Ingeniería de Software

Así, si vamos a hablar de metodologías de desarrollo de software, antes debemos hablar de

ingeniería del software, como parte fundamental de los conceptos que aquí abordaremos.

Ahora bien, aunque existen varias definiciones para entender el concepto de ingeniería del
software de acuerdo a cada autor, a continuación se cita la definición dada por Fritz Bauer,
seguido por Pressman (2005), en una conferencia fundamental sobre la materia:

“[La ingeniería del software es] el establecimiento y uso de principios sólidos de la ingeniería
para obtener económicamente un software confiable y que funcione de modo eficiente en
máquinas reales” p. 23
En este sentido, la ingeniería del software se puede ver como una disciplina que tiene en
cuenta elementos administrativos y tecnológicos –dado que es necesario administrar una
serie de recursos y porque hace uso de las TIC’s y las ciencias de la computación, que son
inherentes a la fabricación de software–, además de económicos, psicológicos, entre muchos
otros como parte integral de ésta.
Siendo consecuentes con lo mencionado y si se piensa en la ingeniería del software
enmarcada en un contexto de proyectos de software, es totalmente posible pensar que ésta
busca:

 Métodos completos para surtir todas las fases del desarrollo de un proyecto de
software.
 Mejores herramientas para la automatización de métodos.
 Bloques de construcción más potentes para la implementación de software.
 Mejores técnicas para la garantía de la calidad del software.
 Filosofía predominante para la construcción y gestión.

Modelos de desarrollo de software

Ahora, en consecuencia con lo indicado hasta ahora, si vamos a hablar de metodologías de
desarrollo de software, antes también debemos hablar de los modelos de desarrollo de
software, pues en sí mismos encontramos la base de las definiciones metodológicas que
existen (las metodologías de desarrollo de software se definen a partir de uno o varios
modelos de desarrollo de software).

Según Pressman (2005), una empresa perteneciente a la industria del software debería
describir un conjunto único de actividades para un marco de trabajo definido para los
procesos de software adoptados. Esto se podría definir cómo modelo de desarrollo, pues
cada empresa debe adaptar la definición de su modelo, a la naturaleza específica de cada
proyecto.
Siendo consecuentes con lo mencionado, se han definido a lo largo del proceso evolutivo de
la industria del software, una serie de modelos de desarrollo “genéricos” que algunas
organizaciones, eventualmente podrían adoptar, bien sea en su forma pura o con ciertas
modificaciones de acuerdo a sus necesidades. Sin embargo, es importante tener en cuenta
que sin importar el modelo seleccionado, la industria del software ha elegido un marco de
trabajo estándar que se define bajo el contexto de las actividades de comunicación,
planeación, modelado, construcción y desarrollo.

En este sentido, a continuación se plantean los principios y características más relevantes de

algunos modelos de desarrollo (hablaremos de cuatro modelos de desarrollo de software, lo
que no necesariamente significa que sean los únicos o lo más importantes, simplemente son
los que he seleccionado para poner sobre la mesa por su importancia, complejidad y aporte a
la ingeniería del software):

Modelo en cascada
Pressman (2005), define que el modelo en cascada –también llamado el ciclo de vida
clásico– sugiere un enfoque sistemático y secuencial hacia el desarrollo de software que
indica ciertas etapas y actividades. El modelo en cascada es el paradigma más antiguo para
la ingeniería del software, sin embargo en décadas pasadas, las críticas al mismo han
ocasionado que incluso sus más fieles seguidores hayan puesto en duda su eficiencia,
Pressman (2005), pues para trabajar con un modelo en cascada, es necesario tener en
cuenta algunos aspectos que de alguna forma se constituyen en sus desventajas; a
continuación se enlistan:
 El modelo propone un flujo de trabajo secuencial y pocas veces un proyecto se
ejecuta de esta forma, y aunque el modelo incluye interacciones, lo hace de forma
indirecta generando cambios que confunden mientras el proyecto sigue su ejecución.
 En ocasiones es complicado establecer todos los requerimientos de forma explícita, y
la metodología exige que éstos sean definidos en las etapas iniciales, pues de lo
contrario, los costos de reproceso sería demasiado alto en términos económicos y de
tiempo.
 El cliente debe ser paciente, pues los resultados no se evidencian rápidamente dado
que la ejecución de cada una de las etapas, generalmente toma demasiado tiempo, y
normalmente, lo clientes sienten bajo esta situación que están perdiendo tiempo y
dinero.

Modelos de proceso incrementales

Pressman (2005), define que:

“En muchas situaciones los requisitos iniciales del software están bien definidos en forma
razonable, pero el enfoque global del esfuerzo de desarrollo excluye un proceso puramente
lineal. Además, quizá haya una necesidad imperiosa de proporcionar de manera rápida un
conjunto limitado de funcionalidades para el usuario y después refinarla y expandirla en las
entregas posteriores del software. En estos casos se elige un modelo de proceso diseñado
para producir el software en forma incremental” p. 51
A continuación se definen las principales características de algunos modelos incrementales:

Modelo incremental
El modelo incremental toma el modelo en cascada y lo aplica de forma iterativa. Básicamente
se aplican secuencias lineales de forma escalonada de acuerdo al avance del proyecto,
donde cada secuencia genera incrementos del software, Pressman (2005).

Esta ejecución permite tener una variación en el número de personas involucradas en el

equipo de trabajo, pues en algunas etapas es posible que no sea necesario un número tan
alto, mientras que en otras sí.

Además, Pressman (2005) planeta que el modelo incremental al igual que el modelo de
prototipos y otros enfoques evolutivos, es iterativo por naturaleza, sin embargo el modelo
incremental se enfoca en la entrega de un producto operacional en cada incremento que
eventualmente se convierten en versiones parciales del software, lo que no necesariamente
ocurre con el modelo de prototipos, pues cada una de sus entregas, no necesariamente es
una versión funcional del software.

Modelo DRA
El modelo de Desarrollo Rápido de Aplicaciones (DRA), resalta un ciclo de desarrollo corto,
siendo en sí mismo una adaptación a alta velocidad del modelo en cascada, donde se logra
un rápido desarrollo a través de la construcción de un software basado en componentes,
Pressman (2005).
Con base en lo anterior, y teniendo en cuenta lo descrito por Pressman (2005), se evidencia
que se deben establecer ciertas restricciones en términos del alcance del proyecto y
tomando como base los requerimientos, lo que es necesario para cumplir con los tiempos
establecidos por el modelo.

Modelos de proceso evolutivos

Siguiendo a Pressman (2005), al igual que todos los sistemas complejos, el software,
evolucionan con el tiempo y los requerimientos del negocio a los cuales obedece dicho
software, cambian de acuerdo a las necesidades del mercado, por ello no existe un esquema
lineal que genere como resultado un producto de software.

Pressman (2005), indica:

“Los modelos evolutivos son iterativos; los caracteriza la forma en que permiten que los
ingenieros de software desarrollen versiones cada vez más completas del software” p. 55
A continuación se definen las principales características de algunos modelos incrementales:

Modelo de prototipos
Un modelo de prototipos puede ofrecer mejores resultados si en dentro de la ejecución del
proyecto no se tiene claridad sobre las necesidades del cliente o seguridad sobre un
desarrollo realizado, pues éste modelo es empleado como proceso independiente que toma
la forma de una técnica susceptible de implementarse dentro del contexto o como
complemento de cualquier otro modelo, Pressman (2005).

Así, el modelo permite sortear diferentes situaciones confusas en términos de definiciones,

por ejemplo, buscado poco a poco generar las definiciones necesarias y clarificar los
elementos que lo requieran. El modelo en prototipos describe una ejecución en ciclos donde
las actividades se repiten una y otra vez, pero resultados diferentes. Sin embargo es
necesario que el equipo de trabajo esté atento a no caer en ciclos infinitos y haciendo una y
otra vez lo mismo, o buscando la satisfacción del cliente.

Modelo en espiral
El modelo en espiral, es un modelo evolutivo que fusiona la naturaleza iterativa del modelo
de prototipos con los aspectos lineales, rígidos y de control del modelo en cascada,
entregando así bases para desarrollar rápidamente versiones incrementales del producto de
software, Pressman (2005).

En el modelo en espiral, seguramente en las primeras iteraciones, la producción se

enmarque en la documentación o prototipos no necesariamente funcionales, y sólo hasta las
últimas iteraciones la producción se enmarcará en versiones más robustas del producto de
software.

Con este modelo es posible hacer entregas parciales al cliente de forma rápida, sin embargo
en cualquier momento se puede salir de control por su naturaleza por su naturaleza
evolutiva, donde además, la cantidad de riesgos que pueden aparecer por el mismo
fenómeno, es alta y se requiere de mucha experticia por parte del equipo de trabajo, para
controlar adecuadamente dichos riesgos en términos de su mitigación y sus planes de
acción.

Modelo de desarrollo concurrente

Pressman (2005) define:

“El modelo de desarrollo concurrente, llamado algunas veces ingeniería concurrente, se

representa de forma esquemática como una serie de actividades del marco de trabajo,
acciones y tareas de la ingeniería del software y sus estados asociados. Por ejemplo, la
actividad modelado, definida para el modelo en espiral, se lleva a cabo al invocar las
acciones siguientes: construcción de prototipos o modelado y especificación del análisis y el
diseño” p. 60
En esencia, todas las actividades existen de forma concurrente e incluso en ejecución,
aunque en diferentes estados, mientras que al mismo tiempo, se generan interacciones y
dependencias entre cada una de las actividades mismas.
Modelos especializados de proceso
Pressman (2005) define:

“Los modelos especializados de proceso adoptan muchas de las características de uno o

más modelos convencionales presentados en sesiones anteriores. Sin embargo, los modelos
especializados tienden a aplicarse cuando se ha elegido un enfoque de ingeniería del
software definido de una manera muy estrecha” p. 63
En este sentido, se han definido algunos modelos con este enfoque como el basado en
componentes[4], en métodos formales[5] y en desarrollo de software orientado a
aspectos[6].

Metodologías de desarrollo de software

Como ya lo mencionamos antes, cuando hablamos de metodologías de desarrollo de
software, es necesario hablar de las familias metodológicas que existen, por lo que antes de
hacer referencia a metodologías específicas, a continuación haremos referencia las
familias referenciadas anteriormente:

Metodologías tradicionales
Son metodologías complejas y estructuradas, donde la documentación es parte fundamental
de sus procesos y la evaluación de cada una de sus fases permite ciertos cambios a nivel de
los objetivos conforme las necesidades así lo requieran, y por ende, el seguimiento basado
en planes de trabajo cobra relevancia.

Ahora bien, dado que normalmente son adoptadas para proyectos largos y grandes, la
aparición de los riesgos es inminente y por ello se hace una tarea compleja.

Desde esta perspectiva, el cliente debe estar en capacidad de describir claramente el

problema y entender la solución propuesta, pues éste no tiene gran participación en todas las
etapas y su interacción con el equipo de trabajo, es principalmente a través de reuniones de
seguimiento.

Normalmente las definiciones dadas para las metodologías tradicionales son provenientes de
estándares formales de desarrollo, que hacen de estas, elementos costosos por ejemplo al
momento de asumir un cambio en las definiciones del proyecto, pues no existe mucha
flexibilidad ante los cambios.

En síntesis, con las metodologías tradicionales existen muchos artefactos, grupos definidos
dentro del equipo de trabajo y por ende un número importante de roles, y un contrato definido
desde etapas tempranas del proyecto.

Metodologías ágiles
Son metodologías sencillas y rápidas en su ejecución, donde la documentación no tiene
mucha relevancia[7] y la entrega de resultados al cliente, es continua. Se pone mucha
atención a la excelencia técnica, donde los planes de trabajo pierden relevancia y por ende el
seguimiento también.
Teniendo en cuenta que normalmente son adoptadas para proyectos cortos y pequeños, la
aparición de los riesgos aunque inevitable, se puede mitigar relativamente fácil dado que se
da importancia a la simplicidad y a la eliminación del trabajo innecesario eliminando procesos
complejos.

Desde esta perspectiva, el cliente hace parte integral del equipo de trabajo, lo que le brinda
cierta flexibilidad en términos de la claridad que debe tener frente a sus necesidades, pues
en a medida que el proyecto avanza, y seguramente con la ayuda de los demás integrantes
del equipo de trabajo, puede ir dando claridad a sus dudas.

Es común que las definiciones dadas para estas metodologías estén basadas en aspectos
empíricos y heurísticas provenientes de la producción de artefactos tangibles, lo que las
convierte en elementos relativamente económicos y muy flexibles ante los cambios.

En síntesis, con las metodologías ágiles existen pocos artefactos, pequeños equipos de
trabajo y por ende un número reducido de roles, y un contrato no tradicional que permite
flexibilidad en términos de costos, tiempos y compromisos.

Metodologías híbridas
Son metodologías flexibles que combinan las mejores prácticas que exponen las
metodologías pertenecientes a las familias metodológicas descritas anteriormente, donde la
documentación tiene importancia de acuerdo a la complejidad del proyecto, así como la
entrega de resultados a los clientes, que además, está definida de acuerdo a las
necesidades que el mismo establezca. En consecuencia, los cronogramas y por ende el
seguimiento, se ajusta del mismo modo de acuerdo a las condiciones.

Los riesgos pueden ser controlados de acuerdo a la complejidad de los proyectos, y por ello
es posible mitigarlos con cierta facilidad, dado que son identificados oportunamente y
administrados de acuerdo al impacto y a las condiciones que el proyecto y el negocio
definan.

En este sentido, el cliente puede o no ser parte integral del equipo de trabajo y en caso de
serlo, puede tomar una participación total o parcial, de igual forma, dependiendo de las
necesidades que el proyecto mismo defina.

En consecuencia, las definiciones dadas para estas metodologías están basadas, no sólo por
aspectos teóricos y formales, sino también en la práctica y la experiencia, seguramente
empírica.
En síntesis, con las metodologías híbridas, la existencia de artefactos dependerá del
proyecto y las condiciones que defina el negocio, y del mismo modo, podrán ajustarse a un
número amplio o reducido de personas según sea la necesidad, dónde también el contrato y
el tipo de proyectos pueden variar.

Algunas metodologías de desarrollo de software

Así, con base en todas las definiciones teóricas y prácticas que se han hecho en relación a
las metodologías de desarrollo de software, existe una amplia variedad de éstas, por lo que a
continuación se hará referencia a algunas (desde luego no son las únicas que existen ni
tampoco necesariamente las más importantes, simplemente son las que se consideran
pertinentes):

Metodología en cascada
La metodología en cascada parte de los principios definidos para el modelo de desarrollo de
software en cascada, también conocido como ciclo de vida clásico o modelo convencional,
donde según Pressman (2005), dicho modelo sugiere un enfoque sistemático y secuencial
hacia el desarrollo de software que indica ciertas etapas y actividades.
En este sentido, el modelo mismo se ha constituido en una metodología que ordena
rigurosamente todas las etapas del ciclo de vida del software, implicando en sí misma un
desarrollo de proyecto rígido y lineal.

Esta es la metodología clásica dentro del contexto del desarrollo de software, que busca
producir un software robusto y estrictamente documentado en cada una de sus etapas,
donde a la finalización de cada una permite el inicio de la siguiente, tomando como parte del
insumo los datos producidos en la anterior.

Así, según Sommerville (2005), las etapas definidas para el modelo se transforman en
actividades fundamentales de desarrollo:

“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.
Diseño del sistema y del software. El proceso de diseño del sistema divide los
requerimientos en sistemas hardware y software. Establece una arquitectura completa del
sistema. El diseño del software identifica y describe las abstracciones fundamentales del
sistema software y sus relaciones.
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 con su especificación.
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 software se entrega al
cliente.
Funcionamiento y mantenimiento. Por lo general (aunque no necesariamente), ésta 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.” p. 62

Metodología RUP (Rational Unified Process)

IBM (2011) define a RUP como:

“IBM Rational Unified Process® (RUP®) is a comprehensive process framework that

provides industry-tested practices for software and systems delivery and implementation and
for effective project management.”
Además, IBM (2011) plantea que:

“RUP promotes iterative development and organizes the development of software and
systems into four phases, each consisting of one or more executable iterations of the
software at that stage of development.”
RUP es una metodología que busca la producción de software, cumpliendo con los requisitos
de los usuarios dentro de una planificación y presupuesto establecidos que contempla dentro
de sus procesos el uso del Unified Modeling Language (UML)[8].
RUP se ejecuta en dos dimensiones, vertical y horizontalmente, pues a medida que los flujos
de trabajo del proceso y de soporte se van ejecutando de forma vertical, también se van
ejecutando las respectivas fases de iniciación, elaboración, construcción y transición, de
forma horizontal, completando así cuando terminan las respectivas ejecuciones, ciclos que
generan entregables internos o externos[9], y a su vez dentro de cada una de las ejecuciones
de las respectivas fases, se generan iteraciones internas de acuerdo a las necesidades que
el equipo de trabajo pueda tener en un momento determinado.
Además, RUP involucra los siguientes modelos de desarrollo de software: Modelo en
cascada: A medida que las fases y los flujos de trabajo se ejecutan, claramente se evidencia
un comportamiento en cascada. Modelo en espiral: Dado que en cada una de las fases se
pueden ejecutar varias iteraciones, es posible ver allí un comportamiento en espiral. Modelo
de prototipos: Sabiendo que cada ciclo genera un entregable, bien podrían definirse algunos
de estos como módulos funcionales que evidencian un comportamiento en prototipos.

Metodología MSF (Microsoft Solutions Framework)

Microsoft (2011) define a MSF como:

“Microsoft® Solutions Framework es un marco de trabajo de referencia para construir e

implantar sistemas empresariales distribuidos basados en herramientas y tecnologías de
Microsoft. MSF comprende un conjunto de modelos, conceptos y guías que contribuyen a
alinear los objetivos de negocio y tecnológicos, reducir los costos de la utilización de nuevas
tecnologías, y asegurar el éxito en la implantación de las tecnologías Microsoft. MSF es el
resultado de las experiencias de diferentes áreas de Microsoft con proyectos exitosos.”
MSF es una metodología flexible e interrelacionada con una serie de conceptos, modelos y
prácticas de uso, que controlan la planificación, el desarrollo y la gestión de proyectos
tecnológicos. Además, se centra en los modelos de proceso y de equipo dejando en un
segundo plano las elecciones tecnológicas.

Metodología Scrum
Scrum (2011) define a Scrum como:

“Scrum, que se basa en la teoría del control empírico del procesos, emplea un enfoque
iterativo e incremental para optimizar la previsibilidad y controlar los riesgos. Existen tres
pilares que sostienen toda implementación del control empírico de procesos.”
Scrum es una metodología de desarrollo muy simple que requiere esfuerzo porque no se
basa en el seguimiento de un plan de trabajo, sino en la adaptación continua a las
circunstancias de la evolución del proyecto, por lo que su ejecución es simple, igual que lo
son sus componentes, los roles que la articulan y las actividades principales.

Vale la pena destacar que la simpleza que describe Scrum y la necesidad de adaptación
constante por parte del equipo de trabajo por la ausencia de un plan de trabajo, pueden
generar ciclos infinitos en su ejecución, ocasionando retrasos, donde dichos ciclos pueden
obedecer a diferentes esquemas de ejecución: secuencial, secuencial con solapamiento y
solapado, que seguramente se adoptarán partiendo de las necesidades y de la experticia del
equipo de trabajo.

Metodología XP (eXtreme Programming)

XP (2011) define a XP como:

“La programación extrema es exitosa porque enfatiza la satisfacción del cliente. En lugar de
entregar todo lo que pueda desear en una fecha lejana en el futuro, este proceso le brinda el
software que necesita según lo necesite.
La programación extrema permite a sus desarrolladores responder con confianza a los
requisitos cambiantes de los clientes, incluso al final del ciclo de vida.

La programación extrema enfatiza el trabajo en equipo. Los gerentes, clientes y

desarrolladores son socios iguales en un equipo colaborativo. Extreme Programming
implementa un entorno simple pero efectivo que permite a los equipos ser altamente
productivos. El equipo se autoorganiza alrededor del problema para resolverlo de la manera
más eficiente posible.

La programación extrema mejora un proyecto de software en cinco formas esenciales;

comunicación, simplicidad, retroalimentación, respeto y coraje. Los programadores extremos
se comunican constantemente con sus clientes y compañeros programadores ".
XP es una metodología ágil centrada en potenciar las relaciones interpersonales como clave
para el éxito en desarrollo de software, promoviendo el trabajo en equipo, preocupándose por
el aprendizaje de los desarrolladores y propiciando un buen clima laboral, donde su proceso
describe simpleza en su ejecución y practicidad al momento de abordar las actividades, sin
embargo, se requiere que el equipo de trabajo tenga un alto grado de adaptación al cambio,
grandes habilidades de programación y trabajo bajo presión.