modelo de desarrollo de software

Modelo de desarrollo de software

Para el desarrollo de cualquier producto de software se realizan una serie de tareas entre la idea inicial y el producto final.

Un modelo de desarrollo establece el orden en el que se harán las cosas en el proyecto, nos provee de requisitos de entrada y salida para cada una de las actividades.

Es necesario destacar el ciclo de vida del proyecto y el modelo de desarrollo.El ciclo de vida del proyecto ayuda a controlar las actividades del proyecto desde el inicio al fin del mismo.El modelo de desarrollo nos ayuda a la forma en la que vamos a construir el producto.Ambos se complementan para generar el producto desde el punto de vista técnico y administrativo.

Modelos de Desarrollo

El Modelo de Cascada.El Modelo en V.En Flor.PrototiposEl Modelo de Espiral.El Modelo de Procesos.Desarrollo Incremental.

El Modelo de Cascada

El modelo en cascada, uno de los primeros modelos de desarrollo de software que considera las diferentes actividades como fases separadas de tal forma que para iniciar una nueva actividad debe esperarse a la finalización de la actividad anterior. El resultado de cada etapa es uno o más documentos aprobados.
Las principales actividades de este modelo son las que podemos observar en el siguiente gráfico extraído de la red:

1. Análisis y definición de requerimientos: En esta etapa se definen los requisitos y requerimientos del sistema software a partir de consultas con los clientes y los usuarios del futuro sistema software. De esta etapa surge el documento de especificación de requisitos (SRD) que contiene toda la especificación del sistema sin entrar en detalles de diseño.

2. Diseño del sistema y del software: En esta etapa se dividen los requerimientos en subsistemas, se establece un arquitectura completa y se identifican y describen las relaciones fundamentales del sistema software. De esta etapa surge el documento de diseño del software (SDD) que contiene toda la descripción del sistema desde el punto de vista del diseño.

3. Implementación: En esta etapa el diseño del software se lleva a cabo implementándolo en un lenguaje de programación. Aquí se implementa el código fuente, se crean las bibliotecas y se reutilizan los componentes.

4. Pruebas: En esta etapa, los programas se integran y se prueban como un sistema completo para asegurar que se cumplen los requerimientos del software. Después de las pruebas el sistema se entrega al cliente.

5. Mantenimiento: Es la etapa más larga de todos los procesos de desarrollo. El sistema se instala y se pone en funcionamiento corrigiendo todos los errores no descubiertos en las etapas anteriores. También se mejora la implementación añadiendo nuevos requerimientos siempre que el usuario los necesite.

Este modelo ha sido muy criticado porque tiene muchas desventajas:

- Lo peor de todo es la necesidad de tener todos los requisitos al principio ya que lo normal es que el cliente no tenga perfectamente definidas las especificaciones surgiendo nuevos requisitos a lo largo de las diferentes etapas de desarrollo. Según este modelo hay que tenerTODOS los requisitos en la primera etapa no pudiendose llevar a cabo los requisitos que surgan una vez acabada la etapa de especificación.

- Es normal cometer errores en alguna de las etapas del proceso de desarrollo. Según este modelo cada vez que se identifique algún error cometido hay que volver a la etapa anterior y rehacer el trabajo.

- Por último, no se tiene el producto software hasta el final del proceso de desarrollo, por lo que el cliente no verá los resultados hasta la última fase. Además la mayoría de errores producidos en el análisis se descubren al final.

Así que este enfoque de desarrollo solo debería seguirse si tenemos muy claro las especificaciones desde el primer momento y sabemos que los requisitos no van a ser cambiantes.

El Modelo en V

El modelo en V es una variación del modelo en cascada que muestra cómo se relacionan las actividades de prueba con el análisis y el diseño. Como se muestra en la Figura 3, la codificación forma el vértice de la V, con el análisis y el diseño a la izquierda y las pruebas y el mantenimiento a la derecha.

La unión mediante líneas discontinuas entre las fases de la parte izquierda y las pruebas de la derecha representa una doble información. Por un lado sirve para indicar en qué fase de desarrollo se deben definir las pruebas correspondientes. Por otro sirve para saber a qué fase de desarrollo hay que volver si se encuentran fallos en las pruebas correspondientes.

Por lo tanto el modelo en V hace más explícita parte de las iteraciones y repeticiones de trabajo que están ocultas en el modelo en cascada. Mientras el foco del modelo en cascada se sitúa en los documentos y productos desarrollados, el modelo en V se centra en las actividades y la corrección.
Ventajas y desventajas  del Modelo en “V”
Ventajas:

• La relación entre las etapas de desarrollo y los distintos tipos de pruebas facilitan la localización de fallos.
• Es un modelo sencillo y de fácil aprendizaje
• Hace explícito parte de la iteración y trabajo que hay que revisar
• Especifica bien los roles de los distintos tipos de pruebas a realizar
• Involucra al usuario en las pruebas

Desventajas:
• Es difícil que el cliente exponga explícitamente todos los requisitos
• El cliente debe tener paciencia pues obtendrá el producto al final del ciclo de vida
• Las pruebas pueden ser caras y, a veces, no lo suficientemente efectivas
• El producto final obtenido puede que no refleje todos los requisitos del usuario

Prototipos

Un prototipo es una versión preliminar de un sistema de información con fines de demostración o evaluación.

Es un método menos formal de desarrollo.El prototipeo es una técnica para comprender las especificaciones.Un prototipo puede ser eliminado.Un prototipo puede llegar a ser parte del producto final.

Construcción de Prototipos

Identificación de Requerimientos.Diseño Rápido.Utilizar el Prototipo.Revisar y Mejorar.

Ventajas:

Útiles cuando los requerimientos son cambiantes.

Cuando no se conoce bien la aplicación.

Cuando el usuario no se quiere comprometer con los requerimientos.

Cuando se quiere probar una arquitectura o tecnología.

Cuando se requiere rapidez en el desarrollo.

Desventajas:

No se conoce cuando se tendrá un producto aceptable.

No se sabe cuantas iteraciones serán necesarias.

Da una falsa ilusión al usuario sobre la velocidad del desarrollo.

Se puede volver el producto aún y cuando no este con los estándares.

El Modelo de Espiral

El modelo en espiral del proceso del software que originalmente fue propuesto por Boehm (1988), El modelo en espiral es una de las metodologías más recomendables para el desarrollo y creación de un programa, ya que consta de pocas etapas o fases, las cuales se van realizando en una manera continua y cíclica.

La espiral tiene una forma de caracola y se dice que mantiene dos dimensiones:

Angular: Indica el avance del proyecto del software dentro de un ciclo.

Radial: Indica el aumento del coste del proyecto, ya que con cada nueva iteración se pasa más tiempo desarrollando.

Cada ciclo de la espiral se divide en 4 etapas:

DEFINICION DE OBJETIVOS:

Se definen los objetivos específicosSe identifican las restricciones del procesos y el productoSe identifican los riesgos del proyecto, dependiendo de los riesgos, se planean estrategias alternativas.EVALUACION Y REDUCCION DE RIESGOS:

Se lleva a cabo un análisis detallado para cada uno de los riesgos del proyecto.
Se definen los pasos para reducir dichos riesgos.

DESARROLLO Y VALIDACION:

 Se elige un modelo para el desarrollo del sistema. Por ejemplo, si los riesgos en la interfaz de usuario son dominantes, un modelo de desarrollo apropiado podría ser la construcción de prototipos evolutivos.
El modelo de cascada es el mas apropiado para el desarrollo si el mayor riesgo identificado es la integración de los subsistemas.

PLANEACION:

 El proyecto se revisa y se toma la decisión de si se debe continuar con un ciclo posterior de la espiral. 

ventajas
Entre sus ventajas están que al pasar a otro nivel se debe preguntar si se sigue, se repite o se anula el proyecto con esto nos evitamos errores y despilfarro de tiempo y dinero. Otra ventaja es que antes de que ocurra un problema nosotros podemos actuar y controlarlo.

Desventajas:

• Requiere mucha experiencia y habilidad para la evaluación de los riesgos, lo cual es requisito para el éxito del proyecto.

• Es difícil convencer a los grandes clientes que se podrá controlar este enfoque evolutivo.

Desarrollo Incremental

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 al final de cada incremento a fin de que el software se adapte mejor a sus necesidades reales. 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.

El Modelo Incremental es particularmente útil cuando no se cuenta con una dotación de personal suficiente. Los primeros pasos los pueden realizar un grupo reducido de personas y en cada incremento se añadir• personal, de ser necesario. Por otro lado los incrementos se pueden planear para gestionar riesgos técnicos.

El Modelo Incremental se puede ver aquí en forma grafica:

- 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.

Pipeline

La arquitectura en pipeline (basada en filtros) consiste en ir transformando un flujo de datos en un proceso comprendido por varias fases secuenciales, siendo la entrada de cada una la salida de la anterior.

Esta arquitectura es muy común en el desarrollo de programas para el intérprete de comandos, ya que se pueden concatenar comandos fácilmente con tuberías (pipe).

También es una arquitectura muy natural en el paradigma de programación funcional, ya que equivale a la composición de funciones matemáticas.

Interprete de comandos

Parte fundamental de un sistema operativo que ordena la ejecución de mandatos obtenidos del usuario por medio de una interfaz alfanumérica.

Características

- Se evitan proyectos largos y se entrega “algo de valor” a los usuarios con cierta frecuencia.

- El usuario se involucre más.

- Difícil de evaluar el costo 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.