MODELOS DEL PROCESO

Un modelo general de proceso

Se define como proceso de software a la estructura de actividades que se
requieren para construir software de alta calidad. Dichas actividades se
encuentran dentro de un modelo que define su relacin con el proceso entre
s.
Con respecto a la actividad estructural, las acciones apropiadas para dicha
actividad dependern de la naturaleza del problema a resolver, las
caractersticas de las personas que hacen el trabajo y los patrocinadores del
proyecto. Se definen 5 actividades estructurales: comunicacin, planeacin,
modelado, construccin y despliegue.
Cada accin de la ingeniera de software, se representa por un cierto
nmero de distintos conjuntos de tareas. Debe de escogerse el conjunto de
tareas que se acomode mejor al proyecto.
Con respecto al conjunto de tareas estas definen el trabajo real por efectuar
a fin de cumplir los objetivos de una accin de ingeniera de software. Por
ejemplo, la indagacin es una accin importante de la ingeniera de
software que ocurre durante la actividad de comunicacin. La meta al
recabar los requerimientos es entender lo que distintos participantes desean
de software que se va a elaborar.
Los patrones de proceso, describe un problema relacionado que se
encuentra durante el trabajo de ingeniera de software y se definen
cualquier nivel de abstraccin. Dicho de manera general un patrn de
proceso da un formato, y al combinar patrones un equipo de software
resuelve problemas y construye el proceso que mejor se acomode al
proyecto.
Ambler ha propuesto un formato para describir un patrn del proceso:
Nombre del patrn: El patrn recibe un nombre significativo que lo
describe en el contexto del proceso.
Fuerzas. El ambiente en el que se encuentra el patrn y los aspectos que
hacen visible al problema.
Tipo. Se especifica el tipo de patrn y se sugieren tres tipos.

1. Patrn de etapa: define un problema asociado con una actividad

estructural para el proceso, como una actividad estructural incluye
mltiples acciones y tareas del trabajo, un patrn de la etapa incorpora
mltiples acciones y tareas del trabajo.

2. Patrn de tarea: define un problema asociado con una accin o tarea de

trabajo de la ingeniera de software y que es relevante para el xito de
la prctica de ingeniera de software.
3. Patrn de fase: define la secuencia de las actividades estructurales que
ocurren dentro del proceso, aun cuando el flujo general de las
actividades sea de naturaleza iterativa.
Contexto inicial. Describe las condiciones en las que aplica el patrn.
Por ejemplo, el patrn planeacin requiere que:1) los clientes y los
ingenieros de software hayan establecido una comunicacin colaboradora;
2) haya terminado con xito cierto nmero de patrones de tarea. Y 3) se
conozcan el alcance del proyecto, los requerimientos bsicos del negocio y
las restricciones del proyecto.
Problema. El problema especfico que debe resolver el patrn.
Solucin. Describe cmo implementar con xito el patrn. Esta seccin
describe la manera como se modifica el estado inicial del proceso como
consecuencia de la iniciacin del patrn. Tambin se describe como se
transforma la informacin sobre la ingeniera de software o sobre el
proyecto disponible antes de que inicie el patrn, como consecuencia de la
ejecucin exitosa del patrn.
Los patrones de proceso dan un mecanismo efectivo para enfrentar
problemas asociados con cualquier proceso del software. Los patrones
permiten desarrollar una descripcin jerrquica del proceso, que comienza
en un nivel alto de abstraccin. Despus se mejora la descripcin como un
conjunto de patrones de etapa que describe las actividades estructurales y
se mejora an ms en forma jerrquica en patrones de tarea detallados
para cada etapa del patrn.

Evaluacin y mejora del proceso

La existencia de un proceso del software no es garanta de que el software
se entregue a tiempo y satisfaga las necesidades de los consumidores o que
tengan las caractersticas tcnicas que conducirn a caractersticas de
calidad a largo plazo. Los patrones de proceso deben acoplarse a una
prctica solida de la ingeniera de software.
ltimamente se han propuesto numerosos enfoques para la mejora y
evaluacin del proceso de software:
Mtodo de evaluacin estndar CMMI para el proceso de mejora,
proporciona un modelo de 5 etapas para evaluar el proceso.
Evaluacin mostrada en CMM para la mejora del proceso interno,
proporciona una tcnica de diagnstico para evaluar la madurez relativa de
una organizacin de software.

SPICE, el objetivo del estndar es ayudar a las organizaciones a desarrollar

una evaluacin efectiva de cualquier proceso de software.
ISO 9001:2000 para software, estndar genrico que se aplica a cualquier
organizacin para mejorar la calidad de los productos o sistemas o servicios
que proporciona.

Modelos del proceso prescriptivo

Los modelos de proceso prescriptivo fueron propuestos originalmente para
poner orden en el desarrollo de software. Estos modelos tradicionales han
dado cierta estructura til al trabajo de ingeniera de software y que
constituyen un mapa razonablemente eficaz para los equipos de software.
EL modelo de cascada, llamado tambin ciclo de vida clsico, sugiere un
enfoque sistemtico y secuencial para el desarrollo del software que
comienza con la especificacin de requerimientos por parte del cliente a
travs de la planeacin, modelado, despliegue y construccin para concluir
con el apoyo del software terminado.
El modelo de la cascada es el paradigma ms antiguo de la ingeniera de
software desde hace tres dcadas. Entre los problemas que en ocasiones
surgen al aplicar el modelo de la cascada se encuentran los siguientes.
Es raro que los proyectos reales sigan un flujo secuencial propuesto por
dicho modelo, aunque el modelo lineal acepta repeticiones, lo hace de
forma indirecta.
Es difcil para el cliente enunciar en forma explcita todos los
requerimientos. El modelo de la cascada necesita que se haga, pero tiene
dificultades para aceptar la incertidumbre.
El cliente debe tener paciencia. No se dispondr de una versin funcional de
los programas hasta que el proyecto est muy avanzado.
En un anlisis de proyectos reales se encontr que a naturaleza lineal del
ciclo de vida clsico llega a estados de bloqueo en los que ciertos miembros
del equipo de proyecto deben esperar a otros a fin de terminar tareas
interdependientes. Hoy en da el trabajo de software es acelerado y est
sujeto a un corriente sin fin de cambios. El modelo de cascada suele ser
inapropiado para ese tipo de labor.

Modelo de Proceso incremental

Nace como una cierta necesidad de dar rpidamente cierta funcionalidad
limitada de software a los usuarios y aumentarla con las entregas

posteriores de software. En tales casos, se elige un modelo de proceso

diseado para producir el software en incrementos.
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.
Cuando se utiliza el modelo incremental es frecuente que el primer producto
sea el producto fundamental. Es decir, se abordan los requerimientos
bsicos. El cliente usa el producto fundamental, como resultado del uso y/o
evaluacin se desarrolla un plan para el requerimiento que sigue.
El modelo del proceso incremental se centra en que 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 tambin le dan una plataforma de evaluacin.
Por lo tanto es til en particular cuando no se dispone de personal para la
implementacin completa del proyecto en el plazo establecido por el
negocio. Los primeros incrementos se desarrollan con pocos trabajadores. Si
el producto bsico es bien recibido, entonces se agrega ms personal (si se
requiere) para que elabore el siguiente incremento.

Modelo de Proceso Evolutivo

Se da en las situaciones en las que se necesita un modelo de proceso
diseado explcitamente para adaptarse a un producto que evoluciona con
el tiempo.
Los modelos evolutivos son iterativos y se caracterizan por la manera en la
que permiten desarrollar versiones ms completas. Se presentan dos
modelos comunes de proceso evolutivo:

Hacer prototipos: El hacer prototipos nos ayuda a mejorar la

comprensin de lo que hay que elaborar cuando los requerimientos
no estn claros. Comienza con la comunicacin por medio de la
reunin con los otros participantes para definir los objetivos generales
del software. Luego, se planea rpidamente una iteracin para hacer
el prototipo y se lleva a cabo el modelado o diseo rpido que leva a
la construccin de un prototipo. Este se entrega y es evaluado por los
participantes, que dan retroalimentacin para mejorar los
requerimientos.
Hacer prototipos puede llegar a ser problemtico debido a que los
participantes ven lo que parece ser una versin funcional del
software, sin darse cuenta de que el prototipo se obtuvo de manera
caprichosa ;no perciben en la prisa por hacer que funcionara, no se
consider la calidad general del software por ejemplo.

En conclusin la clave es definir desde el principio las reglas del

juego; es decir, todos los participantes deben de estar de acuerdo en
que el prototipo sirva como el mecanismo para definir los
requerimientos. Despus se la descartara para pasar a la ingeniera
del software real con la mirada puesta en la calidad

Modelo espiral: Aqu el software se entrega 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 ms completas del
sistema cuya ingeniera se est haciendo. Un modelo en espiral es
dividido por el equipo de software en un conjunto de actividades
estructurales.
El primer circuito alrededor de la espiral da como resultado el
desarrollo de una especificacin del producto; las vueltas sucesivas
se usan para desarrollar un prototipo y, luego versiones cada vez ms
sofisticadas del 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 cmputo.

Modelos concurrentes
Permite que un equipo de software represente elementos iterativos y
concurrentes de cualquiera de los modelos de proceso expuestos. Todas las
actividades de ingeniera de software existen de manera concurrente, pero
se hallan en diferentes estados.
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 ingeniera de software.
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 actividades, acciones y tareas de la ingeniera
de software a una secuencia de eventos, define una red del proceso. Los
eventos generados en cierto punto de la red del proceso desencadenan
transiciones entre los estados.

Una ltima palabra acerca evolutivos de los procesos

Los procesos evolutivos fueron concebidos para cumplir y solucionar

softwares que se caracterizan por su constante cambio, por tiempos de
entrega muy apretados y por una necesidad de calidad apremiante por
parte del cliente, pero aun as segn Nogueira tiene las siguientes
debilidades:

Hacer prototipos plantea un problema para la planeacin del proyecto

ya que la mayor parte de tcnicas de administracin y estimacin de
proyectos se basa en un planteamiento lineal de las actividades por lo
que hacer prototipos no se ajusta por completo.
Los procesos evolutivos no establecen la velocidad mxima de la
evolucin ya que pueden carecer de un periodo de relajamiento o
perjudicar
la
productividad
segn
vaya
rpido
o
lento
respectivamente.
Deben centrarse en la flexibilidad y capacidad d extensin en lugar
de en la alta calidad ya que extender el desarrollo a fin de lograr alta
calidad podra dar como resultado la entrega de tarda del producto.

En conclusin el objetivo de los modelos evolutivos es desarrollar software

de calidad en forma iterativa e incremental, sin embargo es posible hacer
nfasis en la flexibilidad y velocidad de desarrollo. El reto es equilibrar estos
parmetros del proyecto y producto