Gestin de Tecnologas de la Informacin

Aseguramiento de Calidad del Software

Temario :

Estndar E.S.A.
El rol 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:

Definicin de requerimientos del Usuario; (ESA PSS-05-02)

Definicin de requerimientos del Software; (ESA PSS-05-03)
Plan Arquitectnico; (ESA PSS-05-04)
Diseo detallado y Produccin; (ESA PSS-05-05)
Transfer; (ESA PSS-05-06)
Operacin y Manutencin. (ESA PSS-05-07)

Documentos del nivel 3:

El nivel 3 tiene definiciones para codificacin
en Fortran (ESA PSS-05-05-01); codificacin
en ADA (ESA PSS-05-05-02); y codificacin en
C (ESA PSS-05-05-03).

Modelo del ciclo de vida del software

Modelo del ciclo de vida del software

Estndar E.S.A.
FASES
ITEMS
ACTIVIDADES
DESTACADAS

DOCUMENTOS
ENTREGABLES
La flecha indica
cambio de
mando

UR

SR

UR/R

USER
REQUIREMENT
DEFINITIONS

AD

SR/R

SOFTWARE
REQUIREMENT
DEFINITIONS

construccin del
modelo lgico

construccin del
modelo fsico

identificar
requerimientos de
usuarios

Identificar
requerimientos del
software

definicin de los
componentes
generales

Documento
Requerimientos
de usuario

Documento
Requerimientos
de software

Documento
de diseo
arquitectural

URD

SRD

DD/R

DETAILED
DESIGN AND
PRODUCTION

ARCHITECTURAL
DESIGN

determinar
ambiente
operacional

DD

AD/R

diseo de mdulos
cdigo
pruebas unitarias
pruebas de
integracin
pruebas del
sistema

TR
TRANSFER

instalacin

Test de
aceptacin final

Test de aceptacin
Operacin
provisorio
Manutencin del
cdigo y
documentos

Documento
del diseo
detallado

Documento de
Transferencia
del software

DDD
Cdigo
SUM

ADD

OM
OPERATIONS
AND
MAINTENANCE

Documento
historia del
proyecto

STD

PHD

Software User Manual

REVISIONES

HITOS
DESTACADOS

+.........+

+.........+

Revisiones
tcnicas

Recorrer las
inspecciones

Revisiones
tcnicas

Recorrer las
inspecciones

+.........+

Revisiones
tcnicas

Recorrer las
inspecciones

URD
Aprobado

SRD
Aprobado

ADD
Aprobado

+
Revisiones
tcnicas

cdigo/DDD/SUM
aprobado

STD
entregable

PHD
entregable

Aceptacin
provisional

Aceptacin
final

Estndar E.S.A.
Enfoque en Cascada
UR
SR
AD

El modelo en cascada es el ms simple de

ajustar al estndar E.S.A.
Las fases se ejecutan secuencialmente, como
muestran las flechas rojas.
Cada fase se ejecuta una vez, aunque la
iteracin de las fase permiten la correccin 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.

DD
TR
Fase

OM

Estndar E.S.A.
Enfoque a
entregas
incrementales

UR
SR

Las entregas incrementales se caracterizan por dividir las

fases DD, TR y OM en varias unidades ms manejables,
una vez que el plan arquitectnico completo est
definido.
El software se va entregando en mltiples versiones,
cada uno con incrementos funcionales y de capacidad.
Este enfoque puede ser beneficioso para proyectos
grandes dnde una sola entrega sera impracticable. Esto
puede ocurrir por varios razones como :
Que ciertas funciones necesiten estar antes para que
tras puedan ser efectivas;

AD
DD1

El tamao del equipo de desarrollo hace necesario

subdividir el proyecto en varios entregas;
El presupuesto de fondos est distribuido en un
nmero n de aos.

TR1

En todos los casos, cada entregable debe ser un

producto usable, y provea un subconjunto de las
capacidades requeridas.

OM

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

Estndar E.S.A.
Enfocado al desarrollo
Incremental
evolutivo

UR

SR

Para producir una nueva versin, todas las fases del ciclo de vida sern
ejecutadas.

AD

El enfoque incremental evolutivo se caracteriza por un desarrollo que

planifica liberar mltiples versiones.

Cada versin incorpora las experiencias de las versiones previas.

DD

El enfoque evolutivo puede usarse porque, por ejemplo:

TR

Algunos usuarios tienen poca experiencia y se exige refinar y

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.

OM

UR

SR

Las extensiones dibujadas muestra que el traslape de las fases puede

ocurrir hasta que cada nueva versin sea finalmente aceptada.

AD

DD

TR

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
o retrasos.

UR

SR

La desventaja de este enfoque evolutivo es que si los

requisitos estn muy incompletos al empezar, la estructura
inicial del software podra no soportar el peso de
evoluciones posteriores. Un costoso rediseo puede ser
necesario.

AD

DD

TR

Peor aun, las soluciones temporales pueden volverse

empotradas en el sistema y distorsionar su evolucin.

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
riesgo) y un plan adaptable (para asegurar posteriores
adaptaciones).

UR

SR

AD

En un desarrollo evolutivo, no es necesario llevar a cabo

todos los requisitos en cada ciclo de desarrollo. Sin
embargo, el plan arquitectnico debe considerar todos los
requisitos
conocidos.
2

DD

TR

OM