EL PROCESO DEL SOFTWARE

Un proceso es un conjunto de actividades, acciones y tareas que se ejecutan cuando va a crearse algn producto del
trabajo. Una actividad busca lograr un objetivo amplio (por ejemplo, comunicacin con los participantes) y se desarrolla
sin importar el dominio de la aplicacin, tamao del proyecto, complejidad del esfuerzo o grado de rigor con el que se
usar la ingeniera de software. Adems, la estructura del proceso incluye un conjunto de actividades sombrilla que son
aplicables a travs de todo el proceso del software. Una estructura de proceso general para la ingeniera de software
consta de cinco actividades:

Comunicacin: Antes de que comience cualquier trabajo tcnico, tiene importancia crtica comunicarse y colaborar con
el cliente (y con otros participantes). Se busca entender los objetivos de los participantes respecto del proyecto, y reunir
los requerimientos que ayuden a definir las caractersticas y funciones del software.

Planeacin: Cualquier viaje complicado se simplifica si existe un mapa. Un proyecto de software es un viaje difcil, y
la actividad de planeacin crea un mapa que gua al equipo mientras viaja. El mapa llamado plan del proyecto de
software define el trabajo de ingeniera de software al describir las tareas tcnicas por realizar, los riesgos probables, los
recursos que se requieren, los productos del trabajo que se obtendrn y una programacin de las actividades.

Modelado: Ya sea usted diseador de paisaje, constructor de puentes, ingeniero aeronutico, carpintero o arquitecto, a
diario trabaja con modelos. Crea un bosquejo del objeto por hacer a fin de entender el panorama general cmo se
ver arquitectnicamente, cmo ajustan entre s las partes constituyentes y muchas caractersticas ms. Si se requiere,
refina el bosquejo con ms y ms detalles en un esfuerzo por comprender mejor el problema y cmo resolverlo. Un
ingeniero de software hace lo mismo al crear modelos a fin de entender mejor los requerimientos del software y el
diseo que los satisfar.

Construccin: Esta actividad combina la generacin de cdigo (ya sea manual o automatizada) y las pruebas que se
requieren para descubrir errores en ste.

Despliegue: El software (como entidad completa o como un incremento parcialmente terminado) se entrega al
consumidor que lo evala y que le da retroalimentacin, misma que se basa en dicha evaluacin.

Estas cinco actividades estructurales genricas se usan durante el desarrollo de programas pequeos y sencillos, en la
creacin de aplicaciones web grandes y en la ingeniera de sistemas enormes y complejos basados en computadoras.

MODELO DE CASCADA

El modelo original planteaba que cada actividad deba completarse antes de poder continuar con la siguiente actividad.
Sin embargo, en una revisin posterior se extendi el modelo, permitiendo regresar a actividades anteriores. Algunas de
las creencias del modelo de cascada son que las metas se logran mejor cuando se tienen puntos de revisin bien
preestablecidos y documentados (dividiendo el desarrollo del software en actividades secuenciales bien definidas), los
documentos tcnicos son comprensibles para usuarios y administradores no tcnicos, cada detalle de los requisitos se
conoce de antemano antes de desarrollar el software (dichos detalles son estables durante el desarrollo) y las pruebas y
evaluaciones se realizan de manera eficiente al final del desarrollo.

El modelo de cascada fue inicialmente bien recibido, dado que las actividades de las etapas eran razonables y lgicas.
Lamentablemente, el modelo no explicaba cmo modificar un resultado, en especial considerando lo difcil que es
definir todos los requisitos de un sistema desde el inicio y que stos se mantengan estables y sin cambios durante el
desarrollo. Adems, la toma demasiado tarda tiempo en obtener resultados, retrasando la deteccin de errores hasta el
final. El modelo tambin hace difcil rastrear (en otras palabras, ver la dependencia entre los requisitos iniciales y el
cdigo final). Esta rigidez trajo dudas sobre la utilidad del modelo, resultando en que ste dejase de utilizarse de acuerdo
con su definicin original, llevando a los desarrolladores a utilizar variantes del modelo bsico, incluyendo el uso de
prototipos y la reutilizacin de software.
MODELO PROTOTIPO

Hacer prototipos. Es frecuente que un cliente defina un conjunto de objetivos generales para el software, pero que no
identifique los requerimientos detallados para las funciones y caractersticas. En otros casos, el desarrollador tal vez no
est seguro de la eficiencia de un algoritmo, de la adaptabilidad de un sistema operativo o de la forma que debe adoptar
la interaccin entre el humano y la mquina. En estas situaciones, y muchas otras, el paradigma de hacer prototipos tal
vez ofrezca el mejor enfoque. Aunque es posible hacer prototipos como un modelo de proceso aislado, es ms comn
usarlo como una tcnica que puede implementarse en el contexto de cualquiera de los modelos de proceso descritos en
este captulo. Sin importar la manera en la que se aplique, el paradigma de hacer prototipos le ayudar a usted y a otros
participantes a mejorar la comprensin de lo que hay que elaborar cuando los requerimientos no estn claros.

El paradigma de hacer prototipos comienza con comunicacin. Usted se rene 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 definicin. Se planea rpidamente una iteracin para hacer el prototipo, y se lleva a cabo el
modelado (en forma de un diseo rpido). ste se centra en la representacin de aquellos aspectos del software que
sern visibles para los usuarios finales (por ejemplo, disposicin de la interfaz humana o formatos de la pantalla de
salida). El diseo rpido lleva a la construccin de un prototipo. ste se entrega y es evaluado por los participantes, que
dan retroalimentacin para mejorar los requerimientos. La iteracin ocurre a medida de que el prototipo es afinado para
satisfacer las necesidades de distintos participantes, y al mismo tiempo le permite a usted entender mejor lo que se
necesita hacer. El ideal es que el prototipo sirva como mecanismo para identificar los requerimientos del software. Si va
a construirse un prototipo, pueden utilizarse fragmentos de programas existentes o aplicar herramientas (por ejemplo,
generadores de reportes y administradores de ventanas) que permitan generar rpidamente programas que funcionen.

En la mayora de proyectos es raro que el primer sistema elaborado sea utilizable. Tal vez sea muy lento, muy grande,
difcil de usar o todo a la vez. No hay ms alternativa que comenzar de nuevo, con ms inteligencia, y construir una
versin rediseada en la que se resuelvan los problemas.

El prototipo sirve como el primer sistema. Lo que Brooks recomienda es desecharlo. Pero esto quiz sea un punto de
vista idealizado. Aunque algunos prototipos se construyen para ser desechables, otros son evolutivos; es decir, poco a
poco se transforman en el sistema real. Tanto a los participantes como a los ingenieros de software les gusta el
paradigma de hacer prototipos. Los usuarios adquieren la sensacin del sistema real, y los desarrolladores logran
construir algo de inmediato. No obstante, hacer prototipos llega a ser problemtico por las siguientes razones:

1. 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 que en la prisa por hacer que funcionara, usted no
consider la calidad general del software o la facilidad de darle mantenimiento a largo plazo. Cuando se les
informa que el producto debe rehacerse a fin de obtener altos niveles de calidad, los participantes gritan que es
usted un tonto y piden unos cuantos arreglos para hacer del prototipo un producto funcional. Con demasiada
frecuencia, el gerente de desarrollo del software cede.

2. Como ingeniero de software, es frecuente que llegue a compromisos respecto de la implementacin a fin de
hacer que el prototipo funcione rpido. Quiz utilice un sistema operativo inapropiado, o un lenguaje de
programacin tan slo porque cuenta con l y lo conoce; tal vez implement un algoritmo ineficiente slo para
demostrar capacidad. Despus de un tiempo, quiz se sienta cmodo con esas elecciones y olvide todas las
razones por las que eran inadecuadas. La eleccin de algo menos que lo ideal ahora ha pasado a formar parte del
sistema.

Aunque puede haber problemas, hacer prototipos es un paradigma eficaz para la ingeniera de software. La clave
es definir desde el principio las reglas del juego; es decir, todos los participantes deben estar de acuerdo en que
el prototipo sirva como el mecanismo para definir los requerimientos. Despus se descartar (al menos en parte)
y se har la ingeniera del software real con la mirada puesta en la calidad.
MODELO ESPIRAL

El modelo espiral, desarrollado durante la dcada de los aos 80, es una extensin del modelo de cascada. A diferencia
del modelo de cascada, que es dirigido por documentos, el modelo espiral se basa en una estrategia para reducir el riesgo
del proyecto en reas de incertidumbre, como tener requerimientos iniciales incompletos e inestables. El modelo
enfatiza ciclos de trabajo, cada uno de los cuales estudia el riesgo antes de proceder al siguiente ciclo. Cada ciclo
comienza con la identificacin de los objetivos, soluciones alternas y restricciones asociadas con cada alternativa, y
finalmente se procede a su evaluacin. Cuando se encuentra que existe cierta incertidumbre, se utilizan diversas tcnicas
para reducir el riesgo de las distintas alternativas. Cada ciclo del modelo espiral termina con una revisin que discute los
logros actuales y los planes para el siguiente ciclo. Al igual que el modelo de prototipos, el modelo espiral incorpora una
estrategia de uso de prototipos como parte del manejo del riesgo.

Las creencias del modelo de espiral son que una actividad comienza cuando se entienden los objetivos y riesgos
involucrados, se usan las herramientas que mejor reduzcan los riesgos basndose en la evaluacin de soluciones
alternas, todo el personal relacionado debe involucrarse en una revisin que determine cada actividad (planeando y
comprometindose con las siguientes actividades) y el desarrollo se incrementa en cada etapa, permitiendo prototipos
sucesivos del producto. Con algunas variantes, ste es el modelo de proceso ms importante en la actualidad.

MODELOS CONCURRENTES

El modelo de desarrollo concurrente, en ocasiones llamado ingeniera concurrente, permite que un equipo de software
represente elementos iterativos y concurrentes de cualquiera de los modelos de proceso descritos en este captulo. Por
ejemplo, la actividad de modelado definida para el modelo espiral se logra por medio de invocar una o ms de las
siguientes acciones de software: hacer prototipos, anlisis y diseo. Una actividad de ingeniera 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
anloga otras actividades, acciones o tareas (por ejemplo, la actividad de comunicacin, termina su primera iteracin al
principio de un proyecto y existe en el estado de cambios en espera. La actividad de modelado (que exista en estado
inactivo mientras conclua la comunicacin inicial), ahora hace una transicin 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 ingeniera de software. Por ejemplo, durante las
primeras etapas del diseo (accin importante de la ingeniera de software que ocurre durante la actividad de modelado),
no se detecta una inconsistencia en el modelo de requerimientos. Esto genera el evento correccin del modelo de
anlisis, que disparar la accin de anlisis 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 ingeniera de software a una
secuencia de eventos, define una red del proceso. Cada actividad, accin o tarea de la red existe simultneamente con
otras actividades, acciones o tareas. Los eventos generados en cierto punto de la red del proceso desencadenan
transiciones entre los estados ejemplo, comunicacin o construccin). Todas las actividades de ingeniera de software
existen de manera concurrente, pero se hallan en diferentes estados.

PRINCIPIOS QUE GUAN TODA ACTIVIDAD ESTRUCTURAL

En muchos casos, los principios que se estudian para cada una de las actividades estructurales son un refinamiento de
los principios presentados. Tan slo son principios fundamentales planteados en un nivel ms bajo de abstraccin.

PRINCIPIOS DE COMUNICACIN

Antes de que los requerimientos del cliente se analicen, modelen o especifiquen, deben recabarse a travs de la
actividad de comunicacin. Un cliente tiene un problema que parece abordable mediante una solucin basada en
computadora. Usted responde a la solicitud de ayuda del cliente. Ha comenzado la comunicacin. Pero es frecuente que
el camino que lleva de la comunicacin a la comprensin est lleno de agujeros. La comunicacin efectiva (entre
colegas tcnicos, con el cliente y otros participantes, y con los gerentes de proyecto) se encuentra entre las actividades
ms difciles que deben enfrentarse. En este contexto, aqu se estudian principios de comunicacin aplicados a la
comunicacin con el cliente. Sin embargo, muchos de ellos se aplican por igual en todas las formas de comunicacin
que ocurren dentro de un proyecto de software.

PRINCIPIOS DE CONSTRUCCIN

La actividad de construccin incluye un conjunto de tareas de codificacin y pruebas que lleva a un software operativo
listo para entregarse al cliente o usuario final.

En el trabajo de ingeniera de software moderna, la codificacin puede ser:

1) La creacin directa de lenguaje de programacin en cdigo fuente (por ejemplo, Java),

2) La generacin automtica de cdigo fuente que usa una representacin intermedia parecida al diseo del
componente que se va a construir.
3) La generacin automtica de cdigo ejecutable que utiliza un lenguaje de programacin de cuarta generacin
(por ejemplo, Visual C++). Las pruebas dirigen su atencin inicial al componente, y con frecuencia se denomina
prueba unitaria.

Otros niveles de pruebas incluyen, de integracin (realizadas mientras el sistema est en construccin), de validacin,
que evalan si los requerimientos se han satisfecho para todo el sistema (o incremento de software) y de aceptacin, que
efecta el cliente en un esfuerzo por utilizar todas las caractersticas y funciones requeridas. Los siguientes principios y
conceptos son aplicables a la codificacin y prueba:

PRINCIPIOS DE DESPLIEGUE

La actividad del despliegue incluye tres acciones: entrega, apoyo y retroalimentacin. Como la naturaleza de los
modelos del proceso del software moderno es evolutiva o incremental, el despliegue ocurre no una vez sino varias, a
medida que el software avanza hacia su conclusin. Cada ciclo de entrega pone a disposicin de los clientes y usuarios
finales un incremento de software operativo que brinda funciones y caractersticas utilizables.

Cada ciclo de apoyo provee documentacin y ayuda humana para todas las funciones y caractersticas introducidas
durante los ciclos de despliegue realizados hasta ese momento. Cada ciclo de retroalimentacin da al equipo de software
una gua importante que da como resultado modificaciones de las funciones, de las caractersticas y del enfoque
adoptado para el siguiente incremento. La entrega de un incremento de software representa un punto de referencia
importante para cualquier proyecto de software.

CONCLUSIN

Debe hacerse ingeniera con el software en todas sus formas y a travs de todos sus dominios de aplicacin,
estableciendo el uso de los principios fundamentales de la ingeniera con objeto de desarrollar en forma econmica,
software que sea confiable y que trabaje con eficiencia en mquinas reales. Aun as, el enfoque sistemtico,
disciplinado y cuantificable aplicado por un equipo de software podra ser algo burdo para otro. Se necesita disciplina,
pero tambin adaptabilidad y agilidad.

Por otra parte las herramientas de la ingeniera de software proporcionan un apoyo automatizado o semiautomatizado
para el proceso y los mtodos. Cuando se integran las herramientas de modo que la informacin creada por una pueda
ser utilizada por otra, queda establecido un sistema llamado ingeniera de software asistido por computadora que apoya
el desarrollo de software.