Metodologas Para El Desarrollo Del Software

Resumen
En ingeniera de software es un marco de trabajo usado para estructurar,
planificar y controlar el proceso de desarrollo en sistemas de informacin.
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 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, esta estrategia fue propuesta por
W. Edwards Deming, con las etapas de planear, hacer, verificar y actuar y por
J.M. Juran.
El TSP contempla dos componentes principales:
1) Creacin de equipo
2) Trabajo en equipo o componente de gestin.
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 auto dirigido.
Una metodologa de desarrollo de software se refiere a un framework que es
usado para estructurar, planear y controlar el proceso de desarrollo en sistemas
de informacin.
El framework para metodologa de desarrollo de software consiste en:
Una filosofa de desarrollo de programas de computacin con el enfoque del
proceso de desarrollo de software.
Herramientas, modelos y mtodos para asistir al proceso de desarrollo de
software.
Lnea del Tiempo Metodologas de Desarrollo de Software.
El desarrollo de los sistemas tradicionales de ciclo de vida se origin en la
dcada de 1960 donde la idea principal era continuar el desarrollo de los
sistemas de informacin en torno a las actividades resueltas pesadas para el
procesamiento de datos y rutinas de clculo.

1970

Programacin estructurada desde 1969

Programacin estructurada Jackson desde 1975

1980

Structured Systems Analysis and Design Methodology (SSADM) desde

1980
Structured Analysis and Design Technique (SADT) desde 1980
Ingeniera de la informacin (IE/IEM) desde 1981

1990

Rapid application development (RAD) desde 1991.

Programacin orientada a objetos (OOP) a lo largo de la dcada de los
90's
Virtual finite state machine (VFSM) desde 1990s
Dynamic Systems Development Method desarrollado en UK desde 1995.
Scrum (desarrollo), en la ltima parte de los 90's

Nuevo milenio

Programacin extrema desde 1999

Enterprise Unified Process (EUP) extensiones RUP desde 2002
Rational Unified Process (RUP) desde 2003.
Constructionist design methodology (CDM) desde 2004 por Kristinn R.
Thrisson
Agile Unified Process (AUP) desde 2005 por Scott Ambler

Tipos De Metodologas
Metodologas tradicionales

Desarrollo de sistemas de Jackson (JSD):Es un mtodo desarrollado

que cubre el ciclo de vida del software pude ser directo o que provee un
framework con tcnicas ms especializadas dividindolo en 3 etapas:
Anlisis: con entity/action
Diseo: the initial model step, function step, and system timing
step.
Realizacin: El Paso de implementacin
Ingeniera de la informacin: Es un software de la ingeniera que ayuda a
crear y desarrollar sistemas de informacin.

 Structured System Analysis and Design Method (SSADM): Este mtodo

tambin nos ayuda a desarrollar y crear sistemas de informacin.
Metodologa METRICA, promovida por el Ministerio de las
Administraciones Pblicas.
METODOLOGAS GILES
En febrero de 2001, tras una reunin celebrada en Utah-EEUU, nace el trmino
gil aplicado al desarrollo de software. Su objetivo fue esbozar los valores y
principios que deberan permitir a los equipos desarrollar software rpidamente
y respondiendo a los cambios que puedan surgir a lo largo del proyecto.
Se pretenda ofrecer una alternativa a los procesos de desarrollo de software
tradicionales, caracterizados por ser rgidos y dirigidos por la documentacin
que se genera en cada una de las actividades desarrolladas.
Tras una reunin se cre The Agile Alliance3, el punto de partida fue el
Manifiesto gil, un documento que resume la filosofa gil.
Segn el Manifiesto se valora:

Al individuo y las interacciones del equipo de desarrollo sobre el proceso

y las herramientas.
La regla a seguir es no producir documentos a menos que sean
necesarios de forma inmediata para tomar un decisin importante.
Estos documentos deben ser cortos y centrarse en lo fundamental.
Se propone que exista una interaccin constante entre el cliente y el
equipo de desarrollo.
Responder a los cambios ms que seguir estrictamente un plan.

Los valores anteriores inspiran doce principios del manifiesto que son:
I.
II.
III.

IV.
V.

VI.
VII.

La prioridad es satisfacer al cliente mediante tempranas y continuas

entregas de software que le aporte un valor.
Dar la bienvenida a los cambios. Se capturan los cambios para que el
cliente tenga una ventaja competitiva.
Entregar frecuentemente software que funcione desde un par de
semanas a un par de meses, con el menor intervalo de tiempo posible
entre entregas.
La gente del negocio y los desarrolladores deben trabajar juntos a lo
largo del proyecto.
Construir el proyecto en torno a individuos motivados. Darles el entorno
y el apoyo que necesitan y confiar en ellos para conseguir finalizar el
trabajo.
El dilogo cara a cara es el mtodo ms eficiente y efectivo para
comunicar informacin dentro de un equipo de desarrollo.
El software que funciona es la medida principal de progreso.

VIII.

IX.
X.
XI.
XII.

Los procesos giles promueven un desarrollo sostenible. Los

promotores, desarrolladores y usuarios deberan ser capaces de
mantener una paz constante.
La atencin continua a la calidad tcnica y al buen diseo mejora la
agilidad.
La simplicidad es esencial.
Las mejores arquitecturas, requisitos y diseos surgen de los equipos
organizados por s mismos.
En intervalos regulares, el equipo reflexiona respecto a cmo llegar a ser
ms efectivo, y segn esto ajusta su comportamiento.

XIII.
PROGRAMACIN EXTREMA (EXTREME PROGRAMMING, XP)
Es una metodologa gil centrada en potenciar las relaciones interpersonales
como clave para el xito en desarrollo de software, promoviendo el trabajo en
equipo, preocupndose por el aprendizaje de los desarrolladores, y propiciando
un buen clima de trabajo. XP se define como especialmente adecuada para
proyectos con requisitos imprecisos y muy cambiantes, y donde existe un alto
de riesgo tcnico. Los principios y prcticas son de sentido comn pero
llevadas al extremo, de ah proviene su nombre y su creador es Kent Beck.
A continuacin presentaremos las caractersticas esenciales de XP
organizadas en los tres apartados siguientes: historias de usuario, roles,
proceso y prcticas.

Roles XP
Los roles de acuerdo con la propuesta original de Beck son:
Programador. El programador escribe las pruebas unitarias y produce el
cdigo del sistema.
Cliente. Escribe las historias de usuario y las pruebas funcionales para
validar su implementacin. Adems, asigna la prioridad a las historias de
usuario y decide cules se implementan en cada iteracin centrndose
en aportar mayor valor al negocio.
Encargado de pruebas (Tester). Ayuda al cliente a escribir las pruebas
funcionales. Ejecuta las pruebas regularmente, difunde los resultados en
el equipo y es responsable de las herramientas de soporte para pruebas.
Encargado de seguimiento (Tracker). Proporciona realimentacin al
equipo. Verifica el grado de acierto entre las estimaciones realizadas y el
tiempo real dedicado, para mejorar futuras estimaciones. Realiza el
seguimiento del progreso de cada iteracin.

 Entrenador (Coach). Es responsable del proceso global. Debe proveer

guas al equipo de forma que se apliquen las prcticas XP y se siga el
proceso correctamente.
Consultor. Es un miembro externo del equipo con un conocimiento
especfico en algn tema necesario para el proyecto, en el que puedan
surgir problemas.
Gestor (Big boss). Es el vnculo entre clientes y programadores, ayuda a
que el equipo trabaje efectivamente creando las condiciones adecuadas.
Su labor esencial es de coordinacin.

Proceso XP
El ciclo de desarrollo consiste (a grandes rasgos) en los siguientes pasos:
1. El cliente define el valor de negocio a implementar.
2. El programador estima el esfuerzo necesario para su implementacin.
3. El cliente selecciona qu construir, de acuerdo con sus prioridades y las
restricciones de tiempo.
4. El programador construye ese valor de negocio.
5. Vuelve al paso 1.
El ciclo de vida ideal de XP consiste de seis fases: Exploracin, Planificacin
de la Entrega (Release), Iteraciones, Produccin, Mantenimiento y Muerte del
Proyecto.

Prcticas XP
La principal suposicin que se realiza en XP es la posibilidad de disminuir la
mtica curva exponencial del costo del cambio a lo largo del proyecto, lo
suficiente para que el diseo evolutivo funcione. Esto se consigue gracias a las
tecnologas disponibles para ayudar en el desarrollo de software y a la
aplicacin disciplinada de las siguientes prcticas.

El juego de la planificacin. Hay una comunicacin frecuente el cliente y

los programadores.
Entregas pequeas. Producir rpidamente versiones del sistema que
sean operativas.
Metfora. El sistema es definido mediante una metfora o un conjunto
de metforas compartidas por el cliente y el equipo de desarrollo. Una
metfora es una historia compartida que describe cmo debera
funcionar el sistema.
Diseo simple. Se debe disear la solucin ms simple que pueda
funcionar y ser implementada en un momento determinado del proyecto.

Pruebas. La produccin de cdigo est dirigida por las pruebas unitarias

stas son establecidas por el cliente antes de escribirse el cdigo y son
ejecutadas constantemente ante cada modificacin del sistema.
Refactorizacin (Refactoring). Es una actividad constante de
reestructuracin del cdigo con el objetivo de remover duplicacin de
cdigo.
Programacin en parejas. Toda la produccin de cdigo debe realizarse
con trabajo en parejas de programadores.
Propiedad colectiva del cdigo. Cualquier programador puede cambiar
cualquier parte del cdigo en cualquier momento.
Integracin contina. Cada pieza de cdigo es integrada en el sistema
una vez que est lista.
40 horas por semana. Se debe trabajar un mximo de 40 horas por
semana.
Cliente in-situ. El cliente tiene que estar presente y disponible todo el
tiempo para el equipo.
Estndares de programacin. XP enfatiza que la comunicacin de los
programadores es a travs del cdigo, con lo cual es indispensable que
se sigan ciertos estndares de programacin para mantener el cdigo
legible.

OTRAS METODOLOGAS GILES

SCRUM: Impulsada por Ken Schwaber, Jeff Sutherland y Mike Beedle.
Sus dos caractersticas principales son:

El desarrollo de software que se realiza mediante iteraciones

denominadas sprint.

Reuniones a lo largo del proyecto diarias durante 15 minutos.

Crystal Methodologies: Conjunto de metodologas para el desarrollo del

software caracterizadas por estar centradas en las personas que componen el
equipo donde se invierte la fuerza para mejorar en habilidades y destreza. Esta
metodologa fue impulsada por Alistar Cockburn.
Dynamic Systems Development Method: Nace en 1994 con el objetivo de
crear una metodologa RAD unificada.
Su principal caracterstica es que tiene un proceso iterativo e incremental
donde el equipo de desarrollo y usuario trabajan juntos.
Sus 5 fases son: Estudio, viabilidad , estudio del negocio , modelo funcional,
diseo, construccin e implementacin.

Adaptive Software Development: Impulsada por Jim Highsmith, Orientado a

los componentes del software ms que a las tareas y es tolerante a los
cambios.
Propone un ciclo de vida de 3 fases

Especulacin: Se inicia el proyecto y se planifican las caractersticas

del software.

Colaboracin: En esta se desarrollan las caractersticas.

Aprendizaje: Se revisa su calidad y se entrega al cliente.

Feature Driven Development: Las iteraciones son cortas y se centran en las

fases de diseo e implementacin del sistema partiendo de una lista de
caractersticas que rene el software. Esta metodologa fue impulsada por Jeff
De Luca y Peter Coad.
Lean Development : Impulsada por Bob Charetts, su principal caracterstica
es introducir un mecanismo para implementar cambios , cambios que se
consideraban riesgosos pero no si se manejan adecuadamente pueden
convertirse en oportunidades para mejorar la productividad del cliente.
Cosas que NO son metodologas de desarrollo del software.

La "Programacin estructurada" o la "Programacin Orientada a

Objetos" son paradigmas o modelos de programacin. Indican pautas de
comportamiento en los sistemas de programacin.
Los trminos "Ciclo de vida en espiral", "Ciclo de vida incremental", "en
Cascada", "con prototipo" estos son esquemas generales de
organizacin en las tareas del ciclo de vida, unas con respecto a otras y
con respecto a otros aspectos como el tiempo.
El UML no le indica a nadie la manera de realizar las cada tarea en un
proyecto concreto: tan solo es una herramienta para expresar ideas...
as pues... NO ES UNA METODOLOGA.