Modelos de proceso: Modelos de Proceso de un sistema de software

Modelos de Proceso.

Ing. de Software

En la actualidad muchos problemas pueden ser solucionados mediante la implementación de una aplicación o un sistema de software pero ¿Cuál es el procedimiento para llevar a cabo la implementación de un sistema? ¿Cómo empezamos a desarrollar nuestro sistema?

Crear software es mucho más que sentarse a programar a prueba y error buscando siempre satisfacer las necesidades del cliente. El desarrollo de un sistema es aun mucho más complejo que eso, pues antes de empezar a programar y hacer esas cosas divertidas debemos llevar a cabo un análisis de todo el proceso de negocio, un análisis de las problemáticas que enfrenta el proceso actual, hablar con nuestro cliente y obtener los requisitos funcionales para poder proponer los requisitos no funcionales, realizar un cronograma de actividades para calcular el tiempo de desarrollo, ver con cuantos recursos humanos contamos y que tareas ejecutar cada uno, analizar los posibles riesgos que se presenten durante el desarrollo etc.

Como vemos desarrollar un sistema no es solo programar, es llevar a cabo un extenso análisis y proponer un diseño de nuestro sistema, por lo tanto es complicado saber por donde tenemos que empezar para desarrollar un buen sistema de software.

Actualmente no existe una normativa o un procedimiento que nos diga cómo resolver nuestro problema, pues la cantidad de problemas que puede atacar un software es muy extensa al igual que la manera de resolver dicho problema, así que podremos pensar en desarrollar nuestro sistema conforme vayan saliendo los requisitos que nos brindara el cliente, desafortunadamente esto conlleva a inconformidades por ambas partes (clientes y desarrolladores) pues el no realizar un estudio del proceso de negocio y necesidades hace que el cliente pueda exigirnos más cosas de las que se habían acordado. Es por eso que una mejor opción es comenzar con una etapa de análisis y diseño que se presentara a nuestro cliente para llegar a un acuerdo sobre lo que se tiene que hacer, límites y restricciones de nuestro sistema.

Ahora bien, ¿Cuál de todos estos análisis debemos atacar primero? Podemos realizar estos estudios dependiendo de nuestro problema pero también podemos seguir algunos modelos de proceso que han funcionado muy bien para muchos proyectos. Es por eso que escoger un modelo de proceso a la hora de desarrollar un sistema nos ayudara a llevar un control sobre las cosas que estamos haciendo.

Algunos de los modelos de proceso más comunes son:

Lineal secuencial

Cascada

Incremental

Iterativos

Espiral

Construcción de prototipos

Ensamblaje de componentes

Desarrollo rápido de Aplicaciones DRA

Ágiles

Antes de empezar a analizar algunos de los modelos de proceso debemos tomar en cuenta los siguientes conceptos:

Ciclo de vida

“Es una aproximación lógica a la adquisición, el suministro, el desarrollo, la explotación y el mantenimiento del software” (IEEE 1074)

“Un marco de referencia que contiene los procesos, las actividades y las tareas involucradas en el desarrollo, la explotación y el mantenimiento de un producto de software, abarcando la vida del sistema desde la definición de los requisitos hasta la finalización de su uso” (ISO 12207-1)

Proceso

Un proceso es un conjunto de actividades o eventos (coordinados u organizados) que se realizan o suceden (alternativa o simultáneamente) bajo ciertas circunstancias con un fin determinado

En un enfoque más específico un proceso es un conjunto de actividades planificadas que implican la participación de un número de personas y de recursos materiales coordinados para conseguir un objetivo previamente identificado. Se estudia la forma en que el Servicio diseña, gestiona y mejora sus procesos (acciones) para apoyar su política y estrategia y para satisfacer plenamente a sus clientes y otros grupos de interés.

Método

Palabra que proviene del término griego methodos (camino o vía) y se refiere al medio utilizado para llegar a un fin. Es un modo ordenado de proceder para llegar a un resultado o cumplir con un objetivo.

Metodología

Una metodología hace referencia al conjunto de procedimientos racionales utilizados para alcanzar una gama de objetivos que rigen en una investigación científica, una exposición doctrinal o tareas que requieran habilidades, conocimientos o cuidados específicos. Alternativamente puede definirse la metodología como el estudio o elección de un método pertinente para un determinado objetivo.

El concepto hace referencia al plan de investigación que permite cumplir ciertos objetivos en el marco de una ciencia. Cabe resaltar que la metodología también puede ser aplicada en el ámbito artístico, cuando se lleva a cabo una observación rigurosa. Por lo tanto, puede entenderse a la metodología como el conjunto de procedimientos que determinan una investigación de tipo científico o marcan el rumbo de una exposición doctrinal.

Herramienta

Cualquier procedimiento que mejora la capacidad de realizar ciertas tareas.

Paradigma

Paradigma significa «ejemplo» o «modelo». En todo el ámbito científico, religioso u otro contexto epistemológico, el término paradigma puede indicar el concepto de esquema formal de organización, y ser utilizado como sinónimo de marco teórico o conjunto de teorías.

Es un conjunto de realizaciones científicas "universalmente" reconocidas, que durante un tiempo proporcionan modelos de problemas y soluciones a una comunidad científica.

Teniendo claros los conceptos anteriores podemos describir algunos modelos de proceso que son utilizados para el desarrollo de un sistema de software

Modelo en cascada

El ciclo de vida inicialmente propuesto por Royce en 1970, fue adaptado para el software a partir de ciclos de vida de otras ramas de la ingeniería. Es el primero de los propuestos y el más ampliamente seguido por las organizaciones (se estima que el 90% de los sistemas han sido desarrollados así)

Este modelo admite la posibilidad de hacer iteraciones, es decir, durante las modificaciones que se hacen en el mantenimiento se puede ver por ejemplo la necesidad de cambiar algo en el diseño, lo cual significa que se harán los cambios necesarios en la codificación y se tendrán que realizar de nuevo las pruebas, es decir, si se tiene que volver a una de las etapas anteriores al mantenimiento hay que recorrer de nuevo el resto de las etapas. Después de cada etapa se realiza una revisión para comprobar si se puede pasar a la siguiente.

Este modelo trabaja en base a documentos, es decir, la entrada y la salida de cada fase es un tipo de documento específico. Idealmente, cada fase podría hacerla un equipo diferente gracias a la documentación generada

Etapas

Requisitos: Debido a que el software es siempre parte de un sistema mayor el trabajo comienza estableciendo los requisitos de todos los elementos del sistema y luego asignando algún subconjunto de estos requisitos al software. El proceso de recopilación de los requisitos se centra e intensifica especialmente en el software. El ingeniero de software (Analistas) debe comprender el ámbito de la información del software, así como la función, el rendimiento y las interfaces requeridas.

Diseño: el diseño del software se enfoca en cuatro atributos distintos del programa: la estructura de los datos, la arquitectura del software, el detalle procedimental y la caracterización de la interfaz. El proceso de diseño traduce los requisitos en una representación del software con la calidad requerida antes de que comience la codificación.

Implementación: el diseño debe traducirse en una forma legible para la maquina. El paso de codificación realiza esta tarea. Si el diseño se realiza de una manera detallada la codificación puede realizarse mecánicamente.

Verificación: una vez que se ha generado el código comienza la prueba del programa. La prueba se centra en la lógica interna del software, y en las funciones externas, realizando pruebas que aseguren que la entrada definida produce los resultados que realmente se requieren.

Mantenimiento: el software sufrirá cambios después de que se entrega al cliente. Los cambios ocurrirán debido a que hayan encontrado errores, a que el software deba adaptarse a cambios del entorno externo (sistema operativo o dispositivos periféricos), o debido a que el cliente requiera ampliaciones funcionales o del rendimiento.

Ventajas

La planificación es sencilla.

La calidad del producto resultante es alta.

Permite trabajar con personal poco cualificado.

Desventajas

En la vida real, un proyecto rara vez sigue una secuencia lineal, esto crea una mala implementación del modelo, lo cual hace que lo lleve al fracaso.

El proceso de creación del software tarda mucho tiempo ya que debe pasar por el proceso de prueba y hasta que el software no esté completo no se opera. Esto es la base para que funcione bien.

Cualquier error de diseño detectado en la etapa de prueba conduce necesariamente al rediseño y nueva programación del código afectado, aumentando los costos del desarrollo.

Modelo de prototipos

El Modelo de construcción de prototipos pertenece a los modelos de desarrollo evolutivo

, el prototipo debe ser construido en poco tiempo, usando los programas adecuados y no se debe utilizar mucho dinero pues a partir de que éste sea aprobado nosotros podemos iniciar el verdadero desarrollo del software.

Etapas

Comunicación: El ingeniero de software y el cliente encuentran y definen los objetivos globales para el software, identifican los requisitos conocidos y las áreas del esquema en donde es necesaria más definición.

Plan rápido: Después de la comunicación se plantea una pre-solución o prototipo el cual sera solo una idea general de lo que el cliente quiere.

Modelado, diseño rápido: se empieza con una iteración de construcción de prototipos y se presenta el modelado (en la forma de un diseño rápido). El diseño rápido se centra en una representación de aquellos aspectos del software que serán visibles para el usuario final.

Construcción del Prototipo: comienza la implementación del prototipo propuesto en la etapa anterior.

Desarrollo, entrega y retroalimentación: Se muestra el prototipo al usuario y lo evalúa con retroalimentaciones que servirán para redefinir los requisitos del software. Esto permite que al mismo tiempo el desarrollador entienda mejor lo que se debe hacer.

Modelo en Espiral

Boehm, ideó y promulgó un modelo desde un enfoque distinto al tradicional en Cascada: El Modelo Evolutivo Espiral. Su Modelo de Ciclo de Vida en Espiral tiene en cuenta fuertemente el riesgo que aparece a la hora de desarrollar software. Para ello, se comienza mirando las posibles alternativas de desarrollo, se opta por la de riesgo más asumible y se hace un ciclo de la espiral. Si el cliente quiere seguir haciendo mejoras en el software, se vuelve a evaluar las distintas nuevas alternativas y riesgos y se realiza otra vuelta de la espiral, así hasta que llegue un momento en el que el producto software desarrollado sea aceptado y no necesite seguir mejorándose con otro nuevo ciclo.

Básicamente consiste en una serie de ciclos que se repiten en forma de espiral, comenzando desde el centro. Se suele interpretar como que dentro de cada ciclo de la espiral se sigue un Modelo Cascada, pero no necesariamente debe ser así. El Espiral puede verse como un modelo evolutivo que conjuga la naturaleza iterativa del modelo MCP con los aspectos controlados y sistemáticos del Modelo Cascada, con el agregado de gestión de riegos.

Conclusión:

En conclusión podemos decir que para el desarrollo de un sistema de software hay que realizar un análisis en el proceso de negocio, en los riesgos y tomar en cuenta el tiempo que tenemos para desarrollar el sistema así podremos escoger el modelo que más se ajuste al ciclo de vida de nuestro proyecto.

Entregar documentos(análisis de riesgos, planearon, diagramas, estudio de factibilidad) nos da una gran ventaja a la hora de la entrega final, pues en ellos se especifica lo que deberá hacer el sistema, tanto limitaciones como restricciones.

Existen distintos modelos que nos ayudan a desarrollar un proyecto de software, pero siempre tendremos que adaptar el sistema al entorno y no al contrario, entonces es ideal seguir un modelo de ciclo de vida como los antes mencionados pero no es obligatorio; Realmente al cometer errores en el análisis o la implementación debemos regresar a alguna de las etapas del modelo de ciclo de vida elegido en nuestro proyecto, similar a lo que expresa la siguiente imagen.