Modelos de procesos prescriptivos

YILIBER MARTINEZ CORREA:

Modelos de procesos prescriptivos:

Estos modelos fueron propuestos originalmente para poner orden en el caos del desarrollo de software. L historia indica que estos modelos tradicionalmente han dado cierta estructura útil al trabajo de ingeniería de software y que constituyen un mapa razonablemente eficaz para los equipos de software, sin embargo, el trabajo de ingeniería de software y el producto que genera siguen al borde del caos. El borde del caos es visualiza como un estado inestable y parcialmente estructurado. Tenemos la tendencia de pensar que el orden es el estado ideal de la naturaleza, pero investigaciones apoyan la teoría de que la operación que se aleja del equilibrio genera creatividad, procesos autoorganizados y rendimientos crecientes. El cambio ocurre cuando hay cierta estructura que perita que el cambio pueda organizarse. Demasiado caos hace imposible la coordinación y la coherencia. La falta de estructura no siempre significa desorden

Modelo de la cascada:

Cuando los requerimientos para cierto problema se comprenden bien, cuando el trabajo desde la comunicación hasta el despliegue fluye en forma razonablemente línea. También ocurre en cierto número limitado de nuevos esfuerzos de desarrollo. Pero solo cuando los requerimientos están bien definidos y tienen una estabilidad razonable, este modelo sugiere un enfoque sistemático y secuencial para el desarrollo de software, que comienza con la especificación de los requerimientos por parte del cliente y avanza a través de planeación, modelado, construcción y despliegue para concluir con el apoyo del software terminado. Una variante del modelo de la cascada es el modelo en V. este modelo es el paradigma más antiguo de la ingeniería de software. Sin embargo las críticas han hecho que sus defensores cuestionen su eficacia entre los problemas que surgen en este enfoque: 1) es raro que los proyectos sigan el flujo secuencial propuesto por le modelo. 2) a menudo es difícil para el cliente enunciar de forma explícita todos los requerimientos. 3) el cliente debe tener paciencia. No se dispondrá de una versión funcional hasta que el proyecto esté muy avanzado. No obstante sirve como un modelo de proceso útil en situaciones en los que los requerimientos son fijos y e trabajo avanza en forma lineal hasta el final

[pic 1]

Modelos de proceso incremental:

Hay muchas situaciones en las que los requerimientos iniciales del software están razonablemente bien definidos, pero el alcance imposibilita un procesos lineal. El modelo incremental combina elementos de los flujos de proceso lineal y paralelo. El modelo incremental aplica secuencias lineales en forma escalonada a medida que avanza el calendario de actividades. Cada secuencia lineal produce “incrementos” de software susceptibles de entregarse. De manera parecida a los incrementos producidos en el flujo de proceso evolutivo. Cuando se utiliza un modelo incremental, es frecuente que el primer incremento sea el producto fundamental. Es decir se abordan los requerimientos básicos pero no se proporcionan muchas características suplementarias. Se siguen un plan que incluye la modificación del producto fundamental para cumplir mejor las necesidades del cliente, así como la entrega de características adicionales y más funcionalidad. Esto se hace cada vez que se entrega un incremento hasta terminar el producto final. El modelo incremental se centra en que cada incremento se entrega un producto que ya opera. El desarrollo incremental es útil cuando no se dispone de personal para la implementación completa del proyecto en el plazo establecido por el negocio. Los primeros incrementos se desarrollan con pocos trabajadores. Los incrementos se planean para administrar riesgos técnicos

[pic 2]

Modelos de proceso evolutivo:

El software como todos los sistemas complejos, evoluciona con el tiempo, es frecuente que los requerimientos del negocio y el producto cambien conforme pasa el tiempo lo que hace que no sea realista trazar una trayectoria rectilínea hacia el producto final. Es estas situaciones y otras parecidas se necesitan un modelo de proceso diseñando explícitamente para adaptarse a un producto que evoluciona con el tiempo. Los modelos evolutivos son iterativos, se caracterizan por la manera en la que permiten desarrollar versiones cada vez más complejas del software, se presentan dos modelos comunes de proceso evolutivo: hacer prototipo: el paradigma de hacer prototipos comienza con la comunicación. Usted se reúne con otros participantes para definir los objetivos generales del software. Identifica cualesquiera requerimientos que conozca y detecta las áreas en las que es imprescindible una mayor definición. Este se centra en la representación de aquellos aspectos del software que serán visibles para los usuarios finales. El ideal es que el prototipo sirva como mecanismo para identificar los requerimientos del software. Hacer prototipos llega a ser problemático por los sgtes razones: 1) los participantes ven lo que parece ser una versión funcional del software, son darse cuenta de que el prototipo se obtuvo de manera caprichosa. No perciben que en la prisa por hacer que funcionara, usted no considero la calidad general del software a la facilidad de darle mantenimiento a largo plazo. 2) como ingeniero de software, es frecuente que llegue a compromisos respecto de la implementación a fin de hacer que le software funcione rápido. Quizá utilice un sistema operativo inapropiado, o un lenguaje de programación tan solo porque cuenta con el y lo conoce. La elección de algo menos que lo ideal ahora ha pasado a formar parte el sistema. Aunque puede haber problemas hacer prototipos es un paradigma eficaz para la ingeniería de software. El modelo espiral: es un modelo evolutivo del proceso del software y se acopla con la naturaleza iterativa de hacer prototipos con los aspectos controlados y sistémicos del modelo de cascada con el empleo del modelo espiral, el software se desarrolla en una serie de entregas evolutivas. Durante las primeras iteraciones lo que se entrega puede ser un modelo de prototipo. Un modelo espiral es dividido por el equipo de software en un conjunto de actividades estructurales cada una de ellas representa un segmento de la trayectoria espiral, al comenzar el proceso evolutivo, el equipo de software realiza actividades implícitas en un circuito alrededor de la espiral en el sentido horario, partiendo del centro en cada paso se marcan puntos de referencia puntuales: combinación de productos del trabajo y condiciones que se encuentran a lo largo de la trayectoria espiral. A diferencia de otros modelos que finalizan cuando se entrega el software, e modelo espiral puede adaptarse para aplicarse a lo largo de toda la vida de software de cómputo. El modelo espiral es un enfoque realista para el desarrollo de sistemas y de software a gran escala. Como el software evoluciona a medida de que el proceso avanza, el desarrollador y cliente comprenden y reaccionan mejor ante los riesgos en cada nivel de evolución. El modelo espiral usa los prototipos como mecanismo de reducción de riesgos, pero más importante, permite aplicar el enfoque de hacer prototipos en cualquier etapa de la evolución del producto. El modelo espiral demanda una consideración directa de los riesgos técnicos en todas las etapas del proyecto y, si se aplica de manera apropiada, debe reducir los riesgos antes de que se vuelvan un problema, demanda mucha experiencia en la evaluación del riesgo y se basa en ella para llegar al éxito. No hay duda que habrá problemas si algún riesgo importante no se descubre o administra.

...