DISEÑO DE LA TRAZABILIDAD Mónica Cifuentes Villamil.

Presentación del tema: "DISEÑO DE LA TRAZABILIDAD Mónica Cifuentes Villamil."— Transcripción de la presentación:

1 DISEÑO DE LA TRAZABILIDAD Mónica Cifuentes Villamil

2 NECESIDAD ¿Cómo manejar los cambios de los requisitos en el proyecto? ¿Cómo beneficiarse en de hacer el correcto uso de la trazabilidad? Es vital evaluar rápidamente el costo del cambio.

3 QUE ES TRAZABILIDAD Es la documentación de las relaciones entre las capas de información, los requerimientos del sistema y el diseño.

4 BENEFICIOS Verifica que los requerimientos del cliente estén presentes en el proyecto Que hace cada componente Permite realizar pruebas mas concretas Facilita la revisión

5 RAZON DE LA TRAZABILIDAD Relaciona componentes del sistema Ayuda a entender mejor el sistema Satisface un argumento Pruebas Verificación

6 COMO SE HACE Verificación de cada requerimiento del cliente vs. diseño del sistema Suficiente Necesario

7 PROCESO DE CAMBIO 1. Identificar impacto 2. Calcular árbol de impacto 3. Elaborar árbol de impacto 4. Definir el cambio 5. Aplicar el cambio

8 BIBLIOGRAFÍA Design Traceability. Jeremy Dick. IEEE SOFTWARE Published by t he I E E E C o m p u t e r S o c i e t y. 2005

9 ¿Por qué el contexto importa? Y ¿Qué podemos hacer sobre el? Mónica Cifuentes Villamil

10 NECESIDAD Cada problema de diseño empieza por lograr la interacción entre la forma y el contexto. Forma contexto

11 QUE ES?  Forma:  es el resultado final del diseño de SW  Implementación  Producto  Contexto:  Definición del problema  Lo obvio  Lo sutil  Lo invisible  Lo incomprensible

12 AMBIENTE DE DISEÑO Condición Ambigüedad Visibilidad Stakeholders

13 LO OBVIO Relevancias que le importa a todos los Stakeholders Cliente y usuarios esperan que aborden todos Los diseñadores Selectivos: Costos Tiempo Tecnología restricciones

14 LO OBVIO Definir limitaciones Alcance del sistema Estrategia: Comunicación Delegar a algunos diseñadores roles de usuario

15 LO SUTIL Lo que es obvio para lo usuarios pero para los diseñadores no. Definir requerimientos funcionales y no funcionales Observación en la organización, usuarios y clientes Evaluaciones formales

16 LO INVISIBLE Practicas de ingeniería de Software Bosquejos del ambiente Trazabilidad

17 LO INCOMPRENSIBLE Impacto inesperado del SW sobre los usuarios y clientes Impacto inesperado sobre los analistas y diseñadores Enfocar requerimientos no funcionales Observación Descubrir regiones de contexto hondos. Satisfacción del usuario

18 ¿POR QUE IMPORTA EL CONTEXTO? Define nuestra visión y opinión del sistema Define alcance Define restricciones, requerimientos, especificaciones, necesidades, riesgos Conocimiento explicito del problema Diseño mas completo

19 BIBLIOGRAFÍA Why Context Matters—And What Can We Do about It?. Donald C. Gause. September / October 2 0 0 5 IEEE SOFTWARE