ESA PSS-05-0 Issue 2

February 1991

ESA
S O FT WAR E
ENGINEERING
S T AN DAR D S
ISSUE 2

Prepared by:
ESA Board for Software
Standardisation and Control
(BSSC)

Approved by:
The Inspector General, ESA

European Space Agency/ Agence spatiale europeenne

8-10, rue Mario-Nikis, 75738 PARIS CEDEX, France

PRLOGO..............................................................................................................................5
1 PROPSITO DE LAS NORMAS............................................................................................6
2 ESTRUCTURA DE LAS NORMAS........................................................................................6
3 CLASES DE PRCTICAS NORMALES (de norma)............................................................6
3.1 prcticas obligatorias..............................................................................................................................6
3.2 prcticas recomendadas..........................................................................................................................7
3.3 pauta prctica..........................................................................................................................................7

4 APLICANDO LAS NORMAS..................................................................................................7

4.1 factores aplicados a las Normas.............................................................................................................7
4.2 Aplicar el Estandar en un desarrollo de sistema.....................................................................................8
4.3 mtodos y herramientas..........................................................................................................................8

PARTE 1 NORMAS DEL PRODUCTO...............................................................................9

CAPTULO 1: EL CICLO DE VIDA DE SOFTWARE............................................................9
1.1 INTRODUCCIN..................................................................................................................................9
1.2 FASES, ACTIVIDADES E HITOS........................................................................................................9
1.3 ACERCAMIENTOS DE CICLO DE VIDA........................................................................................13
1.4 PROTOTIPADO...................................................................................................................................14
1.5 CAMBIO DE REQUISITOS DE MANEJO........................................................................................15

CAPITULO 2: FASE DE DEFINICION DE REQUERIMIENTOS DEL USUARIO..........16

2.1)
INTRODUCCION......................................................................................................................16
2.2) ENTRADAS DE LA ETAPA..........................................................................................................16
2.3) ACTIVIDADES..............................................................................................................................16
2.4 SALIDAS DE LAS FASES..................................................................................................................18

CAPITULO 3: FASE DE DEFINICION DE REQUERIMIENTOS DE SOFTWARE.........19

3.1) INTRODUCCION..............................................................................................................................19
3.2) ENTRADAS A LA FASE...................................................................................................................20
3.4 SALIDAS DE LA FASE......................................................................................................................25

Capitulo 4 :LA FASE DEL DISEO ARQUITECTNICO...................................................26

4.1 INTRODUCCIN................................................................................................................................26
4.2 Entradas a la fase..................................................................................................................................26
4.3 actividades............................................................................................................................................27
4.4 SALIDA DE CADA FASE..................................................................................................................31
4.4.2
Planes de Prueba de Integracin.................................................................................................31

CAPTULO 5: PLAN DETALLADO Y FASE DE LA PRODUCCIN.................................33

5.1 INTRODUCCION................................................................................................................................33
5.2 ENTRADAS A LA FASE.....................................................................................................................33
5.3 ACTIVIDADES...................................................................................................................................33
5.4 SALIDAS A PARTIR DE LA FASE....................................................................................................37

CAPTULO 6: LA FASE DEL TRASLADO...........................................................................39

6.1 INTRODUCCIN................................................................................................................................39
6.2 ENTRADAS A LA FASE.....................................................................................................................39
6.3 ACTIVIDADES...................................................................................................................................40
6.4 SALIDAS DE LA FASE......................................................................................................................41

CAPTULO 7: LAS OPERACIONES Y LA FASE DEL MANTENIMIENTO.....................42

7,1 INTRODUCCIN................................................................................................................................42
7,2 ENTRADAS A LA FASE.....................................................................................................................42
7,3 ACTIVIDADES...................................................................................................................................43

7,3,1 Aprobacin Final................................................................................................................43

7.4 RENDIMIENTO DE LA FASE...........................................................................................................44

PARTE 2: PROCEDIMIENTO ESTANDAR.....................................................................46

CAPTULO 1: LA DIRECCIN DEL CICLO DE VIDA DE SOFTWARE.........................47
1.1 INTRODUCCIN................................................................................................................................47
1.2 DIRECCIN DE PROYECTO DE SOFTWARE................................................................................47
1.3 DIRECCIN DE CONFIGURACIN DE SOFTWARE...................................................................47
1.4 COMPROBACIN DEL SOFTWARE Y APROBACIN.................................................................48
1.5 CONVICCIN DE CALIDAD DE SOFTWARE...............................................................................48

CAPTULO 2: LA DIRECCIN DE PROYECTO DE SOFTWARE....................................48

2.1 INTRODUCCIN................................................................................................................................48
2.2 ACTIVIDADES...................................................................................................................................49
2.3
EL PLAN GERENCIAL DE PROYECTO DE SOFTWARE.......................................................51
2.3 EVOLUCIN DEL SPMP A TRAVS DEL CICLO DE VIDA....................................................51
2.4.2 Fase SR...........................................................................................................................................51
2.4.3 Fase AD..........................................................................................................................................52
2.4.4 Fase DD..........................................................................................................................................52

CAPTULO 3 ADMINISTRACIN DE LA CONFIGURACIN DEL SOFTWARE.........53

3.1 INTRODUCCIN................................................................................................................................53
3.2 ACTIVIDADES...................................................................................................................................53
3.3 Planificacin de la configuracin del software....................................................................................58
3.4
EVOLUCION DEL SCMP A LO LARGO DEL CICLO DE VIDA.............................................59
3.4.1 Fase UR........................................................................................................................................59
3.4.2 Fase SR...........................................................................................................................................59
3.4.3 Fase AD.........................................................................................................................................59
3.4.4 DD phase.......................................................................................................................................59

CAPTULO 4: Validacin y verificacin del software.............................................................60

4.1 INTRODUCCIN................................................................................................................................60
4.2 ACTIVIDADES...................................................................................................................................60
4.3 LA COMPROBACIN DEL SOFTWARE Y PLAN DE VALIDACION..........................................64
4.4 EVOLUCIN DEL SVVP A LO LARGO DEL CICLO DE VIDA....................................................64

CAPTULO 5: LA CONVICCIN DE CALIDAD DE SOFTWARE...................................66

5.1 INTRODUCCIN................................................................................................................................66
5.2 ACTIVIDADES...................................................................................................................................66
5.3 EL PLAN DE LA GARANTA DE CALIDAD DEL SOFTWARE....................................................68
5.4 EVOLUCIN DEL SQAP A TRAVS DEL CICLO VITAL.............................................................68

P a r t e 3 A p e n d i c e s..................................................................................................69
APNDICE A: GLOSARIO......................................................................................................69
A.1
LISTA DE TERMINOLOGIA....................................................................................................69
A.2 LIST DE SIGLAS................................................................................................................................73

APNDICE B DOCUMENTOS DE PROYECTO DE SOFTWARE...................................74

APNDICE C PLANTILLAS de DOCUMENTOS..............................................................76
El APNDICE C.1 Contenido de URD.....................................................................................................76
El APNDICE C.2 Contenido de SRD......................................................................................................76
El APNDICE C.3 Contenido de ADD.....................................................................................................77
El APNDICE C.4 Contenido del DDD....................................................................................................78
El APNDICE C.5 SUM la Tabla de volmenes.......................................................................................78
APNDICE C.6 STD Tabla de Contenidos..............................................................................................79
APNDICE C.7 PHD Tabla de Contenidos...............................................................................................80
APNDICE C.8 SPMP Tabla de Contenidos.............................................................................................80

APENDICE C.9 tabla de contenidos SCMP.............................................................................................81

APENDICE C.10 la tabla de contenidos SVVP.........................................................................................82
APNDICE C.11 SQAP tabla de contenidos.............................................................................................84

APNDICE D: RESUMEN DE LAS PRCTICAS OBLIGATORIAS.................................85

APNDICE D.1: CICLO DE VIDA DEL SOFTWARE............................................................................85
APNDICE D.2: FASE UR.......................................................................................................................85
EL APNDICE LA D.3 SR FASE.............................................................................................................87
EL APNDICE D.4
AD FASE............................................................................................................87
EL APNDICE D.5
DD fase................................................................................................................89
EL APNDICE LA D.6 TR FASE............................................................................................................90
EL APNDICE LA D.7 OM FASE...........................................................................................................90
EL APNDICE LA D.8 LA DIRECCIN DE PROYECTO DE SOFTWARE.......................................91
EL APNDICE D.9 LA DIRECCIN DE CONFIGURACIN DE SOFTWARE.................................92
APNDICE D.10 LA COMPROBACIN DEL SOFTWARE Y VALIDACION....................................94
APNDICE D.11 ASEGURAMIENTO DE LA CALIDAD DEL SOFTWARE......................................95

EL APNDICE E LAS FORMAS DE PLANTILLAS..........................................................96

PRLOGO
La Ingeniera de Software es una disciplina en evolucin, y muchos de sus cambios han ocurrido en el
campo desde el ltimo problema de las Normas de Ingeniera de Software ESA PSS-05-0 en enero de 1987.
Por consiguiente, la BSSC empez un programa de actualizacin de las Normas en 1989. Se pidi la opinin
a los usuarios de las Normas, los mtodos de Ingeniera de Software fueron revisados, y recientemente las
normas fueron revisadas por otras organizaciones.
Estamos esperando a Yannis (el espaol...aun no llega)
En 1989, la BSSC llam a los usuarios de las normas para proponer propuestas de cambio. Se
recibieron casi 200 propuestas y muchos de los puntos que ah haba, han sido incorporados en esta nueva
publicacin de las Normas.
La BSSC ha comenzado el desarrollo de documentacin de bajo nivel, llamadas GUIAS, las cuales
describirn en detalle cmo implementar las prcticas descritas en las Normas. Las Guas tambin hablarn de
los mtodos de ingeniera de software. El trabajo de desarrollo en las guas ha requerido una revisin
cuidadosa de las normas, y se han encontrado algunos cambios necesarios en ellas.
La ltima publicacin de las Normas tom en cuenta las Normas de Ingeniera de Software publicadas
por el Instituto de Ingenieros Elctricos y Electrnicos (IEEE). La mayora de las Normas son reconocidas por
el Instituto Nacional Americano de Normas (ANSI). Esta publicacin toma en cuenta varias de las nuevas
Normas que ha publicado la IEEE desde la ltima publicacin.
Los siguientes miembros de BSSC han contribuido a la realizacin de esta publicacin: Carlo Mazza
(presidente), Bryan Melton, Daniel De Pablo, Adriaan Scheffer y Richard Stevens.
La BSSC desea agradecer a Jon Fairclough su ayuda en el desarrollo de los estndares y las Guas. La
BSSC expresa su gratitud a todos aquellos ingenieros de software en ESA y en la Industria, quienes han
contribuido a la mejora de las Normas.
Solicitudes de aclaraciones, propuestas de cambio o cualquier otro comentario relacionados con estas
Normas deben dirigirse a:

BSSC/ESOC Secretariat
Sr C Mazza
ESOC
Robert-Bosch-Strasse 5
D-6100 Darmstadt
Alemania

BSSC/ESTEC Secretariat
Sr A Scheffer
ESTEC
Postbus 299
NL-2200 AG Noordwijk
Holanda

_____________________________________ 5 y 6 ______________________________________________

INTRODUCCIN

1 PROPSITO DE LAS NORMAS

Este documento describe normas de ingeniera de software que se aplican a todos los software que
son implementados por la Agencia Espacial Europea (ESA), en la casa o por la industria.
El software esta definido en estas Normas como programas, procedimientos, reglas y toda la
documentacin asociada que pertenecen al funcionamiento de un sistema computarizado. Estas Normas se
preocupan por todos los aspectos del software de un sistema, incluyendo sus interfaces con el hardware del
computador con otros componentes del sistema.
El software puede ser un subsistema de un sistema ms complejo o puede ser un sistema
independiente.
Donde ESA PSS-01-serie documentos son aplicables, y como una consecuencia ESA PSS-01-21,
Software Product Assurance Requirements for ESA space Systems tambin es aplicable, Parte 2, Captulo
5 de estas Normas, seguridad de la Calidad del Software', deja de aplicar.

2 ESTRUCTURA DE LAS NORMAS

Las normas ESA de ingeniera de software estn divididas en tres partes:
Parte 1, Normas del producto, contiene normas, recomendaciones y pautas acerca del producto, es decir, el
software va a ser definido, implementado, operado y mantenido.
Parte 2, Normas de procedimientos, describe los procedimientos que se usan para manejar un proyecto de
software.
Parte 3, Apendices, contiene los resmenes, tablas, formularios y listas de control de las prcticas
obligatorias.

3 CLASES DE PRCTICAS NORMALES (de norma)

Se usan tres categoras de prcticas estndares en las normas ESA de ingeniera de software: las
prcticas obligatorias, prcticas recomendadas y pautas.

3.1 prcticas obligatorias

Frases que contienen la palabra `Shall ' son prcticas obligatorias. Estas prcticas deben seguirse,
sin la excepcin, en todos los proyectos del software. La palabra `Must ' se usa en declaraciones que repiten
una prctica obligatoria.

3.2 prcticas recomendadas

Frases que contienen la palabra `Should ' son prcticas fuertemente recomendadas. Una
justificacin al nivel apropiado en la jerarqua de la Agencia se necesita si ellas no se siguen.

3.3 pauta prctica

Frases que contienen la palabra `May ' son pautas. Ninguna justificacin se requiere si ellas no se
siguen.

4 APLICANDO LAS NORMAS

Los proyectos del software varan ampliamente en el propsito, tamao, complejidad y
disponibilidad de recursos. La direccin de proyecto de software debe definir cmo las Normas sern
aplicadas en los documentos de la planificacin (vea Parte 2). Decidiendo cmo las normas sern aplicadas en
los proyectos especficos esto es llamado a menudo adaptacin.

4.1 factores aplicados a las Normas

Varios factores pueden influenciar cmo las Normas son aplicadas, por ejemplo :

El costo del proyecto, ambos en el desarrollo y funcionamiento,;

El nmero de las personas requeridas para desarrollar, operar y mantener el software;
El nmero de usuarios potenciales del software;
La cantidad del software que tiene que ser producido;
El criticidad del software, es medido por las consecuencias de su fracaso;
La complejidad del software, es medido por el nmero de interfaces o una mtrica similar;
La integridad y estabilidad de los requerimientos del usuario;
Los valores de riesgo incluidos con los requerimientos del usuario.

Note que dos aos hombre o menos es un proyecto pequeo, veinte aos hombre o ms es un
proyecto grande.
La administracin de un proyecto de software debe definir un acercamiento al ciclo de vida y plan
de la documentacin que reflejan estos factores.
Para proyectos que usan cualquier software comercial se debe procurar que el software cumpla los
requisitos declarados. No se espera que en los proyectos se deban reproducirse planes y documentacin de
aplicaciones del software comercial. El mantenimiento de tal software es una responsabilidad del proveedor.
Pueden empotrarse los procedimientos para la produccin del software en la infraestructura del
ambiente activo; una vez que estos procedimientos se han establecido, la documentacin repetitiva de ellos es
innecesaria. En el funcionamiento de los grupos de proyectos deben asegurar que sus prcticas del
funcionamiento conforman las normas ESA de ingeniera de software. La documentacin del proyecto debe
referenciar stas prcticas.
Los proyectos de software grandes y complejos pueden necesitar extender estas normas. Los tales
proyectos pueden necesitar dar una consideracin ms detallada y considerar aspectos de ciclo de vida cuando
hay requerimientos cambiantes o los constructores (desarrolladores) mltiples trabajan en paralelo.

4.2 Aplicar el Estandar en un desarrollo de sistema

El software desarrollado para ESA frecuentemente es una parte de un sistema ms grande, como el
sistema de un satlite que es un ejemplo obvio. En esta situacin se habrn realizado ya varios actividades a
nivel de sistema (como la parte del ciclo vida del desarrollo de un sistema) antes del ciclo de vida para
cualquier parte del software del sistema que se puede comenzar.
Esto es una funcin de ingenieria de sistema para definir sobretodo los requisitos globales para el sistema a
ser construido, a menudo se expresa en un Documento de requerimiento de Sistema (a menudo llamado un
SRD, pero para no ser confundido con un Documento de Requerimiento de Software). De este documento de
requerimientos del sistema se obtiene una descomposicin en los subsistemas que se realiza a menudo las
especificaciones del subsistema resultantes. Comercio-offs (trade-offs?) se hace para dividir el
sistema/subsistema en el hardware y software, aplicando criterios especficos del sistema que va a ser
construido (por ejemplo la concordancia, la fiabilidad, criticidad, etc). Una vez que la necesidad del software
se ha establecido, su ciclo de vida, como se define en esta norma, comienza. Cada uno de los artculos del
software identificados en el sistema tendr su ciclo de vida individual.
Muchos de los requerimientos del usuario pueden existir correctamente en la documentacin del sistema.
Es una economa falsa para asumir la entrada de requerimientos al desarrollo del subsistema software. Para
asegurar alguna consistencia en la entrada a un proyecto del software, un Documento de Requerimientos de
Usuario (URD) siempre debe producirse (generarse). El URD es identificable al sistema y/o documentacin
del subsistema.
Deben estarse de acuerdo las responsabilidades para la produccin y mando de cambio del URD entre
`System ' y `Software ' la direccin del proyecto, y grab en el Software Proyecto Direccin Plan.

4.3 mtodos y herramientas

Estas normas no hacen el uso de cualquier mtodo de ingineering de software particular o herramienta
obligatorio. Las Normas describen las prcticas obligatorias, prcticas recomendadas y pautas para el
ngineering del software proyecta, y permite cada proyecto para decidir la manera mejor de mplementing ellos.
Las referencias a los mtodos y herramientas aparecen, sin embargo, en estas normas por dos razones.
Primeramente, la terminologa de los mtodos particulares se vuelve, con tiempo, parte de computar el
vocabulario. Secondly, los ejemplos de posibles maneras de llevar a cabo las Normas son tiles.

PARTE 1 NORMAS DEL PRODUCTO

CAPTULO 1: EL CICLO DE VIDA DE SOFTWARE

1.1 INTRODUCCIN
Este captulo define el ciclo de vida de software global. Se describen las fases individuales del ciclo de
vida en ms detalle en los captulos subsecuentes.
En estas Normas el trmino que el `Software desarrollo project' se usa a menudo. Claramente el desarrollo
de software tambin involucra el spects de hardware de computadora. Comercio-offs entre el hardware y
software es parte de disear un sistema del omputerised, excepto cuando la configuracin del hardware es el
predefined, y reprime el plan del software.

1.2 FASES, ACTIVIDADES E HITOS

El ciclo de vida de software empieza cuando un producto del software se concibe y acaba cuando es
ningn ms largo disponible para el uso, es decir contiene el todo del desarrollo, funcionamientos y
actividades de mantenimiento.
Se entregarn los productos de un proyecto de desarrollo de software de una manera oportuna y se
encajarn para su propsito. Se planearn las actividades de desarrollo de software sistemticamente y se
llevarn a cabo. Un `Life ciclo model' estructura las actividades del proyecto en `Phases ' y define qu
actividades ocurren en que la fase. Figure 1.2 muestras que el modelo de ycle de vida us en estas Normas.
Un `Life ciclo approach' es una combinacin de las fases bsicas del modelo de ciclo de vida. Seccin
1.3 describe tres posible ciclo de vida se acerca que cubre la mayora de las necesidades de la Agencia.
Todos los proyectos del software tendrn un acercamiento de ciclo de vida que incluye las fases
bsicas mostrado en Figura 1.2:
UR escalonan - la Definicin de los requisitos del usuario
SR escalonan - la Definicin de los requisitos del software
DC la fase - la Definicin del plan arquitectnico
DD escalonan - Detall el plan y produccin del cdigo
TR escalonan - Transfiera del software a los funcionamientos
OM escalonan - los Funcionamientos y mantenimiento

____________________________________9 y 10 ______________________________________________

Figura 1.2: MODELO DEL CICLO DE VIDA DEL SOFTWARE

El fin de las primeras 4 fases se hace con una revisin, denot por ' /R ' (por ejemplo UR/R es la
Revisin de Requisitos de Usuario). Estas fases deben ocurrir cualquiera sea el tamao, la aplicacin (por
ejemplo cientfico, administrativo, real, lote), el hardware, el sistema operativo o el lenguaje de programacin
usado, o si el proyecto se lleva a cabo por el personal interno o por la industria. Cada uno de estos factores,
sin embargo, las influencias al acercamiento del desarrollo, y el estilo y contenido de los itemes entregados.
En Figura 1.2 las lineas negras gruesas marcan el lmite del ciclo de vida de software. Esto empieza
con la entrega del Documento de Requisitos de Usuario (URD) al diseador para la revisin. El UR/R es la
primera actividad del ciclo de vida de software. Siguiendo la aprobacin del URD, las tres fases de desarrollo
deben tener lugar antes que el software se transfiera a los usuarios para su funcionamiento. Las entregas de
cada fase deben ser revisadas y deben aprobarse antes de proceder a la prxima. Despus de un periodo de
funcionamientos, el software es retirado. Este evento marca el fin del ciclo de vida de software.
Hay seis hitos mayores que marcan el progreso para el ciclo de vida de software. Estos hitos,
mostrados en Figura 1.2 como los tringulos llenos, son la:
" aprobacin del Documento de Requisitos de Usuario (URD);
" aprobacin del Documento de Requisitos de Software (SRD);
" aprobacin del Documento del Plan Arquitectnico (ADD);
" aprobacin del Documento del Plan Detallado (DDD), el Manual de Usuario de Software (SUM), el cdigo,
y la declaracin de prontitud para la prueba de aceptacin provisional;
" declaracin de aceptacin provisional y la entrega del Documento de Traslado de Software (STD);
" declaracin de la aceptacin final y la entrega del Documento de Historia de Proyecto (PHD).
El ltimo hito no se cae al final de una fase, pero al final del periodo de la garanta.

Estos hitos se han seleccionado como el requisito mnimo para una relacin contractual laborable.
Ellos deben estar presentes en todos los proyectos. En los proyectos largos, deben agregarse los hitos
adicionales para medir el progreso de entregas.
1.2.1 fase de UR: la definicin de requisitos de usuario
La fase de UR es la fase de definicin del problema de un proyecto de software. El alcance del
sistema debe definirse. Los requisitos del usuario deben capturarse. Esto puede hacerse por la entrevista o
puede inspeccionarse, o construyendo los prototipos. Deben identificarse los requisitos del usuario
especficos y deben documentarse en el Documento de Requisitos de Usuario (URD).
La complicacin de los diseadores en esta fase vara segn la familiaridad de los usuarios con el
software. Algunos usuarios pueden producir una calidad alta URD, mientras otros pueden necesitar la ayuda
de los diseadores.
El URD siempre debe producirse. La revisin del URD se hace por los usuarios, ingenieros de
software y hardware y los gerentes involucrados. El URD aceptado es la entrada a la fase de SR.
Antes de la realizacin de la Revisin de Requisitos de Usuario (UR/R), un Plan de Administracin
de un proyecto de software que perfila el proyecto entero debe producirse por el diseador. Este plan debe
contener una estimacin del costo para el proyecto. Tambin deben producirse planes detallados para la fase
de SR.
1.2.2 fase de SR: la definicin de requisitos de software
La fase de SR es la fase de Anlisis de un proyecto de software. Una parte vital de la actividad
del anlisis es la construccin de un `Modelo ' describiendo que tiene que hacer el softwaree, y no como
tiene que hacerlo. Los prototipos construidos para clarificar los requisitos del software pueden ser
necesarios.
La principal entrega de esta fase es el Documento de Requisitos de Software (SRD). El SRD
siempre debe producirse para cada proyecto del software. La terminologa de aplicacin debe omitirse del
SRD. El SRD debe repasarse formalmente por los usuarios, por los ingenieros de software y hardware, y por
los gerentes involucrados, durante la Revisin de Requisitos de Software (SR/R).
Durante la fase de SR, la seccin del Plan de Administracin del Proyecto de Software que perfila
el resto del proyecto debe ser actualizado. El plan debe contener una estimacin del costo del proyecto total,
y deben hacerse los mejores esfuerzos para lograr una exactitud de por lo menos 30%. Detallar los planes para
la fase del AD tambin debe producirse.
1.2.3 Fase AD: el diseo arquitectnico
El propsito de la fase del AD es definir la estructura del software. El modelo construido en la fase
de SR es el punto de arranque.
Este modelo se transforma en el plan arquitectnico asignando las funciones a los componentes del
software y definiendo el mando y los datos fluyen entre ellos.
Esta fase puede involucrar varias iteraciones del plan. Tcnicamente las partes difciles o crticas
del plan tienen que ser identificadas. El prototipado de estas partes del software puede ser necesario para
confirmar los asuntos del plan bsicos. Pueden proponerse los planes alternativos uno de los cuales debe
seleccionarse.

El artculo entregable que constituye el rendimiento formal de esta fase es el Documento del Plan
Arquitectnico (ADD). El ADD siempre debe producirse para cada proyecto del software. El ADD debe
repasarse formalmente por el hardware de la computadora y ingenieros de software, por los usuarios, y por la
direccin involucrada, durante la Revisin del Plan Arquitectnica (AD/R).
_________________________________________13 y 14________________________________________
1.2.4 fase de DD: el plan detallado y produccin
El propsito de la fase de DD es detallar el plan del software, al cdigo, documento y prueba de l.
El Documento del diseo Detallado (DDD) y el Manual de Usuario de Software (SUM) se produce
concurrentemente con codificar y probar. Inicialmente, el DDD y SUM contienen las secciones que
corresponden a los niveles mas altos del sistema. Para bajar los niveles, se agregan las subdivisiones
relacionadas como los progresos del plan. Al final de la fase los documentos se completan y con el cdigo,
constituyen los artculos entregables de esta fase.
Durante esta fase, unidad, integracin y actividades de testeo del sistema son realizadas segn los
planes de la comprobacin establecidos en los SR y fases del ANUNCIO. As como estas pruebas, aqu tiene
que ser verificada la calidad del software.
Los tres artculos entregables (el Cdigo, DDD, SUM), qu ya ha sido el asunto de revisiones del
intermedio durante la fase DD, debe ser revisado formalmente por los ingenieros del software y la direccin
involucrada, durante la Revisin del Plan Detallado (DD/R). al final del proceso de la revisin, el software
puede declararse listo para la comprobacin de aceptacin provisional.
1.2.5 fase de TR: el traslado
El propsito de esta fase es establecer que el software cumple los requisitos extendidos en el URD.
Esto se hace instalando el software y dirigiendo las pruebas de aceptacin.
Cuando el software ha demostrado que provee las capacidades requeridas, el software puede ser
provisionalmente aceptado y puede comenzar a funcionar.
El Documento de Traslado de Software (STD) debe producirse durante la fase de TR para
documentar el traslado del software al equipo en funcionamiento.
1.2.6 fase de OM: los funcionamientos y mantenimiento
Una vez el software ha entrado en funcionamiento, debe supervisarse para confirmar
cuidadosamente que rene todos los requisitos definidos en el URD. Algunos de los requisitos, por ejemplo
aqullos para la disponibilidad, pueden tomar un periodo de tiempo para ser validados. Cuando el software ha
pasado todas las pruebas de aceptacin, puede aceptarse finalmente.
La documentacin de la Historia del Proyecto (PHD) resume la informacin de manejo significante
acumulada en el curso del proyecto. Este documento debe emitirse despus de la ltima aceptacin. Debe
reeditarse al final del ciclo de vida, con informacin recaudada la fase de OM.
Despus de la ltima aceptacin, el software puede modificarse para corregir los errores no
detectados durante las fases anteriores, o porque aparecen nuevos requerimientos. Esto se llama
`Mantenimiento '.
Para el periodo entero de funcionamiento, debe prestarse la atencin particular a guardar la
documentacin actualizada. Debe grabarse informacin sobre las faltas y fracasos para mantener los datos

crudos para el establecimiento de mtricas de calidad de software para los proyectos subsecuentes. Deben
usarse las herramientas para facilitar la coleccin y anlisis de datos de calidad.

1.3 ACERCAMIENTOS DE CICLO DE VIDA

El software modelo de ciclo de vida, mostrado en Figura 1.2, resume las fases y actividades que
deben ocurrir en cualquier proyecto del software. Un acercamiento de ciclo de vida, basado en este modelo,
debe definirse, para cada proyecto, en el Software Plan de Direccin de Proyecto.
Esta seccin se definen tres acercamientos que cubren la mayora de las necesidades de la Agencia.
En los diagramas, se han reducido las fases de la Figura 1.2 a las cajas. Las flechas que conectan las cajas
representan las transiciones permitidas.
1.3.1 El acercamiento de la cascada

Figure 1.3.1: El acercamiento de la cascada

El enfoque Cascada, mostrado en Figura 1.3.1, es la interpretacin ms simple del modelo mostrada en Figura
1.2. Las fases se ejecutan secuencialmente, como lo muestran las flechas pesadas. Cada fase se ejecuta una
vez, aunque la iteracin de parte de una fase permite la correccin del error, como lo mostrado por las flechas
punteadas. La entrega del sistema completo ocurre a un solo hito al final de la fase de TR. El acercamiento
permite la relacin contractual para ser simple.
1.3.2 el acercamiento de la entrega incremental

Figure 1.3.2: El acercamiento de la entrega incremental

El acercamiento de la entrega incremental, mostrado en la Figura 1.3.2, se caracteriza hendindose el DD,
TR y OM se escalona en un numero de unidades ms manejables, una vez que el plan arquitectnico se ha
definido por completo. El software se entrega en los descargos mltiples, cada uno con la funcionalidad y
capacidad aumentada. Este acercamiento es beneficioso para proyectos grandes dnde una sola entrega no
sera prctica. Esto puede ocurrir por varias razones como:
" ciertas funciones pueden necesitar estar en el lugar antes que otras para ser eficaz;
" el tamao del equipo de desarrollo puede hacer necesario una subdivisin del proyecto en varias entregas;
" las consideraciones del presupuesto pueden solo permitir un solo fondo parcial sobre un numero de aos.
En todos los casos, cada entrega debe ser utilizable, y proporcionar un subconjunto de las
capacidades requeridas.

Una desventaja del acercamiento de la entrega incremental son las pruebas requeridas de regresin
que se exigen para confirmar que las capacidades existentes del software no se daen por cualquier nueva
versin. El incremento de la cantidad de pruebas requeridas aumenta el costo del software.
__________________________________________13 y 14________________________________________
1.3.3 el acercamiento de desarrollo evolutivo
Figure 1.3.3: El acercamiento de desarrollo evolutivo
(Disponible slo en la copia dura)
El acercamiento evolutivo , mostrado en Figura 1.3.3, se caracteriza por el desarrollo planeado de
descargos mltiples. Cada Fase del ciclo de vida se ejecuta para producir un descargo. Cada descargo
incorpora la experiencia de descargos ya realizados. El acercamiento evolutivo puede usarse porque, por
ejemplo:
" un poco de experiencia del usuario se exige para refinar y completar los requisitos (mostrado por la lnea
golpeada dentro del caja OM);
" algunas partes de la aplicacin pueden depender de la disponibilidad de tecnologa futura;
" algunos nuevos requisitos del usuario se anticipan pero no todava se conocen;
" algunos requisitos pueden ser significativamente ms difciles encontrarse que otros, y se decide no
permitirles tardar una entrega utilizable.
Las extensiones golpeadas a las cajas en la Figura 1.3.3 muestra que algunos solapan de fases de
OM ocurrir hasta que cada nueva entrega se acepte finalmente.

En un desarrollo evolutivo, el diseador debe reconocer las prioridades del usuario y debe producir
las partes del software que es ambos importante al usuario y, posible desarrollar con problemas tcnicos
mnimos o retrasos.
La desventaja del acercamiento evolutivo es que si los requisitos estn muy incompletos empezar
con, la estructura del software inicial no puede llevar el peso de evolucin ms tarde. Lo caro de volver a
escribir puede ser necesario. Incluso aun ms, soluciones temporales en el sistema pueden torcer su evolucin.
Ms all, los usuarios pueden ponerse impacientes con los problemas de denticin de cada nueva versin. Por
cada ciclo de desarrollo, es importante su objetivo para una declaracin completa de requisitos (para reducir el
riesgo) y un plan adaptable (para asegurar el la capacidad de modificacin ms tarde). En un desarrollo
evolutivo, todos los requisitos no necesitan ser llevados a cabo totalmente por cada ciclo de desarrollo. Sin
embargo, el plan arquitectnico debe tomar cuenta de todos los requisitos conocidos.

1.4 PROTOTIPADO
El uso de prototipos para probar la reaccin del cliente y las ideas del plan son comunes en muchas
disciplinas de la ingeniera. Los instrumentos de prototipo de software seleccionaron aspectos de software
propuesto para que las pruebas, el tipo ms directo de comprobacin, puedan llevarse a cabo.
Prototipado es el proceso de construir los prototipos. Prototipado dentro de una sola fase es un
medios tiles de reducir el riesgo en un proyecto a travs de la experiencia prctica. El rendimiento de un
ejercicio del prototipado es el conocimiento que se gana de llevar a cabo o usar el software del prototipo.

El objetivo de la actividad del prototipado debe declararse claramente antes de las salidas del
proceso. En el Prototipado para definir los requisitos se llama el prototipazo `Explorativo ', mientras que por
investigar la viabilidad de soluciones propuestas se llama prototipazo `Experimental.
Los prototipos normalmente implementan alto riesgo, actuacin o requisitos de interfaz de usuario
y normalmente ignora calidad, fiabilidad, mantencin y requisitos de seguridad. El software del prototipo es
por consiguiente `Pre-operacional ' y nunca debe entregarse como la parte de un sistema operacional.

1.5 CAMBIO DE REQUISITOS DE MANEJO

El URD y SRD deben ser documentos completos. Esto significa que todos los requisitos conocidos
deben ser incluidos cuando ellos se producen.
No obstante, es posible que que los nuevos requisitos pueden conocerse despus del URD y SRD
hayan sido aceptados. Deben establecerse procedimientos por ocuparse de nuevos requisitos al principio del
proyecto.
La integridad del plan no debe componerse cuando los nuevos requisitos estn incorporados. Los
tales requisitos, aceptados por usuario y el diseador, deben manejarse de la misma manera como los
requisitos originales. El procedimiento por ocuparse de un nuevo requisito del usuario es por consiguiente a:

Genere un nuevo proyecto del URD,

Realize una revisin de UR y, si el cambio se acepta, entonces

Repita el SR, AD y DD escalona para incorporar el nuevo requisito y sus consecuencias.

De un nuevo requisito del software se ocupa de una manera similar.

Un mtodo alternativo por ocuparse de nuevos requisitos es instituir una Tabla de Revisin de
Software despus del UR/R en lugar de despus del DD/R. Otro mtodo es usar el desarrollo vida ciclo
acercamiento evolutivo. Sin embargo, esto difiere el manejo de nuevos requisitos meramente al siguiente
descargo, el que est en la preparacin, y esto no puede ser suficiente.
La calidad del trabajo hecha en los UR y fases de SR puede ser medida por el nmero de requisitos
que aparecen en las fases ms tarde.
Especialmente importante es la tendencia en la ocurrencia de nuevos requisitos. Una tendencia
ascendente es una seal segura que el software es improbable de tener xito.
La disponibilidad de software que disea las herramientas puede ser crtica al xito de un proyecto
con requisitos cambiantes frecuentemente.
En proyectos dnde los requisitos son convenidos y parados al final de la fase de SR, el uso de
mtodos basado en el papel para el anlisis de requisitos y especificacin del plan puede ser suficiente.
En proyectos dnde la congelacin de requisitos no es posible, hay software que disea herramientas
que permiten asimilar los nuevos requisitos y cambios del plan rpidamente puede ser esencial evitar los
retrasos
______________________________15 y 16 __________________________________________

CAPITULO 2: FASE DE DEFINICION DE REQUERIMIENTOS DEL

USUARIO

2.1)

INTRODUCCION

La fase UR puede ser llamada fase de definicin del problema del ciclo de vida. El propsito de
esta fase es refinar una idea acerca de la tarea a realizar, usando equipamiento computacional, dentro de la
definicin de lo que se espera del sistema computacional o de informacin.
La definicin de requerimientos del usuario ser de responsabilidad del usuario. La experiencia de
los ingenieros de software, ingenieros de hardware y personal operativo deber ser usada para ayudar y
revisar los requerimientos del usuario. Una salida de la fase UR es un documento de los requerimientos del
usuario o consumidor (URD). Este es un documento crtico para el proyecto completo, porque define la base
sobre la cual se acepta el software. La fase UR termina con la aprobacin formal del URD (documento de los
requerimientos del usuario), con la revisin de estas exigencias del consumidor o requerimientos del usuario
(UR/R).

2.2)

ENTRADAS DE LA ETAPA

No se requiere ninguna entrada formal, aunque los resultados de entrevistas, de exmenes, de

estudios y prototipos de actividades son a menudo provechosos para formular los requerimientos del usuario.

2.3)

ACTIVIDADES

La actividad principal de la fase de UR es capturar los requerimientos del usuario y documentarlos

en el URD (Documento de Requerimientos de Usuario). El alcance del software tiene que ser establecido y
las interfaces con los sistemas externos ser identificadas.
Los planes de las actividades de la fase SR se deben elaborar en la fase de UR. Estos planes deben
cubrir la gestin del proyecto, la gestin de configuracin, la verificacin, la validacin y la garanta de
calidad. Estas actividades se describen ms detalladamente en la parte 2.

2.3.1) Captura De Requerimientos Del Usuario

Mientras que los requerimientos del usuario se originan con la opinin espontnea de necesidades,
stos se deben clarificar con la crtica y la experiencia del software y de los prototipos existentes.
El acuerdo posible ms amplio sobre los requerimientos del usuario se debe establecer con
entrevistas y exmenes. El conocimiento y la experiencia de las organizaciones potenciales del desarrollo se
deben utilizar para aconsejar sobre viabilidad de la puesta en prctica, y, quizs, para construir prototipos. La
definicin de las exigencias del consumidor es un proceso iterativo, y las actividades de la captura de los
requisitos pueden tener que ser repetido un nmero de veces antes de que el URD sea listo para la revisin.

2.3.2) Determinacion Del Ambiente Operacional

La determinacin del ambiente operacional debe ser el primer paso en la definicin de los
requerimientos del usuario. Una cuenta clara se debe desarrollar en el mundo real donde el software va
funcionar. Esta descripcin narrativa se puede apoyar por los diagramas de contexto, para resumir las
interfaces con los sistemas externos (a menudo llamadas interfaces externas) y diagramas de bloque del
sistema para mostrar el rol del software en un sistema ms grande.
La naturaleza de intercambios con sistemas externos se debe especificar y controlar al comienzo del
proyecto. La informacin puede residir en un documento de control de interfaz (ICD), o en la documentacin
del diseo del sistema externo. Si ya existe el sistema externo, entonces los intercambios se pueden definir ya
en un cierto detalle, y obligan al diseo. Alternativamente, la definicin de las interfaces externas puede
desarrollarse a travs de las fases de UR, del SR y del AD.

2.3.3) Especificacion De Requerimientos Del Usuario

Cuando se ha establecido el ambiente operacional, se extraen y se organizan los requerimientos del
usuario especficos. Se omiten las consideraciones de la puesta en prctica, a menos que sean la esencia del
requisito.

2.3.3.1) Clasificacin de requerimientos del usuario

Los requerimientos del usuario caen en dos categoras:
Las capacidades necesitadas por los usuarios para solucionar un problema o alcanzar un objetivo;
Restricciones puestas por los usuarios acerca de cmo el problema debe ser resuelto o qu objetivo
debe ser alcanzado.
Los requisitos de la capacidad describen las funciones y las operaciones necesitadas por los usuarios.
Las declaraciones cuantitativas que especifican cualidades del funcionamiento y de la exactitud, deben formar
parte de la especificacin de una capacidad.
Las dimensiones del espacio y del tiempo pueden ser tiles para organizar requisitos de la capacidad.
Es a menudo conveniente describir requisitos de la capacidad en trminos de una secuencia de operaciones.
Las limitaciones de los requerimientos ponen restricciones en cmo el software puede ser construido
y cmo debe operar. Por ejemplo, las definiciones de las interfaces externas de las comunicaciones, del
hardware y de software pueden ya existir, porque el software es parte de un sistema ms grande, o porque el
usuario requiere que ciertos protocolos, estndares, computadores, sistemas operativos, libreras o ncleo del
software sea utilizado.
Los requisitos de la Interaccin Humano-Computador (HCI) variarn de acuerdo al tipo de software
del que se trate. Para sistemas interactivos, los usuarios pueden desear proporcionar los ejemplos del dilogo
que se requiere, incluyendo el hardware que se utilizar (el teclado, el mouse, la resolucin de color, etc) y la
ayuda proporcionada por el software (ayuda en lnea). Para los sistemas batch, puede ser suficiente indicar los
parmetros que necesitan ser variados, el medio de salida y el formato requerido.
Las restricciones del usuario con respecto al software incluyen atributos de calidad de adaptabilidad,
de disponibilidad, de portabilidad y de seguridad. El usuario describir las consecuencias de prdidas de
disponibilidad, o las brechas de seguridad, de modo que los desarrolladores puedan apreciar completamente
la criticidad de cada funcin.
El usuario puede elegir hacer estndares adicionales aplicables; tales requisitos son limitaciones
adicionales en el desarrollo.
_____________________________________ 17 y 18 ___________________________________________
2.3.3.2 Atributos del requerimiento del usuario
Cada requerimiento del usuario debe incluir el siguiente listado de atributos.

(a) El Identificador: cada requerimiento del usuario incluir un identificador, para facilitar el trazado a
travs de las fases subsecuentes.
(b) La Necesidad : se marcarn los requerimientos esenciales del usuario como tal. Los requerimientos
esenciales del usuario no son negociables; otros pueden ser sumamente menos importantes y sujeto a la
negociacin.
(c) La Prioridad: para la entrega incremental, cada requerimiento del usuario incluir una medida de
prioridad para que el diseador pueda decidir en que momento piroducir.
(d) La Estabilidad: algunos requerimientos del usuario pueden ser estables durante ciclo de vida del
software; otros pueden ser ms dependientes del feedback entre las etapas de SR, AD y DD o pueden estar
sujetos a cambios durante el ciclo de vida de software. Deben marcarse tales requerimientos como variables.
(e) La Fuente : la fuente de cada requerimiento del usuario se declarar. sta puede ser una referencia a
un documento externo (por ejemplo el documento de requerimientos del sistema) o al nombre del usuario, o a
un grupo de usuarios, o al usuario que proporcion el requerimiento.
(f) La Claridad: un requerimiento del usuario est claro si tiene una, y slo una interpretacin. La
claridad implica falta de ambigedad. Si un trmino se usa en un contexto particular y tiene mltiples
significados, el trmino debe aclararse o debe ser reemplazado por un trmino ms especfico.
(g) Verificabilidad: cada requerimiento del usuario ser comprobable. Esto significa que debe ser
posible :

Chequear que el requerimiento esta incorporado en el plan;

Demostrar que el software llevar a cabo el requerimiento;
Probar que el software llevar a cabo el requerimiento.

2.3.4 Revisiones
Se repasarn los rendimientos de la fase de UR formalmente durante la Revisin de
Requerimientos de Usuario (UR/R). sta debe ser una revisin tcnica (vea Parte 2, Captulo 4). Los
participantes deben incluir a los usuarios, operadores, desarrolladores (ingenieros de hardware y software) y
los gerentes involucrados.
Los requerimientos del usuario que se rechazan en el proceso de la revisin no tienen que ser
sacados del URD, sobre todo si se piensa que los recursos pueden estar disponibles en alguna fecha ms tarde
para llevarlos a cabo.
Se marcarn claramente en el URD los requerimientos del usuario como no aplicables.

2.4 SALIDAS DE LAS FASES

Las salidas principales de la fase son los URD y los planes para la fase de SR.
2.4.1 Documento de Requerimientos del usuario
Una salida de la fase de UR ser el Documento de Requerimientos del Usuario (URD). El URD
siempre se producir antes de que un proyecto del software comience. El contenido de la tabla recomendado
para el URD se proporciona en el Apndice C.

El URD proporcionar una descripcin general de lo que espera el usuario que el software haga.
Todos los requerimientos del usuario conocidos sern incluidos en el URD. El URD debe declarar los
requerimientos especficos del usuario tan claramente como sea posible y de forma consistente.
El URD describir las funciones que el usuario quiere realizar con el sistema del software. El URD
definir todas las restricciones que el usuario desea imponer en cualquier solucin. El URD describir las
interfaces externas al sistema del software, o referencia en ICDs que existen o deben ser escritos.
El control del cambio del URD debe ser responsabilidad del usuario. Si un requerimiento del
usuario cambia despus de que el URD ha sido aceptado, entonces el usuario debe asegurar que el URD sera
sometido al UR/R para su aprobacin.
2.4.2 planes de prueba de aceptacin
Deben definirse los planes de prueba de aceptacin en la seccin de prueba de aceptacin de la
Comprobacin del Software y Plan de Aprobacin (SVVP/AT/Plans, vea Parte 2, Captulo 4). Estos planes
perfilan el acercamiento a demostrar que el software reunir los requerimientos del usuario.
2.4.3 plan de direccin de proyecto para la fase de SR
El plan de proyecto de contorno, la estimacin del costo total del proyecto, y el plan de direccin
para la fase de SR, debe documentarse en la fase SR del Software Proyecto Direccin Plan
(SPMP/SR, vea Parte 2, Captulo 2).
2.4.4 plan de direccin de configuracin para la fase de SR
Los procedimientos de direccin de configuracin para los documentos, productos de herramienta
CASE y prototipos del software para ser producido en la fase de SR, debe documentarse en el Plan de
Configuracin de Software (SCMP/SR, vea Parte 2, Captulo 3).
2.4.5 comprobacin y plan de aprobacin para la fase de SR
La fase SR debe documentar la revisin y procedimientos del traceability en la Comprobacin del
Software y Plan de Aprobacin (SVVP/SR, vea Parte 2, Captulo 4).
2.4.6 plan de conviccin de calidad para la fase de SR
La fase SR debe definir supervisar la calidad de los procedimientos en el Software Calidad
Conviccin Plan (SQAP/SR, vea Parte 2, Captulo 5).
___________________________________ 19 y 20 ______________________________________________

CAPITULO 3: FASE DE DEFINICION DE REQUERIMIENTOS DE

SOFTWARE

3.1) INTRODUCCION

La fase SR puede ser llamada fase de anlisis del problema en el ciclo de vida. El propsito de esta
fase es analizar la declaracin de requerimientos del usuario en el URD y producir un conjunto de
requerimientos del software tan completos, constantes y correctos como sea posible.
La definicin de requerimientos del software es responsabilidad del desarrollador. Los participantes
de esta fase deben ser usuarios, ingenieros de software, ingenieros de hardware y personal de operaciones.
Todos ellos tienen diferentes conceptos del producto final. Estos conceptos se deben analizar y sintetizar en
una declaracin completa y constante de los requisitos sobre los cuales cada uno puede estar a favor.
El jefe de proyecto debe asegurarse de que todas las partes fueron consultadas, con el fin de reducir
al mnimo el riesgo de que se presenten estados incompletos y errores.
Una salida de esta fase es el documento de los requerimientos del software (SRD). As como la
definicin de qu es lo que debe hacer el producto, es tambin la referencia con la cual el diseo y el producto
sern verificados. Aunque hay aspectos que deben ser dirigidos, deben ser eliminados del SRD, excepto
aquellos que el software obligue.
La fase de definicin de requerimientos del software termina con la aprobacin formal de las salidas
de la fase de SR, a travs de la revisin de los requerimientos del software (SR/R).

3.2) ENTRADAS A LA FASE

Las entradas de la fase SR son:

Documento de requerimientos del usuario (URD)

Plan de gestin del proyecto software para la fase SR (SPMP/SR)

Plan de gestin de configuracin del software para la fase SR (SCMP/SR)

Plan de validacin y verificacin del software para la fase SR (SVVP/SR)

Plan de garanta de calidad del software para la fase SR (SQAP/SR)

3.2)

ACTIVIDADES

Las actividades de la fase SR deben ser realizadas acordes con los planes definidos en la fase de
requerimientos del usuario (UR). El progreso de los planes debe ser continuamente supervisado por el jefe de
proyecto y documentado en forma regular con reportes acerca del progreso del proyecto.
La actividad principal de la fase SR es transformar los requerimientos del usuario indicados en el
URD en los requerimientos del software indicados en el SRD. Esto es alcanzado analizando el problema,
segn lo indicado en el URD, y construyendo una descripcin coherente y comprensiva de qu es lo que debe
hacer el software. El SRD contiene la vista que el desarrollador tiene del problema, mejor que la del usuario.
Esta visin se debe basar sobre un modelo del sistema, construido segn un mtodo reconocido y
documentado.
Los requerimeintos del software pueden necesitar de la construccin de prototipos, para clarificarlos
o verificarlos. Los requisitos que no pueden ser justificados a travs del modelo, o que cuya correccin no se
puede demostrar de una manera formal, pueden necesitar de un prototipo. Los requisitos de interfaz de
usuario necesitan a menudo esta clase de prototipo exploratorio.

La planeacin de actividades de la fase AD debe ser elaborada en la fase SR. Estos planes deben
cubrir la gestin del proyecto, la gestin de configuracin, la verificacin, la validacin y la garanta de
calidad.
Estas actividades son descritas con mayor detalle en la parte 2.

3.3.1 construccin del modelo lgico

Esto

El diseador construir a modelo aplicacin-independiente de lo que se necesita por el u suario.

se llama modelo lgico y se usa para producir los requisitos del software.

El modelo lgico se puede construir por la descomposicin de arriba hacia abajo (top-down) de la
funcin principal, segn lo deducido del URD, en una jerarqua de funciones. El modelar es un proceso
iterativo. Las partes del modelo pueden necesitar ser respecificadas muchas veces antes de lograr una
descripcin completa, coherente y constante.
Deben usarse Walkthroughs, revisiones e inspecciones para asegurar que la especificacin de cada
nivel ha sido convenida antes de proceder al prximo nivelado de detalle. Un modelo lgico de la buena
calidad debe satisfacer las reglas enumeradas abajo.
(1) Las funciones deben tener un solo propsito definido. Los nombres de la funcin deben tener una
estructura declarativa (por ejemplo Validar Telecomandos), y dicen cul es el hecho ms bien que el
cmo. El buen nombramiento permite que los componentes del diseo con la cohesin fuerte sean
derivados fcilmente (vase la parte 1, seccin 4,3,1,3).
(2) Las funciones deben ser apropiadas al nivel en que aparecen (por ejemplo Calcular suma de
verificacin no debe aparecer al mismo nivel de Verificar Telecomandos).
(3) Las interfaces deben ser reducidas al mnimo. Esto permite que los componentes del diseo con el
acoplador dbil sean derivados fcilmente (vase la parte 1, seccin 4,3,1,3).
(4) Cada funcin se debe descomponer en no ms de siete sub-funciones.
(5) El modelo debe omitir la informacin de la puesta en prctica (por ejemplo, archivo, registro, tarea,
mdulo);
(6) Las cualidades del funcionamiento de cada funcin (capacidad, velocidad, etc) deben ser declaradas;
(7) Las funciones crticas deben ser identificadas. En todos menos los proyectos ms pequeos, las
herramientas CASE se deben utilizar para construir un modelo lgico. Hacen modelos constantes ms
fciles construir y modificar.
3.3.2 Especificacin de requerimientos del software
Los requerimientos del software se obtienen examinando el modelo y clasificndolos en trminos
de:
(a) Requerimientos Funcionales
(b) Requerimientos de funcionamiento
(c) Requerimientos de Interfaz
(d) Requerimientos Operacionales

(e) Requerimientos de Recurso

(f) Requerimientos de Verificacin
(g) Requerimientos de prueba de Aceptacin
(h) Requerimientos de la Documentacin
(i) Requerimientos de Seguridad
(j) Requerimientos de Portabilidad
(k)Requerimientos de Calidad
(l) Requerimientos de Fiabilidad
(m) Requerimientos de Mantenibilidad
(n) Safety Requerimientos (no pude traducirlo ya que lo traduce como seguridad)
Mientras pueden concebirse otras clasificaciones de requisitos, los diseadores deben usar esta clasificacin,
con las definiciones descritas en Seccin 3.3.2.1.
Deben describirse los requisitos del software rigurosamente. Las diversas alternativas al lenguaje
natural estn disponibles, lo cual anima a su utilizacin. Donde sea posible, se deben declarar los requisitos
del software, teniendo en cuenta las condiciones cuantitativas para aumentar su verificabilidad.
Cuando los requisitos se compilan(acoplan y dan sentido al proyecto), ellos deben incluir los
identificadores(variables), referencias y medidas especificadas como necesarias, prioridad y estabilidad. Los
requisitos deben ser completos y consistentes. La duplicacin debe ser evitada.
3.3.2.1 Clasificacin de requisitos del software
(A) Requerimientos Funcionales. stos especifican lo que el software tiene que hacer. Ellos definen el
propsito del software. Los requisitos funcionales se derivan del modelo lgico que se deriva a su vez de los
requisitos del usuario. Para que ellos puedan declararse cuantitativamente, los requisitos funcionales deben
incluir los valores ptimos(estimaciones) de desempeo.
(b) Requerimientos en cuanto a Desempeo. stos especifican valores numricos medibles y
perceptibles(por ejemplo la proporcin, frecuencia, capacidad, y velocidad). adems, pueden incorporarse
requerimientos de Actuacin en la especificacin cuantitativa de cada funcin, o declarando estos
requerimientos por separado. Las declaraciones cualitativas son inaceptables Los atributos de la actuacin
pueden presentarse como un rango de valores, por ejemplo el:
El peor de los casos que puede ser aceptable;
el valor nominal, empleado para planificar,;
el valor del mejor valor, para indicar donde se necesita mayor potencial de crecimiento.
(c) requerimientos de Interfaces. stos especifican hardware, software o elementos del banco de datos
con que el sistema, o componente del sistema, debe actuar o comunicar recprocamente. Las condiciones de
las interfaces deben ser clasificadas en el software, hardware e interfaces de comunicacin. Las interfaces del
software podran incluir sistemas operativos, ambientes del software, formatos del archivo, sistemas de
direccin de bases de datos y otras aplicaciones del software. Los requisitos de interface de hardware pueden
especificar la configuracin del hardware. Los requerimientos de interface comunican restricciones sobre la
naturaleza de la interface de hardware y software. por ejemplo, se puede exigir el uso de un protocolo de la
red particular. Deben describirse los requisitos de la interface externos. Los requisitos de interface de usuario
deben se especificar bajo Requisitos Operacionales (vea debajo).
Pueden ilustrarse los requisitos de la interface con los diagramas de bloque de sistema (por ejemplo
para mostrar la configuracin del hardware).
(d) Requerimientos Operacionales. stos especifican cmo el sistema se ejecutar y cmo se
comunicar con los operadores humanos. Los requisitos operacionales incluyen toda la interface del usuario,
hombre-mquina o requisitos de interaccin de humano-computadora, as como los requerimientos lgicos y

organizacionales. Los ejemplos son: el esquema de la pantalla, el volumen de mensajes del error, los sistemas
de ayuda, etc. son a menudo tiles para definir la semntica y sintaxis de rdenes.
(e) Requerimientos de Recurso. stos especifican los lmites superiores en los recursos fsicos como
poder de procesamiento, cantidad memoria principal, espacio del disco, etc.
stos se necesitan sobre todo cuando el procesamiento del hardware retrasa los procesos, haciendo
demasiado caro, tal como en muchos sistemas integrado.
(f) Requerimientos de Comprobacin. stos especifican las restricciones sobre el sistema, para que
pueda ser verificado en su calidad. Los requerimientos de comprobacin restringen el SVVP. estos pueden
incluir requerimientos de simulacin, emulacin, pruebas reales con entradas simuladas, pruebas reales con
entradas reales, estableciendo una unin con el ambiente de la comprobacin.
(g) Requerimiento de Aceptacin de pruebas. stos especifican las restricciones con que el software
ser validado. La aceptacin que aprueba los requisitos restringe el SVVP.
(h) Requisitos de Documentacin. stos requisitos especifican para el proyecto su documentacin,
incluyendo en aqullos contenidos estas normas (por ejemplo el formato detallado del Manual de Usuario de
Software).
(i) Requerimientos de Seguridad. stos especifican los requisitos que debe tener el sistema contra las
amenazas entregando confidencialidad, integridad y disponibilidad. Los ejemplos de requisitos de seguridad
estn amarrados al operador de comandos, permitiendo inhibir ordenes, accesos de solo lectura, manejando
sistema de la contrasea y proteccin contra virus de computadora. El nivel de proteccin fsica necesit de
los medios de la computadora tambin puede declararse en este tem (por ejemplo los respaldos sern
guardados en un lugar seguro e incombustible).
(j) Requerimientos de Portabilidad. stos especifican la facilidad de modificar el software para ser
ejecutado en otras computadoras o en otro sistemas operativos. Deben declararse las posibles computadoras y
sistemas operativos a los que podr ser exportado.
(k) Requerimientos de Calidad. stos especifican atributos del software que aseguran que ayuda a sus
propsito (de manera que los atributos de calidad den mayor fiabilidad, mantenibilidad y seguridad, la que
siempre deben especificarse). es apropiado, especificar los atributos de calidad de software que sean medibles
y comprobados (es decir, debe hacerse uso de mtrica).
(l) Requerimientos de Fiabilidad. stos especifican el intervalo de tiempo aceptable de los fracasos del
software, promedi de un periodo significante (MTTF). Ellos tambin pueden especificar el tiempo mnimo
aceptable entre las cadas y la restitucin del sistema. Los requisitos de fiabilidad pueden ser derivados de los
requisitos de disponibilidad del sistema que necesita el usuario.
(m) Requerimientos de Mantenibilidad. stos especifican cuan fcil es reparar las fallas o adaptar el
software a los nuevos requisitos. Debe declararse la facilidad de realizar estas tareas en las condiciones
cuantitativas, como tiempo medio para reparar una falla(MTTR). Ellos pueden incluir restricciones
establecidas por la organizacin, marcando mantenimientos peridicos ante fallas potenciales. Estos
requerimientos pueden derivar de los requisitos de disponibilidad que solicit el usuario o requisitos de
adaptabilidad.
(n) Requerimientos de Disponibilidad. stos especifican cualquier requisito que reduzca la posibilidad
de daos que puede llevar al fracaso del software. Los requisitos de seguridad pueden identificar funciones
crticas, cuyo fracaso puede ser arriesgado para las personas o propiedad de la empresa.
3.3.2.2 Atributos de requisitos del software
Cada requisito del software debe incluir los atributos listados

(a) Identificadores - cada requisito del software incluir un identificador que facilite el trazado a travs
de las fases subsecuentes.
(b) Necesidad - se marcarn los requisitos del software esenciales como tal. Los requisitos del software
esenciales son non-negociables; otros pueden ser sumamente menos importantes y sujeto a negociacin.
(c) Prioridad - para una entrega incremental, cada requisito del software incluir una medida de
prioridad para que el diseador pueda decidir el horario de la produccin.
(d) Estabilidad - algunos requisitos deben conocerse y especificarse para hacer estables la vida
esperada del software; otros pueden ser ms dependientes en la regeneracin de la fase del plan, o puede estar
sujeto al cambio durante el ciclo de vida de software. Deben especificarse los requisitos inestables.
(e) Fuente - referencias que rastrean los requisitos del software atrs del URD, el que acompaarn a
cada requisito del software.
(f) Claridad - un requisito est claro si tiene uno, y slo una interpretacin. La claridad implica falta de
ambigedad. Si un trmino se usara en un contexto particular con mltiples significados, el trmino debe
clarificarse o debe reemplazarse con un trmino ms especfico.

(g) Verificabilidad- cada requisito del software ser comprobable.

Esto significa que debe ser posible:
Chequear que el requisito ha sido incorporado en el diseo;
Demostrar que el software llevar a cabo el requisito;
Probar que el software lleva a cabo el requisito.

3.3.2.3 Integridad de requisitos del software

La integridad tiene dos aspectos:

Ningn requisito del usuario se ha pasado por alto;

Una actividad se ha especificado para cada posible juego de entradas.

Para que el SRD est completo, cada requisito en el URD debe considerarse. Una matriz del
trazado debe insertarse en el SRD para demostrar la integridad.
La frase `Por ser definida' (TBD) indica el estado incompleto. No debe haber ningn TBDs en el
SRD.
3.3.2.4 Consistencia de requisitos del software
Un juego de requisitos es consistente si, y slo si, ningn juego de requisitos individuales est en
desacuerdo. Hay varios tipos de inconsistencia, por ejemplo:
Condiciones diferentes usadas para la misma cosa;
El mismo trmino usado para las cosas diferentes;
Actividades incompatibles que pasan al mismo tiempo;
Actividades que pasan en el orden incorrecto.
El logro de consistencia se hace ms fcil usando mtodos y herramientas.
3.3.2.5 Duplicacin de requisitos del software

La duplicacin de requisitos debe evitarse, aunque alguna duplicacin puede ser necesaria si el
SRD es para ser entendible.
Hay siempre un peligro que un requisito que solapa o reproduce otro se pasar por alto cuando el SRD
es actualizado. Esto lleva a inconsistencias. Donde la duplicacin ocurre, deben insertarse las referenciascruzadas para reforzar el modificabilidad.
3.3.3 Revisiones
Se revisarn formalmente las salidas de la fase de SR durante la Revisin de Requisitos del
Software (SR/R). sta debe ser una revisin tcnica (vea Parte 2, Captulo 4). Los Participantes deben incluir
a los usuarios, el personal de funcionamiento, los desarrolladores y los gerentes involucrados.

3.4 SALIDAS DE LA FASE

Las salidas principales de la fase son los SRD y los planes para la fase AD.
Los informes de progreso, cuentas de estado de la configuracin, y los reportes de auditora
tambin son salidas de la fase. stos siempre deben ser archivados por el proyecto.
3.4.1 Documento de Requisitos de software
Un rendimiento de la fase de SR ser el Documento de Requisitos de Software (SRD).
El SRD ser consistente. Los mtodos de Ingeniera de Software y herramientas pueden ayudar a lograr la
consistencia.
Los requisitos funcionales deben ser estructurados en forma top - down en el SRD. Deben juntarse
los requisitos No-funcionales a los requisitos funcionales y por consiguiente pueden aparecer en todos los
niveles de la jerarqua, y aplica a todos los requisitos funcionales debajo de ellos (la herencia de atributos
familiares).
El SRD no incluir la aplicacin detalla o terminologa, a menos que tiene que estar presente.
Por consiguiente, las descripciones de funciones dirn lo que el software hace, y debe evitar decir
cmo ser hecho. El SRD evitar especificar el hardware, a menos que el usuario lo especifique.
Los rendimientos del mtodo del anlisis, por ejemplo `DFD' en el caso de Anlisis Estructurado, debe ser
incluido, para proporcionar la apreciacin global necesitada para permitir una comprensin de los requisitos
especficos.
Cada requisito del software debe tener un identificador, e incluye medidas de necesidad y
prioridad. Los requisitos del software deben la referencia el URD para facilitar la identificacin al revs.
El SRD puede escribirse en un idioma natural. Esto tiene la ventaja importante que no presenta ninguna
barrera adicional entre las personas de disciplinas diferentes que estn involucrados durante esta fase. Por otro
lado, los idiomas naturales tienen muchas propiedades que son indeseable en las especificaciones (la
ambigedad, imprecisin e inconsistencia). Usando los idiomas de especificacin de requisitos pueden
eliminar muchos de estos problemas, y stos van principalmente en ingls Estructurado para Mtodos
Formales como Z o VDM. Los mtodos formales deben ser considerados para la especificacin de sistemas
de seguridad - crticos. Si en un idioma de especificacin de requisitos se usa, el texto explicativo, escrito en
el idioma natural, debe ser incluido en el SRD para permitirle no ser repasado por aqullos que estn
familiarizados con el idioma de la especificacin.

El SRD se compilar segn la mesa de volmenes proporcionada en el Apndice C que se deriva de

ANSI/IEEE Std 830-1984 las Especificaciones de Requisitos de Software.

3.4.2 planes de prueba de sistema

Deben definirse los planes de prueba de sistema en la seccin de prueba de sistema de la
Validacin del Software y Plan de Aprobacin (SVVP/ST/Plans, vea Parte 2, Captulo 4). Estos planes
perfilan el acercamiento para demostrar que el software reunir los requisitos especificados.
3.4.3 plan de direccin de proyecto para la fase del AD
El perfil del plan de proyecto, la estimacin del costo para el proyecto completo (precisamente
30%), y el plan de direccin para la fase de AD, debe documentarse en la seccin de la fase de AD del Plan de
Proyecto de Software (SPMP/AD, vea Parte 2, Captulo 2).
Deben documentarse la revisin de fase de AD y procedimientos identificacin en la Validacin del
Software y Plan de Aprobacin (SVVP/AD, vea Parte 2, Captulo 4).
3.4.4

Manejo del plan de Configuracin para la Fase AD

El procedimiento para el manejo de configuracin para los documentos, los productos de

herramientas CASE y software de prototipos, sern producidos en la fase de AD, deben estar documentados
en el software de Plan de Manejo de Configuraciones (SCMP/AD, vea Parte 2, Captulo 3).
3.4.5 Verificacin y plan de aprobacin de la fase AD
La Fase AD revisa y trazabiliza procedimientos, documentando las verificaciones del software y el plan de
aprobacin (SVVP/AD, vea Parte 2, Captulo 4)
3.4.6 plan de aseguramiento de la calidad para la fase AD
En la Fase AD, debe definirse procedimientos para supervisar la calidad del Software con el Plan
Aseguramiento de la Calidad (SQAP/AD, vea Parte 2, Captulo 5).

Capitulo 4 :LA FASE DEL DISEO ARQUITECTNICO

4.1 INTRODUCCIN
La fase AD puede llamarse "La fase solucin" del ciclo de vida. El propsito de esta fase es definir una
coleccin de componentes de software y sus interfaces para establecer un armazn que soporte el desarrollo
del software. Esto es el diseo arquitectnico, y debe cubrir todos los requisitos del SRD.
La definicin del diseo arquitectnico es responsabilidad del ingeniero de software. Puede respaldarse con la
opinin de otros ingenieros, y realizar revisiones del diseo arquitectnico con representantes del usuario y
personal operativo.
La salida de esta fase es un Documento del Diseo arquitectnico(ADD). Este debe documentar cada
componente y su relacin con otros componentes.
El ADD se considera terminado cuando el nivel de definicin de los componentes e interfaces el lo
suficientemente clara, de manera que permita a los individuos o grupos, trabajar de forma independiente en la
fase DD.
la fase de diseo arquitectnico termina con la aprobacin formal de las salidas(resultados) de la fase AD con
la Revisin del diseo arquitectnico(AD/R)

4.2 Entradas a la fase

las entradas de la fase AD son las siguientes:

* documento de requerimientos de software
* direccin del plan del proyecto de software para la fase AD (SPMP/AD)
* direccin del plan de configuracin de la fase AD (SCMP/AD)
* Plan de aprobacin y Comprobacin del software para la fase AD ( SWP/AD)
* Plan de aseguramiento de la calidad del software para la fase AD (SQAP/AD)

4.3 actividades
Las actividades de la fase AD se llevaran a cabo segn los planes definidos en la fase SR. Los progresos o
avances en el proyecto, debe monitoriarce continuamente para la direccin del proyecto, documentndose
sobre la marcha y en intervalos regulares.
La actividad principal de la fase AD es el desarrollo del diseo arquitectnico del software y el documento de
AD.
esto involucra:
* construccin de un modelo fsico
* especificacin del diseo arquitectnico
* seleccionar el lenguaje de programacin.
* revisar el plan.

Un mtodo reconocido para el plan del software se adoptar y se aplicar de forma consistente en
la fase del AD. Donde ningn solo mtodo proporciona todo las capacidades requeridas, un mtodo proyectoespecfico puede adoptarse, que debe ser una combinacin de mtodos reconocidos.
Los planes para el resto del desarrollo deben prepararse en la fase del AD. Estos planes cubren
direccin del proyecto, direccin de la configuracin, comprobacin, aprobacin y conviccin de calidad.
Estas actividades se describen en parte 2 en ms detalle.
4.3.1 construccin del modelo fsico
El diseador construir un Modelo Fsico que describe el plan del software, usando la terminologa
de aplicacin. El modelo fsico debe derivarse del modelo lgico, descrito en el SRD. Transformando a un
modelo lgico a un modelo fsico, decisiones de Diseo en que se asignan las funciones a los componentes y
sus entradas y rendimientos definidos. Las decisiones del plan tambin deben satisfacer requisitos no
funcionales, plan de criterio de calidad y consideraciones de tecnologa de aplicacin. Deben respaldar las
decisiones del plan.
El modelado es un proceso reiterativo. Cada parte de las necesidades ejemplares deben ser
especificadas y el respetadas hasta que una descripcin coherente de cada componente se logre.
En todos menos los proyectos ms pequeos, deben usarse las herramientas CASE para construir
el modelo fsico. Ellos hacen ms fcil construir y modificar modelos consistentes.

4.3.1.1 descomposicin del software en componentes

El software debe descomponerse en una jerarqua de componentes segn un mtodo dividiendo.
Los ejemplos de dividir los mtodos son decomposicin Funcional y Correspondecia con objetos mundiales
reales. Debe haber distintos niveles dentro de la jerarqua, con cada componente que ocupa un lugar biendefinido.

El mtodo se usa para descomponer el software en sus partes componentes, permitiendo un

acercamiento top-down. Empezando del componente nivel mas alto, el software se descompone en una
jerarqua del plan de diseo de componentes textuales, especificando los niveles superiores de la jerarqua,
tpicamente la nivel tres o cuatro.
la descomposicin TOP-Down es vital para controlar la complejidad porque da fuerza a la
Informacin Oculta exigiendo que los componentes de los mas bajos niveles se comporten como Cajas
Negras. Slo la funcin e interfaces de los componentes de ms bajo nivel son requeridos para el diseo de
los niveles superiores. La informacin necesaria para el funcionamiento interno de los componentes de Bajo
Nivel, puede permanecer oculto.
la descomposicin Top-Down tambin requiere que cada nivel de diseo se describa usando
condiciones que tienen un grado apropiado de `Abstraccin ' (por ejemplo las condiciones `File ', `Record ', y
`Byte ' debe ocurrir a los niveles diferentes en el plan de un sistema de manejo de archivos) . el grado correcto
de abstraccin a cada nivel ayuda la ocultacin de informacin.
Los componentes niveles de abajo en el ADD debe ser suficientemente independiente permitir que
susu detalles de diseo y codificacin para proceder en paralelo que otros componentes, con un mnimo de
interaccin entre programadores. En los sistemas Multi-Tareas, el nivel ms bajo del Plan Arquitectnico
debe ser el nivel de tarea. Al nivel de Tarea las relaciones (es decir antes de, despus de o coexistente) entre
las funciones se asignan a las tareas.
4.3.1.2 aplicacin de requisitos no-funcionales
El SRD contiene varios requisitos en la categora no-funcional. stos son:
" Los requisitos de la actuacin
" Los requisitos de la interfaz
" Los requisitos operacionales
" Los requisitos del recurso
" Los requisitos de la comprobacin
" Aceptacin que prueba los requisitos
" Los requisitos de la documentacin
" Los requisitos de seguridad
" Los requisitos de portabilidad
" Los requisitos de calidad
" Los requisitos de fiabilidad
" Los requisitos de Mantenibilidad
" Los requisitos de seguridad
El plan de cada componente debe repasarse contra cada uno de estos requisitos. Mientras algunos
requisitos no-funcionales pueden aplicar a todos los componentes en el sistema, otros requisitos nofuncionales slo pueden afectar el plan de unos componentes.
4.3.1.3 plan de criterio de calidad
Los planes deben ser adaptables, eficaces y entendibles. Los planes adaptables son fciles de
modificar y mantener. Los planes eficaces hacen uso mnimo de recursos disponibles. Los planes deben ser
entendibles si ellos sern construidos, se operarn y se mantendrn eficazmente.
El logro de estas metas se ayuda apuntando para la simplicidad en la forma y funciona en cada
parte del plan. Hay varios mtrica que puede usarse por medir la complejidad, (por ejemplo el nmero de
interfaces por el componente), y su uso debe ser considerado.
La simplicidad de funcin es lograda por el maximising el `Cohesion ' de componentes
individuales (es decir el grado a que las actividades interior al componente se relaciona entre si a).

La simplicidad de forma se logra por:

" el minimising el `Coupling ' entre los componentes (es decir el nmero de artculos distintos que se pasan
entre los componentes);
" asegurando que la funcin que un componente realiza es apropiada a su nivel en la jerarqua;
" emparejando el software y estructuras de los datos;
" el maximising el nmero de componentes que usan un componente dado;
" restringiendo el nmero de componentes del nio a 7 o menos;
" quitando la duplicacin entre los componentes haciendo los nuevos componentes.
Los planes deben ser `Modular ', con el acoplamiento mnimo entre los componentes y cohesin
del mximo dentro de cada componente. Hay duplicacin mnima entre los componentes en un plan modular.
Los componentes de un plan modular se describen a menudo como cajas de `Black porque ellos esconden la
informacin interior de otros componentes. Es
no necesario saber cmo un componente de la caja negro trabaja para saber qu hacer con l.
Entendible la terminologa de empleo de planes de una manera consistente y siempre acostumbra la
misma solucin al mismo problema. Donde unce de diseadores colabore para producir un plan, los
understandability pueden ser daados considerablemente permitiendo la variedad innecesaria. Los
tools,tandards del CASO y revisiones del plan toda la ayuda para dar fuerza a consistencia y uniformidad.
4.3.1.4 comercio-fuera de entre los planes de la alternativa
No hay ningn nico plan para cualquier sistema del software. Los estudios de las opciones
diferentes pueden ser necesarios. Varios criterio se necesitar escoger la opcin mejor. El criterio depende del
tipo de sistema. Por ejemplo, en una situacin del real-tiempo, la actuacin y tiempo de la contestacin
podran ser importantes, considerando que en una estabilidad del sistema administrativa de la base de datos
podra ser ms importante.
El Prototipado puede ser realizado para verificar posibles acercamientos en el diseo o evaluar los
acercamientos del plan alternativos. Esto es llamado el Prototipado Experimental. Por ejemplo, si un
programa requiere un rpido acceso a los datos guardados en disco, entonces varios mtodos de acceso a
archivos podran ser codificados y medidos. Diferentes mtodos de acceso podran alterar el acercamiento al
diseo en forma significativa, y el mtodo de acceso y prototipado se convertira en una parte esencial dentro
del proceso de diseo.
Slo el acercamiento al diseo seleccionado se reflejar en el ADD (y DDD). Sin embargo, la
necesidad por un prototipado, listado de cdigo, criterios, y razones para la solucin escogida, debe
documentarse en el Documento de la Historia del Proyecto.
4.3.2 Especificacin del Diseo Arquitectnico
El diseo arquitectnico es el modelo fsico totalmente documentado. Esto debe contener
diagramas que muestran, cada nivel del diseo arquitectnico, flujos de datos y control de flujos entre los
componentes. Los diagramas por bloque, muestran las entidades, tareas y archivos, tambin puede usarse
para describir el diseo. Las tcnicas utilizadas en los diagramas deben documentarse o hacer referencia a
ellas.
4.3.2.1 Definicin Funcional de los Componentes
El resultado del proceso de diseo arquitectnico resulta un set de componentes que han definido
funciones e interfaces. Se derivarn las funciones de cada componente del SRD. El nivel de detalle en el ADD
mostrar qu requisitos funcionales sern reunidos por cada componente, pero no necesariamente cmo son:
esto slo se conocer cuando el diseo detallado este completo. Igualmante, se restringirn las interfaces entre
los componentes a una definicin de la informacin para intercambiar, y no cmo intercambiarlo (a menos
que esto contribuye al xito o fracaso del plan escogido).

Para cada componente la informacin siguiente se definir en el ADD:

- La entrada de los datos;
- Las funciones a realizar;
- La salida de los datos.
Los datos entran y salen, y debe definirse la estructura de los datos. (vea la prxima seccin).
4.3.2.2 Definicin de la estructura de los datos
La estructura de los datos que unen los componentes se definirn en el AGREGUE. Pueden
documentarse las interfaces externas separadamente en un ICD.
La definicin de la estructura de los datos debe incluir:
- La descripcin de cada elemento (por ejemplo el nombre, teclee, dimensin);
- Las relaciones entre los elementos (es decir la estructura);
- El rango de posibles valores de cada elemento;
- Los valores iniciales de cada elemento.
4.3.2.3 Definicin del control de flujo
La definicin recontrol de flujo entre los componentes es esencial para la comprensin del
funcionamiento del software. El control de flujo entre los componentes se definir en el ADD.
Las definiciones de control de flujo pueden describir:
- Operaciones secuenciales y paralelas;
- Comportamiento sncrono y asncrono.
4.3.2.4 Definicin de utilizacin de recurso de computadora
Los recursos de la computadora (por ejemplo la velocidad de CPU, memoria, el almacenamiento, el
software del sistema) necesitado en el ambiente de desarrollo y el ambiente operacional se estimar en la fase
del AD y se definir en el ADD. Para muchos proyectos de software, el ambiente de desarrollo y el ambiente
operacional sern el mismo. Cualquier requisito del recurso en el diseo se restringir en el SRD.
4.3.3 Seleccin de Lenguaje de Programacin
El Lenguaje de Programacin debe ser seleccionado bajo un esquema Top-Down, una
programacin estructurada y una produccin coexistente y documentada. El lenguaje de programacin y el
mtodo AD deben ser compatibles.
Los requerimientos no funcionales pueden influir en la eleccin del lenguaje de programacin. Por
ejemplo, la portabilidad y las consideraciones de mantenimiento sugieren que el ensamblador slo debe
seleccionarse debido a razones muy especficas y justificables. La disponibilidad de compiladores fiables y
depuraciones eficaces reprime la seleccin de un lenguaje de programacin.
4.3.4 Revisiones
El diseo arquitectnico debe repasarse y la capa convenida por la capa como l se desarrolla
durante la fase del AD. El diseo en cualquier nivel invariablemente afecta las capas superiores: varios ciclos
de revisin pueden ser necesarios antes finalizar el diseo de un nivel. debe acostumbrarse a asegurar que el

diseo arquitectnico se entiende por todos los agentes involucrados. Pueden usarse las inspecciones del
diseo, por los ingenieros del software calificados, para eliminar los defectos del diseo.
Se repasarn los rendimientos de la fase del AD formalmente durante la Revisin del Diseo
Arquitectnico (AD/R). sta debe ser una revisin tcnica (vea Parte 2, Captulo 4). Los Participantes deben
incluir a los usuarios, el personal de los funcionamientos, que el hardware disea, el software disea, y los
gerentes involucraron.
Despus de la salida de la fase de DD, las modificaciones al diseo arquitectnico pueden aumentar
substancialmente. La fase de DD no debe empezarse si hay todava duda, los puntos abiertos mayores, o
incertidumbres en el diseo arquitectnico.

4.4 SALIDA DE CADA FASE

Los salidas principales de la fase son el ADD y los planes para la fase de DD.
Los informes de progreso, considera el estado de la configuracin, los informes de comprobacin
de software e informes de auditora tambin son salidass de la fase. stos siempre deben archivarse para el
proyecto.
4.4.1 Documento del diseo arquitectnico
El Documento del diseo Arquitectnico (ADD) es el documento que resume la solucin. Es el
grano de que el diseo detallado que crece. El ADD definir los componentes mayores del software y las
interfaces entre ellos. El ADD definir o referencia las interfaces todo externas. El ADD ser un rendimiento
de la fase del AD.
El ADD estar completo, mientras cubra todos los requisitos del software descritos en el SRD.
Para demostrar esto, una tabla de referencia cruzada de los requisitos de software y las partes del diseo
arquitectnico se pondrn en el ADD.
El ADD ser consistente. El mtodo que disea mtodos y herramientas de software puede ayudar
a lograr la consistencia, y su rendimiento puede ser incluido en el ADD.
El ADD debe ser lo suficientemente detallado para permitirle al lder de proyecto preparar la implementacin
detallada de un plan y controlar el proyecto durante las fases de desarrollo siguientes. El ADD debe ser
bastante detallado para permitir que el coste del desarrollo restante sea estimado dentro de un 10%.
El ADD debe ser compilado segn el contenido de la tabla proporcionado en el apndice C, la cul se deriva
de ANSI/IEEE Std 1016-1987, descripcin del diseo del software. Esta tabla de contenidos pone un
acercamiento a lo descrito en la seccin 4.3.2.
4.4.2

Planes de Prueba de Integracin

Deben definirse los planes de prueba de integracin en la seccin de prueba de integracin de la

Comprobacin del Software y Plan de Aprobacin (SVVP/IT/Plan, ver Parte 2, Captulo 4). Estos planes
perfilan el acercamiento a demostrar que los subsistemas del software se conforman con el ADD.
4.4.3

Plan de Direccin de Proyecto Para la Fase DD

La estimacin del coste total del proyecto (exacto hasta el 10%), y el plan de la gerencia para la fase de la
DD, se deben documentar en la seccin de la fase de la DD del plan de la direccin de proyecto del software
(SPMP/DD, ver parte 2, captulo 2). Un plan del contorno para las fases del TR y de OM debe tambin ser
incluido.

4.4.4

plan de direccin de configuracin para la fase de DD

Los procedimientos de direccin de configuracin para los documentos, cdigo entregable, productos de
herramientas CASE y software del prototipo, para ser producido en la fase de DD, debe documentarse en el
Software Configuracin Direccin Plan (SCMP/DD, ver Parte 2, Captulo 3).
4.4.5

Comprobacin y plan de aprobacin para la fase de DD

Los procedimientos de la revisin y de la trazabilidad de la fase de la DD se deben documentar en el plan de

la verificacin y de la validacin del software (SVVP/DD, ver parte 2, captulo 4).
4.4.6

Plan de conviccin de calidad para la fase de DD

La calidad de la fase de la DD que supervisa procedimientos se debe definir en el plan de la garanta de

calidad del software (SQAP/DD, ver parte 2, captulo 5).

En esta pgina se deja intencionalmente el espacio en blanco

CAPTULO 5: PLAN DETALLADO Y FASE DE LA PRODUCCIN

5.1 INTRODUCCION
La fase de la DD se puede llamar la fase de la puesta en prctica del ciclo de vida. El propsito de la fase de
la DD es detallar el diseo contorneado en la ADD, y cifrarlo, documentar y probar.
El plan detallado y la produccin es la responsabilidad de los ingenieros del software. Pueden
consultarse otros tipos de ingenieros durante esta fase, y representantes de usuarios y personal operacional
pueden observar las pruebas del sistema.
Importantes consideraciones antes de comenzar la produccin del cdigo son la suficiencia y la disponibilidad
de los recursos de la computadora para el desarrollo del software. No hay punto en la codificacin que
comienza y la prueba si la computadora, el sistema operativo y el software del sistema no estn disponibles o
suficientemente confiables y estables. La productividad puede caer dramticamente si estos recursos no son
adecuados. La falta de invertir en herramientas del software y hardware del desarrollo conduce a menudo a
costes ms grandes del desarrollo.
La salida principal de esta fase es el cdigo, el documento detallado del diseo (DDD) y manual del usuario
del software (SUMA).
La fase de la DD termina con la aprobacin formal del cdigo, del DDD y de la SUMA por la revisin de
diseo detallada (DD/R).

5.2 ENTRADAS A LA FASE

Las entradas a la fase de DD son:
" Documento arquitectnico del diseo (ADD);
" Plan de prueba de integracin (SVVP/IT/Plan);
" Plan de prueba de sistema (SVVP/ST/Plan);
" Plan de la direccin de proyecto para la fase DD (SPMP/DD);
" Plan de la configuracin de la direccin del software para la fase DD (SCMP/DD);
" Plan de la configuracin y validacin del software para la fase DD (SVVP/DD);
" Plan para el aseguramiento de la calidad del software para la fase DD (SQAP/DD).

5.3 ACTIVIDADES
Las actividades de la fase de la DD sern realizadas segn los planes definidos en la fase AD. El progreso de
los planes se debe supervisar por la direccin de proyecto y documentar continuamente en informes la marcha
en intervalos regulares.
El diseo detallado y produccin de software sern basados en lo siguientes tres principios:
Descomposicin Top-Down
Programacin estructurada
Produccin y documentacin concurrente

Estos principios se reflejan en el diseo del software y la organizacin del trabajo. Ellos ayudan a asegurar
que el software se entregue a tiempo y dentro del presupuesto, porque se pone el nfasis en `obtenerlo
correcto a la primera vez'. Ellos tambin tienen un efecto positivo en la calidad del software, su fiabilidad,
mantencin y seguridad.
La descomposicin top-down es vital para controlar la complejidad porque da nfasis a la informacin
oculta' exigiendo que los componentes de bajo-nivel se comporten como cajas negras. Slo la funcin e
interfaces de un componente bajo-nivel se requieren para el diseo nivel-superior. La informacin necesaria
del funcionamiento interno de un componente de bajo-nivel puede permanecer oculto.
La programacin estructurada apunta a evitar los errores de fabricacin cuando un mdulo es
diseado y cuando el cdigo es escrito. El refinamiento sucesivo de un plan dentro cdigo, compuesto de una
secuencia bsica, seleccin y estructuras de iteracin son la principal caracterstica de la tcnica. Reduciendo
el nmero de errores del cdigo, la programacin estructurada reduce dramticamente el tiempo gastado
probando y corrigiendo tambin la programacin del software hace el cdigo ms entendible, reduciendo el
tiempo gastado en la inspeccin y en el mantenimiento.
La produccin concurrente y la documentacin del cdigo son un efecto lateral de refinamiento
sucesivo. La informacin del plan debera ser retenida al igual que el comentario del cdigo fuente.
5.3.1 plan detallado
En el plan detallado, componentes de bajo nivel del plan arquitectnico son descompuestos hasta
que ellos puedan expresarse como mdulos en el lenguaje de programacin seleccionado. Un mdulo es una
unidad del programa que es discreto e identificable con respecto a la compilacin, combinado con otras
unidades, y carga.
Empezando desde los componentes de nivel mas bajo en el ADD, el plan procede a bajar niveles
va el refinamiento sucesivo de cada especificacin de mdulo.
Las pautas para el refinamiento sucesivo son:

Comenzar desde las especificaciones funcional y de interfaz;

Concentrarse sobre el control de flujo;
Diferenciar declaraciones de datos hasta la fase de codificacin;
Mantener pasos de un pequeo refinamiento para que la verificacin sea ms fcil;
Revisar cada paso as como estos sean hechos.

La revisin de cada mdulo puede ser por walkthrough o por inspeccin. La revisin de un mdulo
est completa cuando es aceptado para codificarlo.
Los mtodos y herramientas CASE usadas para el plan arquitectnico deberan ser usadas en la
fase DD para el trabajo del plan detallado.
Aunque el diseo normalmente debe proceder hacia abajo, algunos de los componentes de mas bajo
nivel pueden necesitar ser diseados (y codificados) primero. Los ejemplos son drivers de dispositivos y
libreras.
5.3.2 produccin
5.3.2.1 Codificando
Cuando el diseo de cada mdulo se completa, se repasa y se aprueba, puede codificarse.

Las convenciones de la codificacin deben establecerse y documentarse en el DDD. Ellos deben

proporcionar reglas para:

presentacin, (por ejemplo, la informacin de cabecera y el esquema de comentario);

nombrando programas, subprogramas, archivos, variables y datos;
limitando el tamao de mdulos;
usando las rutinas de libreras, sobre todo,:
o las rutinas del sistema operativo;
o las rutinas de libreras comerciales (por ejemplo el anlisis numrico);
o rutinas de utilidad especficas del proyecto;
definiendo las constantes;
usando un copilador de caractersticas especficas no en el lenguaje estndar;
manejo de errores.

El header estndar (vea Parte 2, Captulo 3) debe hacerse disponible para que pueda ser editada,
completada y entonces insertada en el header de cada mdulo.
El cdigo debera ser consistente, esto reduce la complejidad. La adhesin rigurosa de
convenciones de codificacin es fundamental para asegurar la consistencia. Adems, la consistencia se
refuerza adoptando las mismas soluciones a los mismos problemas. Conservar consistencia del cdigo,
cambios y modificaciones deberan seguir el estilo del cdigo original, asumiendo que fue producido bajo
estndares reconocidas.
El cdigo debera ser estructurado, esto reduce errores y refuerza la mantencion. Generalmente,
esto significa resolver bajo una secuencia bsica, seleccin (es decir, condicin) e iteracin (es decir, loops).
Prcticamente, las ideas de programacin estructurada requieren eso:

cada mdulo debe tener una sola entrada y punto de salida;

el flujo de control debera proceder desde el inicio hasta el final;
cdigo relacionado debera ser bloqueado junto, en lugar de disperso alrededor del mdulo;
bifurcaciones fuera de un mdulo slo debe realizarse bajo las condiciones prescritas (por ejemplo la
salida de error).

Produccin de consistencia, cdigo estructurado es hecho ms fcil usando las herramientas como
los editores lenguaje-sensibles, personalizados para satisfacer las convenciones de un proyecto.
El proceso de codificacin incluye la compilacin; no slo esto produce el cdigo del objeto
necesitado para probar el comportamiento de un mdulo, este el primer paso para verificar el cdigo. La
compilacin normalmente produce estadsticas que pueden usarse para el anlisis esttico del mdulo.
El cdigo suplementario incluido para ayudar el proceso de la comprobacin deber ser prontamente
identificable y fcil de deshabilitar, o remover, despus de una comprobacin exitosa. El cuidado que debera
tenerse para asegurar que tal cdigo no obstaculice la lgica del mdulo.
Como la codificacin de un mdulo beneficiado, documentacin de las suposiciones del plan,
funcin, estructura, interfaz, datos internos y utilizacin del recurso deberan proceder concurrentemente.
Esta informacin debe grabarse en parte 2 del DDD. La inclusin de esta informacin en el cdigo fuente es
recomendada. Para evitar el problema de mantenimiento de tener la misma informacin en dos lugares, las
herramientas para seleccionar informacin requerida para el DDD del cdigo fuente son deseables.
Cuando un mdulo ha sido documentado y compilado con xito, la unidad de testing puede
empezar.

5.3.2.2 integracin
La integracin es el proceso de construir un sistema de software combinando los componentes en
una entidad activa.
La integracin de componentes debera proceder en una secuencia ordenada funcin por funcin.
Esto permite demostrar las capacidades operacionales del software tempranamente, incrementando la
confianza en la direccin que el proyecto est progresando satisfactoriamente.
El proceso de integracin se controlar por los procedimientos de direccin de configuracin sw
software definidos en el SCMP. Los buenos procedimientos de SCM son esenciales para la integracin
correcta.
El enfoque top-down a la integracin es para usar resguardos para representar los mdulos de bajo
nivel. Cuando los mdulos son completados y testeados, ellos reemplazan los resguardos. En muchos
proyectos, la necesidad de hacer los componentes compartidos disponibles a las fases tempranas la
integracin a ser organizada inicialmente sobre una base bottom-up, y despus sobre top-down. Lo que sea
tomado del mtodo integracin, debe minimizar el tiempo gastado en testear, mientras se asegure que todas
las instrucciones del cdigo sean verificadas
.
5.3.2.3.3 Prueba del sistema
La prueba del sistema es el proceso de probar un sistema de software integrado. Esta
comprobacin puede hacerse en el desarrollo o ambiente designado, o una combinacin de los dos. La prueba
del sistema verificar conformidad con los objetivos del sistema, segn lo indicado en el SRD.
Lo prueba del sistema debe incluir las actividades tales como:
" pasar datos en el sistema, procesndolos correctamente y hacindolos salir (es decir prueba del sistema endto-end);
" la prctica para las pruebas de aceptacin(es decir la verificacin de que las exigencias del usuario sern
resueltas);
" las pruebas de tensin (es decir la medida de los lmites del funcionamiento);
" la estimacin preliminar de fiabilidad y de la capacidad de mantenimiento;
" la verificacin del Manual de Usuario de Software.

Deben supervisarse tendencias en la ocurrencia de defectos en las pruebas del sistema; el

comportamiento de tales tendencias es importante para la estimacin de aceptabilidad potencial.
Para la mayora de los sistemas incluidos, as como sistemas que usan perifricos especiales, es a
menudo til o necesario construir los simuladores para el hardware con que el sistema entregable
interconectar. Tales simuladores se requieren a menudo debido a:
" ltima disponibilidad del hardware final del sistema;
" tiempo disponible bajo la prueba con el hardware final del sistema;
" deseo de evitar daar el hardware delicado y/o costoso, particularmente el hardware del vuelo.
Los simuladores normalmente son un proyecto separado en si mismos. El esfuerzo debe hacerse
para asegurar que ellos estn disponibles en tiempo, y de que estn certificados como idnticos, desde el
punto de vista de la interfaz, con el hardware designado.

La prueba del sistema, casos de la prueba, procedimientos de prueba e informes de prueba se

documentan en la seccin de Prueba del Sistema del Plan de Validacin y Verificacin del
Software(SVVP/ST).
5.3.3 revisiones
El diseo detallado debe repasarse y la capa convenida por capa se desarrolla durante la fase de
DD. El diseo de cualquier nivel invariablemente afecta las capas superiores y varios ciclos de la revisin
pueden ser necesarios antes de que el diseo de un nivel puede finalizarse. Walkthroughs debe ser utilizado
para asegurar que el diseo detallado es entendido por todos los involucrados. Deben usarse las inspecciones
del diseo, por los ingenieros de software calificados, para reducir la ocurrencia de defectos en el diseo.
Cuando el diseo detallado de un componente mayor (o importante) se acaba, una revisin crtica
del diseo se emplazar para certificar su preparacin para la puesta en marcha. El lder del proyecto debe
participar en estas revisiones, junto con el lder del equipo y los miembros del equipo involucrados.
Despus de que los mdulos han sido codificados y compilados con xito, deben sostenerse
walkthroughs o inspecciones para verificar que la puesta en marcha se conforma con el diseo.
Despus de la produccin, la revisin de la DD (DD/R) considerar los informes de las actividades
de la verificacin y decidir as transferir el software. sta debe ser una revisin tcnica (vea Parte 2, Captulo
4). los participantes de la Revisin deben incluir a ingenieros, representantes del usuario y gerentes.

5.4 SALIDAS A PARTIR DE LA FASE

Las salidas principales de la fase son el cdigo, DDD, SUMA y los planes para la fase del TR.
Los informes de progreso, el estado de la configuracin considera, los informes de verificacin
del software e informes de auditoria tambin son salidas de la fase. stos siempre deben archivarse por el
proyecto.
5.4.1 cdigo
El diseador debe entregar todos los artculos necesitados para ejecutar y modificar cualquier parte
del software producido en el proyecto, e.g,:
" archivos fuentes;
" comandos de procedimiento de archivos;
" configuracin de herramientas de administracin;
" archivos fuente para el software de prueba;
" datos de la prueba;
" procedimientos de la estructura y de instalacin.
Todo el cdigo entregable se identificar en una lista de artculos de configuracin.
5.4.2 Documento del Plan detallado
El DDD crece como los beneficios del plan al nivel ms bajo de descomposicin. La
documentacin debe producirse concurrentemente con el plan detallado, codificando y probando. En los
proyectos grandes, puede ser conveniente organizar el DDD global en varios contenidos. El DDD ser una
salida de la fase de DD. Una tabla recomendada de contenidos del DDD se proporciona en el Apndice C.

Parte 1 del DDD define diseo y codificacion estandar ademas de herramientas, y deberia ser
preparada como la primera actividad de la fase de DD, antes de que empiece el trabajo de diseo detallado y
codificacion.
Parta 2 del DDD extiende como el desarrollo del diseo. Parte 2 del DDD tendrn la misma
estructura y esquema de identificacin como el propio cdigo, con una 1:1 correspondencia entre las
secciones de la documentacin y los componentes del software.
El DDD estar completo, considerando todos los requisitos del software en el SRD. Una tabla de
referencias cruzadas de requerimientos del sw para los componentes del diseo detallado debe estar en el
DDD.
5.4.3 Manual de Usuario de software
Un Manual de Usuario de Software (MUS) sera una salida de la fase de DD. La tabla recomendada
de contenidos para un MUS se provee en el Apndice C. Las reglas para estilo y contenidos del Manual de
Usuario de Software es basado en ANSI/IEEE Std 1063-1987, Documentacin Usuario de `Software '. Dos
estilos de documentacin del usuario son tiles: la `Instruccion ', o `Tutorial ', estilo y la `Reference ' al estilo.
Mientras el estilo de la instruccin se orienta a ayudar a los nuevos usuarios, el estilo de la referencia
satisface ms a usuarios ms experimentados que necesitan la informacin sobre temas especficos.
En la seccin de la instruccin del MUS, el material se pide segn el camino de aprendizaje, desde
lo ms simple, operaciones mas necesarias que aparecen primero y operaciones ms avanzadas y
complicadas, que aparecen despus. El tamao de esta seccin depende del nmero de lectores intencional;
algunos usuarios pueden entender el software despus de unos ejemplos (y puede cambiar a usar la seccin de
la referencia) aunque otros usuarios pueden requerir que muchos ejemplos trabajados.
La seccin de la referencia del MUS presenta las operaciones bsicas, o referencia fcil (e.g. alfabticamente).
La documentacin de la referencia debe ser ms formal, rigurosa y exhaustiva que la seccin educacional. Por
ejemplo un comando se puede describir en la seccin de la instruccin en trminos concretos, con un ejemplo
trabajado especfico. La descripcin en la seccin de la referencia debe describir todos los parmetros,
calificadores y palabras claves, con varios ejemplos.
El desarrollo del MUS debe comenzar lo mas pronto posible. Establecer el nmero total de lectores
potenciales para el MUS debe ser el primer paso. Esta informacin es crtica para establecer el estilo del
documento. La informacin til se puede encontrar Caracteristicas del usuario de la seccin; en el URD
El manual de usuario del software puede ser grande, extendido por varios volmenes. el MUS puede hacerse
disponible electrnicamente, por ejemplo como parte de una facilidad en lnea de la ayuda. Debe haber
requisitos especficos del software para tales instalaciones.
5.4.4 plan de direccin de proyecto para la fase de TR
El plan de la gerencia para la fase del TR se debe documentar en la seccin de la fase de la DD del plan de la
gerencia de proyecto del software (SPMP/TR, ven la parte 2, captulo 2). Este plan puede tambin cubrir el
perodo hasta la aceptacin final.
5.4.5 plan de direccin de configuracin para la fase de TR
Los procedimientos de la fase del TR para la gerencia de la configuracin de los deliverables, en
el ambiente operacional, se deben documentar en el plan de la gerencia de la configuracin del software
(SCMP/TR, ven la parte 2, captulo 3).

5.4.6 especificacin de prueba de aceptacin

Deben documentarse planes de prueba de aceptacin, casos de la prueba y procedimientos de la
prueba en la Comprobacin del Software y Plan de Aprobacin (SVVP/AT, vea Parte 2, Captulo 4).
5.4.7 plan de conviccin de calidad para la fase de TR
La calidad de la fase del TR que supervisa procedimientos se debe definir en la seccin de la fase del TR del
plan de la garanta de calidad del software (SQAP/TR, 2, captulo 5).

CAPTULO 6: LA FASE DEL TRASLADO

6.1 INTRODUCCIN
La fase del TR se puede llamar fase de retocado del ciclo vital. El propsito de la fase del TR es instalar el
software en el ambiente operacional y demostrar al iniciador y a los usuarios que el software tiene todas las
capacidades descritas en el documento de las exigencias del consumidor (URD).
La instalacin y la comprobacin del software es la responsabilidad del diseador. Los representantes de
usuarios y del personal de las operaciones participarn en pruebas de aceptacin. El comit examinador del
software (SRB) repasar el funcionamiento de software en las pruebas de aceptacin y lo recomendar, al
iniciador, si el software se puede aceptar provisional o no.
La salida principal de esta fase es el documento de la transferencia del software (STD), que documenta las
actividades de la prueba de aceptacin
La fase de TR termina con la aceptacin provisional del software y el comienzo de las operaciones.

6.2 ENTRADAS A LA FASE

Las entradas a la fase de TR son el:
" el cdigo;
" Documento del diseo detallado (DDD);
" El Manual de Usuario de software (la SUMA);
" La especificacin de Prueba de aceptacin (SVVP/AT).

Plan de la gerencia de proyecto del software para la fase del TR

(SPMP/TR);
Plan de la gerencia de la configuracin del software para la fase
del TR (SCMP/TR);
Plan de la garanta de calidad del software para la fase del TR
(SQAP/TR).

6.3 ACTIVIDADES
Las actividades de la fase del TR sern realizadas segn los planes definidos en la fase de la DD.
6.3.1 instalacin
La primera actividad de la fase del TR es instalacin del software. Esto se hace por:
" verificando el deliverables contra la lista de artculo de configuracin;
" construyendo un sistema ejecutable en el ambiente designado.
Los procedimientos por construir el software pueden variar, mientras dependiendo del tipo de
software, pero la capacidad de construir el sistema de los componentes que son directamente los modifiable
por el equipo de mantenimiento se establecern. El personal de mantenimiento debe ejercer los
procedimientos por modificar el software, sobre todo si cualquier herramienta de desarrollo de software poco
familiar se ha proporcionado.

6.3.2 aceptacin prueba

Las pruebas de aceptacin validan el software, es decir ellos demuestran las capacidades del
software en su ambiente operacional. Las pruebas de aceptacin deben ser basadas en los requisitos del
usuario, como declarado en el URD. La aceptacin prueba se definen planes, planes de la prueba, casos de la
prueba y procedimientos de la prueba en el SVVP. Se ejecutan las pruebas de aceptacin en la fase de TR y
los resultados grabaron en el SVVP. Un resumen de los informes de prueba de aceptacin debe insertarse en el
STD.
6.3.3 Aceptacin Provisional
La prueba de aceptacin es necesaria para la aceptacin provisional que se indicar en el SVVP. El criterio
para la aceptacin provisional es si el software est listo para el uso operacional. En un periodo de
funcionamiento se exige mostrar que el software rene todos los requisitos en el URD.

La decisin de aprobacin provisional se debe tomar por el iniciador despus de consultas con el SRB,
representantes del usuario final y el personal de operaciones.

6.4 SALIDAS DE LA FASE

6.4.1 Declaracin de la aprobacin provisional
La declaracin de la aprobacin provisional ser producida por el iniciador, a nombre de los usuarios, y
enviada al desarrolador. La aprobacin provisional marca el final de la fase TR.

6.4.2 Sistema de software provisional aceptado

El sistema de software provisional aceptado consistir en las salidas de todas las fases y modificaciones
anteriores encontradas necesarias en la fase TR.

6.4.3 Documento De Transferencia Del Software

El propsito del documento de transferencia del software (STD) es identificar el software que se est
transfiriendo y cmo construirlo e instalarlo. Una salida de la fase del TR ser el STD. El STD ser entregado
del desarrollador a la mantencin de la organizacion en la aprobacin provisional. La tabla de contenido
recomendada para el STD se presenta en el apndice C.

El STD contendr un resumen de los informes de prueba de aprobacin y de toda la documentacin sobre los
cambios de software realizados durante la fase del TR.

En esta pgina se deja intencionalmente el espacio en blanco

CAPTULO 7: LAS OPERACIONES Y LA FASE DEL

MANTENIMIENTO

7,1 INTRODUCCIN

En la fase OM, el software primero incorpora un uso prctico. La operacin del software est ms all del
alcance de estos estndares, as que este captulo discute solamente mantenimiento.
El propsito del mantenimiento del software es asegurarse que el producto contina resolviendo las
necesidades verdaderas del usuario final. Los recursos disponibles para mantenimiento deberan reflejar la
importancia del producto.
A diferencia del mantenimiento del hardware, que apunta a devolver un producto de hardware a su estado
original, el mantenimiento del software da lugar siempre a un cambio a un producto de software. El equipo de
mantenimiento del software debe entender a fondo el software que tiene que alterar. Para ello el
entrenamiento puede ser necesario.
La salida principal de esta fase es el documento de historia del proyecto (PHD), que resume el desarrollo, las
operaciones y el mantenimiento del producto.

7,2 ENTRADAS A LA FASE

Las entradas a la fase OM son:

Declaracin de aprobacin provisional;

Sistema de software provisionalmente aceptado;
Documento de transferencia del Software.

7,3 ACTIVIDADES

Hasta la aprobacin final, las actividades de la fase OM que implican al desarrollador sern realizadas segn
los planes definidos en el SPMP/TR.
La organizacin del mantenimiento puede elegir adoptar el plan administrativo de configuracin del software
usado en las fases de desarrollo. Pueden elegir alternativamente producir uno nuevo, especfico a sus
necesidades. El esfuerzo de convertir a partir de una configuracin de sistema administrativo a otro no
deberia ser subestimada, ni los riesgos implicados ignorados (e.g. la prdida de temes de configuracin o
incorrecto anexo de etiquetas).
Los planes de administracin de proyecto de software y los planes de seguridad de calidad de software
continan aplicndose a las actividades del equipo de desarrollo, pero no a las operaciones y al personal de
mantenimiento, que debe desarrollar sus propios planes.

7,3,1 Aprobacin Final

La parte anterior de la fase OM debe incluir un perodo de garanta en el cual el desarrollador deba mantener
la responsabilidad de corregir errores. El final del perodo de la garanta es marcado por la aprobacin final.
El criterio para la aprobacin final es si el software resuelve todos los requisitos indicados en el URD. Todas
la pruebas de aceptacin debern haber sido terminadas con xito antes de que el software finalmente sea
aceptado.

La decisin de la aprobacin final se debe hecha por el iniciador despus de consultas con el SRB, los
representantes del usuario final y el equipo operacional. Incluso cuando no hay contratista implicado, habr
una milesima a arreglar para la aprobacin final para la entrega formal del desarrollo de software a
mantenimiento.

Siempre que se realice la entrega, el ultimo documento formalmente entregado por el lder de proyecto de la
ingeniera (en comparacin con mantenimiento), debe ser el primer tema en el documento de historia del
proyecto (PHD).
7,3,2 Mantenimiento

Despus de este perodo de garanta, el mantenimiento del software se puede transferir del desarrollador a una
organizacin dedicada del mantenimiento. Una organizacin de mantenimiento ser designada para cada
producto de software en uso operacional. Los recursos sern asignados al mantenimiento de productos hasta
que se retiran.

El mantenimiento de software se debe atender por la ocurrencia de problemas y nuevos requisitos. El SRB
controla problemas manejando actividades, y autorizar todas las modificaciones. La responsabilidad de
modificaciones y de cambios de menor emergencia se puede delegar al personal de mantenimiento,
dependiendo del nivel de criticidad.
Los procedimientos para la modificacin del software sern definidos. Esto es normalmente hecho llevado a
cabo los procedimientos de la gerencia y de la verificacin de configuracin a partir de la fase del desarrollo.
La consistencia entre el cdigo y documentacin ser mantenida.
Algunos problemas del Software pueden dar lugar a nuevos requisitos. Un usuario, despus de la experiencia
con el software, puede proponer una modificacin (en un SPR). El SRB, clasificando el problema como
nuevo o cambiando los requisitos, bosqueja los cambios al URD y realiza revisiones l, con los usuarios
involucrados. Los usuarios pueden tambin bosquejar los cambios al URD y ponerlo adelante al SRB.
Los nuevos requisitos tambin pueden presentarse porque los requisitos originales definidos en las fases de
UR y del SR no eran apropiados, o porque las necesidades del usuario cambian. El presupuesto de
mantenimiento debe apoyar un nivel realista de actividad del cambio de requisito. Los nuevos requisitos
importantes se deben manejar como proyecto separado del desarrollo del software, y que se presupuesten por
separado.
Los usuarios deben estar informados de los problemas. Si es posible, los artculos que son el tema de los
informes del problema se deben retirar de uso, mientras que se corrige el problema. Cuando el retiro no es
posible, se permiten las soluciones temporales del trabajo, proporcionado la seguridad del sistema para que no
se daen. Todas las modificaciones del software se deben documentar, incluso los informes temporales.
Cuando se cambia el software, las pruebas de la regresin se deben realizar para asegurar que el cambio no
ha causado nuevas fallas. Los casos de prueba de regresin pueden ser un subconjunto de los casos de
prueba de aceptacin.

7.4 RENDIMIENTO DE LA FASE

7.4.1

Declaracin de la aceptacin final

La declaracin de la aceptacin final ser producida por el iniciador, a nombre de los usuarios, y enviada al
diseador. Su entrega marca el handover formal del software. La condicin previa de la aceptacin final es
que todas las pruebas de aceptacin se han ejecutado satisfactoriamente.
7.4.2

Documento De la Historia Del Proyecto

El documento de la historia del proyecto (PHD) se debe elaborar por el encargado del proyecto de software.
Resume los acontecimientos principales y el resultado del proyecto. El PHD es til a los proyectos futuros
para:

estimando el esfuerzo requerido;

preparando la organizacin;
encontrando mtodos acertados;
aconsejando sobre los problemas y trampas.

El PHD es el lugar en donde las estimaciones, hechas en las etapas de planificacin, se comparan con
acontecimientos reales. La exactitud de las predicciones del horario del proyecto, del volumen del software,
de los requisitos de la mano de obra, de los requisitos y del costo deben ser medidas. La productividad se
debe estimar usando las medidas de volumen del software y tiempo.
La preparacin del PHD obliga a los encargados del proyecto a considerar el progreso cuidadosamente, y
dibujar conclusiones personales y de organizacin, cuando los acontecimientos involucrados estn frescos en
la mente del encargado del proyecto. Por consiguiente, el encargado del proyecto debe comenzar a hacer las
notas para el PHD al principio del proyecto. Al final de cada fase, los planes hechos para la fase anterior
deben ser comparados con lo qu realmente sucedi. Este conocimiento tambin puede ayudar a planear la
prxima fase.
El PHD ser entregado al iniciador despus de la aceptacin final, que debe ponerlo a disposicin de la
organizacin del mantenimiento. El captulo que describe el funcionamiento del sistema debe ser agregado
por la organizacin sealada del mantenimiento durante la fase de OM y ser puesto al da cuando se retira el
producto. El contenido recomendado para el PHD se presenta en el apndice C.
7.4.3

Sistema de software finalmente aceptado

Esto consiste en uno o ms sistemas de documentacin , de fuente, del objeto y del cdigo ejecutable que
corresponde a las versiones actuales y descargas del producto.

PARTE 2: PROCEDIMIENTO ESTANDAR

Actividades
Plan

Gerencia
Proyecto
Software

revisin
de
las
exigencias
del
consumidor
Actividad
Salida
de -Estimacin SPMP/SR
de
del costo del Pg. 77 y
44

proyecto
-fase WBS y el
proveer
de
personal
del
SR del plan
-plan
del
entorno para el
proyecto del
wholw
los
gerencia de la defina
procedimientos
configuracin
de la fase del
del software
SR para:
-documentos
-caso
de
herramientas
-cdigo
del
prototipo
los
verificacin y -defina
validacin del procedimientos
de la revisin y
software
de la fase del
SR
-pruebas
de
aceptacin de
los test

garanta
calidad
software

definicin
de
los diseo arquitectnico
requisitos del software

diseo
y
detallados

Actividad

Actividad

Salida

Actividad

Salida

-El proyecto de SPMP/AD -El proyecto de SPMP/DD -Detalle DD en

estimacin
estimacin
la faseWBS
cost hasta la Pg. 77 y cost hasta la Pg. 77 y -plan TR en la
exactitud del 44
exactitud del 44
fase WBS y de
30%
10%
personal
-plan AD en la
-plan DD en la
fase WBS y
fase WBS y
de personal
de personal

SCMP/SR defina
los
procedimientos
Pg. 78 y de la fase AD
51
para:
-documentos
-caso
de
herramientas
-cdigo
del
prototipo
SVVP/SR -defina
los
Pg.79
procedimientos
de la revisin y
SVVP/AT de la fase del
Pg. 57
AD
-pruebas
del
plan de sistema

SCMP/AD defina
los
procedimientos
Pg. 78 y de la fase DD
51
para:
-documentos
-caso
de
herramientas
-cdigo
del
prototipo
SVVP/AD -defina
los
Pg.79
procedimientos
de la revisin y
SVVP/ST de la fase del
Pg. 57
DD
-pruebas
de
integracin de
test.

produccin
Salida
Actualizaciones
SPMP/Dd
SPMP/TR
Pg.77y 47

SCMP/DD defina
los SCMP/TR
procedimientos
Pg. 78 y operacionales Pg. 78 y 51
51
del ambiente
para:
-documentos
cdigo
entregable
SVVP/DD -Defina test de
Pg.79
aceptacin,
integracin de
SVVP/IT sistemas
Pg. 57
- planee y
defina
las
pruebas
de
unidad

Actualizaciones
SVVP/AT
Actualizaciones
SVVP/ST
Actualizaciones
SVVP/UT
Pg. 79/57

de -fase del SR SQAP/SR Plan AD en la SQAP/AD Plan DD en la SQAP/DD Plan TR en la SQAP/TR

fase
de
fase
de
fase
de
del del plan que
supervisa
Pg. 81 y monitorear
actividades
62
actividades
-plan
del
entorno para
todo
el
proyecto

Pg. 81 y monitorear
62
actividades

Pg. 81 y monitorear
62
actividades

Pg. 81 y 62

CAPTULO 1: LA DIRECCIN DEL CICLO DE VIDA DE SOFTWARE

1.1 INTRODUCCIN
Parta 2 de estas normas describe las actividades que son esencial para manejar el ciclo de vida de
software. Considerando que Parte 1 describe las actividades y productos de cada fase del ciclo de vida, Parta
2 discute actividades de direccin que se realizan a lo largo de todas las fases de desarrollo.
La meta de las actividades de direccin es construir el producto dentro del presupuesto, segn el
horario, con la calidad requerida. Para lograr esto, planea debe establecerse para:
" la direccin de proyecto de software;
" la direccin de configuracin de software;
" la comprobacin del software y aprobacin;
" la conviccin de calidad de software.
Figure 1.1 que resume cmo estos planes deben documentarse. Los planes para la direccin del
proyecto, la direccin de la configuracin, verification,n y conviccin de calidad son hendido en las
secciones. Cada seccin planea las actividades para las fases subsecuentes. Mientras la misma estructura
puede repetirse en cada seccin de un documento, los volmenes reales pueden variar. Los ttulos de
documentos estn separados de sus nombres de la seccin por ` / ' (por ejemplo SPMP/SR es los SR escalonan
seccin del Software Proyecto Direccin Plan).
Figure 1.1 no incluya los planes exigieron manejar el mantenimiento del software en el periodo
entre ltimo aceptacin y jubilacin. Los organisation de mantenimiento pueden escoger reusar el desarrollo
planea o produce los nuevos planes.

1.2 DIRECCIN DE PROYECTO DE SOFTWARE

Gerente del proyecto, o equipo de direccin de proyecto, tiene al plan, personal, amonestador,
mando y primaca un proyecto del software. El gerente del proyecto es responsable para escribir la Direccin
de Proyecto de Software

El plan (SPMP). El gerente del proyecto lleva el desarrollo unza y es

el punto principal de contacto entre ellos y el iniciador,
los extremo-usuarios y otras fiestas.

1.3 DIRECCIN DE CONFIGURACIN DE SOFTWARE

La direccin de la configuracin apropiada es esencial para el mando de un producto del software.
Un componente puede funcionar absolutamente bien, pero o una falta en integracin o un error en la
identificacin puede producir los errores oscuros. Esta norma define los requisitos por identificar, mientras
controlando, soltando y los artculos del software cambiantes y grabando su estado. Deben definirse
procedimientos por manejar la configuracin del software en el Software Configuracin Direccin Plan
(SCMP).

1.4 COMPROBACIN DEL SOFTWARE Y APROBACIN

Estas normas adoptan la definicin de ANSI/IEEE general de comprobacin como el proceso de
repasar, mientras inspeccionando, probando, mientras interviniendo y repasando los productos del software.
La comprobacin es esencial asegurar que el producto se encajar para su propsito.
El acercamiento de la comprobacin debe planearse por la direccin del proyecto y debe llevarse a
cabo por el personal de desarrollo.
En estas normas, `Validation ' es la evaluacin de software al final del proceso de desarrollo
asegurar la complacencia con los requisitos del usuario. Se hace la aprobacin en la fase de TR.
Deben documentarse toda la comprobacin y actividades de aprobacin en la Comprobacin del
Software y Plan de Aprobacin (SVVP).

1.5 CONVICCIN DE CALIDAD DE SOFTWARE

La actividad de conviccin de calidad es el proceso de verificar que estas normas estn siendo
aplicadas. En pequeo proyecta esto se hace por el gerente del proyecto, pero en los proyectos grandes el
personal especfico debe asignarse al papel. El Software Calidad Conviccin Plan es el documento que
describe cmo la adhesin a las Normas ser verificada.
Donde los ESA PSS-01-serie documentos son aplicables, y como una consecuencia ESA PSS-0121, `Software Producto Conviccin Requisitos para ESA Sistemas Espaciales tambin es aplicable, Parta 2,
Captulo 5 de estas Normas, la Calidad de `Software Assurance', deja de aplicar.

CAPTULO 2: LA DIRECCIN DE PROYECTO DE SOFTWARE

2.1 INTRODUCCIN
La Direccin de Proyecto de software (SPM) es `The procesan de planear, el organising,
proveyendo de personal, supervisando, mientras controlando y llevando un project' del software (ANSI/IEEE
Std 1058.1-1987). El Software Proyecto Direccin Plan (SPMP) es el documento controlando por manejar un
proyecto del software. El SPMP define las funciones del proyecto tcnicas y directivas, actividades y tareas
necesario satisfacer los requisitos de un proyecto del software.
El SPMP es actualizado y refinado, a travs del ciclo de vida, como estimaciones ms exactas y siempre que
ocurren los cambios en requisitos o diseo. Un nmero de mtodos y de herramientas estn disponibles para
el planeamiento del proyecto del software y se recomienda su uso.
Durante todas las fases del ciclo de vida, la direccin del proyecto debe repasar cmo un plan se resuelve en
la prctica. Las desviaciones importantes entre las estimaciones y las actuales tienen que ser explicadas y ser
documentadas en el documento de la historia del proyecto (PHD), que se publica en la fase de OM.

2.2 ACTIVIDADES
2.2.1

Organizacin del proyecto

Una responsabilidad importante de la direccin del proyecto de software est organizando todas las
actividades del proyecto. Hay varios modelos posibles para la organizacin de un proyecto del software (e.g.
funcional y matriz).
Una vez que se hayan definido las tareas, la direccin del proyecto debe definir la estructura del equipo para
llevarlas a cabo. Las posiciones en esa estructura deben ser definidas adecuadamente de modo que cada
miembro del equipo tenga responsabilidades y lneas de autoridad claras. Estas responsabilidades se deben
documentar en trminos de las descripciones del paquete de la referencia y del trabajo.
2.2.2

Conducir el proyecto

La direccin del proyecto decide los objetivos y las prioridades en cada etapa. Deben
documentar las asunciones, las dependencias y los apremios que influencian sus decisiones
en el SPMP.
2.2.3

Direccin de riesgo

Los riesgos amenazan el xito de un proyecto. La direccin del proyecto debe identificar los riesgos de un
proyecto y determinar la amenaza que plantean. Esto se llama anlisis del riesgo. Los ejemplos de las reas
potenciales del riesgo son:
- la calidad y estabilidad de requisitos de usuario;
- nivelado de definicin y estabilidad de interfaces externas;
- la suficiencia y disponibilidad de recursos;
- la disponibilidad y calidad de herramientas;
- personal que entrena y experimenta;
- la definicin de responsabilidades;
- las balanzas de tiempo
- la novedad tcnica del proyecto.
La direccin del proyecto debe idear un plan para reducir niveles de riesgo y asegurarse de que la realizan.
Los logros deben ser medidos y los riesgos deben ser reevaluados a travs del proyecto.
Las decisiones sobre prioridades se deben apoyar por anlisis de riesgo. El gravamen exacto del impacto de
decisiones confa en la valoracin cuantitativa de los factores que deben cambiar cuando se toma la accin.
2.2.4 direccin tcnica
Hay muchos mtodos y herramientas que se pueden aplicar a travs del ciclo de vida del software, que puede
realzar grandemente la calidad del producto final y su uso es recomendable. La direccin del proyecto es
responsable de seleccionar mtodos y las herramientas, y de hacer cumplir su uso.
La direccin tcnica incluye la direccin de la organizacin de la configuracin del software, y actividades de
la verificacin, de la validacin y de la prueba.

2.2.5 planificacin, programacin y presupuesto del trabajo

Estimar los recursos y escala de tiempo requeridos para las actividades es una parte dominante de planear su
ejecucin. El acercamiento bsico a la valoracin es analizar el proyecto en las tareas que son bastante
pequeas para que sus costes sean evaluados fcilmente y exactamente. Las estimaciones para escala de
tiempo y los recursos para el proyecto entero entonces se sintetizan de las estimaciones para las tareas
individuales. Cada tarea se debe ligar a una parte apropiada para esa fase. Por ejemplo, las tareas en la fase
del SR se pudieron basar en requisitos, mientras que en la fase del ANUNCIO puede ser que sean basadas en
componentes. Tradicionalmente, las estimaciones para el diseo detallado y la produccin se han basado en
lneas del cdigo.
Otros factores que afectan las estimaciones son la experiencia del equipo de desarrollo, la novedad del rea
tcnica y la disponibilidad de las herramientas de la tecnologa de dotacin lgica.
La estructura de la interrupcin de trabajo (WBS) es una de las herramientas fundamentales para el
planeamiento y el control de las actividades del proyecto. El WBS describe la jerarqua de las tareas
(agrupadas en los paquetes del trabajo) de ser realizado en un proyecto. El WBS corresponde a la estructura
del trabajo que se realizar, y refleja la manera en la cual los costes del proyecto sern resumidos y
divulgados.
Un paquete de trabajo define un sistema de tareas para ser realizado en un proyecto. Las descripciones del
paquete del trabajo deben definir tareas con suficiente detalle para permitir que los individuos, o grupos de
gente pequeos, trabajen independientemente del resto del proyecto. Las fechas del comienzo y del final de
un paquete del trabajo deben ser especificadas. La duracin de un paquete orientado al producto de trabajo
debe ser suficientemente breve para mantener la visibilidad del proceso de produccin (e.g. un mes en la fase
de la DD). Los paquetes de procedimiento orientado del trabajo, por ejemplo direccin de proyecto, se
pueden extender a lo largo del proyecto entero.
El horario de trabajo debe demostrar cuando los paquetes del trabajo deben ser comenzados y ser acabados.
Un mapa del hito demuestra los acontecimientos dominantes en el proyecto; stos se deben relacionar con las
fechas de la terminacin del paquete de trabajo.
Una estimacin del coste del proyecto entero se debe incluir en la seccin de la fase del SR de la definicin de
SPMP. La definicin pendiente de los requisitos del software y el diseo, ser difcil proporcionar
estimaciones exactas. Los costes reales de proyectos similares ayudan en la fabricacin de estimaciones
iniciales.
Los modelos del coste se pueden utilizar para estimar el tiempo requerido para el diseo y la produccin
detallada. La consideracin cuidadosa se debe dar a la aplicabilidad de cualquier modelo del coste. Los
valores de parmetro atribuidos en la fabricacin de una estimacin del modelo del coste deben ser
documentados claramente.
2.2.6

Divulgacin de progreso del proyecto

La divulgacin del proyecto es esencial para el control apropiado de un proyecto de software. Realizado por
la direccin del proyecto, proporciona la visibilidad de la actividad del desarrollo en los intervalos regulares
durante el proyecto. Los informes son necesarios para asegurar a la gente fuera del equipo del desarrollo que
est procediendo el proyecto satisfactoriamente.

La gerencia de proyecto debe asegurar de que el material presentado en las revisiones del progreso sea
suficientemente detallado, y en un formato constante que permita al PHD ser compilado los datos del
progreso y revisin.

Los contratos para la consecucin del software deben requerir que los datos del progreso estn recogidos y los
informes sobre la marcha de los trabajos estn generados durante el desarrollo. Cuando es necesario mantener
la informacin confidencial entre el ESA y el contratista, los informes sobre la marcha de los trabajos y el
PHD se pueden marcar ' para el uso del ESA solamente '.

2.3

EL PLAN GERENCIAL DE PROYECTO DE SOFTWARE

Todas las actividades gerenciales de proyecto de software sern documentadas en el plan gerencial de
proyecto de software (SPMP). El SPMP es el documento que controla el manejo de un proyecto de
software. El SPMP se divide en cuatro secciones que contienen los planes de la gerencia para las fases
del SR, AD, de DD y del TR. El contenido para cada seccin del SPMP se describe en el apndice C.
Este contenido se deriva del estndar de IEEE para los planes de la gerencia de proyecto del software
(IEEE Std 1058,1-1987).

2.3

EVOLUCIN DEL SPMP A TRAVS DEL CICLO DE VIDA

2.4.1 Fase UR
Para el final de la revisin de UR, la seccin de la fase del SR del SPMP ser producida (SPMP/SR). El
SPMP/SR describe, detalladamente, las actividades del proyecto que se realizarn en la fase del SR. Como
parte de su introduccin, el SPMP/SR contornear un plan para el proyecto entero.
Un clculo aproximado del costo total del proyecto del software se debe incluir en el conocimiento tcnico de
SPMP/SR. y la experiencia ganada en proyectos similares debe ser utilizada en llegar la valoracin de costos.
Una estimacin exacta del esfuerzo implicado en la fase del SR ser incluida en el SPMP/SR. que los factores
especficos que afectan las estimaciones para el trabajo requerido en la fase del SR son:

nmero de las requerimientos del consumidor;

nivel de las requerimientos del consumidor;
estabilidad de las requerimientos del consumidor;
nivel de la definicin de interfaces externas;
calidad del URD.

Una estimacin basada simplemente en el nmero de los requerimientos del consumidor pude ser muy
engaosa - una gran cantidad de requerimientos detallados por un usuario baja pudieron ser ms tiles, y
ahorrar ms tiempo en la fase del SR, que algunas exigencias del usuario de alto nivel. Una mal calidad URD
pudo implicar que los muchos de anlisis de requerimientos estn requeridos en la fase del SR.
2.4.2 Fase SR
Durante la fase del SR, la seccin de la fase AD del SPMP ser producida (SPMP/AD). El SPMP/AD
describe, detalladamente, las actividades del proyecto que se realizarn en la fase del AD.
Una estimacin del costo total del proyecto ser incluida en el SPMP/AD. Cada esfuerzo se debe hacer para
llegar las estimaciones con una exactitud mejor el de 30%. El conocimiento tcnico y la experiencia ganada
en proyectos similares deben ser utilizados en llegar una estimacin del costo total del proyecto.

Cuando no existen proyectos similares, puede ser til construir un prototipo, para conseguir una idea ms
exacta de la complejidad del software. Las actividades de Prototipado se deben planear correctamente y
racionalmente.
Una estimacin exacta del esfuerzo implicado en la fase de AD ser incluida en el SPMP/AD. Los factores
especficos que afectan las estimaciones para el trabajo requerido en la fase AD son:

nmero de requerimientos del software;

nivel de los requerimientos del software;
estabilidad de los requerimientos del software;
nivel de la definicin de interfaces externas;
calidad del SRD.

Si se va a un acercamiento evolutivo del ciclo de vida del desarrollo a ser utilizado, entonces esto se debe
indicar en el SPMP/AD

2.4.3

Fase AD.

Durante la fase de AD, la seccin de la fase de la DD del SPMP ser producida (SPMP/DD). El
SPMP/DD describe, detalladamente, las actividades del proyecto que se realizarn en la fase de la DD.
Una estimacin del costo total del proyecto ser incluida en el SPMP/DD. Una exactitud de el 10%
debe ser dirigida. El nmero de lneas del cdigo se debe estimar para cada componente de software. Esto se
debe utilizar para estimar el tiempo requerido para escribir el software, y por lo tanto su costo.
El SPMP/DD contendr un WBS que se relacione directamente con la descomposicin del software
en componentes.
El SPMP/DD contendr una red del planeamiento que demuestra relaciones de las actividades de la
codificacin, de la integracin y de las pruebas. Las herramientas estn disponibles para esta clase de
planeamiento.
2.4.4

Fase DD

Como el trabajo de diseo detallado procede a niveles ms bajos, al WBS y a la necesidad del
horario del trabajo de ser refinado para reflejar esto. Para alcanzar el nivel necesario de la visibilidad, algunos
paquetes del trabajo de la produccin del software en el SPMP/DD durarn ms de 1 mes laboral.
Durante la fase de la DD, la seccin de la fase del TR del SPMP ser producida (SPMP/TR). El
SPMP/TR describe, detalladamente, actividades del proyecto hasta la aceptacin final, en la fase de OM.

CAPTULO 3 ADMINISTRACIN DE LA CONFIGURACIN DEL

SOFTWARE
3.1 INTRODUCCIN
Definido en ANSI/IEEE Std 729-1983, la administracin de la configuracin del software es:
Procesos de identificacin y definicin de los tems de configuracin en un sistema;
Controlando la publicacin y cambiando esos tems a travs del ciclo de vida del sistema;
Grabando y reportando el estado de los tems de configuracin y cambiando requeridos;
Verificando la completa y correcta configuracin de tems.
la administracin de la configuracin del software son ambos una administracin y una actividad tcnica, y es
esencialmente para mejorar el control de calidad del software. Las actividades de la administracin de la
configuracin del software para un proyecto podran ser definidos en el Plan de administracin de la
configuracin del software (SCMP)
Todos los tems del software, por ejemplo documentacin, cdigo fuente, cdigo ejecutable, archivos,
herramientas, pruebas de software y de datos, podran ser sujetos a los procedimientos de la administracin de
la configuracin. Los procedimientos de la administracin de la configuracin podran establecer mtodos
para identificarlos, tems cambiantes del software a travs del desarrollo, integracin y transferencia. En
grandes desarrollos, dispersar a travs de mltiples plataformas de hardware, procedimientos de
administracin de la configuracin podran diferir en detalles fsicos. Sin embargo, un conjunto comn de
procedimientos de administracin podran ser usados.
Herramientas para los procedimientos de la administracin del software estn ampliamente disponibles. Su
uso es fuertemente recomendado para asegurar que los procedimientos SCM son aplicados consistente y
eficientemente.

3.2 ACTIVIDADES
3.2.1 identificacin de la configuracin
Un tem de Configuracin (CI) es una coleccin de elementos del software, tratada como una
unidad, con el propsito de configurar la esta direccin. Varios factores pueden ser pertinentes decidiendo
dnde dibujar los lmites de un artculo de la configuracin. Un artculo de configuracin puede ser cualquier
artculo del software, por ejemplo,: un mdulo, un documento, o un juego de CIs.
La clave de la configuracin de la direccin de software eficaz es la identificacin inequvoca de
las partes del software. Cada artculo de la configuracin tendr un identificador que lo distingue de otros
artculos con las siguientes diferencias:
" los requisitos, sobre todo la funcionalidad e interfaces,;
" la aplicacin.
Cada componente definido en el proceso del plan se designar como un CI y poseer un
identificador. El identificador incluir un nmero o un nombre relacionado al propsito del CI. El
identificador incluir una indicacin del tipo de proceso de CI (por ejemplo la informacin del tipo de
archivo.).

El trmino `Versin ' se usa para definir una fase en la evolucin de un CI. Cada fase es marcada
por un numero de versin. Cuando el CI cambia, el nmero de versin cambia. El identificador de un CI
incluir un nmero de la versin.
El identificador de documentos incluir un nmero del problema y un nmero de la revisin. Se
usan los nmeros del problema para marcar cambios mayores y nmeros de la revisin se usa para marcar los
cambios menores. Los cambios mayores normalmente requieren la aprobacin formal. El nmero del
problema y nmero de la revisin juntos marcan la versin del documento.
El mtodo de identificacin de configuracin ser capaz de acomodar nuevo CIs, sin requerir la
modificacin de los identificadores de cualquier CIs existente.
Una Lnea de Fondo es un documento o un producto que se ha revisado formalmente, y es una
base para un desarrollo extenso. Una lnea de fondo es un ensamble de artculos de configuracin. Los
cambios formales de control son requeridos para modificar una Lnea de fondo.
La integracin de software debe coordinarse para la identificacin y control de lneas de fondo. La
figura 3.2.1 ilustra la relacin entre las unidades de mdulos, lneas de fondo y descargos.
Los mdulos, despus de una prueba de unidad exitosa, son integradas en lneas de fondo existentes.
La incorporacin en una lnea de fondo slo puede ocurrir despus de las pruebas de integracin exitosa. Las
lneas de fondo deben ser sistemas probados antes de que se transfiriera a los usuarios como un `Lanzamiento
' del software. Despus de la entrega e instalacin, los descargos del software sufren aceptacin que aprueban
los usuarios.

Figure 3.2.1: las Lneas de fondo y descargos

(Disponible slo en la copia dura)

En la fase TR, una lista de artculos de configuracin en el primer descargo ser incluida en el
STD. En la fase OM, una lista de artculos de configuracin cambiados ser incluida en cada Nota de
Descargo de Software (SRN). Un SRN acompaar cada descargo hecho en la fase de OM.
Como la parte del mtodo de identificacin de configuracin, un mdulo tendr un ttulo que
incluye:

El identificador de artculo de configuracin (el nombre, tipo, versin);

el autor original;
la fecha de creacin;
la historia de cambio (versin/fecha/autor/descripcin);

La nota que un ttulo de mdulo tambin puede contener otra informacin del componente del
DDD, Parta 2.
Toda la documentacin y medios de comunicacin de almacenamiento sern claramente los
etiquetados en un formato normal, con por lo menos los datos siguientes,:

el nombre del proyecto;

el identificador de artculo de configuracin (nombre, tipo, versin);
la fecha;
la descripcin del contenido.

3.2.2 almacenamiento de artculo de configuracin

Una biblioteca de software es una coleccin controlada de artculos de configuracin. Puede ser un
solo archivo o una coleccin de archivos. Una biblioteca puede existir en varios medios de comunicacin
(por ejemplo papel, disco magntico).
Asegurar el control y seguridad del software, como mnimo, las bibliotecas de software siguientes
se llevarn a cabo para guardar todos los componentes entregables (por ejemplo la documentacin, la fuente y
el cdigo ejecutable, los archivos de la prueba y procedimientos de comando):

El desarrollo (o Dinmico) la biblioteca;

Amo (o Controlado) la biblioteca;
La esttica (o Archivo) la biblioteca.

Las herramientas para ocuparse de bibliotecas de software son esenciales para el mando eficaz de
la configuracin. Las tales herramientas deben permitir identificacin de CI, seguimiento de cambio, y CI
referencia cruzada.
El software es codificado y probado como un juego de mdulos en la biblioteca de desarrollo.
Despus de que las pruebas de unidad, se transfieren los mdulos para dominar las bibliotecas para la prueba
de integracin y comprobacin del sistema. Cuando los cambios para dominar los mdulos de la biblioteca
son necesarios, los mdulos apropiados son transferidos de vuelta a una biblioteca de desarrollo de la
biblioteca maestra.
Una lnea de fondo incluye un juego de bibliotecas maestra. Cuando una lnea de fondo se suelta,
deben hacerse copias de todas las bibliotecas maestras. Estas copias, llamadas bibliotecas estticas, no se
modificarn.
Hoy en da las copias de seguridad de las bibliotecas estticas siempre estan disponibles. Se
establecern procedimientos para el apoyo regular de bibliotecas de desarrollo. Esto se llama el control de
medios.
3.2.3 Configuracin de cambios de control
El software de control de configuracin es el proceso de evaluar los cambios propuestos a los
artculos de configuracin y coordinar la aplicacin de cambios aprobados. El mando de configuracin de
software de un artculo slo puede ocurrir despus del establecimiento formal de su identificacin, de la
configuracin e inclusin en una lnea de fondo. Las demandas de control de software de configuracin se
definen por:

El nivel de autoridad requerido para cambiar cada CI;

Los mtodos para ocuparse de de propuestas para cambiar cualquier CI.

Al nivel de la cima, el proceso de control de configuracin de software identifica los

procedimientos para manejar cambios a las lneas base conocidas.
Adems, la direccin del proyecto tiene la responsabilidad para la organizacin de las actividades
de SCM, la definicin de roles de SCM (es decir controlan a la tabla y bibliotecario del software), y la
asignacin de personal a esos papeles. En las fases TR y OM de un proyecto del software, la ltima
responsabilidad para el control de configuracin de software miente con la Tabla de Revisin de Software
(SRB). El SRB debe componerse de miembros con la autoridad suficiente y especializacin para resolver
cualquier problema o no conformidades del software.

Cuando un item del software no conforma a su especificacin, debe identificarse como noconforme, y se sostiene para la accin de la revisin.
No conforme debe ser clasificado dependiendo de la menor o mayor en su severidad y por su urgencia.
Pueden procesarse los NO conforme menores a un nivel debajo de SRB. Dependiendo del tamao y la
estructura de administracin del desarrollo del software, una clasificacin extensa debe realizarse el ciclo de
vida de software, es decir contra los requisitos del usuario, requerimientos del software.
Cambios a las interfaces externas o a paquetes del software usados por el sistema deben manejarse
como los cambios a CIs ordinario.
3.2.3.1 niveles del control de cambio
Cuando un item de la configuracin pasa la prueba de unidad, integracin, sistema y la
aceptacin, un nivel ms alto de autoridad necesita aprobar los cambios. Esto se llama la promocin de un
CI. As como programadores firman fuera de la prueba de unidad, los lderes del equipo firman fuera de la
prueba de integracin, y los lderes del proyecto firman fuera de la prueba del sistema, para que la aprobacin
de cambio exige un nivel de autoridad que corresponde al estado de la comprobacin del CI.

3.2.3.2 procedimientos de control de cambio

Los cambios ocurren naturalmente en la evolucin del sistema del software. Esta evolucin debe
planearse y debe llevarse a cabo usando las bibliotecas del software controladas. Los cambios tambin
pueden ocurrir debido a los problemas en desarrollo o funcionamiento. Los cambios tales requieren retrasos
a travs del ciclo de vida para asegurar que las correcciones se llevan fuera con el mismo grado de mando de
calidad como se us para el desarrollo original. El nivel de autoridad para cada cambio depende de la parte a
ser cambiada, y en la fase por el ciclo de vida que se ha alcanzado.
3.2.3.2.1 procedimientos de cambio de documentacin
El procedimiento de cambio descrito debajo se observar cuando se necesitan los cambios a un
documento entregado.
1. un proyecto de un documento se produce y someti para la revisin. Si el documento no es nuevo,
todos los textos cambiados debern ser identificados.
2. Los crticos graban sus comentarios sobre el documento del proyecto en los formularios RID. Una
solucin recomendada puede insertarse en el formulario RID. Los RIDs se devuelven entonces al autor(es)
del documento.
3. el autor(es) del registro del documento responden sobre el formulario RID.
4. cada RID se procesa en una reunin de la revisin formal y una accin decidida (vea Seccin 4.2.1).
5. el documento del proyecto y el RID aceptado se usa para hacer la prxima revisin, o problema, o si
existen cambios mayores, del documento.
6. cada revisin o problema de un documento deben acompaarse por un Registro de Cambio de
Documento (DCR) y una Hoja de Estado de Documento puesta al da (DSS).
Al extremo de la fase de TR, la reunin de la revisin formal es un UR/R, SR/R, AD/R o DD/R,
dependiendo del documento. En la fase de OM la revisin formal se dirige por el SRB. Las plantillas para los
formularios RID, DCR y DSS son proporcionados en el Apndice E.

3.2.3.2.2 Procedimientos que reportan problemas

Pueden informarse los problemas del software en cualquier fase por el ciclo de vida. Los problemas
pueden entrar en varias categoras segn el grado de regresin en el ciclo de vida.

Las categoras del problema son:

" error de funcionamiento;
" la documentacin del usuario no conforme para codificar;
" el cdigo no conforma para disear;
" el diseo no conforma a los requisitos;
" nuevo requisito o cambi los requisitos.
La seleccin de la categora del problema define la fase del ciclo de vida a que la accin correctivo
necesita empezar.
Problemas del software y propuestas de cambio que sern ocupadas por el procedimiento descrito
debajo. Este procedimiento de cambio exige sostener una revisin formal (vea Seccin 4.2.1).
1. Un Informe de Problema de Software (SPR) debe completarse para cada uno de los problemas
descubiertos, mientras se da toda la informacin sobre los sntomas, el ambiente operativo y el software bajo
la prueba. La evidencia, como las inscripciones de resultados, puede atarse. Un problema no existe
formalmente hasta que un SPR ha sido escrito.
2. El SPR se pasa a la Tabla de Revisin de Software (SRB) quin lo asignar a la autoridad pertinente para el
anlisis. Un formulario de cambio de requisito de Software (SCR) debe completarse para cada cambio del
requisito de sotftware. Esto describe los cambios requeridos e incluye una valoracin del costo e impactos del
horario.
3. la Tabla de Revisin de Software revisa cada SCR entonces y, si es apropiado, asigna a alguien para llevar a
cabo el cambio.
4. cada modificacin del software se documenta en detalle en un Informe de Modificacin de Software
(SMR), completar con los tem como:
" los cambios de cdigo de fuente;
" los informes de la prueba;
" los cambios de la documentacin;
" los informes de la comprobacin.
Las plantillas de los formularios SPR, SCR SMR son dados en el Apndice E.

3.2.4 contabilidad de estado de configuracin

La contabilidad de estados de configuracin de software es el rastreo administrativo e informativo
de todos los artculos de la configuracin.
Se grabarn los estados de todos los tem de la configuracin.
La contabilidad de estado de configuracin contina, como haga todas las otras actividades de
direccin de configuracin, a lo largo del ciclo de vida.
Para realizar la contabilidad de estado de software, cada proyecto del software grabar el:
" la fecha y version/issue de cada bsico;
" la fecha y estados de cada uno LIBRARON y DCR;
" la fecha y estado de cada SPR, SCR y SMR;
" la descripcin sumaria de cada Artculo de la Configuracin.

Debe usarse informacin en las cuentas de estado de configuracin para generar los SRNs y listas
de CI que deben acompaar cada entrega de una lnea base del software.
3.2.5 descargo
El primer descargo del software debe documentarse en el STD. Los descargos subsecuentes de
software deben ser acompaados por una Nota de Descargo de Software (SRN) que la lista de CIs incluya en
el descargo, y los procedimientos por instalarlos, para que ello esta disponible (vea el Apndice E). Como un
mnimo, el SRN grabar las faltas que se han reparado y los nuevos requisitos que han estado incorporados.
Para cada descargo, la documentacin y cdigo ser consistente los descargos anteriores, para la
referencia. Donde posible, el descargo anterior debe guardarse en lnea durante un periodo cambioterminado, permitir las comparaciones, y como un fallback. Pueden archivarse los descargos ms viejos. El
nmero de descargos en el uso operacional a cuando quiera debe minimizarse.
Algunas formas de proteccin de software es deseable para controlar cdigo fuente, evitar uso de
un descargo incorrecto. La fuerza de esta proteccin depende de la criticidad de uso del producto. En general,
cada descargo debe -identificando (por ejemplo dilogo del operador o el rendimiento impreso).
El software modificado ser los retested antes del descargo. Deben seleccionarse las pruebas del
SVVP para demostrar su capacidad operacional.
Mientras normalmente no es necesario repetir toda la aceptacin prueba despus de un cambio del
software hecho, un subconjunto normal de la aceptacin de prueba (a menudo llam pruebas de `Regression)
debe correrse cuando cualquier nueva versin es hecho. Estas pruebas se exigen demostrar que una
modificacin no ha introducido los efectos laterales inesperados.

3.3 Planificacin de la configuracin del software

Toda actividad de la planificacin de configuracin del software debe ser documentarn en el
Software Configuracin Direccin Plan (SCMP). El SCMP es dividido en cuatro secciones que contienen el
plan de direccin de configuracin para el SR, AD, DD y fases de TR. La tabla de contenidos para cada
seccin de SCMP se describe en el Apndice C. Esta tabla de contenidos se deriva del IEEE Standard para los
Software Configuracin Direccin Planes (ANSI/IEEE Std 828-1983).

Puede encontrarse informacin adicional sobre la direccin de la configuracin en ANSI/IEEE Std

1042-1987, Gue a la Direccin de Configuracin de Software.

3.4

EVOLUCION DEL SCMP A LO LARGO DEL CICLO DE VIDA

Las salidas Los procedimientos de direccin de configuracin estarn en el lugar antes del
comienzo de la produccin del software (cdigo y documentacin). Los procedimientos de SCM deben ser
simples y eficientes. Dondequiera que sea posible, los procedimientos deben ser capaces de reusarse en las
fases posteriores. La inestabilidad en los procedimientos de SCM puede ser una causa mayor de progreso
pobre en un proyecto del software.
3.4.1

Fase UR

A finales de la revisin del UR, la fase de la seccin SR del SCMP deber ser producida
(SCMP/SR). El SCMP/SR cubrir los procedimientos de direccin de configuracin para toda la
documentacin, salidas de las herramientas CASE y el cdigo prototipo, debe ser producido en la fase de SR.
3.4.2

Fase SR

Durante la fase SR, la seccin de la fase AD del SCMP se producir (SCMP/DD). El SCMP/AD
cubrir los procedimientos de direccin de configuracin para la documentacin, las salidas de las
herramientas CASE o codigo prototipo, sern producido en la fase AD. A menos que exista una buena razn
para cambiar, (por ejemplo diferentes herramientas case utilizadas), los procedimientos de la fase SR debern
ser reutilizadas.
3.4.3

Fase AD

Durante la fase AD, la seccin de la fase DD del SCMP se producir (SCMP/DD). El SCMP/DD
cubrir los procedimientos de direccin de configuracin para la documentacin, cdigo entregable, salidas de
herramientas CASE o cdigo del prototipo, sern producidos en la fase de DD. A menos que hay una buena
razn al cambio, los procedimientos de la fase AD o SR sern reutilizados.
3.4.4

DD phase
Durante la fase de DD, la seccin de la fase TR del SCMP se producir (SCMP/TR). El SCMP/TR
cubrir los procedimientos para la direccin de la configuracin de las entregas en el ambiente operacional.

CAPTULO 4: Validacin y verificacin del software

4.1 INTRODUCCIN
En ANSI/IEEE Std 729-1983, se dan tres definiciones de verificacin. La verificacin puede
significar:
" el acto de repasar, inspeccionar, probar, verificar, intervenir, o establecer por otra parte y documentar o tems
, procesos, servicios o documentos conforme a los requisitos especificados (ANSI/ASQC A3-1978);
" el proceso de determinar o no los productos de una fase dada del ciclo de vida de desarrollo del software
cumplan los requisitos establecidos durante la fase anterior;
" la prueba formal de exactitud del programa.
La primera definicin de verificacin en la lista es la ms general e incluye las otras dos. En estas
Normas, la primera definicin (ANSI/ASQC A3-1978) se aplica.
La validacin es, segn su definicin de ANSI/IEEE, la evaluacin del software al final del
proceso de desarrollo de software para asegurar la complacencia con los requisitos del usuario. la validacin
es, verificacin Extremo a extremo.
La verificacin es esencial para asegurar la calidad de un producto. La verificacin del software es
una funcin tcnica y directiva, desde que el programa de verificacin necesita estar definido e
implementado. Las actividades de verificacin de un proyecto deben reflejar la criticidad del software, y la
calidad requerida de l.
La verificacin puede ser lo que ms consuma tiempo y la parte ms cara de un proyecto; las
actividades de verificacin deben aparecer en el SPMP. Figure 4.1 muestra un acercamiento del vida ciclo de
verificacin.
Figure 4.1 acercamiento del ciclo de Vida de verificacin
(Disponible slo en la copia original (hard copy))

4.2 ACTIVIDADES
Las actividades de la verificacin incluyen:
" las revisiones tcnicas, walkthroughs e inspecciones del software;
" verificar esos requisitos del software son concordables a los requisitos del usuario;
" verificar que los componentes de diseo son concordables a los requisitos de software;
" verificar pruebas formales y algoritmos;
" testear la unidad;
" verificar la integracin;
verificar el sistema;

" verificar la aceptacin;

" auditoras.
Se describen las actividades reales a ser dirigidas en un proyecto en la Verificacin del Software y
Plan de Validacin (SVVP).
As como demostramos que los aserciones sobre el software son verdad, la verificacin tambin
puede mostrar que las aserciones son falsas. No deben infravalorarse la habilidad e ingeniosidad necesitadas
identificar los defectos. Los usuarios tendrn ms confianza en un producto que ha pasado por un riguroso
programa de verificacin que uno sujeto a una examinacin mnima y probado antes de la entrega.

4.2.1 Revisiones
Los procedimientos para las revisiones del software estn basados estrechamente en el Standard
ANSI/IEEE 1028-1988. Una revisin del software es una evaluacin de un elemento del software para
determinar las diferencias de los resultados planeados y recomendar las mejoras correspondientes.

Se pueden usar tres tipos de revisiones para la comprobacin del software:

Revisin tcnica;
Walkthrough;
Inspeccin del software.

Los tres tipos de revisiones son todas Revisiones Formales en el sentido que todos tienen
objetivos y procedimientos especficos. Todos los tipos de revisin buscan identificar los defectos y
diferencias del software frente a las especificaciones, planes y normas.
El problema del software que informa procedimiento y documento los cambio de los
procedimientos definidos en la parte 2, Seccin 3.2.3.2, requieren un proceso de revisin formal para los
cambios de codificacin y documentacin. Cualquiera de los tres tipos de procedimiento de revisin formal
puede aplicarse para controlar el cambio. Por ejemplo, el SRB puede escoger realizar una revisin tcnica,
inspeccin del software o walkthrough segn sea necesario.
4.2.1.1 Revisiones Tcnicas
Deben usarse las revisiones tcnicas para el UR/R, SR/R, AD/R, y DD/R. las revisiones Tcnicas
evalan los elementos del software especficos para verificar el progreso comparado con el plan.
El objetivo de una revisin tcnica es evaluar un elemento del software especfico (por ejemplo la
documentacin, mdulo de cdigo fuente), y proporciona evidencia a la direccin que:

conforme a especificaciones hechas en las fases anteriores;

el elemento de software se ha producido segn las normas y procedimientos del proyecto;
los cambios han sido correctamente implementados, y afecta slo esas reas de sistemas
identificadas por la especificacin de cambio (descritas en un DCR o SCR).

4.2.1.2 Walkthroughs
Walkthroughs debe usarse para la evaluacin temprana de documentos, modelos, planes y cdigo
en el SR, AD y fases de DD.

El objetivo de un walkthrough es evaluar un elemento de software especfico (por ejemplo la

documentacin, mdulos de cdigo fuente). Un walkthrough debe intentar identificar los defectos y
considerar las posibles soluciones.
En contraste con otras formas de revisin, los objetivos secundarios son educar, y resolver los
problemas estilsticos de interfaz.
4.2.1.3 Inspecciones del Software
Deben usarse las inspecciones del software para la evaluacin de documentos y cdigo en el SR,
ADD y fase DD, antes de las revisiones tcnicas o pruebas.
El objetivo de una inspeccin de software es detectar e identificar defectos. Una inspeccin de
software es una exploracin personal rigurosa que:

identifica las discordancias con respecto a las especificaciones y normas;

usa mtricas para supervisar el progreso;
ignora los problemas estilsticos de interfaz;
no busca soluciones.

4.2.2 Trazado
El trazado requiere que cada entrada a una fase deba ser identificable a una salida de la fase.
El trazado demuestra la integridad. El trazado es normalmente hecho construyendo matrices de referenciacruzada. Los agujeros en la matriz demuestran el estado incompleto realmente rpido.
Al revs el trazado requiere que cada salida de una fase deba ser identificable para una entrada a
esa fase. Las salidas que no pueden ser trazadas para las entradas son superfluas, a menos que se verifique que
las entradas estaban incompletas. Al revs el trazado es normalmente hecho incluyendo con cada artculo una
declaracin de por qu existe (por ejemplo la descripcin de la funcin de un componente puede ser una lista
de requisitos funcionales).
Durante el ciclo de vida de software es necesario el trazado:

requerimientos del usuario para los requisitos del software y viceversa;

requerimientos del software para las descripciones de componentes y viceversa;
pruebas de integracin para componentes superiores de la arquitectura y viceversa;
pruebas de sistema para los requerimientos del software y viceversa;
pruebas de aceptacin a los requerimientos del usuario y viceversa.

Para soportar el trazado, todos los componentes y requerimientos son identifican. El SVVP debe
definir cmo el trazado ser hecho.
Las referencias a los componentes y requerimientos deben incluir los identificadores.
4.2.3 Prueba Formal
Dnde puede ser realizada, la prueba deductiva formal de exactitud del Software
Los Mtodos formales, como Z y VDM, poseen una notacin convenida, con la semntica bien
definida, y clculo, que permite construir las pruebas. La primera propiedad es compartida con otros mtodos
para la especificacin del software, pero el segundo grupo los aparta. Si un Mtodo Formal puede demostrar
con la certeza que algo es correcto, entonces la comprobacin separada no es necesaria. Sin embargo, los
errores humanos todava son posibles, y debe buscarse las maneras de evitar esto, por ejemplo asegurando que
todas las pruebas se verifican independientemente.

El refinamiento de una especificacin formal en el cdigo ejecutable generalmente no es un

proceso deductivo; otras formas de comprobacin (por ejemplo pruebas), son necesarias para verificar el
refinamiento.
4.2.4 Comprobacin
Probar es el proceso de ejercer o evaluar un sistema o componente del sistema, por un medio
manual o automatizado, para:

confirma que satisface los requerimientos especificados;

identifique las diferencias entre los resultados esperados y reales.

La cantidad de tiempo gastada probando el software es frecuentemente subestimado. Las

actividades de prueba deben especificarse cuidadosamente para que ellas puedan ser adecuadamente
presupuestadas. El gasto de probar aumenta con el nmero de errores presentes antes del comienzo.
Los mtodos baratos de eliminacin de errores, tales como inspeccin, walkthrough y pruebas formales,
deben siempre ser intentados antes que comiencen las pruebas
Las pruebas de software incluyen las siguientes actividades:

planear el acercamiento general y los recursos asignando;

detallar el acercamiento general para los varios tipos de pruebas en un plan de prueba;
definir las entradas, los resultados y las condiciones de ejecucin en una especificacin de caso de
prueba;
declarar la sucesin de acciones para ser llevadas a cabo por el personal de prueba en un
procedimiento de prueba;
anotar la ejecucin de un procedimiento de prueba en un informe de prueba.

Se han identificado cuatro tipos de test para estos estndares: test de la unidad, test de integracin,
test de sistema y test de aceptacin.
El software de prueba debe producirse bajo los mismos estndares que el software a entregar. El
software de prueba y los datos deben estar documentados y sujetos a los procedimientos de control de
configuracin general. Esto permite supervisar el proceso de la verificacin y permite que el software de
prueba y los datos sean rehusados despus, para verificar que la funcionalidad del software y comportamiento
no han sido daados por las modificaciones. Esto se llama test de regresin.
Los test de planes, test de diseos, test de casos, test de procedimientos e informes de la prueba para
la unidad, integracin, sistema y pruebas de aceptacin deben documentarse en el SVVP.
Tambin deben resumirse informes de Pruebas de Aceptacin en el Documento de Traslado de
Software.
4.2.5 auditorias
Las auditorias son revisiones independientes que evalan la conformidad con los requerimientos de
software, especificaciones, lneas bases, los estndares, instrucciones, los cdigos, contratos y licencias de
requerimientos. Una auditoria fsica chequea que todos los tems identificados como parte de la
configuracin est presente en las lneas base del producto.
Una funcin de auditoria es chequear unidades, integracin, pruebas del sistema y su xito o fracaso.
Se realizarn auditorias funcionales y fsicas antes del entrega del software.

4.3 LA COMPROBACIN DEL SOFTWARE Y PLAN DE VALIDACION

Toda la validacin y verificacin del software deber ser documentada en La Comprobacin del
Software y Plan de Aprobacin (SVVP).
El SVVP es dividido en siete secciones que contienen los planes de la verificacin para las fases de
SR, DC, DD y la unidad, integracin, sistema y especificaciones de los test. La tabla de contenidos para cada
seccin de SVVP se describe en el Apndice C. Esta tabla de contenidos se deriva del IEEE Standard para la
Comprobacin y Validacin de Planes (IEEE Std 1012-1989) y el IEEE Standard para la Documentacin de
Prueba de Software (IEEE Std 829-1983).
El SVVP asegura las actividades de verificacin:
Verificar el grado de criticidad del software;
Conocer la verificacin y aceptacin testiando los requerimientos (declarado en el SRD);
Verificar que el producto reunir la calidad, fiabilidad, mantenibilidad y requerimientos de seguridad (declar
en el SRD);
Verificar que se puede asegurar la calidad del producto.

4.4 EVOLUCIN DEL SVVP A LO LARGO DEL CICLO DE VIDA

4.4.1 fase de UR
Para el final de la revisin de UR, la seccin de la fase del SR del SVVP ser producida
(SVVP/SR). El SVVP/SR definir cmo remontar exigencias del usuario a los requisitos del software, para
poder justificar cada requisito del software. Debe describir cmo el SRD debe ser evaluado definiendo los
procedimientos de la revisin. Puede incluir las especificaciones de las pruebas que se realizarn con los
prototipos.
El iniciador (s) de las exigencias del usuario debe colocar los principios sobre los cuales las pruebas de
aceptacin deben ser basadas. El diseador construir un plan de prueba de aceptacin en la fase de UR y lo
documentar en el SVVP. Este plan debe definir el alcance, el acercamiento, y el horario de las actividades de
la prueba de aceptacin.

4.4.2 fase de SR
Durante la fase del SR, la seccin de la fase del AD del SVVP ser producida (SVVP/AD). El
SVVP/AD definir cmo remontar requisitos del software a los componentes, para poder justificar cada
componente de software. Debe describir cmo la ADD debe ser evaluada definiendo los procedimientos de la
revisin. Puede incluir las especificaciones de las pruebas que se realizarn con los prototipos.
Durante la fase del SR, el diseador analiza las exigencias del consumidor y puede insertar requisitos de la
prueba de aceptacin en el SRD. Estos requisitos obligan el diseo de las pruebas de aceptacin. Esto se debe
reconocer en la declaracin del propsito y del alcance de las pruebas de aceptacin.
El planeamiento de las pruebas del sistema debe proceder en paralelo a la definicin de los requisitos del
software. El diseador puede identificar los requisitos de la verificacin para el software - stos son apremios

adicionales en las actividades de prueba de la unidad, de la integracin y del sistema. Estos requisitos tambin
se indican en el SRD.
El diseador construir un plan de la prueba del sistema en la fase del SR y lo documentar en el SVVP. Este
plan debe definir el alcance, el acercamiento, los recursos y el horario de las actividades de prueba del
sistema.

4.4.3 Fase SR
Durante la fase del AD, la seccin de la fase de la DD del SVVP ser producida (SVVP/DD). El SVVP/AD
describir cmo el DDD y el cdigo deben ser evaluados definiendo los procedimientos de la revisin y del
traceabilidad.
El diseador construir un plan de prueba de la integracin en la fase del AD y lo documentar en el SVVP.
Este plan debe describir el alcance, el acercamiento, los recursos y el horario de las pruebas previstas de la
integracin. Observe que los artculos que se integrarn son los componentes de software descritos en la ADD

4.4.4 fase DD
En la fase de la DD, las secciones de la prueba SVVP se desarrollan mientras que el diseo detallado
y la informacin de implementacin comienzan a estar disponibles
El diseador construir un plan de prueba de unidad en la fase de la DD y lo documentar en el SVVP. Este
plan debe describir el alcance, los recursos y el horario de las pruebas de unidad previstas. Los artculos que
se probarn son los componentes de software descritos en el DDD.

Los diseos de la prueba de la unidad, de la integracin, del sistema y de aceptacin sern descritos en el
SVVP. stos deben especificar los detalles del acercamiento de la prueba para una caracterstica del software,
o la combinacin de las caractersticas del software, e identifican las pruebas asociadas.
La integracin de la unidad, el sistema y los casos de la prueba de aceptacin sern descritos en el SVVP.
stos deben especificar las entradas, los resultados predichos y las condiciones de la ejecucin para un
artculo de la prueba.
Los mtodos de prueba de la unidad, de la integracin, del sistema y de aceptacin sern descritos en el
SVVP. stos deben proporcionar una descripcin paso a paso de cmo realizar cada caja de la prueba.
Los informes de prueba de la unidad, de la integracin, del sistema y de aceptacin sern contenidos en el
SVVP.

CAPTULO 5: LA CONVICCIN DE CALIDAD DE SOFTWARE

NOTA: Donde ESA PSS-01 la serie de documentos son aplicables, y como una consecuencia ESA
PSS-01-21, `Software Producto Conviccin son requisitos para ESA Sistemas Espaciales donde tambin es
aplicable.

5.1 INTRODUCCIN
La Convencin sobre la Calidad de software (SQA) plane y creo un modelo sistemtico de todas
las acciones necesarias para proporcionar la confianza adecuada que el artculo o el producto conforma a
requisitos tcnicos establecidos (ANSI/IEEE Std 730.1-1989). la Convencin de Calidad de Software es
sinnima del Software `Product Assurance' (el PAP) y las condiciones se usan intercambiablemente en estas
Normas.
La actividad de conviccin de calidad es el proceso de verificar que estas normas estn siendo
aplicadas. En pequeo proyectos esto podra hacerse por el equipo de desarrollo, pero en los proyectos
grandes debe asignarse a el personal especfico.
El Plan de Calidad parea el Software (SQAP) define como estn normas deben ser monitoreadas.
La lista de contenidos SQAP es una lista de control (checklist) para actividades que tienen que ser llevado a
cabo para asegurar la calidad del producto. Para cada actividad, aquellos con la responsabilidad de supervisar
los planes SQA.

5.2 ACTIVIDADES
La evidencia objetiva de adhesin a estas normas debe buscarse durante todas las fases del ciclo de
vida. Deben obtenerse documentos requeridos por esta norma y deben examinarse. El cdigo fuente debe
verificarse para ver si cumple con los stanadres. Donde posible, aspectos de calidad (por ejemplo la
complejidad, la fiabilidad, el mantebilidad, la seguridad, los defectos, el nmero de problemas, el nmero de
RIDS) debe medirse cuantitativamente, mientras usen mtricas bien establecidas.
Las secciones subsecuentes listan que actividades derivadas de ANSI/IEEE Std 730.1-1989 eso son
necesarias si un artculo del software ser encajado para su propsito. Cada seccin discute cmo la actividad
puede verificarse.
5.2.1 Direccin
El anlisis de la estructura directiva que influye y controla en la calidad del software es una
actividad de SQA. La existencia de una estructura del organizacional apropiada debe verificarse. Debe
confirmarse que los individuos definieron en esa estructura ha definido tareas y responsabilidades. Se habrn
definido la organizacin, tareas y responsabilidades en el SPMP.
5.2.2 documentacin

El plan de la documentacin que se ha definido en el SPMP que debe analizarse. Debe escrutarse
cualquier salida del plan de la documentacin definido en estas normas y debe discutirse con la direccin del
proyecto.
5.2.3 normas, prcticas, convenciones y mtrica
La adhesin a todas las normas, prcticas y convenciones deben ser monitoreadas.
5.2.4 revisiones y auditorias
Estas Normas requieren las revisiones del URD, el SRD, el ADD, el DDD, el SVVP y el SCMP.
Tambin requiere la revisin y auditoria del cdigo durante la produccin. Deben examinarse la revisin y
arreglos de la auditoria descritos en el SVVP. Muchos tipos de revisiones son posibles (por ejemplo tcnico,
inspeccin y walkthrough). debe verificarse que los mecanismos de la revisin dsean los apropiados para el
tipo de proyecto. El personal de SQA debe participar en el proceso de la revisin.
5.2.5 actividades de la comprobacin
La unidad, integracin, sistema y aceptacin que prueban de software ejecutable son esenciales
para asegurar su calidad. Planes de prueba, Pruebas de Diseo, pruebas de procedimientos y las pruebas de
reportes son descritos en el SVVP. stos deben repasarse por el personal de SQA. Ellos deben supervisar las
actividades de testeo llevadas a cabo por el equipo de desarrollo, la ejecucin de la prueba. Adicionalmente,
pueden proponerse otras pruebas en el SQAP. stos pueden llevarse a cabo por el personal de SQA.
5.2.6 Reportes de problemas y Acciones de Correccin
El problema que se ocupa de procedimiento descrito en estas normas se disea para informar y
rastrear los problemas para si identificarlos y tomar una solucin. El personal de SQA debe supervisar la
ejecucin de los procedimientos, descrita en el SCMP, y debe examinar las tendencias en la ocurrencia del
problema.
5.2.7 herramientas, tcnicas y mtodos
Estas Normas requieren un herramientas, tcnicas y mtodos para la produccin del software deben
ser definidos al nivel del proyecto. Es una actividad de SQA para verificar ese herramientas apropiadas,
tcnicas y mtodos se selecciona y para supervisar su aplicacin correcta.
El personal de SQA puede decidir que se exigen herramientas adicionales, tcnicas y mtodos
apoyar su actividad supervisando. stos deben describirse en el SQAP.
5.2.8 cdigo y medidas de control
Estas Normas requieren que los procedimientos para los mtodos y las facilidades de uso se
mantengan, guardadas, seguras y controladas por documentos en versiones del software identificado, esto se
define en el SCMP. El personal de SQA debe verificar que ese procedimientos apropiados se han definido en
el SCMP y se han llevado a cabo.
5.2.9 Control del proveedor
Siempre deben verificarse artculos del software adquiridos de los proveedores externos contra las
normas para el proyecto. Un SQAP se producir por cada contratista el software en vas de desarrollo. Un
SQAP no se requiere para el software comercial.
5.2.10 coleccin de los archivos, mantenimiento y retencin
Estas normas definen un juego de documentos que deben producirse en cualquier proyecto.
Tambin pueden producirse documentos adicionales, por ejemplo minutas de reuniones y archivos de la

revisin. El personal de SQA debe verificar que se usan ese mtodos apropiados y medios para congregar,
salvaguardan, y mantienen toda esta documentacin para por lo menos la vida del proyecto. Se definen los
procedimientos de mando de documentacin en el SCMP.
5.2.11 entrenamiento
El personal de SQA debe verificar que el staff de desarrollo esta propiamente especializado para
realizar sus tareas e identifica cualquier entrenamiento que sea necesario.
Se documentan los planes de entrenamiento en el SPMP.
5.2.12 Gerencia de riesgo.
Todos los proyectos deben identificar los factores que son crticos a su xito y controlar estos factores. Esto se
llama el riesgo management' del `;. La gerencia de proyecto debe analizar siempre los riesgos que afectan el
proyecto. Sus resultados se documentan en el SPMP. El personal de la SQA debe supervisar la actividad de la
gerencia de riesgo, y aconseja a gerencia de proyecto en los mtodos y los procedimientos a identificar,
determinan, y las reas de control del riesgo.

5.3 EL PLAN DE LA GARANTA DE CALIDAD DEL SOFTWARE

Todas las actividades de la garanta de calidad del software sern documentadas en el plan de la garanta de
calidad del software (SQAP). El contenido recomendado para el SQAP se presenta en el apndice C. Este
contenido se deriva del estndar de IEEE para los planes de la garanta de calidad del software (IEEE Std
730.1-1989).

5.4 EVOLUCIN DEL SQAP A TRAVS DEL CICLO VITAL

5.4.1 Fase de UR.
Para el final de la revisin de UR, la seccin de la fase del SR del SQAP ser producida (SQAP/SR). El
SQAP/SR describir, detalladamente, las actividades de la garanta de calidad que se realizarn en la fase del
SR. El SQAP/SR contornear el plan de la garanta de calidad para el resto del proyecto. (IEEE Std 730.11989).
5.4.2 Fase del SR
Durante la fase del SR, la seccin de la fase del ANUNCIO del SQAP ser producida (SQAP/AD). El
SQAP/AD cubrir detalladamente todas las actividades de la garanta de calidad que se realizarn en la fase
del ANUNCIO. En la fase del SR, el SRD se debe analizar para extraer cualquier apremio que se relacione
con la garanta de calidad del software (Ej. los estndares y los requisitos de la documentacin).

Pa r t e 3 Ap e n d i c e s
APNDICE A: GLOSARIO
A.1

LISTA DE TERMINOLOGIA

La terminologa usada en el estndar de Ingeniera del software ESA esta echo conforme a
ANSI/IEEE Std 729-1983, `IEEE Standard Glossary of Software Engineering Terminology'. Esta seccin
contiene definiciones de trminos:

que no contiene el ANSI/IEEE Std 729-1983;

que tienen definiciones mltiples en ANSI/IEEE Std 729-1983 uno de los cuales se usa en estas Normas
(denot por *);
que se prefieren en la definicin de ISO (denotado por ISO y tomado de ISO 2382, ` Glossary of Terms
used in Data Processing);

Componente
Trminos generales para una parte de un sistema del software. Pueden ensamblarse componentes y pueden
descomponerse para formar nuevos componentes. En la fase de la produccin, se ejecutan o realizan los
mdulos, tareas o cualquier programa que puedan ser un tem de la configuracin. Este uso del trmino es
ms general que en lenguaje de ANSI/IEEE que define un componente como una parte de 'parte bsica de un
sistema o programa'; en ESA PSS-05-0, los componentes no pueden ser `basicos ' cuando ellos pueden
descomponerse.
Produccin concurrente y Documentacin
Una tcnica de desarrollo del software donde la documentacin de un mdulo procede en paralelo con
su produccin, especificaciones del plan es decir detalladas, codificando y probando.
-----------------------Puede comprarse 1 copia de normas de IEEE (con tarjeta de crdito) a:
IEEE Service Center
455 Hoes lane, P.O. Box 1331,
Piscataway, NJ08855-1331, USA
Tel: 908-981-0060
Puede comprarse 2 copias de normas de ISO (con tarjeta del crdito) a:
BSI Sales Dept,
Linfood Wood
Milton Keynes, MK14 6LE, U.K.
Tel: 0908-2211666
Descomposicin
La ruptura en partes.
Desarrollo del software

El periodo de la entrega de 'URD' para su aceptacin final durante la produccin del software.
Diseador
La persona u organizacin responsable para el desarrollo del software desde una especificacin de los
requisitos del usuario a un sistema operacional.
Entorno
Las condiciones fsicas como la temperatura, humedad y limpieza dentro de un sistema operado por
computador; o, el soporte y el software y hardware de utilidad.
El Mtodo formal
Un medio preciso de especificar el software matemticamente, permitiendo demostrar las
especificaciones consistente.
El Documento de Control de Interfaz
Una especificacin de una interfaz entre un sistema y un sistema externo.
La capa
Un nivel jerrquico en la descomposicin de un sistema.
El modelo lgico
Una implementacin independiente que representa un proceso del mundo real; es el contraste el
modelo fsico.
Modelo
Una representacin de un proceso del mundo real. Un modelo del software est compuesto de smbolos
organizados segn alguna convencin.
Mantenibilidad
La facilidad con que el software puede mantenerse (*).
Inconformismo
Una declaracin de conflicto entre la documentacin descriptiva y el objeto descrito.
El Modelo Fsico
Una implementacin dependiente que representa un proceso del mundo real; es el contraste el modelo
lgico.
La Conviccin del producto
La totalidad de actividades, normas, controles y procedimientos en la vida de un producto que
establece confianza que el producto entregado conformar adecuadamente los requerimientos del cliente (la
Conviccin del Producto y Poltica de Seguridad y Requisitos Bsicos para ESA los Sistemas Espaciales,
ESA PSS-01-0, el 1990 de mayo).

Produccin
El proceso de escribir y probar el software, es opuesto al diseo y operaciones.
Proyecto
El desarrollo procesa o la organizacin consagr al proceso de desarrollo.
Prototipo
Un modelo ejecutable de aspectos seleccionados de un sistema propuesto.
Descarga (??) (Release)
Una lnea base hecha disponible para el uso.
Confiabilidad
La probabilidad que el software no causar el fracaso de un sistema durante un tiempo especfico bajo
las condiciones especficas.
Tiempo de Respuesta
El tiempo transcurrido entre el fin de una pregunta o demanda en un sistema computacional y el
principio de la pregunta (ISO).
Revisin
Una actividad para verificar que los saidas de una fase por el ciclo de vida de software conforman a
sus especificaciones (contrast IEEE: `Design Review'.)
Estabilidad
La calidad de no cambiar. Tambien en el trmino corto, no estropendose, el trmino ms largo, no
sujeto al diseo y/o cambios de requisitos (Contrast IEEE (1) la habilidad de continuar inalterado a pesar de
perturbar o los eventos problemticos, (2) la habilidad de retornar a un estado original despus de perturbar o
los eventos problemticos).
Software
Los programas, procedimientos, reglas y toda la documentacin asociada pertenecientes al
funcionamiento de un sistema computarizado (ISO).
La tarea
Un componente del software que ejecuta secuencialmente. Una tarea puede ejecutar en paralelo con
otras tareas.

Traceability
La habilidad de relacionar una entrada a una fase del ciclo de vida de software a un rendimiento de esa
fase. El artculo puede ser software o documentacin.
La Matriz de Traceability
Matriz que muestra qu rendimientos corresponden a que las entradas. Mostrando ms a menudo qu
requisitos qu partes de un plan satisfacen.
Comercio-fuera de
La comparacin de alternativas para determinar la solucin ptima.
Volver-alrededor de
Los pasamos tiempo entre la sumisin de un trabajo y el retorno del rendimiento completo (ISO).
El usuario
Cualquier individual o se agrupa haciendo uso del rendimiento finalmente de un sistema de la
computadora, distinto del personal responsable por construir, o manteniendo el sistema.
La comprobacin
El acto de repasar, inspeccionando, probando, verificando, interviniendo, o estableciendo por otra parte
y documentando si los artculos, los documentos del processes,or conforman a los requisitos especificados (*).
La versin
Una fase en la evolucin de un artculo de la configuracin.
Trabajo-alrededor de
Una solucin temporal a un problema.
La Estructura de Avera de trabajo
El WBS describe la jerarqua de tareas (se agrup en paquetes de `Work) para ser llevado a cabo en un
proyecto. El WBS corresponde a la estructura del trabajo ser realizado, y refleja la manera en que los costes
del proyecto se resumirn y se informarn.
El Paquete de trabajo
Un detall, el palmo corto, unidad de trabajo ser realizado en un proyecto.

A.2 LIST DE SIGLAS

AD el Plan Arquitectnico
ADD el Documento del Plan Arquitectnico
AD/R la Revisin del Plan Arquitectnica
ANSI el Instituto de las Normas Nacional
AT Prueba de Aceptacin
BSSC Board para el Software Standardisation y Mando
CASE Software de apoyo computacional e ingenieril
DCR Documento el Registro de Cambio
DD Detailed el Plan y produccin
DDD Detailed el Plan y Documento de la produccin
DD/R Detailed el Plan y Revisin de la produccin
DSS Documento la Hoja de Estado
ESA Agencia Espacial Europea
IEEE Instituo de Ingeniera Elctrica y Electrnica
ISO Organizacin de Estndares Internacionales
ICD Interfaz el Documento del Mando
IT Prueba de Integracin
PA La Conviccin de Producto
PHD Proyecto Historico Documento
PSS Procedimientos, Estndares y Normas
QA Calidad Conviccin
RID la Diferencia de Artculo de Revisin
SCM Manejo de Configuarcin del SW
SCMP Plan de Manejo de Configuarcin del SW
SCR Software Cambio Demanda
SPM Software Proyecto Direccin
SPMP Plan de Software Proyecto Direccin
SMR Software Modificacin Informe
SPR Software Problema Informe
SQA Software Calidad Conviccin
SQAP Software Calidad Conviccin Plan
SR Software Requisitos
SRD Software Requisitos Documento
SRN Software Descargo Nota
SR/R Software Requisitos Revisin
ST Sistema Prueba
STD Software Traslado Documento
SUM Manual de Usuario de Software
SVVP Software Comprobacin y Plan de Aprobacin
UR Usuario Requisitos
URD Usuario Requisitos Documento
UR/R Usuario Requisitos Revisin
UT Unidad Pruebas

APNDICE B DOCUMENTOS DE PROYECTO DE SOFTWARE

Este Apndice resume los documentos que pueden ser producidos en un Proyecto de Ingeniera de SW. La
tabla A1 resume los documentos tcnicos. La tabla A2 resume los planes. La tabla A3 resume informes,
formas y otra documentacin.
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

sigla

Nombre

.
Propsito

URD

Requerimientos del usuario

Para declarar las necesidades de los usuarios de

documentos del sistema de software

SRD

Requerimientos del software

Para especificar los requisitos del sistema de software del

punto de vista del diseador. El SRD incorpora los
requisitos del usuario descritos en el Documento URD

ADD

Diseo arquitectnico

Para especificar los componentes ms elevados de la

documentacin del software.

El ADD cumple los

requisitos del software declarados en el SRD.

DDD

Diseo detallado

Especificar los componentes ms detallados de la

documentacin del software.

El DDD cumple los

requisitos extendidos en el SRD, siguiendo componentes

ms elevados descritos en el ADD.
SUM

STD

Manual

de

Usuario

de

Para exponer lo que el software hace y cmo operar el

software

software.

Traslado del software

Contiene la lista de elemento de composicin verificada y

SPRs, SCRs, SMRs originados en la fase de TR

PHD

Historial del Proyecto

Para guardar la informacin significante sobre la

especificacin, plan, produccin y funcionamiento del
software.

Tabla A1 - documentos Tcnicos requeridos por ESA PSS-05-0

sigla

Nombre

Propsito

SPMP

Proyecto del software

Para declarar la organizacin, WBS, el Plan de Direccin

de horario y presupuesto, para cada fase de desarrollo.

SCMP

Configuracin del software

Para declarar los procedimientos del Plan de Direccin

identificando, controlando, y registrando el estado de
elementos del software.

SVVP

Comprobacin del software

Para declarar los procedimientos para probar el software y

verificar que el y los productos de Plan de Aprobacin de
cada fase son consistentes con sus entradas.

SQAP

Calidad del software

Para declarar los procedimientos para asegurar la calidad

de los productos de software.

Tabla A2 - Planes requeridos por ESA PSS-05-0

sigla

Nombre

DCR

Registro

Propsito
de

cambios

del

Para registrar los cambios a un documento

Estado

del

Para resumir los problemas y revisiones de un documento.

Diferencia de Elementos de

Para declarar problemas encontrados en una revisin y las

revisin

decisiones del registro.

documento
DSS

Hoja

de

Documento
RID

SCR

Demanda

de

Cambio

de

software

Para describir cambios requeridos en el software y su

documentacin en las fases TR y OM, incluyendo nuevos
requisitos.

SMR

SPR

Informe de Modificacin de

Para describir cambios hechos al software y su

software

documentacin en las fases TR y OM.

Informe

de

Problemas

de

software
SRN

Nota

de

software

Para registrar un problema informado en el uso o prueba

del software y su documentacin.

lanzamiento

del

Para resumir cambios hechos al software con respecto al

lanzamiento anterior.

APNDICE C PLANTILLAS de DOCUMENTOS

Todos los documentos deben contener la siguiente de informacin de servicio:
a - Abstracto
b - Tabla de conidos
c - Hoja de Estado de Documento
d - Archivos de Cambio de Documento hechos desde ltimo problema
Si no hay informacin pertinente a una seccin, lo siguiente que aparece debajo del encabezado de la
seccin: La seccin de `Esta no es aplicable', con las razones apropiadas para esta exclusin.
Los comentarios en las tablas de volmenes son encerrados entre parntesis.
El prrafo titula que ser suministrado por los autores del documento, adjunto en los limites del cuadro.

El APNDICE C.1 Contenido de URD

1 introduccin
1.1 propsito
1.2 alcance
1.3 definiciones, siglas y abreviaciones
1.4 referencias
1.5 apreciacin global
2 Descripcin general
2.1 perspectiva del producto
2.2 caractersticas del usuario
2.3 constreimiento generales
2.4 asunciones y dependencias
2.5 ambiente operacional
3 Requisitos especficos
3.1 requisitos de capacidad
3.2 requisitos de apremios

El APNDICE C.2 Contenido de SRD

1 introduccin
1.1 propsito
1.2 alcance

1.3 definiciones, siglas y abreviaciones

1.4 referencias
1.5 apreciacin global
2 Descripcin general
2.1 relacin a los proyectos actuales
2.2 relacin al predecesor y proyectos del sucesor
2.3 funcin y propsito
2.4 consideraciones medioambientales
2.5 relacin a otros sistemas
2.6 Apremios generales
2.7 descripcin del modelo
3 Requisitos especficos
(Las subdivisiones pueden reagruparse alrededor de las funciones de alto nivel)
3.1 requisitos funcionales
3.2 requisitos de la actuacin
3.3 requisitos de la interfaz
3.4 requisitos operacionales
3.5 requisitos del recurso
3.6 requisitos de la comprobacin
3.7 aceptacin que prueba los requisitos
3.8 requisitos de la documentacin
3.9 requisitos de seguridad
3.10 requisitos de portabilidad
3.11 requisitos de calidad
3.12 requisitos de fiabilidad
3.13 requisitos de Capacidad de mantenimiento.
3.14 requisitos de seguridad
4 Exigencias del consumidor contra la matriz de investigacin de los requisitos del software

El APNDICE C.3 Contenido de ADD

1 introduccin
1.1 propsito
1.2 alcance
1.3 definiciones, siglas y abreviaciones
1.4 referencias
2 Apreciacin global del sistema
3 Contexto del sistema
3.n definicin de la interfaz Externa

4 Plan del sistema

4.1 mtodo del plan
4.2 descripcin de descomposicin
5 Descripcin del componente
5.n identificador del Componente |
5.n.1 Tipo
5.n.2 Propsito
5.n.3 Funcin
5.n.4 Secundario
5.n.5 Dependencias
5.n.6 Interfaces
5.n.7 Recursos
5.n.8 Referencias
5.n.9 Proceso
5.n.10 Datos
6 viabilidades y Estimaciones del Recurso
7 Requisitos del software contra la matriz de investigacin de los componentes

El APNDICE C.4 Contenido del DDD

Parta 1 - la Descripcin General

El APNDICE C.5 SUM la Tabla de volmenes

1 introduccin

2.-

1.1 nmero de lectores intencional

1.2 declaracin de la pertinencia
1.3 propsito
1.4 cmo usar este documento
1.5 documentos relacionados (incluyendo los documentos aplicables)
1.6 convenciones
1.7 problema que informa las instrucciones
Seccin de la Visin Global
(La seccin ha de darle un entendiendo general al usuario que partes del software proporcionan las
capacidades necesarias)

3.-

Seccin de la Instruccin

(Para cada operacin, proporcione...

(a) Descripcin Funcional
(b) Cuidados y Advertencias
(c) Procedimientos, incluyendo,
- La estructuracin e Inicializacin
- Operaciones de entrada
- Qu resultados esperar
(d) Errores Probables y posibles causas)
4.-

Seccin de referencia
(Describa cada operacin, incluyendo:
(a) Descripcin Funcional
(b) Cuidados y Advertencias
(c) la descripcin Formal, incluyendo apropiado,:
- Parmetros Requeridos
- Parmetros Opcionales
- Opciones Predefinidas
- Orden y Sintaxis
(d) Ejemplos
(e) Posibles mensajes de error y causas
(f) Referencias Cruzadas a otros funcionamientos)

Apndice A
Apndice B
Apndice C

Mensajes de Error y procedimientos de recuperacin

Glosario
Indice(para los manuales de 40 pginas o ms)

APNDICE C.6 STD Tabla de Contenidos

1.-

Introduccin
1.1.1.2 .1.3 .1.4 .-

Propsito
Alcance
Definiciones, siglas y abreviaciones
Referencias

2 .-

Procedimientos de instalacin

3 .-

Procedimientos de Construccin

4 .-

Lista de Items de configuracin

5 .-

Aceptacin Prueba Informe Resumen

6 .-

Informes de Problema de software

7 .-

Demandas de Cambio de software

8 .-

Informes de Modificacin de software

APNDICE C.7 PHD Tabla de Contenidos

1.-

Descripcin del proyecto

2 .-

Direccin del proyecto

2.1.2.2 .2.3 .2.4 .-

3.-

Acercamiento contractual (si s aplica)

Organizacin del proyecto
Mtodos usados
Planificacin

Produccin del software

3.1.3.2.3.3 .3.4 .3.5 .-

Estimado vs. la cantidad real de cdigo producido

Documentacin
Estimado vs. Esfuerzo real
Recursos de la computadora
Anlisis de factores de productividad

4.-

Revisin de Seguridad de calidad

5 .-

Revisin financiera

6 .-

Conclusiones

7 .-

Actuacin del sistema en fase de OM

APNDICE C.8 SPMP Tabla de Contenidos

Direccin Proyecto Software Plan para la Fase de SR
1.-

Introduccin
1.1
1.2
1.3
1.4
1.5

Visin global del proyecto

Entregas del proyecto
Evolucin del SPMP
materiales de la referencia
definiciones y siglas

2 proyecto Organisation
2.1 modelo del proceso
2.2 estructura de Organisational
2.3 lmites de Organisational e interfaces
2.4 responsabilidades del proyecto
3 proceso directivo
3.1 objetivos de direccin y prioridades
3.2 asunciones, dependencias y constreimiento
3.3 direccin de riesgo

3.4 supervisando y controlando los mecanismos

3.5 plan proveyendo de personal
4 Proceso tcnico
4.1 mtodos, herramientas y tcnicas
4.2 documentacin del software
4.3 funciones de apoyo de proyecto
5 Paquetes de trabajo, Horario, y Presupuesto
5.1 trabajo empaqueta
5.2 dependencias
5.3 requisitos del recurso
5.4 presupuesto y asignacin del recurso
5.5 horario
El software Proyecto Direccin Plan para la Fase del ADD---Mismo
:
El software Proyecto Direccin Plan para la Fase de DD: estructure como
:
El software Proyecto Direccin Plan para el TR Phase----SPMP/SR

APENDICE C.9 tabla de contenidos SCMP

Plan de direccin del Proyecto de Software para la fase SR
1 Introduccin
1.1 Propsito
1.2 Limites
1.3 Glosario
1.4 Referencias
2 Direccin
3 Identificador de configuracin
4 Control de la configuracin
4.1 Control del cdigo
4.2 Control de los medios
4.3 Control de cambio
5 Contabilidad del estado de configuracin
6 Herramientas, Tcnicas y Mtodos para SCM
7 Control del proveedor
8 Coleccin de los archivos y Retencin

Plan de direccin del Proyecto de Software para la fase del AD----Mismo

:
Plan de direccin del Proyecto de Software para la fase de DD: estructurado como
:
Plan de direccin del Proyecto de Software para la fase TR ---- SCMP/SR

APENDICE C.10 la tabla de contenidos SVVP

Comprobacin del software y Plan de validacin para la Fase SR
1 Propsito
2 Documentos de referencia
3 Definiciones
4 Apreciacin global de la validacin
4.1 Organizacin
4.2 Calendarizacin principal
4.3 Resumen de recursos
4.4 Responsabilidades
4.5 herramientas, tcnicas y mtodos
5 Procedimientos Administrativos de verificacin
5.1 Informe de anomalas y resolucin
5.2 Poltica de iteracin en tareas
5.3 Poltica de desviacin
5.4 Procedimientos de control
5.5 Standars, prcticas y convenciones
6 Actividades de verificacin
7.1 Matriz plantilla de seguimiento
7.2 Pruebas formales
7.3 Revisiones
7 Informe de verificacin del software
Verificacin del software y Plan de validacin para la fase del ANUNCIO----Mismo
: estructurado como
Verificacin del software y Plan de validacin para la fase DD ----SVVP/SR
Especificacin de pruebas de aceptacin
1 Plan de pruebas
1.1 introduccin
1.2 tems de prueba
1.3 Caracterstica a probar
1.4 Caractersticas que no sern probadas

1.5 Acercamiento
1.6 Criterios de aprobacin/reprobacin del tem
1.7 Criterio de la suspensin y requisitos de la reasuncin
1.8 Pruebas de entrega
1.9 Comprobacin de tareas
1.10 Necesidades del ambiente
1.11 Responsabilidades
1.12 Personal y necesidades de entrenamiento
1.13 Calendarizacin
1.14 Riesgos y contingencias
1.15 Aprobaciones
2 Diseo de pruebas (para cada prueba...)
2.n.1 Identificador de plan de Prueba
2.n.2 Caractersticas a ser probadas
2.n.3 Refinamientos de aproximacin
2.n.4 Identificacin de caso de Prueba
2.n.5 Criterio de aprobacin/desaprobacin de las caractersticas
3 Especificaciones de caso de prueba (para cada caso de prueba...)
3.n.1 Identificador de caso de prueba
3.n.2 tems de prueba
3.n.3 Especificaciones de la entrada
3.n.4 Especificaciones de las salidas
3.n.5 Necesidades del ambiente
3.n.6 Requisitos procesales especiales
3.n.7 Dependencias Intercase
4 Procedimientos de prueba (para cada caso de prueba...)
4.n.1 Identificador de procedimiento de prueba
4.n.2 Propsito
4.n.3 Requisitos Especiales
4.n.4 Pasos a seguir por el procedimiento
5. Reporte de Test (para cada ejecucin de un procedimiento de test)
5.n.1 Identificador de Reporte de Test
5.n.2 Descripcin
5.n.3 Actividades y Entrada de Eventos

Especificacin de la Prueba del sistema --- de la Misma Forma

Especificacin de Prueba de la Integracin: estructura como
Especificacin de prueba de unidad (puede estar en DDD) --- SVVP/AT

APNDICE C.11 SQAP tabla de contenidos

Plan de la garanta de calidad del software para la fase SR
1.
2.
3.
4.
5.

Propsito
Documentos de Referencia
Gerencia
Documentacin
Estndares, prcticas, convenciones y mtricas
5.1 Estndares de la documentacin
5.2 Estndares de diseo
5.3 Normas de codificacin
5.4 Estndares de comentarios
5.5 Estndares de pruebas y prcticas.
5.6 Seleccin de la mtrica para la garanta de calidad del software
5.7 Declaracin de cmo la conformidad debe ser supervisada

6.

Revisin y auditoria
6.1 Propsito
6.2 Requisitos mnimos

7.

Pruebas

8.

Divulgacin del problema y accin correctiva

9.

Herramientas, tcnicas y mtodos

10. Control de cdigo

11. Control de medios
12. Control de salidas
13. Medios de coleccin, mantenimiento y retencin
14. Entrenamiento
15. Manejo del riego
16. Entorno del resto del proyecto

Plan de la garanta de calidad del software para la fase AD ---iguales

:
Plan de la garanta de calidad del software para la fase de DD: estructura como
:

Plan de la garanta de calidad del software para la fase TR --- SQAP/SR

APNDICE D: RESUMEN DE LAS PRCTICAS OBLIGATORIAS

Estas prcticas obligatorias han sido extradas para facilidad de referencia, y pueden ser utilizadas como una
lista de comprobacin retrospectiva. Son etiquetados con el captulo del que vienen, aadidos con un sufijo
con un nmero de secuencia. Este nmero corresponde a la orden del requisito en el captulo.

APNDICE D.1: CICLO DE VIDA DEL SOFTWARE

SLC01 Los productos de un proyecto de desarrollo de software debern ser entregados en una manera
oportuna y adecuada para su propsito.
SLC02 Las actividades de desarrollo de software sern planeadas y realizadas sistemticamente.
SLC03 Todos los proyectos de software tendrn un acercamiento al ciclo vital, que incluye las fases bsicas
demostradas en el cuadro 1.2:
Fase
Fase
Fase
Fase
Fase
Fase

UR - Definicin de las exigencias del consumidor

SR - Definicin de los requisitos del software
AD - Definicin del diseo arquitectnico
DD - Diseo y produccin detallados del cdigo
TR - Transferencia del software a las operaciones
OM - Operaciones y mantenimiento

APNDICE D.2: FASE UR

UR01 La definicin de los requerimientos ser la responsabilidad del usuario.
UR02 Cada requerimiento del usuario incluir un identificador.
UR03 Los requerimientos esenciales sern marcadas como tal.
UR04 Para la entrega incremental, cada requisito del usuario incluir una medida de prioridad a fin de que el
desarrollador pueda decidir el programa de produccin.
UR05 La fuente de cada exigencia del usuario ser indicado.
UR06 Cada exigencia del usuario ser comprobable.

UR07 El usuario describir las consecuencias de prdidas de disponibilidad, o brechas de seguridad, para que
diseadores puedan apreciar el criticality de cada funcin totalmente.
UR08 que se repasarn Los rendimientos de la fase de UR formalmente durante la Revisin de Requisitos de
Usuario.
UR09 que se marcarn los requisitos del usuario Non-aplicables claramente en el URD.
UR10 Un rendimiento de la fase de UR ser el Documento de Requisitos de Usuario (URD).
UR11 que El URD siempre se producir antes de un proyecto del software se empieza.
UR12 El URD proporcionar una descripcin general de lo que el usuario espera el software para hacer.
UR13 que Todos los requisitos del usuario conocidos sern incluidos en el URD.
UR14 El URD describir los funcionamientos que el usuario quiere realizar con el sistema del software.
UR15 El URD definir todo los constreimiento que el usuario desea imponer en cualquier solucin.
UR16 El URD describir las interfaces externas al sistema del software o referencia ellos en ICDs que existe
o ser escrito.
APNDICE D.3 FASE SR
SR01 SR escalonan que las actividades se llevarn a cabo segn los planes definidos en la fase de UR.
SR02 El diseador construir a modelo aplicacin-independiente de lo que se necesita por el usuario.
SR04 Cada requisito del software incluir un identificador.
SR05 que se marcarn los requisitos del software Esenciales como a tal.
SR06 Para la entrega incremental, cada requisito del software incluir una medida de prioridad para que el
diseador pueda decidir el horario de la produccin.
Referencias de SR07 que rastrean los requisitos del software atrs al URD acompaarn cada requisito del
software.
SR08 Cada requisito del software ser comprobable.
SR09 que se repasarn Los rendimientos de la fase de SR formalmente durante la Revisin de Requisitos de
Software.
SR10 Un rendimiento de la fase de SR ser el Documento de Requisitos de Software (SRD).
SR11 El SRD estar completo.
SR12 El SRD cubrir todos los requisitos declarados en el URD.
SR13 UNA mesa que muestra cmo los requisitos del usuario corresponden a los requisitos del software se
pondr en el SRD.
SR14 El SRD ser consistente.
SR15 que El SRD no incluir la aplicacin detalla o terminologa, a menos que tiene que estar presente como
un constreimiento.

Las Descripciones de SR16 de funciones... dir lo que el software es hacer, y debe evitar el refrn cmo ser
hecho.

EL APNDICE LA D.3 SR FASE

SR01 SR escalonan que las actividades se llevarn a cabo segn los planes definidos en la fase de UR.
SR02 El diseador construir a modelo aplicacin-independiente de lo que se necesita por el usuario.
SR04 Cada requisito del software incluir un identificador.
SR05 que se marcarn los requisitos del software Esenciales como a tal.
SR06 Para la entrega incremental, cada requisito del software incluir una medida de prioridad para que el
diseador pueda decidir el horario de la produccin.
Referencias de SR07 que rastrean los requisitos del software atrs al URD acompaarn cada requisito del
software.
SR08 Cada requisito del software ser comprobable.
SR09 que se repasarn Los rendimientos de la fase de SR formalmente durante la Revisin de Requisitos de
Software.
SR10 Un rendimiento de la fase de SR ser el Documento de Requisitos de Software (SRD).
SR11 El SRD estar completo.

SR12

El SRD cubrir todos los requisitos declarados en el URD.

SR13

Una tabla muestra cmo los requisitos del usuario corresponden a los requisitos del software
que deben estar especificados en el URD.

SR14

El SRD ser consistente.

SR15

El SRD no incluir detalles de implementaron o terminologas, a menos que tiene que estar
presente como una condicin (constraint).

SR16

Descripcin de las funciones...dir lo que el software hace, y debe evitar el refrn cmo ser
hecho.

SR17

Evitara especificar el software o hardware, a no ser que sea una condicin puesta por el
usuario (constraint).

EL APNDICE D.4

AD FASE

AD01

AD fase- actividades. Se llevarn a cabo segn los planes definidos en la fase de SR.

AD02

UN mtodo reconocido de diseo de software deber ser adoptado y aplicado

consistentemente en la fase AD.

AD03

El desarrollador deber construir un modelo fsico, el cual describe el diseo de software

utilizando terminologa de implementaron.

AD04

El mtodo usado para descomponer el software entre componentes, permitir un

acercamiento Top-down.

AD05

Slo el acercamiento del diseo seleccionado se reflejar en el ADD.

Para cada componente, la siguiente informacin deber ser detallada en el ADD:

AD06

Datos entrada.

AD07

Funciones para ser ejecutadas.

AD08

Salida de datos.

AD09

Estructuras de datos que conectaran (unirn) los componentes seran definidas en el ADD.

Las definiciones de Estructuras de datos incluirn:

AD10

Descripcin de cada elemento (por ejemplo el nombre, tipo, dimensin);

AD11

Las relaciones de entre los elementos (por ejemplo la estructura);

AD12

Rango de valores posibles de cada elemento;

AD13

Valores iniciales de cada elemento.

AD14

Los controles de flujo entre componentes deben ser definidos en el AD.

AD15

Los recursos del computador (por ejemplo la velocidad de CPU, memoria, el

almacenamiento, el software del sistema) necesitados en el ambiente de desarrollo y el
ambiente operacional se estimar en la fase del AD y se definir en el ADD.

AD16

Las salidas de la fase AD debern ser formalmente revisados durante la Revisin de Diseo
Arquitectural. (Arquitectnica).

AD17

El ADD definir los mayores componentes del software y las interfaces entre ellos.

AD18

El ADD definir o referencia todas las interfaces externas.

AD19

El ADD ser ser una salida de la fase del AD.

AD20

El ADD estar completo, cubriendo todos los requisitos del software descritos en el SRD.

AD21

Una tabla de cruce referencial los requisitos del software a las partes del diseo
arquitectnico se pondrn en el ADD.

AD22

El ADD ser consistente.

AD23
El ADD ser lo suficientemente detallado para permitirle al lder del proyecto preparar un
diagrama detallado del plan de implementaron y para controlar el proyecto global durante las fases de
desarrollo restantes.
AD24

El ADD se compilar segn la tabla de volmenes proporcionada en el Apndice C.

EL APNDICE D.5
DD01

DD fase

Las actividades de la fase DD se llevarn a cabo segn los planes definidos en la fase del
ADD.

El plan detallado y produccin de software se basarn en los siguientes tres principios:

DD02

Descomposicin Top-down.

DD03

Programacin estructurada.

DD04

Produccin y documentacin concurrente.

DD05

El proceso de la integracin se controlar por los software de administracin de

configuracin de procedimientos definidos en el SCMP.

DD06

Antes de que un mdulo pueda aceptarse, cada declaracin en un mdulo se ejecutar

substancialmente por lo menos una vez.

DD07

El testeo de Integracin verificarn que todos los datos intercambiados a travs de una
interface estn de acuerdo con las especificaciones de estructura de datos en el ADD.

DD08

El testeo de integracin deber confirmar que los flujos de control definidos en el ADD han
sido implementados.

DD09

El testeo de integracin verificarn la complacencia con los objetivos del sistema, como lo
declarado en el SRD.

DD10

Cuando el diseo de un componente mayor ha sido terminado, se emplazar una revisin

critica del diseo para certificar su disponibilidad para la implementaron.

DD11

Despus de la produccin, el revisor DD (DD/R) considerar los resultados de las

actividades de la comprobacin y decidir si lo transferir para el software.

DD12

Todo el cdigo entregable ser identificado en la lista de itemes de configuracin.

DD13

El DDD ser ser una salida de la fase de DD.

DD14

Parte 2 del DDD tendrn la misma estructura y esquema de identificacin como el propio
cdigo, con un 1:1, la correspondencia entre las secciones de la documentacin y los
componentes del software.

DD15 El DDD estar completo, mientras considerando para todos los requisitos del software en el SRD.
DD16 UNA mesa cruz-referencing los requisitos del software a los componentes del plan detallados se
pondrn en el DDD.
DD17 UN Manual de Usuario de Software (la SUMA) ser un rendimiento de la fase de DD.

EL APNDICE LA D.6 TR FASE

TR01 Representantes de usuarios y personal de los funcionamientos participarn en las pruebas de
aceptacin.
TR02 La Tabla de Revisin de Software (SRB) repasar la actuacin del software en la aceptacin prueba y
recomiende, al iniciador, si el software puede ser provisionalmente aceptado o no.
TR03 TR escalonan que las actividades se llevarn a cabo segn los planes definidos en la fase de DD.
TR04 La capacidad de construir el sistema de los componentes que son directamente los modifiable por el
equipo de mantenimiento se establecern.
TR05 La Aceptacin de prueba necesario para la aceptacin provisional se indicar en el SVVP.
TR06 La declaracin de aceptacin provisional se producir por el iniciador, en nombre de los usuarios, y se
enviar al diseador.
TR07 que El sistema del software aceptado provisionalmente consistir en los rendimientos de todas las fases
anteriores y modificaciones encontr el requisito en la fase de TR.
TR08 Un rendimiento de la fase de TR ser los STD.
TR09 que El STD se entregar del diseador al organisation de mantenimiento a la aceptacin provisional.
TR10 El STD contendr el resumen del reports,ocumentation de prueba de aceptacin sobre cambios del
software realizados durante la fase de TR.

EL APNDICE LA D.7 OM FASE

OM01 Hasta ltimo aceptacin, OM escalonan actividades que involucran al diseador se llevarn a cabo
segn los planes definidos en el SPMP/TR.
OM02 que Todas las pruebas de aceptacin se habrn completado con xito antes del software se acepta
finalmente.
OM03 incluso cuando ningn contratista est envuelto, habr un ltimo hito de aceptacin para colocar el
formal mano-encima de del desarrollo del software al mantenimiento.

OM04 que UN organisation de mantenimiento se designarn para cada producto del software en el uso
operacional.
OM05 Se definirn Procedimientos para la modificacin del software.
OM06 La Consistencia de entre el cdigo y documentacin se mantendr.
OM07 Se asignarn los Recursos al mantenimiento de un producto hasta que est jubilado.
OM08 El SRB... autorizar todas las modificaciones al software.
OM09 La declaracin de ltimo aceptacin se producir por el iniciador, en nombre de los usuarios, y se
enviar al diseador.
OM10 que El PHD se entregar al iniciador despus de ltimo aceptacin.

EL APNDICE LA D.8 LA DIRECCIN DE PROYECTO DE SOFTWARE

SPM01 que Todas las software proyecto direccin actividades se documentarn en el Software Proyecto
Direccin Plan
(SPMP).
SPM02 a finales del UR repasan, los SR escalonan la seccin del SPMP se producir (SPMP/SR).
SPM03 El SPMP/SR perfilar un plan para el proyecto entero.
SPM04 que UNA estimacin precisa del esfuerzo involucrada en la fase de SR ser incluida en el SPMP/SR.
SPM05 Durante el SR escalonan, la seccin de fase de ANUNCIO del SPMP se producir (SPMP/AD).
SPM06 que Una estimacin del costo del proyecto total ser incluida en el SPMP/AD.
SPM07 que UNA estimacin precisa del esfuerzo involucrada en la fase del ANUNCIO ser incluida en el
SPMP/AD.
SPM08 Durante la fase del ANUNCIO, los DD escalonan la seccin del SPMP se producir (SPMP/DD).
SPM09 que Una estimacin del costo del proyecto total ser incluida en el SPMP/DD.
SPM10 El SPMP/DD contendr un WBS en que se relaciona directamente a la descomposicin del software
los componentes.
SPM11 El SPMP/DD contendr una red de la planificacin que muestra relaciones de codificar, integracin y
probando
las actividades.
SPM12 Ningn software produccin trabajo paquete en el SPMP/DD durar ms mucho tiempo que 1
hombre-mes.
SPM13 Durante el DD escalonan, los TR escalonan la seccin del SPMP se producir (SPMP/TR).

EL APNDICE D.9 LA DIRECCIN DE CONFIGURACIN DE

SOFTWARE
SCM01 Todos los artculos del software, por ejemplo la documentacin, cdigo de la fuente, objeto o
relocatable codifican, se sujetarn cdigo ejecutable, los archivos, herramientas, software de
la prueba y datos, a los procedimientos de direccin de configuracin.
SCM02 Los procedimientos de direccin de configuracin establecern los mtodos por identificar, mientras
guardando y artculos del software cambiantes a travs del desarrollo, integracin y traslado.
SCM03 que UN juego comn de procedimientos de direccin de configuracin se usar.
Cada artculo de la configuracin tendr un identificador que lo distingue de otros artculos con diferente:
SCM04 Los requisitos, especialmente la funcionalidad e interfaces;
SCM05 La implementacin.
SCM06 Cada componente definido en el proceso de diseo se designar como un CI y ser incluido un
identificador.
SCM07 El identificador incluir un nmero o un nombre relacionado con el propsito del CI.
SCM08 El identificador incluir una indicacin del tipo de procesamiento que se piensa para el CI
(por ejemplo el filetype la informacin).
SCM09 El identificador de un CI incluir un nmero de la versin.
SCM10 El identificador de documentos incluir un nmero del problema y un nmero de la revisin.
SCM11 El mtodo de identificacin de configuracin ser capaz de acomodar nuevo CIs, sin requerir la
modificacin de los identificadores de cualquier CIs existente.
SCM12 En la fase TR, una lista de los artculos de la configuracin en la primera publicacin ser incluid el
STD.
SCM13 En la fase OM, una lista de artculos de la configuracin cambiados ser incluida en cada Nota de
Software publicada (SRN).
SCM14 Un SRN acompaar cada publicacin hecho en la fase de OM.
Como parte del mtodo de identificacin de configuracin, un mdulo del software tendr un encabezado
estndar que incluye:
El SCM15 Identificacin de los artculos de configuracin (el nombre, teclee, versin);
SCM16 El autor original;
SCM17 La fecha creacin;

SCM18 Cambios en la historia (el version/date/author/description).

Toda la documentacin y medios de comunicacin del almacenamiento sern claramente rotulados en un
formato estndar, con por lo menos los siguientes datos:
SCM19 Nombre del proyecto;
SCM20 Identificacin de los artculos de configuracin (el nombre, tipo, versin);
SCM21 Fecha;
SCM22 La descripcin de contenidos
Para asegurar la seguridad y control del software, a un mnimo, las bibliotecas del siguiente software se
llevarn a cabo para guardar todos los componentes entregados (por ejemplo la documentacin, la fuente el
cdigo ejecutable, los archivos de la prueba, orden del procedimientos ):
SCM23 La librera de desarrollo (o Dinmico);
SCM24 La librera maestra (o Control);
SCM25 La librera esttica (o Archivo);
SCM26 Libreras estticas que no se modificarn.
SCM27 Siempre estarn disponibles copias de seguridad actualizadas para la librera maestra y la esttica.
SCM28 Procedimientos para apoyar el regular desarrollo de bibliotecas establecidas.
SCM29 El procedimiento de cambio descrito (en parte 2, Seccin 3.2.3.2.1) se observar cuando se necesitan
los cambios a un documento entregado.
SCM30 Software problemas y propuestas de cambio sern manipuladas por el procedimiento descrito (en
parte 2, la Seccin, 3.2.3.2).
SCM31 El estado de todos los artculos de configuracin sern grabados.
Para realizar la contabilidad de estado de software, cada proyecto de software grabar:
SCM32 La fecha y versin/publicacin de cada bsico;
SCM33 La fecha y nmero de la revisin de cada cambio del documento;
SCM34 La fecha y estado de cada SPR, SCR y SMR;
SCM35 Una descripcin sumaria de cada Artculo de la Configuracin.
SCM36 Como mnimo, el SRN grabar las fallas que se han reparado y los nuevos requisitos que han estado
incorporados.
SCM37 Para cada descargo, la documentacin y cdigo sern consistentes.
SCM38 Se retendrn los descargos viejos, para la referencia.
SCM39 Modificaciones del software sern retested antes de la publicacin.

SCM40 Todas las actividades para direccional la configuracin del software se documentarn en el Plan de
Direccin de Configuracin de Software (SCMP).
SCM41La configuracin direccin procedimientos estarn en el lugar antes de la partida da la produccin de
software (el cdigo y documentacin).
SCM42 Para el fin del repado del UR , los faces SR de la seccin SCMP producir (SCMP/SR).
SCM43 El SCMP/SR cubrir los procedimientos de direccin de configuracin para la documentacin, y
producir cualquier herramienta CASE o cdigo prototipo, ser producido en la fase de SR.
SCM44 Durante la fase SR, la seccin de fase de ANUNCIO del SCMP se producir (SCMP/AD).
SCM45 El SCMP/AD cubrir los procedimientos de direccin de configuracin para la documentacin, y
rendimiento de herramienta de CASE o cdigo del prototipo, ser producido en la fase del ANUNCIO.
SCM46 Durante la fase del AD, las fases DD de la seccin SCMP se producir (SCMP/DD).
SCM47 El SCMP/DD cubrir los procedimientos de direccin de configuracin para la documentacin,
cdigo entregable, y cualquier rendimiento de las herramientas CASE con cdigo del prototipo,
sern producido en la fase de DD.
SCM48 Durante la fase DD, la fase TR de la seccin SCMP se producir (SCMP/TR). El SCMP/TR cubrir
los procedimientos para la direccin de la configuracin de las entregas en el ambiente operacional.

APNDICE D.10 LA COMPROBACIN DEL SOFTWARE Y VALIDACION

SVV01 Aumenta la rastreabilidad el hecho que cada entrada a una fase sea trazable a una salida de esa fase.
SVV02 Disminuye la rastreabilidad el hecho que cada salida de una fase sea trazable a una entrada para esa
fase.
SVV03 Las revisiones funcionales y fsicas sern realizadas antes del lanzamiento del software.
SVV04 Todas las actividades de verificacin y validacin del software se documentarn en el Plan de
Verificacin y Validacin del Software (SVVP).
El SVVP asegurar que las actividades de la comprobacin:
SVV05

son apropiadas para el grado de criticidad del software;

SVV06

cumplen las pruebas de requerimientos de verificacin y aceptacin (declarados en el SRD);

SVV07

verifican que el producto reunir la calidad, fiabilidad, mantenibilidad y requisitos de

seguridad necesarios (declarados en el SRD);

SVV08

son suficientes para asegurar la calidad del producto.

SVV09 Al trmino de la revisin UR, la seccin de SR del SVVP se producir (SVVP/SR).

SVV10 El SVVP/SR definir cmo alinear los requisitos del usuario a los requisitos del software, para que
cada requisito del software pueda justificarse.
SVV11 El diseador construir un plan de prueba de aceptacin en la fase de UR y lo documentar en el
SVVP.
SVV12 Durante la fase de SR, la seccin de AD del SVVP se producir (SVVP/AD).
SVV13 El SVVP/AD definir cmo alinear los requisitos del software a los componentes, para que cada
componente del software pueda justificarse.
SVV14 El diseador construir un plan de prueba de sistema en la fase de SR y lo documentar en el SVVP.
SVV15 Durante la fase de AD, la seccin de DD del SVVP se producir (SVVP/DD).
SVV16 El SVVP/AD describir cmo el DDD y cdigo sern evaluados definiendo la revisin y
procedimientos de rastreabilidad.
SVV17 El diseador construir un plan de prueba de integracin en la fase de AD y lo documentar en el
SVVP.
SVV18 El diseador construir un plan de prueba de unidad en la fase de DD y lo documentar en el SVVP.
SVV19 Los planes de prueba de unidad, integracin, sistema y aceptacin sern descritos en el SVVP.
SVV20 Los casos de prueba de unidad, integracin, sistema y aceptacin sern descritos en el SVVP.
SVV21 Los procedimientos de prueba de unidad, integracin, sistema y aceptacin sern descritos en el
SVVP.
SVV22 Los informes de prueba de unidad, integracin, sistema y aceptacin sern descritos en el SVVP.

APNDICE D.11 ASEGURAMIENTO DE LA CALIDAD DEL SOFTWARE

SQA01 Un SQAP ser producido por cada contratista desarrollando el software.
SQA02 Todas las actividades de aseguramiento de la calidad del software sern documentadas en el Plan de
Aseguramiento de la Calidad del Software (SQAP).

EL APNDICE E LAS FORMAS DE PLANTILLAS

Las formas de la plantilla se proporcionan para:
DCR - el Registro de Cambio de Documento
DSS - la Hoja de Estado de Documento
RID - la Diferencia de Artculo de Revisin
SCR - la Demanda de Cambio de Software
SMR - el Informe de Modificacin de Software
SPR - el Informe de Problema de Software
SRN - la Nota de Descargo de Software
REPORTE DE MODIFICACION DE SOFTWARE

SRN N:
FECHA:
CREADOR:
SCRs
RELACIONADAS:

1.

TITULO ITEM SOFTWARE:

2.

NUMERO VERSION ITEM DE SOFTWARE :

3.

CAMBIOS IMPLEMENTADOS:

4.

FECHA DE INICIO, FECHA DE TERMINO Y ESFUERZO DE LA MANO DE OBRA::

5. ANEXOS

documentacin

Cdigo Fuente
Procedimientos de Prueba
Datos de Prueba
Resultados de Prueba
Actualizaciones de la

(tickear cuando sea apropiado)

REPORTE DE PROBLEMA DE SOFTWARE

SPR N:
FECHA:
CREADOR:

1.

TITULO ITEM SOFTWARE:

2.

NUMERO VERSION ITEM DE SOFTWARE:

3.

PRIORIDAD: CRITICA/URGENTE/RUTINARIA (subraye opcin)

4.

DESCRIPCION DEL PROBLEMA:

5.

DESCRIPCION DE LAS CONDICIONES/ENTORNO:

6.

SOLUCION RECOMENDADA:

7.

REVISION DE TABLA DE DECISIN DEL SOFTWARE:

8.

ANEXOS:

NOTA DE LA VERSION DEL SOFTWARE

SRN N:
FECHA:
CREADOR:
APROVADO POR:

1.

TITULO ITEM SOFTWARE:

2.

NUMERO VERSION ITEM DE SOFTWARE:

3.

CAMBIOS EN ESTA VERSION:

4.

ITEMS DE CONFIGURACION INCLUIDOS EN ESTVERSION:

5. INSTRUCCIONES DE INSTALACION:

FASES

UR

ITEMS

Definicin
Requerimientos de
Usuario

ACTIVIDADES
PRINCIPALES

ITEMS
ENTREGA
BLES

UR/R

SR

Definicin
Requerimi
entos de
Software

Determinacin del
entorno
operacional

Construccin
de un
Modelo
Lgico

Identificacin de los
requerimientos de los
usuarios

Identificacin
de los
requerimientos
de Software

Documento de
Requerimientos
de Usuario

SR/R

AD

Diseo
de
Arquitectu
ra

AD/R

Construccin
de un
Modelo
Fsico

Diseo
Detallad
oy
Producc
in

DD/R

Diseo de
Mdulo
s

Documento de
Diseo de
Arquitectu
ra

TR
Transfer
encia

Instalacin
Tests de
Aceptacin
Provisionales

Codificacin
Test de
Unidades
Test de
Integracin
Test de
sistema

Definicin de
Principale
s
Componen
tes

Documento de
Requerimi
entos de
Software

DD

Documento de
Diseo
Detallad
o
DDD

Documento de
Transfer
encia de
Softwar
e

OM Operaciones
y
Mantenimien
to

Tests de
Aceptacin
Finales
Operaciones
Mantenimiento de
Cdigo y
Documentacin

Documento de
Historial del
Proyecto

Cdigo

Flecha implica
cambio de control

URD

SRD

ADD

STD

SUM
Manual del
Softwar
e del
Usuario

REVISIONES

(ver lista)

Revisiones
Tc
nica
s

Inspecciones
Rpidas

Revisiones
Tc
nica
s

Inspecciones
Rpidas

Revisiones
Tc
nica
s

Inspecciones
Rpidas

Revisiones
Tc
nica
s

PHD

PRINCIPALES
HITOS

URD
aprobada

SRD
aprobada

ADD
aprobada

Cdigo/DDD /SUM STD entregado

PHD entregado
aprobada
Aceptacin
Provisional

Aceptacin
Provisional