Transcript
Estándar de Ingeniería de Software de la “European Space Agency (ESA)” Sergio Ochoa M. Cecilia Bastarrica
Contenidos • Fases, actividades e hitos establecidos por el estándar. • Conclusiones
2
1
Ciclo de Vida • Todo ciclo de vida del software va desde su concepción hasta cuando ya no está disponible para su uso. • Un modelo de ciclo de vida – estructura las actividades de un proyecto en fases, – define las actividades de cada fase, – determina los hitos dentro del proyecto.
3
Fases de la ESA • • • • • •
UR: definición de requisitos de los usuarios. SR: definición de requisitos del software. AD: definición del diseño arquitectónico. DD: diseño detallado y producción de código. TR: transferencia del software a operaciones. OM: operación y mantenimiento.
4
2
Fases, Actividades e Hitos
5
Principales Hitos • • • •
• •
Aprobación del documento de requisitos del usuario (URD); Aprobación del documento de requisitos de software (SRD); Aprobación del documento de diseño arquitectónico (ADD); Aprobación del documento de diseño detallado (DDD), el manual de software del usuario (SUM), el código y la declaración de terminación para las pruebas primarias de aceptación; Declaración de acptación provisional y confección del documento de transferencia del software (STD); Declaración de aceptación final y entrega del documento de historia del proyecto (PHD).
6
3
Fase de Requisitos del Usuario • • • •
Definición del problema. Los requisitos del usuario deben ser “capturados”. Entrevistas, encuestas, formularios, prototipos. El apoyo de los desarrolladores en esta etapa varía dependiendo de la familiaridad de los usuarios con el software.
•
Se genera un “Documento de Requisitos de Usuario (URD)” siempre. • Participan los usuarios, los ingenieros de software y el administrador del proyecto. • Antes de completar la UR/R, debe construirse un Plan de Administración del Proyecto de Software que muestre todas las fases siguientes, con estimación de recursos.
7
Fase de Requisitos del Software • Fase de análisis del proyecto. • Parte vital de la descripción del modelo, que especifica qué debe hacer el software (y no cómo debe hacerlo). • Puede ser necesario escribir prototipos para clarificar requisitos de software y completar los requisitos del usuario. • El producto de esta fase es el “Documento de Requisitos del Software” (SRD). • Cada proyecto de software debe contar con este documento. • Debe omitirse todo detalle de implementación. 8
4
Fase de Requisitos del Software • El documento debe ser revisado por los usuarios, los ingenieros de software y por el administrador del proyecto durante la “Revisión de Requisitos del Software” (SR/R). • El Plan de Administración del Proyecto de Software debe revisarse en esta fase. • Deben hacerse los mayores esfuerzos para tener estimaciones con errores menores del 30%. • Debe construirse un plan detallado como base
para la fase de AD.
9
Fase de Diseño Arquitectónico • En esta fase se define la estructura del software a partir del modelo construido en la fase SR. • Este modelo se transforma en diseño arquitectónico asignando funciones a componentes de software y definiento el control y flujo de datos entre ellos. • Puede ser necesario iterar varias veces en el diseño. • Las dificultades técnicas y partes críticas del sistema deben ser identificadas. – Puede ser necesario construir prototipos para comprobar la factibilidad ténica.
10
5
Producto de la Fase de Diseño Arquitectónico • El item entregable es el “Documento de Diseño Arquitectónico” (ADD). • El ADD debe ser formalmente revisado por los ingenieros de software, los usuarios y el administrador del proyecto durante la AD/R. • En esta fase debe refinarse el Plan de Adminsitración de Proyecto de Software para el resto del proyecto. – debe contener una estimación del costo del proyecto con un error menor al 10%.
• También debe hacerse un plan detallado para la fase de DD. 11
Fase de Diseño Detallado y Producción • El propósito de esta fase es el de detallar el diseño de software, codificarlo, documentarlo y probarlo. • En forma concurrente se hacen: – la condificación y las pruebas, – los documentos de diseño detallado (DDD) y manual de software del usuario (SUM).
• Los documentos DDD y SUM contienen: – las secciones de los niveles superiores del sistema, – a medida que el diseño progresa, también las subsecciones relacionadas con los niveles más bajos.
12
6
Producto de la Fase de Diseño Detallado y Producción • Al final de la fase, los documentos están completos y, junto con el código, constituyen los ítems entregables. • En esta fase se realizan las pruebas de unidad, de integración y de sistema, de acuerdo con los planes de pruebas establecidos en SR y AD.
13
Revisión en la Fase de Diseño Detallado y Producción • Los 3 entregables (código, DDD y SUM) deben ser revisados formalmente por los ingenieros de software y el administrador (DD/R). • Al final de la revisión, el software puede considerarse listo para las pruebas de aceptación provisional.
14
7
Fase de Transferencia • El propósito de esta fase es establecer que el software cumple con los requisitos especificados en el URD. • Esto se realiza instalando el software y aplicando las pruebas de aceptación. • Si el software muestra las capacidades requeridas, entonces puede ser aceptados provisionalmente y con ello comienza la operación. • Como producto de la transferencia (TR) se genera el Documento de Transferencia del Software (STD) que documenta el proceso para el equipo de operaciones. 15
Fase de Operación y Mantenimiento • Una vez en operación, el software debe monitorearse para confirmar que cumple los requisitos del URD. • Algunos requisitos, especialmente los no funcionales, puede tomar algún tiempo validarlos. • El software se acepta en forma definitiva cuando ha pasado todos las pruebas. • El documento de historia del proyecto (PHD) resume la información administrativa relevante acumulada durante el proyecto – este documento se genera después de la aceptación final, – debe rehacerse al final del ciclo de vida incluyendo la información de la fase OM. 16
8
Mantenimiento • Después de la aceptación final, el software puede ser modificado – para corregir errores no detectados durante fases anteriores, – para incluir nuevos requisitos.
• Durante todo el período de operación debe hacerse un esfuerzo especial para mantener toda la documentación actualizada. • La información sobre fallas y caídas debe registrarse para establecer métricas de calidad del software para ser usadas en proyectos subsiguientes. 17
Modelo de Proceso para CC51A • En el curso se usará una adaptación del modelo propuesto por la ESA. • Esta adaptación apunta a: – simplificar el modelo original haciéndolo más aplicable a proyectos chicos a medianos; – realizar un desarrollo incremental del producto final; – aumentar el paralelismo entre las tareas que realizan los miembros del equipo de trabajo.
• A continuación se muestra la dinámica del modelo adaptado.
18
9
Modelo Adaptado
Semana Semana Fase Fase 11
1
2
3
4
Análisis
5
6
7
8
Diseño/Implementación
Fase Fase 22
9
10 11 12 13 14 15 16
Transf.
Análisis
Diseño/Implementación
Transf.
19
Tareas del Analista Semana Semana Fase Fase 11 Fase Fase 22
1
2
3
A1 (3-5 sem.)
4
5
6
7
DI1 (4-5 sem.)
A2 (4,5 sem)
8
9
10 11 12 13 14 15 16
T1 (2 sem)
DI 2 (7 sem)
T2.
Referencia Referencia Recopilación de Información Especificación de Requisitos Validación de Requisitos (con el cliente y/o con los diseñadores/implementadores) Control de cumplimiento de Requisitos 20
10
Tareas de Diseño e Implementación 1
Semana Semana Fase Fase 11
2
3
4
5
A1 (3-5 sem.)
6
7
8
9
DI1 (4-5 sem.)
10 11 12 13 14 15 16
T1 (2 sem)
Diseño Implementación
Fase Fase 22
A2 (4,5 sem)
DI 2 (7 sem)
T2
Diseño Implementación
Preparación de herramienas y definición de reglas de funcionamiento Diseño de prototipos Implementación de prototipos Control de cumplimiento del Diseño Diseño del producto Implementación del producto Corrección y ajuste del producto
21
Tareas de Administración y Pruebas 1
Semana Semana Fase Fase 11
2
3
A1 (3-5 sem.)
4
5
6
7
8
DI1
9
10 11 12 13 14 15 16
T1
Administración Pruebas
Fase Fase 22
A2 (4,5 sem)
DI 2 (7 sem)
T2
Administración Pruebas
Interacción con el cliente Monitoreo, redefinición y coordinación de tareas (guiar el barco) Entrega del producto Planificación de controles y definición del tipo de revisión Control de productos y emisión de alertas Prueba del producto 22
11
Conclusiones • El estándar de la ESA propone un conjunto de actividades para abordar el “ciclo de vida” de un proyecto de software. • Puede ser adaptado para la realidad de una empresa específica. • Puede ser aplicado en forma parcial, según la naturaleza del problema a resolver. • Es simple, por lo tanto, con poca práctica se puede hacer un buen uso de él. • Nos podría ayudar a certificar ISO 9000. 23
Bibliografía y Casos • I. Sommerville, P. Sawyer. “Requirements Engineering, A Good Practice Guide.” Wiley, 1999. • S. Robertson, J. Robertson. “Mastering the Requirements Process.” Addison-Wesley, 1999. • ESA, SOFTWARE ENGINEERING STANDARDS, ISSUE 2. Preparado por ESA Board for Software Standardisation and Control (BSSC). URL: http://www.estec.esa.nl/wmwww/WME/index.html
24
12