Escolar Documentos
Profissional Documentos
Cultura Documentos
Introduccin
Segn la filosofa de desarrollo, las metodologas se pueden clasificar en dos grupos, las
metodologas tradicionales, que se basan en una fuerte planificacin durante todo el
desarrollo y un ciclo de vida ms tradicional, y las metodologas giles, en las que el desarrollo
de software es incremental, cooperativo, sencillo y adaptado.
Las metodologas tradicionales son denominadas, como metodologas pesadas. Centran su
atencin en llevar una documentacin exhaustiva de todo el proyecto y en cumplir con un plan
de proyecto, definido en la fase inicial del desarrollo del proyecto. Otra de las caractersticas
ms importantes dentro de este enfoque, son los altos costes al implementar un cambio y la
falta de flexibilidad. Las metodologas tradicionales se focalizan en la documentacin,
planificacin y procesos (plantillas, tcnicas de administracin, revisiones, etc.).
MTODOS Y TCNICAS PARA LA GESTIN DE PROYECTOS SOFTWARE
Pgina 30
Las metodologas giles nacen como respuesta a los problemas que puedan ocasionar las
metodologas tradicionales y se basa en dos aspectos fundamentales, retrasar las decisiones y
la planificacin adaptativa. Destacan en la adaptabilidad de los procesos de desarrollo. Estas
metodologas destacan que la capacidad de respuesta a un cambio es ms importante que el
seguimiento estricto de un plan.
A continuacin en este captulo, repasaremos las siguientes metodologas:
METODOLOGAS TRADICIONALES
MTRICA V3
PRINCE2
SSADM
MERISE
METODOLOGAS GILES
Extreme-Programming XP
Scrum
Crystal Methodologies
Adaptive Software Development
Feature-Driven Development (FDD)
Dynamic Systems Development Method (DSDM)
Lean software development
Tabla 4 Metodologas
3.2.
Metodologas tradicionales
3.2.1. MTRICA V3
3.2.1.1.
Introduccin
Pgina 31
En julio del 2001 se liber la V.3 en la que se han tenido en cuenta las diferentes
tecnologas actuales (cliente/servidor, orientacin a objetos, reutilizacin, etc.). Esta
versin aporta un conjunto de procesos (definidos en la metodologa como interfaces)
orientados a la organizacin y como apoyo al propio proceso de desarrollo. Entre los
interfaces destaca uno especfico para la gestin de los proyectos y que se estudia ms
en detalle.
3.2.1.2.
Descripcin
Tambin incluye un conjunto de interfaces que definen una serie de actividades de tipo
organizativo o de soporte al proceso de desarrollo y a los productos, que se debern aplicar
como apoyo a la ejecucin de los procesos principales de la metodologa y para complementar
y garantizar el xito del proyecto
Las interfaces incluidas en la metodologa son:
Pgina 32
Procesos
Planificacin de Sistemas de
Informacin
Desarrollo de Sistemas de
Informacin
Mantenimiento de Sistemas de
Informacin
PSI
MSI
EVS (Estudio de la Viabilidad del Sistema)
ASI (Anlisis del Sistema de Informacin)
DSI (Diseo del Sistema de Informacin)
CSI (Construccin del Sistema de
Informacin)
IAS (Implantacin y Aceptacin del Sistema)
Interfaces
Gestin de
Proyectos
Seguridad
SEG
GP
Aseguramiento Gestin de la
de la calidad
Configuracin
CAL
GC
Objetivo:
Tiene como objetivo proporcionar
proporcionar un marco estratgico de referencia para los
Sistemas de Informacin de un determinado mbito de la organizacin.
Desarrollo:
Estudio de las necesidades de informacin
informacin de los procesos de la
organizacin afectados por el Plan de Sistemas, con el fin de definir los
requisitos generales y obtener modelos conceptuales de informacin.
Pgina 33
Pgina 34
Desarrollo:
En primer lugar se describe inicialmente el Sistema de Informacin. Se
delimita su alcance, se genera un catlogo de requisitos generales y se
describe el sistema mediante unos modelos iniciales de alto nivel.
Se recogen de forma detallada los requisitos funcionales que el
Sistema de Informacin debe cubrir, catalogndolos. Adems, se
identifican los requisitos no funcionales del sistema (las facilidades
que ha de proporcionar el sistema, y las restricciones en cuanto a
rendimiento, frecuencia de tratamiento, seguridad, etc.).
Se identifican los subsistemas de anlisis, y se elaboran los modelos de
Casos de Uso y de Clases, en desarrollos orientados a objetos, y de
Datos y Procesos en desarrollos estructurados.
Finalizados los modelos, se realiza un anlisis de consistencia que
puede forzar la modificacin de algunos de los modelos obtenidos y,
posteriormente, se elabora el producto Especificacin de Requisitos
Software.
Se inicia la especificacin del Plan de Pruebas, que se completar en el
proceso Diseo del Sistema de Informacin (DSI).
Resultados:
Se obtiene el catlogo de requisitos del sistema a implementar, as
como los estndares y normas a tener en cuenta, la descripcin
general del entorno tecnolgico y la especificacin de la interfaz de
usuario.
Si el sistema a desarrollar sigue un enfoque Estructurado, adems hay
que aadir el plan de migracin y carga inicial de datos, el contexto del
sistema, la matriz de procesos/localizacin geogrfica, la descripcin
de interfaz con otros sistemas, el modelo de procesos y modelo lgico
de datos normalizado.
Si se sigue un enfoque Orientado a Objetos, hay que aadir la
descripcin de subsistemas de anlisis, la descripcin de interfaces
entre subsistemas, el modelo de clases de anlisis, el comportamiento
de clases de anlisis y el anlisis de la realizacin de los casos de uso.
Pgina 35
Desarrollo:
Las actividades de este proceso se agrupan en dos grandes bloques:
En un primer bloque se obtiene el diseo de detalle del
Sistema de Informacin que comprende la particin fsica,
independiente de un entorno tecnolgico concreto, la
organizacin en subsistemas de diseo, la especificacin del
entorno tecnolgico sobre el que se despliegan dichos
subsistemas y la definicin de los requisitos de operacin,
administracin del sistema, seguridad y control de acceso.
El segundo bloque complementa el diseo del Sistema de
Informacin y en l se generan todas las especificaciones
necesarias para la construccin del Sistema.
Resultados:
Especificaciones de construccin relativas al propio sistema, la
descripcin tcnica del plan de pruebas, la definicin de los requisitos
de implantacin y el diseo de los procedimientos de migracin y
carga inicial, si procede.
Pgina 36
Pgina 37
Resultados:
Catlogo de peticiones de cambio, el resultado del estudio de la
peticin, la propuesta de solucin, el anlisis de impacto de los
cambios, el plan de accin para la modificacin, el plan de pruebas de
regresin, la evaluacin del cambio y la evaluacin del resultado de las
pruebas de regresin.
Pgina 38
Para el interfaz especfico de gestin de los proyectos, Mtrica v.3 aade otras tcnicas como
son:
Pgina 39
3.2.2.
3.2.2.1.
PRINCE2
Introduccin
PRINCE2 (PRojects IN Controlled Environments) [29], fue desarrollado para el gobierno del
Reino Unido y se utiliza regularmente no solo en el gobierno britnico sino tambin en el
sector privado. Actualmente es el estndar de facto en el Reino Unido.
PRINCE2 es una metodologa estructurada basada en procesos. Ofrece una gua de dominio
pblico para la aplicacin de las mejores prcticas en la gestin de los proyectos.
En 1989 la Agencia Central de Computacin y Telecomunicaciones (CCTA) desarroll la tcnica
PRINCE como un estndar para la gestin de los proyectos de telecomunicaciones del gobierno
del Reino Unido.
En 1996 se liber una versin de PRINCE2 como una metodologa genrica para la gestin de
los proyectos. La ltima versin es la edicin del 2009.
Pgina 40
3.2.2.2.
Descripcin
Procesos
Componentes
Tcnicas
PRINCE2
Figura 2 Elementos PRINCE2
Pgina 41
Direccin de
Proyecto
Puesta en
marcha
Inicio
Control de etapa
Gestin de
lmites de etapa
Cierre del
proyecto
Gestin de
entrega del
producto
Planificacin
Planificacin
Planificacin
Puesta en marcha del proyecto: Permite un inicio controlado del proyecto. Solo se
realiza al principio del ciclo de vida del proyecto y proporciona una preparacin inicial
para la gestin del resto del proyecto, as como para el control y viabilidad del
proyecto. Este proceso crea la junta del proyecto, y garantiza el acuerdo de las
necesidades de recursos.
Inicio del proyecto: Es otro proceso que solo se realiza una vez durante el ciclo de
vida del proyecto. Sirve para realizar un trazado de cmo se puede gestionar la
totalidad del proyecto, y lo plasma en un contrato, denominado documento de
inicio del proyecto (PID Project Initiation Document). El objetivo de este documento
es el establecimiento de un entendimiento comn de los elementos crticos del
proyecto, as como el acuerdo de la junta del proyecto para la primera etapa de
desarrollo del proyecto.
Direccin del proyecto: Dirige todo el proyecto y define las responsabilidades de la
junta del proyecto en la supervisin del mismo. De acuerdo con su posicin en el
diagrama del modelo de procesos, est por encima de todos e interacta con el resto
de procesos. Proporciona los mecanismos para las autorizaciones de aprobacin de
continuidad al final de cada etapa y al cierre del proyecto. Este proceso es el marco de
suministro de entradas, de recepcin de requisitos y para la toma de decisiones. Es el
nico proceso en el que acta la junta del proyecto, ya que el resto de procesos son
conducidos por el director del proyecto y el resto del equipo de proyecto.
Pgina 42
Pgina 43
Proceso de negocio
Control de cambios
Organizacin
Gestin de la
configuracin
Planes
Calidad en el
entorno del
proyecto
Controles
Pgina 44
Planificacin
Control de Cambios
Calidad
Planificacin basada en el producto: esta tcnica involucra otros tres elementos que
nos ayudan a la definicin de los productos a entregar:
Product breakdown: diagrama de los productos.
pro
Product description: descripcin detallada de (los) producto(s).
Product Flor: descripcin de la interrelacin de productos.
Aproximacin al control de cambios: esta tcnica nos garantiza someter a procesos
toda la gerencia del proyecto basada en
en tener bajo control cualquier cambio que
ocurra.
Revisiones de la calidad: esta tcnica nos ayuda a revisar los estndares ya existentes
y tambin poder buscar nuevos que puedan ser aplicados. Tambin nos ayuda a tener
procedimientos exitosos as como tener
tener un acercamiento a revisar cada uno de los
elementos y productos a entregar. En esta tcnica tambin involucra la correcta toma
de decisiones del proyecto, la gestin de proveedores y el control de la informacin.
Pgina 45
3.2.3. SSADM
3.2.3.1.
Introduccin
SSADM (Structured Systems Analysis and Design Method) [46] es una metodologa de
aproximacin en cascada para el desarrollo de sistemas de informacin y que puede ser
considerada como una de las ms metodologas estructuradas ms completas.
SSADM fue desarrollada inicialmente por Learmonth y Burchett Management Systems (LBMS)
y continuada por el Central Computing and Telecommunications Agency (CCTA) mediante la
adopcin de un mtodo de desarrollo de sistemas de informacin para el uso en los proyectos
del gobierno del Reino Unido.
Se lanz la primera versin en 1981 y en 1983 se convirti en uso obligatorio para el desarrollo
de todos los proyectos nuevos del gobierno de Reino Unido, y en 1988 fue promocionada
como un Standard abierto. En el ao 2000 CCTA renombr SSADM como Business System
Development
Actualmente, es la metodologa estndar de desarrollo de proyectos del gobierno del Reino
Unido.
3.2.3.2.
Descripcin
SSADM considera las estructuras de datos con mayor estabilidad que los procesos, y por lo
tanto, los datos forman la columna vertebral de la metodologa. De este modo, SSADM
pertenece a la familia de los mtodos orientado a los datos.
MTODOS Y TCNICAS PARA LA GESTIN DE PROYECTOS SOFTWARE
Pgina 46
SSADM cubre las tres fases fundamentales del ciclo de vida del desarrollo software: Estudio de
viabilidad, Anlisis y Diseo, pero no est diseada para realizar la implementacin y el
mantenimiento de las aplicaciones, lo que hace es suministrar la documentacin completa y
precisa para poder mantener el sistema fcilmente.
Viabilidad
Estudio de la viabilidad
Anlisis de requerimientos
Anlisis
Diseo
Diseo fsico
Implementacin
No la cubre
Mantenimiento
No la cubre
Pgina 47
Estudio de
Viabilidad
Anlisis de
requerimientos
Nivel 0. Viabilidad
Especificacin de
requerimientos
Especificacin del
sistema lgico
Diseo
Pgina 48
En relacin a las tcnicas de representacin, las ms usuales que utiliza SSADM seran las
siguientes:
Diagramas de flujo de datos (DFD): es una representacin grfica del "flujo" de datos
a travs de un sistema de informacin. Un diagrama de flujo de datos tambin se
puede utilizar para la visualizacin de procesamiento de datos.
Pgina 49
3.2.4. MERISE
3.2.4.1.
Introducin
MERISE [47] es una metodologa de la Administracin francesa, creada por iniciativa del
Ministerio de Industria Francs y desarrollada por Tardieu, Rochfeld y Colleti.
Comienza a desarrollarse en 1972, y se publica la primera versin a finales de 1976 con el
objetivo de crear una metodologa para las necesidades de la administracin francesa por
parte del CTI (Centre Technique Informatique) del Ministerio de Industria Francs.
En 1977 surgi la metodologa RACINES tratando la informatizacin como un acto estratgico
que maneja un recurso de una manera reflexiva y ordenada.
A lo largo de 1979 MERISE se orient hacia el anlisis y diseo de sistemas de informacin,
aportando un plan de trabajo y tcnicas de modelado para la fabricacin de aplicaciones
coherentes para el rea de gestin de empresas, suponiendo una interseccin entre
informtica y organizacin e integrando los sistemas as diseados en el marco comn
diseado por RACINES.
En 1982, y tambin, bajo el patrocinio del Ministerio de Industria Francs se procedi a
actualizar RACINES y a definir sus interfaces con MERISE formando un cuerpo metodolgico
completo bajo la denominacin de MERISE.
Pgina 50
3.2.4.2.
Descripcin
El ciclo de abstraccin
cin
El ciclo de decisin.
Ciclo de
Abstraccin
Ciclo de
decisin
MERISE cubre las cuatro fases fundamentales del ciclo de vida de desarrollo del software:
Estudio de viabilidad (Estudio preliminar), Anlisis, Diseo, e Implementacin. Pero no cubre
el mantenimiento de las aplicaciones, lo que hace es suministrar la documentacin completa y
precisa para poder mantener el sistema fcilmente.
Pgina 51
Viabilidad
(Estudio Preliminar)
Anlisis
Diseo
Implementacin
Mantenimiento
Estudio preliminar
Estudio detallado
Realizacin y Puesta en marcha
Diseo fsico
Implementacin
No la cubre
Estudio Preliminar
En
En esta fase se analiza la situacin existente y la propuesta de una
solucin global atendiendo a los criterios de gestin, de la organizacin
y decisiones adoptadas por el comit directivo del proyecto.
Estudio detallado
En
En esta fase se define la solucin a nivel funcional.
Realizacin y
puesta en marcha
En
En esta fase se realiza la instalacin, formacin del personal, as como
la implantacin de los medios tcnicos y organizativos y la recepcin
por parte del usuario.
Diseo fsico
Es
Es la fase donde se describe el entorno tcnico con la distribucin de
los datos en los ficheros y los tratamientos en mdulos de programas.
Implementacin
En
En esta fase se codifican los programas con sus correspondientes
pruebas.
Pgina 52
Comit director: Su funcin es fijar los objetivos y tomar las decisiones importantes en
el desarrollo del mismo, interviniendo al final de cada etapa para realizar el control y
seguimiento del proyecto y aprobando los informes de las mismas. Este equipo de
trabajo estar formado por los directivos de cada rea afectada, los responsables de
los servicios implicados, el responsable del servicio de informtica y el jefe del
proyecto.
Comit de usuarios: Su funcin es realizar un seguimiento sistematizado para la
comprobacin a lo largo del desarrollo de los cumplimientos de las actividades
asignadas, mediante la comprobacin de los diseos de las pantallas, validacin de
informes y de listados, resolucin de problemas, etc. Estar compuesto por los
responsables de los servicios afectados.
Equipo de desarrollo: Su misin es elaborar los informes y documentacin
contemplados en cada una de las fases de desarrollo, as como la realizacin de los
anlisis, programacin, pruebas, instalacin y puesta en marcha. Este equipo estar
formado por el jefe del proyecto y los analistas y programadores asignados al mismo,
as como el representante del grupo de usuarios.
Comit
director
Comit
de
usuarios
Equipo de
desarrollo
Pgina 53
3.3.
Modelo conceptual de tratamientos: Para representar las acciones a realizar sobre los
datos con el objeto de obtener los resultados previstos. Para ello, utiliza las redes
Petri.
Modelo organizativo de tratamientos: Para describir cmo se va a organizar la
ejecucin de las mismas.
Modelo operacional de tratamientos: Se parte de la descomposicin de los
procedimientos y fases anteriores y se obtienen los procedimientos manuales, las
fases en tiempo real, las fases en tiempo diferido donde se incluyen las entradas,
tratamientos y listados.
Metodologas giles
3.3.1.1.
Introduccin
La programacin extrema o eXtreme Programming (XP) fue creada por Kent Beck en 1999, a
travs de su libro Extreme Programming Explained: Embrace Change [48]. Est
especialmente diseada para el desarrollo de software.
XP es una metodologa gil centrada en la potenciacin de las relaciones interpersonales
como clave para lograr el xito. Promueve el trabajo en equipo, prestando atencin al
aprendizaje de los desarrolladores, y estableciendo un buen clima de trabajo.
XP utiliza la realimentacin continua entre el cliente y el equipo de desarrollo, comunicacin
fluida entre todos los participantes, simplicidad en las soluciones implementadas y
determinacin frente a los cambios. Los principios y prcticas que describe pueden parecer de
sentido comn, pero se llevan al extremo, de ah su nombre.
XP es especialmente adecuada para proyectos con requisitos imprecisos, cambiantes, y donde
existe un alto riesgo tcnico.
Pgina 54
3.3.1.2.
Descripcin
Historia de usuario
Roles
Proceso
Prcticas
Figura 9 Caractersticas XP
Historia de usuario: Esta tcnica se utiliza para especificar los requisitos del software.
Se trata de tarjetas de papel en las cuales el cliente describe brevemente las
caractersticas que el sistema debe tener, sean requisitos funcionales o no
funcionales.
El tratamiento de las historias de usuario es muy dinmico y flexible.
exible.
Cada historia de usuario debe ser entendible y suficientemente concreta para que los
programadores puedan
edan implementarla
im
en unas semanas.
Un ejemplo de ficha podra recoger los siguientes campos:
Fecha
Prueba Funcional
Prioridad
Estimacin tcnica
Notas
Comentarios
Tabla 11 Ficha XP
Pgina 55
Pgina 56
El cliente define
el valor de
negocio a
implementar
El programador
estima el
esfuerzo
necesario para
su
implementacin
El programador
construye ese
valor de
negocio
El cliente
selecciona qu
construir, de
acuerdo con sus
prioridades y las
restricciones de
tiempo
Pgina 57
Pgina 58
3.3.2. Scrum
3.3.2.1.
Introduccin
El concepto de Scrum [28] tiene su origen en un estudio de 1986, The New New Product
Developement Game (Hirotaka Takeuchi y Ikujiro Nonaka ). Este estudio versaba sobre los
nuevos procesos de desarrollo utilizados en productos exitosos en Japn y los Estados Unidos
(cmaras de fotos de Canon, fotocopiadoras de Xerox, automviles de Honda, ordenadores de
HP y otros).
Los equipos que desarrollaron esos productos partan de requisitos muy generales, as como
muy novedosos, y deban salir al mercado en mucho menos del tiempo del que se tard en
lanzar productos anteriores. Estos equipos seguan patrones de ejecucin de proyecto muy
similares. En este estudio se comparaba la forma de trabajo de estos equipos altamente
productivos y multidisciplinares con la colaboracin entre los jugadores de Rugby y su
formacin de Scrum (mel en espaol).
Fue ya en 1993, cuando Jeff Sutherland, John Scumniotales y Jeff McKenna concibieron,
ejecutaron y documentaron el primer Scrum para desarrollo gil en desarrollo de software,
utilizando el estudio de gestin de equipos de Takeuchi y Nonaka como base en Easel
Corporation.
Scrum fue presentado formalmente en 1995 por Je Sutherland y Ken Schwaber en el
OOPSLA95. En 2001, Schwaber y Mike Beedle describieron la metodologa en el libro Agile
Software Development with Scrum.
Actualmente existe, la Gua de Scrum (The Scrum Guide), que representa la gua de
conocimiento oficial de Scrum (Scrum Body Of Knowledge), escrita por Ken Schwaber and
Jeff Sutherland. La ltima versin data de Febrero de 2010.
Pgina 59
3.3.2.2.
Descripcin
Entrega de resultados
prioritarios en ese momento, ya compl
Gestin regular de las expectativas del cl
Resultados anticipados (time to market).
Flexibilidad y adaptacin respecto a las necesidades del cliente, cambios en el
mercado, etc.
Gestin sistemtica del Retorno de Inversin (ROI).
Mitigacin sistemtica de los
Incremento de la productividad y
Alineamiento entre el cliente y el equipo de desarrollo.
Equipo motivado.
La pila de producto es una lista priorizada de las caractersticas o requisitos que el dueo
del producto quiere que el producto tenga. A cada uno de dichos requisitos se les llama
historias de usuario o simplemente historias.
Pgina 61
Indicadores
Sprints
Un sprint es un ciclo de desarrollo durante el cual, los miembros del equipo, trabajan sobre
las historias situadas en la cima de la pila del producto.
Normalmente tiene una duracin ja de unas dos o cuatro semanas. Es importante que
dicha duracin sea ja para as poder hacer un seguimiento de cmo de productivo es el
equipo.
Pgina 62
El sprint comienza con un sprint planning. Durante el mismo se realizan scrum meetings a
diario, y al nalizar el sprint se realiza una demostracin del producto y una retrospectiva.
Durante el sprint no se deben aadir tareas a la cima de la pila de producto ni alterar las
prioridades.
Es posible, sin embargo, que durante un sprint aparezcan tareas que deban ser resueltas de
forma inmediata. Estos son las historias inesperadas y hay que procurar que surjan con la
menor frecuencia posible porque afectan muy negativamente a la productividad del equipo.
Sprint Planning
Pgina 63
Burndown Chart
El burndown chart es una grca que muestra la evolucin diaria del nmero de horas o
story points restantes para nalizar todas las tareas de ese sprint.
Es una herramienta esencial dentro de Scrum puesto que aporta mucha informacin de
forma visual.
El burndown consta de dos lneas. La primera, es una recta que representa la evolucin
terica de las horas o story points restantes para nalizar todas las historias de ese sprint.
Esta lnea estar ms inclinada conforme mayor sea la velocidad de equipo.
La segunda lnea, representa la evolucin real. Para calcular esta segunda recta, es
importante que cada miembro del equipo actualice las tareas en las que ha trabajado a
diario, indicando cuantas horas quedan para que estn terminadas. Si, conforme avanza el
sprint, observamos que la lnea real avanza por encima de la terica, signica que el
equipo avanza ms lentamente de lo esperado y tendr que trabajar ms si quiere nalizar
el sprint satisfactoriamente .Si por el contrario, se encuentra por debajo, estn
produciendo ms de lo esperado. Dado que es posible que el equipo siga trabajando sobre
la pila de producto a pesar de haber nalizado todas las historias a las que se
comprometieron para dicho sprint, es posible que para un determinado sprint, el
burndown contine por debajo de cero y nalice con un valor negativo.
Otra forma de expresar lo mismo es subiendo la lnea de la evolucin real para que
siempre quede por encima de cero. En este caso, la diferencia entre las horas o story
points a los que se ha comprometido el equipo, y las que ha producido nos lo da la
diferencia entre la lnea real y la ideal al inicio del sprint.
Pgina 64
Scrum Diario
El scrum diario es una reunin diaria en la que cada miembro del equipo responde a tres
cuestiones.
Qu hiciste ayer?
Qu vas a hacer hoy?
Hay obstculos en tu camino?
Tambin se le conoce como scrum meeting o daily scrum. Se suele celebrar de pie y no
debe durar ms de 15 minutos.
Todo el mundo est invitado, pero slo los miembros del equipo, Scrum Master y Dueo
del Producto pueden hablar.
Esta reunin favorece mucho la visibilidad sobre el proyecto y permite detectar posibles
problemas de inmediato.
Al nal de cada sprint se realiza una demostracin de las nuevas funcionalidades que se
han aadido ante el dueo del producto. De esta forma, el dueo del producto hace un
seguimiento exhaustivo y puede aadir tareas al a pila de producto antes del siguiente
sprint.
3.3.3.1.
Introduccin
Pgina 65
3.3.3.2.
Descripcin
Crystal Methodologies [5] da una importancia vital a las personas que componen el equipo de
un proyecto, y por tanto sus puntos de estudio son:
Roles
Se describen los siguientes roles:
Pgina 66
Crystal
Clear
Se
Se corresponde con el color Blanco en
la codificacin de colores de Crystal
3-8
8 personas
Crystal
Orange
Se
Se corresponde con el color Naranja
en la codificacin de colores de Crystal
25--50 personas
3.3.4.1.
Introduccin
Iterativo
Orientado a los componentes software ms que a las tareas
Tolerante a los cambios
Pgina 67
3.3.4.2.
Descripcin
Especulacin
Colaboracin
Aprendizaje
3.3.5.1.
Introduccin
FDD es una metodologa gil creada inicialmente por Jeff De Luca para satisfacer las
necesidades especficas de un proyecto de desarrollo software que deba realizarse en 15
meses con 50 personas para un gran banco de Singapur en 1997.
La descripcin de FDD apareci por primera vez en el libro Java Modeling in Color with UML
[50], en 1999. Posteriormente, en 2002, se public el libro A Practical Guide to Feature-Driven
Development [51], donde se describa de forma ms precisa la metodologa.
Se basa en un proceso iterativo con iteraciones cortas que producen un software funcional que
el cliente y la direccin de la empresa pueden ver y monitorizar.
MTODOS Y TCNICAS PARA LA GESTIN DE PROYECTOS SOFTWARE
Pgina 68
3.3.5.2.
Descripcin
Un miembro del equipo puede tener otros roles a cargo, y un solo rol puede ser compartido
por varias personas.
FDD consiste en cinco procesos secuenciales durante los cuales se disea y construye el
sistema.
La parte iterativa soporta desarrollo gil con rpidas adaptaciones a cambios en
requerimientos y necesidades del negocio.
Cada fase del proceso tiene un criterio de entrada, tareas, pruebas y un criterio de salida.
Pgina 69
Diseo por
rasgos
Construccin
por rasgos
Planeamiento
por rasgos
Construccin
d ela lista de
rasgos
Desarrollo
de un
modelo
general
Planeamiento por rasgos: Incluye la creacin de un plan de alto nivel, en el que los
conjuntos de rasgos se secuencian conforme a su prioridad y dependencia, y se asigna
a los programadores jefes.
Pgina 70
Algunos precursores del desarrollo gil sienten que FDD es demasiado jerrquico para ser un
mtodo gil, porque demanda un programador jefe, quien dirige a los propietarios de clases,
quienes dirigen equipos de rasgos.
3.3.6.1.
Introduccin
La metodologa gil DSDM [5] fue desarrollada en el Reino Unido en los aos 90 por un
consorcio de proveedores y de expertos en la materia del desarrollo de sistemas de
informacin liderado por Tony Mobbs, combinando sus experiencias de mejores prcticas.
Este consorcio es una organizacin sin nimo de lucro y proveedor independiente, que posee y
administra el framework.
En febrero de 1995 se public la primera versin, siendo la 4.2., la actual (liberada en 2006).
DSDM se centra en los proyectos TI que son caracterizados por presupuestos y agendas
apretadas. DSDM trabaja sobre problemas que ocurren con frecuencia en el desarrollo de los
sistemas de informacin, cmo tiempo, presupuesto, falta de implicacin del usuario, de la
gerencia, etc.
DSDM es un mtodo que provee un framework para el desarrollo gil de software, apoyado
con la continua implicacin del usuario en un desarrollo iterativo y creciente que sea sensible a
los requerimientos cambiantes, para desarrollar un sistema que rena las necesidades de la
empresa en tiempo y presupuesto.
Pgina 71
3.3.6.2.
Descripcin
PreProyecto
Ciclo de
Vida del
Proyecto
PostProyecto
Estudio de viabilidad
Calcular los costes
Ver si es tcnicamente viable
Asegurarse de que DSDM sea el enfoque adecuado
Estudio de negocio
Modelado del proceso del negocio
Fuerte colaboracin cliente-equipo de desarrollo.
Iteracin del modelo funcional
Refinar aspectos funcionales del negocio
Pgina 72
MoSCoW Rules: Para dar prioridades a los requisitos DSDM usa las MoSCoW rules.
Tenemos 4 clases de requisitos:
M Must Have: vitales para el proyecto
o
S Should Have: para obtener el mximo beneficio
C Could Have: deben implementarse si el tiempo lo permite
o
W Wont Have: pueden dejarse para otro momento
Prototipados: El prototipado evolutivo es una de las tcnicas en las que se basa DSDM.
Encontramos los siguientes prototipos :
Bussines
Usability
Performance
Capability
Pgina 73
3.3.7.1.
Introduccin
Lean Software Development [15] es una metodologa gil que tiene origen en el libro del
mismo nombre, escrito por Mary Poppendieck y Tom Poppendieck en el ao 2003. En l se
presentan los principios de Lean aplicados, as como un conjunto de 22 instrumentos,
herramientas y las comparaciones con otras prcticas giles
La metodologa se basa en los principios de Lean Manufacturing. Lean es la forma de producir
bienes mediante la eliminacin de despilfarros y la implantacin de un flujo, que surge como
contraposicin a la fabricacin en cadena basada en un procesado y encolamiento masivo
vigentes hasta la fecha, y es una derivacin del mtodo de produccin de Toyota (TPS).
3.3.7.2.
Descripcin
Es una metodologa gil que se basa en un proceso iterativo para la construccin del producto.
Existen siete principios en Lean Software Development que vienen de los siete principios de
Lean Thinking. No son recetas especiales para desarrollo de software, pero sin dan unas
guas muy interesantes para la forma de desarrollar software.
Estos siete principios son:
PRINCIPIOS
Eliminar los residuos
Ampliar el aprendizaje
Decidir lo ms tarde posible
Entrega rpida
Potenciar el equipo
Crear integridad
Vase en conjunto
Figura 20 Principios Lean Thinking
Pgina 74
2. Ampliar el aprendizaje.
El desarrollo de software es un proceso continuo de aprendizaje. Los miembros del
equipo deben poder experimentar y aprender de sus errores. La retroalimentacin es
una parte muy importante del proceso.
3. Decidir lo ms tarde posible.
El desarrollo de software est siempre asociado con cierto grado de incertidumbre, los
mejores resultados se alcanzan con un enfoque basado en opciones, lo que retrasa las
decisiones tanto como sea posible, hasta que estas se basen en hechos y no en
suposiciones y pronsticos inciertos.
Cuanto ms complejo es un proyecto, ms posibilidades de cambios existen.
El enfoque iterativo promueve este principio, la capacidad de adaptarse a los cambios
y corregir los errores, lo que podra ser muy costoso si se descubre despus de la
entrega completa del sistema.
4. Entrega rpida.
Cuanto antes el producto final se entrega sin defectos considerables, ms pronto se
pueden recibir comentarios, y se incorporan en la siguiente iteracin.
Cuanto ms cortas sean las iteraciones, mejor es el aprendizaje y la comunicacin
dentro del equipo. Sin velocidad, las decisiones no pueden ser postergadas.
La velocidad puede asegurar que se cumplan las necesidades actuales del cliente y no
lo que este requera para el da anterior. Esto les da la oportunidad de pararse a
pensar lo que realmente necesitan, hasta que adquieran un mejor conocimiento. Los
clientes valoran la entrega rpida de un producto de calidad.
Pgina 75
5. Potenciar el equipo.
El equipo necesita algo ms que la lista de tareas y la seguridad de que no ser
alterada durante la realizacin de las tareas. Las personas necesitan motivacin y un
propsito para el cual trabajar.
Pgina 76