Post on 31-Dec-2015
description
Juan Palacio BañeresDic. 2005
Juan Palacio BañeresDic. 2005
Visión ejecutiva de procesos y prácticas
para desarrollo de software
2
Modelos de procesos y prácticasModelos de procesos y prácticas
1959MIL-Q 9858
1979BS 5750
1987ISO 9000
1997TickIT1991
ISO 9000-3Ada
ptac
ione
spa
ra s
oftw
.
1995ISO 12207
1995Proy. SPICE
1993CMM-SW
Mod
elos
esp
ecíf
icos
para
sof
twar
e.2003-05
ISO 15504
2001CMMI
ModelosCMM
TR 15504Mod
elos
y e
stán
dare
sde
cal
idad
Modelos genéricos Modelos para software
Trillium
Bootstrap
DSDM
SCRUM
CRYSTAL
XP
ASD
PP
AM
ISD
19952000
ManifiestoÁgil
Téc
nica
s y
mét
odos
ágile
s
Procesos y técnicas para desarrollo de software
3
ISO/IEC 12207ISO/IEC 12207
5. Procesos primarios5. Procesos primarios
7. Procesos organizacionales7. Procesos organizacionales
5.1 Adquisición5.1 Adquisición
5.2 Suministro5.2 Suministro
5.3
Desarrollo
5.3
Desarrollo
5.3
Operación
5.3
Operación
5.3
Mantenimiento
5.3
Mantenimiento
6.1 Documentación6.1 Documentación
6.2 Gestión de la configuración6.2 Gestión de la configuración
6.3 Control de calidad6.3 Control de calidad
6.4 Verificación6.4 Verificación
6.5 Validación6.5 Validación
6.6 Reuniones6.6 Reuniones
6.7 Auditoría6.7 Auditoría
6.8 Resolución de problemas6.8 Resolución de problemas
7.1 Gestión7.1 Gestión
7.3 Mejora7.3 Mejora
7.2 Infraestructura7.2 Infraestructura
7.4 Formación7.4 Formación
5. Procesos de soporte5. Procesos de soporteCiclo de vida
Concepto
Retirada
Proceso
1
…Proceso
N
Actividad 1Tarea 1Tarea 2…Tarea n
… Actividad nTarea 1Tarea 2…Tarea n
Procesos y técnicas para desarrollo de software
4
CMM: Modelo de madurez de las capacidadesCMM: Modelo de madurez de las capacidades
Idea principal: Organizaciones maduras/inmaduras
En una organización inmadura:- Procesos de software: improvisados o no respetados (si existen)- Planificación en función de los problemas- Presupuestos y planificación incumplidos- Sin base objetiva para evaluar la calidad o para resolver problemas- Inexistencia o reducción de las actividades de mejora de la calidad
En una organización madura:- Capacidad de gestión: desarrollo de software y procesos de mantenimiento- Proceso de software difundido al equipo y planificado- Procesos modificables: pruebas piloto controladas y análisis de coste/beneficio- Roles y responsabilidades establecidos en el proyecto y la organización- Gestores: monitorización la calidad de los productos y de los procesos- Planificaciones y presupuestos realistas: rendimientos históricos- Proceso disciplinado en el que todos los participantes entienden su valor,
existiendo además la infraestructura necesaria para soportar el proceso
Procesos y técnicas para desarrollo de software
5
CMM: Modelo de madurez de las capacidadesCMM: Modelo de madurez de las capacidades
1
2
3
4
5
Madurez de los procesos
Capacidad de los procesos
Eficiencia de los procesos
Baja
Alta
Escalabilidad
Alta
Baja
Repetibilidad
Inicial
Repetible
Definido
Gestionado.
Optimizado
Procesos y técnicas para desarrollo de software
6
CMM: Modelo de madurez de las capacidadesCMM: Modelo de madurez de las capacidades
Nivel de madurez Descripción
1.- InicialEntorno caótico o de programación heroica. El desarrollo del software no se basa en procesos sino en esfuerzo personal “ad hoc” para cada situación.
2.- RepetibleSe emplean procesos básicos de gestión de proyectos para trazar costes, agendas y funcionalidad. La organización repite las prácticas que se van revelando exitosas.
3.- DefinidoLos procesos de software, tanto de ingeniería como de gestión, se encuentran documentados, integrados como actuación estándar de la organización; y se emplean en todos los proyectos
4.- GestionadoSe obtienen mediciones detalladas de todos los procesos y se mide cuantitativamente tantos los procesos como sus productos.
5.- OptimizadoLa retro-información cuantitativa que se obtiene a través de la ingeniería de procesos se emplea para mejora continua e innovación.
Departamento de Defensa Americano(DoD), Instituto de Ingeniería del Software (SEI) 1987: Publicación de la descripción inicial del marco de madurez y de cuestionarios de
evaluación de organizaciones (proveeodores DoD) 1992: CMM for software 1.0
Procesos y técnicas para desarrollo de software
7
CMMI: Integración de modelos para la mejora de procesosCMMI: Integración de modelos para la mejora de procesos
Integración en un modelo único de varias disciplinas.
CMMI-SW : Software (Agosto 2002)Queda en desuso CMM-SW
CMMI-SE/SW : + Ingeniería de sistemas (Enero 2002)CMM-SW 2.0 Draft C + SECM (Systems Engineering Capability Model, también llamado EIA 731)
CMMI-SE/SW/IPPD : + Desarrollo integrado de procesos y productos (Enero 2002)+ IPD-CMM 0.98
CMMI-SE/SW/IPPD/SS : + Gestión de proveedores (Marzo 2002)+ CMM-SA
Principales diferencias con CMM
Además de la inclusión e integración de tres nuevas disciplinas:
Pone un mayor énfasis en el uso continuo de métricas
Insiste en la necesidad de la trazabilidad desde los requerimientos al producto final
Desglosa y detalla las áreas de proceso relativas a la ingeniería
Los niveles 2 y 4 se llaman ahora "gestionado" y "gestionado cuantitativamente".
Se ha desarrollado también un nuevo método de para la evaluación de las organizaciones denominado SCAMPI.
Procesos y técnicas para desarrollo de software
8
CMMI: Representaciones continuas y escalonadasCMMI: Representaciones continuas y escalonadas
CMMI-SE/SW
Staged
Representation
CMMI-SE/SW
Continuous
Representation
MADUREZ
CAPACIDAD
Atributo de la organización: cómo de previsible y repetible es la calidad de sus resultados, y su capacidad para aprender de la experiencia.
Atributo de los procesos: eficacia y eficiencia para obtener el resultado.
cap
acid
ad0
1
2
3
4
5
Área de procesoNM 1
NM 2
NM 3
NM 4
NM 5
Procesos y técnicas para desarrollo de software
9
Niveles de capacidadNiveles de capacidad
Nivel de Capacidad Descripción
0.- IncompletoNo se realizan procesos, o con éstos no se alcanzan los objetivos del área de proceso.
1.- Ejecutado El proceso o la actividad consigue su objetivo.
2.- GestionadoEl proceso consigue el objetivo, y además es planificado, revisado y evaluado para conseguir que cumpla los requisitos que se desean.
3.- DefinidoProceso gestionado que además está incorporado y ajustado al estándar normalizador de la organización, y alineado con su estrategia.
4.- Cuantitativamente gestionado
Proceso definido que además se mide cuantitativamente (con técnicas estadísticas u otras)
5.-OptimizadoProceso cuantitativamente gestionado que a través de la información que proporciona y de procesos de innovación, se adapta y cambia, mejorando su convergencia con los objetivos de negocio.
Procesos y técnicas para desarrollo de software
10
1 INICIAL
2 GESTIONADO
3 DEFINIDO
4 GESTIONADO CUANTITATIVAMENTE
5 OPTIMIZADO
Gestión de requisitos
Planificación de proyecto
Monitorización y control de proyectos
Gestión y acuerdo con suministradores
Medición y análisis
Gestión de la calidad de procesos y productos
Gestión de la configuración
Desarrollo de requisitos
Solución técnica
Verificación
Validación
Integración de producto
Procesos orientados a la organización
Definición de los procesos de la organización
Formación
Gestión integrada de proyecto
Gestión de riesgos
Análisis y resolución de decisiones
Gestión cuantificada de proyectos
Rendimiento de los procesos de la organización
Innovación y desarrollo
NIVEL DE MADUREZ ÁREAS DE PROCESO
Áreas de procesos en la representación escalonadaÁreas de procesos en la representación escalonada
Procesos y técnicas para desarrollo de software
11
GESTIÓN DE PROCESOS
INGENIERÍA
SOPORTE
GESTIÓN DE PROYECTOS
Definición de los procesos de la organización
Procesos orientados a la organización
Formación
Rendimiento de los procesos de la organización
Innovación y desarrollo
Desarrollo de requisitos
Gestión de requisitos
Soluciones técnicas
Integración de producto
Verificación
Validación
Gestión de la configuración
Gestión de la calidad de procesos y productos
Medición y análisis
Análisis y resolución de decisiones
Análisis y resolución de problemas
Planificación de proyecto
Monitorización y control de proyecto
Gestión y acuerdo con proveedores
Gestión integrada de proyecto
Gestión de riesgos
Gestión cuantificada de proyecto
CATEGORÍA ÁREAS DE PROCESO
Áreas de procesos en la representación continuaÁreas de procesos en la representación continua
Procesos y técnicas para desarrollo de software
12
ISO/IEC TR 15504ISO/IEC TR 15504
1990 1991 1992 1993 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005
Estudio M. Defensa U.K.
Informe “Improve I.T.”
Proyecto SPICE
Análisis ISO
SPICE 1.0
SPICE 2.0
ISO/IEC TR 15504PUBLICACIÓNISO/IEC Std.
15504
CMM SW 1.0
CMM SW 1.1
CMMI
Procesos y técnicas para desarrollo de software
13
ISO/IEC Std. 15504: estructura del estándarISO/IEC Std. 15504: estructura del estándar
Conceptosy guía de
introducción
Guia para det.capacidad deproveedores
Realizaciónde
evaluación
Guía de evaluación
Guia decapacitación de
evaluadores
Vocabulario
Guíapara mejorade procesos
Modelo de ref.para procesos
y capacidad
Modelo deevaluación
y guía de indic.
P1P1 P9P9
P7P7
P8P8 P6P6
P3P3 P4P4
P2P2 P5P5
Procesos y técnicas para desarrollo de software
14
ISO/IEC TR 15504: CaracterísticasISO/IEC TR 15504: Características
Marco para métodos de evaluación, no es un método o modelo en sí. Finalidad:
Evaluación de procesos Mejora de procesos
Modelo continuo. Alineado con ISO/IEC 12207 Information Technology Software Life Cycle Processes
Dimensiones del modeloDimensiones del modelo
El modelo tiene una arquitectura basada en dos dimensiones:
Dimensión de procesoCaracterizada por las declaraciones del propósito de un proceso, que son objetivos esenciales mensurables de un proceso.
Dimensión de capacidad de procesoCaracterizada por una serie de atributos de proceso, aplicables a cualquier proceso, que representan características mensurables necesarias para gestionar un proceso y mejorar su capacidad.
Procesos y técnicas para desarrollo de software
15
ISO/IEC TR 15504: Dimensión de proceso (alineado 12207) ISO/IEC TR 15504: Dimensión de proceso (alineado 12207)
Preparación de la AdquisiciónSelección del suministradorSeguimiento del suministradorAceptación del cliente
CUS.1 Adquisición
CUS.3 Obtención de requisitos
CUS.2 Suministro
CUS.4 Operación
OperaciónSoporte a cliente
Requisitos del sistemaAnálisis y diseñoAnálisis requ. SoftwareDiseño del software
ENG.1 DesarrolloConstrucción del softwareIntegración del softwarePruebas del softwarePruebas e integ. del sistema
ENG.2 Mantenimiento del sistema y del software
SUP.1 Documentación
SUP.2 Gestión de la configuración
SUP.3 Aseguramiento de la calidad
SUP.4 Verificación
SUP.5 Validación
SUP.6 Revisión conjunta
SUP.7 Auditoría
SUP.8 Resolución de problemas
MAN.1 Gestión
MAN.1 Gestión de proyecto
MAN.1 Gestión de la calidad
MAN.1 Gestión de riesgos
Definición de procesosEvaluación de procesosMejora de procesos
ORG.2 Mejora
ORG.1 Alineamiento organizacional
ORG.3 Gestión de las personas
ORG.4 Infraestructura
ORG.5 Medición
ORG.6 Reutilización
Procesos y técnicas para desarrollo de software
16
ISO/IEC TR 15504: Dimensión de capacidadISO/IEC TR 15504: Dimensión de capacidad
Niveles de capacidad y atributosNiveles de capacidad y atributos
Nivel 0: Proceso Incompleto Nivel 1: Proceso Realizado
PA 1.1 Se produce el resultado Nivel 2: Proceso Gestionado
PA 2.1 Gestión de la ejecución PA 2.2 Gestión de las
características del producto Nivel 3: Proceso Establecido
PA 3.1 Definición del proceso PA 3.2 Recursos de lproceso
Nivel 4: Proceso Predecible PA 4.1 Medición del proceso PA 4.2 Control del proceso
Nivel 5: Proceso en optimización PA 5.1 Cambio del proceso PA 5.2 Mejora continua
NN
No alcanzado (0% a 15%).Escasa o ninguna evidencia de la consecución del atributo.
No alcanzado (0% a 15%).Escasa o ninguna evidencia de la consecución del atributo.
PP
Parcialmente alcanzado (16% a 50%).Evidencia de un enfoque sistemático y de la consecucióndel atributo.Algunos aspectos de la consecución pueden ser impredecibles.
Parcialmente alcanzado (16% a 50%).Evidencia de un enfoque sistemático y de la consecucióndel atributo.Algunos aspectos de la consecución pueden ser impredecibles.
LL
Ampliamente alcanzado (51% a 85%).Evidencia de un enfoque sistemático y de una consecución significativa del atributo.La realización del proceso puede variar en algunas áreas.
Ampliamente alcanzado (51% a 85%).Evidencia de un enfoque sistemático y de una consecución significativa del atributo.La realización del proceso puede variar en algunas áreas.
FF
Totalmente alcanzado (86% a 100%).Evidencia de un enfoque completo y sistemático y de la consecución plena del atributo.
Totalmente alcanzado (86% a 100%).Evidencia de un enfoque completo y sistemático y de la consecución plena del atributo.
Medición de atributosMedición de atributos
Procesos y técnicas para desarrollo de software
17
En marzo de 2001, 17 críticos de estos modelos, convocados por Kent Beck, que acababa de definir una nueva metodología denominada Extreme Programming, se reunieron en Salt Lake City para discutir sobre los modelos de desarrollo de software.
En la reunión se acuñó el término “Métodos Ágiles” para definir a aquellos que estaban surgiendo como alternativa a las metodologías formales, (CMM-SW, PMI, SPICE) a las que consideraban excesivamente “pesadas” y rígidas por su carácter normativo y fuerte dependencia de planificaciones detalladas, previas al desarrollo.
Los integrantes de la reunión resumieron en cuatro postulados lo que ha quedado denominado como “Manifiesto Ágil”, que compendia el espíritu en el que se basan estos métodos.
Aunque como se verá más adelante, en la actualidad hay aproximaciones que combinan lo mejor de ambos enfoques (formal y ágil), hasta 2005, en cada lado sus defensores adoptaron posturas radicales, quizá más ocupadas en descalificar a la contraria que en estudiarla y conocerla para mejorar la propia.
Origen de los “métodos ágiles”Origen de los “métodos ágiles”
Manifiesto ágil (2001)Manifiesto ágil (2001)
Procesos y técnicas para desarrollo de software
18
Estamos poniendo al descubierto mejores métodos para desarrollar software, haciéndolo y ayudando a otros a que lo hagan. Con este trabajo hemos llegado a valorar:
A los individuos y su interacción de los procesos y las herramientas
por encima
El software que funciona de la documentación exhaustiva
por encima
La colaboración con el cliente la negociación contractualpor encima
La respuesta al cambio seguimiento de un planpor encima
Aunque hay valor en los elementos de la derecha, valoramos más los de la izquierda
Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff
Sutherland, Dave Thomas
http://agilemanifesto.org/
Manifiesto ágil (2001)Manifiesto ágil (2001)
Procesos y técnicas para desarrollo de software
19
Métodos ágilesMétodos ágiles
1959MIL-Q 9858
1979BS 5750
1987ISO 9000
1997TickIT1991
ISO 9000-3Ada
ptac
ione
spa
ra s
oftw
.
1995ISO 12207
1995Proy. SPICE
1993CMM-SW
Mod
elos
esp
ecíf
icos
para
sof
twar
e.2003-05
ISO 15504
2001CMMI
ModelosCMM
TR 15504Mod
elos
y e
stán
dare
sde
cal
idad
Modelos genéricos Modelos para software
Trillium
Bootstrap
DSDM
SCRUM
CRYSTAL
XP
ASD
PP
AM
ISD
19952000
ManifiestoÁgil
Téc
nica
s y
mét
odos
ágile
s
Procesos y técnicas para desarrollo de software
20
Métodos ágilesMétodos ágiles
5. Procesos primarios5. Procesos primarios
7. Procesos organizacionales7. Procesos organizacionales
5.1 Adquisición5.1 Adquisición
5.2 Suministro5.2 Suministro
5.3
Desarrollo
5.3
Desarrollo
5.3
Operación
5.3
Operación
5.3
Mantenimiento
5.3
Mantenimiento
6.1 Documentación6.1 Documentación
6.2 Gestión de la configuración6.2 Gestión de la configuración
6.3 Control de calidad6.3 Control de calidad
6.4 Verificación6.4 Verificación
6.5 Validación6.5 Validación
6.6 Reuniones6.6 Reuniones
6.7 Auditoría6.7 Auditoría
6.8 Resolución de problemas6.8 Resolución de problemas
7.1 Gestión7.1 Gestión
7.3 Mejora7.3 Mejora
7.2 Infraestructura7.2 Infraestructura
7.4 Formación7.4 Formación
5. Procesos de soporte5. Procesos de soporte
Recogen técnicas, “buenas prácticas” contrastadas por profesionales reconocidos.
Cada una tiene sus características propias y cubre un rango de áreas de procesos más o menos amplia:
Tendencia a combinarlas para dar mayor cobertura en el ciclo de vida
Han surgido de entornos reales de desarrollo de software
Responden mejor a la realidad del software y las diferencias con producción industrial.
Procesos y técnicas para desarrollo de software
21
eXtreme Programming (XP)eXtreme Programming (XP)
Procesos y técnicas para desarrollo de software
Este es el método que más popularidad ha alcanzado entre las metodologías ágiles, y posiblemente sea también el más transgresor de la ortodoxia basada en procesos.
Su creador, Kent Beck fue el alma mater del Manifiesto Ágil.
Extreme Programming (XP) se irgue sobre la suposición de que es posible desarrollar software de gran calidad a pesar, o incluso como consecuencia del cambio continuo. Su principal asunción es que con un poco de planificación, un poco de codificación y unas pocas pruebas se puede decidir si se está siguiendo un camino acertado o equivocado, evitando así tener que echar marcha atrás demasiado tarde.
Valores que inspiran XPValores que inspiran XP
FEEDBACK CORAJE COMUNICACIÓNSIMPLICIDAD
22
eXtreme Programming (XP)eXtreme Programming (XP)
Procesos y técnicas para desarrollo de software
XP pone en comunicación directa y continua a clientes y desarrolladores. El cliente se integra en el equipo para establecer prioridades y resolver dudas. De esta forma ve el avance día a día, y es posible ajustar la agenda y las funcionalidades de forma consecuente
ComunicaciónComunicación
Una metodología basada en el desarrollo incremental de pequeñas partes, con entregas y pruebas frecuentes y continuas, proporciona un flujo de retro-información valioso para detectar los problemas o desviaciones.
De esta forma fallos se localizan muy pronto.
La planificación no puede evitar algunos errores, que sólo se evidencian al desarrollar el sistema.
La retro-información es la herramienta que permite reajustar la agenda y los planes.
Feedback rápido y continuoFeedback rápido y continuo
23
eXtreme Programming (XP)eXtreme Programming (XP)
Procesos y técnicas para desarrollo de software
La simplicidad consiste en desarrollar sólo el sistema que realmente se necesita. Implica resolver en cada momento sólo las necesidades actuales.
Con este principio de simplicidad, junto con la comunicación y el feedback resulta más fácil conocer las necesidades reales
SimplicidadSimplicidad
El coraje implica saber tomar decisiones difíciles. Reparar un error cuando se detecta. Mejorar el código siempre que tras el feedback y las sucesivas iteraciones se manifieste susceptible de mejora.
Tratar rápidamente con el cliente los desajustes de agendas para decidir qué partes y cuándo se van a entregar.
CorajeCoraje
Los costes y la complejidad de predecir el futuro son muy elevados, y la mejor forma de acertar es esperar al futuro. Los costes y la complejidad de predecir el futuro son muy elevados, y la mejor forma de acertar es esperar al futuro.
24
eXtreme Programming (XP)eXtreme Programming (XP)
Procesos y técnicas para desarrollo de software
XP no es un modelo de procesos ni un marco de trabajo, sino un conjunto de 12 prácticas que se complementan unas a otras y deben implementarse en un entorno de desarrollo cuya cultura se base en los cuatro valores citados
Las 12 prácticas de XPLas 12 prácticas de XP
PRÁCTICAS DE CODIFICACIÓNPRÁCTICAS DE CODIFICACIÓN
1.- Simplicidad de código y de diseño para producir software fácil de modificar.
2.- Reingeniería continua para lograr que el código tenga un diseño óptimo.
3.- Desarrollar estándares de codificación, para comunicar ideas con claridad a través del código.
4.- Desarrollar un vocabulario común, para comunicar las ideas sobre el código con claridad.
PRÁCTICAS DE DESARROLLOPRÁCTICAS DE DESARROLLO
1.- Adoptar un método de desarrollo basado en las pruebas para asegurar que el código se comporta según lo esperado.
2.- Programación por parejas, para incrementar el conocimiento, la experiencia y las ideas.
3.- Asumir la propiedad colectiva del código, para que todo el equipo sea responsable de él.
4.- Integración continua, para reducir el impacto de la incorporación de nuevas funcionalidades.
25
eXtreme Programming (XP)eXtreme Programming (XP)
Procesos y técnicas para desarrollo de software
Las 12 prácticas de XPLas 12 prácticas de XP
PRÁCTICAS DE NEGOCIOPRÁCTICAS DE NEGOCIO
1.- Integración de un representante del cliente en el equipo, para encauzar las cuestiones de negocio del sistema de forma directa, sin retrasos o pérdidas por intermediación.
2.- Adoptar el juego de la planificación para centrar en la agenda el trabajo más importante.
3.- Entregas regulares y frecuentes para satisfacer la inversión del cliente.
4.- Ritmo de trabajo sostenible, para terminar la jornada cansado pero no agotado.
26
ScrumScrum
Procesos y técnicas para desarrollo de software
No es propiamente un método o metodología de desarrollo, e implantarlo como tal resulta insuficiente.
Scrum define métodos de gestión y control para complementar la aplicación de otros métodos ágiles como XP que, centrados en prácticas de tipo técnico, carecen de ellas.
Los principios de Scrum son:
Equipos autogestionados.
Una vez dimensionadas las tareas no es posible agregarles trabajo extra.
Reuniones diarias en las que los miembros del equipo se plantean 3 cuestiones:
¿Qué has hecho desde la última revisión?
¿Qué obstáculos te impiden cumplir la meta?
¿Qué vas a hacer antes de la próxima reunión?
Iteraciones de desarrollo de frecuencia inferior a un mes, al final de las cuales se presenta el resultado a los externos del equipo de desarrollo, y se realiza una planificación de la siguiente iteración, guiada por cliente.
27
ScrumScrum
Procesos y técnicas para desarrollo de software
28
Procesos y técnicas para desarrollo de software
Otros métodos ágilesOtros métodos ágiles
Familia de métodos CrystalFamilia de métodos Crystal
La familia de metodologías Crystal ofrece diferentes métodos para seleccionar el más apropiado para cada proyecto.
Crystal identifica con colores diferentes cada método, y su elección debe ser consecuencia del tamaño y criticidad del proyecto, de forma que los de mayor tamaño, o aquellos en los que la presencia de errores o desbordamiento de agendas implique consecuencias graves, deben adoptar metodologías más pesadas.
Los métodos Crystal no prescriben prácticas concretas
ASD (Adaptative Software Development)ASD (Adaptative Software Development)
Método que como alternativa a los procedimientos formales, aborda el desarrollo de grandes sistemas con el uso de técnicas propias de las metodologías ágiles.
No se trata de una metodología, sino de la implantación de una cultura en la empresa, basada en la adaptabilidad.
29
Procesos y técnicas para desarrollo de software
Otros métodos ágilesOtros métodos ágiles
PP (Pragmatic Programming)PP (Pragmatic Programming)
Pragmatic Programming es la colección de 70 prácticas de programación, comunes a otros métodos ágiles, cuya aplicación resulta útil para solucionar los problemas cotidianos. Surge del libro “The Pragmatic Programmer” de Dave Thomas y Andres Hunt.
AM (Agile Modeling)AM (Agile Modeling)
Agile Modeling es la presentación de un nuevo enfoque para realizar el modelado de sistemas,(diseño) y basado en los principios de los métodos ágiles remarca la conveniencia de reducir el volumen de la documentación. (Amber S. “Agile Modeling: Effective Practices for Extreme Programming and the Unified Process”)
ISD Internet Speed DevelopmentISD Internet Speed Development
Surge de las conclusiones del coloquio celebrado en Octubre de 2001, promovido por SEI que reunió a especialistas de las universidades Carneige Mellon, Georgia y Copenhagen.
Sienta bases de gestión para abordar el desarrollo de sistemas de software, de tamaño pequeño que requieren tiempos de desarrollo muy rápidos.
FDD (Feature Driven Development)FDD (Feature Driven Development)
Prescribe un proceso iterativo de 5 pasos, con iteraciones de dos semanas.
El punto de referencia son las características que debe reunir el software, y se centra en las fases de diseño e implementación del sistema
30
Procesos y técnicas para desarrollo de software
Modelos de propiedad Comercial: MSFModelos de propiedad Comercial: MSF
MSF es la metodología empleada por Microsoft para el desarrollo de software.
Hasta su versión 3 (principios de 2005) MSF se definía como un marco de desarrollo flexible para adaptarse a las necesidades de cada proyecto, en oposición a lo que sería una metodología prescriptiva; porque parte de la base de que no hay una estructura de procesos óptima para las necesidades de todos los entornos de desarrollo posibles.
El marco MSF se asienta sobre unos Principios Fundamentales que definen la cultura del entorno de desarrollo:
Fomento de la comunicación abierta.
Trabajo en torno a una visión compartida.
Apoderar a los integrantes del equipo (“empowerment”)
Establecimiento de responsabilidades claras y compartidas.
Centrar el objetivo en la entrega de valor para el negocio.
Permanecer ágiles y esperar e cambio.
Invertir en calidad.
Aprender de la experiencia.
Fomento de la comunicación abierta.
Trabajo en torno a una visión compartida.
Apoderar a los integrantes del equipo (“empowerment”)
Establecimiento de responsabilidades claras y compartidas.
Centrar el objetivo en la entrega de valor para el negocio.
Permanecer ágiles y esperar e cambio.
Invertir en calidad.
Aprender de la experiencia.
MSF: PRINCIPIOS FUNDAMENTALES
31
Procesos y técnicas para desarrollo de software
Modelos de propiedad Comercial: MSFModelos de propiedad Comercial: MSF
Elementos que componen el modeloElementos que componen el modelo
Principios fundamentales
Modelos
Disciplinas
Conceptos clave
Prácticas contrastadas
Recomendaciones
Principios básicos en los que se basa todo el modelo (los 8 de la pág. ant.)
Mapas mentales de organización. Hay 2: De equipo y de procesos
Áreas de trabajo en las que se usan métodos determinados (Gestión de proyecto, de riesgos y de la mejora del talento)
Ideas que dan soporte a los principios y disciplinas de MSF y se muestrana través de prácticas específicas contrastadas.
Prácticas que han demostrado su efectividad en proyectos en diferentes condiciones de entornos reales
Prácticas opcionales, sugeridas por el modelo.
32
Procesos y técnicas para desarrollo de software
Modelos de propiedad Comercial: MSFModelos de propiedad Comercial: MSF
Relación entre los componentes del modeloRelación entre los componentes del modelo
Este diagrama es un ejemplo para mostrar la interconexión y relación entre los componentes de Microsoft Solutions Framework
Aprender de las
experiencias
Modelo de procesos
Disposición al aprendizaje
Hitos de revisión
Uso de facilitadores
externos
Permanecer ágil y esperar
el cambio
Gestión de riesgos
Evaluación continua de
riesgos
Definir y monitorizar
disparadores de riesgos
Creación de una BD de
riesgos
Principio
Fundamental
Modelo o
Disciplina
Concepto
Clave
Práctica
ContrastadaRecomendac.
˜
˜
˜
˜
˜
˜
˜
˜˜
Está relacionado
En 2005, el desarrollo del nuevo producto de Microsoft “Visual Studio 2005 Team System” ha ganerado la evolución de MSF hacia la nueva versión 4.0 con dos líneas paralelas:
Microsoft Solutions Framework (MSF) for Agile Software Development.
Microsoft Solutions Framework (MSF) for CMMI Process Improvement.
33
Procesos y técnicas para desarrollo de software
Modelos de propiedad Comercial: RUPModelos de propiedad Comercial: RUP
Rational Unified ProcessRational Unified Process
Es un proceso de Ingeniería del Software que proporciona una visión disciplinada para la asignación de tareas y responsabilidades en las organizaciones de desarrollo de software.
RUP es un “modelo-producto” desarrollado y mantenido por Racional Software, integrado en su conjunto de herramientas de desarrollo, y distribuido por IBM.
RUP integra un conjunto de “buenas prácticas” para el desarrollo de software en un marco de procesos válido para un rango amplio de tipos de proyectos y organizaciones.
Desarrollo iterativo.
Gestión de requisitos.
Uso de arquitecturas basadas en componentes.
Uso de técnicas de modelado visual.
Verificación continua de la calidad.
Gestión y control de cambios.
Desarrollo iterativo.
Gestión de requisitos.
Uso de arquitecturas basadas en componentes.
Uso de técnicas de modelado visual.
Verificación continua de la calidad.
Gestión y control de cambios.
RUP: Buenas Prácticas
34
Procesos y técnicas para desarrollo de software
Modelos de propiedad Comercial: RUPModelos de propiedad Comercial: RUP
Rational Unified Process: Visión estáticaRational Unified Process: Visión estática
En su visión estática, el modelo RUP está compuesto por:
Roles: analista de sistemas, diseñador, diseñador de pruebas, roles de gestión y roles de administración.
Actividades: RUP determina el trabajo de cada rol a través de actividades. Cada actividad del proyecto debe tener un propósito claro, y se asigna a un rol específico. Las actividades pueden tener duración de horas o de algunos días; y son elementos base de planificación y progreso.
Artefactos: Son los elementos de entrada y salida de las actividades. Son productos tangibles del proyecto. Las cosas que el proyecto produce o usa para componer el producto final (modelos, documentos, código, ejecutables…)
Disciplinas: son “contenedores” empleados para organizar las actividades del proceso. RUP comprende 6 disciplinas técnicas y 3 de soporte.Técnicas: modelado del negocio, requisitos, análisis y diseño, implementación, pruebas y desarrollo.Soprte: gestión de proyecto, gestión de configuración y cambio, y entorno.
Flujos de trabajo: son el “pegamento”de los roles, actividades, artefactos y disciplinas, y constituyen la secuencia de actividades que producen resultados visibles.
35
Procesos y técnicas para desarrollo de software
Modelos de propiedad Comercial: RUPModelos de propiedad Comercial: RUP
Rational Unified Process: Visión dinámicaRational Unified Process: Visión dinámica
En su visión dinámica, la visión de la estructura del ciclo de vida RUP se basa en un desarrollo iterativo, jalonado por hitos para revisar el avance y planear la continuidad o los posibles cambios de rumbo.
Cuatro son las fases que dividen el ciclo de vida de un proyecto RUP:
1.- Inicio. Es la fase de la idea, de la visión inicial de producto, su alcance. El esbozo de una arquitectura posible y las primeras estimaciones. Concluye con el “hito de objetivo”.
2.- Elaboración. Comprende la planificación de las actividades y del equipo necesario. La especificación de las necesidades y el diseño de la arquitectura. Termina con el “hito de Arquitectura”.
3.- Construcción. Desarrollo del producto hasta que se encuentra disponible para su entrega a los usuarios. Termina con el “hito del inicio de la capacidad operativa”.
4.- Transición. Traspaso del producto a los usuarios. Incluye: manufactura, envío, formación, asistencia y el mantenimiento hasta lograr la satisfacción de los usuarios. Termina con el “hito de entrega del producto”.
36
FACTORES CLAVE EN LOS PROYECTOSFACTORES CLAVE EN LOS PROYECTOS
Factor Discriminadores ágiles Discriminadores formales
Tamaño
Dependencia y escalabilidad limitada por el porcentaje alto de conocimiento tácito.
Apropiado para equipos y productos pequeños.
Escalabilidad y conocimiento explícito.
Apropiado para productos y equipos grandes. Duro de mantener en pequeños proyectos.
Criticidad
La simplicidad en la documentación y el diseño dificulta los planes de pruebas.
No aconsejado para sistemas con niveles de criticidad altos (IEEE 1012)
Rigor de requisitos y diseño adecuados para procesos de pruebas, verificación y validación.
Duros de gestionar en proyectos de escasa criticidad
Dinamismo
“Re-factorizar” desde un diseño básico hasta el producto final es un método ideal para entornos dinámicos e in-novadores, pero muy caro por el “re-trabajo” para entornos estables o conocidos
En sistemas estables y conocidos, partir de requisitos completos y diseños detallados permite trazar y seguir un plan completo y “hacerlo bien a la primera”.
Personal
Los métodos de trabajo ágiles requieren una masa crítica de técnicos con niveles de experiencia medios-altos, capaces de comprender y adaptar los métodos y las técnicas empleadas.
Aunque es aconsejable contar con personas expertas en las fases de definición del proyecto, luego pueden ejecutarse con menor masa crítica de expertos.
CulturaMás apropiado para culturas de “empowerment” responsabilidad y horquilla de decisión y libertad personal.
Más apropiado en culturas en las que las personas se sienten seguras con un marco de tareas y responsabilidades bien definido.
Adaptado de Barry Bohem y Richard TurnerBalancing Agility and Discipline
Procesos y técnicas para desarrollo de software
37
¿Enfoque formal o ágil?¿Enfoque formal o ágil?
Personal
Criticidad
Dinamismo
TamañoCultura
% Junior % Senior y Master
Pérdidas posibles
Número de personas
% Modific. Requisitos / mes
% adaptación a entornos caóticos
Ágil Formal
1
510
3050
10
30
50
70
90
300
100
30
10
3
0
10
20
30
40
35
30
25
20
15
Vidas – Bienes - utilidad
Procesos y técnicas para desarrollo de software
38
Para ampliar informaciónPara ampliar información
Página oficial CMMI del Software Engineering Institute. (http://www.sei.cmu.edu/cmmi/cmmi.html)
Página para descarga de los modelos CMMI. (http://www.sei.cmu.edu/cmmi/models/models.html)
SWEBOK: Áreas de conocimiento de la Ingeniería del software (http://www.swebok.org/)
Gestión de proyectos PMI (http://www.pmi.org) IPMA (http://www.ipma.ch) PRINCE 2 (http://www.prince2.com/)
Modelos basados en procesos
Manifiesto Ágil (http://www.agilemanifesto.org/)
Agile Alliance (http://www.agilealliance.org/)
Scrum (http://www.controlchaos.com/)
Exreme Programming (http://www.extremeprogramming.org/)
DSDM (http://www.dsdm.org/)
Microsoft Solutions Framework (http://msdn.microsoft.com/vstudio/teamsystem/msf/)
Rational Unified Process (http://www-306.ibm.com/software/rational/)
(http://www-128.ibm.com/developerworks/rational/library/content/RationalEdge/jan01/WhatIstheRationalUnifiedProcessJan01.pdf)
Agile Modeling (http://www.agilemodeling.com/)
Feature Driven Development (http://www.featuredrivendevelopment.com/)
Internet Speed Development (http://www.sei.cmu.edu/pub/documents/02.reports/pdf/02tr020.pdf)
Modelos ágiles
Procesos y técnicas para desarrollo de software
39
¿ Preguntas ?¿ Preguntas ?
Procesos y técnicas para desarrollo de software
40
Procesos y técnicas para desarrollo de software
Juan Palaciojpalacio@navegapolis.net
http://www.navegapolis.net
Puedes consultar la licencia de uso y distribución de este trabajo en el registro de Safe Creative. http://www.safecreative.org/work nº de obra: 0711220312698