Está en la página 1de 15

FACULTAD DE INGENIERIA Y ARQUITECTURA

ESCUELA PROFESIONAL DE INGENIERIA DE SISTEMAS

TEMA:
METODOLOGIA ESA PSS

ASIGNATURA:

Anlisis y diseo de sistemas II

DOCENTE:

Ing. Luis Alberto Sota Orellana

ALUMNOS:

Arias Vera, Carlos Eduardo


Escobedo Baca, Kyle
Vargas Noriega, Camila Jimena
Ugarte Portilla, Fredy ngel

CUSCO PER
Junio de 2016

ndice
Metodologa........................................................................................................ 3
Introduccin........................................................................................................ 3
Marco Terico........................................................................................................ 4
Definiciones Previas......................................................................................... 4
Metodologa de desarrollo de software.........................................................4
Caractersticas................................................................................................. 4
Ciclo de vida de software................................................................................. 4
Fases del proyecto........................................................................................ 4
Conclusiones..................................................................................................... 10
Referencias Bibliogrficas................................................................................. 11

Pgina 2

Metodologa
El presente informe fue puesto en pie a partir un corto proceso que inicia con el
subproceso denominado como recoleccin de datos. Consiste en una
recopilacin de informacin, en especial provenientes de fuentes de las cuales
tengamos conocimiento puedan brindarnos informacin veraz y confiable;
haciendo que en las siguientes partes del proceso no tengamos informacin de
ms, debido a su poca utilidad y reducindonos el trabajo de clasificacin y
anlisis de esta.
El siguiente paso que conforma este proceso es el del anlisis de la informacin,
a consecuencia de su lectura; La clasificacin fue el paso adyacente que se tom
para la elaboracin del informe; separacin entre conceptos.
De forma externa a la informacin que netamente concierne al informe. Se estable
la informacin que permiti estructurar el informe, y las reglas APA para la
escritura de referencias bibliogrficas.

Introduccin
El estndar de la ESA presenta un marco general que puede
ser utilizado para abordar un proyecto de software.
El estndar establece las macro-actividades que deben
hacerse en el proyecto, los roles involucrados, y los productos
intermedios que deberan obtenerse.

Pgina 3

Marco Terico
Definicin Previa
El estndar establece las macro-actividades que deben
hacerse en el proyecto, los roles involucrados, y los productos
intermedios que deberan obtenerse.

Caractersticas

Combinacin de los requisitos de software y fase del diseo


arquitectnico.
Utilizacin de las plantillas de documentos simplificadas.
Informacin detallada del diseo incluida en el cdigo fuente.
Combinacin de los planes.
Disminucin de los requisitos de formalidad.
No hay elaboracin de documentacin de diseo de pruebas.
Seleccin de pruebas del sistema que se usan para la aceptacin de
pruebas.
No hay aplicacin de todas las prcticas de SQA.
No hay obligacin de entregar el Documento Histrico del Proyecto.

Ciclo de vida de software

Pgina 4

Fases del proyecto

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.

Fase RU: Definicin de requisitos de usuario

Deber ser responsabilidad del usuario la definicin de los requisitos de


usuario.
Cada requisito de usuario deber incluir un identificador.
Los requisitos esenciales de usuario debern ser marcados como tales.
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.
Deber establecerse la fuente de cada requisito de usuario.
Deber verificarse cada requisito de usuario.
El usuario deber describir las consecuencias de las prdidas de
disponibilidad, o violaciones de seguridad, de tal manera que los
desarrolladores puedan apreciar en su totalidad lo crtico de cada funcin.
Debern revisarse formalmente las salidas de la fase RU durante la
Revisin de
Requisitos de Usuario.
Debern sealarse claramente los requisitos de usuario no aplicables.
Un producto de la fase RU deber ser el Documento de Requisitos de
Usuario (DRU).
El DRU deber producirse siempre antes de que el proyecto de software
empiece.
El DRU proporcionar una descripcin general de lo que el usuario espera
que haga el software.
Debern incluirse todos los requisitos de usuario conocidos en el DRU.
El DRU deber describir las operaciones que el usuario quiere realizar con
el sistema software.
El DRU deber definir todas las restricciones a las que el usuario desea
imponer una solucin.
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.
Pgina 5

Qu compete a esta fase?


o
o
o
o
o
o
o

Definicin del problema.


Los requisitos del usuario deben ser capturados.
Entrevistas, encuestas, formularios, prototipos.
El apoyo de los desarrolladores en esta etapa vara dependiendo de la
familiaridad de los usuarios con el software.
Se genera un Documento de Requisitos de Usuario (URD) siempre.
Participan los usuarios, los ingenieros de software y el administrador del
proyecto.
Antes de completar la UR/R, debe construirse un Plan de Administracin
del Proyecto de Software que muestre todas las fases siguientes, con
estimacin de recursos.

Fase RS: Definicin de requisitos de software

Las actividades de la fase RS debern ser llevadas a cabo de


acuerdo a los planes definidos en la fase RU.
El desarrollador deber construir un modelo de implementacin
independiente de lo que necesita el usuario.
Deber adoptarse un mtodo reconocido para analizar los
requisitos de software y aplicarlo adecuadamente en la fase RS.
Cada requisito de software deber incluir un identificador.
Debern sealarse como tales los requisitos esenciales de un
software.
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.
Los requisitos software debern ir acompaados de las referencias
a los RU que trazan, segn el etiquetado del DRU.
Deber ser verificable cada requisito de software.
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.
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).
El DRS debe ser completo. Esta prctica se aplica al DES.
El DES deber cubrir todos los requisitos establecidos en DRU. Esta
prctica se aplica al DES.
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.
Pgina 6

El DRS deber ser consistente. Esta prctica se aplica al DES.


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.
Descripciones de funciones, debern decir para qu es el software,
y evitar decir
cmo se elabor.
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. 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.

Qu compete a esta fase?


o
o
o
o
o
o
o
o
o
o

Fase de anlisis del proyecto.


Parte vital de la descripcin del modelo, que especifica qu debe hacer
el software (y no cmo debe hacerlo).
Puede ser necesario escribir prototipos para clarificar requisitos de
software y completar los requisitos del usuario.
El producto de esta fase es el Documento de Requisitos del Software
(SRD).
Cada proyecto de software debe contar con este documento.
Debe omitirse todo detalle de implementacin.
El documento debe ser revisado por los usuarios, los ingenieros de
software y por el administrador del proyecto durante la Revisin de
Requisitos del Software (SR/R).
El Plan de Administracin del Proyecto de Software debe revisarse en
esta fase.
Deben hacerse los mayores esfuerzos para tener estimaciones con
errores menores del 30%.
Debe construirse un plan detallado como base para la fase de DA

Fase DA: Definicin del diseo arquitectnico

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.
Deber adoptarse y aplicarse adecuadamente un mtodo
reconocido para el diseo de software en la fase DA.
Pgina 7

Esta prctica se aplica a la fase RS/DA.


El desarrollador deber construir un modelo fsico, que describa el
diseo de software utilizando terminologa de implementacin.
El mtodo utilizado para descomponer el software en las partes
que lo componen
deber permitir un acercamiento "Top-Down".
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.

Datos de entrada;
Funciones que se van a realizar;
Datos de Salida.

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:
La descripcin de cada elemento (por ejemplo: nombre, tipo,
tamao);
Las relaciones entre los elementos (por ejemplo: la estructura);
La variacin de los posibles valores de cada elemento;
Valores iniciales de cada elemento DA10, 11, 12, 13 se aplican al
DES.
Deber definirse en el DDA el flujo de control entre los
componentes.
Esta prctica se aplica al DES.
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.
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.
El DDA definir los principales componentes de software y las
interfaces entre ellos. Esta prctica se aplica al DES.
DDA mencionar todas las interfaces externas. Esta prctica se
aplica al DES.
El DDA ser una salida de la fase DA. Esta prctica se aplica al
DES.
El DDA se completar, abarcando todos los requisitos de software
descritos en el DRS. Esta prctica se aplica al DES.

Pgina 8

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.
El DDA deber ser consistente. Esta prctica se aplica al DES.
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.
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.

Qu compete a esta fase?


o

En esta fase se define la estructura del software a partir del modelo


construido en la fase SR.
o Este modelo se transforma en diseo arquitectnico asignando
funciones a componentes de software y definiendo el control y
flujo de datos entre ellos.
o Puede ser necesario iterar varias veces en el diseo.
o Las dificultades tcnicas y partes crticas del sistema deben ser
identificadas.
Puede ser necesario construir prototipos para comprobar la
factibilidad tcnica.
o El item entregable es el Documento de Diseo Arquitectnico
(ADD).
o El ADD debe ser formalmente revisado por los ingenieros de
software, los usuarios y el administrador del proyecto durante la
AD/R.
o En esta fase debe refinarse el Plan de Adminsitracin de Proyecto
de Software para el resto del proyecto. debe contener una
estimacin del costo del proyecto con un error menor al 10%.
o Tambin debe hacerse un plan detallado para la fase de DD.

Fase DD: Diseo detallado y produccin de


cdigo
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:
* Descomposicin "Top-Down"
Pgina 9

* Programacin estructurada /Programacin OO


* Documentacin y produccin concurrente.
Los procesos de integracin debern ser controlados por los procedimientos
de gestin de configuracin de software, definidos en PGCS.
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.
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.
Las pruebas de integracin debern confirmar que el flujo de control definido
en el DDA ha sido implementado. Esta prctica se aplica al DES.
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.
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.
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.
Todo el cdigo entregable deber estar identificado en una lista de elementos
de configuracin.
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.
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.

Pgina 10

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.
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.
El Manual de Usuario de Software (MUS) deber ser una salida de la fase DD.
Qu compete a esta fase?
o
o

o
o
o
o

El propsito de esta fase es el de detallar el diseo de software,


codificarlo, documentarlo y probarlo.
En forma concurrente se hacen:
la condificacin y las pruebas,
los documentos de diseo detallado (DDD) y manual de
software del usuario (SUM).
Los documentos DDD y SUM contienen:
las secciones de los niveles superiores del sistema.
a medida que el diseo progresa, tambin las subsecciones
relacionadas con los niveles ms bajos.
Al final de la fase, los documentos estn completos y, junto con el
cdigo, constituyen los tems entregables.
En esta fase se realizan las pruebas de unidad, de integracin y de
sistema, de acuerdo con los planes de pruebas establecidos en SR
y AD.
Los 3 entregables (cdigo, DDD y SUM) deben ser revisados
formalmente por los ingenieros de software y el administrador
(DD/R).
Al final de la revisin, el software puede considerarse listo para las
pruebas de aceptacin provisional.

FASE TR: Transferencia de software a


operaciones
Los representantes de los usuarios y personal de operaciones debern
participar en las pruebas de aceptacin.
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.

Pgina 11

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.
Deber establecerse la capacidad de construir el sistema comenzando por los
componentes que son directamente modificables por el equipo de
mantenimiento.
Debern indicarse en el PVVS las pruebas de aceptacin necesarias para la
aceptacin provisional.
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.
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.
Una salida de la fase TR ser el DTS.
El DTS ser entregado por el desarrollador a la organizacin de
mantenimiento para su aceptacin provisional.
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.
Qu compete a esta fase?

o El propsito de esta fase es establecer que el software cumple con


los requisitos especificados en el URD.
o Esto se realiza instalando el software y aplicando las pruebas de
aceptacin.
o Si el software muestra las capacidades requeridas, entonces
puede ser aceptados provisionalmente y con ello comienza la
operacin.
o Como producto de la transferencia (TR) se genera el Documento
de Transferencia del Software (STD) que documenta el proceso
para el equipo de operaciones.

Pgina 12

FASE OM: Operacin y mantenimiento


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.
Todas las pruebas de aceptacin debern completarse exitosamente antes de
que el software sea finalmente aceptado.
Incluso cuando el contratista no est involucrado, habr un hito de aceptacin
final para acordar la entrega formal del desarrollo de software a
mantenimiento.
Deber designarse una organizacin de mantenimiento para cada producto
de software en produccin.
Debern definirse los procedimientos para las modificaciones de software.
Deber mantenerse la consistencia entre el cdigo y la documentacin.
Debern asignarse recursos al mantenimiento del producto hasta que ste
sea retirado.
El SRB deber autorizar todas las modificaciones del software.
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.
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.
Qu compete a esta fase?
o
o
o
o

Una vez en operacin, el software debe monitorearse para confirmar que


cumple los requisitos del URD.
Algunos requisitos, especialmente los no funcionales, puede tomar algn
tiempo validarlos.
El software se acepta en forma definitiva cuando ha pasado todos las
pruebas.
El documento de historia del proyecto (PHD) resume la informacin
administrativa relevante acumulada durante el proyecto
o este documento se genera despus de la aceptacin final,
Pgina 13

debe rehacerse al final del ciclo de vida incluyendo la informacin


de la fase OM.
Despus de la aceptacin final, el software puede ser modificado
o para corregir errores no detectados durante fases anteriores,
o para incluir nuevos requisitos.
Durante todo el perodo de operacin debe hacerse un esfuerzo especial
para mantener toda la documentacin actualizada.
La informacin sobre fallas y cadas debe registrarse para establecer
mtricas de calidad del software para ser usadas en proyectos
subsiguientes.
o

o
o

Conclusiones
-

ESA propone un conjunto de actividades para abordar el


ciclo de vida de un proyecto de software.
Puede ser adaptado para la realidad de una empresa
especfica.
Puede ser aplicado en forma parcial, segn la naturaleza
del problema a resolver.

Referencias Bibliogrficas
Berzal, F. (2008). El ciclo de vida de un sistema. Obtenido de
http://elvex.ugr.es/idbis/db/docs/lifecycle.pdf
Cabrera, M. I. (Mayo de 1996). Gua para la aplicacin de.
Manuel Rey, J. D. (16 de Junio de 2014). PSS-05. Obtenido de
https://prezi.com/c__mmvkoqk37/pss-05-0/
Ochoa, S., & Bastarrica, M. C. (2008). Estndar de Ingeniera de. Obtenido de
http://www.face.ubiobio.cl/~cgutierr/clase04-2.pdf
Padla, D. F. (2003). Apuntes de taller de Ingenieria de Software. Obtenido de
http://es.slideshare.net/Isa06t/roles-desarrollo-software

Pgina 14

Pgina 15