Metodolog�as de desarrollo de software. �Cu�l es el camino?

Ing. Erly Delgado Exp�sito

Profesor Ingenier�a Inform�tica
Universidad de Matanzas �Camilo Cienfuegos�
Telf: (45) 283498
Email: erly_delgado2003@yahoo.es
Recibido: 29-05-2008
Aceptado: 2-09-2008

RESUMEN :
El desarrollo de software no es 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.
La raz�n de ser de este trabajo se basa en el an�lisis de algunos tipos de
metodolog�as
existentes, viendo sus principales caracter�sticas y los rasgos que las hacen
superior a las
otras.
Palabras claves: Metodolog�as, RUP, XP, 3P, Software, Procesos, Ingenier�a.
ABSTRACT:
The software development is not an easy task. As a result to this problem an
alternative has
arisen for a lot: the Methodology. The methodologies impose a process disciplined
on the
software development with the purpose of making it more predictable and more
efficient. They
make it developing a detailed process with a strong emphasis in planning, inspired

by other
disciplines of the engineering.
The methodologies of engineerings have been present during a lot of time. They
have not in
fact been distinguished to be very successful, even less for their popularity. The

most frequent
critic to these methodologies is that they are bureaucratic. There is so much to
make to follow
the methodology that the whole rhythm of the development is slowed.
The reason of being of this work is based on the analysis of some types of existent
methodologies, seeing its main ones characteristic and the features that make
them superior to
the other ones.
Key words: Methodologies, RUP, XP, 3P, Software, Processes, Engineering.
Introducci�n:
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. �stas 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.
Revista de Arquitectura e Ingenier�a
2008, vol. 2 no.3.
Ing. Erly Delgado Exp�sito Metodolog�as de desarrollo de
software �
Aplicar metodolog�as tradicionales nos obliga a forzar a nuestro cliente a que
tome la mayor�a
de las decisiones al principio. Como respuesta a los problemas de las
metodolog�as
tradicionales surgieron otras metodolog�as. El encanto de estas metodolog�as
�giles es su
reacci�n ante la burocracia de las metodolog�as monumentales. El resultado de
todo esto es
que los m�todos �giles cambian significativamente algunos de los �nfasis de los
m�todos
ingenieriles. La diferencia 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.
Desarrollo:
Problemas detectados en las metodolog�as ingenieriles:
Retrasos en la planificaci�n: llegada la fecha de entregar el software, �ste no
esta
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.
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 RUP. El resultado
es
un proceso RUP
basado en componentes, dirigido por los casos de uso de RUP, centrado en la
arquitectura, iterativo e
incremental RUP. [6].
Caracter�sticas principales de RUP
Centrado en los modelos: Los diagramas RUP 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 con RUP. [10]
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. [10]
Centrado en la arquitectura: Los modelos son proyecciones del an�lisis y el
dise�o constituye
la arquitectura del producto a desarrollar. [10]
Iterativo e incremental: Durante todo el proceso de desarrollo se producen
versiones
incrementales (que se acercan al producto terminado) del producto en desarrollo.
[10]
Beneficios que aporta RUP
Permite desarrollar aplicaciones sacando el m�ximo provecho de las nuevas
tecnolog�as,
mejorando la calidad, el rendimiento, la reutilizaci�n, la seguridad y el
mantenimiento del
software mediante una gesti�n sistem�tica de riesgos. [8]
RUP Permite la producci�n de software que cumpla con las necesidades de los
usuarios, a trav�s de
la especificaci�n de los requisitos, con una agenda y costo predecible. [8]
Enriquece la productividad en equipo y proporciona pr�cticas �ptimas de software
a todos sus
miembros. [8].
Revista de Arquitectura e Ingenier�a RUP
2008, vol. 2 no.3.
Ing. Erly Delgado Exp�sito Metodolog�as de desarrollo de
software �
Permite llevar a cabo el proceso de desarrollo pr�ctico, brindando amplias gu�as,
plantillas y
ejemplos para todas las actividades cr�ticas. [8].
Se integra estrechamente con herramientas Rational, permitiendo a los equipos
de desarrollo
aprovechar todas las ventajas de las caracter�sticas de los productos Rational, el

Lenguaje de
Modelado Unificado (UML) y otras pr�cticas �ptimas de la industria. [8].
Optimiza la productividad de cada miembro del equipo al poner al alcance la
experiencia
derivada de miles de proyectos y muchos l�deres de la industria.
No solo garantiza que los proyectos abordados ser�n ejecutados �ntegramente,
sino que
adem�s evita desviaciones importantes respecto a los plazos. [8].
Metodolog�as �giles.
XP
La Programaci�n Extrema surge ideada por Kent Beck, como proceso de
creaci�n de software
diferente al convencional. En palabras de Beck: �XP es una metodolog�a ligera,
eficiente, con
bajo riesgo, flexible, predecible y divertida para desarrollar software�.
Objetivos de XP
Los objetivos de XP son muy simples: la satisfacci�n del cliente. Esta metodolog�a

trata de
dar al cliente el software que �l necesita y cu�ndo lo necesita. Por tanto, debemos

responder
muy r�pido a las necesidades del cliente, incluso cuando los cambios sean al final

de ciclo de
la programaci�n.
El segundo objetivo es potenciar al m�ximo el trabajo en grupo. Tanto los jefes de

proyecto,
los clientes y desarrolladores, son parte del equipo y est�n involucrados en el
desarrollo del
software.
Bases de XP
La programaci�n extrema se basa en la simplicidad, la comunicaci�n y el
reciclado continuo de
c�digo, para algunos no es m�s que aplicar una pura l�gica. Lo que buscan en
definitiva es la
reducci�n de costes.
Valores XP
Una de las cosas que a los programadores nos tiene que quedar muy claro es que
en el ciclo
de vida del desarrollo de un proyecto software los cambios van a aparecer,
cambiar�n los
requisitos, las reglas de negocio, el personal, la tecnolog�a, todo va a cambiar.
Por
tanto el
problema no es el cambio en si, ya que �ste va a suceder, sino la incapacidad de
enfrentarnos
a estos cambios.
Como en otra cualquier actividad humana necesitamos valores para desarrollar
nuestro trabajo
y conseguir los planteamientos iniciales. Estos cuatro valores son: Comunicaci�n,
Sencillez,
Retroalimentaci�n, Valent�a.
Variables XP
XP define cuatro variables para proyectos: Coste, Tiempo, Calidad, y �mbito.
Actividades b�sicas XP
Ahora que tenemos nuestros cuatro valores estamos preparados para construir
una disciplina
de desarrollo de software. �Qu� tareas debemos de llevar a cabo para desarrollar
un buen
software?
Codificar
Es la �nica actividad de la que no podremos prescindir. Sin c�digo fuente no hay
programa, por
tanto necesitamos codificar y plasmar nuestras ideas a trav�s del c�digo. En una
programaci�n
en XP en pareja el c�digo expresa tu interpretaci�n del problema, as� podemos
utilizar el
c�digo para comunicar, para hacer m�as tus ideas, y por consiguiente para
aprender y mejorar.
Revista de Arquitectura e Ingenier�a
2008, vol. 2 no.3.
Ing. Erly Delgado Exp�sito Metodolog�as de desarrollo de
software �
Hacer pruebas
Las caracter�sticas del software que no pueden ser demostradas mediante
pruebas
simplemente no existen. Las pruebas me dan la oportunidad de saber si lo que
implement� es
lo que en realidad yo pensaba que hab�a implementado. Las pruebas nos indican
que nuestro
trabajo funciona, cuando no podemos pensar en ninguna prueba que pudiese
originar un fallo
en nuestro sistema, entonces has acabado por completo.
No debemos de escribir tan solo una prueba, ver qu� funciona y salir corriendo,
debemos de
pensar en todas las posibles pruebas para nuestro c�digo.
Programar y probar es m�s r�pido que s�lo programar. Puedes ganar media hora
de
productividad sin hacer pruebas, pero perder�s mucho tiempo en la depuraci�n.
Tendr�s
menos errores, tendr�s que volver menos veces sobre el c�digo, te costar�
menos localizar los
errores, perder�s menos tiempo, escuchando como tus clientes te dicen que no
funciona.
Las pruebas deben de ser sensatas y valientes. No podemos hacer pruebecillas
que no testen
a fondo el sistema, esos agujeros que vamos dejando nos esperan para cuando
pasemos de
nuevo por all� y volveremos a caer dentro.
Escuchar
Los programadores no lo conocemos todo y sobre todo muchas cosas que las
personas de
negocios piensan que son interesantes. Si ellos pudieran programarse su propio
software
�para qu� nos querr�an ?
Si vamos a hacer pruebas tenemos que preguntar si lo obtenido es lo deseado y
tenemos que
preguntar qui�n necesita la informaci�n. Tenemos que escuchar a nuestros
clientes, cu�les son
los problemas de su negocio, debemos de tener una escucha activa explicando lo
que es f�cil y
dif�cil de obtener y la realimentaci�n entre ambos nos ayudan a todos a entender
los
problemas.
Dise�ar
El dise�o crea una estructura que organiza la l�gica del sistema, un buen dise�o
permite que el
sistema crezca con cambios en un solo lugar. Los dise�os deben de ser sencillos,
si alguna
parte del sistema es de desarrollo complejo, div�dela en varias. Si hay fallos en
el
dise�o o
malos dise�os, �stos deben de ser corregidos cuanto antes.
En resumen, tenemos que codificar porque sin c�digo no hay programas,
tenemos que hacer
pruebas, porque sin pruebas no sabemos si hemos acabado de codificar,
tenemos que
escuchar, porque si no escuchamos no sabemos qu� codificar ni probar y
tenemos que dise�ar
para poder codificar, probar y escuchar indefinidamente.
3P [7]
Paradigma 3P es una metodolog�a de desarrollo de software nacida al calor de la
experiencia
acumulada del grupo de investigaci�n y desarrollo Atis, debido a 3P da la
insuficiente
capacidad de
respuesta a los clientes utilizando las metodolog�as tradicionales.
Principios que sustentan el modelo 3P
Los individuos y sus interacciones son m�s importantes que los procesos y las
herramientas: El
PERSONAL.
La comunicaci�n con el cliente evita construir una elegante soluci�n para un
problema
equivocado: El PROBLEMA.
El software que funciona es m�s importante que la documentaci�n exhaustiva. El
PROCESO.
Valores 3P
Comunicaci�n 3P: Sin comunicaci�n todo proyecto estar�a destinado a fracasar,
comunicar no es
escribir o hablar muchas palabras, sino utilizar solo las palabras necesarias para

trasmitir una
idea.
Sencillez 3P: Nadie es mejor o peor que los dem�s miembros del grupo de
desarrollo, todos
tenemos fortalezas y debilidades, conocerlas har� que nuestras relaciones con los
miembros
del grupo sean mejores.
Revista de Arquitectura e Ingenier�a
2008, vol. 2 no.3.
Ing. Erly Delgado Exp�sito Metodolog�as de desarrollo de
software �
Retroalimentaci�n 3P: Saber cu�ndo se debe rehacer algo que no funciona,
equivocarse es de
humanos, encarar nuevamente la tarea con emprendimiento y optimismo.
Emprendimiento: Estar dispuesto siempre a acometer las tareas m�s complejas,
encararla con
esmero y con alegr�a har� que crezca nuestro prestigio entre los dem�s
miembros, la
convicci�n y el deseo del triunfo debe prevalecer.
Optimismo 3P: Ser realista, pero tener siempre el pensamiento hacia el �xito.
Actividades b�sicas
Codificar, Probar, Comunicar, Idear, Escuchar, Dise�ar.
Roles del proyecto
Jefe del Proyecto, Cliente, Consultor, Analista-Programador, Programador,
Dise�ador de
Interfaces.
Resumen puntos clave
RUP
Pesado
Dividido en cuatro fases, que se dividen en iteraciones
Los artefactos son el objetivo de cada actividad
Se basa en roles
UML
Muy organizativo
Mucha documentaci�n
XP
Ligero
Cercano al desarrollo
Se basa en UserStories
Fuerte comunicaci�n con el cliente
El c�digo fuente pertenece a todos
Programaci�n por parejas
Solo el m�nimo de organizaci�n
Pobre en cuanto a documentaci�n
3P
�gil
Cercano al desarrollo, pero sin olvidar el dise�o
Se basa en 3 principios: Personal, Problema, Proceso
Gran interacci�n con el cliente
Logra alcanzar un control y organizaci�n del proceso
Logra un equilibrio en cuanto a la generaci�n de documentaci�n
Conclusiones:
�Qu� debemos esperar entonces de un proceso de desarrollo?
�Qu� criterios debe cumplir para que aporte algo a la empresa?
B�sicamente el proceso de desarrollo tiene que ayudarnos a escribir software,
tiene que poner
las reglas necesarias para alcanzar el �xito en nuestro proyecto, pero dejando la
libertad
suficiente para no sentirnos agobiados.
Esto no nos lo va a ofrecer ning�n proceso est�ndar y como dice el refr�n (aunque
no se
cumple exactamente en el mundo de la inform�tica) todos los caminos conducen a
Roma.
Revista de Arquitectura e Ingenier�a
2008, vol. 2 no.3.
Ing. Erly Delgado Exp�sito Metodolog�as de desarrollo de
software �
De forma que es tarea de cada empresa, casi para cada proyecto, decidir cu�l es
el mejor
modo de llegar a nuestra meta.
Bibliograf�a:
Alianza �gil. Disponible en: http://www.agilealliance.org
Alistair Desarrollo de Software �gil. Disponible en: http://www.amazon.com/exec/
obidos/ASIN/0201699699/programacione-20
An�nimo. Proceso Unificado de Rational para el desarrollo de software.
Disponible en:
http://www.dybox.cl/metodologia/rup.html. (Mayo 2 del 2005)
An�nimo. Rational Unified Process. Disponible
en:http://www.itera.com.mx/itera/productos/fundamentos.asp. (Mayo 2 del 2005)
An�nimo. Seminario sobre RUP en un entorno empresarial de desarrollo.
Disponible en:
http://www-5.ibm.com/services/learning/es/tairis.nsf. (Mayo 2 del 2005)
Manifiesto para el Desarrollo de Software �gil. Disponible en:
http://www.agilemanifesto.org
Mart�n, F. La Nueva Metodolog�a. Disponible en: http://www.programacion.net
Patricio, L. Departamento de Sistemas Inform�ticos y Computaci�n, Universidad
Polit�cnica de
Valencia. Disponible en: www.upv.es/index-es.html