1.
Introducción
El desarrollo de
software no es
sin dudas una tarea fácil. Como resultado a este problema
ha surgido una alternativa desde hace mucho: la Metodología. Las metodologías
imponen un proceso
disciplinado sobre el desarrollo de software con el fin de
hacerlo más predecible y eficiente. Lo hacen desarrollando
un proceso detallado con un fuerte énfasis en planificar
inspirado por otras disciplinas de la ingeniería.
Las metodologías ingenieriles han estado
presentes durante mucho tiempo. No se
han distinguido precisamente por ser muy exitosas. Aún
menos por su popularidad. La crítica
más frecuente a estas metodologías es que son
burocráticas. Hay tanto que hacer para seguir la
metodología que el ritmo entero del desarrollo se
retarda.
Hoy en día existen numerosas propuestas
metodológicas que inciden en distintas dimensiones del
proceso de desarrollo. Un ejemplo de ellas son las propuestas
tradicionales centradas específicamente en el control del
proceso. Estas han demostrado ser efectivas y necesarias en un
gran número de proyectos, sobre
todo aquellos proyectos de gran tamaño (respecto a tiempo
y recursos).
Sin embargo la experiencia ha demostrado que las
metodologías tradicionales no ofrecen una buena
solución para proyectos donde el entorno es volátil
y donde los requisitos no se conocen con exactitud, porque no
están pensadas para trabajar con incertidumbre.
Aplicar metodologías tradicionales nos obliga a
forzar a nuestro cliente a que
tome la mayoría de las decisiones al principio. Luego el
coste de cambio de una
decisión tomada puede llegar a ser muy elevado si
aplicamos metodologías tradicionales.
Es por ello que varios problemas como
los que a continuación mencionamos han sido
detectados:
- Retrasos en la planificación: llegada la fecha de
entregar el software éste no está
disponible. - Sistemas deteriorados: el software se ha creado pero
después de un par de años el coste de su mantenimiento es tan complicado que
definitivamente se abandona su producción. - Tasa de defectos: el software se pone en
producción pero los defectos son tantos que nadie lo
usa. - Requisitos mal comprendidos: el software no resuelve
los requisitos planificados inicialmente. - Cambios de negocio: el problema que resolvía
nuestro software ha cambiado y nuestro software no se ha
adaptado. - Falsa riqueza: el software hace muchas cosas
técnicamente muy interesantes y divertidas, pero no
resuelven el problema de nuestro cliente, ni hace que
éste gane más dinero. - Cambios de personal:
después de unos años de trabajo los
programadores comienzan a odiar el proyecto y lo
abandonan.
Como respuesta a los problemas aplicando
metodologías tradicionales surgieron otras
metodologías que tratan de adaptarse a la realidad del
desarrollo de software.
El encanto de estas metodologías ágiles es
su reacción ante la burocracia de las
metodologías monumentales. Estos nuevos métodos
buscan un justo medio entre ningún proceso y demasiado
proceso, proporcionando simplemente suficiente proceso para que
el esfuerzo valga la pena.
El resultado de todo esto es que los métodos
ágiles cambian significativamente algunos de los
énfasis de los métodos ingenieriles. La diferencia
inmediata es que son menos orientados al documento, exigiendo una
cantidad más pequeña de documentación para una tarea dada. De
muchas maneras son más bien orientados al código:
siguiendo un camino que dice que la parte importante de la
documentación es el código fuente.
2.
Desarrollo
Metodologías pesadas.
RUP
El proceso unificado de desarrollo (RUP) es una
metodología para la ingeniería de
software que va más allá del mero análisis y diseño
orientado a objetos para proporcionar una familia de
técnicas que soportan el ciclo completo de
desarrollo de software. El resultado es un proceso basado en
componentes, dirigido por los casos de uso, centrado en la
arquitectura,
iterativo e incremental. [JAC05].
Características principales de
RUP
- "Centrado en los modelos: Los diagramas son
un vehículo de comunicación más expresivo que las
descripciones en lenguaje
natural. Se trata de minimizar el uso de descripciones y
especificaciones textuales del sistema.
[BAR05]" - "Guiado por los Casos de Uso: Los Casos de Uso
son el instrumento para validar la arquitectura del software y
extraer los casos de prueba. [BAR05]" - "Centrado en la arquitectura: Los modelos son
proyecciones del análisis y el diseño constituye
la arquitectura del producto a
desarrollar. [BAR05]" - "Iterativo e incremental: Durante todo el
proceso de desarrollo se producen versiones incrementales (que
se acercan al producto terminado) del producto en desarrollo.
[BAR05]"
Página siguiente  |