Modelos de desarrollo de software

Jesus David Gil Berdugo

"La creación del software es un proceso intrínsecamente creativo y la ingeniería del software trata de sistematizar este proceso con el fin de acotar el riesgo del fracaso en la consecución del objetivo creativo por medio de diversas técnicas que se han demostrado adecuadas en base a la experiencia previa."

Etapas del proceso

Análisis de requisitos: Extraer los requisitos de un producto de software es la primera etapa para crearlo. Mientras que los clientes piensan que ellos saben lo que el software tiene que hacer, se requiere habilidad y experiencia para reconocer requisitos incompletos, ambiguos o contradictorios.

Especificación:
La especificación de requisitos describe el comportamiento esperado en el software una vez desarrollado. Gran parte del éxito de un proyecto de software radicará en la identificación de las necesidades del negocio (definidas por la alta dirección), así como la interacción con los usuarios funcionales.

Entre las técnicas utilizadas para la especificación de requisitos se encuentran:

Caso de uso,

Historias de usuario,

Siendo los primeros más rigurosas y formales, los segundas más ágiles e informales.

Arquitectura: lA ARQUITECTURA DE SOFTWARE CONSISTE EN EL DISEÑO DE COMPONENTES DE UNA APLICACIÓN (ENTIDADES DEL NEGOCIO), GENERALMENTE UTILIZANDO PATRONES DE ARQUITECTURA. EL DISEÑO ARQUITECTÓNICO DEBE PERMITIR VISUALIZAR LA INTERACCIÓN ENTRE LAS ENTIDADES DEL NEGOCIO Y ADEMÁS PODER SER VALIDADO, POR EJEMPLO POR MEDIO DE DIAGRAMAS DE SECUENCIA. UN DISEÑO ARQUITECTÓNICO DESCRIBE EN GENERAL EL CÓMO SE CONSTRUIRÁ UNA APLICACIÓN DE SOFTWARE. PARA ELLO SE DOCUMENTA UTILIZANDO DIAGRAMAS, POR EJEMPLO:

Diagramas de clases

Diagramas de base de datos

Diagrama de despliegue

Diagrama de secuencia

Programación: Reducir un diseño a código puede ser la parte más obvia del trabajo de ingeniería de software, pero no necesariamente es la que demanda mayor trabajo y ni la más complicada. La complejidad y la duración de esta etapa está íntimamente relacionada al o a los lenguajes de programación utilizados, así como al diseño previamente realizado.

Prueba: Consiste en comprobar que el software realice correctamente las tareas indicadas en la especificación del problema. Una técnica de prueba es probar por separado cada módulo del software, y luego probarlo de forma integral, para así llegar al objetivo. Se considera una buena práctica el que las pruebas sean efectuadas por alguien distinto al desarrollador que la programó, idealmente un área de pruebas; sin perjuicio de lo anterior el programador debe hacer sus propias pruebas. En general hay dos grandes formas de organizar un área de pruebas, la primera es que esté compuesta por personal inexperto y que desconozca el tema de pruebas, de esta forma se evalúa que la documentación entregada sea de calidad, que los procesos descritos son tan claros que cualquiera puede entenderlos y el software hace las cosas tal y como están descritas. El segundo enfoque es tener un área de pruebas conformada por programadores con experiencia, personas que saben sin mayores indicaciones en qué condiciones puede fallar una aplicación y que pueden poner atención en detalles que personal inexperto no consideraría.

Documentación: Todo lo concerniente a la documentación del propio desarrollo del software y de la gestión del proyecto, pasando por modelos (UML),diagramas de casos de uso, pruebas, manuales de usuario, manuales técnicos, entre otros; todo con el propósito de eventuales correcciones, usabilidad, mantenimiento futuro y ampliaciones al sistema.
Mantenimiento: Fase dedicada a mantener y mejorar el software para corregir errores descubiertos e incorporar nuevos requisitos. Esto puede llevar más tiempo incluso que el desarrollo del software inicial. Alrededor de 2/3 del tiempo de ciclo de vida de un proyecto está dedicado a su mantenimiento. Una pequeña parte de este trabajo consiste eliminar errores (bugs); siendo que la mayor parte reside en extender el sistema para incorporarle nuevas funcionalidades.

Modelos

La ingeniería de software dispone de varios modelos, paradigmas y filosofías de desarrollo, en los cuales se apoya para la construcción del software, entre ellos se puede citar:

Modelo en cascada o Clásico (modelo tradicional)

Modelo de prototipos

Modelo en espiral

Desarrollo por etapas

Desarrollo iterativo y creciente o Iterativo e Incremental

RAD (Rapid Application Development)

Desarrollo concurrente

Proceso Unificado

RUP (Proceso Unificado de Rational)

MSF

Modelo de Prototipos

El Modelo de prototipos, en Ingeniería de software, pertenece a los modelos de desarrollo evolutivo. El prototipo debe ser construido en poco tiempo, usando los programas adecuados y no se debe utilizar muchos recursos.

Comienza con una recolección de requisitos por parte del desarrollador y el cliente o el usuario define los objetivos generales originando un diseño rápido permitiendo la participación directa del usuario en el análisis y diseño.

El diseño rápido se centra en una representación de aquellos aspectos del software que serán visibles para el cliente o el usuario final. Este diseño conduce a la construcción de un prototipo, el cual es evaluado por el cliente para una retroalimentación; gracias a ésta se refinan los requisitos del software que se desarrollará. La interacción ocurre cuando el prototipo se ajusta para satisfacer las necesidades del cliente. Esto permite que al mismo tiempo el desarrollador entienda mejor lo que se debe hacer y el cliente vea resultados a corto plazo.

Estos prototipos son efectivos cuando nunca antes se ha diseñado un sistema con las características que requiere el usuario o no se identifican todos las características a pesar de un riguroso análisis de requerimientos.

Ventajas

Probar ideas

Participación Activa del usuario

Permite entender mejor un problema antes de la implementan final

Reduce el riesgo de construir productos que no satisfacen las necesidades del cliente

Reduce costos y aumenta la probabilidad de éxito

Énfasis en la interfaz de usuario

Equipo de desarrollo pequeño

Funciona muy bien apadrinado por alguno de los otros modelos

Etapas

Plan rápido: Recolección y refinamiento de requisitos
Modelado: diseño rápido
Construcción del Prototipo
Desarrollo, entrega y retroalimentación: Evaluación del prototipo por el cliente, refinamiento del prototipo
Entrega del desarrollo final: Producto ingeniería

Desechable / Evolutivo

El primero utilizado para eliminar dudas respecto a las necesidad del cliente ademas de presentar la interfaz que mejor convenga el evolutivo es un modelo parcialmente construido que puede pasar de un prototipo a ser producto final pero no tiene buena documentación y menos calidad

Estos modelos son útiles cuando los requerimientos son cambiantes o se quiere probar una tecnología nueva o solo se busca rapidez en el desarrollo

identificar requisitos e información que el usuario conoce, diseñar un prototipo que funcione para posteriores cambios y mejoras recolectando información a través de la experiencia del usuario para identificar nuevos requerimientos, construcción de un prototipo que funcione cumpliendo con todos lo requisitos identificados (responsabilidad del analista), evaluación del prototipo por el cliente para determinar si se agregan o eliminan características o se debe mejorar algún aspecto del sistema, en el refinamiento se aplica lo acordado luego de la intervención del cliente, al final se entrega un prototipo con todas las características que se acordaron.

Gráfico modelo de prototipo

Inconvenientes

No presenta calidad ni robustez.

El usuario tiende a crearse unas expectativas cuando ve el prototipo de cara al sistema final y quiere empezar a usarlo para resolver su problema.

O por ser un prototipo el usuario se desanima viendo un modelo inconcluso o poco estético

A causa de la intención de crear un prototipo de forma rápida, se suelen desatender aspectos importantes, tales como la calidad y el mantenimiento a largo plazo, lo que obliga en la mayor parte de los casos a reconstruirlo una vez que el prototipo ha cumplido su función. Es frecuente que el usuario se muestre reacio a ello y pida que sobre ese prototipo se construya el sistema final, lo que lo convertiría en un prototipo evolutivo, pero partiendo de un estado poco recomendado.

En aras de desarrollar rápidamente el prototipo, el desarrollador suele tomar algunas decisiones de implementación poco convenientes (por ejemplo, elegir un lenguaje de programación incorrecto porque proporcione un desarrollo más rápido). Con el paso del tiempo, el desarrollador puede olvidarse de la razón que le llevó a tomar tales decisiones, con lo que se corre el riesgo de que dichas elecciones pasen a formar parte del sistema final.