ANALISIS DE REQUERIMIENTOS DE SOFTWARE

1. ANALISIS DEREQUERIMIENTOS DE SOFTWARE UNIDAD 5 Jesús Martínez San Germán

2. Contenido • Análisis de Requerimientos de Software • 5.1Fase Preliminar • 5.2Fase de Análisis • 5.3Principios de Análisis • 5.4Modelo de Análisis • 5.5Técnicas de Especificación • 5.6 Especificación de Requerimientos de Software

3. 5.1Fase Preliminar

4. Análisis de las áreas de negocio • define “grupos de funciones y datos de negocio naturalmente cohesivos” (Martin) • lleva a cabo algunas de las mismas actividades que el ISP, pero en un alcance más restringido en las áreas de negocio individuales • identifica sistemas de información existentes (viejos) / determina la compatibilidad con el modelo del nuevo ISP • define sistemas que son problemáticos • defne sistemas que son incompatibles con el nuevo modelo de información • comienza a establecer las prioridades de reingeniería

5. El proceso BAA admin. manufactura QC distrib. ventas cont ing. Diagram. Descomp. Procesos Matrices v.g., matriz entidad/ proceso Modelo de Flujo de Procesos IDEF0/3 Modelo de Datos E/R

6. Ingeniería de Producto El producto completo Análisis de sistema (Vista Panorámica) características Ingeniería de hardware software componentes (Vista de Dominio) Requerimiento de procesamiento Modelo funciones comportamiento datos Análisis y Diseño (Vista de Elemento) componentes Ingeniería de programa Software Construcción e Integración (vista detallada)

7. Ingeniería deRequerimientos • Licitación — determinar qué requiere el usuario • Análisis y negociación — entender las relaciones entre varios requerimientos de clientes y conformar esas relaciones para lograr un resultado exitoso • Especificación de requerimientos — construir un modelo de requerimientos tangible

8. Ingeniería de Requerimientos • Modelado del Sistema — construir una representación de requerimientos que serán la base para la correctividad, completitud y consistencia. • Validación — revisar el modelo • Administración — identificar, controlar y dar seguimiento a los requerimientos y los cambios que serán aplicados a estos

9. Plantilla de Arquitectura de Producto procesamiento de la interfaz del usuario procesamiento procesamiento funciones de de la entrada de la salida proceso y control mantenimiento y auto-prueba

10. Diagrama de Flujo de la Arquitectura interfaz del operador requerimientos del operador subsistema consultas, reportes y despliegues de la interfaz del operador requerimientos de adquisición de código de barras status de control de activación reportes ordenados proccesamiento y control CLSS datos de temporización/localización requerimientos de reportes subsistema controlador número de subsistema de control Subsistema parte de activacón lector de de activación decodificador código de barras código de barras datos código de localización comandos de activacion code barras crudos binaria código de barras subsistema de acceso reportes CLSS a base de datos subsistema velocidad de formateo clave subsistema de línea de reportes de adquisición de datos sensados registros ordenados controlador de comunicaciones BCR status shunt status subsistema status de sensor entrada de pulsos de diagnóticos datos de reporte formateados status de comunicaciones interfaz de status del lector adquisición de datos interfaz de salida de código de barras interfaz de diagnóstico

11. 5.2Fase de Análisis

12. ¿Cuáles son los problemas reales? el cliente tiene una idea muy vaga de lo que se requiere. el desarrollador decide avanzar con la “idea vaga” con el supuesto de que “iremos encontrando los detalles conforme avanzamos” el cliente continua cambiando los requerimientos el desarrollador es “afectado” por estos cambios, cometiendo errores en las especificaciones y desarrollo y así continúa...

13. Análisis de Requerimientos de Software • identificar al “cliente” y el trabajo; así como negociar los requerimientos de “nivel-producto” • construir un modelo de análisis • enfocarse en los datos • definir la función • representar el comportamiento • prototipar áreas de incertidumbre • desarrollar una especificación que guiará el diseño • conducir revisiones técnicas formales

14. Reunir requerimientos Facilitated Application Specification Techniques Técnicas de Especificación de Aplicaciones Grupo de Grupo del Ingeniería Cliente de Softare

15. Guías FAST • los participantes deben asistir a la reunión completa • todos los participantes son iguales • la preparación es tan importante como la reunión • todos los documentos pre-reunión deben ser vistos como “propuestos” • la ubicaciones de las reuniones fuera de sitio son preferibles • establecer y mantener una agenda • no enfrascarse en detalles técnicos J. Wood & D. Silver

16. Distribución de la Función de Calidad • La Distribución de la Función determina el “valor” (como lo percibe el cliente) de cada función requerida en el sistema • La Distribución de Información identifica objetos de datos y eventos • Distribución de Tareas examina el comportamiento del sistema • Análisis del valor determina la prioridad relativa de los requerimientos

17. Casos de Uso • Una colección de escenarios que describe “el hilo” o situación de uso del sistema • Cada escenario es descrito desde el punto de vista de un “actor” – una persona o dispositivo que ineractúa con el software de alguna manera • Cada escenario contesta las siguientes preguntas • ¿cuáles son las principales tareas o funciones llevadas a cabo por el actor? • ¿qué sistemas de información el actor adquiere, produce o cambia” • ¿el actor informará al sistema acerca de cambios del entorno? • ¿qué información el actor requiere del sistema? • ¿el usuario desea ser informado acerca de cambios no esperados?

18. 5.3 Principios de Análisis

19. El proceso de Análisis constuir un prototipo Licitación de Requerimientos Desarrollar Especificación el problema Revisión crear modelos de análisis

20. Principio de Análisis IModelar el Dominio de los Datos • definir los objetos de datos • describir atributos de los datos • establecer relaciones de los datos

21. Principio de Análisis IIModelar la Función • identificar funciones que transforman los objetos de datos • indicar el flujo de datos del sistema • representar los productores y consumidores de los datos

22. Principio de Análisis IIIModelar el Comportamiento • indicar los diferentes estadosdel sistema • especificareventosque provocan que el sistema cambie de estado

23. Principio de Análisis IVParticionar los modelos • refinar cada modelo para representar niveles más bajos de abstracción • refinar objetos de datos • crear una jerarquía funcional • representar el comportamiento a diferentes niveles de detalle

24. Principio de Análisis VEsencia • comenzar enfocándose en la esencia del problema sin descuidar los detalles de implantación

25. Principios de Davis • Entender el problema antes de comenzar a crear el modelo de análisis. • Desarrollar prototipos que permitan al usuario entender cómo será la interacción hombre-máquina. • Registrar el origen de y la razón de cada requerimiento. • Utilizar múltiples vistas de los requerimientos. • Priorizar los requerimientos. • Trabajar para eliminar la ambigüedad.

26. 5.4. Modelo de Análisis

27. El Modelo de Análisis Modelos de Datos Modelo Funcional Modelo de Comportamiento

28. Modelo de Análisis:¿Dónde comenzar? • Establecer una Sentencia o Declaración de Alcance a partir de: • el documento de trabajo FAST • un conjunto de casos de uso • la sentencia de alcance debe ser “analizada” para extraer datos, funciones y comportamiento de la información del dominio

29. Declaración del Alcance • una descripción breve (relativa) del sistema a ser desarrollado • indica los datos que son entrada y salida, así como la funcionalidad básica • indica el procesamiento condicional (a alto nivel) • implica ciertas restricciones y limitaciones

30. Identificar objetos y operaciones • definir “objetos” mediane subrayar todos los sustantivos den la declaración de alcance • productores/consumidores de los datos • establecer dónde los datos serán almacenados • elementos de datos “compuestos” • definir “operaciones” mediante subrayar doble todos los verbos activos • procesos relavantes a a aplicación • transformaciones de los datos • considerar otros “servicios” que serán requeridos por los objetos

31. Modelado de Datosy Diagramación Entidad Relación (E-R)

32. ¿Qué es el Modelado de Datos? • examinar los objetos de datos independientemente del procesamiento • enfoca la atención en el dominio de los datos • crea un modelo a nivel de abstracción del cliente • indica cómo los datos se relacionan entre sí

33. ¿Qué es un Objeto de Datos? Objeto —algo que es descrito por el conjunto de atributos (elementos de datos) y serán manipulados dentro del software (sistema) cada instancia de un objeto (v.g., un libro) puede ser identificado únicamente (v.g. ISBN) cada uno desempeña un rol necesario en el sistema v.g., el sistema no puede funcionar sin acceso a las instancias del objeto cada uno es descrito por atributos que son elementos de datos por sí mismos

34. Objetos típicos entidades externas(impresora, usuario, sensor) cosas (v.g, reportes, despliegues, señales) ocurrencias o eventos(e.g., interruptor, alarma) roles (v.g., administrador, ingeniero, vendedor) (v.g., división, equipo) unidades organizacionales lugares (v.g., piso de manufactura) estructura(v.g., registro de empleado)

35. Objetos de Datos y Atributos Un objeto de datos contiene un conjunto de atributos que actúan como un aspecto, cualidad, característica, o descriptor del objeto objeto: automóvil atributos: fabricante modelo carrocería precio código de opc.

36. ¿Qué es una relación? • pueden existir varias instancias de una relación • los objets pueden ser relacionados de diferentes formas relación —indica “conexionismo”; un “hecho” que debe ser “recordado” por el sistema y no puede ser computado o derivado mecánicamente

37. Notación ERD Una forma común: (0, m) objeto objeto relación 1 2 (1, 1) atributos Otra forma común: relación objeto objeto 1 2 (1, 1) (0, m)

38. Construcción de un ERD • Nivel 1—modelar todos los objetos de datos (entidades) y sus “conexiones” a otros • Nivel 2—modelar todas las entidades y sus relaciones • Nivel 3—modelar todas las entidades, relaciones,y los atributos que proveen mayor profundidad

39. Ejemplo de un ERD requerim. de serv. Cliente lugares (1,1) (1,m) (1,1) tareas estándar (1,n) orden trabajo genera (1,1) (1,1) (1,1) (1,w) tareas seleccionado de consiste de (1,w) (1,i) materiales lista

40. Creación delModelo de Flujo

41. Modelo de Flujo Cada sistema basado en computadora es una transformación de información sistema basado computadora entrada salida

42. Notación del Modelo de Flujo entidad externa proceso flujo de datos almacenamiento de datos

43. Entidad Externa Un productor o consumidor de información Ejemplos: una persona, un dispositivo, un sensor Otro ejemplo: un sistema basado en computadora Los datos deben siempre originarse en algún lado y deben siempre enviarse a otro

44. Proceso Un transformador de datos (cambia una entrada por una salida) Ejemplos: impuestos calculados, calcular áreas, formatear un reporte, desplegar un gráfico Los datos deben siempre ser pocesados de alguna manera para llevar a cabo una función

45. Flujo de Datos Los flujos de datos a través de un sistema, comienzan con una entrada y deben ser transformados a una salida. base calcular el área de un triángulo área altura

46. Almacenamiento de Datos Los datos son frecuentemente almacenados para un uso posterior #sensor #sensor, tipo, ubicación, intevalo revisión de los datos del sensor reporte requrido tipo, ubicación, intervalo #sensor datos del sensor

47. Diagramación del Flujo de Datos:Guías • todos los íconos deben ser etiquetados con nombres significativos • el DFD evoluciona a través del úmero de niveles de detalle • siembre comienzan con un diagrama de contexto (siempre llamado “nivel 0”) • muestran las entidades externas a nivel 0 • los flujos de datos simpre están etiquetados • no se representa la lógica procedural

48. Construcción de un DFD—I • revisar un ERD para aislar los objetos de • datos y revisar gramaticalmente para determinar “operaciones” • determinar las entidades externas (productores y consumidores de datos) • crear el nivel 0 del DFD

49. Ejemplo de un Nivel 0 del DFD requerimiento de procesamiento usuario señal de video requerida procesador de video digital monitor fuente de video Señal de video NTSC

50. Construcción de un DFD—II • escribir una narrativa describiendo la transformación • revisar para determinar las transformaciones del siguiente nivel • “balancear” el flujo para mantener la continuidad del flujo de datos • desarrollar el Nivel 1 del DFD • utilizar una expansión 1:5 (aprox.)