Modelos de Procesos de Software y Metodologias de Desarrollo

Por su naturaleza, los modelos son simplificaciones; por lo tanto, un modelo de procesos del software es una simplificación o abstracción de un proceso real.

Podemos definir un modelo de procesos del software como una representación abstracta de alto nivel de un proceso software.

Cada modelo es una descripción de un proceso software que se presenta desde una perspectiva particular. Alternativamente, a veces se usan los términos ciclo de vida y Modelo de ciclo de vida. Cada modelo describe una sucesión de fases y un encadenamiento entre ellas.

Una metodología es un conjunto de procedimientos que permiten producir y mantener un producto software, esto es, define una serie de pasos a seguir para obtener un software de calidad.

Modelos Vs. Metodologias

Modelo Lineal Secuencial

Es el más antiguo de todos los modelos de Ingeniería del Software. El modelo lineal presenta una estructura secuencial (de ahí el nombre de Modelo en cascada).
Es también conocido como “Modelo en cascada”, “Modelo lineal secuencial”, “Ciclo de vida básico” o “Ciclo de vida clásico”.
Es un refinamiento altamente influenciado para 1970 del modelo de etapas. Tiene su origen en el "Modelo de cascada" ingeniado por Winston Royce, sugiere un enfoque sistemático o más bien secuencial del desarrollo de software que comienza en un nivel de sistemas y progresa con el análisis, diseño, codificación, pruebas y mantenimiento.

El MLS tiene las siguientes actividades:

• Análisis de los requerimientos del software: es la fase en la cual se reúnen todos los requisitos que debe cumplir el software. En esta etapa es fundamental la presencia del cliente que documenta y repasa dichos requisitos.
• Diseño: es una etapa dirigida hacia la estructura de datos, la arquitectura del software, las representaciones de la interfaz y el detalle procedimental (algoritmo). En forma general se hace un esbozo de lo solicitado y se documenta haciéndose parte del software.
• Generación del código: es la etapa en la cual se traduce el diseño para que sea comprensible por la máquina. Esta etapa va a depender estrechamente de lo detallado del diseño.
• Pruebas: esta etapa se centra en los procesos lógicos internos del software, asegurando que todas las sentencias se han comprobado, y en la detección de errores.
• Mantenimiento: debido a que el programa puede tener errores, puede no ser del completo agrado del cliente o puede necesitar, eventualmente acoplarse a los cambios en su entorno. Esto quiere decir que no se rehace el programa, sino que sobre la base de uno ya existente se realizan algunos cambios.

Desventajas:

• Los proyectos raramente siguen el paradigma secuencial que propone el proyecto.
• Los responsables del desarrollo de software siempre se retrasan innecesariamente.
• No siempre se sigue el flujo secuencial.
• Es difícil tener un 100% de los requisitos al inicio.
• El cliente debe tener paciencia. Los primeros resultados serán hasta que ya este operando el sistema.

Representación Grafica Del Modelo

Estructurada MEDSI

Es una metodología estructurada para desarrollar sistemas de información en y para organizaciones de cualquier tipo. Entre las características resaltantes de esta metodología podemos destacar:

• Estructurada: esta característica se debe a dos razones esenciales:

a. Utiliza diferentes métodos y técnicas estructuradas.

b. Guía paso a paso de arriba hacia abajo el grupo que la aplica explicando primero de forma muy general lo que debe hacerse para luego entrar en los detalles.

• Completa. Cubre todas las distintas fases del ciclo de desarrollo de un sistema de información, desde la definición del proyecto hasta la implantación del sistema en la organización.

• Particionada. A fin de manipular mejor la inherente a un proyecto de este tipo, la metodología se divide en fases, y cada una de las fases esta compuesta por pasos los cuales están orientados a algún tipo de tópicos, aspecto o elemento de un sistema de información.

Construccion de Prototipos

Este modelo no secuencial, basado en la construcción de simulaciones o modelos ejecutables de aplicaciones, persigue un objetivo principal: la participación directa del cliente en la construcción del software requerido.
Tras recoger los requisitos tanto del cliente como del sistema, se comienza con el diseño rápido del prototipo; se hace un diseño preliminar, sobre el cual se construye un prototipo o modelo del sistema, compuesto a menudo de ventanas, tablas de la Base de Datos, formatos de entrada y de salida básicos.
Éste prototipo es el que mostraremos al cliente para que lo evalúe y considere cambios en él, aunque no se trate de una versión definitiva. El diseño completo obedece al previo diseño de pequeños prototipos específicos para funciones individuales. Más tarde, estos diseños serán unidos en uno sólo.

Ventajas:

• Reducción de la incertidumbre y del riesgo.
• Reducción de tiempo y de costos.
• Incrementos en la aceptación del nuevo sistema.
• Mejoras en la administración de proyectos.
• Mejoras en la comunicación entre desarrolladores y clientes, etc.

Desventajas:

• La mala interpretación que pueden hacer los usuarios del prototipo, al cual pueden confundir con el sistema terminado. El cliente ve funcionando lo que parece ser una primera versión del software, ignorando que, por las prisas en hacer que funcione, no se han considerado aspectos de calidad o mantenimiento del software a largo plazo.
• El técnico de desarrollo, usualmente, impone ciertos compromisos de implementación con el fin de obtener un prototipo que funcione rápidamente. Puede que utilice un sistema operativo inapropiado, o un lenguaje de programación equívoco o simplemente porque ya está disponible y es conocido, puede que implemente ineficientemente un algoritmo, sencillamente para demostrar su capacidad.

Representación Grafica Del Modelo

Orientado a Objetos. Rational Unified Process (RUP)

La metodología RUP, llamada así por sus siglas en inglés Rational Unified Process, divide en 4 fases el desarrollo del software:

• Inicio, El Objetivo en esta etapa es determinar la visión del proyecto.
• Elaboración, En esta etapa el objetivo es determinar la arquitectura óptima.
• Construcción, En esta etapa el objetivo es llevar a obtener la capacidad operacional inicial.
• Transmisión, El objetivo es llegar a obtener el release del proyecto.

Cada una de estas etapas es desarrollada mediante el ciclo de iteraciones, la cual consiste en reproducir el ciclo de vida en cascada a menor escala. Los Objetivos de una iteración se establecen en función de la evaluación de las iteraciones precedentes. Vale mencionar que el ciclo de vida que se desarrolla por cada iteración, es llevada bajo dos disciplinas:

Disciplina de Desarrollo

• Ingeniería de Negocios: Entendiendo las necesidades del negocio.
• Requerimientos: Trasladando las necesidades del negocio a un sistema automatizado.
• Análisis y Diseño: Trasladando los requerimientos dentro de la arquitectura de software.
• Implementación: Creando software que se ajuste a la arquitectura y que tenga el comportamiento deseado.
• Pruebas: Asegurándose que el comportamiento requerido es el correcto y que todo los solicitado esta presente.

Disciplina de Soporte

• Configuración y administración del cambio: Guardando todas las versiones del proyecto.
• Administrando el proyecto: Administrando horarios y recursos.
• Ambiente: Administrando el ambiente de desarrollo.
• Distribución: Hacer todo lo necesario para la salida del proyecto

Es recomendable que a cada una de estas iteraciones se les clasifique y ordene según su prioridad, y que cada una se convierte luego en un entregable al cliente. Esto trae como beneficio la retroalimentación que se tendría en cada entregable o en cada iteración.

Los elementos del RUP son:

• Actividades, Son los procesos que se llegan a determinar en cada iteración.
• Trabajadores, Vienen hacer las personas o entes involucrados en cada proceso.
• Artefactos, Un artefacto puede ser un documento, un modelo, o un elemento de modelo. Una particularidad de esta metodología es que, en cada ciclo de iteración, se hace exigente el uso de artefactos, siendo por este motivo, una de las metodologías más importantes para alcanzar un grado de certificación en el desarrollo del software.

Modelo Incremental

Perteneciente a la familia de los Modelos de Procesos Evolutivos, el Modelo Incremental combina elementos del MLS con la filosofía interactiva de construcción de prototipos.
En una visión genérica, el proceso se divide en 4 partes: Análisis, Diseño, Código y Prueba. Sin embargo, para la producción del Software, se usa el principio de trabajo en cadena o “Pipeline”, utilizado en muchas otras formas de programación. Con esto se mantiene al cliente en constante contacto con los resultados obtenidos en cada incremento. Es el mismo cliente el que incluye o desecha elementos. El proceso se repite hasta que se elabore el producto completo. De esta forma el tiempo de entrega se reduce considerablemente.
Al igual que los otros métodos de modelado, el Modelo Incremental es de naturaleza interactiva pero se diferencia de aquellos en que al final de cada incremento se entrega un producto completamente operacional.

En el Modelo Incremental:

• Se evitan proyectos largos y se entrega algo de valor a los usuarios con cierta frecuencia.
• El usuario se involucra más.
• Difícil de evaluar el coste total.
• Difícil de aplicar a los sistemas transaccionales que tienden a ser integrados y a operar como un todo.
• Requiere gestores experimentados.
• Los errores en los requisitos se detectan tarde.
• El resultado puede ser muy positivo.

Ventajas:

• Con un paradigma incremental se reduce el tiempo de desarrollo inicial, ya que se implementa la funcionalidad parcial.
• También provee un impacto ventajoso frente al cliente, que es la entrega temprana de partes operativas del Software.
• El modelo proporciona todas las ventajas del modelo en cascada realimentado, reduciendo sus desventajas sólo al ámbito de cada incremento.
• Permite entregar al cliente un producto más rápido en comparación del modelo de cascada.
• Resulta más sencillo acomodar cambios al acotar el tamaño de los incrementos.
• Por su versatilidad requiere de una planeación cuidadosa tanto a nivel administrativo como técnico.

Desventajas:

• El modelo Incremental no es recomendable para casos de sistemas de tiempo real, de alto nivel de seguridad, de procesamiento distribuido, y/o de alto índice de riesgos.
• Requiere de mucha planeación, tanto administrativa como técnica.
• Requiere de metas claras para conocer el estado del proyecto.

Representación Grafica Del Modelo

Desarrollo Ágil. Extreme Programing (XP)

Es una de las metodologías de desarrollo de software más exitosas en la actualidad utilizadas para proyectos de corto plazo, corto equipo y cuyo plazo de entrega era ayer. La metodología consiste en una programación rápida o extrema, cuya particularidad es tener como parte del equipo, al usuario final, pues es uno de los requisitos para llegar al éxito del proyecto.

Características de XP, la metodología se basa en:

• Pruebas Unitarias: se basa en las pruebas realizadas a los principales procesos, de tal manera que adelantándonos en algo hacia el futuro, podamos hacer pruebas de las fallas que pudieran ocurrir. Es como si nos adelantáramos a obtener los posibles errores.
• Refabricación: se basa en la reutilización de código, para lo cual se crean patrones o modelos estándares, siendo más flexible al cambio.
• Programación en pares: una particularidad de esta metodología es que propone la programación en pares, la cual consiste en que dos desarrolladores participen en un proyecto en una misma estación de trabajo. Cada miembro lleva a cabo la acción que el otro no está haciendo en ese momento. Es como el chofer y el copiloto: mientras uno conduce, el otro consulta el mapa.

Modelo Espiral

En 1988, Barry Boehm publicó un sistema de desarrollo de software formal "modelo en espiral", que combina algunos aspectos clave del modelo de cascada y rápidas metodologías de prototipos, añadiendo al mismo tiempo un nuevo elemento: el análisis de riesgo.

El modelo representado mediante la espiral define cuatro actividades principales:

• Planificación: Determinación de objetivos, alternativas y restricciones.
• Análisis de riesgo: Análisis de alternativas e identificación/resolución de riesgos.
• Ingeniería: Desarrollo del producto del "siguiente nivel".
• Evaluación del cliente: Valorización de los resultados de la ingeniería.

Ventajas:

1. En cada ciclo el cliente evalúa el trabajo.
2. Se llega al sistema final muy rápido.
3. Analiza el momento de salirse del ciclo.
4. Permite un considerable nivel de flexibilidad en un proyecto.

Desventajas:

1. El modelo en espiral destaca como modelo de análisis de riesgo, pero requieren que los clientes acepten y crean que gran parte de este análisis, y dar la respuesta pertinente no es fácil, por lo tanto, este modelo se ha adaptado al desarrollo de software a gran escala interna.
2. Si la aplicación de análisis de riesgo afectara en gran medida los beneficios del proyecto, el análisis de riesgo no tiene sentido, por lo tanto, el modelo espiral es sólo apto para los proyectos de software a gran escala.
3. Los buenos desarrolladores de software deben buscar los posibles riesgos, un análisis preciso del riesgo, de lo contrario, dará lugar a un mayor riesgo.

Representación Grafica Del Modelo

Basadas en Componentes

En esencia, un componente es una pieza de código preelaborado que encapsula alguna funcionalidad expuesta a través de interfaces estándar. Los componentes son los "ingredientes de las aplicaciones", que se juntan y combinan para llevar a cabo una tarea. Es algo muy similar a lo que podemos observar en el equipo de música que tenemos en nuestra sala. Cada componente de aquel aparato ha sido diseñado para acoplarse perfectamente con sus pares, las conexiones son estándar y el protocolo de comunicación está ya preestablecido. Al unirse las partes, obtenemos música para nuestros oídos.

El paradigma de ensamblar componentes y escribir código para hacer que estos componentes funcionen se conoce como Desarrollo de Software Basado en Componentes.

El uso de este paradigma posee algunas ventajas:

1. Reutilización del software. Nos lleva a alcanzar un mayor nivel de reutilización de software.
2. Simplifica las pruebas. Permite que las pruebas sean ejecutadas probando cada uno de los componentes antes de probar el conjunto completo de componentes ensamblados.
3. Simplifica el mantenimiento del sistema. Cuando existe un débil acoplamiento entre componentes, el desarrollador es libre de actualizar y/o agregar componentes según sea necesario, sin afectar otras partes del sistema.
4. Mayor calidad. Dado que un componente puede ser construido y luego mejorado continuamente por un experto u organización, la calidad de una aplicación basada en componentes mejorará con el paso del tiempo.

Modelo DRA (Desarrollo Rápido de Aplicaciones):

El modelo DRA, es un modelo de proceso del desarrollo del software lineal secuencial que enfatiza un ciclo de desarrollo extremadamente corto (Es una adaptación a alta velocidad del modelo lineal secuencial). El proceso DRA permite al equipo de desarrollo crear un sistema completamente funcional dentro de periodos muy cortos de tiempo.

El DRA comprende las siguientes etapas:

• Modelado de Gestión: aquí se modela el flujo de información entre las funciones de gestión. Este flujo debe "responder" a preguntas tales como ¿Qué información conduce el proceso de gestión?, ¿Quién la genera?, ¿A dónde va la información?, ¿Quién la procesa?
• Modelado de datos: se definen las características (atributos) de cada objeto, formado a partir del flujo de información, y las relaciones entre ellos.
• Modelado del proceso: las descripciones del proceso se crean para añadir, modificar, suprimir o recuperar un objeto de datos.
• Generación de aplicaciones: en lugar de crear software, el RAD reutiliza componentes de programas ya existentes o crea componentes reutilizables.
• Prueba y entrega: debido al punto anterior, los componentes ya han sido examinados y probados, lo cual permite que el tiempo de duración de las pruebas sea menor. Todo esto no impide que se tenga que probar cada uno de los nuevos componentes.

Desventajas:

• Para proyectos en gran escala se requiere recursos humanos suficientes como para crear el número suficiente de equipos.
• Debe haber un compromiso muy fuerte entre todas las partes para completar el sistema en el tiempo necesario.
• No es adecuado cuando los riesgos tecnicos son muy alto.

Representacion Gráfica del Modelo

Referencias a Paginas Web

http://msdn.microsoft.com/es-es/library/bb972268.aspx

http://www.tiposdesoftware.com/titulo-articulo.php?link=modelos-de-desarrollo-de-software

http://www.informatizate.net/articulos/metodologias_de_desarrollo_de_software_07062004.html

http://www.mitecnologico.com/Main/ModeloIncremental

http://www.monografias.com/trabajos14/medsi/medsi.shtml

http://html.rincondelvago.com/modelos-de-desarrollo-de-software.html

http://members.fortunecity.es/odi39/modelo.htm