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