Informe 1:

1. Informe 1: Análisis de requerimientos y especificación

2. Lectores del Informe • Stakeholders Cualquier persona interesada en usar el sistema, comprenderlo, hacer requerimientos sobre el mismo o desarrollar parte de éste (gerente, usuarios, guionistas, desarrolladores,...) • Docentes

3. Lineamientos generales • Fácil lectura • Mantener coherencia (definiciones, nombres, formatos, etc.) • Justificar decisiones / afirmaciones / técnicas / herramientas / lenguajes utilizados • No transcribir discursos teóricos de libros, papers, etc. • Longitud: Aprox. 25 páginas A4, font 12 Times New Roman

4. Estructura y presentación (Guía general) • Introducción • Desarrollo • Conclusiones • Glosario • Bibliografía

5. Introducción (Contenidos mínimos) • Propósito del informe • Descripción general del problema • Enfoque para la resolución del problema • Descripción de la organización del informe • Recomendaciones para la lectura • etc...

6. Análisis de requerimientos • Objetivo, alcance y restricciones del sistema • Identificación de requerimientos: • funcionales y no funcionales (descriptos y justificados adecuadamente) • priorizar requerimientos: establecer una forma de clasificación y definir el significado de cada clase • Asignar un “nombre o identificación” a cada requerimiento. Utilizar esta identificación en el resto del informe

7. Análisis de requerimientos • Casos de uso • Explicar mínimamente la técnica • Justificar su utilización • Relacionar los casos de uso con los requerimientos • Aplicar la técnica adecuadamente (identificar casos adecuados, factorizar, ....) • USAR CASOS DE USO NO ES SÓLO HACER DIAGRAMAS

8. Ejemplo I: Objetivo del Sistema El sistema a desarrollar tiene como objetivo facilitar la asignación de equipos de ayuda .... GLOSARIO ....... Equipo de Ayuda: se denomina equipo de ayuda.....

9. Ejemplo I: Alcances del Sistema • El sistema no va a interactuar con las personas que llaman para avisar emergencias .... • La decisión y responsabilidad de qué unidades enviar será de los operadores ...

10. Ejemplo I: Requerimientos • RF1A El sistema debe poder localizar las unidades cada vez que se lo solicite.Para ello ... • RF2C El sistema debe mostrar gráficamente la unidades es un mapa de la ciudad.Esto es, cada unidad.... • RNF1B El sistema debe ser escalable. Se entiende por escalable ..... El identificador de un requerimiento esta formado por identificador del tipo de requerimiento [...], un .....

11. Ejemplo I: Prioridad de req. • Los requerimientos se clasificaran en 4 clases porque ... • Significado de las clases: • Los requerimientos de categoría A son aquellos requerimientos que ..... Requerimiento Prioridad RF1A A RF2C C RF5B B

12. Ejemplo I: Casos de Uso • En este informe se utiliza la técnica casos de uso para..... • Hemos elegido esta técnica porque.... • A continuación se hace una pequeña introducción a los conceptos principales. Una descripción más detallada puede encontrarse en [UML99a][UML99b].... BIBLIOGRAFIA ....... [UML99a] The Unified.....

13. Ejemplo I: Casos de Uso Diagrama de CU. • En este diagrama se muestran .... • Se han identificado los siguientes actores: • Un auditor es .... • Se han identificado las siguientes relaciones ....

14. Ejemplo I: Casos de Uso Este caso de Uso tiene relación con los requerimientos RF2A, RF3C .... Se especifican formalmente en Z (pág 28) Ver DA pág 23, donde se describe ...

15. Ejemplo I: Diag. de actividad • En este informe se utiliza la técnica DA para..... • Hemos elegido esta técnica porque.... • A continuación se hace una pequeña introducción a los conceptos principales. Una descripción más detallada puede encontrarse en [UML99a][UML99b].... BIBLIOGRAFÍA ....... [UML99a] The Unified.....

16. Ejemplo I: Diag. de actividad • En este diagrama se describe el CU Recibiendo ..... Diagrama de Actividad.

17. Especificación No se pretende formalizar todos los aspectos del sistema, sólo aquellos que requieran ser precisados, puntos donde se deban eliminar ambigueda-des, etc.

18. Especificación • Justificar la elección del lenguaje • Identificar claramente el aspecto que se va a describir y fundamentar la necesidad del empleo de una descripción formal • Describir brevemente el lenguaje y/o citar bibliografía • Explicar la relación con otras partes del documento

19. Ejemplo II: Requerimientos LINK al glosario 1.1.1.3 El sistema debe permitir definir gráficamente la especificación del comportamiento, como un hMSC (definición formal en Z). En el sistema debe ser posible definir ..... LINK a la Especificación

20. Ejemplo II: Glosario Glosario Volver hMSC Un digrafo, donde cada nodo contiene una descripción en el lenguaje MSC. Existe un nodo MSC Sinónimo de Diagrama de Secuencias

21. Ejemplo II: Z En esta sección se describe formalmente el concepto de especificación válida. Consideramos fundamental describir formalmente cuáles son las descripciones válidas dado que las mismas ...... Utilizaremos Z (lenguaje de especificación formal explicado en el apéndice IV) dado que posee la capacidad descriptiva necesaria para expresar .... Aspecto a describir y justificación Volver Justificación de la elección de lenguaje Descripción del lenguaje

22. Ejemplo II: Z Un hMSC es un grafo de nodos bMSC (ver esquema NODO_bMSC). De todos los nodos de este grafo, hay uno que está distinguido como el nodo inicial. Todos los nodos comparten el mismo conjunto de instancias. Comentario gral. del Esquema e_hMSC Comentario sobre el predicado

23. Ejemplo II: Z Relaciones con otras secciones del documento • Los esquemas de datos especificados en esta sección se relacionan con las entidades y relaciones definidas en el Modelo de Datos. • Cada entidad del modelo de datos está asociada con un esquema de datos que tiene el mismo nombre precedido por el prefijo e_. Por ejemplo la entidad hMSC se relaciona con el esquema e_hMSC • Las relaciones uno a muchos se han representado en Z como • Lafunción aplicable define formalmente la condición aplicable utilizada en los diagramas de FSM.

24. Ejemplo II: DER hMSC MSC Z Diccionario de datos

25. Proyecto ¿Qué y cómo describimos formalmente en nuestro proyecto? ? ?

26. Conclusiones • Conclusiones sobre el trabajo realizado!!!!: • Instanciadas en el problema abordado • Dificultades con las técnicas/herramientas utilizadas. • Relacionadas con las actividades llevadas a cabo • Referidas al desarrollo de la materia, las actividades de taller preparadas por los docentes • etc..., etc...., etc.... NO REPRODUCIR DISCURSOS TOMADOS DE LA BIBLIOGRAFÍA

27. Para tener en cuenta Estos son lineamientos generales a considerar (no una receta...) La cátedra espera que sean creativos en el trabajo de taller.