Gestión de Tecnologías de la Información

Aseguramiento de Calidad del Software

Temario : • Estándar E.S.A.

• El árol de documentos. • Modelo del Ciclo de vida. • Fases :

• Definición de requerimientos de usuario (UR) • Definición de requerimientos de software (SR) • Diseño aquitectónico (AD); • Diseño detallado y codificación (DD); • Transferncia; • Operación y manutención.

• Enfoques del Estándar E.S.A.: • Modelo de proceso cascada. • Modelo de proceso incremental. • Modelo de proceso evolutivo.

European Space Agency

Estándar E.S.A. - Árbol de documentos

Estándar E.S.A. - Árbol de documentos

Documentos del nivel 1: Contiene uno y sólo un documento, ESA PSS-05-0 que es una norma obligatoria para todos los proyectos de ESA.

Documentos del nivel 2: Los documentos del nivel 2 ofrecen una guía para llevar a cabo las prácticas del estándar describieron en ESA PSS-05-0.

El primer documento del nivel 2, ESA PSS-05-01 (ese documento) existe para definir y explicar el árbol de documentos.

El ESA PSS-05-0 divide las actividades de ingeniería de software en dos partes: los propias al productos y los procedimientos usados para fabricar este producto.

El proceso de producción lo divide en seis fases: • Definición de requerimientos del Usuario; (ESA PSS-05-02) • Definición de requerimientos del Software; (ESA PSS-05-03) • Plan Arquitectónico; (ESA PSS-05-04) • Diseño detallado y Producción; (ESA PSS-05-05) • Transfer; (ESA PSS-05-06) • Operación y Manutención. (ESA PSS-05-07)

Documentos del nivel 3: El nivel 3 tiene definiciones para codificación en Fortran (ESA PSS-05-05-01); codificación en ADA (ESA PSS-05-05-02); y codificación en C (ESA PSS-05-05-03).

Modelo del ciclo de vida del software

HITOS DESTACADOS

REVISIONES

DOCUMENTOS ENTREGABLES La flecha indica cambio de mando

ACTIVIDADES DESTACADAS

ITEMS

FASES

Documento Requerimientos de usuario

• determinar ambiente operacional

• identificar requerimientos de usuarios

UR USER REQUIREMENT DEFINITIONS

UR/R

+ Revisiones

técnicas Recorrer las inspecciones

+.........+

Documento Requerimientos de software

• construcción del modelo lógico

• Identificar requerimientos del software

SOFTWARE REQUIREMENT DEFINITIONS

SR SR/R

+ Revisiones

técnicas

+.........+ Recorrer las inspecciones

Documento de diseño arquitectural

• construcción del modelo físico

• definición de los componentes generales

ARCHITECTURAL DESIGN

AD AD/R

+ Revisiones

técnicas

+.........+ Recorrer las inspecciones

Documento del diseño detallado

• diseño de módulos • código • pruebas unitarias • pruebas de

integración • pruebas del

sistema

DD DETAILED DESIGN AND PRODUCTION

DD/R

Revisiones técnicas

+

Modelo del ciclo de vida del software Estándar E.S.A.

URD

Documento de Transferencia del software

• instalación

• Test de aceptación provisorio

TRANSFER

TR

Documento historia del proyecto

• Test de aceptación final

• Operación • Manutención del

código y documentos

SRD STD

OM OPERATIONS AND MAINTENANCE

PHD DDD

Código SUM

Software User Manual

ADD

URD Aprobado

SRD Aprobado

ADD Aprobado

código/DDD/SUM aprobado

STD entregable

Aceptación provisional

PHD entregable

Aceptación final

Estándar E.S.A. Enfoque en Cascada

SR

AD

DD

TR

OM

UR • El modelo en cascada es el más simple de

ajustar al estándar E.S.A. • Las fases se ejecutan secuencialmente, como

muestran las flechas rojas. • Cada fase se ejecuta una vez, aunque la

iteración de las fase permiten la corrección del error, como se muestra por las flechas azules.

• La entrega del sistema completo se produce en un solo hito, al final de la fase de TR.

Fase

Estándar E.S.A. Enfoque a entregas

incrementales

SR UR

AD DD

TR OM

1

1

1

DD TR

OM

2

2

2

Las entregas incrementales se caracterizan por dividir las fases DD, TR y OM en varias unidades más manejables, una vez que el plan arquitectónico completo está definido. El software se va entregando en múltiples versiones, cada uno con incrementos funcionales y de capacidad. Este enfoque puede ser beneficioso para proyectos grandes dónde una sola entrega sería impracticable. Esto puede ocurrir por varios razones como :

•Que ciertas funciones necesiten estar antes para que tras puedan ser efectivas;

•El tamaño del equipo de desarrollo hace necesario subdividir el proyecto en varios entregas;

•El presupuesto de fondos está distribuido en un número n de años.

En todos los casos, cada entregable debe ser un producto usable, y provea un subconjunto de las capacidades requeridas. Una desventaja del enfoque de entregas incremental es el hecho de necesitar pruebas regresivas que aseguren que las capacidades existentes del software no se han daña con la nueva versión. Las pruebas incrementales requeridos incrementan el costo del software.

Estándar E.S.A. Enfocado al desarrollo

Incremental evolutivo

SR UR

AD DD

TR OM

1

1

1

1

1

1

SR UR

AD DD

TR OM

2

2

2

2

2

2

El enfoque incremental evolutivo se caracteriza por un desarrollo que planifica liberar múltiples versiones. Para producir una nueva versión, todas las fases del ciclo de vida serán ejecutadas. Cada versión incorpora las experiencias de las versiones previas. El enfoque evolutivo puede usarse porque, por ejemplo: • Algunos usuarios tienen poca experiencia y se exige refinar y

completar los requisitos. • Algunas partes de la implementación pueden depender de la

disponibilidad de futuras tecnologías; • Se consideran nuevos requisitos de usuario pero aun no se conocen; • Algunos requisitos pueden ser significativamente más difíciles de

conocer que otros, y se decide no retrasar una entrega utilizable. Las extensiones dibujadas muestra que el traslape de las fases puede ocurrir hasta que cada nueva versión sea finalmente aceptada.

SR UR

AD DD

TR OM

1

1

1

1

1

1

SR UR

AD DD

TR OM

2

2

2

2

2

2

En un desarrollo incremental evolutivo, el diseñador debe considerar las prioridades del usuario y producir las partes del software que se consideran importante para el usuario y, posibles de desarrollar con mínimos problemas técnicos o retrasos. La desventaja de este enfoque evolutivo es que si los requisitos están muy incompletos al empezar, la estructura inicial del software podría no soportar el peso de evoluciones posteriores. Un costoso rediseño puede ser necesario. Peor aun, las soluciones temporales pueden volverse empotradas en el sistema y distorsionar su evolución. En el futuro, los usuarios pueden ponerse impacientes con los problemas detectados en cada nueva versión. En cada ciclo de desarrollo, es importante como objetivo una declaración completa de los requisitos (para reducir el riesgo) y un plan adaptable (para asegurar posteriores adaptaciones). En un desarrollo evolutivo, no es necesario llevar a cabo todos los requisitos en cada ciclo de desarrollo. Sin embargo, el plan arquitectónico debe considerar todos los requisitos conocidos.