You are on page 1of 13

INTRODUCCIN

Los estndares de ingeniera de software ESA, definen las prcticas de software que deben
aplicarse en todos los proyectos de la agencia Europea. 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 informe proporciona las pautas sobre el
estndar y como se aplican.

PROPSITO
ESA describe los estndares de ingeniera de software que se aplicarn a todos los artefactos
software implementados por la Agencia Espacial Europea (ESA).

Este documento se ha producido para informar acerca de las directrices a las que organizaciones
y a los administradores de los proyectos de software usan, como una gua para la aplicacin de
los estndares a proyectos de software pequeos. En una serie de documentos descritos en ESA,
se entregan directrices adicionales para la aplicacin de los estndares, Gua de los Estndares
de Ingeniera de Software

TERMINOLOGA
DES Documento de Especificacin de Software
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.
ESA 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.

MARCO TERICO
Metodologa

Antes de hablar acerca del estndar ESA vamos a explicar el trmino metodologa como: El
conjunto de pasos y procedimientos que debe seguirse para el desarrollo de software.

El concepto tambin incluye:

- Como se debe dividir un proyecto en etapas.


- Que tareas se llevan a cabo en cada etapa.
- Heurstica para llevar a cabo dichas tareas.
- Que salidas se producen y cuando se deben producir
- Que restricciones se aplican.
- Que herramientas se van a utilizar.

Qu es mtodo de desarrollo de software?

Es un conjunto de procedimientos, tcnicas, herramientas, y un soporte documental que ayuda a


los desarrolladores a producir nuevo software.

- Modelo de proceso (fases y subfases, actividades, tareas).


- Procedimientos que dan lugar a productos.
- Tcnicas (graficas, textuales).
- Herramientas.

Puede acomodar varios ciclos de vida

- Ciclo de vida: que hay que producir, no cmo.


- Mtodo: qu y cmo

a. Estndar de la ESA PSS-05-02

Es la norma utilizada por la agencia espacial Europea (ESA, European Space Agency) para sus
desarrollos de software. Este documento est orientado principalmente a las empresas que
desarrollan software bajo contrato, ya que la agencia desarrolla poco software por s misma.
Estos estndares son bastante generales, y cada proyecto de gran envergadura suele
desarrollarlos ms, haciendo los estndares propios del proyecto. En caso de conflicto, se suele
establecer una jerarqua, en la que prima el estndar ms general.

En este estndar, se consideran todos los aspectos de un proyecto software. Adems del propio
desarrollo y su normativa, se contemplan los aspectos de:

- Gestin de proyecto.
- Gestin de configuracin.
- Control y garanta de calidad.

Las etapas que establece este documento para el ciclo de vida son las siguientes:

- Definicin de requisitos del usuario.


- Definicin de requisitos del software.
- Diseo de la arquitectura.
- Diseo detallado y produccin del software.
- Transferencia de la tecnologa al usuario.
- Operacin y mantenimiento.

La etapa que aparece nueva respecto al ciclo de vida clsico, es la de transferencia. En esta fase
al agencia, viendo los resultados de las pruebas, da su aceptacin provisional al software, y se
procede a la instalacin de la maquina objetivo, a la formacin de los usuarios, etc.
Esta fase tiene sentido, en tanto en cuanto, el software se suele desarrollar en pases distintos de
aquel que se va instalar posteriormente, y por lo tanto, la fase de instalacin precisa de
desplazamiento de personal, y otras peculiaridades.

En el estndar se contemplan para cada fase los siguientes aspectos:

- Entradas.
- Actividades.
- Salidas.

Adems, y para cada uno de los tres aspectos mencionados: gestin del proyecto y de las
configuraciones y control de calidad, se describen los planes necesarios para su ejecucin, as
como los documentos e hitos asociados.

Las ventajas fundamentales de este estndar es que es muy sencillo y fcil de comprender, con
lo que se pueden tomar como punto de referencia para desarrollos propios en cualquier otro
entorno.

b. CICLO DE VIDA DEL SOFTWARE

El estndar ESA PSS-05-02 divide el ciclo de vida del software en seis fases principales y
cuatro fases complementarias de revisin. Y son:

- Fase RU - Definicin de los requisitos de usuario.


- Fase RS - Definicin de los requisitos de software.
- Fase DA - Definicin del diseo arquitectnico.
- Fase DD - Diseo detallado y produccin del cdigo.
- Fase TR - Transferencia de software a las operaciones.
- Fase OM - Operaciones y mantencin.
FASES DE UN PROYECTO DE SOFTWARE BASADO EN EL ESTANDAR ESA
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.

FASE RS/DA

RS01 Las actividades de la fase RS debern ser llevadas a cabo de acuerdo a los planes
definidos en la fase RU.
RS02 El desarrollador deber construir un modelo de implementacin independiente de lo que
necesita el usuario.
RS03 Deber adoptarse un mtodo reconocido para analizar los requisitos de software y
aplicarlo adecuadamente en la fase RS.
Esta prctica se aplica a la fase RS/DA
RS04 Cada requisito de software deber incluir un identificador.
RS05 Debern sealarse como tales los requisitos esenciales de un software.
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 cmo
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.
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 adecuadamente 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.

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 cul transferir al software.
DD12 Todo 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.

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.

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.
Conclusiones

El estndar de la ESA propone un conjunto de procesos que pueden servir como un


esquema para la elaboracin de proyectos pequeos, pero que cumplen con un estndar
internacional el cual le da una formalidad a la elaboracin del software
Es adaptable, ya que puede ser incorporado en la elaboracin de un software para una
empresa con la normativa del caso.
Es simple, por lo tanto, con poca prctica se puede hacer un buen uso de l y adecuarse
para la elaboracin de cualquier proyecto.
REFERENCIAS BIBLIOGRFICAS

I. Sommerville, P. Sawyer(1999) Requirements Engineering, A Good Practice


Guide.Wiley,
S. Robertson, J. Robertson (1999). Mastering the Requirements Process. Addison-
Wesley.
ESA, SOFTWARE ENGINEERING STANDARDS, ISSUE 2. Preparado por: ESA
Board for Software Standardisation and Control (BSSC). URL:
http://www.estec.esa.nl/wmwww/WME/index.html