PROCESO DE DESARROLLO DE UN SISTEMA (metodologías y ciclo de vida)
El objetivo de un proceso de desarrollo de software es la producción de software de manera
eficaz y eficiente. Este proceso se ve influenciado por la creatividad y decisiones de las
personas involucradas: es totalmente intelectual. Se puede comparar con cualquier pro-
yecto de ingeniería, aunque en el desarrollo de un sistema intervienen retos adicionales
relacionados con las características y naturaleza del producto que se obtendrá. Los rasgos
particulares que están vinculados y tienen influencia en el proceso se detallan a continua-
ción.
Por pequeña que sea, la complejidad de un sistema de información es tal que imposibilita
conseguir su confiabilidad al 100 %. Una gran combinación de factores hace muy difícil
verificar de manera exhaustiva todas las situaciones posibles de ejecución que puedan pre-
sentarse (ingreso de datos, valores de las variables, almacenamiento de datos, relación con
otras aplicaciones y el equipo en el que se trabaja, entre otros aspectos).
Por la intangibilidad y lo abstracto de un sistema de información es muy complicado definir
sus características y requisitos, sobre todo si no se dispone de antecedentes de desarrollos
equivalentes. Esta situación dificulta el establecimiento y consolidación de los requisitos, y
estos pueden sufrir cambios durante el desarrollo y aún después de terminado el producto.
El desarrollo de un sistema de información no es un proceso único. No existe un proceso
general que se apegue a todas las características y contextos de los proyectos de desarro-
llo. Tal diversidad dificulta la automatización de todo un proceso de desarrollo de software.
Metodologías de desarrollo de sistemas
El desarrollo de un sistema de información puede iniciarse al existir problemas con el sis-
tema actual, incorporar nuevas oportunidades de negocio, aumentar la competencia, hacer
uso más eficiente de la información o por crecimiento en la organización.
Una metodología de desarrollo de software incluye un conjunto de actividades utilizadas
como marco de referencia para la estructuración, planeación y control de todo el proceso
de desarrollo de los sistemas de información.
Las metodologías de desarrollo de sistemas deben definir objetivos, fases, tareas, produc-
tos y responsables, necesarios para la correcta realización del proceso y su seguimiento.
Principales objetivos de una metodología de desarrollo:
a) Asegurar la uniformidad y calidad tanto del desarrollo como del sistema en sí
b) Satisfacer las necesidades de los usuarios del sistema
c) Conseguir un mayor nivel de rendimiento y eficiencia del personal asignado al desarrollo
d) Ajustarse a los plazos y costes previstos en la planificación
e) Generar de forma adecuada la documentación asociada a los sistemas
f) Facilitar el mantenimiento posterior de los sistemas
Tomando como base la clase de notación empleada para especificar los productos obteni-
dos en las etapas de análisis y diseño, las metodologías pueden clasificarse en dos tipos:
estructuradas y orientadas a objetos.
Por otra parte, considerando su filosofía de desarrollo, las metodologías con mayor énfasis
en la planificación y control del proyecto, en especificación precisa de requisitos y mode-
lado, se conocen como tradicionales (o peyorativamente pesadas o peso pesado).
Otras metodologías denominadas ágiles están más encauzadas a la generación de código
con ciclos muy cortos de desarrollo; se dirigen a equipos de desarrollo pequeños; hacen
hincapié en aspectos humanos asociados al trabajo en equipo e involucran activamente al
cliente en el proceso.
Metodologías estructuradas. Los métodos estructurados comenzaron a desarrollarse a
fines de la década de 1970 con la programación estructurada. Luego, a mediados de esa
misma década, aparecieron primero algunas técnicas para el diseño (por ejemplo, el dia-
grama de estructura), y posteriormente para el análisis (como el diagrama de flujo de datos).
Estas metodologías son particularmente apropiadas en proyectos que utilizan para la im-
plementación lenguajes de tercera y cuarta generación.
Metodologías orientadas a objetos. Su historia va unida a la evolución de los lenguajes
de programación orientada a objeto. Entre los más representativos están Simula (fines de
la década de 1960), Smalltalk-80 (fines de la década de 1970), la primera versión de C++
por Bjarne Stroustrup (1981), y actualmente Java o C# de Microsoft. Al término de la década
de 1980 comenzaron a consolidarse algunos métodos orientados a objeto.
En 1995, Booch y Rumbaugh propusieron el método unificado, con la ambiciosa idea de
conseguir una unificación de sus métodos y notaciones, que posteriormente se reorientó a
un objetivo más modesto, para dar lugar al Unified Modeling Language (UML), la notación
OO más popular en la actualidad.
Algunos métodos OO con notaciones predecesoras de UML son OOAD (Booch), OOSE
(Jacobson), Coad & Yourdon, Shaler & Mellor y OMT (Rumbaugh).
Y algunas metodologías orientadas a objetos que utilizan la notación UML son Rational
Unified Process (RUP), Open y Métrica (que también soporta la notación estructurada).
Metodologías tradicionales (no ágiles). Las metodologías no ágiles son aquéllas que es-
tán guiadas por una fuerte planificación durante todo el proceso de desarrollo. Son llamadas
también metodologías tradicionales o clásicas, donde se realiza una intensa etapa de aná-
lisis y diseño antes de la construcción del sistema.
Metodologías ágiles. Un proceso es ágil cuando el desarrollo del sistema de información
es incremental (entregas pequeñas de software con ciclos rápidos), cooperativo (cliente y
desarrolladores trabajan juntos constantemente con una comunicación cercana), sencillo
(el método en sí mismo es fácil de aprender y modificar, y bien documentado), y adaptable
(permite realizar cambios de último momento).
Ciclo de vida del desarrollo de sistema
Al proceso de desarrollo de un sistema también se le conoce como ciclo de vida de desa-
rrollo de sistema, debido a que las actividades relacionadas en él son continuas. Conforme
se va creando un sistema, el proyecto utiliza calendarios que consideran fechas límite,
hasta la conclusión y aceptación.
Todo proceso de desarrollo se inicia cuando la gerencia o el personal correspondiente se
percatan de la necesidad de un sistema por perfeccionarse o mejorarse. Las principales
etapas del desarrollo de un sistema son las siguientes:
El ciclo de vida del desarrollo de los sistemas (SDLC, Systems Development Life Cycle) es
un enfoque por fases, cuya premisa principal consiste en que los sistemas se desarrollan
mejor utilizando un ciclo específico de actividades del analista y el usuario.
Los analistas no se ponen de acuerdo en la cantidad de fases que incluye el SDLC, pero
en general alaban su enfoque organizado. A pesar de que cada fase se explica por sepa-
rado, generalmente nunca se realiza como un paso aislado. Es posible que varias activida-
des ocurran de manera simultánea y algunas de ellas podrían repetirse. Es más práctico
considerar que el SDLC se realiza por fases (con actividades en pleno apogeo que se tras-
lapan con otras hasta terminarse por completo) y no en pasos aislados.
Se pueden distinguir las siguientes etapas que forman el ciclo de vida de desarrollo de un
sistema de información:
Planificación. En esta fase se incluyen tareas como la determinación del ámbito del pro-
yecto, un estudio de viabilidad, análisis de riesgos, costes estimados, asignación de recur-
sos en las distintas etapas, etc.
Análisis. Proceso en el que se trata de descubrir lo que se necesita y cómo llegar a las
características que el sistema debe poseer.
Diseño. Se estudian las posibles implementaciones que hay que construir y la estructura
general del software. Es una etapa complicada, y si la solución inicial no es la más ade-
cuada, habrá que redefinirla.
Implementación. Se trata de elegir las herramientas adecuadas, un entorno de desarrollo
que haga más sencillo el trabajo y el lenguaje de programación óptimo. Esta decisión va a
depender del diseño y el entorno elegido. Es importante tener en cuenta la adquisición de
productos necesarios para que el software funcione.
Pruebas. Conseguiremos detectar los fallos que se hayan cometido en etapas anteriores,
para que no repercuta en el usuario final. Esta fase del ciclo hay que repetirla tantas veces
como sea necesaria, ya que la calidad y estabilidad final del software dependerá de esta
fase.
Instalación. En esta fase pondremos el software en funcionamiento.
Mantenimiento. Este es un momento crucial dentro del ciclo de vida de un software. Se
proporciona mantenimiento correctivo para eliminar defectos que se van detectando, man-
teniendo adaptativo para adecuar el sistema a nuevas necesidades y mantenimiento per-
fectivo para añadir nuevas funcionalidades.
Modelos de ciclo de vida
El modelo de proceso o modelo de ciclo de vida utilizado para el desarrollo de sistemas
define el orden para las actividades involucradas y la coordinación entre ellas, su enlace y
retroalimentación.
El ciclo de vida de un sistema de información empieza cuando se da la recolección de re-
querimientos para el sistema a desarrollar y termina cuando el sistema ha quedado com-
pletado y es entregado al cliente. Sin embargo, en el intermedio, hay una gran cantidad de
fases por las cuales se tiene que pasar y cada metodología tiene fases distintas en su ciclo
de desarrollo de sistemas.
Modelos tradicionales o clásicos
Waterfall (cascada): las etapas se organizan de arriba a abajo, de ahí el nombre. Se desa-
rrollan las diferentes funciones en etapas diferenciadas y obedeciendo un riguroso orden.
Antes de cada etapa se debe revisar el producto para ver si está listo para pasar a la si-
guiente fase. Los requisitos y especificaciones iniciales no están predispuestos para cam-
biarse, por lo que no se pueden ver los resultados hasta que el proyecto ya esté bastante
avanzado.
Prototipado: se basa en la construcción de un prototipo de software que se construye rá-
pidamente para que los usuarios puedan probarlo y aportar feedback. Así, se puede arreglar
lo que está mal e incluir otros requerimientos que puedan surgir. Es un modelo iterativo que
se basa en el método de prueba y error para comprender las especificidades del producto.
Espiral: es una combinación de los dos modelos anteriores, que añade el concepto de aná-
lisis de riesgo. Se divide en cuatro etapas: planificación, análisis de riesgo, desarrollo de
prototipo y evaluación del cliente. El nombre de esta metodología da nombre a su funcio-
namiento, ya que se van procesando las etapas en forma de espiral. Cuanto más cerca del
centro se está, más avanzado está el proyecto.
Incremental: se va construyendo el producto final de manera progresiva. En cada etapa
incremental se agrega una nueva funcionalidad, lo que permite ver resultados de una forma
más rápida en comparación con el modelo en cascada. El software se puede empezar a
utilizar incluso antes de que se complete totalmente y, en general, es mucho más flexible
que las demás metodologías.
Diseño rápido de aplicaciones (RAD): permite desarrollar software de alta calidad en un
corto periodo de tiempo. Los costes son mucho más altos y el desarrollo más flexible, aun-
que requiere una mayor intervención de los usuarios. Por otro lado, el código puede conte-
ner más errores, y sus funciones son limitadas debido al poco tiempo del que se dispone
para desarrollarlas. El objetivo es iterar el menor número posible de veces para conseguir
una aplicación completa de forma rápida.
Modelos ágiles
Kanban: inventada por la empresa de automóviles Toyota. Consiste en dividir las tareas en
porciones mínimas y organizarlas en un tablero de trabajo dividido en tareas pendientes,
en curso y finalizadas. De esta forma, se crea un flujo de trabajo muy visual basado en
tareas prioritarias e incrementando el valor del producto.
Scrum: divide los requisitos y tareas de forma similar a Kanban. Se itera sobre bloques de
tiempos cortos y fijos (entre dos y cuatro semanas) para conseguir un resultado completo
en cada iteración. Las etapas son: planificación de la iteración (planning sprint), ejecución
(sprint), reunión diaria (daily meeting) y demostración de resultados (sprint review). Cada
iteración por estas etapas se denomina también sprint.
Lean: está configurado para que pequeños equipos de desarrollo muy capacitados elabo-
ren cualquier tarea en poco tiempo. Los activos más importantes son las personas y su
compromiso, relegando así a un segundo plano el tiempo y los costes. El aprendizaje, las
reacciones rápidas y potenciar el equipo son fundamentales.
Programación extrema (XP): está basado en las relaciones interpersonales, que se con-
sideran la clave del éxito. Su principal objetivo es crear un buen ambiente de trabajo en
equipo y que haya un feedback constante del cliente. El trabajo se basa en 12 conceptos:
diseño sencillo, testing, refactorización y codificación con estándares, propiedad colectiva
del código, programación en parejas, integración continua, entregas semanales e integridad
con el cliente, cliente in situ, entregas frecuentes y planificación.
Modelos orientados a objetos
Modelo Fuente. En este ciclo de vida, las fases se solapan mucho, y se representa al
ciclo de desarrollo como si fuese una fuente, siendo cada fase una “burbuja”. Cada clase
puede tener un ciclo de vida sólo para ella debido a que cada una puede estar en una fase
diferente en un momento cualquiera. La ventaja es que permite un desarrollo solapado e
iterativo.
Modelo de Agrupamiento (Clúster). El clúster es la unidad natural para el desarrollo del
sistema y es un grupo de clases relacionadas. Cada clúster tiene un ciclo de vida propio
formado por Especificación, Diseño, Implementación, Verificación/Validación y Generaliza-
ción. Tiene un componente secuencial y un componente concurrente. Es decir, existen di-
ferentes subciclos de vida, que pueden solaparse en el tiempo.
Modelo Remolino. El ciclo de vida de un desarrollo orientado al objeto es desordenado,
involucrando múltiples iteraciones interrelacionadas, En el modelo en cascada se asume
una sola dimensión de iteración, consistentes en la fase de proceso, en cambio, el modelo
remolino se pueden asumir otras dimensiones:
• Amplitud: tamaño del desarrollo, por ejemplo, en número de elementos.
• Profundidad: referida al nivel de abstracción o detalle.
• Madurez: grado de complexión, corrección y elegancia.
• Alternativas: Diferentes soluciones a un problema.
• Alcance: Propósitos y objetivos del sistema, ya que los requisitos van cambiando a
lo largo del tiempo.
Las diferentes dimensiones pueden anidarse de varias formas. Ejemplo: profundidad - ma-
durez – amplitud. Este proceso fractal (más que lineal), consiste en un desarrollo multiciclo
en forma de remolino en lugar de una cascada, de ahí su nombre.
Modelo PinBall. En este ciclo de vida, una pelota del Pinball representa el sistema a
desarrollar, que pasa iterativamente por fases que ocurren casi en cualquier momento,
saltando de una a otra. Se procede de forma iterativa a encontrar clases, atributos, méto-
dos y relaciones (actividades que pueden englobarse en la fase de análisis) y definir
colaboraciones, herencia, agregación y subsistemas (actividades de diseño), y por último
se pasa a la programación, prueba e implementación. Como en el pinball los pasos se pue-
den dar en cualquier orden y de forma simultánea.
