Ciclo de vida de un Software

El término ciclo de vida del software describe el desarrollo de software, desde la fase inicial hasta la fase final. El propósito de este programa es definir las distintas fases intermedias que se requieren para validar el desarrollo de la aplicación, es decir, para garantizar que el software cumpla los requisitos para la aplicación y verificación de los procedimientos de desarrollo: se asegura de que los métodos utilizados son apropiados.

Estos programas se originan en el hecho de que es muy costoso rectificar los errores que se detectan tarde dentro de la fase de implementación. El ciclo de vida permite que los errores se detecten lo antes posible y por lo tanto, permite a los desarrolladores concentrarse en la calidad del software, en los plazos de implementación y en los costos asociados.

El ciclo de vida básico de un software consta de los siguientes procedimientos:

• Definición de objetivos: definir el resultado del proyecto y su papel en la estrategia global.
• Análisis de los requisitos y su viabilidad: recopilar, examinar y formular los requisitos del cliente y examinar cualquier restricción que se pueda aplicar.
• Diseño general: requisitos generales de la arquitectura de la aplicación.
• Diseño en detalle: definición precisa de cada subconjunto de la aplicación.
• Programación (programación e implementación): es la implementación de un lenguaje de programación para crear las funciones definidas durante la etapa de diseño.
• Prueba de unidad: prueba individual de cada subconjunto de la aplicación para garantizar que se implementaron de acuerdo con las especificaciones.
• Integración: para garantizar que los diferentes módulos se integren con la aplicación. Éste es el propósito de la prueba de integración que está cuidadosamente documentada.
• Prueba beta (o validación), para garantizar que el software cumple con las especificaciones originales.
• Documentación: sirve para documentar información necesaria para los usuarios del software y para desarrollos futuros.
• Implementación
• Mantenimiento: para todos los procedimientos correctivos (mantenimiento correctivo) y las actualizaciones secundarias del software (mantenimiento continuo).

El orden y la presencia de cada uno de estos procedimientos en el ciclo de vida de una aplicación dependen del tipo de modelo de ciclo de vida acordado entre el cliente y el equipo de desarrolladores.

Modelos de ciclo de vida

Para facilitar una metodología común entre el cliente y la compañía de software, los modelos de ciclo de vida se han actualizado para reflejar las etapas de desarrollo involucradas y la documentación requerida, de manera que cada etapa se valide antes de continuar con la siguiente etapa.

Modelo en cascada

El modelo de ciclo de vida en cascada comenzó a diseñarse en 1966 y se terminó alrededor de 1970. Se define como una secuencia de fases en la que al final de cada una de ellas se reúne la documentación para garantizar que cumple las especificaciones y los requisitos antes de pasar a la fase siguiente:

Modelo V

El modelo de ciclo de vida V proviene del principio que establece que los procedimientos utilizados para probar si la aplicación cumple las especificaciones ya deben haberse creado en la fase de diseño.

<====--------------------(°º¤ø,¸¸,ø¤º°`°º¤ø,¸°º¤ø,¸¸,ø¤º°`°º¤ø,¸.)--------------------===>>

Unified Modeling Language

(UML)

Lenguaje Unificado de Modelado ( ó UML).

Es el lenguaje de modelado de sistemas de software más conocido y utilizado en la actualidad; está respaldado por el OMG (Object Management Group). Es un lenguaje gráfico para visualizar, especificar, construir y documentar un sistema. UML ofrece un estándar para describir un "plano" del sistema (modelo), incluyendo aspectos conceptuales tales como procesos de negocio, funciones del sistema, y aspectos concretos como expresiones de lenguajes de programación, esquemas de bases de datos y componentes reutilizables.

Es importante resaltar que UML es un "lenguaje de modelado" para especificar o para describir métodos o procesos. Se utiliza para definir un sistema, para detallar los artefactos en el sistema y para documentar y construir. En otras palabras, es el lenguaje en el que está descrito el modelo.

Se puede aplicar en el desarrollo de software gran variedad de formas para dar soporte a una metodología de desarrollo de software (tal como el Proceso Unificado Racional o RUP), pero no especifica en sí mismo qué metodología o proceso usar.

UML no puede compararse con la programación estructurada, pues UML significa Lenguaje Unificado de Modelado, no es programación, solo se diagrama la realidad de una utilización en un requerimiento. Mientras que, programación estructurada, es una forma de programar como lo es la orientación a objetos, sin embargo, la programación orientada a objetos viene siendo un complemento perfecto de UML, pero no por eso se toma UML sólo para lenguajes orientados a objetos.

* Tipos de Diagramas 

UML cuenta con varios tipos de diagramas, los cuales muestran diferentes aspectos de las entidades representadas.

Diagrama de Clases: sirve para mostrar la estructura estática de un sistema, ya sean estas las clases como los paquetes.

- Diagrama de Estructura Compuesta: nuevo en UML2, este diagrama muestra la estructura INTERNA de un elemento o clase.

- Diagrama de Componente: muestra el sistema como una colección de componentes tecnológicos, ejecutables, DLLs, páginas de HTML, etc.

- Diagrama de Despliegue: muestra como el los componentes de un sistema se distribuyen entre los computadores que los ejecutan. Útil en el caso de sistemas distribuidos.

- Diagrama de Objeto: muestra instancias de clases y sus nexos.

- Diagrama de Paquete: muestra paquetes y sus relaciones, suele ser útil para la gestión de un modelo grande en UML.

- Diagrama de actividad: suerte de diagrama de flujo, indican actividades, decisiones y bifurcaciones.

- Diagrama de Secuencia: muestra la interacción entre elementos indicando claramente el eje de tiempo (hay un ejemplo en “Análisis de Casos de Uso”)

- Diagrama de Comunicación: equivale a un diagrama de secuencia, pero colapsa el eje del tiempo.

- Diagrama de Resumen de Interacción: dado que no hay paquetes de actividades se muestran las partes de un diagrama de actividad agrupando estas a la manera de un paquete, pero con un símbolo distinto.

- Diagrama de Tiempo: muestra la evolución de uno o más componente como líneas de vidas que se cruzan en un eje de tiempo. Esto es útil en desarrollo de sistemas en tiempo real.

- Diagrama de Casos de Uso: sirve para ilustrar un modelo de casos de uso. En el blog hay muchos ejemplos de estos.

- Diagrama de Maquina de Estado: muestra el sistema como estados y transiciones entre estos. Las maquinas de estado son un concepto muy bien establecido en ingeniería. En UML2 se usa un formalismo basado en redes de Petri, con lo que estos diagramas adquieren mucho mayor poder.

El total de diagramas es de trece.

Ahora que no veo la razón por la cual la especificación diferencia entre diagrama de clases y diagrama de paquetes. En la práctica uno puede hacer un diagrama con clases y paquetes, dando a lugar a un diagrama mixto. Muchas herramientas de UML no diferencian entre estos dos tipos de diagramas.

Los diagramas nuevos suelen tener muy poco soporte. Especialmente los diagramas de Tiempo. Aún estoy esperando encontrar una herramienta que le de soporte y los use para algo más que tener el diagrama.

La diferencia entre los diagramas de secuencia y los de comunicación es solo de gusto. Son por completo equivalentes y de hecho las herramientas suelen poder convertir automáticamente entre estos dos. Ya que es de gusto, a mí me gustan más los de secuencia.

Los diagramas de maquina de estado son en extremo útiles, pero solo si uno esta haciendo un sistema con este concepto en mente. Si lo que uno hace es un sistema de información (un CRM, un CMS, un ERP, etc.) entonces posiblemente no se le encuentre uso.

Finalmente los diagramas de actividad son un legado de otras metodologías de desarrollo. Son útiles para documentar procesos y otras cosas como esas, pero no lo son tanto para el desarrollo de software.