Metodologas de desarrollo y modelos de

ciclo de vida.
Pablo Burgos Casado (SGTIC)
Ministerio Industria, Energa y Turismo
1
1. Introduccin a las Metodologas
2. Mtrica v3
3. Metodologas Agiles
4. SCRUM
5. XP
6. TDD
7. Modelo CMMI. Diferencia con metodologas agiles.
8. Tipologa de proyectos TIC en AAPP
9. Adaptacin metodologa a los proyectos: Minetur MIMO
10. Contratacin de proyectos desarrollo
11. Entregables y documentacin.
12. Ciclo de vida
Sumario
2
1. Introduccin a las metodologas
Se define metodologa como el conjunto de mtodos y reglas que sirven de gua para realizar
los trabajos propios de desarrollo y que obligan a los miembros del equipo de proyecto a
realizar ciertas comprobaciones sistemticas de manera que el resultado final no presente
incoherencias y est dirigido a un objetivo claro y prefijado.

3
1. Introduccin a las metodologas
Diferencias entre MCV (Modelo de ciclo de vida) y Metodologa
Se define MCV de un SI como el conjunto de fases por las que pasa el sistema desde que se
concibe hasta que se retira del servicio. El MCV indica cules son las actividades a realizar y el
orden en que se van a realizar.
El MCV no indica cmo se realizan las actividades y ni quin las tiene que realizar. La
metodologa hace esa funcin (la manera de construir el software; con qu tcnicas, cmo se
llevan a cabo,). Indica el procedimiento de trabajo para avanzar en la construccin del sistema
pero el orden en que se realizan las actividades lo indica el MCV.

4
2. Mtrica v3
La metodologa Mtrica V3 tiene un enfoque orientado al proceso, y se ha enmarcado dentro de
la norma ISO 12.207, que se centra en la clasificacin y definicin de los procesos del ciclo de
vida del software. Como punto de partida y atendiendo a dicha norma, MTRICA Versin 3 cubre
el Proceso de Desarrollo y el Proceso de Mantenimiento de Sistemas de Informacin.
5
2. Mtrica v3 (Procesos, actividades y tareas)
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.
6
2. Mtrica v3
Contempla los dos paradigmas de desarrollo: OO (Orientado a objetos) y Estructurado.
Incluye la fase de mantenimiento.
Incluye cuatro interfaces que completan las actividades de:
Gestin de proyectos
Gestin de configuracin
Aseguramiento de la calidad (ISO 9001:2000, ISO15504 SPICE)
Seguridad
Propone una gua de tcnicas mucho ms amplia donde se distingue entre tcnicas (de uso
general y formalizado) y prcticas (de uso particular y no formalizado).
7
2. Mtrica v3 (Diferencia entre tcnicas y prcticas)
- Tcnica: Conjunto de heursticas y procedimientos que se apoyan en estndares, es decir, que
utilizan una o varias notaciones especficas en trminos de sintaxis y semntica y cumplen unos
criterios de calidad en cuanto a la forma de obtencin del producto asociado.
- Las prcticas representan un medio para la consecucin de unos objetivos especficos de manera
rpida, segura y precisa, sin necesidad de cumplir unos criterios o reglas preestablecidas.
8
TCNICAS DE DESARROLLO TCNICAS DE GESTIN DE
PROYECTOS
PRCTICAS
ANLISIS COSTE/BENEFICIO
CASOS DE USO
DIAGRAMA DE CLASES
DIAGRAMA DE COMPONENTES
DIAGRAMA DE DESCOMPOSICIN
DIAGRAMA DE DESPLIEGUE
DIAGRAMA DE ESTRUCTURA
DIAGRAMA FLUJO DATOS (DFD)
DIAGRAMA DE INTERACCIN
Diagrama de secuencia
Diagrama de colaboracin
DIAGRAMA DE PAQUETES
DIAGRAMA TRANSICIN ESTADOS
MODELADO DE PROCESOS
SADT (Structured Analysis and
Design Technique)
MODELO E/R EXTENDIDO
NORMALIZACIN
OPTIMIZACIN
REGLAS DE OBTENCIN DEL
MODELO FSICO A PARTIR DEL
LGICO
REGLAS DE TRANSFORMACIN
TCNICAS MATRICIALES
TCNICAS DE ESTIMACIN
Mtodo Albrecht (Puntos Funcin)
Mtodo MARKII (Puntos Funcin)
STAFFING SIZE- Orientacin a
Objetos
PLANIFICACIN
PERT
Diagrama de Gantt
Estructura de Descomposicin de
Trabajo (WBS)
Diagrama de Extrapolacin
ANLISIS DE IMPACTO
CATALOGACIN
CLCULO DE ACCESOS
CAMINOS DE ACCESO
DIAGRAMA DE REPRESENTACIN
FACTORES CRTICOS DE XITO
IMPACTO EN LA ORGANIZACIN
PRESENTACIONES
PROTOTIPADO
PRUEBAS
Pruebas Unitarias
Pruebas de Integracin
Pruebas del Sistema
Pruebas de Implantacin
Pruebas de Aceptacin
Pruebas de Regresin
REVISIN FORMAL
REVISIN TCNICA
SESIONES DE TRABAJO
Entrevistas Reuniones
JAD (Joint Application Design)
JRP (Joint Requirements Planning)

2. Mtrica v3 (Participantes)
La metodologa tipifica las figuras del personal que participa en un proyecto. Se engloban en cinco
grandes perfiles :
- Perfil Directivo: Comit de direccin; Comit de Seguimiento; Directores de usuarios; Usuarios
expertos.
- Perfil Jefe de Proyecto: Jefe de Proyecto; Responsable (de implantacin, de mantenimiento, de
operacin, de sistemas); Responsable (de seguridad, de calidad).
- Perfil Consultor: Consultor (de negocio, informtico, de Tecnologas de la informacin, de
sistemas de informacin); Especialista en Comunicaciones; Tcnico de Sistemas; Tcnico de
Comunicaciones.
- Perfil Analista: Analistas; DBA; Equipo de proyecto (Arquitectura, Implantacin, Operacin,
Seguridad, Soporte Tcnico); Equipo de Formacin; Grupo de aseguramiento de la Calidad.
- Perfil Programador: Programador.

9
3. Metodologas giles
Los procesos Agile o giles se refieren a un grupo de procesos surgidos desde 1990
centrados en dos principios clave:
- Alta involucracin y comunicacin frecuente entre los miembros del equipo del proyecto y los
expertos del negocio
- Entrega regular y peridica de funcionalidad del producto
La mayor ventaja de las metodologas giles (como SCRUM, eXtremme Programming
o TDD) es la facilidad de adaptacin a los cambios de requisitos.
10
3. Metodologas giles
El 17 de febrero de 2001 diecisiete crticos de los modelos de mejora del desarrollo de software
basados en procesos, convocados por Kent Beck, se reunieron en Snowbird, Utah para tratar
sobre tcnicas y procesos para desarrollar software. En la reunin se acu el trmino Mtodos
giles para definir a los mtodos que estaban surgiendo como alternativa a las metodologas
formales (CMMI, SPICE) a las que consideraban excesivamente pesadas y rgidas por su
carcter normativo y fuerte dependencia de planificaciones detalladas previas al desarrollo.
Los integrantes de la reunin resumieron los principios sobre los que se basan los mtodos
alternativos en cuatro postulados, lo que ha quedado denominado como Manifiesto gil.
11
3. Metodologas giles
La prioridad, de acuerdo a los principios marcados por la Agile Alliance (www.agilealliance.org),
es satisfacer al cliente con la entrega prematura y continua de valor en el software que permita
evaluar el progreso. Es por todos conocidos que los requisitos de negocio cambian durante el
proceso de desarrollo; que las personas son ms importantes durante el desarrollo que los
procesos y herramientas; y que el cliente del proyecto debe involucrarse durante todo el
proceso.
12
4. Metodologa SCRUM
Scrum surge como metodologa para la gestin y desarrollo de software a raz de los principios
recogidos en el llamado Manifiesto gil promovido por Kent Beck en 2001. Propone una
gestin basada en un proceso iterativo e incremental, utilizado comnmente en entornos
basados en el desarrollo gil de software.
13
4. Metodologa SCRUM
Scrum basa el desarrollo de software en iteraciones incrementales (sprints) donde, tras cada
iteracin, se tendr una versin del producto totalmente funcional y que incluir los requisitos
definidos en cada sprint. El seguimiento de evolucin del Sprint es sencillo en base a grficos de
avance donde se puede ver si se avanza respecto a la planificacin del Sprint.
14
4. Metodologa SCRUM
Scrum define la existencia de tres roles fundamentalmente:
a) El product owner, que correspondera con los responsables funcionales. Ser el encargado de
definir las prioridades del backlog de forma conjunta con el scrum master.
b) El scrum master: Perfil encargado de solucionar las necesidades del equipo de desarrollo y
coordinar la correcta ejecucin de la iteracin.
c) Equipo de desarrollo: los profesionales encargados de las labores de codificacin.
15
4. Metodologa SCRUM
Scrum Se basa en el principio gil de desarrollo iterativo e incremental. Al perodo de trabajo
para desarrollar un incremento de producto se lo denomina sprint, y se recomiendan
duraciones entre una y cuatro semanas. Durante cada sprint, el equipo crea un incremento de
software potencialmente entregable (utilizable).
Scrum establece una reunin al inicio de cada sprint para determinar el trabajo que se va a
realizar, otra al final para evaluar el resultado, y revisiones diarias que realiza el equipo en su
auto-gestin.
16
4. Metodologa SCRUM
El conjunto de caractersticas que forma parte de cada sprint viene del Product Backlog, que es
un conjunto de requisitos de alto nivel priorizados que definen el trabajo a realizar. Los
elementos del Product Backlog que forman parte del sprint se determinan durante la reunin de
Sprint Planning.
Durante esta reunin, el Product Owner identifica los elementos del Product Backlog que quiere
ver completados y los comunica al equipo. Entonces, el equipo determina la cantidad de ese
trabajo que puede comprometerse a completar durante el siguiente sprint. Durante el sprint,
nadie puede cambiar el Sprint Backlog, lo que significa que los requisitos estn congelados
durante el sprint.
17
5. Metodologa Extreme Programming (XP)
XP considera los cambios como un requisito natural, inevitable e incluso como aspecto
deseable en el desarrollo de proyectos. Se considera que la adaptacin a los cambios debe ser
posible a lo largo de todo el proyecto y que esto es ms realista que intentar definir una serie de
requisitos, de los cuales a priori no se tiene un conocimiento tan profundo como para proponer
soluciones realistas. El mayor objetivo de XP es la reduccin de costes.
18
5. Metodologa Extreme Programming (XP)
El ciclo de vida ideal de XP consiste de seis fases [LetelierPenades03]:
- Exploracin: Los clientes plantean a grandes rasgos las historias de usuario que son de inters para
la primera entrega del producto.
- Planificacin de la Entrega (Release): El cliente establece la prioridad de cada historia de usuario, y
los programadores realizan una estimacin del esfuerzo necesario de cada una de ellas. Al
planificar se obtiene el nmero de iteraciones necesarias para su implementacin.
- Iteraciones: Esta fase incluye varias iteraciones sobre el sistema antes de ser entregado. El Plan de
Entrega est compuesto por iteraciones de no ms de tres semanas. En la primera iteracin se
puede intentar establecer una arquitectura del sistema que pueda ser utilizada durante el resto del
proyecto. Al final de la ltima iteracin el sistema estar listo para entrar en produccin.
19
5. Metodologa Extreme Programming (XP)
- Produccin: La fase de produccin requiere de pruebas adicionales y revisiones de
rendimiento antes de que el sistema sea trasladado al entorno del cliente. Es posible que se
rebaje el tiempo que toma cada iteracin, de tres a una semana. Las ideas que han sido
propuestas y las sugerencias son documentadas para su posterior implementacin (por
ejemplo, durante la fase de mantenimiento).
- Mantenimiento: Mientras la primera versin se encuentra en produccin, el proyecto XP debe
mantener el sistema en funcionamiento al mismo tiempo que desarrolla nuevas iteraciones.
Para realizar esto se requiere de tareas de soporte para el cliente.
- Finalizacin del Proyecto: Es cuando el cliente no tiene ms historias para ser incluidas en el
sistema. Se genera la documentacin final del sistema y no se realizan ms cambios en la
arquitectura.
20
6. Metodologa Desarrollo guiado por pruebas (TDD)
Tambin conocido en ingls por su acrnimo TDD (Test Driven Development). Esta tcnica de
programacin extrema promueve los test unitarios de cada una de las nuevas funcionalidades
que se vayan a realizar.
Ms que escribir nuevo cdigo, se deben escribir nuevos test. El ciclo de vida de esta tcnica se
basa en:
- Escribir un test que pruebe la funcionalidad deseada.
- Comprobar que, evidentemente, el test falla.
- Dotar de mnima funcionalidad a la clase para que pase el test.
- Comprobar que el test ha pasado.
21
7. Modelo CMMI. Diferencias con metodologas agiles
Aunque exista la
percepcin de que los
mtodos giles y CMMI
son polos opuestos hay
numerosos los estudios (
por ejemplo, el de Jeff
Sutherland, uno de los
creadores de Scrum,
Scrum and CMMI Level 5:
The Magic Potion for Code
Warriors) y casos reales,
que muestran que no slo
no son opuestos, si no que
adems pueden ser
complementarios y
pueden potenciar el uno al
otro.
22
7. Modelo CMMI. Diferencias con metodologas agiles
CMMI es un modelo no una metodologa. CMMI se centra en el qu se espera encontrar en una
organizacin, mientras que metodologas y mtodos giles se centran en el cmo elaborar
productos del ciclo de vida del software.
- CMMI no establece orden en la ejecucin de los procesos, ni determina un ciclo de vida
- CMMI muestra reas de proceso, no procesos en s.
- La evaluacin de CMMI tiene el objetivo de interpretar el modelo en la organizacin concreta
23
8. Tipologa de proyectos de Ministerio
El Ministerio de Industria, Energa y Turismo (MINETUR) dispone de ms de 300 procedimientos
destacando los relacionados con las ayudas y subvenciones, autorizaciones y licencias. Se
encuentran alojados en la sede electrnica del Ministerio y afectan a ciudadanos y empresas.
24
SGTIC - Ayudas
60
SGTIC - Energa
126
SGTIC -
Industria 19
SGTIC - S.
Informacin y
Comercio
Interior 10
SGTIC -
Subsecretar
a 12
SGTIC -
Telecomunicaci
ones 42
OOAA 85
Distribucin de procedimientos SIA por
rea
8. Tipologa de proyectos TIC
En el Ministerio hay 419 aplicaciones, aparte de las aplicaciones que permiten gestionar los
procedimientos administrativos hay aplicaciones internas: gestin de permisos, vacaciones,
recursos humanos, nominas, etc.

25
rea de desarrollo de
Ayudas y Subvenciones. 51
rea de desarrollo de
Energa. 81
rea de desarrollo de
Industria y Turismo. 21
rea de desarrollo de
Telecomunicaciones. 55
rea de desarrollo para la
Sociedad de la Informacin y
Comercio Interior. 34
rea de desarrollos
horizontales. 134
rea Web. 43
419 aplicaciones activas en 2014
8. Tipologa de proyectos TIC
Las aplicaciones externas (para ciudadanos y empresas)
incluyen:
- Concesin de ayudas y subvenciones
- Licencias y Autorizaciones administrativas (permiten inicio
de actividad econmica).
-Inclusin en registros administrativos (operadores en
distintos sectores).
- Comunicacin de datos de actividad, estadsticas, etc
Todas estas aplicaciones incluyen la gestin interna de
solicitudes y comunicaciones.
La mayora atienden a normativa publicada en el BOE, para
cambios normativos se suele necesitar un plazo de
adaptacin o desarrollo aplicacin.

26
9. Adaptacin metodologas al caso MINETUR:MIMO
27
La metodologa MIMO (MInisterio Metodologa y
Desarrollo), ha sido diseada para facilitar la gestin
de los proyectos y homogeneizar los procesos de
desarrollo en todas las reas de Desarrollo de la
SGTIC.
MIMO adopta principios de las metodologas giles y
de CMMI y sienta un conjunto de buenas prcticas y
pautas que facilitan y homogeneizan las actividades de
desarrollo y mantenimiento, ofreciendo al mismo
tiempo las herramientas necesarias para la gestin y
seguimiento de los proyectos,
9. Adaptacin metodologas al caso MINETUR:MIMO
28
MIMO contempla la integracin de la herramienta de
planificacin Microsoft Project Professional 2010 con
la gestin de elementos de trabajo a travs de TFS.
Esto permitir al responsable planificar el catlogo de
requisitos del proyecto, programar las tareas, asignar
los recursos y gestionar el seguimiento de los
elementos de trabajo conjuntamente desde Microsoft
Project y TFS.
Plantilla de proceso basada en MSF Agile dentro del
Team Foundation Server.
MIMO adopta un modelo de proceso basado en un
desarrollo iterativo e incremental .

10. Contratacin proyectos desarrollo
La contratacin se realiza utilizando en la mayora de los
casos el Catlogo de Patrimonio para la contratacin por
Concurso 26 (desde el ao 2012) (actualmente incluye unas
40 empresas). Caractersticas:
- Plazo de contratacin ms reducido (1,5 a 2 meses) que
concurso (4 - 5 meses) . Necesita Informe favorable previo
del CIO.
- Cuanta no superior al milln de euros.
- Por debajo de 150.000 euros con IVA solo es necesario 3
ofertas.
- Por encima de 150.000 euros es necesario invitar a todo el
catlogo.
29
10. Contratacin proyectos desarrollo- Pliegos
30
10. Contratacin proyectos desarrollo- Pliegos
31
10. Contratacin proyectos desarrollo- Pliegos
32
Criterios Pesos
1. Precio 40
1. Equipo de trabajo 20
1. Metodologa y herramientas para la calidad del
servicio
Metodologa de trabajo
Solucin tcnica propuesta
Plan de calidad y documentacin
Plan de transferencia tecnolgica y
formacin

10
10
5
5
1. Condiciones de ejecucin y recepcin y entrega de
servicio
10
TOTAL 100
11. Entregables y documentacin.
33
Las metodologas suelen incluir ejemplos de entregables. ISO y el IEEEE proponen distintos
estndares para las distintas fases del proyecto.
11. Entregables y documentacin.
34
Fase (Proceso en Metrica V3) Documento Estandar o metodologia Tipo proyecto
EVS Resumen Ejecutivo VAL IT (IT GOVERNANCE INSTITUTE) 1
EVS Documento Propuesta de proyecto (Caso de proyecto) MAREVA + Universidad Alberta Canada 1
ASI ERS (especificacin requisitos Software) IEEE std. 830-1998 2,3
ASI DRU (Documento Requisitos de usuario) IEEE std.1362-1998 2
ASI Anlisis funcional Metrica v3 2
ASI Anlisis de procesos (notacin BPMN) BPMN,XPDL 2,3
DSI Modelo de datos Metrica v3 2,3
CSI Manual de usuario Metrica v3 2,3
CSI Plan de pruebas Metrica v3 2
IAS Manual de explotacin Metrica v3 2,3
MSI Peticin de mantenimiento sistema Metrica v3 2
Interfaz Documento Estandar o metodologa Tipo de proyecto
Gestion Proyectos Plan General Proyectos WBS, matriz RAM, D. Gantt 2
Gestion Proyectos Actas de reunin Metrica v3 2,3
Descripcin de tipo de proyecto
1: Piloto o prototipo
2: Proyecto completo
3: Desarrollo rapido aplicacin
Las metodologas suelen incluir ejemplos de entregables. Una buena practica es seleccionar
los tipos de entregables para cada tipo de proyecto adaptando la documentacin al volumen y
a los tiempos de desarrollo, flexibilizando el uso de la metodologa.
12. Modelos de ciclo de vida.
35
Se define modelo de ciclo de vida de software (o modelos de desarrollo) como la descripcin
de la vida de un producto software desde su concepcin inicial hasta que deja de utilizarse,
pasando por su desarrollo, implementacin, entrega, uso y mantenimiento.
Seguidamente se van a describir los modelos de proceso (o modelos de ciclo de vida) ms
habituales en la Ingeniera del Software.
12. Modelos de ciclo de vida.
36
1. CODE AND FIX (Codificar y Corregir)
Este modelo viene del trmino ingls code and fix y, en
realidad, consiste en la no aplicacin de ningn modelo de
ciclo de vida: se empieza inmediatamente con la
codificacin del proyecto y se van haciendo las
correcciones necesarias sobre la marcha, segn se
detectan fallos por parte de los desarrolladores o, ms
comnmente, por parte del cliente y los usuarios cuando se
les entregan versiones del producto.
2.2 Modelo de Cascada
En los aos 70 se impuso un nuevo enfoque de desarrollo
del software, introducido por Royce en 1970, a travs de un
ciclo de vida en cascada,as denominado por la
disposicin de las distintas fases de desarrollo, en las que
los resultados de una fase parecen caer en cascada hacia
la siguiente fase.
12. Modelos de ciclo de vida.
37
3. Modelo en V
El modelo en V es una variacin del modelo en cascada que muestra cmo se relacionan las
actividades de prueba con el anlisis y el diseo.
12. Modelos de ciclo de vida.
38
4. Prototipado
En contraste con la Ingeniera de Software de la dcada de los 70, que dio respuesta a
proyectos grandes pero con requisitos estables, la Ingeniera de Software de los 80 reaccion a
las complicaciones resultantes de encontrarse con requisitos poco claros y dinmicos, dando
lugar a la construccin de prototipos. El modelo de ciclo de vida de prototipos fue propuesto
por Gomaa en 1984. Un prototipo es un mecanismo para identificar los requisitos del software.
Hay distintas formas para organizar el desarrollo de prototipos evolutivos. Las tcnicas ms
utilizadas son el desarrollo incremental y el desarrollo iterativo.
12. Modelos de ciclo de vida.
39
5. Desarrollo Rpido de Aplicaciones
El Desarrollo Rpido de Aplicaciones, abreviado
como RAD (del ingls Rapid Application
Development) es un modelo de ciclo de vida que
enfatiza un desarrollo extremadamente corto. Se
trata de una adaptacin del modelo tradicional
en cascada en el que se logra el desarrollo rpido
utilizando una construccin basada en
componentes.
Codificacin. El modelo RAD asume la
utilizacin de tcnicas de cuarta generacin.
Pruebas. Como se enfatiza la reutilizacin, ya se
han comprobado muchos de los componentes de
los programas.

12. Modelos de ciclo de vida.
40
6. Modelo en Espiral
Boehm cerr la dcada de los 80 publicando en 1988 un modelo de ciclo de vida en
espiral que sustituye a la solucin en fases del modelo en cascada con ciclos de
experimentacin y aprendizaje. El modelo incorpora un nuevo elemento en el desarrollo de
software como es el anlisis de riesgos y define cuatro actividades principales
representadas por los cuatro cuadrantes de la figura
pburgos@minetur.es
Gracias.
41