Ciclo de vida del desarrollo El ciclo de vida del desarrollo de software, presenta de manera organizada y secuencial, las actividades

y procedimientos que deben realizarse en cualquier proyecto de desarrollo. Las fases del ciclo de desarrollo (ciclo de vida) deben completarse todas, sea cual sea el mtodo de ingeniera que se emplee.

El ciclo de desarrollo de software es a menudo referenciado en los libros como ciclo de vida del desarrollo de software o SDLC (Software Development Life Cycle ).

Modelos de ciclo de vida del desarrollo Modelo de cascada La nocin de ciclo de desarrollo (ciclo de vida) del software y las fases y etapas que lo componen, han variado ampliamente durante los aos. Uno de los primeros modelos de ciclo de vida del desarrollo fue establecido por W. Royce en 1970 y es conocido como el "modelo de cascada" (waterfall model). El modelo de cascada es el primero en establecer el proceso de desarrollo como la ejecucin de un conjunto de actividades. En su concepcin bsica, cada una de las actividades generan como salidas productos y modelos que son utilizados como entradas para el proceso subsiguiente. Lo cual supone que una actividad debe terminarse (por lo menos, en algn grado) para empezar la siguiente. Figura 5. Modelo de cascada del Ciclo de vida del Desarrollo

El modelo presenta una situacin ideal para el proceso de desarrollo: un proceso con progresos ordenados y coherentes. Sin embargo, la idea de obtener tal progreso ordenado no es nada realista. En particular, el enfoque secuencial no permite el tratamiento de fenmenos reales como las relaciones con el personal, las polticas de las organizaciones, las incidencias de la competencia o la economa.

En trminos generales el modelo en cascada: Asume que todo va en una direccin No hay sobre posicin ni iteraciones entre las fases Implica una entrega al completar cada una de las fases Asume que el conocimiento y requerimientos obtenidos en las fases

iniciales del proyecto no cambia significativamente durante la vida del mismo. Asume que no se cometen muchos errores en cada una de las fases. Modelo en espiral En 1976 Barry Boehm propuso un nuevo modelo de ciclo de vida del desarrollo. El nuevo modelo es conocido como modelo de espiral y busca manejar los riesgos asociados al modelo de cascada. El modelo en espiral es, esencialmente, un desarrollo completo en cascada en cada iteracin. El modelo de Boehm es tambin conocido como "modelo evolutivo" o "modelo del caracol". Figura 6. Modelo de Espiral de Ciclo de vida del Desarrollo

En cada una de las iteraciones, se deben cumplir cuatro actividades principales (una en cada cuadrante) : Planeacin: determinacin de los objetivos, alternativas y restricciones. Anlisis de riesgo: anlisis de alternativas e identificacin/resolucin de

riesgos. Ingeniera: desarrollo del producto hasta "el siguiente nivel". Evaluacin: valoracin por parte del cliente de los resultados obtenidos.

El movimiento de la espiral, ampliando con cada iteracin su amplitud radial, indica que cada vez se van construyendo versiones sucesivas del software, cada vez ms completas.

El modelo en espiral maneja el concepto de versiones del sistema de software. Cada que se completa una versin del sistema de software, se vuelven a estudiar los requerimientos y el impacto del sistema sobre los mismos para crear una nueva versin del sistema.

Modelo de prototipos Una variacin del modelo en espiral es utilizada por algunos nuevos mtodos. Los nuevos mtodos se basan nicamente en la construccin incremental de prototipos. En estos modelos no se genera un sistema completo en cada iteracin, sino que cada iteracin genera tan slo un nuevo prototipo, cada vez ms cercano al sistema final.

Estos nuevos mtodos son conocidos actualmente como desarrollo rpido de aplicaciones o RAD (Rapid Applications Development). Este estilo fue promovido en 1985 por DuPont Co. (Inventores del nylon y la lycra) mediante una metodologa propia conocida como produccin iterativa de prototipos o RIIP. James Martin realiz un libro posterior definiendo una metodologa similar e introduciendo el trmino RAD.

El proceso iterativo de construccin de prototipos debe estar precedido por una fase de anlisis y construccin del modelo conceptual. Posteriormente, cada una de las iteraciones deber contar con una fase rpida de anlisis y con la confrontacin permanente de las necesidades del usuario.

Figura 7. Modelo de Prototipos del Ciclo de vida de Desarrollo

La construccin iterativamente de prototipos se representa diferente para enfatizar la tendencia haca el sistema final ideal. (El modelo en espiral construye un sistema cada vez ms completo y complejo en cada iteracin).

El manejo de prototipos trae consigo, sin embargo, muchos nuevos problemas a ser considerados. De manera especial observaremos los problemas relacionados con las iteraciones mismas: Cuntas veces es necesario iterar? En que momento es "razonable" dejar de iterar?

Fases genricas del proceso de desarrollo Para facilitar el entendimiento de las diversas metodologas, los autores han preferido establecer varios pasos genricos que caracterizan el desarrollo de software de manera independiente del mtodo o el esquema de ciclo de vida utilizado.

De hecho, sea cual sea el ciclo de vida que se adopte, o la metodologa que se use, las fases genricas deben cumplirse. Este es el criterio con el cual fueron seleccionadas. Modelo de cinco fases genricas Aunque algunos expertos presentan unas variaciones bsicas, todo proyecto de desarrollo de software requiere de ejecutar cinco pasos fundamentales : Anlisis Diseo Implementacin Pruebas y correccin de defectos Operacin y mantenimiento

Anlisis: Comnmente se denomina anlisis a la etapa centrada en establecer el "qu" del software. Su preocupacin bsica es el problema a ser resuelto, las necesidades de los usuarios y las funciones que debe desempear el software. En definitiva lo qu debe hacer el software.

Algunos expertos, por ejemplo Edward Yourdon y Roger Pressman, diferencian el estudio de los requerimientos del anlisis. Para los propsitos de esta divisin genrica, estos dos aspectos son cubiertos en una nica fase.

Diseo: Esta etapa se centra en el "cmo", en la forma cmo debe construirse el sistema de software de acuerdo a la informacin obtenida de la etapa de anlisis.

Edward Yourdon define esta etapa como la construccin del modelo de implementacin. Es decir, en esta etapa se define como deber implementarse el sistema de software. Para Yourdon los modelos creados en la fase de anlisis determinan claramente cul debe ser el comportamiento general del sistema en un entorno ideal. Los modelos a crear en la fase de diseo determinan, ya sobre el entorno propio de la organizacin, cmo deber implementarse el sistema.

Implementacin: La implementacin se establece como la "construccin" del sistema. La actividad slo lleva a la prctica el sistema que se model en la fase de diseo. La fase incluye las actividades de codificacin e integracin de los diferentes mdulos constitutivos del sistema.

Pruebas y correccin de defectos: El software generado en la fase de implementacin no puede ser "entregado" a los clientes, para que funcione, sin practicarle antes una serie de pruebas. Las pruebas son tendientes a encontrar defectos en el sistema final debidos a omisin o mal interpretacin de alguna parte del anlisis o el diseo.

Operacin y Mantenimiento: En esta fase el software es puesto en funcionamiento con los usuarios y el entorno de la organizacin. Es comn que estas etapas requieran de trabajo adicional del equipo de desarrolladores, especialmente en procesos de configuracin adecuada, utilidades menores de copias de respaldo, administracin de seguridad o reportes adicionales.

Modelo de tres fases genricas Roger Pressman, define tan slo tres pasos fundamentales. Aunque esta divisin es un poco extraa y es solamente utilizada varios expertos y tericos, estas tres fases fundamentales pueden aclarar fcilmente el propsito de cada una de las fases de cualquier metodologa y pueden ser tiles al momento de ensear y comparar diversas tcnicas.

Las fases sugeridas por Pressman son:

Definicin Desarrollo Mantenimiento

Definicin: Segn las propias palabras de Pressman, la fase de definicin se centra sobre el "qu". Es decir, esta fase busca identificar que informacin ha de ser procesada, qu funcin y rendimiento se desea, qu interfaces han de establecerse, que restricciones de diseo existen y que criterios de validacin se necesitan para definir un sistema correcto. En definitiva la etapa de definicin debe identificar los requisitos clave del sistema y del software.

Aunque la fase de definicin puede variar de acuerdo al esquema utilizado, esta fase incluye, bsicamente, tres pasos especficos: Anlisis del sistema. Planificacin del proyecto de software. Anlisis de requerimientos (requisitos).

Desarrollo: La fase de desarrollo se ocupa del "cmo". Esto es, durante esta fase, el desarrollador de software intenta de descubrir cmo han de disearse las estructuras de datos y la arquitectura del software, cmo han de implementarse los detalles, cmo ha de traducirse el diseo a un lenguaje de programacin y cmo han de realizarse las pruebas.

Bsicamente la fase de desarrollo comprende tres pasos especficos: Diseo del software Codificacin Prueba del software

Mantenimiento: La fase de mantenimiento se centra en el "cambio" del software. Los cambios se asocian a la correccin de errores, a las adaptaciones requeridas por la evolucin del entorno del software y a las modificaciones requeridas por el cambio de los requisitos del cliente dirigidos a reforzar o a ampliar el sistema. Los cambios, y actividades, realizadas en la fase de mantenimiento son de tres tipos: Correctivos, tendientes a corregir defectos y errores. Adaptativos, tendiente a adaptar el software a los cambios del entorno. De Mejoramiento, tendiente a incorporar nuevas funcionalidades al

software.

2.5. Anlisis Estructurado

Para Qu Se Utilizan las Herramientas de Modelado?

La labor del anlisis involucra el modelado del sistema que desea el usuario, Los modelos de anlisis de sistema son representaciones abstractas de lo que al final ser una combinacin de hardware y software.

Modelado de las Funciones del Sistema. Diagrama de Flujo de Datos.

Ilustra las funciones que el sistema debe realizar. Podra describirse como qu transformaciones debe llevar a cabo el sistema? Qu entradas se Transforman en qu salidas? Entre otras. Los diagramas de flujo de datos consisten en procesos, agregados de datos y terminadores: Los procesos se representan por medio de crculos, o 'burbujas' en el diagrama. Representan las funciones individuales que el sistema lleva a cabo. Las funciones transforman entradas en salidas. Los flujos se muestran por medio de flechas curvas, son conexiones entre los procesos y representa la informacin que dicho proceso necesita como entrada o genera como salida. Los agregados de datos se representan por medio de dos lneas paralelas o mediante una elipse. Muestran colecciones de datos que el sistema debe recordar por un perodo de tiempo. Cuando los diseadores de sistema y programadores terminen de construir el sistema, estos sern archivos o bases de datos. Los terminadores muestran la entidad externa con la que el sistema se comunica, tpicamente son individuos; grupos de personas; organizaciones externas; otros sistemas, etc.

Ejemplo diagrama de Flujo. El diagrama de flujo de datos proporciona una visin global de los componentes funcionales del sistema, pero no da detalles de estos. Para mostrar detalles acerca de que informacin se transforma y como se transforma, se ocupan dos herramientas textuales de modelado adicionales: el Diccionario de Datos y la Especificacin de Procesos. Ejemplo Diccionario de Datos: NOMBRE del cliente = tratamiento de cortesa o titulo + nombre + apellido Tratamiento de cortesa o ttulo = [Sr. | Srta. | Sra. | Dr. | Prof.] Nombre = {carcter valido} Apellido = {carcter valido} Carcter valido = [A - Z| a -z| | - |] Ejemplo de Especificacin de Proceso Tpica para un solo proceso. Por cada pago de cliente ingresado Buscar su detalle de factura correspondiente al cliente Si el pago es efectivo, Colocar sello de pagado a la factura del cliente, Colocar marca de pagado en factura copia y almacenar En caso contrario Descontar monto pagado a factura cliente Acentar fecha de entrega.

Almacenar factura cliente copia Entregar recibo entrega. Fin pago.

Modelado de Datos Almacenados. Diagrama de Entidad - Relacin.

Estos diagramas hacen nfasis en las relaciones entre los datos. Todos los sistemas almacenan y usan informacin acerca del ambiente en el cual interactan; a veces, esta informacin es mnima, pero en la mayora de los sistemas es bastante compleja. No solo deseamos conocer en detalle que informacin hay en cada agregado de datos, sino que tambin queremos conocer la relacin que existe entre agregados. Este aspecto del sistema no se resalta en el diagrama de flujo, pero s aqu. Este diagrama consta de dos elementos fundamentales: Tipo de Objetos: se representan por medio de un rectngulo en los diagramas. Esto representa una coleccin o conjunto de objetos (cosas) del mundo real cuyos miembros juegan algn papel en el desarrollo del sistema; pueden adems identificarse de manera nica y ser descriptos por uno o ms atributos. Relaciones: se representan por medio de rombos en el diagrama y son la serie de conexiones o asociaciones entre los tipos de objetos que estn conectados por la relacin por medio de flechas.

Ejemplo de Diagrama de Entidad Relacin.

Modelado

de

la

Estructura

de

los

Programas.

El

Diagrama de Estructura.
Herramienta grfica de modelado utilizada para representar la jerarqua de software. Este diagrama cada rectngulo representa un mdulo (por ejemplo un sub- programa), las flechas que conectan los rectngulos representan invocaciones de mdulos (por ejemplo llamado de sub- rutinas). El diagrama tambin muestra parmetros de entrada que se le dan a cada mdulo invocado y parmetros de salida devueltos por cada mdulo cuando termina su tarea y devuelve el control al que lo llama.

Ejemplo de Diagrama de Estructura: