Ingeniería de Software

Presentación del tema: "Ingeniería de Software"— Transcripción de la presentación:

1 Ingeniería de Software
Ing. De requerimientos / SRS

2 ¿Qué es la ing. de requerimientos?
Es la disciplina de establecer los servicios requeridos por el cliente para un sistema y las restricciones en las cuales el mismo va a operar y en las cuales va a ser desarrollado, buscando cumplir los objetivos esperados por el cliente.

3 Su importancia “La tarea más difícil de construir un sistema de software es precisamente decidir qué construir. Ninguna otra parte del trabajo conceptual es tan difícil como establecer los requisitos, incluyendo todas las interfaces a las personas, a las máquinas, y otros sistemas del software. Ninguna parte del trabajo lesiona tanto al sistema resultante si hace mal. Ninguna otra parte es más difícil de rectificar después."[Brooks, No Silver Bullets, 1987].

4 ¿Qué es un requerimiento?
El requerimiento puede variar desde una sentencia abstracta de un servicio o restricción a una función matemática detallada. Un mismo requerimiento puede ser dado como fuente para realizar el relevamiento o directamente como un contrato que debe ser respetado. En casos de licitación, una especificación de requerimientos de alto nivel sin detalles se utiliza para que distintos interesados puedan licitar. A partir de cada objetivo es la explicitación de una intención que el cliente requiere para el sistema. De estos objetivos salen los requerimientos. A veces el cliente especifica los requerimientos sin tener en cuenta los objetivos que busca.

5 Clasficación Según punto de vista: Según funcionalidad:
Requerimientos de usuario: Sentencias en lenguaje natural o en poco detalle especificando a alto nivel el servicio provisto. Requerimientos de sistema: Documento estructurado, especificando en detalle y en lenguaje formal, especificando las acciones que hará el sistema para proveer dicho requerimiento Según funcionalidad: Requerimientos funcionales: se ven servicios y funcionalidades individuales que el sistema debe proveer. En general actúan como respuesta a estímulos específicos. En la mayoría de los casos relacionan con el atributo de calidad funcionalidad. Requerimientos no funcionales y restricciones: Se ven servicios y funcionalidades que el sistema debe proveer como un todo. Incluye además requerimientos de tecnologías específicas, estándares de calidad, y restricciones por parte del proceso y la organización. En general pueden ser mas importantes que los funcionales ya que delimitan el accionar de los desarrolladores.

6 Requerimientos no funcionales
En la práctica los requerimientos no funcionales ponen cotas de aceptación a los atributos de calidad. Partiendo de los requerimientos no funcionales, se crean requerimientos funcionales.

7 Complejidades especificando
Imprecisión Es difícil lograr requerimientos específicos. Coherencia Entre los diferentes requerimientos Ambigüedad Sobre todo en el lenguaje Abstracción Solo se debe tener en cuenta lo relevante para el sistema.

8 Identificación de requerimientos
Esta fase consiste en realizar un relevamiento inicial de los requerimientos principales del proyecto No se puede avanzar en las tareas de planificación sin tener una conocimiento global de lo que hay que hacer. No siempre se cuenta con mucho tiempo para realizar esta tarea en detalle, se debe realizar a un alto nivel. Tiene por objetivo: Especificar el objetivo del proyecto y alcance Identificar los roles del cliente Establecer los drivers del proyecto Definir los requerimientos mas importantes del proyecto (“Wish List”) Funcionales No Funcionales Restricciones

9 Identificación de requerimientos
Describe los resultados de negocio esperados a los cuales contribuye la concreción del proyecto El éxito del proyecto deberá medirse en el grado de cumplimiento de dichos objetivos Los objetivos deben ser precisos (de lo contrario no se podrá corroborar si se alcanzaron) Recordar no confundir la solución con el objetivo del proyecto La solución es el curso de acción para alcanzar el objetivo El objetivo no es la forma en que vamos a hacer algo sino el resultado que esperamos

10 Identificación de requerimientos
Alcance Define los límites del sistema Lo que incluye Si es necesario, se aclaran especialmente que “no” incluye (con el objetivo de despejar dudas) La lista de requerimientos debe incluir: Requerimientos Funcionales Describen como debe comportarse el sistema ante determinado estímulo Describen la interacción entre sistema y ambiente (describen los servicios que el sistema proveerá) Requerimientos No Funcionales Describen bajo qué condiciones debe darse el comportamiento del sistema Restricciones Describen limitaciones a la que debe estar sujeta la solución que se diseñe y por lo general tienen poca flexibilidad (no están bajo control directo) Ej.: cumplimiento de estándares / ejecutar sobre cierta plataforma específica / legislación

11 Etapas en la ing. de req.

12 Priorización de requerimientos
La lista debe estar priorizada Esenciales (“Must Have”) Importantes (“Should Have”) Deseables (“Nice to Have”)

13 Chequeo interno de los requerimientos
Validez: El sistema provee la funcionalidad que mejor atiende las necesidades del cliente? Consistencia: Hay algún conflicto entre los requerimientos? Completitud: Están incluidas todas las funciones requeridas por el cliente? Realismo: Se pueden implementar los requerimientos con el presupuesto y la tecnología disponible? Verificabilidad: Se pueden verificar los requerimientos?

14 Chequeo externo de los requerimientos (con los clientes)
Comprensibilidad: Se entienden? Trazabilidad: Se puede identificar claramente el origen de los requerimientos? Adaptabilidad: Se pueden cambiar sin tener un gran impacto en los otros requerimientos?

15 Roles a tener en cuenta Sponsor Usuario Campeón Stakeholders
Es el “owner” del proyecto Es el que tiene la autoridad para llevar adelante el proyecto Usuario Campeón Experto en el dominio del problema del proyecto Asegurar su capacidad para la función y su disponibilidad (son muy demandados) Stakeholders Los que tienen el poder de decisión para con capacidad de influir en la marcha del proyecto Usuarios Directos Interactuan directamente con el sistema Usuario Indirectos Hacen uso del sistema, aunque no necesariamente lo operan

16 Dimensiones Se identifican 5 dimensiones en un Proyecto de SW:
Funcionalidad Calidad Recursos Costo Plazo No se puede cumplir con todas a la vez !! Cada dimensión puede ser Driver: objetivo vital a lograr (tiene poco/nada de flexibilidad) Restricción: no está bajo nuestro control directo y también tiene poco/nada de flexibilidad Grados de Libertad: Libertad para fijar objetivos en alguna dimensión

17 Técnicas de relevamiento: Entrevista
Es una conversacion, no un interrogatorio Se puede hacer con una o mas personas Se pueden utilizar preguntas abiertas (para obtener información cualitativa) o cerrada (determinísticas, por ej cantidades) Pasos para armarla: lectura previa, establecer objetivos, decidir a quienes entrevistar, preparar al entrevistado, decidir estructura y tipo de preguntas, armar entrevista Ventajas: no hay intermediarios, se puede preguntar sobre temas que surgen en el momento, mejora relación con usuario, aporta calidad porque permite hallar opiniones, problemas, políticas, etc. Desventajas: mucho tiempo en planificación, mucho tiempo en entrevistar, poca “cantidad” de información obtenida, mucho tiempo para analizar resultados

18 Observación Se busca obtener una percepción de lo que realmente sucede, no solo de lo documentado Se puede utilizar para verificar lo relevado con otras técnicas Permite obtener información directa sobre qué, cómo, quién, cuándo se hace, cuánto tarda, dónde se hace y para qué se hace la tarea observada. Puede ser participativa (incluye al observador, se interrumpe la tarea), o no participativa (atención: LA OBSERVACIÓN MODIFICA EL EXPERIMENTO)

19 Cuestionario Generalmente las respuestas son “multiple choice” (cerrado), también se pueden hacer para recabar información en general (abirto) Se puede utilizar para cuantificar lo hallado en las entrevistas Antes de distribuir masivamente se recomienda hacer un pequeño test para retocar el cuestionario si hace falta Ventajas: se puede automatizar el análisis, es relativamente barato en comparación a la información obtenida, si son anónimos se puede obtener información sincera Desventajas: suele haber problemas de interpretación, se debe articular para que TODOS los respondan, es poco flexible ya que no se hace en presencia del analista y no permite profundizar en caso de ser necesario

20 Revisión de registros Muy ùtil a la hora de rehacer un sistema existente Problemas: la falta de documentación atenta contra esta técnica de relevamiento Ventaja: se puede hacer búsqueda de patrones en datos, se puede analizar volúmenes y performance esperados

21 SRS El documento de requisitos es un escrito oficial de los requisitos del sistema para los clientes, usuarios finales y desarrolladores de software. Se lo conoce por diferentes nombres: especificación funcional, definición de requisitos, especificación de los requisitos de software (SRS)

22 SRS El documento describe:
Los servicios y funciones que el sistema debería proveer. Las restricciones bajo las cuales el sistema debe operar Las propiedades generales del sistema, entre otras cosas, restricciones sobre las propiedades emergentes del sistema Definiciones de otros sistemas con los cuales el sistema se debe integrar. Información acerca del dominio de aplicación del sistema, por ej. cómo llevar a cabo tipos particulares de cálculos. Restricciones sobre el proceso usado para desarrollar el sistema

23 Caract. de la SRS: Correcto
Un SRS es correcto si, y sólo si, cada requerimiento incluido es uno de los que el software debe cumplir. No hay ninguna herramienta o procedimiento que aseguran la exactitud. Alternativamente el cliente o el usuario pueden determinar si el SRS refleja las necesidades reales correctamente.

24 Caract. de la SRS: Inequívoco
Un SRS es inequívoco si, y sólo si, cada requisito declarado tiene sólo una interpretación. Es aconsejable el uso de un glosario. Hay que tener cuidado con las trampas del idioma natural, se puede apelar a lenguajes de especificación o al uso de herramientas CASE.

25 Caract. de la SRS: Inequívoco

26 Caract. de la SRS: Completo
Los requerimientos deben estar relacionados con la funcionalidad, el desarrollo, las restricciones del diseño, los atributos y las interfaces externas. Se debe incluir la definición de las respuestas del software a todos los posibles datos de la entrada del sistema y a toda clase de situaciones.

27 Caract. de la SRS: Consistente
La consistencia se refiere a la consistencia interior. Si un SRS no está de acuerdo con algún documento del superior-nivel, como una especificación de requisitos de sistema, entonces no es correcto.

28 Caract. de la SRS: Delinear que tiene importancia y/o estabilidad
Un SRS debe delinear la importancia y/o estabilidad si cada requisito en él tiene un identificador para indicar la importancia o estabilidad de ese requisito en particular. Típicamente, todos los requisitos que relacionan a un producto del software no son igualmente importantes.

29 Caract. de la SRS: Comprobable
Un SRS es comprobable si, y sólo si, cada requisito declarado es comprobable. Un requisito es comprobable si, y sólo si, allí existe algún proceso rentable finito con que una persona o la máquina puede verificar que el producto del software reúne el requisito.

30 Caract. de la SRS: Modificable
Un SRS es modificable si, y sólo si, su estructura y estilo son tales que puede hacerse cualquier cambio a los requisitos fácilmente, completamente y de forma consistente mientras conserva la estructura y estilo.

31 Caract. de la SRS: Identificable
Un SRS es identificable si el origen de cada uno de sus requisitos está claro (hacia atrás) y si facilita las referencias de cada requisito en el desarrollo futuro o documentación del mismo (hacia adelante).

32 SRS: Estructura básica
Introducción Propósito del documento de requisitos Alcance del proyecto Definiciones, acrónimos y abreviaturas Resumen del resto del documento Descripción General Perspectiva del producto Funciones del producto Características de los usuarios Limitaciones generales Suposiciones y dependencias Requisitos Específicos Requisitos funcionales, no funcionales Apéndices Índice

33 Preguntas

34 Sugerencias

35 Aplausos