Upload
victor-restrepo
View
221
Download
0
Embed Size (px)
Citation preview
8/7/2019 Modelos para calidadimp
http://slidepdf.com/reader/full/modelos-para-calidadimp 1/72
1
1.- Agilidad y procesos1.- Agilidad y procesos
8/7/2019 Modelos para calidadimp
http://slidepdf.com/reader/full/modelos-para-calidadimp 2/72
2
Agilidad y procesos
Visión simplificada de modelos formales y ágiles
1959MIL-Q 9858
1979BS 5750
1987 ISO 9000
1997
TickIT1991
ISO 9000-3Adaptaciones
parasoftw.
1995
ISO 122071995
Proy. SPICE
1993
CMM-SWModelosespecíf
icos
parasoftware.
2003-05
ISO 15504
2001
CMMI
ModelosCMM
TR 15504Modelosy
es
tándares
formales
dec
alidad
Modelos genéricos Modelos para software
Trillium
Bootstrap
DSDM
SCRUM
CRYSTALXP
ASD
PP
AM
ISD
19952000
ManifiestoÁgil
Técnicasym
étod
os
ágiles
8/7/2019 Modelos para calidadimp
http://slidepdf.com/reader/full/modelos-para-calidadimp 3/72
3
Modelos formales: CMMI
CMM (Capability Maturity Model)
Deficiencias en las metodologías ⇒ Incapacidad para manejar elproceso de software
En 1986, SEI (Software Engineering Institute): marco de trabajosobre madurez de procesos
En 1991, SEI desarrolló Capability Maturity Model (CMM)
Conjunto de prácticas recomendadas en determinadas áreas clave deproceso Mejora la capacidad del proceso de software
Guía en la selección de estrategias de mejora de proceso Establecer la madurez de los procesos Determina cuestiones críticas para la calidad y la mejora del proceso
8/7/2019 Modelos para calidadimp
http://slidepdf.com/reader/full/modelos-para-calidadimp 4/72
4
Modelos formales: CMMI
Idea principal: distinción entre empresas 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
Organizaciones de software maduras / inmadudas
8/7/2019 Modelos para calidadimp
http://slidepdf.com/reader/full/modelos-para-calidadimp 5/72
5
Modelos formales: CMMI
DoD (Departamento de Defensa de los Estados Unidos), SEI (SoftwareEngineering Institute) y NDIA (National Defense Industrial Association).
Más de 100 organizaciones involucradas U.S. Army, Navy, Air Force Federal Aviation Administration National Security Agency Software Engineering Institute ADP, Inc. AT&T Labs BAE Boeing Computer Sciences Corporation
EER Systems Ericsson Canada Ernst and Young General Dynamics Harris Corporation Honeywell
KPMG Lockheed Martin Motorola Northrop Grumman Pacific Bell Q-Labs Raytheon Reuters Rockwell Collins
SAIC Software Productivity Consortium Sverdrup Corporation TeraQuest Thomson CSF TRW
Proyecto CMMI
8/7/2019 Modelos para calidadimp
http://slidepdf.com/reader/full/modelos-para-calidadimp 6/72
6
Modelos formales: CMMI
CMMI-SE/SW
Staged
Representatio
n
CMMI-SE/SW
Continuous
Representation
Modelo combinadoSystem Engineering/SoftwareEngineering
Aplicable:– Sólo a proyectos de software
engineering– Sólo a proyectos de system
engineering– Ambos
Ambas incluyen el mismo contenido y consiguen idénticos objetivos
La representación continua centra su actuación en la CAPACIDAD DE LOS PROCESOS
La representación escalonada centra su actuación en la MADUREZ DE LA ORGANIZACIÓN
Modelos CMMI
¿Continua o escalonada?
8/7/2019 Modelos para calidadimp
http://slidepdf.com/reader/full/modelos-para-calidadimp 7/727
Modelos formales: CMMI
Heredado de los modelos de origen. Software CMM--Escalonado SECM--Continuo IPD CMM--Híbrido
En el del equipo de desarrollo de CMMI había defensores de decada una de las representaciones.
Seleccionar una única representación se planteaba como algo “toohard”.
Compromiso: Inicialmente soportar dos representaciones delmodelo con contenidos equivalentes.
¿Por qué dos representaciones del modelo?
8/7/2019 Modelos para calidadimp
http://slidepdf.com/reader/full/modelos-para-calidadimp 8/728
Modelos formales: CMMI
. . .para un conjunto deáreas de proceso establecido
Escalonado
ML 1
ML2
ML3
ML4
ML5
. . .para un área de proceso
o un conjunto de áreas de proceso
Continuo
PA PA
Capac
idad
0
1
2
3
4
5
PA
Un modelo, dos representaciones
8/7/2019 Modelos para calidadimp
http://slidepdf.com/reader/full/modelos-para-calidadimp 9/729
Modelos formales: CMMI
Capacidad es un atributo que se aplica a los procesos y define laeficacia del mismo para conseguir los objetivos previstos.
Madurez es un atributo que se aplica a la organización y define su
potencial de calidad en la producción.
ML 1
ML2
ML3
ML4
ML5
0
1
2
3
4
5
Capacidad y madurez
8/7/2019 Modelos para calidadimp
http://slidepdf.com/reader/full/modelos-para-calidadimp 10/7210
Modelos formales: CMMI
0 – IncompletoLos procesos no se realizan, o no consiguen sus objetivos
1 – EjecutadoLos procesos se ejecutan y se logran los objetivos específicos del área
2 – GestionadoLos procesos que además de considerarse “ejecutados” son también planificados,revisados y evaluados para comprobar que cumplen los requisitos
3 – DefinidoLos procesos que además de considerarse “gestionados” se ajustan al conjunto deprocesos estándar conforme a las líneas directivas de la organización
4 – Gestión cuantificadaProcesos “definidos” que son controlados utilizando técnicas estadísticas u otrastécnicas cuantitativas
5 – OptimizadoProcesos “gestionados cuantificadamente” que son cambiados y adaptados paraconseguir objetivos relevantes de negocio
Niveles de capacidad
8/7/2019 Modelos para calidadimp
http://slidepdf.com/reader/full/modelos-para-calidadimp 11/7211
Modelos formales: CMMI
Los valores describen “cómo de bien” se realiza el proceso (nivelde capacidad del proceso).
C a p a c id a d
Procesos
AreaProceso 1
AreaProceso n
AreaProceso 2
AreaProceso 3
Proceso bien ejecutado ymejorado continuamente
Proceso no ejecutado
Dimensión de la capacidad
8/7/2019 Modelos para calidadimp
http://slidepdf.com/reader/full/modelos-para-calidadimp 12/7212
Modelos formales: CMMI
1 – InicialControl deficiente e impredecibilidad de los resultados
2 – GestionadoEs posible obtener niveles de calidad previamente alcanzados
3 – DefinidoLos procesos realizados se encuentran normalizados, son conocidos ycomprendidos
4 – Gestionado cuantitativamente
Los procesos incluyen indicadores de medición y control 5 – Optimizado
Centralización en la mejora de los procesos
Niveles de madurez
8/7/2019 Modelos para calidadimp
http://slidepdf.com/reader/full/modelos-para-calidadimp 13/72
13
Modelos formales: CMMI
Proceso imprevisible, pococontrolado y reactivo
Proceso caracterizadopara los proyectos y amenudo reactivo
Proceso caracterizadopara la organización yproactivo
Proceso medido
y controlado
Centrado en la mejora deprocesos
Optimizado
Gestionadocuantitativamente
Definido
Inicial
Gestionado
1
2
3
4
5
Dimensión de la madurez
8/7/2019 Modelos para calidadimp
http://slidepdf.com/reader/full/modelos-para-calidadimp 14/72
14
Modelos formales: CMMI
CMMI recoge prácticas para 22 áreas de procesos
Las áreas de procesos agrupan a las actividades necesarias parala ejecución de los proyectos de ingeniería de sistemas y de
software
El modelo en su representación escalonada clasifica a las 22áreas de proceso en aquellas cuya gestión es necesaria paralograr cada nivel de calidad
El modelo en su representación continua las clasifica según a lacategoría que pertenecen: Gestión de proyectos, ingeniería,soporte y gestión de procesos
Áreas de procesos
8/7/2019 Modelos para calidadimp
http://slidepdf.com/reader/full/modelos-para-calidadimp 15/72
15
Modelos formales: CMMI
1 INICIAL
2 GESTIONADO
3 DEFINIDO
4 GESTIONADOCUANTITATIVAMENTE
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
8/7/2019 Modelos para calidadimp
http://slidepdf.com/reader/full/modelos-para-calidadimp 16/72
16
Modelos formales: CMMI
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
8/7/2019 Modelos para calidadimp
http://slidepdf.com/reader/full/modelos-para-calidadimp 17/72
17
Modelos formales: CMMI
Cómo usar el modelo
Área de procesoConjunto de practicas relacionadas que son ejecutadas de forma conjunta para conseguir unconjunto de objetivos.
Componentes requeridos
Los objetivos genéricos asociados a un nivel de capacidad establecen lo que una organización debealcanzar en ese nivel de capacidad.El logro de cada uno de esos objetivos en un área de proceso significa mejorar el control en laejecución del área de proceso
Objetivo genérico
Objetivo específico
Los objetivos específicos se aplican a una única área de proceso y localizan las particularidades quedescriben que se debe implementar para satisfacer el propósito del área de proceso
8/7/2019 Modelos para calidadimp
http://slidepdf.com/reader/full/modelos-para-calidadimp 18/72
18
Modelos formales: CMMI
Cómo usar el modelo
Componentes esperados
Una practica genérica se aplica a cualquier área de proceso porque puede mejorar el funcionamientoy el control de cualquier proceso.
Práctica genérica
Práctica específica
Una practica específica es una actividad que se considera importante en la realización del objetivo
especifico al cual está asociado.Las prácticas específicas describen las actividades esperadas para lograr la meta específica de unárea de proceso.
Componentes informativos
PropósitoNotas introductoriasReferencias
Las referencias son indicadores de otras áreas de proceso relacionadas que pueden aportarinformación adicional o más detalladaNombresTablas de relaciones práctica-objetivoPrácticas
8/7/2019 Modelos para calidadimp
http://slidepdf.com/reader/full/modelos-para-calidadimp 19/72
19
Modelos formales: CMMI
Cómo usar el modelo
Componentes informativosPropósitoNotas introductoriasReferencias
Las referencias son indicadores de otras áreas de proceso relacionadas que pueden aportarinformación adicional o más detalladaNombresTablas de relaciones práctica-objetivoPrácticasProductos típicosSubprácticas
Una subpractica es una descripción detallada que sirve como guía para la interpretación de unapractica genérica o especificaAmpliaciones de disciplina
Las ampliaciones contienen información relevante de una disciplina particular y relacionada con unapractica especifica.
Elaboraciones de prácticas genéricasUna elaboración de una practica genérica es una guía de cómo la practica genérica debe aplicarse alárea de proceso.
8/7/2019 Modelos para calidadimp
http://slidepdf.com/reader/full/modelos-para-calidadimp 20/72
20
Modelos formales: CMMI
Área de proceso
Propósito
Notas
Referencias
Objetivos específicos
Objetivos genéricos
Mapa del documento
8/7/2019 Modelos para calidadimp
http://slidepdf.com/reader/full/modelos-para-calidadimp 21/72
21
Modelos formales: CMMI
R. Metas-Practicas
Practicas especificas
Nombres
Mapa del documento
8/7/2019 Modelos para calidadimp
http://slidepdf.com/reader/full/modelos-para-calidadimp 22/72
22
Modelos formales: CMMI
Productos de
trabajo
Practicas genericas
Elaboraciones
Notas
Subpracticas
Mapa del documento
8/7/2019 Modelos para calidadimp
http://slidepdf.com/reader/full/modelos-para-calidadimp 23/72
23
Modelos formales: CMMI
CMMI SE/SW incluye 22 áreas de proceso
Las áreas de proceso son iguales en ambas representaciones del modelo
En la representación continua, las áreas de proceso se agrupan por categorías: Gestión deproyectos, Ingeniería, Soporte y Gestión de procesos
Process areas by capability
En la representación escalonada, las áreas de proceso se agrupan por niveles de madurez (2 –5)
Process areas by maturity level
Áreas de proceso
8/7/2019 Modelos para calidadimp
http://slidepdf.com/reader/full/modelos-para-calidadimp 24/72
24
Áreas de proceso
Gestión de proyecto
El modelo CMMI SE/SW incluye seis áreas de proceso en gestión de proyectos: Planificación de proyecto Monitorización y control de proyecto Gestión y acuerdos con proveedores Gestión integrada de proyecto Gestión de riesgos Gestión cuantificada de proyecto
Las áreas de procesos de gestión de proyectos cubren las actividades relacionadas con laplanificación, monitorización y control del proyecto.Las áreas de procesos de gestión de proyectos cubren las actividades relacionadas con laplanificación, monitorización y control del proyecto.
Modelos formales: CMMI
8/7/2019 Modelos para calidadimp
http://slidepdf.com/reader/full/modelos-para-calidadimp 25/72
25
ISO/IEC 15504: Origen
En enero de 1993 la comisión ISO/IEC JTC1 aprobó un programa de trabajopara el desarrollo de un modelo que fuera la base de un futuro estándarinternacional para la evaluación de los procesos del ciclo de vida del software.
Este trabajo recibió el nombre de proyecto SPICE (Software ProcessImprovement and Capability dEtermination), y en junio de 1995, con lapublicación de su primer borrador, desde ISO fueron invitadas diferentes
organizaciones para aplicarlo y valorar sus resultados.
Proyecto SPICE
Proyecto -> Instrucción Técnica -> Estándar
Modelos formales: ISO/IEC 15504
En 1998, pasada la fase de proyecto, y tras las primeras evaluaciones, el trabajo pasóa la fase de informe técnico con la denominación ISO/IEC TR 15504.
La instrucción técnica consta de 9 apartados, recogidos en volúmenes independientes,que se han ido publicando como redacción definitiva del estándar internacional
ISO/IEC 15504 durante el periodo 2003-2005.Ámbito de aplicación
Cualquier organización de software que quiera establecer y mejorar su capacidad enadquisición, suministro, desarrollo, operación evolución y soporte de software.
Independientemente de estructuras, filosofías de gestión, modelos de ciclo de vida de
software, tecnologías o metodologías de desarrollo.
8/7/2019 Modelos para calidadimp
http://slidepdf.com/reader/full/modelos-para-calidadimp 26/72
26
Modelos formales: ISO/IEC 15504
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 procesosy capacidad
Modelo deevaluación
y guía de indic.
P1P1 P9P9
P7P7
P8P8 P6P6
P3P3 P4P4
P2P2 P5P5
Estructura
8/7/2019 Modelos para calidadimp
http://slidepdf.com/reader/full/modelos-para-calidadimp 27/72
27
Modelos formales: ISO/IEC 15504
Características Marco para métodos de evaluación, no es un método o modelo en sí. Comprende:
Evaluación de procesos Mejora de procesos Determinación de capacidad
Alineado con ISO/IEC 12207 Information Technology Software Life CycleProcesses
Dimensiones del modeloEl 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 acualquier proceso, que representan características mensurablesnecesarias para gestionar un proceso y mejorar su capacidad.
8/7/2019 Modelos para calidadimp
http://slidepdf.com/reader/full/modelos-para-calidadimp 28/72
28
Modelos formales: ISO/IEC 15504
Características
Dimensión de proceso
Agrupa los procesos en tres grupos correspondientes a los procesos delciclo de vida que contienen cinco categorías de acuerdo al tipo deactividad.
Procesos primarios
CUS: Cliente – Proveedor
ENG: Ingeniería
Procesos organizacionales MAN: Gestión
ORG: Organización
Procesos de soporte
SUP: Soporte
8/7/2019 Modelos para calidadimp
http://slidepdf.com/reader/full/modelos-para-calidadimp 29/72
29
Modelos formales: ISO/IEC 15504
Dimensión de proceso
CUS: Cliente - proveedor
CUS.1 Proceso de adquisición CUS.1.1 Proceso de preparación de la adquisición
CUS.1.2 Proceso de selección de proveedor CUS.1.3 Procesos de seguimiento de proveedor CUS.1.4 Proceso de aceptación del cliente
CUS.2 Proceso de suministro
CUS.3 Proceso de obtención de requisitos CUS.4 Proceso de operación
CUS.4.1 Proceso de uso operacional CUS.4.2 Proceso de soporte al cliente
La categoría CUS está formada por procesos que afectan directamente alcliente, soportan el desarrollo y la transición del software al cliente ypermiten la correcta operación y uso del producto y/o servicio de software.
8/7/2019 Modelos para calidadimp
http://slidepdf.com/reader/full/modelos-para-calidadimp 30/72
30
Modelos formales: ISO/IEC 15504
Dimensión de proceso
ENG: Ingeniería
La categoría ENG está formada por procesos que directamente especifican,implementan o mantienen el producto de software, su relación con elsistema y documentación. ENG.1 Proceso de desarrollo
ENG.1.1 Proceso de análisis y diseño de requisitos de sistema. ENG.1.2 Proceso de análisis de requisitos de software. ENG.1.3 Procesos de diseño de software. ENG.1.4 Proceso de construcción de software. ENG.1.5 Proceso de integración de software. ENG.1.6 Proceso de prueba de software.
ENG.1.7 Proceso de integración y prueba de sistema. ENG.2 Proceso de mantenimiento de software
8/7/2019 Modelos para calidadimp
http://slidepdf.com/reader/full/modelos-para-calidadimp 31/72
31
Modelos formales: ISO/IEC 15504
Dimensión de proceso
SUP: Soporte
La categoría SUP está formada por procesos que dan soporte al resto deprocesos (incluidos los SUP), en distintos puntos del ciclo de vida delsoftware. SUP.1 Proceso de documentación
SUP.2 Proceso de gestión de configuración SUP.3 Proceso de aseguramiento de calidad
SUP.4 Proceso de verificación
SUP.5 Proceso de validación
SUP.6 Proceso de revisión conjunta
SUP.7 Proceso de auditoría
8/7/2019 Modelos para calidadimp
http://slidepdf.com/reader/full/modelos-para-calidadimp 32/72
8/7/2019 Modelos para calidadimp
http://slidepdf.com/reader/full/modelos-para-calidadimp 33/72
33
Modelos formales: ISO/IEC 15504
Dimensión de proceso
ORG: Organización
La categoría ORG está formada por procesos que establecen los objetivosde negocio de la organización.
ORG.1 Proceso de alineación organizacional.
ORG.2 Proceso de mejora ORG.2.1 Proceso de definición de proceso.
ORG.2.2 Proceso de evaluación de proceso.
ORG.2.3 Proceso de mejora de proceso.
ORG.3 Proceso de gestión de RR.HH.
ORG.4 Proceso de infraestructura
ORG.5 Proceso de medición
ORG.6 Proceso de reutilización
8/7/2019 Modelos para calidadimp
http://slidepdf.com/reader/full/modelos-para-calidadimp 34/72
34
Modelos formales: ISO/IEC 15504
Dimensión de proceso
Componentes de proceso
Identificador Identifica la categoría del proceso y el nº de secuencia en la categoría.Distingue entre procesos de primer y segundo nivel.
Nombre Frase descriptivo del contenido del proceso
TipoHay 5 tipos de proceso. 3 de primer nivel (básico, extendido y nuevo) y 2 desegundo nivel (componente, componente extendido)
PropósitoPárrafo que establece el propósito del proceso indicando los objetivosglobales de su ejecución.
SalidasLista de resultados observables de la implementación exitosa del proceso
Notas
8/7/2019 Modelos para calidadimp
http://slidepdf.com/reader/full/modelos-para-calidadimp 35/72
35
Modelos formales: ISO/IEC 15504
Dimensión de capacidad
Def ine una escala de medida para determinar la capacidad de cualquier proceso
Consta de seis niveles de capacidadNivel 0 IncompletoNivel 1 RealizadoNivel 2 GestionadoNivel 3 EstablecidoNivel 4 Predecible
Nivel 5 En optimización ...y un conjunto de atributos de procesos asociados al nivel de
capacidad
Capacidad de proceso: rango de resultados que espera obtenerseal seguir el proceso.
Capacidad de proceso: rango de resultados que espera obtenerseal seguir el proceso.
8/7/2019 Modelos para calidadimp
http://slidepdf.com/reader/full/modelos-para-calidadimp 36/72
36
Modelos formales: ISO/IEC 15504
Dimensión de capacidad
Niveles de capacidad y atributos
Nivel 0: Proceso Incompleto Nivel 1: Proceso Realizado Nivel 2: Proceso Gestionado
PA 2.1 Gestión de realización PA 2.2 Gestión productos
Nivel 3: Proceso Establecido PA 3.1 Definición de proceso
PA 3.2 Recursos de proceso
Nivel 4: Proceso Predecible PA 4.1 Medición
PA 4.2 Control de proceso
Nivel 5: Proceso en optimización PA 5.1 Cambio de proceso
PA 5.2 Mejora continua
8/7/2019 Modelos para calidadimp
http://slidepdf.com/reader/full/modelos-para-calidadimp 37/72
37
Modelos formales: ISO/IEC 15504
Dimensión de capacidadMedición de atributos
Los atributos de un proceso se evalúan con N (Not), P (Partially), L(Largely) y F (Fully), siendo:
NNNo 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.
PPParcialmente alcanzado (16% a 50%).Evidencia de un enfoque sistemático y de la consecucióndelatributo. Algunos aspectos de la consecución pueden serimpredecibles.
Parcialmente alcanzado (16% a 50%).Evidencia de un enfoque sistemático y de la consecucióndelatributo. Algunos aspectos de la consecución pueden serimpredecibles.
LL
Ampliamente alcanzado (51% a 85%).Evidencia de un enfoque sistemático y de una consecuciónsignificativa 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 laconsecución plena del atributo.
Totalmente alcanzado (86% a 100%).Evidencia de un enfoque completo y sistemático y de laconsecución plena del atributo.
8/7/2019 Modelos para calidadimp
http://slidepdf.com/reader/full/modelos-para-calidadimp 38/72
38
En marzo de 2001, 17 críticos de estos modelos, convocados por KentBeck, que acababa de definir una nueva metodología denominada Extreme
Programming, se reunieron en Salt Lake City para discutir sobre losmodelos de desarrollo de software.
En la reunión se acuñó el término “Métodos Ágiles” para definir aaquellos 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 deplanificaciones detalladas, previas al desarrollo.
Los integrantes de la reunión resumieron en cuatro postulados lo que haquedado denominado como “Manifiesto Ágil”, que compendia el espíritu enel que se basan estos métodos.
Aunque como se verá más adelante, en la actualidad hay aproximacionesque combinan lo mejor de ambos enfoques (formal y ágil), hasta 2005, encada lado sus defensores adoptaron posturas radicales, quizá másocupadas en descalificar a la contraria que en estudiarla y conocerla paramejorar la propia.
Origen de los “métodos ágiles”Manifiesto ágil (2001)
Agilidad y procesos
Agilidad y procesos
Manifiesto ágil (2001)
8/7/2019 Modelos para calidadimp
http://slidepdf.com/reader/full/modelos-para-calidadimp 39/72
39
Agilidad y procesos
Estamos poniendo al descubierto mejores métodos paradesarrollar software, haciéndolo y ayudando a otros aque lo hagan. Con este trabajo hemos llegado a valorar:
A los individuos y suinteracción
de los procesos y lasherramientas
porencimaEl software que
funciona
de la documentación
exhaustiva
por
encimaLa colaboración con elcliente
la negociacióncontractual
porencimaLa respuesta al
cambioseguimiento de unplan
porencima
Aunque hay valor en los elementos de la derecha,valoramos más los de la izquierda
Kent Beck, Mike Beedle, Arie van Bennekum, AlistairCockburn, Ward Cunningham, Martin Fowler, James
Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, JonKern, Brian Marick, Robert C. Martin, Steve Mellor, Ken
Schwaber, Jeff Sutherland, Dave Thomashttp://agilemanifesto.org/
g ( )
8/7/2019 Modelos para calidadimp
http://slidepdf.com/reader/full/modelos-para-calidadimp 40/72
40
3.- Entregar con frecuencia software que funcione, enperiodos de un par de semanas hasta un par de
meses, con preferencia en los periodos breves.
3.- Entregar con frecuencia software que funcione, enperiodos de un par de semanas hasta un par de
meses, con preferencia en los periodos breves.
2.- Son bienvenidos los requisitos cambiantes,
incluso si llegan tarde al desarrollo. Los procesoságiles se doblegan al cambio como ventajacompetitiva para el cliente.
2.- Son bienvenidos los requisitos cambiantes,
incluso si llegan tarde al desarrollo. Los procesoságiles se doblegan al cambio como ventajacompetitiva para el cliente.
1.- Nuestra principal prioridad es satisfacer al cliente através de la entrega temprana y continua de softwarede valor.
1.- Nuestra principal prioridad es satisfacer al cliente através de la entrega temprana y continua de softwarede valor.
12 principios del manifiesto ágil
4.- Las personas del negocio y los desarrolladoresdeben trabajar juntos de forma cotidiana a través delproyecto.
4.- Las personas del negocio y los desarrolladoresdeben trabajar juntos de forma cotidiana a través delproyecto.
Agilidad y procesos
8/7/2019 Modelos para calidadimp
http://slidepdf.com/reader/full/modelos-para-calidadimp 41/72
41
8.- Los procesos ágiles promueven el desarrollosostenido. Los patrocinadores, desarrolladores yusuarios deben mantener un ritmo constante de formaindefinida.
8.- Los procesos ágiles promueven el desarrollosostenido. Los patrocinadores, desarrolladores yusuarios deben mantener un ritmo constante de formaindefinida.
7.- El software que funciona es la principal medida del
progreso.
7.- El software que funciona es la principal medida del
progreso.
6.- La forma más eficiente y efectiva de
comunicar información de ida y vuelta dentrode un equipo de desarrollo es mediante laconversación cara a cara.
6.- La forma más eficiente y efectiva de
comunicar información de ida y vuelta dentrode un equipo de desarrollo es mediante laconversación cara a cara.
5.- Construcción de proyectos en torno a individuosmotivados, dándoles la oportunidad y el respaldo quenecesitan y procurándoles confianza para que realicenla tarea.
5.- Construcción de proyectos en torno a individuosmotivados, dándoles la oportunidad y el respaldo quenecesitan y procurándoles confianza para que realicenla tarea.
12 principios del manifiesto ágil
Agilidad y procesos
8/7/2019 Modelos para calidadimp
http://slidepdf.com/reader/full/modelos-para-calidadimp 42/72
42
12.- En intervalos regulares, el equipo reflexiona sobrela forma de ser más efectivo y ajusta su conducta enconsecuencia.
12.- En intervalos regulares, el equipo reflexiona sobrela forma de ser más efectivo y ajusta su conducta enconsecuencia.
11.- Las mejores arquitecturas, requisitos y diseñosemergen de equipos que se auto-organizan.
11.- Las mejores arquitecturas, requisitos y diseños
emergen de equipos que se auto-organizan.
10.- La simplicidad como arte de maximizar lacantidad de trabajo que se hace, es esencial.10.- La simplicidad como arte de maximizar lacantidad de trabajo que se hace, es esencial.
9.- La atención continua a la excelencia técnicaenaltece la agilidad.9.- La atención continua a la excelencia técnicaenaltece la agilidad.
12 principios del manifiesto ágil
Agilidad y procesos
8/7/2019 Modelos para calidadimp
http://slidepdf.com/reader/full/modelos-para-calidadimp 43/72
43
3.- Modelos ágiles3.- Modelos ágiles
8/7/2019 Modelos para calidadimp
http://slidepdf.com/reader/full/modelos-para-calidadimp 44/72
44
Modelos ágiles
Ubicación en el panorama general de modelos y procesos
1959
MIL-Q 98581979
BS 57501987
ISO 9000
1997
TickIT1991
ISO 9000-3Adapta
ciones
paras
oftw.
1995
ISO 122071995
Proy. SPICE
1993
CMM-SWModelosespecíf
icos
parasoftware.
2003-05
ISO 15504
2001
CMMI
ModelosCMM
TR 15504Modelosyes
tándares
decalidad
Modelos genéricos Modelos para software
Trillium
Bootstrap
DSDM
SCRUM
CRYSTAL
XP
ASD
PP
AM
ISD
19952000
Manifiesto
Ágil
Técnicasym
étodos
ágiles
8/7/2019 Modelos para calidadimp
http://slidepdf.com/reader/full/modelos-para-calidadimp 45/72
45
DSDM: Dynamic Systems Development Method
Modelos ágiles
Es la metodología más veterana de las auto-denominadas ágiles. Surgió en 1994 de los trabajos de
Jennifer Stapleton, la actual directora del DSDM Consortium.
DSDM es la metodología ágil más próxima a los métodos formales, de hecho la implantación de unmodelo DSDM en una organización la lleva a alcanzar lo que CMM consideraría un nivel 2 demadurez.
Sin embargo los aspectos que DSDM reprocha a CMM son:
Aunque es cierto que se ha desarrollado con éxito en algunas organizaciones, lo quefunciona bien en unos entornos no tiene por qué servir para todos.
CMM no le da al diseño la importancia que debería tener.
CMM plantea un foco excesivo en los procesos, olvidando la importancia que ennuestra industria tiene el talento de las personas.
El tener procesos claramente definidos no es sinónimo de tener buenos procesos.En común con los métodos ágiles, DSDM considera imprescindible una implicación y una relaciónestrecha con el cliente durante el desarrollo, así como la necesidad de trabajar con métodos dedesarrollo incremental y entregas evolutivas.
DSDM cubre los aspectos de gestión de proyectos, desarrollo de los sistemas, soporte ymantenimiento y se autodefine como un marco de trabajo para desarrollo rápido más que como unmétodo específico para el desarrollo de sistemas.
8/7/2019 Modelos para calidadimp
http://slidepdf.com/reader/full/modelos-para-calidadimp 46/72
46
eXtreme Programming (XP)Modelos ágiles
Este es el método que más popularidad ha alcanzado entre lasmetodologí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 esposible desarrollar software de gran calidad a pesar, o inclusocomo consecuencia del cambio continuo. Su principal asunción es
que con un poco de planificación, un poco de codificación y unaspocas pruebas se puede decidir si se está siguiendo un caminoacertado o equivocado, evitando así tener que echar marcha atrásdemasiado tarde.
Valores que inspiran XP
FEEDBACK CORAJE COMUNICACIÓNSIMPLICIDAD
8/7/2019 Modelos para calidadimp
http://slidepdf.com/reader/full/modelos-para-calidadimp 47/72
47
eXtreme Programming (XP)
Modelos ágiles
XP pone en comunicación directa y continua a clientes y desarrolladores. El cliente seintegra en el equipo para establecer prioridades y resolver dudas. De esta forma ve elavance día a día, y es posible ajustar la agenda y las funcionalidades de formaconsecuente
Comunicación
Una metodología basada en el desarrollo incremental de pequeñaspartes, con entregas y pruebas frecuentes y continuas, proporcionaun flujo de retro-información valioso para detectar los problemas odesviaciones.
De esta forma fallos se localizan muy pronto.
La planificación no puede evitar algunos errores, que sólo seevidencian al desarrollar el sistema.
La retro-información es la herramienta que permite reajustarla agenda y los planes.
Feedback rápido y continuo
8/7/2019 Modelos para calidadimp
http://slidepdf.com/reader/full/modelos-para-calidadimp 48/72
48
eXtreme Programming (XP)
Modelos ágiles
La simplicidad consiste en desarrollar sólo el sistema que realmente senecesita. Implica resolver en cada momento sólo las necesidades actuales.
Con este principio de simplicidad, junto con la comunicación y el feedbackresulta más fácil conocer las necesidades reales
Simplicidad
El coraje implica saber tomar decisiones difíciles. Reparar un error
cuando se detecta. Mejorar el código siempre que tras el feedbacky las sucesivas iteraciones se manifieste susceptible de mejora.
Tratar rápidamente con el cliente los desajustes de agendas paradecidir qué partes y cuándo se van a entregar.
Coraje
Los costes y la complejidad de predecir el futuro son muy elevados, y lamejor forma de acertar es esperar al futuro.Los costes y la complejidad de predecir el futuro son muy elevados, y lamejor forma de acertar es esperar al futuro.
eXtreme Programming (XP)
8/7/2019 Modelos para calidadimp
http://slidepdf.com/reader/full/modelos-para-calidadimp 49/72
49
eXtreme Programming (XP)
Modelos ágiles
XP no es un modelo de procesos ni un marco de trabajo, sino unconjunto de 12 prácticas que se complementan unas a otras y deben
implementarse en un entorno de desarrollo cuya cultura se base enlos cuatro valores citados
Las 12 prácticas de XP
PRÁCTICAS DE CODIFICACIÓNPRÁCTICAS DE CODIFICACIÓN1.- 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ésdel código.
4.- Desarrollar un vocabulario común, para comunicar las ideas sobre el código conclaridad.
PRÁCTICAS DE DESARROLLOPRÁCTICAS DE DESARROLLO1.- Adoptar un método de desarrollo basado en las pruebas para asegurar que elcódigo se comporta según lo esperado.
2.- Programación por parejas, para incrementar el conocimiento, la experiencia ylas ideas.
3.- Asumir la propiedad colectiva del código, para que todo el equipo searesponsable de él.
4.- Integración continua, para reducir el impacto de la incorporación de nuevasfuncionalidades.
8/7/2019 Modelos para calidadimp
http://slidepdf.com/reader/full/modelos-para-calidadimp 50/72
50
eXtreme Programming (XP)
Modelos ágiles
Las 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 agendael trabajo más importante.
3.- Entregas regulares y frecuentes para satisfacer la inversióndel cliente.
4.- Ritmo de trabajo sostenible, para terminar la jornadacansado pero no agotado.
Scrum
8/7/2019 Modelos para calidadimp
http://slidepdf.com/reader/full/modelos-para-calidadimp 51/72
51
Scrum
Modelos ágiles
No es propiamente un método o metodología de desarrollo, e implantarlo comotal resulta insuficiente.
Scrum define métodos de gestión y control para complementar la aplicación deotros 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 agregarlestrabajo extra.
Reuniones diarias en las que los miembros del equipo se plantean3 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 finalde las cuales se presenta el resultado a los externos del equipo dedesarrollo, y se realiza una planificación de la siguiente iteración, guiada
por cliente.
8/7/2019 Modelos para calidadimp
http://slidepdf.com/reader/full/modelos-para-calidadimp 52/72
52
Scrum
Modelos ágiles
Otros métodos ágiles
8/7/2019 Modelos para calidadimp
http://slidepdf.com/reader/full/modelos-para-calidadimp 53/72
53
Modelos ágiles
Otros métodos ágiles
Familia de métodos Crystal
La familia de metodologías Crystal ofrece diferentes métodos paraseleccionar el más apropiado para cada proyecto.
Crystal identifica con colores diferentes cada método, y su elección debe serconsecuencia del tamaño y criticidad del proyecto, de forma que los demayor tamaño, o aquellos en los que la presencia de errores odesbordamiento de agendas implique consecuencias graves, deben adoptarmetodologías más pesadas.
Los métodos Crystal no prescriben prácticas concretas
ASD (Adaptative Software Development)
Método que como alternativa a los procedimientos formales,
aborda el desarrollo de grandes sistemas con el uso de técnicaspropias de las metodologías ágiles.
No se trata de una metodología, sino de la implantación de unacultura en la empresa, basada en la adaptabilidad.
Otros métodos ágiles
8/7/2019 Modelos para calidadimp
http://slidepdf.com/reader/full/modelos-para-calidadimp 54/72
54
Modelos ágiles
Otros métodos ágiles
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 solucionarlos problemas cotidianos
AM (Agile Modeling)
Agile Modeling es la presentación de un nuevo enfoque para realizar elmodelado 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.
ISD (Internet Speed Development)Es el más reciente de los métodos ágiles, surgido como respuesta paralas situaciones que requieren ciclos de desarrollo muy breves conentregas rápidas.
Se centra en el talento de las personas sobre los procesos.
ISD es un entorno de gestión orientado al negocio
FDD (Feature Driven Development)Prescribe un proceso iterativo de 5 pasos, con iteraciones de dos semanas.Elpunto de referencia son las características que debe reunir el software, y secentra en las fases de diseño e implementación del sistema
8/7/2019 Modelos para calidadimp
http://slidepdf.com/reader/full/modelos-para-calidadimp 55/72
55
Modelos ágiles
Modelos 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 paraadaptarse a las necesidades de cada proyecto, en oposición a lo que sería una metodologíaprescriptiva; porque parte de la base de que no hay una estructura de procesos óptima para lasnecesidades de todos los entornos de desarrollo posibles.
El marco MSF se asienta sobre unos Principios Fundamentales que definen la cultura del entornode 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
8/7/2019 Modelos para calidadimp
http://slidepdf.com/reader/full/modelos-para-calidadimp 56/72
56
Modelos ágiles
Modelos de propiedad Comercial: MSF
Elementos que componen el modeloPrincipios 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 deproyecto, 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 diferentescondiciones de entornos reales
Prácticas opcionales, sugeridas por el modelo.
8/7/2019 Modelos para calidadimp
http://slidepdf.com/reader/full/modelos-para-calidadimp 57/72
57
Modelos ágiles
Modelos de propiedad Comercial: MSF
Relación entre los componentes del modeloEste diagrama es un ejemplo para mostrar la interconexión y relación entre los componentes deMicrosoft Solutions Framework
Aprender delas
experiencias
Modelo deprocesos
Disposición alaprendizaje
Hitos derevisión
Uso defacilitadores
externos
Permanecerágil y esperar
el cambio
Gestión deriesgos
Evaluacióncontinua de
riesgos
Definir ymonitorizardisparadoresde riesgos
Creación deuna 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” haganerado 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.
8/7/2019 Modelos para calidadimp
http://slidepdf.com/reader/full/modelos-para-calidadimp 58/72
58
Modelos ágiles
Modelos de propiedad Comercial: RUP
Rational Unified ProcessEs un proceso de Ingeniería del Software que proporciona una visión disciplinada para la asignaciónde tareas y responsabilidades en las organizaciones de desarrollo de software.
RUP es un “modelo-producto” desarrollado y mantenido por Racional Software, integrado en suconjunto de herramientas de desarrollo, y distribuido por IBM.
RUP integra un conjunto de “buenas prácticas” para el desarrollo de software en un marco deprocesos 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
8/7/2019 Modelos para calidadimp
http://slidepdf.com/reader/full/modelos-para-calidadimp 59/72
59
Modelos ágiles
Modelos de propiedad Comercial: RUP
Rational Unified Process: Visión estáticaEn 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 deadministración.
Actividades: RUP determina el trabajo de cada rol a través de actividades. Cada actividaddel proyecto debe tener un propósito claro, y se asigna a un rol específico. Las actividadespueden tener duración de horas o de algunos días; y son elementos base de planificación yprogreso.
Artefactos: Son los elementos de entrada y salida de las actividades. Son productostangibles del proyecto. Las cosas que el proyecto produce o usa para componer el productofinal (modelos, documentos, código, ejecutables…)
Disciplinas: son “contenedores” empleados para organizar las actividades del proceso. RUPcomprende 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, yconstituyen la secuencia de actividades que producen resultados visibles.
8/7/2019 Modelos para calidadimp
http://slidepdf.com/reader/full/modelos-para-calidadimp 60/72
60
Modelos ágiles
Modelos de propiedad Comercial: RUP
Rational Unified Process: Visión dinámicaEn su visión dinámica, la visión de la estructura del ciclo de vida RUP se basa en un desarrolloiterativo, jalonado por hitos para revisar el avance y planear la continuidad o los posibles cambios derumbo.
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 unaarquitectura 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. Laespecificación de las necesidades y el diseño de la arquitectura. Termina con el “hito deArquitectura”.
3.- Construcción. Desarrollo del producto hasta que se encuentra disponible para suentrega 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”.
8/7/2019 Modelos para calidadimp
http://slidepdf.com/reader/full/modelos-para-calidadimp 61/72
61
4.- Gestión de proyectos: formal y ágil4.- Gestión de proyectos: formal y ágil
8/7/2019 Modelos para calidadimp
http://slidepdf.com/reader/full/modelos-para-calidadimp 62/72
62
Cómo gestionar los proyectos de software
Referentes de la gestión formal de proyectosLas principales referencias de la gestión formal de proyectos son las asociaciones:
PMI (Project Management Institute) IPMA (International Project Management Association)
Y la metodología: PRINCE2 (Projects in Controlled Environments)
IPMA se constituyó en 1965, PMI lo hizo en 1969, y PRINCE2 se comenzó a desarrollar en 1989.
Forma inicial y evoluciónForma inicial y evoluciónPMI e IPMA son organizaciones que han ido desarrollando estándares, métodos y modelos decertificación profesional (www.pmi.org – www.ipma.ch).
Siguiendo un camino inverso, PRINCE2 no nace como asociación, sino como metodología alrededorde la cual se ha formado un grupo de desarrollo.
Gestión formal de proyectos
Gestión de proyectos
8/7/2019 Modelos para calidadimp
http://slidepdf.com/reader/full/modelos-para-calidadimp 63/72
63
Cómo gestionar los proyectos de software
Referentes de la gestión formal de proyectos
Ámbito global de la gestión formalÁmbito global de la gestión formalPMI E IPMA defienden que la gestión de proyectos comprende un cuerpo de conocimiento que debeser profesionalizado, y que resulta válido y aplicable a los proyectos de cualquier industria:construcción, química, aeroespacial, TI, etc.
Aunque en la actualidad también comparten esta visión, también en este caso el origen de PRINCE2fue el contrario: su desarrollo inicial lo llevó a cabo la CCTA (Central Computer andTelecommunications Agency) del Gobierno Británico, para que sirviera como estándar en losproyectos de Tecnologías de la Información. Sin embargo, el ámbito de aplicación se fue ampliandoy en su revisión de 1996 se le dio cobertura global para los proyectos de todas las industrias.
Gestión de proyectos
8/7/2019 Modelos para calidadimp
http://slidepdf.com/reader/full/modelos-para-calidadimp 64/72
64
Cómo gestionar los proyectos de software
Objeciones a la gestión formal de proyectosLos modelos ágiles para el desarrollo de software plantean objeciones a la teoría de la gestiónformal de proyectos.
Características específicas del softwareCaracterísticas específicas del software
El software no resulta comparable a la materia prima de otras ingenierías.
El software no es físico, y los sistemas de soft, a diferencia de los artefactos físicos son muymaleables. Por esta razón, resulta tendencioso comparar la construcción de un edificio, un avión, oun dispositivo de hardware con un sistema de software.
A nadie se le ocurriría construir un proyecto de arquitectura con el método de prueba y error,levantando las plantas del edificio para luego demolerlas, o ampliarlas si no son como desea elcliente; o desarrollar una embarcación básica, para ir ampliando y modificando sus características, amedida que por el uso las van descubriendo los clientes.
Sin embargo con el software esto es posible.
Los 12 principios del Manifiesto Ágil (v. agilidad y procesos) plantean principios que pueden resultarviables para los proyectos de software de determinadas características, pero que se apartan de losmétodos formales de gestíón.
¿Es posible un marco único y universal para la gestión de proyectos?
Los 12 principios del Manifiesto Ágil (v. agilidad y procesos) plantean principios que pueden resultarviables para los proyectos de software de determinadas características, pero que se apartan de losmétodos formales de gestíón.
¿Es posible un marco único y universal para la gestión de proyectos?
Gestión de proyectos
8/7/2019 Modelos para calidadimp
http://slidepdf.com/reader/full/modelos-para-calidadimp 65/72
65
Cómo gestionar los proyectos de software
Referentes de la gestión ágil de proyectosLas principales referencias de la gestión ágil de proyectos son:
Scrum Rational Unified Process (RUP) Microsoft Solutions Framework (MSF)
CaracterísticasCaracterísticas
Scrum es un modelo ágil no centrado en prácticas de programación (como XP p. ej.), sino enprácticas de gestión. Por eso puede y suele combinarse Scrum junto con otro de prácticas técnicas.RUP.Rational Unified Process es un proceso iterativo para desarrollo de software creado por RationalSoftware (IBM).MSF es un marco de desarrollo que define procesos, principios, modelos, disciplinas, conceptos yprácticas contrastadas por Microsoft.No son modelos de procesos sino marcos de trabajo adaptables a las circunstancias de lasorganizaciones de los proyectos.
Gestión ágil de proyectos
Gestión de proyectos
8/7/2019 Modelos para calidadimp
http://slidepdf.com/reader/full/modelos-para-calidadimp 66/72
66
Cómo gestionar los proyectos de software
Fundamentos de la cultura ágil con problemas de encaje enla gestión formal de proyectos
Gestión de proyectos
Entrega temprana de software operativo.
Trabajo con incertidumbre de requisitos, y apertura constante a cambios en los mismos.
Entregas frecuentes de funcionalidades operativas.
Preferencia de la comunicación verbal sobre otros medios. Infravaloración de métricas teóricas y formales, considerando como válida “el software que
funciona”.
Auto-organización de equipos.
La gestión formal se asienta sobre la dirección del proyecto sobre un plan general con visibilidad yámbito de certidumbre hasta el final del proyecto.
La planificación de la gestión ágil es informal (algunos modelos llegan a prohibir el uso de diagramasde Gannt), y solo cubre el ciclo de software que se está elaborando (generalmente 1 mes).La gestión formal hace hincapié en la necesidad de conocer con el mayor detalle los requisitos desdeel principio para dar rigor al plan del proyecto.La gestión ágil
La gestión formal se asienta sobre la dirección del proyecto sobre un plan general con visibilidad yámbito de certidumbre hasta el final del proyecto.
La planificación de la gestión ágil es informal (algunos modelos llegan a prohibir el uso de diagramasde Gannt), y solo cubre el ciclo de software que se está elaborando (generalmente 1 mes).La gestión formal hace hincapié en la necesidad de conocer con el mayor detalle los requisitos desdeel principio para dar rigor al plan del proyecto.La gestión ágil
8/7/2019 Modelos para calidadimp
http://slidepdf.com/reader/full/modelos-para-calidadimp 67/72
67
Desavenencias
Gestión de proyectos
Trabajo y gestión guiada por un plan general delproyecto que comprende todo su ciclo dedesarrollo.
Trabajo y gestión guiada por un plan general delproyecto que comprende todo su ciclo dedesarrollo.
La planificación del trabajo sólo comprende el cicloen el que se está trabajando (normalmente 30días). Algunos modelos ágiles prohíben el uso degráficos de Gantt
La planificación del trabajo sólo comprende el cicloen el que se está trabajando (normalmente 30días). Algunos modelos ágiles prohíben el uso degráficos de Gantt
Conocimiento detallado de los requisitos antes decomenzar el diseño del proyectoConocimiento detallado de los requisitos antes decomenzar el diseño del proyecto
Descubrimiento progresivo de requisitos, eincorporación de cambios en cualquier iteración deldesarrollo
Descubrimiento progresivo de requisitos, eincorporación de cambios en cualquier iteración deldesarrollo
“Hacerlo bien a la primera”.Evitar la re-codificación y el re-trabajo que suponeuna pérdida de eficiencia.
“Hacerlo bien a la primera”.Evitar la re-codificación y el re-trabajo que suponeuna pérdida de eficiencia.
“Refactorización” de código como modelo detrabajo compatible con el punto anterior.“Refactorización” de código como modelo detrabajo compatible con el punto anterior.
Comunicación formal según el plan decomunicación del proyectoComunicación formal según el plan decomunicación del proyecto
Comunicación directa entre los integrantes delequipo (incluidos cliente y usuarios) prefiriendo laverbal directa.
Comunicación directa entre los integrantes delequipo (incluidos cliente y usuarios) prefiriendo laverbal directa.
Gestión de equipos y personas centralizada en elgestor del proyectoGestión de equipos y personas centralizada en elgestor del proyecto
Equipos auto-gestionados.Equipos auto-gestionados.
Gestión formalGestión formal Gestión ágilGestión ágil
8/7/2019 Modelos para calidadimp
http://slidepdf.com/reader/full/modelos-para-calidadimp 68/72
8/7/2019 Modelos para calidadimp
http://slidepdf.com/reader/full/modelos-para-calidadimp 69/72
69
Gestión de proyectos: principales conceptos y prácticas
Gestión de riesgos
IDENTIFICACIÓN
ANÁLISIS
TRATAMIENTO
G
ESTIÓ
N
DERIESG
OS
Plan de gestiónde riesgos
IEEE Std P1540-2001
Gestión formal de proyectos
8/7/2019 Modelos para calidadimp
http://slidepdf.com/reader/full/modelos-para-calidadimp 70/72
70
Gestión de proyectos: principales conceptos y prácticas
Gestión de riesgosCausas y consecuenciasCausas y consecuencias
Causa
Causa
CONSECUENCIACONSECUENCIA
CONSECUENCIACONSECUENCIA
CONSECUENCIACONSECUENCIA
consecuenciaconsecuencia
consecuenciaconsecuencia
consecuenciaconsecuencia
Requisitos
crecientes
Requisitos
crecientes
Más horasMás horas
Presión equipoPresión equipo
Desbordamientocostes
Desbordamientocostes
IncumplimientofechasIncumplimientofechas
Más errorespeor calidadMás errorespeor calidad
Desmotivaciónmenor eficienciaDesmotivación
menor eficiencia
Gestión formal de proyectos
8/7/2019 Modelos para calidadimp
http://slidepdf.com/reader/full/modelos-para-calidadimp 71/72
71
Gestión de proyectos: principales conceptos y prácticas
Gestión de riesgos
Gestión formal de proyectos
La gestión de proyectos incorpora métodos sistemáticos de control de riesgos consoluciones genéricas.
La gestión de proyectos incorpora métodos sistemáticos de control de riesgos consoluciones genéricas.
RIESGO TIPORIESGO TIPO
Desbordamiento de costesDesbordamiento de costes
Errores en los productosErrores en los productos
Procesos de desarrolloincontrolados
Procesos de desarrolloincontrolados
Producto incontroladoProducto incontrolado
Problemas de comunicaciónProblemas de comunicación
SOLUCIÓN TIPOSOLUCIÓN TIPO
Verificación / validación derequisitos y diseño
Verificación / validación derequisitos y diseño
Verificación / validaciónpruebas en el desarrolloVerificación / validaciónpruebas en el desarrollo
Desarrollo sobre procesosdefinidos
Desarrollo sobre procesosdefinidos
Gestión de la configuraciónSQA
Gestión de la configuraciónSQA
Normalización document.Comunicación, resolución prob.
Normalización document.
Comunicación, resolución prob.
Si en un proyecto se adecuan las decisiones importantes, la planificación, los recursos, elpresupuesto y el esfuerzo para reducir las probabilidades y el impacto de los riesgos,entonces se puede considerar que hay una GESTIÓN DE RIESGOS.
Cuando los riesgos se conocen y tratan con el “estándar” propio de la gestión deproyectos resulta más propio decir que los riesgos se tratan a través de la GESTIÓN DELPROYECTO.
Si en un proyecto se adecuan las decisiones importantes, la planificación, los recursos, elpresupuesto y el esfuerzo para reducir las probabilidades y el impacto de los riesgos,entonces se puede considerar que hay una GESTIÓN DE RIESGOS.
Cuando los riesgos se conocen y tratan con el “estándar” propio de la gestión deproyectos resulta más propio decir que los riesgos se tratan a través de la GESTIÓN DELPROYECTO.
8/7/2019 Modelos para calidadimp
http://slidepdf.com/reader/full/modelos-para-calidadimp 72/72
Roles: gallinas y cerdos
Una gallina y un cerdo paseaban por la carretera. La gallina dijo alcerdo: “Quieres abrir un restaurante conmigo”. El cerdo consideró lapropuesta y respondió: “Sí, me gustaría. ¿Y cómo lo llamaríamos?”. Lagallina respondió: “Huevos con beicon”.
Una gallina y un cerdo paseaban por la carretera. La gallina dijo alcerdo: “Quieres abrir un restaurante conmigo”. El cerdo consideró lapropuesta y respondió: “Sí, me gustaría. ¿Y cómo lo llamaríamos?”. Lagallina respondió: “Huevos con beicon”.
El cerdo se detuvo, hizo una pausa y contestó: “Pensándolo mejor,creo que no voy a abrir un restaurante contigo. Yo estaría
realmente comprometido, mientras que tu estarías sólo implicada”.
El cerdo se detuvo, hizo una pausa y contestó: “Pensándolo mejor,creo que no voy a abrir un restaurante contigo. Yo estaría
realmente comprometido, mientras que tu estarías sólo implicada”.
COMPROMETIDOS EN EL PROYECTODueño del producto
IMPLICADOS EN EL PROYECTOMarketingComercial
Scrum diferencia claramente entre estosdos grupos para garantizar que quienestienen la responsabilidad tienen también
la autoridad necesaria para poder lograrel éxito, y que quienes no tienen la
responsabilidad no produceninterferencias innecesarias
Scrum diferencia claramente entre estosdos grupos para garantizar que quienestienen la responsabilidad tienen también
la autoridad necesaria para poder lograrel éxito, y que quienes no tienen la
responsabilidad no produceninterferencias innecesarias
Gestión ágil de proyectos: Scrum