Metodologas.

Las metodologas han evolucionado de manera significativa. Permitiendo as el xito o el

fracaso de muchos de los sistemas desarrollados para distintas reas.
Algunas de las metodologas tradicionales ms utilizadas para el desarrollo de software han
sido, la denominada proceso personal de software (PSP) y la proceso en equipo para el
software TSP. El TSP toma sus fundamentos en que los ingenieros deben de dar a conocer
bien su trabajo y que puedan implementar un plan para poderlo realizar mejor, cuando el
plan se implementa, pueden ahorrarse tiempo en realizar el trabajo y por ende generar
productos de calidad. El TSP contempla dos componentes principales:
1) Creacin de equipo
2) Trabajo en equipo o componente de gestin.
El TSP es una metodologa para dirigir el desarrollo de software adems de establecer un
entorno donde el trabajo efectivo de equipo sea normal y natural. En donde involucra a los
ingenieros a desarrollar un trabajo en equipo. El desarrollo del (TSP) toma sus bases en la
estrategia de calidad que propuso W. Edwards Deming (1982), con las etapas de planear,
hacer, verificar y actuar. Y J.M. Juran (1988). El TSP ofrece un contexto disciplinado para
el trabajo de la ingeniera del software. La motivacin principal es que los ingenieros
siguiendo esta metodologa pueden hacer un excelente trabajo. Los ingenieros deben estar
bien capacitados, bien entrenados y deben ser bien dirigidos por un miembro calificado que
entienda bien la metodologa del TSP. El objetivo principal del TSP es guiar debidamente a
sus equipos de ingenieros. El TSP proporciona un proceso operacional definido para guiar a
los ingenieros y administradores a travs de diferentes pasos para la formacin de equipos
de trabajo.
Antes de que los miembros del equipo de trabajo participen en el equipo de TSP, deben
saber cmo organizar bien su trabajo. Se requiere que el equipo o el personal se encuentre
entrenado primero con el Personal Software Process (PSP). Esto le permite a los ingenieros
obtener el conocimiento en saber cmo crear un plan detallado, reuniendo y usando
procesos de datos, usando valores obtenidos para seguir un proyecto en donde puedan
medir y dirigir la calidad del producto. El objetivo del PSP es poner a los profesionales de
software a cargo de su trabajo y para que se sientan personalmente responsables de la
calidad de los productos que producen. PSP puede trabajar a la par con los objetivos de la
metodologa (TSP) son:
1) Proporcionar un entorno de equipo que apoya el trabajo de la PSP
2) Construir y mantener un equipo autodirigido.
PSP y TSP son potentes herramientas que proporcionan los conocimientos necesarios, la
disciplina y el compromiso necesarios para los proyectos de software exitoso. Se sabe que
en nuestro pas para que se pueda producir software con calidad se debe de adoptar un nivel
de madurez de procesos alto, es decir, que sea equiparable a los niveles internacionales,
esto es a travs del CMMI (Capability Maturity Model Integration), pero es difcil
implementarlo en organizaciones pequeas. En Mxico se cuenta con la norma mexicana

basada en MoProsoft (Modelo de Procesos para la Industria del Software), pero esta se
centra en los procesos de las organizaciones pero no en las personas, que son los ms
importantes para que ellas funcionen. En Mxico no solamente se debe incrementar el nivel
de madurez en los procesos de la industria de Software, si no que, se debe incluir el
mejoramiento del elemento bsico que sustente la industria, que son las personas.
Con PSP, los desarrolladores utilizan procesos bien definidos y medibles. Se toma
informacin de tamao, tiempo y defectos al momento de realizar el trabajo. Se utilizan los
datos para: planear y monitorear el trabajo, as como administrar la calidad de los productos
que se producen y medir el desempeo. TSP ha permitido resolver problemas tpicos de
negocio: como predecir el costo y tiempo, mejorar la productividad y establecer ciclos de
desarrollo para generar la mejora en la calidad de los productos. PSP/TSP mejoran el
desempeo tanto de equipos como de individuos; es disciplinado y dirigida en todo su
desarrollo a la planeacin; provee beneficios inmediatos y medibles; acelera las iniciativas
de mejora de los procesos organizacionales. Con TSP, los equipos encuentran y reparan
defectos en etapas tempranas del proceso de desarrollo. Esto reduce de manera importante
el tiempo de pruebas.

Metodologas Agiles
Aunque los creadores e impulsores de las metodologas giles ms populares han suscrito el
manifiesto gil y coinciden con los principios enunciados anteriormente, cada metodologa
tiene caractersticas propias y hace hincapi en algunos aspectos ms especficos. A
continuacin se resumen dichas metodologas giles

SCRUM. Desarrollada por Ken Schwaber, Jeff Sutherland y Mike Beedle. Define
un marco para la gestin de proyectos, que se ha utilizado con xito durante los
ltimos 10 aos. Est especialmente indicada para proyectos con un rpido cambio
de requisitos. Sus principales caractersticas se pueden resumir en dos. El desarrollo
de software se realiza mediante iteraciones, denominadas sprints, con una duracin
de 30 das. El resultado de cada sprint es un incremento ejecutable que se muestra al
cliente. La segunda caracterstica importante son las reuniones a lo largo proyecto.
stas son las verdaderas protagonistas, especialmente la reunin diaria de 15
minutos del equipo de desarrollo para coordinacin e integracin.

Crystal Methodologies. Se trata de un conjunto de metodologas para el desarrollo

de software caracterizadas por estar centradas en las personas que componen el
equipo (de ellas depende el xito del proyecto) y la reduccin al mximo del
nmero de artefactos producidos. Han sido desarrolladas por Alistair Cockburn. El
desarrollo de software se considera un juego cooperativo de invencin y
comunicacin, limitado por los recursos a utilizar. El equipo de desarrollo es un
factor clave, por lo que se deben invertir esfuerzos en mejorar sus habilidades y

destrezas, as como tener polticas de trabajo en equipo definidas. Estas polticas

dependern del tamao del equipo, establecindose una clasificacin por colores,
por ejemplo Crystal Clear (3 a 8 miembros) y Crystal Orange (25 a 50 miembros).

Dynamic Systems Development Method (DSDM). Define el marco para

desarrollar un proceso de produccin de software. Nace en 1994 con el objetivo el
objetivo de crear una metodologa RAD unificada. Sus principales caractersticas
son: es un proceso iterativo e incremental y el equipo de desarrollo y el usuario
trabajan juntos. Propone cinco fases: estudio viabilidad, estudio del negocio,
modelado funcional, diseo y construccin, y finalmente implementacin. Las tres
ltimas son iterativas, adems de existir realimentacin a todas las fases.

Adaptive Software Development(ASD). Su impulsor es Jim Highsmith. Sus

principales caractersticas son: iterativo, orientado a los componentes software ms
que a las tareas y tolerante a los cambios. El ciclo de vida que propone tiene tres
fases esenciales: especulacin, colaboracin y aprendizaje. En la primera de ellas se
inicia el proyecto y se planifican las caractersticas del software; en la segunda
desarrollan las caractersticas y finalmente en la tercera se revisa su calidad, y se
entrega al cliente. La revisin de los componentes sirve para aprender de los errores
y volver a iniciar el ciclo de desarrollo.

Feature-Driven Development(FDD) . Define un proceso iterativo que consta de 5

pasos. Las iteraciones son cortas (hasta 2 semanas). Se centra en las fases de diseo
e implementacin del sistema partiendo de una lista de caractersticas que debe
reunir el software. Sus impulsores son Jeff De Luca y Peter Coad.

Lean Development(LD) . Definida por Bob Charettes a partir de su experiencia en

proyectos con la industria japonesa del automvil en los aos 80 y utilizada en
numerosos proyectos de telecomunicaciones en Europa. En LD, los cambios se
consideran riesgos, pero si se manejan adecuadamente se pueden convertir en
oportunidades que mejoren la productividad del cliente. Su principal caracterstica
es introducir un mecanismo para implementar dichos cambios.

compara las distintas aproximaciones giles en base a tres parmetros: vista del sistema
como algo cambiante, tener en cuenta la colaboracin entre los miembros del equipo y
caractersticas ms especficas de la propia metodologa como son simplicidad,
excelencia tcnica, resultados, adaptabilidad, etc. Tambin incorpora como referencia
no gil el Capability Madurity Model (CMM).

CM
M

AS
D

Crysta
l

DSD
M

FD
D

LD

Scru
m

XP

Sistema como algo

cambiante

Colaboracin

-Resultados

-Simplicidad

-Adaptabilidad

-Excelencia tcnica

-Prcticas de
colaboracin

Media CM

2.2

4.4

4.4

3.6

3.8

3.6

4.2

4.4

Media Total

1.7

4.8

4.5

3.6

3.6

3.9

4.7

4.8

Caractersticas
Metodologa (CM)

Tabla 1. Ranking de agilidad (Los valores ms altos representan una mayor

agilidad)

Como se observa en la Tabla 1, todas las metodologas giles tienen una significativa
diferencia del ndice de agilidad respecto a CMM y entre ellas destacan ASD, Scrum y XP
como las ms giles.