Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Guía para La Aplicación de Estándares de Ingeniería de Software ESA (Agencia Espacial Europea) para Proyectos de Software Pequeños
Guía para La Aplicación de Estándares de Ingeniería de Software ESA (Agencia Espacial Europea) para Proyectos de Software Pequeños
Preparado por: ESA Comit de Estandarizacin y Control de Software (BSSC) European Space Agency / Agence Spatiale Europenne (Agencia Espacial Europea) 8-10, rue Mario -Nikis, 75738 PARIS CEDEX, Francia BSSC(96) 2Nmero 1
PREFACIO .......................................................................................................................................................................... 4 CAPTULO 1: INTRODUCCIN ................................................................................................................................ 5 1.1 PROPSITO................................................................................................................................................................ 5 1.2 ASPECTOS GENERALES ...................................................................................................................................... 5 CAPTULO 2: PROYECTOS DE SOFTWARE PEQUEOS............................................................................. 7 2.1 INTRODUCCIN....................................................................................................................................................... 7 2.2 COMBINACIN DE LAS FASES RS Y DA...................................................................................................... 8 2.3 SIMPLIFICACIN DE LA DOCUMENTACIN........................................................................................... 8 2.4 SIMPLIFICACIN DE LOS PLANES ................................................................................................................ 9 2.5 REDUCCIN DE LA FORMALIDAD DE LOS REQUISITOS .................................................................. 9 2.6 UTILIZACIN DE LAS ESPECIFICACIONES DEL PLAN DE PRUEBAS PARA LAS PRUEBAS DE ACEPTACIN .................................................................................................................................... 10 CAPTULO 3: PRCTICAS PARA PROYECTOS DE SOFTWARE PEQUEOS ..................................11 3.1 INTRODUCCIN..................................................................................................................................................... 11 3.2 CICLO DE VIDA DE SOFTWARE.................................................................................................................... 12 3.3 FASE RU ..................................................................................................................................................................... 13 3.4 FASE RS/DA............................................................................................................................................................... 13 3.5 FASE DD ..................................................................................................................................................................... 16 3.6 FASE TR...................................................................................................................................................................... 17 3.7 FASE OM .................................................................................................................................................................... 18 3.8 ADMINISTRACIN DE PROYECTOS DE SOFTWARE.......................................................................... 18 3.9 GESTIN DE LA CONFIGURACIN DE SOFTWARE ........................................................................... 19 3.10 VERIFICACIN Y VALIDACIN DE SOFTWARE ................................................................................ 22 3.11 ASEGURAMIENTO DE CALIDAD DE SOFTWARE............................................................................... 23 APNDICE A: GLOSARIO ......................................................................................................................................... 24 A.1 LISTA DE SIGLAS Y ABREVIATURAS ........................................................................................................ 24 APNDICE B: REFERENCIAS .................................................................................................................................26
APNDICE C: PLANTILLAS DE DOCUMENTOS ............................................................................................ 27 C.1 NDICE DEL DRU .................................................................................................................................................. 28 C.2 NDICE DES .............................................................................................................................................................. 29 C.3 DOCUMENTACIN DE LOS REQUISITOS DEL CDIGO FUENTE............................................... 31 C.4 NDICE MUS ............................................................................................................................................................ 31 C.5 NDICE DTS .............................................................................................................................................................. 33 C.7 NDICE PGCS .......................................................................................................................................................... 35 C.8 NDICE PVVS........................................................................................................................................................... 36
PREFACIO
Los estndares de ingeniera de software ESA PSS-05-0, definen las prcticas de software que deben aplicarse en todos los proyectos de la agencia. Mientras que su aplicacin es bastante directa en grandes proyectos, la experiencia ha demostrado que un enfoque simplificado es apropiado para proyectos de software pequeos. Este documento proporciona las pautas sobre cmo aplicar los estndares de ingeniera de software (ESA) a proyectos de software pequeos. Por consiguiente a la gua se le ha dado el seudnimo de "PSS-05 lite". Los siguientes miembros de BSSC, tanto los pasados como los actuales, han contribuido a la elaboracin de esta gua: Michael Jones (co-presidente), Uffe Mortensen (co-presidente), Gianfranco Alvisi, Bryan Melton, Daniel de Pablo, Adriaan Scheffer y Jacques Marcoux. La BSSC desea agradecer a Jon Fairclough por redactar y editar la gua. Los autores desean agradecer a todas las personas que aportaron con ideas sobre la aplicacin de ESA PSS-050 a proyectos pequeos. Las solicitudes para aclaraciones, propuestas de cambios u otros comentarios relacionados con esta gua deben dirigirse a :
Secretaria de BSSC/ESOC Secretara BSS/ESTEC Atencin Seor M. Jones Atencin Seor U. Mortensen ESOC ESTEC Robert Bosch Strasse 5 Postbus 299 D-64293 Darmstadt NL-2200 AG Noordwijk Alemania Holanda.
CAPTULO 1: INTRODUCCIN
1.1 PROPSITO
ESA PSS-05-0 describe los estndares de ingeniera de software que se aplicarn a todos los artefactos software implementados por la Agencia Espacial Europea (ESA) [Referencia 1]. Este documento se ha producido para proporcionar directrices a las organizaciones y a los administradores de los proyectos de software, como una gua para la aplicacin de los estndares a proyectos de software pequeos. En una serie de documentos descritos en ESA PSS-05-0, se entregan directrices adicionales para la aplicacin de los estndares, Gua de los Estndares de Ingeniera de Software [Referencias 2 a 12]. Existen muchos criterios para decidir si un proyecto de software es pequeo, y por lo tanto si se puede aplicar esta gua. Esto se tratar en el Captulo 2. Cualquiera sea el resultado de la evaluacin, esta gua no debera aplicarse cuando el software es crtico (por ejemplo, un fallo de un software podra provocar la prdida de vidas, propiedades, o mayores inconvenientes a los usuarios) o cuando se aplica aseguramiento de los requisitos de producto de software para ESA Space System ESA PSS-01-21
Puede considerarse que un proyecto de software es pequeo si se aplican uno o ms de los siguientes criterios: Si se necesitan menos de dos aos hombre de esfuerzo para el desarrollo. Si se requiere un equipo nico de desarrollo de cinco o menos personas. Si la cantidad de cdigo fuente es inferior a 10000 lneas, excluyendo los comentarios.
Con frecuencia una o ms de las siguientes estrategias son apropiadas a los proyectos pequeos que generan software no crtic o: Combinacin de los requisitos de software y las fases del diseo arquitectnico. Documentacin simplificada. Simplificacin de los planes. Reduccin de la formalidad de los requisitos. Utilizacin de las especificaciones del plan de pruebas para las pr uebas de aceptacin.
ESA PSS-05-0 requiere que cada requisito sea probado por lo menos una vez. A veces esto se conoce como el requisito de cobertura de requisito. Hay evidencia de que una cantidad significativa de defectos permanece en el software cuando el alcance del requisito baja del 70% [Referencia 14], y de que la cantidad de defectos disminuye significativamente cuando la cobertura del requisito sobrepasa el 90%. Sin embargo, lograr una alta proteccin en las pruebas puede ser costoso en trminos de esfuerzo. Los casos de prueba tienen que
inventarse para forzar la ejecucin de todos los requisitos. El costo de esta prueba exhaustiva puede exceder el costo de reparacin de los defectos durante las operaciones. Los desarrolladores deberan: Establecer un objetivo de pruebas de requisitos (por ejemplo: cobertura del 80%). Revisar cada requisito no cubierto en las pruebas.
Existen herramientas software disponibles para medir la cobertura de prueba y deberan usarse siempre vez que sea posible.
2.6 UTILIZACIN DE LAS ESPECIFICACIONES DEL PLAN DE PRUEBAS PARA LAS PRUEBAS DE ACEPTACIN
Cuando el desarrollador es responsable de producir la especificacin de la aceptacin de pruebas, a menudo las pruebas de aceptacin repiten procedimientos y casos de prueba del sistema seleccionado. Un mtodo para la documentacin de pruebas de aceptacin del sistema consiste simplemente en indicar en la especificacin de pruebas de sistema cuales de los casos de prueba y procedimientos debieran ser utilizados en las pruebas de aceptacin.
Figura 3.1: Ciclo de vida de un proyecto de software pequeo Las siguientes secciones describen las prcticas obligatorias en un proyecto de software pequeo. Las prcticas se tabulan con su identificador ESA PSS-05-0. La adjuntan guas (en itlica) en caso de que sea apropiado explicar como se aplican estas prcticas en un proyecto pequeo. Estas guas se basan en las estrategias descritas en el Captulo 2.
3.3 FASE RU
RU01 Deber ser responsabilidad del usuario la definicin de los requisitos de usuario. RU02 Cada requisito de usuario deber incluir un identificador. RU03 Los requisitos esenciales de usuario debern ser marcados como tales. RU04 Para hacer entregas incrementales, cada requisito de usuario deber incluir un grado de prioridad, de tal manera que el desarrollador pueda decidir la agenda de produccin. RU05 Deber establecerse la fuente de cada requisito de usuario. RU06 Deber verificarse cada requisito de usuario. RU07 El usuario deber describir las consecuencias de las prdidas de disponibilidad, o violaciones de seguridad, de tal mane ra que los desarrolladores puedan apreciar en su totalidad lo crtico de cada funcin. RU08 Debern revisarse formalmente las salidas de la fase RU durante la Revisin de Requisitos de Usuario. RU09 Debern sealarse claramente los requisitos de usuario no aplicables. RU10 Un producto de la fase RU deber ser el Documento de Requisitos de Usuario (DRU). RU11 El DRU deber producirse siempre antes de que el proyecto de software empiece. RU12 El DRU proporcionar una descripcin general de lo que el usuario espera que haga el software. RU13 Debern incluirse todos los requisitos de usuario conocidos en el DRU. RU14 El DRU deber describir las operaciones que el usuario quiere realizar con el sistema software. RU15 El DRU deber definir todas las restricciones a las que el usuario desea imponer una solucin. RU16 El DRU deber describir las interfaces externas del sistema software o deber hacer mencin de ellas en los Documentos de Control de Interfaces que existan o que se deben escribir.
RS06 Para entregas incrementales cada requisito de software deber incluir un grado de prioridad de tal manera que el desarrollador pueda decidir la agenda de produccin. RS07 Los requisitos software debern ir acompaados de las referencias a los RU que trazan, segn el etiquetado del DRU. RS08 Deber ser verificable cada requisito de software. RS09 Las salidas de la fase RS debern ser formalmente revisadas durante la Revisin de los Requisitos de Software. Las salidas de las actividades de definicin de los requisitos de software se revisaron en la fase de repaso RS/DA. RS10 Una salida de la fase RS ser el Documento de Requisitos de Software DRS. Esta prctica se aplica a la fase RS/AD. La informacin de DRS se establece en el Documento de Especificacin de Software (DES). RS11 El DRS debe ser completo. Esta prctica se aplica al DES. RS12 El DES deber cubrir todos los requisitos establecidos en DRU Esta prctica se aplica al DES. RS13 Una tabla mostrar como los requisitos de usuario corresponden a los requisitos de software que debern ser establecidos en el DRS. Esta prctica se aplica al DES. RS14 El DRS deber ser consistente. Esta prctica se aplica al DES. RS15 El DRS no deber incluir detalles de implementacin o terminologa, a menos que estos tengan que presentarse como una restriccin. Esta prctica se aplica al DES. RS16 Descripciones de funciones...debern decir para qu es el software, y evitar decir como se elabor. RS17 El DRS deber evitar la especificacin del hardware o equipamiento, a menos que esto sea una restriccin establecida por el usuario. Esta prctica no se aplica. RS18 El DRS deber compilarse de acuerdo al ndice estipulado en el Apndice C. Esta prctica se aplica al DES. El DES deber compilarse de acuerdo al ndice en el Apndice C de esta gua. DA01 Las actividades de la fase DA debern realizarse de acuerdo a los planes definidos en la fase RS. En proyectos pequeos, los planes de DA debern realizarse en la fase RU. DA02 Deber adoptarse y aplicarse adecuadame nte un mtodo reconocido para el diseo de software en la fase DA. Esta prctica se aplica a la fase RS/DA. DA03 El desarrollador deber construir un modelo fsico, que describa el diseo de software utilizando terminologa de implementacin. DA04 El mtodo utilizado para descomponer el software en las partes que lo componen deber permitir un acercamiento "Top-Down". DA05 Deber reflejarse en el DDA slo el mtodo del diseo seleccionado. Esta prctica se aplica al DES.
La siguiente informacin para cada componente deber detallarse en el DDA. DA06 * Datos de entrada; DA07 * Funciones que se van a realizar; DA08 * Datos de Salida. DA06, 7, 8 se aplican al DES. DA09 Deber definirse en el DDA la estructura de los datos que componen la interfaz. Esta prctica se aplica al DES. Las definiciones de la estructura de datos debern incluir: DA10 * La descripcin de cada elemento (por ejemplo: nombre, tipo, tamao); DA11 * Las relaciones entre los elementos (por ejemplo: la estructura); DA12 * La variacin de los posibles valores de cada elemento; DA13 * Valores iniciales de cada elemento DA10, 11, 12, 13 se aplican al DES. DA14 Deber definirse en el DDA el flujo de control entre los componentes. Esta prctica se aplica al DES. DA15 Los recursos del computador (por ejemplo: Velocidad de CPU, memoria, almacenamiento, software del sistema) necesarios en el ambiente de desarrollo y en el ambiente operacional debern evaluarse en la fase DA y definirse en el DDA. Esta prctica se aplica al DES. DA16 Las salidas de la fase DA debern revisarse formalmente durante la Revisin del Diseo Arquitectnico. Los productos de las actividades del diseo arquitectnico de software se revisan en la fase de revisin RS/DA. DA17 El DDA definir los principales componentes de software y las interfaces entre ellos. Esta prctica se aplica al DES. DA18 El DDA mencionar todas las interfaces externas. Esta prctica se aplica al DES. DA19 El DDA ser una salida de la fase DA. Esta prctica se aplica al DES. DA20 El DDA se completar, abarcando todos los requisitos de software descritos en el DRS. Esta prctica se aplica al DES. DA21 Se establecer en el DDA una tabla de referencias cruzadas para trazar los requisitos de software del diseo arquitectnico. Esta prctica se aplica al DES. DA22 El DDA deber ser consistente. Esta prctica se aplica al DES. DA23 El DDA deber ser lo suficientemente detallado para permitir al jefe de proyecto preparar un documento con un plan de implementacin detallado y para controlar todo el proyecto durante las fases de desarrollo restantes. Esta prctica se aplica al DES. DA24 El DDA deber compilarse de acuerdo al ndice estipulado en el Apndice C.
Esta prctica se aplica al DES. El DES debera compilarse de acuerdo al ndice que se encuentra en el Apndice C de esta gua.
3.5 FASE DD
DD01 Las actividades de la fase DD debern realizarse de acuerdo a los planes definidos en la fase DA. Los planes de la fase DD estn contenidos en los planes desarrollados en la fase RU y actualizados a medida que corresponda durante el proyecto. El diseo detallado y produccin de un software deber basarse en los tres principios siguientes: DD02 * Descomposicin "Top-Down"; DD03 * Programacin estructurada /Programacin OO; DD04 * Documentacin y produccin concurrente. DD05 Los procesos de integracin debern ser controlados por los procedimientos de gestin de configuracin de software, definidos en PGCS. DD06 Antes de que un mdulo pueda aceptarse, cada requisito deber ejecutarse exitosamente por lo menos una vez. La aceptacin debera realizarla el administrador del proyecto despus de las pruebas unitarias y por el cliente al final de la fase. Los proyectos de software deberan: - Establecer un objetivo de pruebas de requisitos (por ejemplo: cobertura del 80%). - Revisar cada requisito no cubierto en las pruebas. Existen herramientas software disponibles para medir la cobertura de las pruebas. Debern utilizarse siempre que sea posible. DD07 Las pruebas de integracin debern verificar que toda la informacin intercambiada a travs de una interfaz, concuerde con las especificaciones de la estructura de datos en el DDA. Esta prctica se aplica al DES. DD08 Las pruebas de integracin debern confirmar que el flujo de control definido en el DDA ha sido implementado. Esta prctica se aplica al DES. DD09 El sistema de pruebas deber verificar la concordancia con los objetivos del sistema, como est establecido en el DRS. Esta prctica se aplica al DES. DD10 Cuando el diseo de un componente principal est terminado, deber acordarse una revisin crtica del diseo para certificar su aptitud y conveniencia para la implementacin. DD11 Despus de la produccin, la revisin del DD (R/DD) deber considerar los resultados de las actividades de verificacin y decidir cual transferir al sof tware. DD12 Todos el cdigo entregable deber estar identificado en una lista de elementos de configuracin. DD13 El DDD deber ser una salida de la fase DD. No aplicable. La informacin detallada del diseo est establecida en el DES y en el cdigo fuente.
DD14 La parte 2 del DDD deber tener la misma estructura y esquema de identificacin que el cdigo en s mismo, con una correspondencia de 1:1 entre las secciones de la documentacin y los componentes de software. No aplicable. DD15 El DDD deber completarse, con una descripcin de todos los requisitos de software en del DRS. Esta prctica significa que todos los requisitos en el DES deben implementarse en el cdigo. DD16 Deber establecerse en el DDD una tabla de referencias cruzadas de los requisitos de software para el diseo detallado de los componentes. En su lugar se deber actualizar la matriz de trazabilidad en el DES. DD17 El Manual de Usuario de Software (MUS) deber ser una salida de la fase DD.
3.6 FASE TR
TR01 Los representantes de los usuarios y personal de operaciones debern participar en las pruebas de aceptacin. TR02 El Comit de Revisin de Software (del ingls SRB) deber revisar el desempeo del software en las pruebas de aceptacin y sugerir al encargado del proyecto en la empresa cliente (del trmino initiator), si el software puede aceptarse de manera provisional o no. TR03 Las actividades de la fase TR debern llevarse a cabo de acuerdo a los planes definidos en la fase DD. Los planes de la fase TR sern establecidos en la fase RU y actualizados cuando corresponda. TR04 Deber establecerse la capacidad de construir el sistema comenzando por los componentes que son directamente modificables por el equipo de mantenimiento. TR05 Debern indicarse en el PVVS las pruebas de aceptacin ne cesarias para la aceptacin provisional. TR06 El informe de la aceptacin provisional deber elaborarlo el encargado del proyecto en la empresa cliente, en favor de los usuarios, y enviarlo al desarrollador. TR07 La aceptacin provisional del sistema de software deber consistir en las salidas de todas las fases previas y en las modificaciones que sean necesarias en la fase TR. TR08 Una salida de la fase TR ser el DTS. TR09 El DTS ser entregado por el desarrollador a la organizacin de mantenimiento para su aceptacin provisional. TR10 El DTS deber incluir el resumen de los informes de las pruebas de aceptacin, y toda la documentacin sobre los cambios del software, realizados durante la fase TR.
3.7 FASE OM
OM01 Hasta la aceptacin final, las actividades de la fase OM que involucren al desarrollador debern llevarse a cabo de acuerdo a los planes definidos en el PAPS/TR. OM02 Todas las pruebas de aceptacin debern completarse exitosamente antes de que el software sea finalmente aceptado. OM03 Incluso cuando el contratista no est involucrado, habr un hito de aceptacin final para acordar la entrega formal del desarrollo de software a mantenimiento. OM04 Deber designarse una organizacin de mantenimiento para cada producto de software en produccin. OM05 Debern definirse los procedimientos para las modificaciones de software. OM06 Deber mantenerse la consistencia entre el cdigo y la documentacin. OM07 Debern asignarse recursos al mantenimiento del producto hasta que ste sea retirado. OM08 El SRB deber autorizar todas las modificaciones del software. OM09 La informacin de la aceptacin final deber producirla el responsable del proyecto en la empresa cliente , a favor de los de los usuarios, y enviarla al desarrollador. OM10 El DHP (Documento Histrico del Proyecto) deber entregarse al encargado del proyecto en la empresa cliente despus de la aceptacin final. No aplicable. Sin embargo, se alienta a los desarrolladores para que produzcan un DHP para uso interno.
APS08 Deber producirse (PAPS/DD) la seccin de la fase DD del PAPS durante la fase DA. No aplicable. Sin embargo, el PAPS debera actualizarse cuando el DES se ha producido. APS09 Deber incluirse en el PAPS/DD un costo estimado del total del proyecto. Esta prctica se aplica al PAPS. APS10 El PAPS/DD deber contener un WBS que est directamente relacionado con la descomposicin de software en componentes. Esta prctica se aplica al PAPS. APS11 El PAPS deber contener una red de planificacin que muestre la relacin entre las actividades de codificacin, integracin y prueba. Debera utilizarse un diagrama de barras (por ejemplo: Diagrama Gant) para mostrar la relacin. APS12 El trabajo de produccin de paquetes de software en PAPS/DD no debera durar ms de 1 mes-hombre. Esta prctica se aplica al PAPS. APS13 Durante la fase DD deber producirse la seccin correspondiente a la fase TR del PAPS (PAPS/TR). Esta prctica se aplica al PAPS.
ACM11 El mtodo de identificacin de la configuracin deber ser capaz de acomodar lo s nuevos EIs, sin requerir la modificacin de los identificadores de cualquier EIs existente. ACM12 En la fase TR, deber incluirse en el DTS una lista de los elementos de configuracin en la primera versin. ACM13 En la fase OM, deber incluirse en cada Nota de Entrega de Software (NES), una lista de los elementos de configuracin que se cambiaron. ACM14 Una NES deber acompaar cada entrega realizada en la fase OM. Como parte del mtodo de identificacin de configuracin, un mdulo de software tendr una cabecera que incluya: ACM15 * identificador de elemento de configuracin (nombre,tipo, versin); ACM16 * Autor original; ACM17 * Fecha de creacin; ACM18 * Cambios histricos (versin/fecha/autor/descripcin). Toda la documentacin y almacenamiento deber estar claramente etiquetada en un formato estndar, incluyendo al menos la siguiente informacin: ACM19 * nombre del proyecto; ACM20 * Identificador del elemento de configuracin (nombre, tipo, versin); ACM21 * fecha; ACM22 * descripcin del contenido. Para asegurar la seguridad y control del software, como mnimo, debern implementarse las siguientes libreras de software para almacenar todos los componentes disponibles (por ejemplo: documentacin, cdigos fuente y ejecutable, archivos de prueba, procedimientos de instrucciones): ACM23 * librera de Desarrollo (o Dinmica); ACM24 * librera Maestra (o Controlada); ACM25 * librera Esttica (o Archivo). ACM26 No debern modificarse las libreras estticas. ACM27 Las copias de seguridad actualizadas de las libreras Estticas y Maestra debern estar siempre disponibles. ACM28 Debern establecerse los procedimientos para realizar copias peridicas de respaldo de las libreras desarrolladas. ACM29 El cambio del procedimiento descrito (en Parte 2, Seccin 3.2.3.2.1) deber observarse cuando sean necesarios los cambios para entregar el documento. ACM30 Los problemas de software y las propuestas de cambio debern manejarse con el procedimiento descrito (en Parte 2, Seccin 3.2.3.2.2) ACM31 Deber grabarse el estado de todos los elementos de configuracin. Para realizar el estado de contabilidad del software, cada proyecto de software deber registrar: ACM32 * la fecha y versin/nmero de cada lnea base; ACM33 * la fecha y el estado de cada RID y DCR. ACM34 * la fecha y estado de cada SPR, SCR y SMR; ACM35 * una descripcin resumida de cada Elemento de Configuracin. ACM36 Como mnimo, la NES deber almacenar los defectos que se han reparado y los nuevos requisitos que se han incorporado.
ACM37 Para cada entrega, la documentacin y cdigo debern ser consistentes. ACM38 Las entregas antiguas se guardarn como referencia. ACM39 El software modificado deber probarse de nuevo antes de la entrega . ACM40 Todas las actividades de gestin de configuracin de software debern documentarse en el Plan de Gestin de Configuracin de Software (PGCS). ACM41 Los procedimientos de Gestin de Configuracin debern establecerse antes de que la produccin del software comience (cdigo y documentacin). ACM42 Al finalizarse la revisin de RU, deber elaborarse la seccin correspondiente a la fase RS del PGCS (PGCS/RS). Esta prctica se aplica al PGCS. ACM43 El PGCS/RS deber cubrir los procedimientos de gestin de configuracin para la documentacin, y cualquier salida de herramienta "CASE" o cdigo prototipo, producidos en la fase RS. Esta prctica se aplica al PGCS. ACM44 Durante la fase RS, deber producirse la seccin correspondiente a la fase DA del PGCS (PGCS/DA). No aplicable. ACM45 El PGCS/DA deber cubrir los procedimientos de gestin de configuracin para la documentacin, y cualquier salida de herramienta "CASE" o cdigo prototipo, producidos en la fase DA. Esta prctica se aplica al PGCS. ACM46 Durante la fase DA, se elaborar la seccin correspondiente a la fase DD del PGCS (PGCS/DD). No aplicable. ACM47 El PGCS/DD deber cubrir los procedimientos de gestin de configuracin para la documentacin, cdigo disponible, y cualquier salida de herramienta "CASE" o cdigo prototipo, producidos en la fase DD. Esta prctica se aplica al PGCS. ACM48 Durante la fase DD, se elaborar la seccin de la fase TR del PGCS (PGCS/TR). No aplicable. ACM49 El PGCS/TR deber cubrir los procedimientos para la gestin de la configuracin de los entregables en el entorno operacional. No aplicable.
VVS19 Los diseos de las pruebas unitarias, de integracin, de sistema y de aceptacin debern estar descritos en el PVVS. No aplicable. VVS20 Los casos de prueba debern describirse en el PVVS, para las pruebas unitarias de integracin, sistema y aceptacin. VVS21 Debern describirse en el PVVS los procedimientos de prueba de aceptacin, unitaria , de integracin y de sistema. VVS22 Debern describirse en el PVVS los informes de prueba de aceptacin, unitaria, integracin y sistema.
APNDICE A: GLOSARIO
A.1 LISTA DE SIGLAS Y ABREVIATURAS
DA Diseo arquitectnico. DDA Documento de Diseo Arquitectnico. ANSI "American National Standards Institute". PA Pruebas de Aceptacin. DD Diseo Detallado y produccin. DDD Diseo del Documento Detallado. AEE Agencia Espacial Europea. IEEE "Institute of Electrical and Electronics Engineers". PI Pruebas de Integracin. DHP Documento Histrico del Proyecto. PNE Procedimientos, Normas y Especificaciones. PGCS Plan de Gestin y Configuracin de Software. PAPS Plan de Administracin del Proyecto de Software. PACS Plan de Aseguramiento de Calidad de Software. RS Requisitos de Software. PS Prueba del Sistema. DTS Documento de Transferencia de Software. DRS Documento de Requisitos de Software. DES Documento de Especificacin de Software. MUS Manual de Usuario de Software. PVVS Plan de Validacin y Verificacin de Software. DRU Documento de Requisitos del Usuario. UP Unidad de Prueba. EAT Estructura de Interrupcin del Trabajo.
1
APNDICE B: REFERENCIAS
1. ESA Software Engineering Standards , ESA PSS-05-0 Nmero 2 Febrero de 1991. 2. Guide to the ESA Software Engineering Standards, ESA PSS-05-01 Nmero 1 Octubre de 1991. 3. Guide to the User Requirements Definition Phase, ESA PSS-05-02 Nmero 1 Octubre de 1991. 4. Guide to the Software Requirements Definition Phase, ESA PSS-05-03 Nmero 1 Octubre de 1991. 5. Guide to the Software Architectural Design Phase, ESA PSS-05-04 Nmero 1 Enero de 1992. 6. Guide to the Software Detailed Design and Production Phase, ESA PSS-05-05 Nmero 1 Mayo de 1992. 7. Guide to the Software Transfer Phase, ESA PSS -05-06 Nmero 1 Octubre de 1994. 8. Guide to the Software Operations and Maintenance Phase, ESA PSS-05-07 Nmero 1 Diciembre de 1994. 9. Guide to Software Proyect Management, ESA PSS-05-08 Nmero 1 Junio de 1994. 10. Guide to Software Configuration Management, ESA PSS-05-09 Nmero 1 Noviembre de 1992. 11. Guide to Software Verification and Validation, ESA PSS-05- 10 Nmero 1 Febrero de 1994. 12. Guide to Software Quality Assurance, ESA PSS-05-11 Nmero 1 Julio de 1993. 13. Software Engineering Economics, B.Boehm, Prentice-Hall (1981) 14. Achieving Software Quality with Testing Coverage Measures, J. Horgan, S.London y M. Lyu, "Computer", IIEE, Septiembre de 1994.
5.n.4 Dependencias Describe las precondiciones para utilizar estos componentes. 5.n.5 Procesamiento Describe el control y flujo de datos dentro del componente. Resume el procesamiento de los componentes de bajo nivel. 5.n.6 Datos Define en detalle los datos internos para los componentes, tales como los archivos utilizados para relacionarlos con los componentes principales. Por otra parte entrega una descripcin resumida. 5.n.7 Recursos Lista de los recursos requeridos, tales como pantallas e impresoras. 6 Viabilidad y estimacin de los recursos Resumen de los recursos del computador requeridos para construir, operar y mantener el software. 7 Matriz de Trazabilidad de Requisitos de Usuario frente a Requisitos de Software Muestra la correspondencia entre los requisitos de usuario y los requisitos de software que los resuelven. 8 Matriz de Trazabilidad de Requisitos de Software frente a Componentes Muestra la correspondencia entre los requisitos software y los componentes que los soportan.
4 [Seccin de instruccin] Desde el punto de vista del aprendiz, para cada tarea, entrega: (a) Descripcin funcional Qu realizar la tarea. (b) Precauciones y advertencias Qu hacer y qu no hacer. (c) Procedimientos Incluye: Programa de instalacin Operaciones de entrada Qu resultados esperar (d) Errores probables y sus causas Qu hacer cuando las cosas van mal . 5 [Seccin de referencia] Desde el punto de vista del experto, para cada operacin bsica, entrega: (a) Descripcin funcional Qu hace la operacin. (b) Precauciones y advertencias Qu hacer y qu no hacer. (c) Descripcin formal Parmetros requeridos Parmetros opcionales Opciones por defecto Parmetro orden y sintaxis (d) Ejemplos Entrega ejemplos probados de la operacin. (e) Posibles errores de mensajes y sus causas Lista de los posibles errores y sus causas probables. (f) Referencias cruzadas con otras operaciones Se refiere a cualquier operacin complementaria, anterior o posterior. Apndice A Mensajes de error y procedimientos de recuperacin Lista de todos los mensajes de error. Apndice B Glosario Lista de todos los trminos con significados especializados. Apndice C ndice (para manuales de 40 pginas o ms) Lista de todos los trminos importantes y sus ubicaciones.
3 Especificacio nes de los Casos de Prueba (para cada caso de prueba......) 3.n.1 Identificador de caso de prueba Asigna un identificador nico para cada caso de prueba. 3.n.2 Elementos de prueba Lista de los elementos que se probarn. 3.n.3 Especificaciones de entrada Describe la entrada para el caso de prueba. 3.n.4 Especificaciones de salida Describe la salida requerida del caso de prueba. 3.n.5 Necesidades de entorno Describe el entorno de prueba. 4 Procedimientos de prueba (para cada procedimiento de prueba.....) 4.n.1 Identificador del procedimiento de prueba Asigna un identificador nico para el procedimiento de prueba 4.n.2 Propsito Describe el propsito del procedimiento. Lista de los casos de prueba que ejecuta este procedimiento. 4.n.3 Pasos del procedimiento Describe como registrar, ajustar los parmetros, empezar, proceder, medir, cerrar, reiniciar, parar, adaptar la prueba, y como manejar contingencias. 5 Plantilla de Informe de Prueba 5.n.1 Identificador del informe de prueba Asigna un identificador nico para el informe de la prueba. 5.n.2 Descripcin Lista de los elementos que se probarn. 5.n.3 Actividad y eventos de entrada. Identifica el procedimiento de prueba. Indica cundo se hizo la prueba, quin la hizo, y quin la presencio. Indica si el software aprob o fall para cada caso de prueba cubierto por el procedimiento. Describe los problemas.