4 DE JUNIO DEL 2014
SEMANA # 1
INTRODUCCIÓN
Los modelos de procesos prescriptivos fueron presentados inicialmente para poner
orden en el caos del desarrollo de software. Estos modelos han servido de
mucho, es decir han sido muy útil al trabajo de ingeniería de software.
MARCO TEÓRICO
MODELO DE PROCESO
PRESCRIPTIVO
MODELOS CONCURRENTES
El modelo de desarrollo concurrente,
en ocasiones llamado ingeniería concurrente, permite que un equipo de software
represente elementos iterativos y concurrentes de cualquiera de los modelos de
proceso descritos en este capítulo. Por ejemplo, la actividad de modelado
definida para el modelo espiral se logra por medio de invocar una o más de las
siguientes acciones de software: hacer prototipos, análisis y diseño.
La siguiente figura muestra la representación esquemática de una actividad de
ingeniería de software dentro de la actividad de modelado con el uso del
enfoque de modelado concurrente. La actividad modelado puede estar en
cualquiera de los estados mencionados en un momento dado. En forma similar, es
posible representar de manera análoga otras actividades, acciones o tareas (por
ejemplo, comunicación o construcción). Todas las actividades de ingeniería de
software existen de manera concurrente, pero se hallan en diferentes estados.
Por ejemplo, la actividad de comunicación (no se muestra en la figura) termina
su primera iteración al principio de un proyecto y existe en el estado de
cambios en espera. La actividad de modelado (que existía en estado inactivo
mientras concluía la comunicación inicial, ahora hace una transición al estado
en desarrollo. Sin embargo, si el cliente indica que deben hacerse cambios en
los requerimientos, la actividad de modelado pasa del estado en desarrollo al
de cambios en espera.
El modelado concurrente define una serie de eventos que desencadenan
transiciones de un estado a otro para cada una de las actividades, acciones o
tareas de la ingeniería de software.
Por ejemplo, durante las primeras
etapas del diseño (acción importante de la ingeniería de software que ocurre
durante la actividad de modelado), no se detecta una inconsistencia en el
modelo de requerimientos. Esto genera el evento corrección del modelo de
análisis, que disparará la acción de análisis de requerimientos del estado
terminado al de cambios en espera.
El modelado concurrente es aplicable a todos los tipos de desarrollo de
software y proporciona un panorama apropiado del estado actual del proyecto. En
lugar de confinar las actividades, acciones y tareas de la ingeniería de
software a una secuencia de eventos, define una red del proceso. Cada
actividad, acción o tarea de la red existe simultáneamente con otras
actividades, acciones o tareas. Los eventos generados en cierto punto de la red
del proceso desencadenan transiciones entre los estados.
MODELO DE PROCESO
INCREMENTAL
Hay muchas situaciones en las que los
requerimientos iniciales del software están razonablemente bien definidos, pero
el alcance general del esfuerzo de desarrollo imposibilita un proceso lineal.
Además, tal vez haya una necesidad imperiosa de dar rápidamente cierta
funcionalidad limitada de software a los usuarios y aumentarla en las entregas
posteriores de software. En tales casos, se elige un modelo de proceso diseñado
para producir el software en incrementos.
El modelo incremental combina
elementos de los flujos de proceso lineal y paralelo estudiados anteriormente
En relación con la figura siguiente, 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 [McD93] de manera parecida a los incrementos producidos en un flujo
de proceso evolutivo .Por ejemplo, un software para procesar textos que se
elabore con el paradigma incremental quizá entregue en el primer incremento las
funciones básicas de administración de archivos, edición y producción del
documento; en el segundo dará herramientas más sofisticadas de edición y
producción de documentos; en el tercero habrá separación de palabras y revisión
de la ortografía; y en el cuarto se proporcionará la capacidad para dar formato
avanzado a las páginas.
Debe observarse que el flujo de
proceso para cualquier incremento puede incorporar el paradigma del prototipo.
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 (algunas conocidas y otras no). El cliente usa el
producto fundamental (o lo somete a una evaluación detallada). Como resultado
del uso y/o evaluación, se desarrolla un plan para el incremento que sigue. El
plan 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. Este proceso se repite después de entregar cada incremento,
hasta terminar el producto final.
El modelo de proceso incremental se
centra en que en cada incremento se entrega un producto que ya opera. Los
primeros incrementos son versiones desnudas del producto final, pero
proporcionan capacidad que sirve al usuario y también le dan una plataforma de
evaluación.
El desarrollo incremental es útil en
particular 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. Si el producto básico es bien recibido,
entonces se agrega más personal (si se requiere) para que labore en el
siguiente incremento. Además, los incrementos se planean para administrar
riesgos técnicos. Por ejemplo, un sistema grande tal vez requiera que se
disponga de hardware nuevo que se encuentre en desarrollo y cuya fecha de
entrega sea incierta. En este caso, tal vez sea posible planear los primeros
incrementos de forma que eviten el uso de dicho hardware, y así proporcionar
una funcionalidad parcial a los usuarios finales sin un retraso importante.
EL MODELO ESPIRAL
El modelo de
desarrollo espiral es un generador de modelo de proceso impulsado por el
riesgo, que se usa para guiar la ingeniería concurrente con participantes
múltiples de sistemas intensivos en software.
Tiene dos características distintivas principales. La primera es el enfoque
cíclico para el crecimiento incremental del grado de definición de un sistema y
su implementación, mientras que disminuye su grado de riesgo. La otra es un
conjunto de puntos de referencia de anclaje puntual para asegurar el compromiso
del participante con soluciones factibles y mutuamente satisfactorias. 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 o
prototipo. En las iteraciones posteriores se producen versiones cada vez más
completas del sistema cuya ingeniería se está haciendo.
Un modelo en espiral es dividido por el equipo de software en un conjunto de
actividades estructurales. Para fines ilustrativos, se utilizan las actividades
estructurales generales ya analizadas.
Cada una de ellas representa un segmento de la trayectoria espiral ilustrada en
la siguiente figura. 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. El riesgo se considera conforme se
desarrolla cada revolución. En cada paso evolutivo se marcan puntos de
referencia puntuales: combinación de productos del trabajo y condiciones que se
encuentran a lo largo de la trayectoria de la espiral.El primer circuito
alrededor de la espiral da como resultado el desarrollo de una especificación
del producto; las vueltas sucesivas se usan para desarrollar un prototipo y,
luego, versiones cada vez más sofisticadas del software. Cada paso por la
región de planeación da como resultado ajustes en el plan del proyecto. El
costo y la programación de actividades se ajustan con base en la
retroalimentación obtenida del cliente después de la entrega. Además, el
gerente del proyecto ajusta el número planeado de iteraciones que se requieren
para terminar el software.
A diferencia de otros modelos del proceso que finalizan cuando se entrega el
software, el modelo espiral puede adaptarse para aplicarse a lo largo de toda
la vida del software de cómputo. Entonces, el primer circuito alrededor de la
espiral quizá represente un “proyecto de desarrollo del concepto” que comienza
en el centro de la espiral y continúa por iteraciones múltiples10 hasta que
queda terminado el desarrollo del concepto. Si el concepto va a desarrollarse
en un producto real, el proceso sigue hacia fuera de la espiral y comienza un
“proyecto de desarrollo de producto nuevo”. El nuevo producto evolucionará a
través de cierto número de iteraciones alrededor de la espiral. Más adelante
puede usarse un circuito alrededor de la espiral para que represente un
“proyecto de mejora del producto”. En esencia, la espiral, cuando se
caracteriza de este modo, sigue operativa hasta que el software se retira. Hay
ocasiones en las que el proceso está inmóvil, pero siempre que se inicia un
cambio comienza en el punto de entrada apropiado (por ejemplo, mejora del
producto).
El modelo espiral es un enfoque realista para el desarrollo de sistemas y de
software a gran escala. Como el software evoluciona a medida 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.
Mantiene el enfoque de escalón sistemático sugerido por el ciclo de vida
clásico, pero lo incorpora en una estructura iterativa que refleja al mundo
real en una forma más realista. 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.
Pero, como otros paradigmas, el modelo espiral no es una panacea. Es difícil
convencer a los clientes (en particular en situaciones bajo contrato) de que el
enfoque evolutivo es controlable.
Demanda mucha experiencia en la evaluación del riesgo y se basa en ella para
llegar al éxito.
No hay duda de que habrá problemas si algún riesgo importante no se descubre y
administra.
CONCLUSIÓN
Este
modelo de desarrollo concurrente lo usan las personas simultáneamente y al mismo tiempo desarrollan un
sin número de actividades importantes, tareas y estados ligados a ellas.
En
el modelo incremental a medida q se va incrementando nuevas funcionalidades se
mejora el producto de software..
El modelo espiral , es un modelo muy
completo pero complejo de entender es aplicable para proyectos de gran tamaño
con resultados excelentes.
BIBLIOGRAFÍA
Pressman, R. 2010. INGENIERÍA DEL
SOFTWARE. Un enfoque práctico. Séptima edición.
