Gestin de Tecnologas de la Informacin

Aseguramiento de Calidad del Software

Temario :

Estndar E.S.A.
El rbol de documentos

Modelo del Ciclo de vida.

Fases :
Definicin de requerimientos de usuario (UR)
Definicin de requerimientos de software (SR)
Diseo aquitectnico (AD);
Diseo detallado y codificacin (DD);
Transferncia;
Operacin y manutencin.

Enfoques del Estndar E.S.A.:

Modelo de proceso cascada.
Modelo de proceso incremental.
Modelo de proceso evolutivo.
European Space Agency
Estndar E.S.A. - rbol de documentos
 Estndar E.S.A. - rbol de documentos

Documentos del nivel 1:

Contiene uno y slo 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 gua para
llevar a cabo las prcticas del estndar 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 ingeniera

de software en dos partes: los propias al productos y
los procedimientos usados para fabricar este
producto.

El proceso de produccin lo divide en seis fases: Documentos del nivel 3:

El nivel 3 tiene definiciones para codificacin
Definicin de requerimientos del Usuario; (ESA PSS-05-02) en Fortran (ESA PSS-05-05-01); codificacin
Definicin de requerimientos del Software; (ESA PSS-05-03) en ADA (ESA PSS-05-05-02); y codificacin en
Plan Arquitectnico; (ESA PSS-05-04) C (ESA PSS-05-05-03).
Diseo detallado y Produccin; (ESA PSS-05-05)
Transfer; (ESA PSS-05-06)
Operacin y Manutencin. (ESA PSS-05-07)
Modelo del ciclo de vida del software
 Modelo del ciclo de vida del software
Estndar E.S.A.
FASES UR UR/R SR SR/R AD AD/R DD DD/R TR OM
USER SOFTWARE DETAILED OPERATIONS
ARCHITECTURAL TRANSFER
ITEMS REQUIREMENT REQUIREMENT DESIGN DESIGN AND AND
DEFINITIONS DEFINITIONS PRODUCTION MAINTENANCE

ACTIVIDADES determinar diseo de mdulos instalacin Test de

DESTACADAS ambiente construccin del construccin del cdigo aceptacin final
operacional modelo lgico modelo fsico pruebas unitarias Test de aceptacin
pruebas de provisorio Operacin
identificar Identificar definicin de los integracin
requerimientos del componentes pruebas del Manutencin del
requerimientos de
software generales sistema cdigo y
usuarios
documentos

DOCUMENTOS Documento Documento Documento Documento Documento de Documento

ENTREGABLES Requerimientos Requerimientos de diseo del diseo Transferencia historia del
de usuario de software arquitectural detallado del software proyecto

URD SRD ADD STD PHD

cambio de Cdigo
mando SUM

Software User Manual

REVISIONES
+ +.........+ + +.........+ + +.........+ +
Revisiones Recorrer las Revisiones Recorrer las Revisiones Recorrer las Revisiones
tcnicas inspecciones tcnicas inspecciones tcnicas inspecciones tcnicas

HITOS
DESTACADOS
URD SRD ADD cdigo/DDD/SUM STD PHD
Aprobado Aprobado Aprobado aprobado entregable entregable
Aceptacin Aceptacin
provisional final
 Estndar E.S.A.
Enfoque en Cascada

El modelo en cascada es el ms simple de

ajustar al estndar E.S.A.
UR Las fases se ejecutan secuencialmente, como
muestran las flechas rojas.
Cada fase se ejecuta una vez, aunque la
SR iteracin de las fase permiten la correccin del
error, como se muestra por las flechas azules.
La entrega del sistema completo se produce en
AD un solo hito, al final de la fase de TR.

DD

TR

Fase OM
 Estndar E.S.A. Las entregas incrementales se caracterizan por dividir las
fases DD, TR y OM en varias unidades ms manejables,
Enfoque a una vez que el plan arquitectnico completo est
definido.

entregas El software se va entregando en mltiples versiones,

incrementales cada uno con incrementos funcionales y de capacidad.

UR
Este enfoque puede ser beneficioso para proyectos
grandes dnde una sola entrega sera impracticable. Esto
puede ocurrir por varios razones como :

SR Que ciertas funciones necesiten estar antes para que

tras puedan ser efectivas;

AD El tamao del equipo de desarrollo hace necesario

subdividir el proyecto en varios entregas;

DD El presupuesto de fondos est distribuido en un

1 nmero n de aos.
TR En todos los casos, cada entregable debe ser un
1
OM
producto usable, y provea un subconjunto de las
capacidades requeridas.
1
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 daa
con la nueva versin.

DD2
Las pruebas incrementales requeridos incrementan el
costo del software.

TR 2
OM 2
 Estndar E.S.A.
Enfocado al desarrollo
Incremental
1 evolutivo El enfoque incremental evolutivo se caracteriza por un desarrollo que
planifica liberar mltiples versiones.
UR 1
SR
Para producir una nueva versin, todas las fases del ciclo de vida sern
1 ejecutadas.

AD 1 Cada versin incorpora las experiencias de las versiones previas.

DD 1 El enfoque evolutivo puede usarse porque, por ejemplo:

TR 1 Algunos usuarios tienen poca experiencia y se exige refinar y

OM
completar los requisitos.
Algunas partes de la implementacin pueden depender de la
disponibilidad de futuras tecnologas;
Se consideran nuevos requisitos de usuario pero aun no se conocen;
Algunos requisitos pueden ser significativamente ms difciles de
conocer que otros, y se decide no retrasar una entrega utilizable.
2
UR 2
Las extensiones dibujadas muestra que el traslape de las fases puede
ocurrir hasta que cada nueva versin sea finalmente aceptada.
SR 2
AD 2
DD 2
TR 2
OM
 En un desarrollo incremental evolutivo, el diseador debe
considerar las prioridades del usuario y producir las partes
del software que se consideran importante para el usuario
y, posibles de desarrollar con mnimos problemas tcnicos
1 o retrasos.
UR 1 La desventaja de este enfoque evolutivo es que si los
SR 1 requisitos estn muy incompletos al empezar, la estructura
inicial del software podra no soportar el peso de
AD 1 evoluciones posteriores. Un costoso rediseo puede ser

DD
necesario.
1
TR
Peor aun, las soluciones temporales pueden volverse
empotradas en el sistema y distorsionar su evolucin.
1
OM En el futuro, los usuarios pueden ponerse impacientes
con los problemas detectados en cada nueva versin.

En cada ciclo de desarrollo, es importante como objetivo

una declaracin completa de los requisitos (para reducir el
2 riesgo) y un plan adaptable (para asegurar posteriores

UR
adaptaciones).
2
SR 2
En un desarrollo evolutivo, no es necesario llevar a cabo
todos los requisitos en cada ciclo de desarrollo. Sin
AD embargo, el plan arquitectnico debe considerar todos los
re2
quisitos conocidos.
DD 2
TR 2
OM