TABLA DE CONTENIDOS
ESA PSS-05-0 Issue 2
February 1991
E S A
S O F T W A R E
E N G I N E E R I N G
S T A N D A R 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
5PRLOGO
61 PROPSITO DE LAS NORMAS
62 ESTRUCTURA DE LAS NORMAS
63 CLASES DE PRCTICAS NORMALES (de norma)
63.1 prcticas obligatorias
73.2 prcticas recomendadas
73.3 pauta prctica
74 APLICANDO LAS NORMAS
74.1 factores aplicados a las Normas
84.2 Aplicar el Estandar en un desarrollo de sistema
84.3 mtodos y herramientas
9PARTE 1 NORMAS DEL PRODUCTO
9CAPTULO 1: EL CICLO DE VIDA DE SOFTWARE
91.1 INTRODUCCIN
91.2 FASES, ACTIVIDADES E HITOS
131.3 ACERCAMIENTOS DE CICLO DE VIDA
141.4 PROTOTIPADO
151.5 CAMBIO DE REQUISITOS DE MANEJO
16CAPITULO 2: FASE DE DEFINICION DE REQUERIMIENTOS DEL
USUARIO
162.1) INTRODUCCION
162.2)ENTRADAS DE LA ETAPA
162.3)ACTIVIDADES
182.4 SALIDAS DE LAS FASES
19CAPITULO 3: FASE DE DEFINICION DE REQUERIMIENTOS DE
SOFTWARE
193.1) INTRODUCCION
203.2) ENTRADAS A LA FASE
253.4 SALIDAS DE LA FASE
26Capitulo 4 :LA FASE DEL DISEO ARQUITECTNICO
264.1 INTRODUCCIN
264.2 Entradas a la fase
274.3 actividades
314.4 SALIDA DE CADA FASE
314.4.2Planes de Prueba de Integracin
33CAPTULO 5: PLAN DETALLADO Y FASE DE LA PRODUCCIN
335.1 INTRODUCCION
335.2 ENTRADAS A LA FASE
335.3 ACTIVIDADES
375.4 SALIDAS A PARTIR DE LA FASE
39CAPTULO 6: LA FASE DEL TRASLADO
396.1 INTRODUCCIN
396.2 ENTRADAS A LA FASE
406.3 ACTIVIDADES
416.4 SALIDAS DE LA FASE
42CAPTULO 7: LAS OPERACIONES Y LA FASE DEL MANTENIMIENTO
427,1 INTRODUCCIN
427,2 ENTRADAS A LA FASE
437,3 ACTIVIDADES
437,3,1 Aprobacin Final
447.4 RENDIMIENTO DE LA FASE
46PARTE 2: PROCEDIMIENTO ESTANDAR
47CAPTULO 1: LA DIRECCIN DEL CICLO DE VIDA DE SOFTWARE
471.1 INTRODUCCIN
471.2 DIRECCIN DE PROYECTO DE SOFTWARE
471.3 DIRECCIN DE CONFIGURACIN DE SOFTWARE
481.4 COMPROBACIN DEL SOFTWARE Y APROBACIN
481.5 CONVICCIN DE CALIDAD DE SOFTWARE
48CAPTULO 2: LA DIRECCIN DE PROYECTO DE SOFTWARE
482.1 INTRODUCCIN
492.2 ACTIVIDADES
512.3 EL PLAN GERENCIAL DE PROYECTO DE SOFTWARE
512.3 EVOLUCIN DEL SPMP A TRAVS DEL CICLO DE VIDA
512.4.2 Fase SR
522.4.3 Fase AD.
522.4.4 Fase DD
53CAPTULO 3 ADMINISTRACIN DE LA CONFIGURACIN DEL SOFTWARE
533.1 INTRODUCCIN
533.2 ACTIVIDADES
583.3 Planificacin de la configuracin del software
593.4 EVOLUCION DEL SCMP A LO LARGO DEL CICLO DE VIDA
593.4.1 Fase UR
593.4.2 Fase SR
593.4.3 Fase AD
593.4.4 DD phase
60CAPTULO 4: Validacin y verificacin del software
604.1 INTRODUCCIN
604.2 ACTIVIDADES
644.3 LA COMPROBACIN DEL SOFTWARE Y PLAN DE VALIDACION
644.4 EVOLUCIN DEL SVVP A LO LARGO DEL CICLO DE VIDA
66CAPTULO 5: LA CONVICCIN DE CALIDAD DE SOFTWARE
665.1 INTRODUCCIN
665.2 ACTIVIDADES
685.3 EL PLAN DE LA GARANTA DE CALIDAD DEL SOFTWARE
685.4 EVOLUCIN DEL SQAP A TRAVS DEL CICLO VITAL
69P a r t e 3 A p e n d i c e s
69APNDICE A: GLOSARIO
69A.1 LISTA DE TERMINOLOGIA
73A.2 LIST DE SIGLAS
74APNDICE B DOCUMENTOS DE PROYECTO DE SOFTWARE
76APNDICE C PLANTILLAS de DOCUMENTOS
76El APNDICE C.1 Contenido de URD
76El APNDICE C.2 Contenido de SRD
77El APNDICE C.3 Contenido de ADD
78El APNDICE C.4 Contenido del DDD
78El APNDICE C.5 SUM la Tabla de volmenes
79APNDICE C.6 STD Tabla de Contenidos
80APNDICE C.7 PHD Tabla de Contenidos
80APNDICE C.8 SPMP Tabla de Contenidos
81APENDICE C.9 tabla de contenidos SCMP
82APENDICE C.10 la tabla de contenidos SVVP
84APNDICE C.11 SQAP tabla de contenidos
85APNDICE D: RESUMEN DE LAS PRCTICAS OBLIGATORIAS
85APNDICE D.1: CICLO DE VIDA DEL SOFTWARE
85APNDICE D.2: FASE UR
87EL APNDICE LA D.3 SR FASE
87EL APNDICE D.4 AD FASE
89EL APNDICE D.5 DD fase
90EL APNDICE LA D.6 TR FASE
90EL APNDICE LA D.7 OM FASE
91EL APNDICE LA D.8 LA DIRECCIN DE PROYECTO DE SOFTWARE
92EL APNDICE D.9 LA DIRECCIN DE CONFIGURACIN DE SOFTWARE
94APNDICE D.10 LA COMPROBACIN DEL SOFTWARE Y VALIDACION
95APNDICE D.11 ASEGURAMIENTO DE LA CALIDAD DEL SOFTWARE
96EL APNDICE E LAS FORMAS DE PLANTILLAS
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 SecretariatBSSC/ESTEC Secretariat
Sr C MazzaSr A Scheffer
ESOCESTEC
Robert-Bosch-Strasse 5Postbus 299
D-6100 DarmstadtNL-2200 AG Noordwijk
AlemaniaHolanda
_____________________________________ 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)ACTIVIDADESLa 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 UsuarioMientras 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 OperacionalLa 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 UsuarioCuando 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
El diseador construir a modelo aplicacin-independiente de lo que
se necesita por el usuario. Esto 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
referencias-cruzadas 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
proyecto-especfico 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 bien-definido.
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
no-funcionales 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 asegura