Metodologas del desarrollo de software

Surgen ante la necesidad de utilizar una serie de procedimientos, tcnicas, herr

amientas y soporte documental a la hora de desarrollar un producto software.
Dichas metodologas pretenden guiar a los desarrolladores al crear un nuevo so
ftware, pero los requisitos de un software a otro son tan variados y cambiantes,
que ha dado lugar a que exista una gran variedad de metodologas para la crea
cin del software. Se podran clasificar en dos grandes grupos:

Las metodologas orientadas al control de los procesos, estableciendo rig

urosamente las actividades a desarrollar, herramientas a utilizar y notaci
ones que se usarn. Estas metodologas son llamadas Metodologas Pesa
das.
Las metodologas orientadas a la interactuaccin con el cliente y el
desarrollo incremental del software, mostrando versiones parcialmente f
uncionales del software al cliente en intervalos cortos de tiempo, para qu
e pueda evaluar y sugerir cambios en el producto segn se va desarrolla
ndo. Estas son llamadas Metodologas ligeras/giles.

Metodologas pesadas
Mtrica V3
Mtrica Versin 3 ha sido concebida para abarcar el desarrollo completo de
Sistemas de Informacin sea cual sea su complejidad y magnitud, por lo cual
su estructura responde a desarrollos mximos y deber adaptarse y
dimensionarse en cada momento de acuerdo a las caractersticas particulares
de cada proyecto.
La metodologa descompone cada uno de los procesos en actividades, y stas
a su vez en tareas. Para cada tarea se describe su contenido haciendo
referencia a sus principales acciones, productos, tcnicas, prcticas y
participantes.
El orden asignado a las actividades no debe interpretarse como secuencia en
su realizacin, ya que stas pueden realizare en orden diferente a su
numeracin o bien en paralelo, como se muestra en los grficos de cada
proceso. Sin embargo, no se dar por acabado un proceso hasta no haber
finalizado todas las actividades del mismo determinadas al inicio del proyecto.
As los procesos de la estructura principal de Mtrica V3 son los siguientes:

Planificacin de sistemas de informacin

Desarrollo de sistemas de informacin
Mantenimiento de sistemas de informacin

RUP
La metodologa RUP, llamada as por sus siglas en ingls
RationalUnifiedProcess, divide en 4 fases el desarrollo del software:

Inicio
Elaboracin
Construccin
Transicin

Cada una de estas etapas es desarrollada mediante un 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.
Caractersticas de RUP:

Es un proceso iterativo.
Permite considerar las variaciones de los requisitos.
La integracin de los distintos elementos se realiza progresivamente.
Permite disminuir los riesgos.
Facilita la reutilizacin al identificar partes comunes.
Permite una arquitectura ms robusta.
Se puede auto refinar el proceso de desarrollo.
Gestiona los cambios en los requisitos
Facilita el control de proyectos complejos.
Mejora la calidad del software y la satisfaccin del cliente.
Se basa en las tcnicas de modelado propuestas por UML.
Persigue la calidad del producto y la calidad del proceso.
Contempla la gestin de configuracin y la gestin de cambios.
Es un proceso orientado por los casos de uso.

Metodologas agiles
XP (Extreme programming).
La ms conocidas por su acrnimo XP. Se ha mostrado como una metodologa
muy efectiva en grupos de trabajo reducidos gracias a la baja complejidad, por
este motivo, los detractores de metodologas giles, apuntan a problemas de
escalabilidad en el uso de estos enfoques.
XP elimina mucho trabajo superfluo, con lo que consigue mayor eficacia, sin
embargo en grandes empresas, este trabajo extra es necesario para su
correcto funcionamiento.
Los elementos de XP son los siguientes:
El juego de la planificacin (ThePlanningGame).
XP convierte la planificacin de un proyecto en un juego de negocio. Involucra
a todo el equipo en la planificacin consiguiendo que la gente
cooperativamente tome decisiones sobre su carga de trabajo, sus
responsabilidades, y las consecuencias de alcanzar o no los objetivos.
Pequeos estrenos.
La continua liberacin de versiones del software en pequeos
incrementos es una caracterstica de todos los enfoques de giles en
algn nivel. Esto conlleva varios beneficios:
Demuestra que el grupo de trabajo est desarrollando su actividad.
Puede proporcionar un valor real al cliente desde el principio, ayudando
a compensar el costo del proyecto.
El uso de una metfora.
Para facilitar que los desarrolladores entiendan el objetivo del sistema
para el cliente, XP ofrece crear una metfora que explique con un
ejemplo que hay que desarrollar.
Diseo simple.
XP obliga a utilizar siempre el diseo ms simple que cumpla los
requisitos actuales. En principio esto puede provocar que en futuras
versiones se tenga que cambiar todo el diseo, por lo que XP define
historias de extensin que indican futuros cambios seguros.
Refactorizacin.

Esta es sin duda la parte ms difcil de XP. Con las nuevas iteraciones, la
actual representacin de la base de conocimiento debe ser refactorizada
o reestructurada para mantener representada todo el conocimiento que
se genera en cada iteracin. El reto de modificar la estructura existente
de un sistema de software para representar el total de la base de
conocimientos es la filosofa del mantenimiento del software. El
problema puede encontrarse en que la actual estructura de
conocimiento contradice con la nueva que se genera.
Pruebas.
La metodologa XP exige a una continua poltica de pruebas de todo el
cdigo que se produce, as mismo, pruebas de integracin de cada
nueva funcionalidad en el sistema y pruebas globales. Podemos decir
que las pruebas tienen una alta importancia en XP.
Programacin en parejas.
Es la caracterstica ms famosa de XP. Una persona sola es incapaz de
ver sus fallos, por lo que XP recomienda que los trabajos se realicen en
parejas, uno ejecuta la tarea y otro comprueba lo que est desarrollando.
Propiedad colectiva.
Adems de la programacin en parejas, XP ensalza la propiedad
colectiva de todo el trabajo, incluyendo el cdigo.
Integracin continua.
Los cortos ciclos, el desarrollo iterativo y la constante refactorizacin
hacen necesario que todo el sistema se integre diariamente. Esto
proporciona resultados diarios sobre las pruebas de integracin.
Limitacin de las horas de trabajo seminal.
Para mejorar el trabajo de los desarrolladores, las horas de trabajo a la
semana deben estar limitadas. La motivacin y el cansancio del grupo
de trabajo pueden hacer que el proyecto no se ejecute correctamente.
En el lado del cliente.
XP intenta romper con las barreras entre clientes y desarrolladores,
acercndolos para mejorar su comunicacin. Para resolver los problemas
del cliente, este debe estar motivado dentro del grupo de trabajo, as
como el grupo de trabajo debe conocer bien el dominio del cliente.
Estndares de cdigo.

XP tambin recomienda incluir estndares de cdigo.

Crystals
Comparten con XP una orientacin humana, pero se centra en las personas de
forma diferente. Explora una metodologa menos disciplinada cuyos principios
se indican a continuacin:
Se centra en las personas en lugar de en los procesos: los procesos
(herramientas, productos de su trabajo, etc.) slo existen para apoyar la
capacidad de comprensin humana.
Flexibilidad del mtodo
El mtodo debe adaptarse a los diferentes proyectos, no solo por lo que rodea
a los proyectos, sino porque cada proyecto es en esencia diferente y puede
requerir diferentes procesos.
Productos intermedios de trabajo puede reducirse en nmero, tamao y
complejidad: el cdigo de prueba y el producto proporcionan un canal de
comunicacin ms ricos que los documentos secundarios en papel.
El proyecto necesita menos control cuando cobra impulso.
El desarrollo es cclico; tanto aprendizaje como produccin.
La entrega del trabajo software se deber regular cada 2 o 3 meses.
Participacin directa del cliente en el proyecto.
Los productos de trabajo como: requisitos, casos de uso, pruebas de interfaz de
usuario, modelado de objetos, etc. Se deja a la eleccin del grupo de trabajo,
en funcin de la naturaleza del proyecto y de sus requerimientos.
Adaptative Software Development
Desarrollada por JimHighsmith y Sam Bayer a comienzos de 1990 y queda
referenciada en el libro Adaptive SoftwareDevelopment (Highsmith, 2000).
Al igual que otras metodologas giles, su funcionamiento es cclico y reconoce
que en cada iteracin se producirn cambios e incluso errores.
ASD utiliza un "cambio orientado hacia el ciclo de vida", que tiene tres
componentes:
Especular o explorar las opciones.
Cclicamente colaborar utilizando una variedad de habilidades y capacidades
del equipo para "crecer" la comprensin del sistema y de su solucin.

Aprender o mejor extraer lo que se ha aprendido para permitir que los

conocimientos se apliquen al sistema.
Estos componentes definen las siguientes actividades:
Especular.
Una primera fase de iniciacin para establecer los principales objetivos y metas
del proyecto en su conjunto y comprender las limitaciones (zonas de riesgo)
con las que operar el proyecto.
Es ASD se realizan estimaciones de tiempo sabiendo que pueden sufrir
desviaciones. Sin embargo, estas son necesarias para la correcta atencin de
los trabajadores que se mueven dentro de plazos de forma que puedan
priorizar sus tareas.
Se decide el nmero de iteraciones para consumir el proyecto, prestando
atencin a las caractersticas que pueden ser utilizadas por el cliente al final de
la iteracin. Son por tanto necesarios, marcar objetivos prioritarios dentro de
las mismas iteraciones.
Estos pasos se puede volver a examinar varias veces antes de que el equipo y
los clientes estn satisfechos con el resultado.
Colaborar.
Es la fase donde se centra la mayor parte del desarrollo manteniendo
una componente cclica. Un trabajo importante es la coordinacin que
asegure que lo aprendido por un equipo se transmite al resto y no tenga
que volver a ser aprendido por los otros equipos.
Aprender.
La ltima etapa termina con una serie de ciclos de colaboracin, su
trabajo consiste en capturar lo que se ha aprendido, tanto positivo como
negativo. Es un elemento crtico para la eficacia de los equipos.
JimHighsmith identifica cuatro tipos de aprendizaje en esta etapa:
Calidad del producto desde un punto de vista del cliente.
Es la nica medida legtima de xito, pero adems, dentro de las
metodologas giles, los clientes tienen un valor importante.
Calidad del producto desde un punto de vista de los desarrolladores.
Se trata de la evaluacin de la calidad de los productos desde un punto
de vista tcnico. Ejemplos de esto incluyen la adhesin a las normas y
objetivos conforme a la arquitectura.

La gestin del rendimiento.

Este es un proceso de evaluacin para ver lo que se ha aprendido
mediante el empleo de los procesos utilizados por el equipo.
Situacin del proyecto.
Como paso previo a la planificacin de la siguiente iteracin del
proyecto, es el punto de partida para la construccin de la siguiente
serie de caractersticas.

Scrum
Desarrollado por Ken Schwaber y Jeff Sutherland y debidamente documentado
en libro Agile Software DevelopmentwithScrum (Schwaber, 2001).
Scrum se basa en ciclos de 30 das denominados Sprints, conformados por tres
fases de planificacin, desarrollo y monitorizacin. Las tres etapas se
denominan pre-Sprint, Sprint y Post-Sprint.
Pre-Sprint.
Antes de iniciar esta fase es necesario definir el ProductBacklog. Este
documento es responsabilidad del cliente y en l comentar y priorizar
las caractersticas del producto que necesite.
A partir de los datos del cliente, en esta primera fase se realiza la
planificacin de los elementos que esperan ser completados, tanto
funciones del usuario y tecnologa como arquitectura del sistema.
Sprint.
En esta fase se ejecutan las tareas identificadas permitiendo que los
grupos se gestionen de forma autnoma. Una caracterstica destacada
es la reunin diaria scrum, una reunin informal donde se comenta sobre
la planificacin y el progreso que tiene el proyecto. En ella deben
intervenir todas las personas involucradas en el proyecto:
desarrolladores y usuarios.
Durante los ciclos Sprint no se permiten modificaciones de la
funcionalidad del producto, para ofrecer a los grupos de trabajo un
entorno estable.
Post-Sprint.

Al final de cada ciclo se examinan los logros y deficiencias que se

produjeron. Y por otro lado, el cliente comprueba la funcionalidad del
producto provisional.

Feature-DrivenDevelopment (FDD)
Desarrollado por Jeff De Luca y Peter Coad, para ejecutar un proyecto de un
banco en Singapur a finales de 1990; antes el proyecto fue otorgado a una
gran consultora que no lo finaliz, generando enormes cantidades de
documentacin pero no de cdigo.
FDD est documentado en el libro A Practical Guide toFeatureDrivenDevelopment (Palmer, 2002).
FDD tiene un par de caractersticas distintivas que hacen que sea de gran
inters:

Es uno de los pocos mtodos diseados a partir del desarrollo de un gran

sistema, y muestra algunas de las cuestiones relativas a la escalabilidad.
No est centrada en el cdigo como otros mtodos; los trabajos tambin
se centran en realizar un modelado.
Por ltimo FDD utiliza un modelo de cinco etapas permitiendo cambios
en el proyecto durante su desarrollo y como en otros mtodos giles,
flexibilizando las fases.

Desarrollar un modelo general.

En esta primera etapa se desarrolla el modelado general del sistema sin
entrar en detalles. Los detalles son pospuestos para fases posteriores. El
propsito de esta etapa es crear una base para la planificacin del
proyecto.
Construir Caractersticas.
A partir del modelo y las prestaciones que necesita el cliente se genera
la lista de caractersticas del sistema. Se utiliza un enfoque denominado
arriba-abajo, donde se van descomponiendo las funciones solicitadas por
el cliente.
Plan de Reportaje.
El listado de caractersticas es utilizado por el equipo de planificacin de
desarrollo para priorizarlas y definir las funcionalidades del sistema al
finalizar cada ciclo.
Diseo de Reportaje.

Conjuntos de caractersticas relacionadas se integran en paquetes que

sern las unidades que despus se traducirn en cdigo.
Construir por Caracterstica.
Cada equipo completa sus caractersticas asignadas implementando las
clases y mtodos, escribiendo e inspeccionando el cdigo, generando
pruebas, e integrando todo a nivel de sistema.

http://ingenieriasoftware.wikispaces.com/%C3%81giles+o+Poco+pesadas