Está en la página 1de 7

Qu metodologa debo usar para el desarrollo de un Software?

Todos en algn momento nos hemos hecho esta pregunta, cuando hemos tenido que desarrollar
un software. Y de hecho esta pregunta se torna muy importante, pues como arquitectos
(diseadores) de Software, debemos tener un plano en que apoyarnos.
Todo desarrollo de software es riesgoso y difcil de controlar, pero si no llevamos una metodologa
de por medio, lo que obtenemos es clientes insatisfechos con el resultado y desarrolladores an
ms insatisfechos.
Sin embargo, muchas veces no se toma en cuenta el utilizar una metodologa adecuada, sobre
todo cuando se trata de proyectos pequeos de dos o tres meses.
Lo que se hace con este tipo de proyectos es separar rpidamente el aplicativo en procesos, cada
proceso en funciones, y por cada funcin determinar un tiempo aproximado de desarrollo.
Cuando los proyectos que se van a desarrollar son de mayor envergadura, ah si toma sentido el
basarnos en una metodologa de desarrollo, y empezamos a buscar cul sera la ms apropiada
para nuestro caso. Lo cierto es que muchas veces no encontramos la ms adecuada y terminamos
por hacer o disear nuestra propia metodologa, algo que por supuesto no est mal, siempre y
cuando cumpla con el objetivo.
Muchas veces realizamos el diseo de nuestro software de manera rgida, con los requerimientos
que el cliente nos solicit, de tal manera que cuando el cliente en la etapa final (etapa de prueba),
solicita un cambio se nos hace muy difcil realizarlo, pues si lo hacemos, altera muchas cosas que
no habamos previsto, y es justo ste, uno de los factores que ocasiona un atraso en el proyecto y
por tanto la incomodidad del desarrollador por no cumplir con el cambio solicitado y el malestar por
parte del cliente por no tomar en cuenta su pedido. Obviamente para evitar estos incidentes
debemos haber llegado a un acuerdo formal con el cliente, al inicio del proyecto, de tal manera que
cada cambio o modificacin no perjudique al desarrollo del mismo.
Por experiencia, muchas veces los usuarios finales, se dan cuenta de las cosas que dejaron de
mencionar, recin en la etapa final del proyecto, pese a que se les mostr un prototipo del software
en la etapa inicial del proyecto.
Los proyectos en problemas son los que salen del presupuesto, tienen importantes retrasos, o
simplemente no cumplen con las expectativas del cliente.
Para dar una idea de qu metodologa podemos utilizar y cual se adapta ms a nuestro medio,
mencionar tres de ellas de las que considero las ms importantes y en la actualidad las ms
utilizadas, tal como: RUP, XP y MSF.
Rational Unified Process (RUP)
La metodologa RUP, llamada as por sus siglas en ingls Rational Unified
Process, divide en 4 fases el desarrollo del software:
Inicio, El Objetivo en esta etapa es determinar la visin del proyecto.
Elaboracin, En esta etapa el objetivo es determinar la arquitectura ptima.
Construccin, En esta etapa el objetivo es llevar a obtener la capacidad operacional inicial.
Transmisin, El objetivo es llegar a obtener el release del proyecto.

Cada una de estas etapas es desarrollada mediante el ciclo de iteraciones, la cual consiste en
reproducir el ciclo de vida en cascada a menor escala. Los Objetivos de una iteracin se
establecen en funcin de la evaluacin de las iteraciones precedentes.
Vale mencionar que el ciclo de vida que se desarrolla por cada iteracin, es llevada bajo dos
disciplinas:
Disciplina de Desarrollo
Ingeniera de Negocios: Entendiendo las necesidades del negocio.
Requerimientos: Trasladando las necesidades del negocio a un sistema automatizado.
Anlisis y Diseo: Trasladando los requerimientos dentro de la arquitectura de software.
Implementacin: Creando software que se ajuste a la arquitectura y que tenga el comportamiento

deseado.
Pruebas: Asegurndose que el comportamiento requerido es el correcto y que todo lo solicitado
est presente.
Disciplina de Soporte
Configuracin y administracin del cambio: Guardando todas las versiones del proyecto.
Administrando el proyecto: Administrando horarios y recursos.
Ambiente: Administrando el ambiente de desarrollo.

Distribucin: Hacer todo lo necesario para la salida del proyecto

Figura 1: Fases e Iteraciones de la Metodologa RUP.

Es recomendable que a cada una de estas iteraciones se les clasifique y ordene segn su
prioridad, y que cada una se convierte luego en un entregable al cliente. Esto trae como beneficio
la retroalimentacin que se tendra en cada entregable o en cada iteracin.
Los elementos del RUP son:
Actividades, Son los procesos que se llegan a determinar en cada iteracin.
Trabajadores, Vienen hacer las personas o entes involucrados en cada proceso.
Artefactos, Un artefacto puede ser un documento, un modelo, o un elemento de modelo.

Una particularidad de esta metodologa es que, en cada ciclo de iteracin, se hace exigente el uso
de artefactos, siendo por este motivo, una de las metodologas ms importantes para alcanzar un
grado de certificacin en el desarrollo del software.
Extreme Programing (XP)
Es una de las metodologas de desarrollo de software ms exitosas en la actualidad utilizadas para
proyectos de corto plazo, corto equipo y cuyo plazo de entrega era ayer. La metodologa consiste
en una programacin rpida o extrema, cuya particularidad es tener como parte del equipo, al
usuario final, pues es uno de los requisitos para llegar al xito del proyecto.

Figura 2: Metodologa Extreme Programing

Caractersticas de XP, la metodologa se basa en:


Pruebas Unitarias: se basa en las pruebas realizadas a los principales procesos, de tal manera

que adelantndonos en algo hacia el futuro, podamos hacer pruebas de las fallas que pudieran
ocurrir. Es como si nos adelantramos a obtener los posibles errores.
Re fabricacin: se basa en la reutilizacin de cdigo, para lo cual se crean patrones o modelos
estndares, siendo ms flexible al cambio.
Programacin en pares: una particularidad de esta metodologa es que propone la
programacin en pares, la cual consiste en que dos desarrolladores participen en un proyecto en
una misma estacin de trabajo. Cada miembro lleva a cabo la accin que el otro no est haciendo
en ese momento. Es como el chofer y el copiloto: mientras uno conduce, el otro consulta el mapa.
Qu es lo que propone XP?
Empieza en pequeo y aade funcionalidad con retroalimentacin continua
El manejo del cambio se convierte en parte sustantiva del proceso
El costo del cambio no depende de la fase o etapa
No introduce funcionalidades antes que sean necesarias
El cliente o el usuario se convierte en miembro del equipo

Derechos del Cliente


Decidir que se implementa
Saber el estado real y el progreso del proyecto
Aadir, cambiar o quitar requerimientos en cualquier momento
Obtener lo mximo de cada semana de trabajo

Obtener un sistema funcionando cada 3 o 4 meses

Derechos del Desarrollador


Decidir cmo se implementan los procesos
Crear el sistema con la mejor calidad posible
Pedir al cliente en cualquier momento aclaraciones de los requerimientos
Estimar el esfuerzo para implementar el sistema
Cambiar los requerimientos en base a nuevos descubrimientos

Lo fundamental en este tipo de metodologa es:


La comunicacin, entre los usuarios y los desarrolladores
La simplicidad, al desarrollar y codificar los mdulos del sistema
La retroalimentacin, concreta y frecuente del equipo de desarrollo, el cliente y los usuarios

finales.
Microsoft Solution Framework (MSF)
Esta es una metodologa flexible e interrelacionada con una serie de conceptos, modelos y
prcticas de uso, que controlan la planificacin, el desarrollo y la gestin de proyectos tecnolgicos.
MSF se centra en los modelos de proceso y de equipo dejando en un segundo plano las elecciones
tecnolgicas.

Figura 3: Metodologa MSF


MSF tiene las siguientes caractersticas:
Adaptable: es parecido a un comps, usado en cualquier parte como un mapa, del cual su uso es

limitado a un especfico lugar.


Escalable: puede organizar equipos tan pequeos entre 3 o 4 personas, as como tambin,
proyectos que requieren 50 personas a ms.
Flexible: es utilizada en el ambiente de desarrollo de cualquier cliente.
Tecnologa Agnstica: porque puede ser usada para desarrollar soluciones basadas sobre
cualquier tecnologa.
MSF se compone de varios modelos encargados de planificar las diferentes partes implicadas en el
desarrollo de un proyecto: Modelo de Arquitectura del Proyecto, Modelo de Equipo, Modelo de
Proceso, Modelo de Gestin del Riesgo, Modelo de Diseo de Proceso y finalmente el modelo de
Aplicacin.

M
O
D
E
L
O

P
R
O
C
E
S
O

Se define como una secuencia de


actividades donde la estrategia
principal es seguir el proceso del
desarrollo de SW hacia checkpoints
o
mediante
entregas
calendarizadas

A
S
C

D
E
S
V
E
N
T
A
J
A
S

V
E
N
T
A
J
A
S

Los documentos tcnicos son


comprensibles para usuarios y
administradores no tcnicos.

Cada detalle de los requisitos se


conoce de antemano antes de
desarrollar el SW, y los detalles
son estables durante el desarrollo.

Las pruebas y evaluaciones se


realizan eficientemente al final del
desarrollo.

Las metas se logran mejor cuando


se tiene puntos de revisin bien
preestablecidos y documentados.

La administracin de proyectos es
ms fcil de lograr en incrementos
ms pequeos.

Es ms fcil comprender y probar


incrementos de funcionalidad ms
pequeos.

La
funcionalidad
inicial
de
desarrolla
ms
temprano,
logrando resultados de inversin
en menor tiempo.

U
S
O

Los
proyectos
reales
raramente siguen el flujo
secuencial que propone el
modelo,
siempre
hay
iteraciones y se crean
problemas en la aplicacin
del paradigma.

Difcil de evaluar el coste


total.

Difcil de aplicar a los


sistemas transaccionales
que
tienden
a
ser
integrados y a operar
como un todo.

Requiere
gestores
experimentados.

Los
errores
requisitos se
tarde.

D
A

I
N
C
R
E
M
E
N
T
A
L

Es una extensin del modelo de


cascada. A diferencio del modelo de
cascada, que es dirigido por
documentos, el modelo espiral se
basa en una estrategia para reducir
el riesgo del proyecto en reas de
incertidumbre, como requerimientos
inestables e incompletos. Al igual
que el modelo evolucionario, el
modelo de espiral incorpora una
estrategia de uso de prototipos
como parte del manejo del riesgo.
Con algunas variantes este es el
proceso ms importante en la
actualidad

Hay
ms
probabilidad
de
satisfacer el cambio en los
requisitos de usuario mediante
incrementos del SW en el tiempo
que si fueran planeados todos a la
vez en un mismo periodo.

en
los
detectan

E
V
O
L
U
T
I
V

Es una extensin del modelo de


cascada. A diferencio del modelo de
cascada, que es dirigido por
documentos, el modelo espiral se
basa en una estrategia para reducir
el riesgo del proyecto en reas de
incertidumbre, como requerimientos
inestables e incompletos. Al igual
que el modelo evolucionario, el
modelo de espiral incorpora una
estrategia de uso de prototipos
como parte del manejo del riesgo.
Con algunas variantes este es el
proceso ms importante en la
actualidad

Se entrega temprano parte del


sistema, aunque no estn
completos todos los
requerimientos.

Se permite entregar parte del


sistema como herramienta para la
generacin de requerimientos
faltantes.

Se obtienen beneficios para el


sistema mediante entregas
iniciales mientras las entregas
posteriores estn en desarrollo.

Es una extensin al modelo


incremental, donde los incrementos
de hacen de manera secuencial en
lugar de en paralelo; es tambin
conocido como desarrollo rpido de
aplicaciones
(RAD,
Rapid
Application Development), que se
basa en el uso de prototipos

Una actividad comienza cuando


es entienden los objetivos y
riesgos involucrados.

Basado en la evaluacin de
soluciones alternas, se usan las
herramientas que mejor reduzcan
los riesgos.

Todo el personal relacionado debe


involucrarse en una revisin que
determine cada actividad.

El desarrollo se incrementa en
cada etapa, permitiendo prototipos
sucesivos del producto.

Para construir un programa


exitoso se deben conocer qu
quieren y necesitan los usuarios
potenciales.

O
E
S
P
I
R
A
L

U
P

Es un desarrollo inicial de la
arquitectura completa del sistema,
seguido de incrementos y versiones
parciales
del
mismo.
Cada
incremento tiene si propio ciclo de
vida. Cada incremento agrega
funcionalidad adicional o mejorada
sobre el sistema. Conforme se
completa cada etapa se verifica e
integra la versin con las dems
versiones ya completadas del
sistema. Para que la secuencia de
desarrollo sea exitosa es esencial
definir etapas que no requieran
cambiar los resultados anteriores al
agregar nuevas

Referencias Bibliogrficas

Genera mucho tiempo en


el desarrollo del sistema

Modelo costoso

Requiere experiencia en la
identificacin de riesgos

El desarrollo de un
producto comercial puede
significar un gran esfuerzo
durante meses, e incluso
aos.

Ian Somerville: Ingeniera de Software. Editorial Pearson Addison Wesley.


Sptima Edicin. Madrid, 2005.

S. Pressman, Roger: INGENIERA DEL SOFTWARE, UN ENFOQUE


PRCTICO. Editorial Mc-Graw Hill. Quinta Edicin. 2002.

Weitzenfeld, Alfredo: Ingeniera de Software, Orientada a Objetos con UML,


Java e Internet. Editorial Thomson.