Metodolog A para El Desarrollo de Sistemas V1 - 4

Comisin Nacional de los Sistemas de Ahorro para el Retiro
Gua Metodologca para el Desarrollo y Mantenimiento de Aplicativos de Cmputo

V 1.4 Marzo de 2004
Direccin General de Informtica
Contenido
CICLO DE VIDA DEL DESARROLLO DE SISTEMAS................................................................ 1 ETAPAS ..................................................................................................................................... 1 ACTIVIDADES A DESARROLLAR .................................................................................................. 4 EQUIPOS DE TRABAJO................................................................................................................ 5 DOCUMENTACIN ....................................................................................................................... 7 USO DE MTODOS Y ESTNDARES ............................................................................................. 8 RESUMEN DE LAS ETAPAS DEL CICLO DE VIDA................................................................... 1 1. 2. 3. 4. 5. 6. 7. 8. 1. DEFINICIN DE REQUERIMIENTOS...................................................................................... 1 ANLISIS DE REQUERIMIENTOS ......................................................................................... 1 DISEO PRELIMINAR ......................................................................................................... 2 DISEO DETALLADO ......................................................................................................... 2 IMPLANTACIN ................................................................................................................. 3 PRUEBA DEL SISTEMA ...................................................................................................... 3 PRUEBAS DE ACEPTACIN................................................................................................ 4 MANTENIMIENTO Y OPERACIN ......................................................................................... 4 ETAPA DE DEFINICIN DE REQUERIMIENTOS ............................................................. 7 PROPSITO ................................................................................................................................ 8 FUNCIONES ................................................................................................................................ 8 ACTIVIDADES ............................................................................................................................. 8 DOCUMENTACIN ....................................................................................................................... 9
DESCRIPCIN DE CONCEPTOS OPERACIONALES (OCD) .......................................................................... 9
ELEMENTOS ............................................................................................................................... 9
REQUERIMIENTOS.................................................................................................................................. 9
2.
ANLISIS DE REQUERIMIENTOS................................................................................... 11 PROPSITO .............................................................................................................................. 12 FUNCIONES .............................................................................................................................. 12 ACTIVIDADES ........................................................................................................................... 12 DOCUMENTACIN ..................................................................................................................... 12
ESPECIFICACIN DEL SISTEMA Y SUBSISTEMA (SSS) ............................................................................ 12
ELEMENTOS ............................................................................................................................. 13
SISTEMA ............................................................................................................................................. 13
INTERFACES ........................................................................................................................................ 13 ESPECIFICACIONES GENERALES ........................................................................................................... 14 ESPECIFICACIONES DETALLADAS.......................................................................................................... 14
3.
DISEO PRELIMINAR ...................................................................................................... 15 PROPSITO .............................................................................................................................. 16 FUNCIONES .............................................................................................................................. 16 ACTIVIDADES ........................................................................................................................... 16 DOCUMENTACIN ..................................................................................................................... 17
DESCRIPCIN DEL DISEO DEL SISTEMA/SUBSISTEMA (SSDD) ............................................................. 17
ELEMENTOS ............................................................................................................................. 17
DIMENSIONES DE LOS SISTEMA ............................................................................................................ 17 DISEO DEL SISTEMA .......................................................................................................................... 19
4.
DISEO DETALLADO ...................................................................................................... 23 PROPSITO .............................................................................................................................. 24 FUNCIONES .............................................................................................................................. 24 ACTIVIDADES ........................................................................................................................... 24 DOCUMENTACIN ..................................................................................................................... 25
ESPECIFICACIN DE REQUERIMIENTOS DEL SOFTWARE (SRS) .............................................................. 25 DESCRIPCIN DEL DISEO DEL SOFTWARE (SDD) ................................................................................ 25
ELEMENTOS ............................................................................................................................. 26
DISEO DEL SISTEMA .......................................................................................................................... 26
5.
IMPLANTACIN................................................................................................................ 29 PROPSITO .............................................................................................................................. 30 FUNCIONES .............................................................................................................................. 30 ACTIVIDADES ........................................................................................................................... 31 PRODUCTOS ............................................................................................................................ 31
6.
PRUEBAS DEL SISTEMA ................................................................................................ 33 PROPSITO .............................................................................................................................. 34 FUNCIONES .............................................................................................................................. 34

INTEGRACIN DE UNIDADES DE SOFTWARE Y SUS PRUEBAS .................................................................. 34 LAS PRUEBAS DE COMPONENTES DE SOFTWARE .................................................................................. 34
ACTIVIDADES ........................................................................................................................... 35 DOCUMENTACIN ..................................................................................................................... 36

DESCRIPCIN DE LAS PRUEBAS DEL SOFTWARE (STD) ......................................................................... 36
ii
7.
PRUEBAS DE ACEPTACIN........................................................................................... 37 PROPSITO .............................................................................................................................. 38 FUNCIONES .............................................................................................................................. 38 ACTIVIDADES ........................................................................................................................... 39 DOCUMENTACIN ..................................................................................................................... 39
REPORTE DE LAS PRUEBAS DEL SISTEMA (STR)................................................................................... 39 MANUAL DE USUARIO DEL SOFTWARE (SUM) ....................................................................................... 39
8.
MANTENIMIENTO Y OPERACIN................................................................................... 41 PROPSITO .............................................................................................................................. 42 FUNCIONES .............................................................................................................................. 42 ACTIVIDADES ........................................................................................................................... 42
ANEXO: ACTIVIDADES Y DOCUMENTACIN POR TIPO SISTEMA ..................................... 43 ANEXO: PLANTILLAS PARA LA DOCUMENTACIN DE SISTEMAS ................................... 45 1. 2. 3. 4. 5. 6. 7. 8. DESCRIPCIN DE CONCEPTOS OPERACIONALES (OCD) .................................................. 45 ESPECIFICACIN DE SISTEMA Y SUBSISTEMAS (SSS)...................................................... 45 DESCRIPCIN DEL DISEO DE SISTEMA Y SUBSISTEMAS (SSDD) .................................... 45 ESPECIFICACIN DE REQUERIMIENTOS DE SOFTWARE (SRS) .......................................... 45 DESCRIPCIN DEL DISEO DEL SOFTWARE (SDD) .......................................................... 45 DESCRIPCIN DE PRUEBAS DEL SOFTWARE (STD) ......................................................... 45 REPORTE DE PRUEBAS DEL SOFTWARE (STR)................................................................ 45 MANUAL DE USUARIO DEL SOFTWARE (SUM) ................................................................. 45
iii
iv
Metodologa para el Desarrollo de Sistemas

Ciclo de Vida del Desarrollo de Sistemas
Etapas
El proceso de desarrollo de sistemas comprende una serie de ocho etapas secuenciales, conjuntadas bajo el nombre de Ciclo de Vida del Desarrollo de Sistemas.
1. Definicin de Requerimientos 2. Anlisis de Requerimientos 3. Diseo Preliminar 4. Diseo Detallado 5. Implementacin 6. Pruebas del Sistema 7. Pruebas de Aceptacin 8. Mantenimiento y Operacin
Cada etapa del Ciclo de Vida del Desarrollo de Sistemas est caracterizado por actividades especficas y por los productos que se generan en cada una de las actividades. Las ocho etapas en las que se divide el Ciclo de Vida se llevan a cabo en periodos de tiempo consecutivos que, en estricto sentido, no se sobreponen, sin embargo, por sus caractersticas las actividades de una etapa generalmente continuarn llevndose a cabo en otras etapas, aunque cada vez en menor proporcin y menor significado. La figura siguiente muestra, por ejemplo, que aunque la mayor parte del trabajo en el anlisis de requerimientos ocurre durante la etapa de anlisis de requerimientos, parte de estas
actividades continan en las etapas posteriores, como vayan evolucionando los requerimientos.
Fases del Ciclo de Vida
Anlisis de Diseo Requerimientos Preliminar 100 90 80 Porcentaje de Esfuerzo 70 60 50 40 30 20 Definicin de Requerimientos 10 0 Anlisis de Requerimientos Diseo Implementacin Pruebas Aceptacin Diseo Detallado Implementacin Pruebas Aceptacin
Definicin de Requerimientos 20 30 40 50 60 Porcentaje de Tiempo del Proyecto 70 80 90 100
10
Dependiendo del orden en que se desarrollen las actividades y la forma en que se vayan liberando productos, las actividades del desarrollo de sistemas se pueden llevar a cabo dentro de diferentes ciclos de vida. Adicionalmente al de cascada, se encuentran entre los ms usados: el Evolutivo, Prototipos Rpidos y el Incremental. Cascada. Asume que la produccin total del sistema puede construirse en la primera ejecucin de las etapas del ciclo de vida del desarrollo (no descarta mejorar, corregir o adaptar el sistema a futuro). El estilo de desarrollo es de fcil manejo y bajo costo, sin embargo no tiene ningn resultado hasta el final del ciclo. Todo de una vez, cada paso una sola vez: determinar necesidades, definir requerimientos, diseo del sistema, implantacin, pruebas, correcciones y liberacin. Incremental. Construye el sistema en pequeos pasos, en el que en cada paso del desarrollo se produce un activo til. Es menos prctico que los mtodos tradicionales, pero fragmentando el sistema en grupos de tipos de objetos que encapsulan datos y operaciones, se pueden desarrollar fragmentos de la aplicacin para produccin con calidad, dentro de cada ciclo parcial. Determinar las necesidades del usuario y definir los requerimientos del sistema, despus de esto, desarrollar el resto del sistema en bloques secuenciales, cada bloque agrega ms capacidades al sistema. Evolutivo. Asume que llevar varias ejecuciones de algunas etapas del ciclo de vida obtener un sistema de calidad. En lugar de eso utiliza las tcnicas de desarrollo rpido
para producir bien el 70% aproximadamente del sistema, el cual se usa en produccin o algo cercano a produccin. Se generan versiones sucesivas del sistema usando ciclos adicionales de las actividades de desarrollo, hasta conseguir el sistema de produccin deseable. Tambin es en bloques, slo que todos los requerimientos no pueden definirse en una sola etapa, por lo que las necesidades del usuario y los requerimientos se definen parcialmente al inicio del proyecto y posteriormente se van refinando despus de cada liberacin de bloques. Prototipos Rpidos. Es una variante del desarrollo evolutivo, en donde los ciclos son ms rpidos y el alcance menor, las liberaciones parciales son usadas solo en modo de prueba y no en produccin. Es usado normalmente para el diseo de la interfaz de usuario, pero algunos la promueven como una tcnica para encontrar elementos ms all del dominio del problema. Ambas se posicionan en el desarrollo de sistemas que involucran grados de interaccin altos con el usuario, o nuevos estilos de interfaces.
Evolutivo
Versin uno Versin dos Versin tres
Prototipo Rpido
Mdulo uno
Incremental
Mdulo dos Mdulo tres
E1 E2 E1
Prototipo Uno Prototipo Dos Prototipo Tres
E1 E2 E3 E4 E2 E3 E4 E2 E3 E4 E5
E1 E2 E2 E3 E4 E5 E2 E3 E4 E5
E3 E2 E1 E4 E3 E2 E4 E3 E4 E5
E3 E4 E5
Cada una de las estrategias de desarrollo est determinada por la informacin disponible, para lo cual el tipo de ciclo de vida a utilizar debe contestar las preguntas del cuadro siguiente, con las respuestas mostradas, para que sea aplicable.
Estrategia Cascada Incremental Evolutivo Estn definidos todos los requerimientos? Si Si No Mltiples ciclos de desarrollo? No Si Si Campos de Intervalos en el software? No Probable Si
El cuadro siguiente proporciona algunas recomendaciones que pueden utilizarse para evaluar y determinar el ciclo de vida a utilizar. Calificar de acuerdo con: NR=Nivel de riesgo: alto=3, medio=2 y bajo=1 NO=Nivel de oportunidad: alto=3, medio=2 y bajo=1
Incremental NR Razones en contra NR Evolutivo Razones en contra NR
Cascada Razones en contra
No usar Los requerimientos no estn 1 cuando bien entendidos El sistema es muy grande o 2 complejo para construirlo de una pasada Se esperan cambios rpidos en 3 las funciones y cambios tecnolgicos que pueden cambiar los requerimientos Personal o presupuesto limitado 3 Puntuacin Oportunidad a favor Usar cuando 9 NO
NO se entienden totalmente los 1 requerimientos El usuario prefiere todas las 2 funciones del sistema en una liberacin Se esperan cambios rpidos en 1 las funciones y cambios tecnolgicos que pueden cambiar los requerimientos El usuario prefiere todas las 2 funciones del sistema en una liberacin
Puntuacin Oportunidad a favor
4 NO
Puntuacin Oportunidad a favor
2 NO
El usuario prefiere todas las 2 funciones del sistema en una liberacin El usuario prefiere una sola fase 1 para todo el sistema de una vez
Se requieren algunas funciones 3 al principio El sistema se parte en forma 2 natural Los recursos y presupuesto se 3 ira incrementando con el tiempo
Se requieren algunas funciones 3 al principio El sistema se parte en forma 2 natural Los recursos y presupuesto se 3 ira incrementando con el tiempo La retroalimentacin del usuario 3 y el monitoreo del cambio tecnolgico es necesario para entender totalmente los requerimientos
Puntuacin
Puntuacin
Puntuacin
11
Es recomendable utilizar la estrategia que obtenga mejor diferencial entre el total de los niveles de oportunidad y los niveles de riesgo.
Actividades a Desarrollar
Las actividades a desarrollar para cada una de las etapas estn determinadas por el tipo de sistemas a desarrollar. Para los trminos de la presente gua, se consideran los siguientes tipos de sistemas.
Software Personal. Software que se ejecutar en una computadora personal, y que su uso esta restringido a una persona o un nmero limitado de personal. Software Web. Software que operar con una interfaz acezada por un navegador de Internet, prestando servicio a un nmero limitado de usuarios.
Software Administrativo. Sistemas que soportan los niveles administrativos o en apoyo a una funcin especifica de una empresa. No son de misin crtica, y la operacin de la empresa no se ve afectada sustantivamente por su carencia o fallas en su funcionamiento. Software Estratgico. Sistemas de misin crtica orientados al apoyo de los principales procesos del negocio, que soportan la operacin de los principales productos y servicios a los que est orientada la Institucin. Sistema Complejo. Conjunto de software que interacta y se interrelaciona, apoyando diferentes dominios de la operacin de una organizacin, as como diferentes proceso o etapas de procesos muy complejos y crticos.
Por lo anterior, las etapas y documentos que se generen como parte de los trabajos consideran el tipo de sistema a desarrollar, de acuerdo a la tabla del Anexo: Actividades y Documentacin por Tipo Sistema de este documento.
Equipos de Trabajo
Para llevar a cabo el proceso de desarrollo de aplicaciones, se conforman cinco equipos de trabajo orientados a la ejecucin de las etapas.
1. 2. 3. 4. 5.
Equipo de Definicin de Requerimientos Equipo de Desarrollo Equipo de Pruebas de Aceptacin Equipo de Pruebas del Sistemas Equipo de Mantenimiento y Operacin
Al igual que en las actividades, la participacin de los equipos de trabajo no es consecutiva, como resultado de los traslapes de las actividades relacionadas con las etapas del ciclo de vida, la participacin de los equipos de trabajo tambin se presentar en etapas posteriores a las de su responsabilidad, pero con menor participacin. El cuadro siguiente muestra la participacin de los equipos de trabajo en cada una de las etapas. El primer equipo en aparecer en la lista (en negrillas) es el responsable principal de llevar a cabo las actividades comprendidas en ella, los equipos subsecuentes apoyarn en algunas de las actividades.
Etapas 1. Definicin de Requerimientos 2. Anlisis de Requerimientos 3. Diseo Preliminar 4. Diseo Detallado
Equipos de Trabajo Equipo de Definicin de Requerimientos Equipo de Definicin de Requerimientos Equipo de Desarrollo Equipo de Desarrollo Equipo de Definicin de Requerimientos Equipo de Desarrollo Equipo de Definicin de Requerimientos Equipo de Pruebas de Sistemas
5. Implementacin
Equipo de Desarrollo Equipo de Definicin de Requerimientos Equipo de Pruebas de Sistemas Equipo de Pruebas del Sistemas Equipo de Desarrollo Equipo de Pruebas de Aceptacin Equipo de Pruebas del Sistemas Equipo de Desarrollo Equipo de Mantenimiento y Operacin Equipo de Desarrollo
6. Pruebas del Sistema 7. Pruebas de Aceptacin
8. Mantenimiento y Operacin
La conformacin de los grupos de trabajo contendr personal directivo del rea responsable del desarrollo y mantenimiento de los sistemas de informacin y de la infraestructura, de las reas usuarias y personal de desarrollo, tanto externo como interno. La participacin deber considerar los siguientes criterios:
Equipo de Definicin de Requerimientos: Directores Generales o equivalentes, Directores de rea, Directivos de la(s) Unidad(es) Administrativa(s), Coordinadores, Subdirectores, Jefes de rea o de Divisin de la(s) Unidad(es) Administrativa(s) involucradas, usuarios afectados por el uso del sistema. Equipo de Desarrollo: Directivos de la(s) Unidad(es) Administrativa(s), Subdirectoresw, Coordinadores, Jefes de rea o Divisin de la(s) Unidad(es) Administrativa(s) involucradas, usuarios afectados por el uso del sistema; Directores, Subdirectores, Jefes de rea o Divisin del rea responsable del desarrollo de sistemas, dependiendo de las especialidades que se requieran en el desarrollo del sistema (comunicaciones, equipo, uso de servidores, Internet o Intranet, bases de datos, etc.), y, personal de empresas externas, en caso de que el desarrollo se efecte por terceros. Equipo de Pruebas de Sistemas: Directivos de la(s) Unidad(es) Administrativa(s), Coordinadores, Subdirectores, Jefes de rea o Divisin de la(s) Unidad(es) Administrativa(s) involucradas, usuarios afectados por el uso del sistema; Directores, Subdirectores, Jefes de rea o Divisin del rea responsable del desarrollo de sistemas, dependiendo de las especialidades que se requieran en el desarrollo del sistema (comunicaciones, equipo, uso de servidores, Internet o Intranet, bases de datos, etc.), y, personal de empresas externas, en caso de que el desarrollo se efecte por terceros. Equipo de Pruebas de Aceptacin: Usuarios finales del sistema, Directivos de la(s) Unidad(es) Administrativa(s), Coordinadores, Subdirectores, Jefes de rea o Divisin de la(s) Unidad(es) Administrativa(s) involucradas, usuarios afectados por el uso del sistema; Directores, Subdirectores, Jefes de rea o Divisin del rea responsable del desarrollo de sistemas, personal de desarrollo externo, de ser el caso. Equipo de Mantenimiento y Operacin: La operacin se lleva a cabo por usuarios y Directores, Subdirectores, Jefes de rea o Divisin del rea responsable operar sistemas e infraestructura. Para el caso del mantenimiento, depender de la magnitud de las modificaciones, para el caso de mantenimientos menores participar personal que conforma Equipos de Desarrollo del Sistema; para el caso de mantenimientos mayores requerir de considerar los trabajos como un nuevo proyecto.
Documentacin
Los resultados del desempeo de las etapas se documentarn en formatos definidos que integrarn la documentacin del sistema. Los documentos a generar dependern del tipo de sistema que se este desarrollando, por lo que el nmero de stos vara de un sistema a otro. El siguiente cuadro muestra los documentos y productos recomendados que se pueden entregar al final de la etapa indicada.
Etapas 1. Definicin de Requerimientos 2. Anlisis de Requerimientos 3. Diseo Preliminar 4. Diseo Detallado 5. Implementacin 6. Pruebas del Sistema 7. Pruebas de Aceptacin 8. Mantenimiento y Operacin Documentos y Productos a Entregar 1. Descripcin de Conceptos Operacionales (OCD) 2. Especificacin del Sistema y Subsistemas (SSS) 3. Descripcin del Diseo del Sistema y Subsistemas (SSDD) 4. Especificacin de Requerimientos del Software (SRS) 5. Descripcin del Diseo del Software (SDD) Cdigo Fuente y Ejecutables 6. Descripcin de Pruebas del Software (STD) 7. Reporte de Pruebas del Software (STR) 8. Manual de Usuario del Software (SUM) Actualizacin de documentos afectados
Cabe mencionar que el inicio y generacin de los documentos generalmente ocurre en etapas anteriores a la etapa de entrega. La etapa de inicio puede variar dependiendo de las actividades que se lleven a cabo, sin embargo, la etapa de entrega es fija y condicin para que la etapa en la que se seala su entrega se de por concluida. Toda la informacin que se va generando durante el desarrollo del proyecto debe irse almacenando de manera ordenada en el conjunto de documentos. El contenido de estos documentos abarca la mayora de la informacin que se puede generar, sin embargo no es necesario que se llenen por completo todos los puntos de ellos. Los documentos se deben trabajar en conjunto con la ejecucin de etapas, al igual que estas, no se espera llenarlos en forma secuencial, sino ir completando su contenido como se vaya generando la informacin. La documentacin se deber mantener actualizada a lo largo de todo el proyecto y durante la etapa de mantenimiento y operacin del sistema. El conjunto de documentos conforma el estndar de documentacin. Los estndares de documentacin se utilizan para organizar la informacin que se genera durante el desarrollo del proyecto y del sistema. No se emplean como guas para el desarrollo de actividades, pero si de los elementos que se debern de integrar durante el proceso del desarrollo de sistemas. Se deben ajustar al tipo y tamao del sistema en desarrollo, por lo que no necesariamente se deben llenar todos, ni llenar todos lo incisos que stos contienen. No deben ser requisitados linealmente, sino conforme se desarrollen actividades, se generan productos como resultados de estas actividades, y estos se les vayan dando su lugar en los estndares de documentacin.
Uso de Mtodos y Estndares

En cada una de etapas se definen un conjunto de mtodos y herramientas que servirn para el desarrollo de las actividades descritas. A continuacin se presentan las referencias de los mtodos y las herramientas en las cuales se describen y utilizan dichos mtodos. Si se desea un mayor detalla de stos, referirse a la bibliografa de la herramienta especfica. Para la deteccin de problemas, identificacin de necesidades y especificacin de requerimientos, se utilizarn entrevistas, reuniones de trabajo y revisin de documentos, con apoyo de diagramas de estilo libre, para documentar los resultados se har uso de herramientas de automatizacin de oficina. Para la diseo de procesos se utilizar el estndar IDEF0 o equivalente, con apoyo de herramientas como BP-Win. Para la diagramacin de procesos se utilizar el estndar IDEF3 o equivalente, con apoyo de herramientas como BPWin, o con el uso del mtodo Modelado de Procesos de las herramientas contenidas en productos como iPlanet, Oracle o WebSphere. Para la descomposicin funcional se utilizar el estndar IDEF 0 o equivalente, con apoyo de la herramienta como BP-Win, o el estndar especificado en el conjunto de mtodos del producto o productos disponibles como iPlanet, Oracle o WebSphere. Para los Diagramas Entidad-Relacin, lgico y fsico, se utilizar el estndar IDEF 1X o equivalente, con apoyo de la herramienta como ER-Win, iPlanet, Oracle o WebSphere. Para los Diagramas de Flujo de Datos se utilizar la notacin especificada en productos disponibles como iPlanet, Oracle o WebSphere. Para el caso de utilizar Anlisis Orientado a Objetos, tanto en diseo preliminar como en diseo detallado, se utilizarn los estndares Unified Modeling Language (UML), Object Modeling Tool o Booch, con apoyo de herramientas como Rational Rose. Para el caso de utilizar Anlisis, tanto en diseo preliminar como en diseo detallado, se utilizarn los estndares Coad, Yourdon o similar, con apoyo de herramientas como Visio. En estos estndares se especifican los diagramas tanto para diseo lgico (preliminar), como para diseo fsico (detallado). Para la generacin de bases de datos y pistas de auditoria se utilizarn los estndares de nomenclatura de tablas y pistas de auditoria definidos por el rea.
Resumen de las Etapas del Ciclo de Vida
1. Definicin de Requerimientos
La definicin de requerimientos es el proceso por medio del cual las necesidades del cliente son trasladadas a una clara especificacin general de las actividades que el sistema debe soportar. El "Equipo de Definicin de Requerimientos" genera un conjunto de requerimientos al nivel de subsistemas. Estos requerimientos definen que datos fluirn en el sistema, que datos fluirn tanto de entrada como de salida, y que procesamiento se debe realizar para transformar los datos de entrada en datos de salida. La etapa incluye la revisin de la informacin disponible sobre la funcin especfica, procesos y procedimientos de la Unidad o Unidades Administrativas, Direcciones, Subdirecciones y Departamentos involucrados en la ejecucin de las actividades relacionadas. Esto incluye los eventos de inicio del proceso, procedimientos involucrados, actividades especficas y sobre todo los datos que se generan, utilizan, fluyen y transforman a lo largo de los procesos. Las principales funciones que el sistema debe ejecutar son definidas hasta el nivel de subsistema. Derivado de esta revisin, se desarrollan los conceptos de operacin que soportar el sistema, situacin actual, situacin deseada, se analizan el soporte actual de sistemas y se plantea la solucin propuesta. Es resultado se documentar en el formato de "Descripcin de Conceptos Operacionales" (OCD). Con una versin de borrador de los requerimientos se pueden iniciar las actividades de anlisis de requerimientos. Los requerimientos al nivel de subsistema servirn para iniciar la generacin del documento "Especificacin del Sistema y Subsistemas" (SSS), en la etapa consecutiva.
2. Anlisis de Requerimientos
En esta etapa, el Equipo de Definicin de Requerimientos analiza los requerimientos y sus especificaciones para determinar que estn completos, determinar su viabilidad, clarifica y amplia los requerimientos mediante tcnicas de anlisis estructurado o anlisis orientado a objetos. El "Equipo de Desarrollo" inicia la revisin de los requerimientos y debe trabajar en conjunto con el "Equipo de Definicin de Requerimientos" para resolver ambigedades, discrepancias y todos aquellos requerimientos que queden pendientes de determinar.
Los resultados de esta actividad se documentan en el formato "Especificacin del Sistema y Subsistemas" (SSS). Cuando el anlisis de requerimientos esta completo, los diagramas y resultados del anlisis forman la base para el diseo preliminar.
3. Diseo Preliminar
Durante esta etapa, el "Equipo de Desarrollo" define la arquitectura del sistema, diseo general y diseo arquitectnico, que satisfaga las especificaciones del sistema. El diseo arquitectnico comprende la estructura organizacional de un sistema, subsistema o componente de software, sus interfaces (relacionas con otros componentes), y la relacin dinmica de los componentes (conceptos de ejecucin). Se organizan los requerimientos de acuerdo a los subsistemas mayores y se selecciona el diseo ptimo entre las diferentes alternativas posibles. Se definen todas las interfaces internas y externas en el mbito de subsistema, y se especifica el diseo de las funciones u objetos del ms alto nivel. El Equipo de Desarrollo documenta el diseo de alto nivel en el formato "Descripcin del Diseo de Sistema y Subsistemas" (SSDD), en el cual el equipo presenta formalmente el diseo de la solucin. El "Equipo de Definicin de Requerimientos" deber resolver cualquier duda existente en los requerimientos, y complementar aquellos requerimientos que por algn motivo no fue posible definir en la etapa anterior. La Especificacin del Sistema y Subsistemas (SSS) forma el documento de enlace entre el "Equipo de Definicin de Requerimientos" y "El Equipo de Desarrollo" y establece el punto de partida para el diseo preliminar.
4. Diseo Detallado
Durante la etapa del diseo detallado, el Equipo de Desarrollo extiende la arquitectura del sistema al nivel de componentes de software, definiendo el diseo de su comportamiento y el diseo detallado de los mtodos, objetos, procedimientos o funciones que contendr cada componente de software propiamente dicho. Por medio de tcnicas de refinamiento sucesivo, se elabora el diseo detallado para producir especificaciones en forma de pseudo-cdigo del software. En esta etapa se producen todos los formalismos para la construccin del software, incluyendo todo el software necesario que incluir lo siguiente:
x Funciones u objetos. x Entradas del usuario, salidas del sistema (por ejemplo, reportes impresos, pantallas de consulta y exportacin de archivos), y archivos de entrada y salida. x Interfaces internas e internas, como unidades de software. x Procedimientos para la operacin.
El "Equipo de Desarrollo" documenta los resultados de la etapa en dos formatos: Especificacin de Requerimientos de Software (SRS) y "Descripcin del Diseo del Software" (SDD). Estos documentos deben contener el suficiente nivel de detalle para poder iniciar la codificacin. En esta etapa, al igual que en la anterior, el Equipo de Definicin de Requerimientos interactuar con el Equipo de Desarrollo a fin de efectuar los cambios, correcciones o adecuaciones de los requerimientos que surjan en el proceso de diseo. Por otra parte, el Equipo de Pruebas del Sistema podr iniciar el esquema y las bateras de pruebas que deber realizar durante las etapas posteriores.
5. Implantacin
En la etapa de implantacin, los desarrolladores que participen en el Equipo de Desarrollo codifican los componentes especificados en el diseo y, en su caso, se revisan componentes existentes posibles de reutilizar, para satisfacer los nuevos requerimientos. Integran cada componente en un sistema creciente, y ejecutan las pruebas unitarias y llevan a cabo las pruebas de integracin para asegurar que las capacidades asignadas a cada componente de software funcionen correctamente. En un proyecto tpico, los integrantes del "Equipo de Desarrollo" construyen varios subsistemas, componentes de software (mdulos, objetos, procedimientos o funciones) de manera simultneamente y como componentes individuales. El "Equipo de Desarrollo" repetidamente prueba cada subsistema o componente, como se vayan generando las unidades de software, codificando e integrando nuevos componentes al software en evolucin. El "Equipo de Desarrollo" combina capacidades de los subsistemas en un sistema completo para posteriormente probar las capacidades de procesamiento de punta a punta. La secuencia en la cual los componentes son codificados e integrados en los subsistemas, y el proceso de combinar estos subsistemas en el sistema esperado se deben especificar en el plan de implementacin, el cual lo preparan el lder y el administrador del proyecto durante la etapa del diseo detallado. El "Equipo de Pruebas del Sistema" inicia sus trabajos en esta etapa, en conjunto con el "Equipo de Desarrollo", los cuales consisten en empezar a generar los documentos "Descripcin de Pruebas del Software" (STD) y el borrador del "Manual de Usuario del Software" (SUM), como trabajos preliminares a la etapa de pruebas del sistema.
6. Prueba del Sistema

En esta etapa, el "Equipo de Pruebas del Sistema" refina este documento, basado en los requerimientos y especificaciones del sistema. Durante la etapa de pruebas del sistema, el "Equipo de Pruebas del Sistema" en conjunto con el "Equipo de Desarrollo" valida el sistema completamente integrado probando sus capacidades de punta a punta, de acuerdo a la "Descripcin de Pruebas del Software" (STD) del sistema. El xito de las pruebas completas especificadas en el documento de pruebas demuestra que el sistema satisface los requerimientos.
En esta fase, el "Equipo de Desarrollo" corrige cualquier error detectado en las pruebas y el "Equipo de Pruebas del Sistema" deber de refinar el "Manual de Usuario del Software" (SUM). La etapa se considera concluida cuando todas las pruebas especificadas en el documento de pruebas del sistema han sido ejecutadas correctamente.
7. Pruebas de Aceptacin
En la etapa de pruebas de aceptacin, el sistema debe ser probado por el "Equipo de Pruebas de Aceptacin", integrado por personal independiente, tanto personal tcnico que haya participado en el "Equipo de Definicin de Requerimientos", como personal que ser usuario del sistema (que no tenga las preconcepciones de los desarrolladores acerca del funcionamiento del sistema), para asegurar que el software satisface todos los requerimientos. Esta etapa se lleva a cabo probando el sistema por un equipo independiente del desarrollo, con lo que se asegura que el sistema satisface el propsito de los requerimientos originales. Durante la pruebas de aceptacin, el Equipo de Pruebas del Sistema proporciona el apoyo necesario al "Equipo de Pruebas de Aceptacin" para que este pueda ejecutar pruebas no planeadas bajo su perspectiva. Cualquier error descubierto durante las pruebas es corregido por el "Equipo de Desarrollo". La prueba de aceptacin es considerada completa cuando las pruebas especificadas en el "Descripcin de Pruebas del Software" (STD) corren exitosamente, los resultados se debern documentar en el formato "Reporte de Pruebas del Software" (STR). Una vez concluidas la pruebas con resultados satisfactorios, el sistema debe ser formalmente aceptado. El "Equipo de Pruebas de Aceptacin" deber liberar la versin final del software y la documentacin del sistema para el usuario, revisando la versin final del "Manual de Usuario del Software" (SUM).
Al final de las pruebas de aceptacin del sistema, ste pasa a responsabilidad del Equipo de Mantenimiento y Operacin. Las actividades conducentes durante la etapa de mantenimiento son altamente dependientes del tipo de software involucrado. Para sistemas de misin crtica, la etapa debe considerar la actualizacin del marco normativo, la implementacin de cambios en los procesos y procedimientos sistematizados, y la correccin o modificaciones menores que se presenten durante su operacin. Durante la etapa de mantenimiento, las actividades a realizar comprenden la adecuacin de la documentacin del sistema, cambios en el software y el control de versiones. El nmero y la formalidad de las actividades a realizar y la cantidad de cambios a los documentos producidos durante el desarrollo varan dependiendo del tamao y la complejidad del software y lo extenso de las modificaciones Por otra parte, las actividades de operacin consiste en vigilar que el sistema se ejecute correctamente, la administracin de usuarios, instalacin y actualizacin de software del equipo de produccin, la produccin centralizada, el soporte para la logstica de operacin, y apoyo para la instalacin y uso del software.
Este equipo podr considerar la instalacin de una mesa de ayuda que proporcione el soporte tcnico y de uso del sistema, dependiendo del nmero de sitios instalados y nmero de usuarios del software.
1. Etapa de Definicin de Requerimientos
Elementos Principales
Criterios de Entrada
x x
Criterios de Salida
x x
Descripcin del Problema Proyecto Aprobado
Completar el documento de la Descripcin de Conceptos Operacionales (OCD) Documentacin inicial de las Especificaciones del Sistema y Subsistemas (SSS), con los requerimientos mnimos al nivel de Subsistema
Productos
x x
Equipos de Trabajo
x
Descripcin de Conceptos Operacionales (OCD) Especificaciones del Sistema y Subsistemas (SSS), documento preliminar
Equipo de Definicin de Requerimientos
Herramientas
x x x x
Actividades Clave
x x x x x
BPWin, Edwin iPlanet, WebSphere Desginer 2000 Microsoft Office
Mtodos
x x x x x x
Diagramas de estilo libre IDEF 0 IDEF 1X IDEF 3 Diagramas de Flujo de Datos Diagramas Entidad Relacin Lgicos
x x x
Revisar documentacin Entrevistar clientes Describir los Conceptos Operacionales Describir y diagramar procesos y procedimientos Identificar de datos de entrada y salida de las actividades del proceso Identificar de los Subsistemas que soportarn el proceso Identificar y describir de las interfaces externas entre sistemas y subsistemas Describir la situacin actual y situacin deseada.
Propsito
El propsito de la etapa de definicin de requerimientos es producir una especificacin clara, completa, consistente y factible de probar, del entorno actual y de la propuesta de solucin que el sistema deber satisfacer.
Funciones
El "Equipo de Definicin de Requerimientos" debe participar en la definicin de requerimientos analizando los procesos y procedimientos, situacin actual y situacin a la que se desea llegar, as como los flujos de datos que se presentan a lo largo de los procesos. Los resultados de esta etapa los deber registrar en el documento "Descripcin de Conceptos Operacionales". La definicin de requerimientos deber ser resultado de la observacin de procesos, de entrevistas, generacin de prototipos, del anlisis de entradas y salidas, deteccin de deficiencias y visualizacin de posibles soluciones.
Actividades
La etapa inicia tan pronto como se establecen los objetivos del proyecto, respecto a la problemtica que se desea resolver y una vez que se ha dado la autorizacin para llevar a cabo la solucin. La definicin de requerimientos es el proceso por medio del cual las necesidades del cliente son trasladadas a una clara especificacin general de las actividades que el sistema debe soportar. El "Equipo de Definicin de Requerimientos" genera un conjunto de requerimientos al nivel de subsistemas. Estos requerimientos definen que datos fluirn en el sistema, que datos fluirn tanto de entrada como de salida, y que procesamiento se debe realizar para transformar los datos de entrada en datos de salida. La etapa incluye la revisin de la informacin disponible sobre la funcin especfica, procesos y procedimientos de la Unidad o Unidades Administrativas, Direcciones, Subdirecciones y Departamentos involucrados en la ejecucin de las actividades relacionadas. Esto incluye los eventos de inicio del proceso, procedimientos involucrados, actividades especficas y sobre todo los datos que se generan, utilizan, fluyen y transforman a lo largo de los procesos. Las principales funciones que el sistema debe ejecutar son definidas hasta el nivel de subsistema. Derivado de esta revisin, se desarrollan los conceptos de operacin que soportar el sistema, situacin actual, situacin deseada, se analizan el soporte actual de sistemas y se plantea la solucin propuesta. Es resultado se documentar en el formato de "Descripcin de Conceptos Operacionales" (OCD). Con una versin de borrador de los requerimientos se pueden iniciar las actividades de anlisis de requerimientos. Los requerimientos al nivel de subsistema servirn para iniciar la generacin del documento "Especificacin del Sistema y Subsistemas" (SSS), en la etapa consecutiva.
Documentacin
Descripcin de Conceptos Operacionales (OCD)
El propsito del documento es describir el sistema propuesto en trminos de las necesidades del usuario que se atendern; la relacin con sistemas o procedimientos existentes; y, la forma en que ste ser utilizado. Permite obtener consenso entre los participantes acerca de los conceptos de la operacin del sistema propuesto. Dependiendo de su uso, el documento se puede enfocar a la comunicacin de las necesidades del usuario, a los desarrolladores, o para comunicar las ideas de los desarrolladores a los usuarios o a otras partes interesadas.
Elementos
Requerimientos
Los requerimientos se definen como: x Caractersticas que un sistema, subsistemas o componente de software debe poseer para ser aceptado. x Una oracin que establezca obligatoriedad, contenido en un estndar o la porcin de algn lineamiento, procedimiento, norma, y restricciones en general. Los requerimientos estn presentes en todo el desarrollo de un sistema: se definen, se transmiten, se evalan, se controlan y se prueban. Los requerimientos se transforman a software ejecutable que cubre las necesidades de los usuarios. La metodologa contiene dos actividades para definir y registrar requerimientos que el sistema o subsistemas deben contener para que sea aceptado: 1. Anlisis de Requerimientos del Sistema (desarrollado en esta etapa) 2. Anlisis de Requerimientos de Software (desarrollado en la etapa de Diseo Detallado).
1. Anlisis de Requerimientos del Sistema

Contiene las siguientes actividades: x Anlisis de entradas y salidas del usuario x Definicin y registro de los conceptos de operacin del sistema y su entorno x Definicin y registro de los requerimientos que se deben cubrir
El resultado de estas actividades se registra en los documentos de conceptos operacionales del sistema (OCD) y de especificacin del sistema/subsistema (SSS) El documento OCD normalmente se genera antes que el SSS, aunque se pueden generar en conjunto. El anlisis de requerimientos se efecta en forma iterativa junto con las actividades del diseo. Cada iteracin proporciona elementos y datos adicionales para los requerimientos del diseo, hasta que se identifican completamente los componentes de software (CSCI), de hardware (HWCI) y manuales de operacin, que sern necesarios.
2. Anlisis de Requerimientos de Software

Contempla: x los requerimientos de software que debe contener cada elemento identificado; x mtodos para asegurar que se logren; y x transicin entre los requerimientos del sistema y los elementos de software. El resultado de esta actividad se registra en las especificaciones de requerimientos del software (SRS). El sistema o componente se desarrolla en etapas mltiples, los requerimientos no quedarn totalmente definidos hasta llegar a la etapa final. Algunos requerimientos debern ser detallados y otros relativamente generales. Los documentos SRS y SSS identifican 16 categoras de requerimientos que se pueden cubrirse, cuando as aplique.
1. Capacidades 2. Interfaces externas 3. Interfaces internas 4. Representacin interna de datos 5. Adaptacin 6. Seguridad 7. Privacidad 8. Ambiente
9. Recursos de cmputo 10. Factores de calidad 11. Restricciones de diseo e implantacin 12. Personal 13. Entrenamiento 14. Logstica 15. Empacado 16. Precedencia y factores crticos
10
2. Anlisis de Requerimientos
x x
Criterios de Salida
x
Que exista el documento de la Descripcin de Conceptos Operacionales (OCD) Documentacin inicial de las Especificaciones del Sistema y Subsistemas (SSS) con los requerimientos mnimos al nivel de Subsistema
Especificaciones del Sistema y Subsistemas (SSS) completo
Productos
x
Equipos de Trabajo
x x
Especificaciones del Sistema y Subsistemas (SSS)
Equipo de Definicin de Requerimientos Equipo de Desarrollo
Herramientas
x x x x x
Actividades Clave
x x x
Rational Rose Designer 2000 ERWin, BPWin iPlanet, WebSphere Microsoft Office
x
Mtodos
x x x x
Anlisis Estructurado Anlisis Orientado a Objetos Diagramas de Flujo de Datos Diagramas Entidad Relacin Lgicos
x x
Revisar la especificacin de requerimientos Complementar los requerimientos Desagregar los requerimientos al siguiente nivel, aplicando anlisis orientado a objetos o estructurado Agrupar los requerimientos en subsistemas y descomponer los subsistemas en mdulos, clases u objetos Describir y diagramar los subsistemas Detallar el diagrama entidad relacin lgico
Propsito
El propsito de la etapa de anlisis de requerimientos es asegurar que los requerimientos y sus especificaciones sean factibles, estn completas y sean consistentes, y que el "El Equipo de Desarrollo" las ha comprendido. Con este entendimiento, desagregar los requerimientos al siguiente nivel, requerimientos que se debern satisfacer en el nivel de subsistemas o componentes de software, definiendo el qu se deber hacer sin llegar a definir el cmo se implementar la solucin.
Funciones
El "El Equipo de Desarrollo" debe participar en definir y registrar los requerimientos que se debern satisfacer con el sistema propuesto, y determinar la forma en que se asegurar que los requerimientos se satisfagan. Los resultados debern proporcionar los elementos definidos en el documento "Especificacin del Sistema y Subsistemas" (SSS). Si el sistema se compondr de subsistemas, la etapa se debe llevar a cabo en forma iterativa con las actividades de Diseo Preliminar y Diseo Detallado, para refinar los requerimientos del sistema, disear el sistema, identificar los subsistemas, definir los requerimientos de estos subsistemas, disear los subsistemas e identificar sus componentes, definir los requerimientos de esos componentes y disear los componentes, y as sucesivamente.
Actividades
La etapa inicia despus de que el Equipo de Definicin de Requerimientos completa los requerimientos y sus especificaciones. En esta etapa, el Equipo de Definicin de Requerimientos analiza los requerimientos y sus especificaciones para determinar que estn completos, determinar su viabilidad, clarifica y amplia los requerimientos mediante tcnicas de anlisis estructurado o anlisis orientado a objetos. El "Equipo de Desarrollo" inicia la revisin de los requerimientos y debe trabajar en conjunto con el "Equipo de Definicin de Requerimientos" para resolver ambigedades, discrepancias y todos aquellos requerimientos que queden pendientes de determinar. Los resultados de esta actividad se documentan en el formato "Especificacin del Sistema y Subsistemas" (SSS). Cuando el anlisis de requerimientos est completo, los diagramas y resultados del anlisis forman la base para el diseo preliminar.
Documentacin
Especificacin del Sistema y Subsistema (SSS)
El propsito del documento es especificar los requerimientos del sistema y subsistemas y describir los mtodos a ser usados para asegurar que cada requerimiento sea satisfecho.
12
Incluye la especificacin de los requerimientos correspondiente a las interfaces externas del sistema y subsistemas. La especificacin de requerimientos de interfaces especifica los requerimientos impuestos a un sistema, a un subsistema o a un componente de software de contener una o ms interfaces con otras entidades.
Elementos
Sistema
El trmino sistema que se utiliza en este estndar tiene dos connotaciones: x un sistema de hardware y software, para el cual el estndar nicamente aplica para la parte de software. x un sistema de software para el cual cubre todo el desarrollo. Si el sistema consiste de subsistemas, todos los requisitos para el sistema aplican para los subsistemas. En un determinado nivel, cada subsistema se compondr de componentes de software, que implementen las funciones designadas para ese subsistema.
VENTANAS
kjhlkj jhlkjh j hljhl ljhlkjhlkjh kjhlkj jhlkjh j kjh ljhlkjhlkj hljhl ljhlkjhlkjh hlhlkjh kjh ljhlkjhlkj hlhlkjh
INTERACCION CON EL USUARIO Objetos que proporcionan interfaces entre los objetos del dominio del problema y el usuario (V entanas y Reportes)
DOMINIO DEL PROBLEMA Objetos que directamente corresponden al problema, que son neutrales, y que no tienen necesidad del conociemiento de los otros elementos
INTERACCION CON OTROS SISTEMAS Objetos que proporcionan interfaces entre objetos del dominio del problema y objetos y dispositivos de otros sistemas
OTROS SISTEMAS
sdfjkfj dsd oirehyufn
ADMINISTRACION DE INFORMACION Objetos que proporcionan la interfase entre objetos del dominio del problema y bases de datos, o sistemas de archivos.
DISPOSITIVOS
REPORTES
ALMACENAMIENTO Archivos, RDBMS
Interfaces
Las interfaces se refieren a la relacin de dos o ms entidades (CSCI-CSCI, CSCI-HWCI, CSCI-usuario, o unidad de software-unidad de software), por medio de las cuales comparten, proporcionan e intercambian datos. Una interfaz no es un CSCI, unidad de software u otro componente del sistema, es una relacin entre stos. Donde sea aplicable, se debe proporcionar la especificacin del sistema, subsistemas o componente de software en forma breve, y debe considerar:
13
x x x x x x x
identificar las partes fsicas principales; reas funcionales e interfaces funcionales y fsicas; diagramas lgicos del sistema; diagramas de bloque; diagramas esquemticos; aspectos operacionales pertinentes; y conceptos y consideraciones organizacionales y logsticas.
La especificacin de desarrollo y productos debe describir todas las caractersticas requeridas de desempeo, fsicas, y de disponibilidad, mantenimiento, consideraciones ambientales y, cuando sea necesario, prioridades relativas sobre disciplinas de diseo.
Especificaciones Generales
Contiene todos los requerimientos que son comunes a una familia de sistemas, subsistemas, componentes de software o procesos. Cuando las especificaciones detalladas se preparen para complementar las especificaciones generales se define completamente cada elemento en forma individual.
Especificaciones Detalladas
Contiene los requerimientos nicamente para un sistema, subsistemas, componente de software o proceso particular. Si la especificacin cubre ms de un elemento, se debe especificar primero los requerimientos generales a todos. Los requerimientos que los diferencian se especifican para cada elemento en forma individual, como se requiera. En general, cada requerimiento debe cubrirse en prrafos separados, cuando un requerimiento contenga elementos particulares, se debe poner en un prrafo separado seguido inmediatamente de los requerimientos generales. Los requerimientos detallados deben colocarse en los subprrafos apropiados. Donde sea necesario incluir datos adicionales, deben usarse encabezados descriptivos y apropiados y asignados en un orden lgico.
14
3. Diseo Preliminar
x
Criterios de Salida
x
Especificaciones del Sistema y Subsistemas (SSS) completo
Completar los aspectos del diseo de componente y documentarlo en la Descripcin del Diseo del Sistema y Subsistemas (SSDD)
Productos
x
Equipos de Trabajo
x x
Descripcin del Diseo del Sistema y Subsistemas (SSDD)
Equipo de Desarrollo Equipo de Definicin de Requerimientos
Herramientas
x x x x x x
Actividades Clave
x
Rational Rose Designer 2000 ERWin, BPWin iPlanet, WebSphere Microsoft Office Delphi, Visual Basic
Disear el comportamiento del sistema, estableciendo los conceptos de ejecucin de los subsistemas, mdulos, paquetes u objetos (relacin dinmica de los componentes)
Disear la arquitectura del sistema, describiendo las interfaces externas del sistema e interfaces entre los subsistemas, mdulos, paquetes u objetos Refinar el Diagrama Entidad Relacin Detallar los diversos diagramas Disear las ventanas, funciones del teclado, avisos, ayudas, mensajes, y la definicin de las reglas, formulas, algoritmos y comportamiento de datos
x
Mtodos
x x x x x x x
Anlisis Estructurado Anlisis Orientado a Objetos Diagramas de Flujo de Datos Diagramas de Transicin de Estados Diagramas de Descomposicin Funcional Diagramas Entidad Relacin Lgicos Prototipos
x x x
x
Desarrollar prototipos
Propsito
El propsito de la etapa de diseo preliminar es definir la arquitectura de software de alto nivel (sistemas y subsistemas) que mejor satisfaga los requerimientos y describir sus especificaciones como sistema.
Funciones
El Equipo de Desarrollo deber participar en el diseo del sistema, identificar los subsistemas, definir los requerimientos de estos subsistemas y disear los subsistemas. El diseo se llevar a cabo en dos partes: el diseo general y el diseo arquitectnico. Los resultados de esta etapa debern de proporcionar los elementos incluidos en el documento "Descripcin del Diseo de Sistema y Subsistemas" (SSDD). En las actividades del diseo general se definen y registran las decisiones del diseo, esto es, las decisiones acerca del diseo del comportamiento del sistema y otras decisiones que afecten la seleccin y diseo de componentes del sistema, como la arquitectura del sistema cliente servidor, sistema distribuido o stand-alone. El diseo arquitectnico del sistema, esto es, identificacin de componentes de los subsistemas, la identificacin y diseo de interfaces, el diseo de bases de datos, y los conceptos de ejecucin entre componentes. Las decisiones de diseo se mantienen a discrecin del Equipo de Desarrollo a menos que formalmente se especifique otra cosa, estas actan como "requerimientos" de desarrollo internos, impuestos para ser implantados, y probados internamente, los cuales no es necesario demostrarlos al cliente final.
Actividades
El Equipo de Desarrollo particiona el sistema en subsistemas mayores, diseo general, especifica todas las interfaces del sistema entre subsistemas y genera el diseo utilizando descomposicin funcional o diagramas orientados a objetos. Durante esta etapa, se define la arquitectura del sistema, diseo general, que satisfacer las especificaciones del sistema. El diseo arquitectnico comprende la estructura organizacional de un sistema, subsistema o componente de software y sus interfaces (relacionas con otros componentes), y la relacin dinmica de los componentes (conceptos de ejecucin). Se organizan los requerimientos de acuerdo a los subsistemas mayores y se selecciona el diseo ptimo entre las diferentes alternativas posibles. Se definen todas las interfaces internas y externas en el mbito de subsistema, y se especifica el diseo de las funciones u objetos al ms alto nivel. Durante esta etapa, el "Equipo de Desarrollo" define la arquitectura del sistema, diseo general y diseo arquitectnico, que satisfaga las especificaciones del sistema. El diseo arquitectnico comprende la estructura organizacional de un sistema, subsistema o componente de software, sus interfaces (relacionas con otros componentes), y la relacin dinmica de los componentes (conceptos de ejecucin). Se organizan los requerimientos de acuerdo a los subsistemas mayores y se selecciona el diseo ptimo entre las diferentes alternativas posibles. Se definen todas las interfaces internas y externas en el
16
mbito de subsistema, y se especifica el diseo de las funciones u objetos del ms alto nivel. El Equipo de Desarrollo documenta el diseo de alto nivel en el formato "Descripcin del Diseo de Sistema y Subsistemas" (SSDD), en el cual el equipo presenta formalmente el diseo de la solucin. El "Equipo de Definicin de Requerimientos" deber resolver cualquier duda existente en los requerimientos, y complementar aquellos requerimientos que por algn motivo no fue posible definir en la etapa anterior. La Especificacin del Sistema y Subsistemas (SSS) forma el documento de enlace entre el "Equipo de Definicin de Requerimientos" y "El Equipo de Desarrollo" y establece el punto de partida para el diseo preliminar.
Documentacin
Descripcin del Diseo del Sistema/Subsistema (SSDD)
El propsito de documento es describir las decisiones de diseo generales del sistema y subsistema, as como las del diseo arquitectnico que conformarn la solucin. Este documento debe incluir la Descripcin de Diseo de Interfaces y la Descripcin de Diseo de Base de Datos. La informacin del diseo de interfaces describe las caractersticas de la relacin entre sistemas, subsistemas, componentes de software, unidades de software o alguna otra entidad, y debe estar en congruencia con los requerimientos de interfaces. El documento resultante es usado como base para el desarrollo del sistema y puede referirse a la Descripcin del Diseo del Sistema o a la Descripcin del Diseo del Subsistema, o a ambos, segn el producto descrito.
Elementos
Dimensiones de los Sistema
Todo sistema tiene tres perspectivas bsicas para describirlo, y desde las cuales se puede iniciar el diseo.
17
Funcional
(actividades desempeadas)
an, cre s y de ida ifican v i t ac od os Las zan, m an dat utili sform tran
Las a eje ctivida cuta d tiem n en es se po det un ord erm e ina n y do
Datos
(entradas, almacenamiento y salidas)
y an, cre ifican tro s o dat mod den da Los ilizan, rman de vi ut ansfo ciclo tr un de
Control
(efectos y comportamiento observables)
Dimensin Funcional
Engloba las actividades o acciones llevadas a cabo por el sistema. Las funciones apoyan y automatizan las polticas, reglas y procedimientos del negocio. Sinnimos de funciones: procesos, servicios y mtodos. Mtodos y Herramientas: x Diagrama de Flujo de Datos x Diagrama Funcional x Diagramas de Descomposicin Funcional
Dimensin de Datos
Como parte de un sistema de informacin, los datos que entran y se almacenan son transformados o procesados en alguna salida significativa y til para el negocio llamada informacin. Elementos: x Entradas va algn dispositivo de entrada de datos como el teclado, escner o mdem. x Ya en el sistema, se almacenan en algn dispositivo electrnico como disco duro, disquete o cinta. x Desplegados en algn medio de salida como pantalla, papel o microficha. Mtodos y Herramientas:
18
x Diagrama Entidad-Relacin x Diccionario de Datos
Dimensin de Control
Esta dimensin tiene que ver con el comportamiento y los conceptos de la ejecucin del sistema. El control es el establecimiento de los efectos observables de una solicitud al sistema, en el orden, secuencia y resultados esperados. Mtodos y Herramientas: x Diagrama de Transicin de Estados x Diagramas de Flujo de Datos x Diagramas de Control
Diseo del Sistema

Una de las prcticas ms usadas para conjuntar los requerimientos es dividir el sistema propuesto en subsistemas que engloben requerimientos relacionados. A su vez, estos subsistemas se compondrn de mdulos, objetos o componentes de software. Esta descomposicin se lleva a cabo en las dos etapas relacionadas con el diseo.
Nivel Sistema
Nivel Subsistema 0
Diseo Preliminar
(Diseo del Sistema y Diseo Arquitectnico)
Nivel Subsistema 1
Mdulo 1
Diseo Detallado
(Componentes de Software)
Componente de Software
Unidades de Software
El diseo se refiere a todas las caractersticas seleccionadas por el desarrollador en respuesta a los requerimientos. El diseo contempla tres elementos bsicos: 1. Diseo General: vista del usuario sin hacer caso de la implantacin interna. 2. Diseo Arquitectnico: vista externa de la estructura de componentes.
19
3. Diseo Detallado: vista interna de las unidades de software (ejecutada en la etapa siguiente).
Diseo General
Incluye todas las caractersticas para cubrir los requerimientos, sin importar las decisiones de diseo que se realicen e ignorando los detalles internos de implantacin, a nivel sistema y subsistema.
x x x
Diseo del Comportamiento Decisiones que afectan la seleccin y diseo de componentes Decisiones que afectan el diseo de bases de datos
El diseo de comportamiento describe como se comportar todo el sistema, subsistema o CSCI, desde el punto de vista del usuario, ignorando la implantacin interna. El comportamiento puede ser parte de los requerimientos o parte de diseo. Si las caractersticas del comportamiento son un requisito para aceptar el sistema, entonces se consideran requerimientos. Generalmente se efectan prototipos sobre este diseo, a travs de herramientas visuales. Incluye: informacin en ventanas, funciones del teclado, interaccin usuario-mquina, avisos, ayudas, errores, reglas del negocio, restricciones, comportamiento de datos, algoritmos, formulas matemticas, y prrafos que describen el agrupamiento y almacenamiento de datos. Las decisiones sobre diseo arquitectnico considera las decisiones sobre la seleccin de componentes e interfaces y los conceptos de la ejecucin del sistema, los cuales se ven afectados por la decisin arquitectnica: diseo distribuido, cliente-servidor o stand-alone.
Diseo Arquitectnico
Comprende la estructura organizacional de un sistema y subsistema, identificacin de los componentes y sus interfaces (relacionas con otros componentes) y la relacin dinmica de los componentes (conceptos de ejecucin).
x x x
Identificacin de componentes Identificacin de interfaces Conceptos de ejecucin
Incluye: componentes, relaciones dinmicas entre componentes, interaccin entre componentes, flujo de control, flujo de datos, transicin de estado y manejo de interrupciones.
20
Diseo Arquitectnico y Diseo Detallado

Los diseos arquitectnico o detallado difieren en la perspectiva de como ven a los componentes.
Sistema
Arquitectnico Componente A (caja negra) interfaces Componente B Funcion 1 Funcin 2 ... Interaccin
Si cada componente se considera una caja, con un lmite definido, la diferencia entre estos diseos es que, el arquitectnico considera una vista del componente desde afuera, y el detallado la considera desde adentro. Diseo Arquitectnico. Se refiere a la estructura organizacional de un sistema, subsistema o componente de software, que identifica cada componente (visto como una caja negra), describe como estos componentes intercambian informacin (interfaces) y considera la interaccin entre componentes (conceptos de ejecucin), todo esto ignorando el funcionamiento interno de los componentes. Diseo Detallado. Considera los conceptos de ejecucin internos de cada componente (vistos como una caja transparente), como los componentes trabajan internamente para implementar las interfaces requeridas, interacciones y procesamiento interno.
Detallado
21
4. Diseo Detallado
x
Criterios de Salida
x
Descripcin del Diseo del Sistema y Subsistemas (SSDD)
Contar con el pseudo cdigo de los componentes de software que conformarn al sistema
Productos
x x
Equipos de Trabajo
x x x
Especificacin de Requerimientos de Software (SRS) Descripcin del Diseo del Software (SDD)
Equipo de Desarrollo Equipo de Definicin de Requerimientos Equipo de Pruebas del Sistema
Herramientas
x x x x x x
Actividades Clave
x
x
x
Mtodos
x x x x x x
x x
Anlisis Estructurado Anlisis Orientado a Objetos Diagramas de Flujo de Datos Diagramas de Transicin de Estados Diagramas Entidad Relacin Fsico Pseudo cdigo
x
Definir los componentes internos de los subsistemas, mdulos, paquetes u objetos, es decir, mtodos, procedimientos o funciones Definir los componentes internos para , las interfaces externas del sistema y entre los subsistemas, mdulos, paquetes u objetos Refinar el Diagrama Entidad Relacin a nivel fsico Detallar los diversos diagramas Definir los mtodos, funciones o procedimientos para la operacin de las ventanas, funciones del teclado, avisos, ayudas, mensajes, y la definicin de las reglas, formulas, algoritmos y comportamiento de datos Describir el pseudo cdigo para los mtodos, funciones o procedimientos definidos
Propsito
El propsito de la etapa de diseo detallado es producir una especificacin de diseo, completa que satisfaga todos los requerimientos del sistema, a nivel de componentes de software que pueda ser directamente codificada.
Funciones
El Equipo de Desarrollo deber llevar a cabo y registrar las actividades de diseo del software, atendiendo a los requerimientos que debern ser cubiertos por los componentes de software. Esta etapa se llevar a cabo en tres partes: las decisiones generales sobre componentes, el diseo arquitectnico de componentes y el diseo detallado de componentes. Los resultados de esta etapa debern proporcionar los elementos incluidos en los documentos Especificacin de Requerimientos de Software (SRS) y "Descripcin del Diseo del Software" (SDD). Las decisiones general sobre componentes, comprenden la definicin y registro de las decisiones acerca del diseo del comportamiento de los componentes de software y decisiones que afecten la seleccin y diseo de unidades de software comprendidas en esos componente (como programacin estructurada, u orientada a objetos, almacenamiento de datos en archivos o bases de datos, formato de archivos, lenguajes de programacin y herramientas de desarrollo). En el diseo arquitectnico de componentes se desarrollan y registran la estructura de cada componte de software, esto es la descripcin de cada unidad de software contenido en los componentes de software, sus interfaces y sus conceptos de ejecucin. Las unidades de software pueden estar compuestas de otras unidades de software y deben ser organizadas en tantos niveles como sea necesario para representar la arquitectura del componente de software. El diseo detallado de componentes consiste del desarrollo y registro de la descripcin de las unidades de software, hasta llegar a la definicin de su contenido en pseudo cdigo que ser utilizado para la implantacin del producto.
Actividades
La etapa da inicio una vez que se tengan los componentes principales del sistema, y no se detecten problemas graves en el diseo preliminar. La etapa es una extensin de las actividades realizadas durante el diseo detallado. Durante la etapa del diseo detallado, el Equipo de Desarrollo extiende la arquitectura del sistema al nivel de componentes de software, definiendo el diseo de su comportamiento y el diseo detallado de los mtodos, objetos, procedimientos o funciones que contendr cada componente de software propiamente dicho. Por medio de tcnicas de refinamiento sucesivo, se elabora el diseo detallado para producir especificaciones en forma de pseudo-cdigo del software. En esta etapa se producen todos los formalismos para la construccin del software, incluyendo todo el software necesario que incluir lo siguiente:
24
x Funciones u objetos. x Entradas del usuario, salidas del sistema (por ejemplo, reportes impresos, pantallas de consulta y exportacin de archivos), y archivos de entrada y salida. x Interfaces internas e internas, como unidades de software. x Procedimientos para la operacin.
El "Equipo de Desarrollo" documenta los resultados de la etapa en dos formatos: Especificacin de Requerimientos de Software (SRS) y "Descripcin del Diseo del Software" (SDD). Estos documentos deben contener el suficiente nivel de detalle para poder iniciar la codificacin. En esta etapa, al igual que en la anterior, el Equipo de Definicin de Requerimientos interactuar con el Equipo de Desarrollo a fin de efectuar los cambios, correcciones o adecuaciones de los requerimientos que surjan en el proceso de diseo. Por otra parte, el Equipo de Pruebas del Sistema podr iniciar el esquema y las bateras de pruebas que deber realizar durante las etapas posteriores.
Documentacin
Especificacin de Requerimientos del Software (SRS)
El propsito del documento es especificar los requerimientos para los componentes de software que compondrn el sistema y subsistemas, y los mtodos a ser usados para garantizar que cada requerimiento sea atendido. Los requerimientos correspondientes a las interfaces externas entre componentes de software se deben incluir en este documento. El contenido de este documento es usado como base para el diseo y pruebas de cada componente del software.
Descripcin del Diseo del Software (SDD)

El propsito del documento es describir el diseo de los componentes de software. Describe las decisiones de diseo general, el diseo arquitectnico y el diseo detallado de cada componente de software necesario para conformar el sistema. El documento deber incluir la descripcin de diseo de interfaces y la descripcin del diseo de bases de datos. La informacin del diseo de interfaces describe las caractersticas de la relacin entre componentes de software, unidades de software o alguna otra entidad, y debe estar en congruencia con los requerimientos de interfaces. En cuanto al diseo de bases de datos, describe la coleccin de datos relacionados, almacenados en uno o ms archivos o tablas de manera que puedan ser accesados por los usuarios del sistema por medio de un sistema administrador de bases de datos relacionales (RDBMS). El documento resultante ser utilizado como base para la construccin del software. Deber proporcionar el diseo y la informacin necesaria para el soporte del software.
25
Elementos
Diseo del Sistema
Una de las prcticas ms usadas para conjuntar los requerimientos es dividir el sistema propuesto en subsistemas que engloben requerimientos relacionados. A su vez, estos subsistemas se compondrn de mdulos, objetos o componentes de software. Esta descomposicin se lleva a cabo en las dos etapas relacionadas con el diseo.
Nivel Sistema
Nivel Subsistema 0
Diseo Preliminar
(Diseo del Sistema y Diseo Arquitectnico)
Nivel Subsistema 1
Mdulo 1
Diseo Detallado
(Componentes de Software)
Componente de Software
Unidades de Software
El diseo se refiere a todas las caractersticas seleccionadas por el desarrollador en respuesta a los requerimientos. El diseo contempla tres elementos bsicos: 1. Diseo General: vista del usuario sin hacer caso de la implantacin interna (descrito en la etapa anterior). 2. Diseo Arquitectnico: vista externa de la estructura de componentes (descrito en la etapa anterior). 3. Diseo Detallado: vista interna de las unidades de software.
Diseo Detallado
Conjunta todas las caractersticas de un sistema, subsistema o CSCI seleccionadas por el desarrollador en respuesta a los requerimientos y funciones asignadas.
x x x
Unidades de software Bases de datos Interfaces
26
Incluye: decisiones de diseo como algoritmos; restricciones, limitaciones, o caractersticas inusuales en el diseo de las unidades de software; lenguajes de programacin; comandos y procedimientos; respuesta y tiempo para cada entrada y salida; lgicas de control cuando la aplicacin pasa de un componente a otro; secuencias de operacin; y, secuencias de control dinmico. La arquitectura detallada, es decir de software, est delimitada por la decisin del modelo de programacin adoptado
x x
programacin estructurada programacin orientada a objetos
Diseo Arquitectnico y Diseo Detallado

Los diseos arquitectnico o detallado difieren en la perspectiva de como ven a los componentes.
Sistema
Arquitectnico Componente A (caja negra) interfaces Componente B Funcion 1 Funcin 2 ... Interaccin
Si cada componente se considera una caja, con un lmite definido, la diferencia entre estos diseos es que, el arquitectnico considera una vista del componente desde afuera, y el detallado la considera desde adentro. Diseo Arquitectnico. Se refiere a la estructura organizacional de un sistema, subsistema o componente de software, que identifica cada componente (visto como una caja negra), describe como estos componentes intercambian informacin (interfaces) y considera la interaccin entre componentes (conceptos de ejecucin), todo esto ignorando el funcionamiento interno de los componentes. Diseo Detallado. Considera los conceptos de ejecucin internos de cada componente (vistos como una caja trasparente), como los componentes trabajan internamente para implementar las interfaces requeridas, interacciones y procesamiento interno.
Detallado
27
28
5. Implantacin
x x
Criterios de Salida
x x x
Especificacin de Requerimientos de Software (SRS) Descripcin del Diseo del Software (SDD)
Cdigo Fuente Mdulos Ejecutables Pruebas Unitarias y Modulares
Productos
x x x
Equipos de Trabajo
x x x
Cdigo Fuente y Mdulos Ejecutables Descripcin de Pruebas del Software (STD) Borrador del Manual de Usuario del Software (SUM)
Equipo de Desarrollo Equipo de Definicin de Requerimientos Equipo de Pruebas del Sistema
Herramientas
x x x x x
Actividades Clave
x x x x x x
Designer 2000 ERWin iPlanet, WebSphere Delphi, Visual Basic Microsoft Office
Mtodos
x x x
Codificacin Pruebas Unitarias Integracin de Componentes de Software Pruebas Integrales Definir las pruebas del software y del sistema Elaborar la versin borrador del Manual de Usuario
Programacin Estructurado Programacin Orientado a Objetos PL/SQL
Propsito
El propsito de la etapa de implantacin es construir un sistema de software completo y de calidad, basados en los planos proporcionados como resultados del diseo detallado.
Funciones
El "Equipo de Desarrollo" deber de llevar a cabo la implementacin, codificacin, construccin y las pruebas de las unidades de software contenidas en el diseo. Esta etapa considera como aplicable la codificacin de instrucciones de computadora en el lenguaje seleccionado, definicin de datos, construccin de bases de datos, populacin de bases de datos y archivos. Todos estos elementos debern ser probados durante la etapa de construccin, iniciando el registro de las pruebas que debern de llevarse a cabo en la etapa posterior en el documento "Descripcin de Pruebas del Software" (STD) y la conformacin del borrador del "Manual de Usuario del Software" (SUM). El trmino software incluye programas de cmputo y bases de datos. El trmino implantacin significa convertir el diseo de software en programas de cmputo y bases de datos. Las unidades de software comprenden los elementos en los que se subdivide un componente de software, clases, objetos, mdulos, funciones, rutinas, procedimientos y elementos de la base de datos. Durante la etapa de implantacin se debern efectuar pruebas de las unidades de software, y componentes de software que se vayan desarrollando. La pruebas a desempear, en todos los componentes, debern seguir cuatro pasos: 1. Preparacin. Durante el desarrollo el "Equipo de Desarrollo" deber establecer casos de prueba (en trminos de entradas, resultados esperados y criterios de evaluacin), procedimientos y datos de pruebas para verificar el funcionamiento de cada unidad de software. Los casos de pruebas debern cubrir los aspectos descritos en el diseo detallado. 2. Desempeo. El "Equipo de Desarrollo" deber llevar a cabo las pruebas correspondientes a las unidades de software, de acuerdo a los casos de pruebas y procedimientos establecidos durante la preparacin. 3. Revisin y Verificacin. El "Equipo de Desarrollo" efectuar todas las revisiones necesarias al software, llevar a cabo la repeticin de pruebas, y actualizar los datos de pruebas y productos involucrados como sea necesarios, basados en los resultados que vayan obteniendo. 4. Anlisis y Registro. El "Equipo de Desarrollo" analizar el resultado de las pruebas y deber registrar las pruebas, los casos usados y los resultados del anlisis. Todos los elementos de los cuatro pasos formarn debern registrarse y servirn de base para el documento "Descripcin de Pruebas del Software" (STD), aunque formalmente las pruebas contenidas en el documento se llevarn a cabo en la etapa posterior.
30
Actividades
La etapa inicia despus de revisar que las especificaciones de diseo estn los suficientemente correctas y completas. En la etapa de implantacin, los desarrolladores que participen en el Equipo de Desarrollo codifican los componentes especificados en el diseo y, en su caso, se revisan componentes existentes posibles de reutilizar, para satisfacer los nuevos requerimientos. Integran cada componente en un sistema creciente, y ejecutan las pruebas unitarias y llevan a cabo las pruebas de integracin para asegurar que las capacidades asignadas a cada componente de software funcionen correctamente. En un proyecto tpico, los integrantes del "Equipo de Desarrollo" construyen varios subsistemas, componentes de software (mdulos, objetos, procedimientos o funciones) de manera simultneamente y como componentes individuales. El "Equipo de Desarrollo" repetidamente prueba cada subsistema o componente, como se vayan generando las unidades de software, codificando e integrando nuevos componentes al software en evolucin. El "Equipo de Desarrollo" combina capacidades de los subsistemas en un sistema completo para posteriormente probar las capacidades de procesamiento de punta a punta. La secuencia en la cual los componentes son codificados e integrados en los subsistemas, y el proceso de combinar estos subsistemas en el sistema esperado se deben especificar en el plan de implementacin, el cual lo preparan el lder y el administrador del proyecto durante la etapa del diseo detallado. El "Equipo de Pruebas del Sistema" inicia sus trabajos en esta etapa, en conjunto con el "Equipo de Desarrollo", los cuales consisten en empezar a generar los documentos "Descripcin de Pruebas del Software" (STD) y el borrador del "Manual de Usuario del Software" (SUM), como trabajos preliminares a la etapa de pruebas del sistema.
Productos
Cdigo fuente, mdulos ejecutables, especificaciones de los productos, pruebas unitarias e integrales.
31
32
6. Pruebas del Sistema
x x x x x x
Criterios de Salida
x x x x
Cdigo Fuente Mdulos Ejecutables Pruebas Unitarias Ejecutadas Componente de software integrados Pruebas integrales Codificacin terminada
Sistema probado integralmente Pruebas del software completadas Documentacin de la Descripcin de Pruebas del Software (STD) Manual de Usuario del Software (SUM) concluido
Productos
x x x
Equipos de Trabajo
x x
Sistema probado integralmente Descripcin de Pruebas del Software (STD) Manual de Usuario del Software (SUM)
Equipo de Pruebas del Sistema Equipo de Desarrollo
Herramientas
x x x x x
Actividades Clave
x x x x x x
Designer 2000 ERWin iPlanet, WebSphere Delphi, Visual Basic Microsoft Office
Mtodos
x x x
Programacin Estructurado Programacin Orientado a Objetos Matriz de Pruebas
Validar el sistema completamente Probar cada una de sus funcionalidades de acuerdo al diseo Corregir cualquier error que se detecte Describir las especificaciones del producto Refinar el manual del usuario del sistema Completar las pruebas que se realizarn en la etapa posterior y describirlas en el documento correspondiente
Propsito
El propsito de la etapa de pruebas del sistema es verificar la funcionalidad punta a punta del sistema, verificando que se satisfacen los requerimientos y sus especificaciones.
Funciones
El "Equipo de Pruebas del Sistema" deber llevar a cabo la integracin y pruebas de unidades de software, y la integracin y pruebas de los componentes de software que conformarn los subsistemas y sistema propuesto. Las pruebas se efectuarn en dos partes: 1. Integracin y Pruebas de Unidades de Software. Deber integrar el software correspondiente a dos o ms unidades de software, probando que el software resultante trabaja en conjunto como fue especificado, y continuar este proceso de integracin de unidades de software hasta que sea integrado y probado el componente de software para el cual las unidades de software fueron diseadas. 2. Integracin y Pruebas de Componentes de Software. Posteriormente, deber desarrollar las pruebas necesarias para demostrar al cliente que los requerimientos de especificados para cada componente y sus interfaces han sido cubiertos, y que la integracin de componentes dentro del sistema propuesto opera como un todo. Las pruebas debern cubrir las especificaciones incluidas en el documento "Especificaciones de Requerimientos de Software" (SRS).
Integracin de Unidades de Software y sus Pruebas

1. Preparacin. El "Equipo de Pruebas del Sistema" deber establecer los casos de pruebas (en trminos de entradas, resultados esperados, y criterios de evaluacin), procedimientos de prueba, y datos de prueba para llevar a cabo la integracin y pruebas de unidades de software. 2. Ejecucin. El "Equipo de Pruebas del Sistema " deber llevar a cabo las pruebas correspondientes a la integracin de unidades de software, de acuerdo a los casos de pruebas y procedimientos establecidos durante la preparacin. 3. Revisin y Verificacin. El "Equipo de Pruebas del Sistema " efectuar todas las revisiones necesarias al software, llevar a cabo la repeticin de pruebas, y actualizar los datos de pruebas y productos involucrados como sea necesarios, basados en los resultados que vayan obteniendo. 4. Anlisis y Registro. El "Equipo de Pruebas del Sistema " analizar el resultado de las pruebas y deber registrar las pruebas, los casos usados y los resultados del anlisis.
Las Pruebas de Componentes de Software

1. Independencias. El "Equipo de Pruebas del Sistema " deber en la medida de lo posible, estar conformado con personal que no haya participado en el diseo o la implantacin del componente. Esto no significa que el personal que particip el diseo
34
y la implantacin no participe en el proceso, sino que no debe ser el responsable de la actividad. 2. Determinacin del Equipo de Pruebas. La pruebas de componentes se debern realizar en el ambiente de cmputo similar al de la operacin, para lo cual deber de seleccionarse el equipo de cmputo apropiado, con el software con el que operar y coexistir. 3. Preparacin. El "Equipo de Pruebas del Sistema " deber definir y registrar la preparacin de las pruebas, casos de prueba, y procedimientos de prueba a ser usados para la evaluacin de los componentes de software, estas pruebas debern ser significativas de los requerimientos del cada componente de software. El resultado de esta preparacin deber ser adicionado al documento "Descripcin de Pruebas del Software" (STD). 4. Corrida Limpia. En caso de que las pruebas deban ser presenciadas por el cliente, el equipo debe asegurarse de ejecutar los casos de pruebas y los procedimientos con anticipacin para garantizar que estn completos y correctos, y que el software est listo para pruebas con el cliente. 5. Ejecucin. El "Equipo de Pruebas del Sistema " deber llevar a cabo las pruebas de cada componente de software, de acuerdo a los casos de pruebas y procedimientos descritos en el documento "Descripcin de Pruebas del Software" (STD). 6. Revisin y Verificacin. El "Equipo de Pruebas del Sistema " efectuar las corridas de pruebas, revisiones al software, actualizacin de casos de pruebas y productos, necesarias basados en los resultados que obtenga, hasta que el software funcione correctamente y de acuerdo a lo especificado. 7. Anlisis y Registro. El "Equipo de Pruebas del Sistema " analizar el resultado de las pruebas y deber registrar las pruebas, los casos usados y los resultados del anlisis. Los resultados de esta etapa permitirn conformar el documento final de la "Descripcin de Pruebas del Software" (STD) y el "Manual de Usuario del Software" (SUM).
Actividades
La etapa inicia al trmino de la construccin de los componentes y la integracin de los subsistemas. En esta etapa, el "Equipo de Pruebas del Sistema" refina este documento, basado en los requerimientos y especificaciones del sistema. Durante la etapa de pruebas del sistema, el "Equipo de Pruebas del Sistema" en conjunto con el "Equipo de Desarrollo" valida el sistema completamente integrado probando sus capacidades de punta a punta, de acuerdo a la "Descripcin de Pruebas del Software" (STD) del sistema. El xito de las pruebas completas especificadas en el documento de pruebas demuestra que el sistema satisface los requerimientos. En esta fase, el "Equipo de Desarrollo" corrige cualquier error detectado en las pruebas y el "Equipo de Pruebas del Sistema" deber de refinar el "Manual de Usuario del Software"
35
(SUM). La etapa se considera concluida cuando todas las pruebas especificadas en el documento de pruebas del sistema han sido ejecutadas correctamente.
Documentacin
Descripcin de las Pruebas del Software (STD)
El propsito del documento es describir las pruebas que debern llevar a cabo, la preparacin de los casos de prueba, y la generacin de los procedimientos a ser usados durante el desempeo de pruebas de sistemas, subsistemas y componentes de software. La ejecucin de las pruebas, permite la evaluacin y calificacin de las pruebas que se debern llevar a cabo.
36
7. Pruebas de Aceptacin
x x x x
Criterios de Salida
x x x
Sistema probado integralmente Pruebas del software completadas y ejecutadas exitosamente Descripcin de pruebas del software Manual de Usuario del Software (SUM) concluido
Pruebas del sistema ejecutadas exitosamente Reporte de Pruebas del Software (STR) concluido Manual de Usuario del Software (SUM) validado
Productos
x x x
Equipos de Trabajo
x x x
Sistema empacado Manual de Usuario del Software (SUM) Reporte de Pruebas del Software (STR)
Equipo de Pruebas de Aceptacin Equipo de Pruebas del Sistema Equipo de Desarrollo
Herramientas
x
Actividades Clave
x x
Microsoft Office
Mtodos
x
Matriz de Pruebas
x x x
Probar el sistema completamente, por personal ajeno al desarrollo Probar cada una de sus funcionalidades del sistema, de acuerdo a la documentacin de pruebas y requerimientos Realizar pruebas no documentadas Corregir cualquier error que se detecte Elaborar el reporte de resultados de las pruebas realizadas
Propsito
El propsito de la etapa de pruebas de aceptacin es demostrar al cliente que el sistema satisface los requerimientos dentro del ambiente establecido en el cual operar.
Funciones
El "Equipo de Pruebas de Aceptacin" deber participar en la calificacin de pruebas del sistema. La calificacin de pruebas del aceptacin se lleva a cabo para demostrar al cliente que el sistema cubre los requerimientos especificados. Las pruebas debern cubrir los requerimientos del sistema conforme a las especificaciones del sistema y subsistemas (SSS) y la especificacin de las interfaces definidas en el mismo documento. Las pruebas debern ser desarrolladas por personal independiente del diseo y la implementacin, stos debern cubrir la condicin de independencia, determinando el equipo de para las pruebas, las actividades de preparacin, la ejecucin limpia, ejecucin, revisin y verificacin, y anlisis y registro. 1. Independencias. El "Equipo de Pruebas de Aceptacin" deber en la medida de lo posible, estar conformado con personal que no haya participado en el diseo o la implantacin del sistema. Esto no significa que el personal que particip el diseo y la implantacin no participe en el proceso, sino que no debe ser el responsable de la actividad. 2. Determinacin del Equipo de Pruebas. Las pruebas del sistema se debern realizar en el ambiente de cmputo similar al de la operacin, para lo cual deber de seleccionarse el equipo de cmputo apropiado, con el software con el que operar y coexistir. 3. Preparacin. El "Equipo de Pruebas de Aceptacin " deber definir y registrar la preparacin de las pruebas, casos de prueba, y procedimientos de prueba a ser usados para la evaluacin del sistema, estas pruebas debern ser significativas de los requerimientos del sistema. El resultado de esta preparacin deber ser adicionado al documento "Descripcin de Pruebas del Software" (STD). 4. Corrida Limpia. En caso de que las pruebas deban ser presenciadas por el cliente, el equipo debe asegurarse de ejecutar los casos de pruebas y los procedimientos con anticipacin para garantizar que estn completos y correctos, y que el sistema est listo para pruebas con el cliente. 5. Ejecucin. El "Equipo de Pruebas de Aceptacin" deber llevar a cabo las pruebas del sistema, de acuerdo a los casos de pruebas y procedimientos descritos en el documento "Descripcin de Pruebas del Software" (STD). 6. Revisin y Verificacin. El "Equipo de Pruebas de Aceptacin" efectuar las corridas de pruebas, revisiones al software, actualizacin de casos de pruebas y productos, necesarias basados en los resultados que obtenga, hasta que el sistema funcione correctamente y de acuerdo a lo especificado.
38
7. Anlisis y Registro. El "Equipo de Pruebas de Aceptacin" analizar el resultado de las pruebas y deber registrar las pruebas, los casos usados y los resultados del anlisis en el documento "Reporte de Pruebas del Software" (STR).
Actividades
En la etapa de pruebas de aceptacin, el sistema debe ser probado por el "Equipo de Pruebas de Aceptacin", integrado por personal independiente, tanto personal tcnico que haya participado en el "Equipo de Definicin de Requerimientos", como personal que ser usuario del sistema (que no tenga las preconcepciones de los desarrolladores acerca del funcionamiento del sistema), para asegurar que el software satisface todos los requerimientos. Esta etapa se lleva a cabo probando el sistema por un equipo independiente del desarrollo, con lo que se asegura que el sistema satisface el propsito de los requerimientos originales. Durante la pruebas de aceptacin, el Equipo de Pruebas del Sistema proporciona el apoyo necesario al "Equipo de Pruebas de Aceptacin" para que este pueda ejecutar pruebas no planeadas bajo su perspectiva. Cualquier error descubierto durante las pruebas es corregido por el "Equipo de Desarrollo". La prueba de aceptacin es considerada completa cuando las pruebas especificadas en el "Descripcin de Pruebas del Software" (STD) corren exitosamente, los resultados se debern documentar en el formato "Reporte de Pruebas del Software" (STR). Una vez concluidas la pruebas con resultados satisfactorios, el sistema debe ser formalmente aceptado. El "Equipo de Pruebas de Aceptacin" deber liberar la versin final del software y la documentacin del sistema para el usuario, revisando la versin final del "Manual de Usuario del Software" (SUM).
Documentacin
Reporte de las Pruebas del Sistema (STR)
El propsito del documento es registrar los resultados de las pruebas llevadas a cabo sobre cada componente de software, de los subsistemas en los que se integran y de cualquier otra relacin entre elementos. Establece la evaluacin y los resultados resultantes del software.
Manual de Usuario del Software (SUM)

El propsito del documento es indicar al usuario del software como instalar y usar los elementos del software, grupos afines de funciones contenidas en cada componente y del sistema y subsistema de la solucin. Este tambin puede cubrir los aspectos particulares de operacin de componentes, as como instrucciones para el puesto o tarea del usuario relacionada con cada funcin del sistema. El documento est enfocado a software que ser ejecutado por un usuario, que contenga interfaces de usuario que requieran entradas y salidas de datos en lnea y que incluya la interpretacin de desplegados de salidas del sistema.
39
Para el caso de que el software est incluido en un sistema de hardware-software, el manual de usuario o los procedimientos operativos para este pueden ser contenidos en un solo documento.
40
x x x
Criterios de Salida
x x
Descripcin de problemas en el sistema Proyecto aprobado para modificaciones Sistema operando correctamente
Realizacin de las modificaciones solicitadas Actualizacin de la documentacin
Productos
x x
Equipos de Trabajo
x x
Documentos actualizados Sistema modificado
Equipo de Mantenimiento y Operacin Equipo de Desarrollo
Herramientas
x x x x x x
Actividades Clave
x x x x x x x x
Mtodos
x x x
Codificacin Pruebas Unitarias Integracin de Componentes de Software Pruebas Integrales Vigilar la operacin normal del sistema Administrar el sistema Generar la produccin central Proporcionar el soporte tcnico y de uso del sistema
Programacin Estructurado Programacin Orientado a Objetos Matriz de Pruebas
Propsito
El propsito de la etapa de mantenimiento y operacin es mantener actualizado y en produccin el sistema, a cambios menores del producto y errores menores, cambios en la operacin, actualizacin de la tecnologa usada o cambios en la normatividad, as como proporcionar el soporte tcnico necesario durante la operacin del sistema.
Funciones
Para que el sistema pase a la etapa de mantenimiento y operacin, se debern de llevar las actividades conducentes para instalar y poner en operacin el sistema. Dentro de las actividades a desarrollar, se encuentran:
x
Preparacin para el uso del sistema. Preparar el software ejecutable para cada sitio en el que operar, incluyendo los archivos, datos precargados, y archivos de utilera que debern estar presentes para que el sistema opere; contar con del manual de usuario del software, para el personal que operar y har uso de los resultados del sistema. Instalacin del sistema. Apoyar en la instalacin del sistema en el sitio del usuario, proporcionar el entrenamiento a los usuarios del sistema, y proporcionar asistencia durante la etapa de operacin. Soporte tcnico. Establecer los canales de comunicaciones para que se reporten problemas o nuevos requerimientos una vez que ha sido puesto en operacin el sistema.
x
x
Actividades
Al final de las pruebas de aceptacin del sistema, ste pasa a responsabilidad del grupo de mantenimiento y operacin. Las actividades conducentes durante la fase de operacin y mantenimiento son altamente dependientes del tipo de software involucrado. Para sistemas de misin crtica, la etapa debe considerar la actualizacin del marco normativo, la implementacin de cambios en los procesos y procedimientos sistematizados, y la correccin o modificaciones menores que se presenten durante su operacin. Durante la etapa de operacin y mantenimiento, las actividades a realizar comprenden la adecuacin de la documentacin del sistema, cambios en el software y el control de versiones. El nmero y la formalidad de las actividades a realizar y la cantidad de cambios a los documentos producidos durante el desarrollo varan dependiendo del tamao y la complejidad del software y lo extenso de las modificaciones
42
Anexo: Actividades y Documentacin por Tipo Sistema

Actividades Propuestas a Desarrollar por Etapa Etapas 1. Definicin de Requerimientos 2. Anlisis de Requerimientos Actividades a Desarrollar Identificacin de Requerimientos Anlisis de Requerimientos Diseo Arquitectnico Plan del Proyecto 3. Diseo Preliminar 4. Diseo Detallado Diseo Inicial Diseo Detallado 3. Descripcin del Diseo del Sistema y Subsistemas (SSDD) 4. Especificacin de Requerimientos del Software (SRS) 5. Descripcin del Diseo del Software (SDD) Cdigo Fuente y Ejecutables X X Documentos y Productos a Entregar 1. Descripcin de Conceptos Operacionales (OCD) 2. Especificacin del Sistema y Subsistemas (SSS) X X Software Personal Tipo de Sistema a Desarrollar Sistemas Departamental Software Administrativo X X X X X X Sistemas de Misin Crtica X X X X X X Sistemas Complejos X X X X X X
Revisiones del Diseo 5. Implementacin Codificacin Reuso Inspecciones de Cdigo Verificacin y Validacin Administracin de Configuraciones Integracin Formal Empacado 6. Pruebas del Sistema Pruebas Unitarias Pruebas Funcionales Pruebas de Integracin Pruebas del Sistema Pruebas de Campo 7. Pruebas de Aceptacin Pruebas de Aceptacin Pruebas Independientes Documentacin de Usuario 8. Administrativas Aseguramiento de Calidad Instalacin y Capacitacin Administracin del Proyecto Total de Actividades por Tipo de Sistema 5 X 8 X X 18 8. Manual de Usuario del Software (SUM) X X X 7. Reporte de Pruebas del Software (STR) X X X X X 6. Descripcin de Pruebas del Software (STD) X X X X X X X X X X
X X X X X X X X X X X X X X X X X 23
X X X X X X X X X X X X X X X X X X X 25
44
Anexo: Plantillas para la Documentacin de Sistemas
1. Descripcin de Conceptos Operacionales (OCD) 2. Especificacin de Sistema y Subsistemas (SSS) 3. Descripcin del Diseo de Sistema y Subsistemas (SSDD) 4. Especificacin de Requerimientos de Software (SRS) 5. Descripcin del Diseo del Software (SDD) 6. Descripcin de Pruebas del Software (STD) 7. Reporte de Pruebas del Software (STR) 8. Manual de Usuario del Software (SUM)

Metodolog A para El Desarrollo de Sistemas V1 - 4

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Metodolog A para El Desarrollo de Sistemas V1 - 4

Cargado por

Copyright:

Formatos disponibles

Comisin Nacional de los Sistemas de Ahorro para el Retiro

Gua Metodologca para el Desarrollo y Mantenimiento de Aplicativos de Cmputo

Direccin General de Informtica

ACTIVIDADES ........................................................................................................................... 35 DOCUMENTACIN ..................................................................................................................... 36

Metodologa para el Desarrollo de Sistemas

Definicin de Requerimientos 20 30 40 50 60 Porcentaje de Tiempo del Proyecto 70 80 90 100

Prototipo Uno Prototipo Dos Prototipo Tres

Cascada Razones en contra

Puntuacin Oportunidad a favor

Puntuacin Oportunidad a favor

Etapas 1. Definicin de Requerimientos 2. Anlisis de Requerimientos 3. Diseo Preliminar 4. Diseo Detallado

6. Pruebas del Sistema 7. Pruebas de Aceptacin

Uso de Mtodos y Estndares

Resumen de las Etapas del Ciclo de Vida

6. Prueba del Sistema

1. Etapa de Definicin de Requerimientos

Descripcin del Problema Proyecto Aprobado

Equipo de Definicin de Requerimientos

BPWin, Edwin iPlanet, WebSphere Desginer 2000 Microsoft Office

1. Anlisis de Requerimientos del Sistema

2. Anlisis de Requerimientos de Software

Especificaciones del Sistema y Subsistemas (SSS) completo

Especificaciones del Sistema y Subsistemas (SSS)

Equipo de Definicin de Requerimientos Equipo de Desarrollo

sdfjkfj dsd oirehyufn

ALMACENAMIENTO Archivos, RDBMS

Especificaciones del Sistema y Subsistemas (SSS) completo

Descripcin del Diseo del Sistema y Subsistemas (SSDD)

Equipo de Desarrollo Equipo de Definicin de Requerimientos

Las a eje ctivida cuta d tiem n en es se po det un ord erm e ina n y do

x Diagrama Entidad-Relacin x Diccionario de Datos

Diseo del Sistema

Identificacin de componentes Identificacin de interfaces Conceptos de ejecucin

Diseo Arquitectnico y Diseo Detallado

Descripcin del Diseo del Sistema y Subsistemas (SSDD)

Equipo de Desarrollo Equipo de Definicin de Requerimientos Equipo de Pruebas del Sistema

Descripcin del Diseo del Software (SDD)

Unidades de software Bases de datos Interfaces

programacin estructurada programacin orientada a objetos

Diseo Arquitectnico y Diseo Detallado

Cdigo Fuente Mdulos Ejecutables Pruebas Unitarias y Modulares

Equipo de Desarrollo Equipo de Definicin de Requerimientos Equipo de Pruebas del Sistema

Programacin Estructurado Programacin Orientado a Objetos PL/SQL

6. Pruebas del Sistema

Equipo de Pruebas del Sistema Equipo de Desarrollo

Programacin Estructurado Programacin Orientado a Objetos Matriz de Pruebas

Integracin de Unidades de Software y sus Pruebas

Las Pruebas de Componentes de Software

Equipo de Pruebas de Aceptacin Equipo de Pruebas del Sistema Equipo de Desarrollo

Manual de Usuario del Software (SUM)

Realizacin de las modificaciones solicitadas Actualizacin de la documentacin

Documentos actualizados Sistema modificado

Equipo de Mantenimiento y Operacin Equipo de Desarrollo

Programacin Estructurado Programacin Orientado a Objetos Matriz de Pruebas

Anexo: Actividades y Documentacin por Tipo Sistema

Anexo: Plantillas para la Documentacin de Sistemas

También podría gustarte