LECTURA SEMANAL  

LECTURA UNO: PROCESOS DE INGENIERÍA DE SOFTWARE. HISTORIA Y

PRINCIPALES PROPUESTAS

¿QUÉ ES UN PROCESO DE SOFTWARE?

De manera breve, se puede definir un proceso de software como el conjunto de actividades

organizadas que permiten completar el desarrollo de un producto de software. Naturalmente,
esta es una definición que abarca una gran cantidad de implementaciones posibles y esto
es apenas natural. A pesar de que contar con una aproximación organizada tiene una
extrema importancia para el correcto desarrollo de un proyecto de software, no existe una
única forma para abordar dicha aproximación. Algunos proyectos se verán beneficiados al
contar con una aproximación altamente estructurada, mientras que en otros será ventajoso
poder flexibilizar algunos procesos y estructuras para poder dar cabida a los cambios de una
manera más simple. La complejidad misma del proceso escogido dependerá de la
complejidad del proyecto y el producto que se espera desarrollar. Lo que resulta necesario
tener claro desde el principio, es que para poder llevar adelante un proyecto de software de
cierta importancia y que redunde en un producto que satisfaga las expectativas del cliente
manteniéndose dentro de los requerimientos de tiempo, presupuesto y calidad esperados, es
necesario enmarcar dicho proyecto en un proceso organizado de software.

Ahora, si bien se ha mencionado que existen diversas maneras de implementar de manera

particular un esquema de modelo de software, la mayor parte de dichas implementaciones o
modelos particulares coinciden en sus componentes generales. De esta manera, es posible
caracterizar los elementos genéricos que componen un proceso de software de la siguiente
forma:

En alianza con

 
Colombia
 Figura 1. Componentes generales de un proceso de Software.

Planificación

Gestión de
DEFINICIÓN Requerimientos

Análisis

PROCESO DESARROLLO Diseño

Codificación

Prueba

MANTENIMIENTO (Diferentes Tipos)

Fuente: ELABORACIÓN PROPIA JULIÁN RODRIGUEZ- CREATIVE CENTER, POLITÉCNICO

GRANCOILOMBIANO

De acuerdo con lo representado en la figura, un proceso de software consta, de manera

general, de tres grandes momentos, cada uno de los cuales a su vez puede subdividirse en
varios componentes. Cabe anotar que la división aquí presentada se hace con el propósito
de demostrar que de manera general los procesos de software comparten elementos y no
coincide estrictamente con ningún modelo. Descritas de manera más detallada, las partes
propuestas son:

1. Definición: en esta parte de un proceso de software se busca entender de manera

completa el problema a solucionar, las condiciones generales dentro de las que es necesario
trabajar, para con base en estos elementos poder determinar un esquema de organización
de recursos y tiempo que ofrezca soporte al desarrollo de la solución requerida. De una
manera resumida, la pregunta que se busca responder en esta fase es ¿Qué? ¿Qué debe
hacer el software? Los componentes que pueden ubicarse en esta parte son:
• Planificación. Aquí se definen las restricciones de tiempo, presupuesto, personal y en general,
cualquier elemento que implique un impacto en la planeación del desarrollo del proyecto
debe ser tenido en cuenta. Resultado de este componente es una visión clara del mapa de
ruta del proyecto.
• Gestión de requerimientos. La gestión de requerimientos contempla los procesos y métodos
necesarios para identificar, organizar y documentar las necesidades del cliente respecto al
producto de software que resultará del proceso en cuestión.
• Análisis. Aquí la idea es tomar la comprensión que se tiene del problema y decantarla en una
serie de artefactos documentales que ofrezcan una visión más ordenada y técnica del
problema y el punto de partida para encontrar la solución adecuada al mismo.
En alianza con

 
Colombia
2. Desarrollo. En la segunda fase general común a los procesos de software, es necesario
responder a la pregunta “¿Cómo?”. ¿Cómo dará el software respuesta a las necesidades del
cliente? ¿Cómo satisfará los requerimientos expresados, documentados y analizados en la
fase previa? ¿Cuál es la estructura interna más adecuada para cumplir con las necesidades
presentes? La respuesta a estas preguntas da paso a la posibilidad de escribir código que
responda de manera real a las necesidades encontradas, a la vez que cumple con los
requisitos de calidad y robustez esperados. Los componentes generales de esta fase son:
● Diseño. Aquí, con base en los documentos generados durante la fase de análisis, es posible
determinar una estructura interna eficiente, eficaz, robusta y en general, adecuada para
solucionar el problema identificado. El resultado de esta fase es un conjunto de documentos
que describen esta estructura y le permiten a los desarrolladores comenzar la escritura del
código con la certeza de que están basados en una estructura sólida y adecuada al
problema.
● Codificación. En esta parte del proceso se escribe de manera efectiva el código que, al
ser ejecutado, ofrecerá la solución esperada al problema identificado y analizado con
anterioridad. Es en este punto cuando realmente se genera el software en su acepción más
técnica. Nótese que para poder llegar con confianza a este punto, es necesario haber
completado los procesos anteriores de una manera cabal. Sin embargo, haber realizado de
manera adecuada el tránsito por los componentes previos, a pesar de consumir tiempo, es
una garantía de que se minimizan las probabilidades de cometer errores durante la
codificación, que pueden ser mucho más costosos después.
● Prueba. Este componente, que a veces se incorpora de manera estrecha con el anterior,
resulta de importancia obvia. La correcta ejecución del código, así como la correcta
traducción de los requerimientos identificados a una aplicación completamente funcional
dependen en gran medida de la supervisión que se dé a los resultados de la codificación.
Los esquemas de pruebas son muchos y variados. Sin embargo, resulta evidente su extrema
importancia.

3. Mantenimiento. Hoy en día, resulta claro para la mayor parte de los desarrolladores de
software, que el ciclo de vida de un producto no termina en la entrega. Uno de los factores
de éxito de un producto y por tanto de la compañía que lo genera, es la capacidad de
adaptarse al cambio constante que resulta apenas natural en los ambientes de producción
actuales. El rapidísimo ritmo de cambio presente en la mayor parte de los escenarios de
acción del software hacen que sea imperativo contar con estrategias y mecanismos para
garantizar la adaptabilidad de los productos entregados. Cambios requeridos por
necesidades variables de los clientes, del ambiente, o como prevención de futuras
necesidades son normales en el ámbito del desarrollo de software. En esta fase se lidia con
estos requerimientos.
El ámbito que cubre este módulo tiene que ver con los aspectos de análisis y diseño de un
producto de software. Los aspectos iniciales de planeación, así como las pruebas y gestión
del cambio serán contemplados, entre otros elementos, en módulos posteriores, en tanto que
los aspectos relacionados con la codificación fueron abordados en módulos previos a éste.
Con una visión general de los componentes comunes de todo proceso de software, es
posible abordar con algo más de detalle las aproximaciones más específicas a dichos
procesos. No se pretende aquí describir de manera detallada y definitiva los diferentes
procesos existentes. Se busca más bien definir cuáles son las abstracciones más comúnmente
utilizadas para describir los diferentes enfoques que se utilizan cuando se enfrenta un

En alianza con

 
Colombia
proyecto de desarrollo. Con esto dicho, existen algunos modelos de proceso que
tradicionalmente han sido utilizados en la industria del software. Dichos modelos son:

1. MODELO EN CASCADA
El modelo en cascada fue el primer modelo formal de desarrollo de software en hacerse
público y en ser utilizado de manera generalizada. Es por definición el modelo más simple, y
contempla un conjunto de etapas encadenadas de la manera como se muestra en la figura.
Dichas etapas son:
1. Análisis y definición de requerimientos. La idea en esta etapa es obtener un modelo del
sistema a implementar con base en las necesidades del usuario. De esta manera se definen
los objetivos a cumplir y las restricciones a tener en cuenta.
2. Diseño del sistema y del software. Se pretende en esta fase y a partir de las necesidades
identificadas de manera previa, definir la arquitectura y la estructura general interna del
sistema a implementar.
3. Implementación y prueba de unidades. Aquí se lleva a cabo la codificación de las
unidades de código que reflejen el diseño definido con anterioridad. Cada una de ellas es
probada para garantizar que cumple con los requerimientos adecuados.
4. Integración y prueba del sistema. Una vez implementadas y probadas las unidades
particulares, éstas son integradas en el sistema final y el mismo es probado como un todo,
para garantizar que el funcionamiento total es el esperado.
5. Funcionamiento y mantenimiento. Es aquí donde el sistema es puesto en marcha en su
ambiente final y cualquier cambio que sea necesario realizar es implementado. Estos cambios
pueden surgir de errores no detectados previamente, o de requerimientos que no habían sido
identificados con anterioridad.

Figura 2. Modelo en Cascada

Fuente: ELABORACIÓN PROPIA JULIÁN RODRIGUEZ- CREATIVE CENTER, POLITÉCNICO

GRANCOILOMBIANO

En principio, en un modelo en cascada, cada fase debe esperar a que la anterior termine
para poder comenzar, aunque en términos prácticos esto no sucede. Lo que usualmente
pasa es que se hacen varias iteraciones de cada una de las fases, hasta que llega un punto
en el que resulta necesario detener este proceso para poder pasar a la siguiente fase.
En alianza con

 
Colombia
Debido a la compartimentalización del trabajo en fases separadas, esta detención implica
en ocasiones que se queden requerimientos sin identificar o problemas de diseño o
implementación sin corregir y que solamente serán detectados en la fase final, al poner en
marcha el sistema como un todo. Esta condición hace que esa fase final sea usualmente la
más compleja y la más larga de un proceso que sigue este modelo. En general, se
recomienda utilizar el modelo en cascada para proyectos en los que los requerimientos sean
claramente conocidos y se espere que no cambien demasiado a lo largo del proyecto.

2. MODELO DE DESARROLLO EVOLUTIVO

Bajo el esquema de desarrollo evolutivo, la idea no es desarrollar una aplicación de software

de manera monolítica y estructurada como se haría utilizando un modelo en cascada, sino
que se pretende aproximarse a la solución definitiva a través de un proceso iterativo en el
cual se van encontrando soluciones parciales cada vez más cercanas al producto final.

Figura 3.Modelo de desarrollo evolutivo

Fuente: ELABORACIÓN PROPIA JULIÁN RODRIGUEZ- CREATIVE CENTER, POLITÉCNICO

GRANCOILOMBIANO

Como se aprecia en el diagrama, existe un conjunto de actividades (Especificación,

desarrollo y validación) que se llevan a cabo de manera simultánea, pretendiendo con ello
mantener una constante retroalimentación del proceso que permita encontrar de manera
rápida los cambios que sea necesario hacer con base en las recomendaciones y
observaciones del cliente sobre un prototipo presentado. Las tres actividades se
complementan de manera muy estrecha a través de dos momentos que resultan claves en el
proceso: En primer lugar existe un momento de trabajo directo con el cliente, orientado a
encontrar sus necesidades e intereses y en segundo lugar existe un proceso de generación
de prototipos que implementan lo hallado, de tal manera que el cliente pueda examinar una
implementación y ofrecer su opinión. De la misma manera, la existencia de un prototipo
colabora con la comprensión que el cliente tiene del problema y a medida que esta
aumenta, es posible incorporar la información obtenida en el siguiente prototipo.

En alianza con

 
Colombia
El modelo evolutivo es recomendable por encima del modelo en cascada para proyectos
de software no muy grandes. Uno de los inconvenientes que tiene es que la necesidad de
incorporar cambios a prototipos ya desarrollados hace que la arquitectura y el diseño
interno de la aplicación necesiten cambiar sustancialmente y este no es un proceso que sea
sencillo en aplicaciones relativamente complejas. A medida que crece la complejidad del
software aumenta la dificultad para incorporar modificaciones, lo que al final puede generar
un producto inestable o con un diseño poco adecuado.
No obstante lo mencionado en el párrafo anterior, el modelo evolutivo presenta grandes
ventajas cuando se utiliza en el marco de un proyecto para el que no se tienen claros por
completo los requerimientos (Esto puede ser cierto incluso para el cliente, quien en ocasiones
tiene dudas acerca del conjunto final de requerimientos para el software). Aquí, un enfoque
evolutivo permite la detección y refinamiento de dichos requerimientos por medio de la
utilización de prototipos, lo que puede resultar al final, en un ahorro de tiempo y esfuerzo, con
una claridad mayor.

3. MODELO BASADO EN COMPONENTES

Uno de los objetivos más importantes durante un proceso de desarrollo de software es
minimizar el esfuerzo y tiempo requeridos para cumplir con los requerimientos encontrados. Ya
que en la mayor parte de los casos buena parte de este esfuerzo y tiempo se centra en la
generación de código, resulta evidente que una mejora en ese sentido podría afectar de
manera favorable el desarrollo del proyecto. Los modelos basados en reutilización de
código son por tanto muy importantes y el modelo basado en componentes se destaca entre
ellos. La idea general del modelo es poder encontrar componentes, o partes de software
previamente desarrollados (por la compañía misma, o disponibles de manera comercial
habiendo sido desarrollados por terceros), que satisfagan requerimientos definidos para la
aplicación cuyo desarrollo está en curso, de tal manera que no sea necesario llevar a cabo
un desarrollo repetido consumiendo tiempo y recursos. Las etapas comunes un modelo
basado en componentes son:
1. Especificación de requerimientos. Esta etapa es similar a la llevada a cabo en otro tipo de
procesos. El objetivo sigue siendo la comprensión y documentación de las necesidades del
cliente y los requerimientos finales del software a implementar.
2. Análisis de componentes. Habiendo definido las necesidades y requerimientos para el
proyecto, en esta fase se verifica la existencia de componentes preexistentes que puedan ser
integrados a la solución en curso para satisfacer dichos requerimientos.
3. Modificación de componentes. En la mayor parte de los casos es difícil encontrar
componentes que satisfagan los requerimientos identificados de manera completa, sin que se
requieran modificaciones. Es por eso que en esta parte del proceso se llevan a cabo los
cambios necesarios para que los componentes a utilizar cumplan con las necesidades
identificadas. Puede suceder que dichas modificaciones no sean posibles, caso en el cual es
necesario retornar al paso anterior, para buscar otras alternativas de componentes a utilizar.
4. Diseño del sistema. Ya que el correcto funcionamiento del sistema depende de la sinergia
existente entre los componentes a reutilizar, es necesario definir aquí un diseño que satisfaga
las interacciones necesarias y cumpla a la vez con los requerimientos definidos para el
sistema.
5. Desarrollo e integración. Aquí se desarrollan las partes del software que no existen bajo la
forma de componentes propios o adquiridos, así como las partes necesarias para conectar
dichos componentes.

En alianza con

 
Colombia
6. Validación y pruebas. De manera similar a la presentada en los modelos anteriores, durante
la validación y pruebas se realizan los controles que determinan el correcto cumplimiento por
parte de la solución de los requerimientos definidos de manera inicial.
Figura 4. Modelo basado en componentes

Especificación   Análisis  de   Modificación   Diseño   Desarrollo   Validación  

de   component de   del   e   y  pruebas  
requerimientos   es   componentes   sistema   integración  

Fuente: ELABORACIÓN PROPIA JULIÁN RODRIGUEZ- CREATIVE CENTER, POLITÉCNICO

GRANCOILOMBIANO

Evidentemente, el enfoque basado en componentes ofrece ventajas en términos del tiempo y

trabajo que se pueden ahorrar a lo largo de un proceso de desarrollo. Sin embargo, existe un
factor importante a considerar alrededor de la pérdida de propiedad y control sobre las
partes de la solución cuando se utilizan componentes desarrollados por terceros que hacen
que muchas compañías prefieran hacer el desarrollo por completo.

4. MODELO INCREMENTAL

Este modelo presenta una aproximación intermedia entre los modelos en cascada y evolutivo,
que busca evitar los inconvenientes de cada uno (para el modelo en cascada es necesario
definir todos los requerimientos antes de poder comenzar el desarrollo y el modelo evolutivo,
a pesar de ser más flexible en ese sentido puede generar sistemas débiles y difíciles de
mantener).
Bajo el esquema incremental, se define en conjunto con el cliente, qué es lo que éste espera
del software en términos de requerimientos. Luego, dichos requerimientos son priorizados y
divididos en incrementos de tal manera que cada uno ofrezca funcionalidad creciente al
producto. Cuando este proceso de división ha sido terminado, cada uno de los incrementos
definidos puede ser desarrollado con un enfoque que puede ser el de un modelo en
cascada. Cada vez que se termina el desarrollo de un incremento, su funcionalidad es
agregada a la entrega anterior, aumentando la utilidad del producto.
Una de las mayores ventajas del modelo incremental es que el cliente puede poner en
funcionamiento el sistema sin tener que esperar demasiado. Al haber sido priorizados los
requerimientos, aquellos que son más importantes son entregados primero, lo que los somete a
pruebas durante más tiempo que los que no son tan importantes, lo cual es deseable para
garantizar la calidad del producto.
Una de las metodologías basada en el concepto de incrementos que es más popular hoy en
día es Programación Extrema o Extreme Programming. En la videoconferencia de esta semana
se hablará en detalle de esta metodología, comparándola con RUP (Rational Unified
Process), una metodología muy estructurada que es uno de sus principales rivales en el medio
del desarrollo de software.

5. MODELO EN ESPIRAL

El modelo en espiral surge de una propuesta hecha por Barry Boehm en un artículo publicado
en 1986. Como su nombre lo indica, está basado en el concepto de modelar el proceso de
En alianza con

 
Colombia
desarrollo de un producto de software no en un modelo lineal, sino en una estructura espiral
en la que cada ciclo modela una fase del proceso. Siguiendo esta línea de pensamiento, el
ciclo más interno de la espiral podría trabajar sobre la especificación de requerimientos para
el producto, mientras que el siguiente podría ocuparse del análisis y el siguiente del diseño,
luego de lo cual vendría un ciclo que se ocupe de la implementación, etc.
Cada uno de los ciclos definidos para la espiral se divide en cuatro cuadrantes, así:
Definición de objetivos. La idea aquí es determinar qué se pretende alcanzar en este ciclo
particular del proceso, así como identificar los riesgos que se presentan para alcanzar dichos
objetivos. Alrededor de estos riesgos se elaborarán planes de alternativas.
Evaluación y manejo de riesgos. Para cada uno de los riesgos identificados se crea un plan
de gestión con el fin de minimizarlo. Esto se logra mediante un análisis detallado del riesgo y
el planteamiento de alternativas de solución y manejo para el mismo.
Desarrollo y pruebas. Una vez se han identificado los riesgos y definido planes de acción
para su control se determina el modelo adecuado para la implementación del producto.
Dependiendo de los riesgos encontrados, podría optarse por un modelo en cascada, o uno
evolutivo, o basado en prototipos.
Planeación. Al finalizar cada ciclo de la espiral, se evalúa el avance del proyecto y los
riesgos aun existentes y se determina si es viable continuar al siguiente ciclo (Es necesario
recordar que cada ciclo se ocupa de intereses diferentes dentro de la evolución del
proyecto). De ser así, se elaboran los planes para dicho ciclo.

Figura 5.Modelo en espiral de Boehm

Fuente: ELABORACIÓN PROPIA JULIÁN RODRIGUEZ- CREATIVE CENTER, POLITÉCNICO

GRANCOILOMBIANO

El proceso de evolución de un proyecto de software bajo el modelo en espiral es muy

intuitivo entonces: se basa en la identificación de los objetivos a alcanzar en el ciclo presente
(tener los requerimientos claros, tener un diseño completo, implementar una versión de la
aplicación), con base en los cuales se encuentran los riesgos correspondientes (mala
En alianza con

 
Colombia
comunicación con el cliente, complejidad de la aplicación, dificultades con el lenguaje),
determinándose luego las acciones a tener en cuenta para la mitigación de dichos riesgos
(planificación de reuniones periódicas, reevaluación de la arquitectura, capacitación del
personal), para culminar con la mitigación de los riesgos mediante la aplicación de los planes
definidos, seguida por la planeación del siguiente ciclo, en caso de que se considere viable
hacerlo así.

En alianza con

 
Colombia