PARADIGMAS DEL PROCESO DE SOFTWARE.

1.3. La evolución de los paradigmas del proceso de software.

La metodología del proceso de software surgió hasta después de 1960. El ciclo de
vida de desarrollo de sistemas (SDLC) es considerado como la primera metodología
formalizada para construir sistemas de información. La principal idea del SDLC era
"lograr el desarrollo de sistemas de información en una forma deliberada,
estructurada y metodológica, requiriendo que cada estado del ciclo de vida (desde
la concepción de la idea hasta la entrega del sistema final) sea realizado rígida y
secuencialmente dentro del contexto del marco aplicado. El principal objetivo de
esta metodología era desarrollar sistemas de negocios funcionales y a gran escala
en una era de negocios conglomerados a gran escala. (Geoffrey, 2004).

1.3.1. El proceso de software.

Un proceso de software es un conjunto de actividades que conducen a la creación
de un producto de software. Estas actividades pueden consistir en el desarrollo de
software desde cero en un lenguaje de programación estándar como Java o C. Sin
embargo, cada vez más se desarrolla nuevo software ampliando y modificando los
sistemas existentes y configurando e integrando software comercial o componentes
del sistema.
Los procesos de software son complejos y, como todos los procesos intelectuales y
creativos, dependen de las personas que toman decisiones y juicios. Debido a la
necesidad de juzgar y crear, los intentos para automatizar estos procesos han tenido
un éxito limitado. Las herramientas de ingeniería del software asistida por
computadora (CASE) pueden ayudar a algunas actividades del proceso. Sin
embargo, no existe posibilidad alguna, al menos en los próximos años, de una
automatización mayor en el diseño creativo del software realizado por los ingenieros
relacionados con el proceso del software.
Aunque existen muchos procesos diferentes de software, algunas actividades
fundamentales son comunes para todos ellos:
1. Especificación del software. Se debe definir la funcionalidad del software y
las restricciones en su operación.
2. Diseño e implementación del software. Se debe producir software que
cumpla su especificación.
3. Validación del software. Se debe validar el software para asegurar que hace
lo que el cliente desea.
4. Evolución del software. El software debe evolucionar para cubrir las
necesidades cambiantes del cliente. (Sommerville, 2005, p. 60).

1.3.2. El modelo en cascada.

El primer modelo de proceso de desarrollo de software que se publicó se derivó de
procesos de ingeniería de sistemas generales. La primera descripción formal del
modelo en cascada es frecuentemente adjudicado al artículo de (Royce, 1970).
Aunque Royce no uso el término “cascada” en el artículo, presentó este modelo
como un ejemplo de un modelo defectuoso.
Las principales etapas de este modelo se transforman en actividades
fundamentales de desarrollo:
1. Análisis y definición de requerimientos. Los servicios, restricciones y metas
del sistema se definen a partir de las consultas con los usuarios. Entonces,
se definen en detalle y sirven como una especificación del sistema.
2. Diseño del sistema y del software. El proceso de diseño del sistema divide
los requerimientos en sistemas de hardware o software. Establece una
arquitectura completa del sistema. El diseño del software identifica y describe
las abstracciones fundamentales del sistema de software y sus relaciones.
3. Implementación y prueba de unidades. Durante esta etapa, el diseño del
software se lleva a cabo como un conjunto o unidades de programas. La
prueba de unidades implica verificar que cada una cumpla su especificación.
4. Integración y prueba del sistema. Los programas o las unidades individuales
de programas se integran y prueban como un sistema completo para
asegurar que se cumplan los requerimientos del software. Después de las
pruebas, el sistema de software se entrega al cliente.
5. Funcionamiento y mantenimiento. Por lo general (aunque no
necesariamente), está es la fase más larga del ciclo de vida. El sistema se
instala y se pone en funcionamiento práctico. El mantenimiento implica
corregir errores no descubiertos en las etapas anteriores del ciclo de vida,
mejorar la implementación de las unidades del sistema y resaltar los servicios
del sistema una vez que se descubren nuevos requerimientos.

Figura 1. Modelo en cascada.

En (Pressman, 2010) se definen las cinco actividades del proceso de software de la
siguiente manera:
 Comunicación. Antes de que comience cualquier trabajo técnico, tiene
importancia crítica 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
características y funciones del software.
 Planeación. Cualquier viaje complicado se simplifica si existe un mapa. Un
proyecto de software es un viaje difícil, y la actividad de planeación crea un
“mapa” que guía al equipo mientras viaja. El mapa —llamado plan del
proyecto de software— define el trabajo de ingeniería de software al describir
las tareas técnicas por realizar, los riesgos probables, los recursos que se
requieren, los productos del trabajo que se obtendrán y una programación de
las actividades.
 Modelado. Ya sea usted diseñador de paisaje, constructor de puentes,
ingeniero aeronáutico, carpintero o arquitecto, a diario trabaja con modelos.
Crea un “bosquejo” del objeto por hacer a fin de entender el panorama
general —cómo se verá arquitectónicamente, cómo ajustan entre sí las
partes constituyentes y muchas características más—. Si se requiere, refina
el bosquejo con más y más detalles en un esfuerzo por comprender mejor el
problema y cómo resolverlo. Un ingeniero de software hace lo mismo al crear
modelos a fin de entender mejor los requerimientos del software y el diseño
que los satisfará.
 Construcción. Esta actividad combina la generación de código (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 evalúa y que le da
retroalimentación, misma que se basa en dicha evaluación.

En principio, el resultado de cada fase es uno o más documentos aprobados. La

siguiente fase no debe empezar hasta que la fase previa haya finalizado. En la
práctica, estas etapas se superponen y proporcionan información a las otras.
Durante el diseño del código se encuentran problemas, y así sucesivamente. El
proceso de software no es un modelo lineal simple, sino que implica una serie de
iteraciones de las actividades de desarrollo.

1.3.3. Desarrollo evolutivo.

El desarrollo evolutivo se basa en la idea de desarrollar una implementación inicial,
exponiéndola a los comentarios del usuario y refinándola a través de las diferentes
versiones hasta que se desarrolla un sistema adecuado (Figura 3). Las actividades
de especificación, desarrollo y validación se entrelazan en vez de separarse, con
una rápida retroalimentación entre estas.
 Figura 2. El modelo en V.

Existen dos tipos de desarrollo evolutivo:

1. Desarrollo exploratorio, donde el objetivo del proceso es trabajar con el
cliente para explorar sus requerimientos y entregar un sistema final. El
desarrollo empieza con las partes del sistema que se comprenden mejor. El
sistema evoluciona agregando nuevos atributos propuestos por el cliente.
2. Prototipos desechables, donde el objetivo del proceso de desarrollo
evolutivo es comprender los requerimientos del cliente y entonces desarrollar
una definición mejorada de los requerimientos del cliente que no se
comprenden del todo.

Figura 3. Desarrollo evolutivo.

En la producción de sistemas, un enfoque evolutivo para el desarrollo de software

suele ser más efectivo que el enfoque en cascada, ya que satisface las necesidades
inmediatas de los clientes. La ventaja de un proceso del software que se basa en
un enfoque evolutivo es que la especificación se puede desarrollar de forma
creciente. Tan pronto como los usuarios desarrollen un mejor entendimiento de su
problema, este se puede reflejar en el sistema de software. Sin embargo, desde una
perspectiva de ingeniería y de gestión, el enfoque evolutivo tiene dos problemas:
1. El proceso no es visible. Los administradores tienen que hacer entregas
regulares para medir el progreso. Si los sistemas se desarrollan rápidamente,
no es rentable producir documentos que reflejen cada versión del sistema.
2. A menudo los sistemas tienen una estructura deficiente. Los cambios
continuos tienden a corromper la estructura del software. Incorporar cambios
en él, se convierte cada vez más en una tarea difícil y costosa.

Para sistemas pequeños y de tamaño medio (hasta 500,000 líneas de código), el

enfoque evolutivo de desarrollo es el mejor. Los problemas del desarrollo evolutivo
se hacen particularmente agudos para sistemas grandes y complejos con un
periodo de vida largo, donde diferentes equipos desarrollan distintas partes del
sistema. Es difícil integrar las contribuciones de los equipos.
Para sistemas grandes, se recomienda un proceso mixto que incorpore las mejores
características del modelo en cascada y del desarrollo evolutivo. Esto puede
implicar desarrollar un prototipo desechable utilizando un enfoque evolutivo para
resolver incertidumbres en la especificación del sistema. Puede entonces
reimplementarse utilizando un enfoque más estructurado. Las partes del sistema
bien comprendidas se pueden especificar y desarrollar utilizando un proceso
basado en el modelo en cascada. Las otras partes del sistema, como la interfaz de
usuario, que son difíciles de específicas por adelantado, se deben desarrollar
siempre utilizando un enfoque de programación exploratoria. (Sommerville, 2005,
pp. 63-64).

1.3.4. Ingeniería del software basada en componentes.

En la mayoría de los proyectos de software existe algo de reutilización de software.
Por lo general, esto sucede informalmente cuando las personas que trabajan en el
proyecto conocen diseños o código similares al requerido. Los buscan, los modifican
según lo creen necesario y los incorporan en el sistema.
Esta reutilización informal es independiente del proceso de desarrollo que se utilice.
Sin embargo, en los últimos años, ha surgido un enfoque de desarrollo de software
denominado ingeniería del software basada en componentes (CBSE) que se basa
en la reutilización, el cual se está utilizando de forma amplia.
Este enfoque basado en la reutilización se compone de una gran base de
componentes de software reutilizables y de algunos marcos de trabajo de
integración para estos. Algunas veces estos componentes son sistemas de sí
mismos (COTS o sistemas comerciales) que se pueden utilizar para proporcionar
una funcionalidad específica, como dar formato al texto o efectuar cálculos
numéricos. En la Figura 4, se muestra el modelo del proceso genérico para la CBSE.
 Figura 4. Ingeniería de Software Basada en Componentes.

Aunque la etapa de especificación de requerimientos y la de validación son

comparables con otros procesos, las etapas intermedias en el proceso orientado a
la reutilización son diferentes. Estas etapas son:
1. Análisis de componentes. Dada la especificación de requerimientos, se
buscan los componentes para implementar esta especificación. Por lo
general, no existe una concordancia exacta y los componentes que se utilizan
solo proporcionan parte de la funcionalidad requerida.
2. Modificación de requerimientos. En esta etapa, los requerimientos se
analizan utilizando información acerca de los componentes que se han
descubierto. Entonces, estos componentes se modifican para reflejar los
componentes disponibles. Si las modificaciones no son posibles, la actividad
de análisis de componentes se puede llevar a cabo nuevamente para buscar
soluciones alternativas.
3. Diseño del sistema con reutilización. En esta fase se diseña o se reutiliza un
marco de trabajo para el sistema. Los diseñadores tienen en cuenta los
componentes que se reutilizan y organizan el marco de trabajo para que los
satisfaga. Si los componentes reutilizables no están disponibles, se puede
tener que diseñar nuevo software.
4. Desarrollo e integración. Para crear el sistema, el software que no se puede
adquirir externamente se desarrolla, y los componentes y los sistemas COTS
se integran. En este modelo, la integración de sistemas es parte del proceso
de desarrollo, más que una actividad separada.
La ingeniería del software basada en componentes tiene la ventaja obvia de reducir
la cantidad de software a desarrollarse y así reduce los costos y los riesgos. Por lo
general, también permite una entrega más rápida del software. Sin embargo, los
compromisos en los requerimientos son inevitables, y esto puede dar lugar a un
sistema que no cumpla las necesidades reales de los usuarios. Más aún: si las
nuevas versiones de los componentes reutilizables no están bajo el control de la
organización que los utiliza, se pierde parte del control sobre la evolución del
sistema.
La CBSE tiene mucho en común con un enfoque que está surgiendo para el
desarrollo de sistemas que se basa en la integración de servicios web de una serie
de proveedores. (Sommerville, 2005, pp. 64-66).
1.3.5. El modelo 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.
En relación con la Figura 5, 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 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.

Figura 5. El modelo incremental.

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. (Pressman, 2010, pp. 35-36).

1.3.6. El modelo espiral.

Propuesto en primer lugar por (Boehm, 1986), 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. Tiene
el potencial para hacer un desarrollo rápido de versiones cada vez más completas.
Boehm describe el modelo del modo siguiente:
“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 Figura 6. 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.

Figura 6. Modelo de espiral común.

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últiples 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. (Pressman, 2010, pp. 39-40).

Modelo de Prototipos

El modelo de prototipos busca definir los objetivos globales del sistema para luego
refinar en conjunto con el cliente los requisitos específicos. En la primera etapa se
crea un prototipo rápido y luego se itera sobre él en base a la retroalimentación
obtenida desde el cliente.

FIGURA 4.3 Modelo de prototipo

Esta modelo es extremadamente útil cuando el cliente no tiene claridad con

respecto a lo que necesita, y ayuda al equipo de desarrolladores a reducir los
riesgos de cambios en las etapas más avanzadas del proceso de desarrollo. Sin
embargo, dependiendo del cliente, este puede no desear involucrarse en el
proceso de desarrollo, lo que también implica un riesgo.
 Bibliografía

Boehm, B. (1 de Agosto de 1986). A Spiral Model of Software Development and Enhancement. (P. G.
Neumann, Ed.) ACM SIGSOFT Software Engineering Notes, 11(4), 14-24.
Geoffrey, E. (2004). Global Business Information Technology: an integrated systems approach. Pearson
Education.
Pressman, R. S. (2010). Ingeniería del software: Un enfoque práctico (Séptima ed.). (V. Campos, & J.
Enríquez, Trads.) Ciudad de México, México: McGRAW-HILL INTERAMERICANA EDITORES, S.A. DE
C.V.
Royce, W. (1970). Managing the Development of Large Software Systems. (I. WESCON, Ed.) Proceedings,
328-338.
Sommerville, I. (2005). Ingeniería del Software (Séptima ed.). (M. Alfonso, A. Botía, & J. Trigueros, Trads.)
Madrid, España: PEARSON EDUCACIÓN.