Modelo CMMI y métodos ágiles en la gestión de proyectos software

136 Pages·2017·2.1 MB·Spanish

UNIVERSIDAD DE OVIEDO
DEPARTAMENTO DE EXPLOTACIO´N Y PROSPECCIO´N DE MINAS
MASTER INTERUNIVERSITARIO EN “DIRECCIO´N DE PROYECTOS”
Trabajo Fin de Master
Modelo CMMI y m´etodos ´agiles
en la gestio´n de proyectos
software
Autor: Juan Alonso Baldonedo
Director: Vicente Rodr´ıguez Montequ´ın
Junio 2017
Resumen
EsteTFMbuscaabordarc´omodosa´reasdelaingenier´ıadesoftwareaparentemen-
te incompatibles como el modelo de mejora de procesos CMMI y las metodolog´ıas
de desarrollo ´agiles pueden ser utilizadas de manera cooperativa para mejorar el
´exito de los proyectos software. Para poder comprender por qu´e puede ser intere-
sante esta cooperacio´n es necesario analizar cua´les son las caracter´ısticas de los
m´etodos a´giles, qu´e m´etodos existen y qu´e los diferencia de los tradicionales. Por
otro lado, necesitamos entender tambi´en el proceso software y co´mo ayudar CM-
MI a mejorarlo. Para ello debemos entender qu´e elementos componentes CMMI y
co´mo se estructuran. Solo de esta manera podremos llegar a entender co´mo surge
el CMMI a´gil.
´
Indice general
Resumen 1
1. Introduccio´n 9
1.1. Introduccio´n . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.2. Motivaci´on Trabajo Fin de Ma´ster . . . . . . . . . . . . . . . . . . 10
1.3. Gestio´n de proyectos . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.4. Gestio´n de Proyectos Software . . . . . . . . . . . . . . . . . . . . . 11
2. Ingenier´ıa de Software 14
2.1. Introduccio´n . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2. El proceso software . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.3. Actividades del proceso software . . . . . . . . . . . . . . . . . . . . 17
2.3.1. Especificacio´n . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.3.2. Disen˜o e implementacio´n . . . . . . . . . . . . . . . . . . . . 18
2.3.3. Validacio´n y verificaci´on . . . . . . . . . . . . . . . . . . . . 19
2.3.4. Evoluci´on . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.4. Cambios Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.5. Paradigmas y modelos de proceso software . . . . . . . . . . . . . . 21
2.5.1. El ciclo de vida de desarrollo software . . . . . . . . . . . . . 22
2.5.2. Waterfall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.5.3. Modelo desarrollo en V . . . . . . . . . . . . . . . . . . . . . 24
2.5.4. Prototipado . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.5.5. M´etodo Incremental . . . . . . . . . . . . . . . . . . . . . . 25
2.5.6. M´etodo en Espiral . . . . . . . . . . . . . . . . . . . . . . . 26
2.5.7. Rational Unified Process (RUP) . . . . . . . . . . . . . . . . 27
2.5.8. Otros m´etodos . . . . . . . . . . . . . . . . . . . . . . . . . 29
3. M´etodos A´giles 30
2
3.1. Introduccio´n . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
´
3.2. El manifiesto Agil . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
´
3.3. Metodolog´ıas Agiles . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.3.1. Agile modeling . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.3.2. Adaptive software development . . . . . . . . . . . . . . . . 34
3.3.3. Feature-driven development . . . . . . . . . . . . . . . . . . 35
3.3.4. Extreme programming . . . . . . . . . . . . . . . . . . . . . 37
3.3.5. Agile Unified Process . . . . . . . . . . . . . . . . . . . . . . 38
3.3.6. Dynamic systems development method . . . . . . . . . . . . 40
3.3.7. Lean software development . . . . . . . . . . . . . . . . . . . 42
3.3.8. Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.3.9. Kanban . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.3.10. Scrumban . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4. CMMI 49
4.1. Introduccio´n . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.2. Mejora basada en procesos . . . . . . . . . . . . . . . . . . . . . . . 50
4.2.1. El proceso de mejora de procesos . . . . . . . . . . . . . . . 51
4.2.2. Medici´on de Procesos . . . . . . . . . . . . . . . . . . . . . . 52
4.2.3. An´alisis de Procesos . . . . . . . . . . . . . . . . . . . . . . 55
4.2.4. Proceso de cambio . . . . . . . . . . . . . . . . . . . . . . . 57
4.3. Qu´e es CMMI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.4. Modelo de Trabajo CMMI . . . . . . . . . . . . . . . . . . . . . . . 60
4.4.1. CMMI-DEV . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.4.2. CMMI-ACQ . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.4.3. CMMI-SVC . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.5. Beneficio Potencial de CMMI . . . . . . . . . . . . . . . . . . . . . 61
´
4.6. Areas de Proceso CMMI . . . . . . . . . . . . . . . . . . . . . . . . 62
4.6.1. Objetivo Espec´ıfico (SG) . . . . . . . . . . . . . . . . . . . . 63
4.6.2. Pr´acticas Espec´ıficas . . . . . . . . . . . . . . . . . . . . . . 64
4.6.3. PA en los modelos CMMI . . . . . . . . . . . . . . . . . . . 64
4.6.4. Objetivos gen´ericos (GG) . . . . . . . . . . . . . . . . . . . 66
4.6.5. Pr´acticas Gen´ericas (GPs) . . . . . . . . . . . . . . . . . . . 66
4.6.6. Informaci´on Adicional . . . . . . . . . . . . . . . . . . . . . 66
´
4.7. Descripcio´n Areas de Proceso . . . . . . . . . . . . . . . . . . . . . 67
3
4.7.1. Requirements Management (REQM) . . . . . . . . . . . . . 67
4.7.2. Project Planning (PP) . . . . . . . . . . . . . . . . . . . . . 67
4.7.3. Project Monitoring and Control (PMC) . . . . . . . . . . . . 70
4.7.4. Risk Management (RSKM) . . . . . . . . . . . . . . . . . . 72
4.7.5. Supplier Agreement Management (SAM) . . . . . . . . . . . 73
4.7.6. Configuration Management (CM) . . . . . . . . . . . . . . . 74
4.7.7. Process and Product Quality Assurance (PPQA) . . . . . . 76
4.7.8. Measurement and Analysis (MA) . . . . . . . . . . . . . . . 77
4.7.9. Decision Analysis and Resolution (DAR) . . . . . . . . . . . 79
4.7.10. Organizational Process Focus (OPF) . . . . . . . . . . . . . 80
4.7.11. Organizational Process Definition (OPD) . . . . . . . . . . . 81
4.7.12. Integrated Project Management (IPM) . . . . . . . . . . . . 82
4.7.13. Organizational Training (OT) . . . . . . . . . . . . . . . . . 84
4.7.14. Requirements Development (RD) . . . . . . . . . . . . . . . 85
4.7.15. Technical Solution (TS) . . . . . . . . . . . . . . . . . . . . 87
4.7.16. Product Integration (PI) . . . . . . . . . . . . . . . . . . . . 89
4.7.17. Verification (VER) . . . . . . . . . . . . . . . . . . . . . . . 89
4.7.18. Validaci´on (VAL) . . . . . . . . . . . . . . . . . . . . . . . . 92
4.7.19. Organizational Process Performance (OPP) . . . . . . . . . 93
4.7.20. Quantitative Project Management (QPM) . . . . . . . . . . 94
4.7.21. Causal Analysis and Resolution (CAR) . . . . . . . . . . . . 95
4.7.22. Organizational Process Management (OPM) . . . . . . . . . 96
4.7.23. Objetivos y Pra´cticas Gen´ericas (GG/GP) . . . . . . . . . . 97
4.8. Representaciones CMMI . . . . . . . . . . . . . . . . . . . . . . . . 99
4.8.1. Representacio´n Continua . . . . . . . . . . . . . . . . . . . . 99
4.8.2. Representacio´n por Etapas . . . . . . . . . . . . . . . . . . . 102
4.8.3. Elecci´on de representacio´n CMMI . . . . . . . . . . . . . . . 102
4.9. Niveles CMMI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
4.9.1. Niveles de capacidad . . . . . . . . . . . . . . . . . . . . . . 104
4.9.2. Niveles de madurez . . . . . . . . . . . . . . . . . . . . . . . 104
4.10.Evaluacio´n CMMI . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
5. CMMI A´gil 108
´
5.1. Percepcio´n del CMMI Agil . . . . . . . . . . . . . . . . . . . . . . . 108
5.1.1. Falta de uso y uso incorrecto . . . . . . . . . . . . . . . . . . 109
4
5.1.2. Falta de informaci´on precisa . . . . . . . . . . . . . . . . . . 109
5.1.3. Terminolog´ıa confusa . . . . . . . . . . . . . . . . . . . . . . 109
5.2. Combinando CMMI y Agile . . . . . . . . . . . . . . . . . . . . . . 110
5.2.1. Retos al usar m´etodos ´agiles . . . . . . . . . . . . . . . . . . 110
5.2.2. Retos al usar CMMI . . . . . . . . . . . . . . . . . . . . . . 112
´
5.3. Areas de Proceso CMMI y SCRUM . . . . . . . . . . . . . . . . . . 113
5.3.1. Project Planning (PP) y SCRUM . . . . . . . . . . . . . . . 113
5.3.2. Project Monitoring and Control (PMC) y SCRUM . . . . . 114
5.3.3. Requirements Management (REQM) y SCRUM . . . . . . . 115
´
5.4. Ejemplo Pra´ctico de CMMI Agile . . . . . . . . . . . . . . . . . . . 115
5.4.1. Escenario base . . . . . . . . . . . . . . . . . . . . . . . . . 115
5.4.2. Implementacio´n CMMI y SCRUM: Gestio´n del proyecto . . 116
5.4.3. Implementacio´n CMMI y SCRUM: Entorno de desarrollo . . 118
5.4.4. Implementacio´n CMMI y SCRUM: Proceso de desarrollo. . . 123
6. Conclusiones Finales y L´ıneas de Futuro 128
6.1. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
6.2. L´ıneas de Futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
Bibliograf´ıa 131
5
´
Indice de figuras
2.1. Tri´angulo de gesti´on de proyectos . . . . . . . . . . . . . . . . . . . 15
2.2. Modelo general del proceso de disen˜o . . . . . . . . . . . . . . . . . 19
2.3. Fases de pruebas software . . . . . . . . . . . . . . . . . . . . . . . 20
2.4. Modelo “waterfall” o de cascada . . . . . . . . . . . . . . . . . . . . 23
2.5. Modelo desarrollo en V . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.6. Proceso de desarrollo de prototipo . . . . . . . . . . . . . . . . . . . 25
2.7. Modelo incremental . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.8. Modelo en espiral . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.1. Proceso software con Agile Modeling . . . . . . . . . . . . . . . . . 34
3.2. Proceso software con ASD . . . . . . . . . . . . . . . . . . . . . . . 35
3.3. Esquema de releases en AUP . . . . . . . . . . . . . . . . . . . . . 40
3.4. Fases de desarrollo DSDM . . . . . . . . . . . . . . . . . . . . . . . 41
3.5. Ciclo de vida Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.6. Tablero de trabajo Kanban . . . . . . . . . . . . . . . . . . . . . . . 47
4.1. Ciclo de mejor de procesos . . . . . . . . . . . . . . . . . . . . . . . 53
4.2. Paradigma GQM . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.3. Proceso de cambio de procesos . . . . . . . . . . . . . . . . . . . . . 58
4.4. Esquema del ´area de proceso CMMI . . . . . . . . . . . . . . . . . . 63
4.5. Niveles de capacidad CMMI . . . . . . . . . . . . . . . . . . . . . . 104
4.6. Niveles de madurez CMMI . . . . . . . . . . . . . . . . . . . . . . . 105
5.1. Entorno de desarrollo CMMI a´gil. . . . . . . . . . . . . . . . . . . . 119
5.2. Ejemplo WBS de un proyecto software. . . . . . . . . . . . . . . . . 124
6
´
Indice de cuadros
1.1. Resultados informe CHAOS . . . . . . . . . . . . . . . . . . . . . . 12
3.1. Hitos y porcentaje asociado de una actividad FDD . . . . . . . . . 36
4.1. Atributos gen´ericos de procesos . . . . . . . . . . . . . . . . . . . . 52
4.2. Algunos aspectos del ana´lisis de procesos. . . . . . . . . . . . . . . . 56
4.3. Mejoras obtenidas por categor´ıas. . . . . . . . . . . . . . . . . . . . 62
´
4.4. Area de proceso: Requirements Management (REQM) . . . . . . . . 68
´
4.5. Area de proceso: Project Planning (PP) . . . . . . . . . . . . . . . 69
´
4.6. Area de proceso: Project Monitoring and Control (PMC) . . . . . . 71
´
4.7. Area de proceso: Risk Management (RSKM) . . . . . . . . . . . . . 72
´
4.8. Area de proceso: Supplier Agreement Management (SAM) . . . . . 74
´
4.9. Area de proceso: Configuration Management (CM) . . . . . . . . . 75
´
4.10.Area de proceso: Process and Product Quality Assurance (PPQA) . 77
´
4.11.Area de proceso: Measurement and Analysis (MA) . . . . . . . . . . 78
´
4.12.Area de proceso: Decision Analysis and Resolution (DAR) . . . . . 79
´
4.13.Area de proceso: Organizational Process Focus (OPF) . . . . . . . . 80
´
4.14.Area de proceso: Organizational Process Definition (OPD) . . . . . 82
´
4.15.Area de proceso: Integrated Project Management (IPM) . . . . . . 83
´
4.16.Area de proceso: Organizational Training (OT) . . . . . . . . . . . 85
´
4.17.Area de proceso: Requirements Development (RD) . . . . . . . . . . 86
´
4.18.Area de proceso: Technical Solution (TS) . . . . . . . . . . . . . . . 88
´
4.19.Area de proceso: Product Integration (PI) . . . . . . . . . . . . . . 90
´
4.20.Area de proceso: Verification (VER) . . . . . . . . . . . . . . . . . . 91
´
4.21.Area de proceso: Validaci´on (VAL) . . . . . . . . . . . . . . . . . . 92
´
4.22.Area de proceso: Organizational Process Performance (OPP . . . . 94
´
4.23.Area de proceso: Quantitative Project Management (QPM) . . . . . 95
´
4.24.Area de proceso: Causal Analysis and Resolution (CAR) . . . . . . 96
7
´
4.25.Area de proceso: Organizational Process Management (OPM) . . . 98
4.26.Procesos y pra´cticas gen´ericas (GG/GP) . . . . . . . . . . . . . . . 100
4.27.Clasificacio´n de ´areas de proceso CMMI . . . . . . . . . . . . . . . 101
´
4.28.Areas de proceso asociadas a cada nivel de madurez del modelo por
etapas CMMI. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
4.29.Comparativa de los m´etodos de evaluaci´on CMMI SCAMPI. . . . . 107
5.1. Mapeo de SCRUM en ´area de proceso (PP) . . . . . . . . . . . . . 114
5.2. Mapeo de SCRUM en ´area de proceso (PMC) . . . . . . . . . . . . 114
5.3. Mapeo de SCRUM en ´area de proceso (PMC) . . . . . . . . . . . . 115
5.4. Herramientas utilizadas en la integraci´on continua por lenguaje. . . 122
8
Cap´ıtulo 1
Introduccio´n
1.1. Introduccio´n
Durante las u´ltimas d´ecadas, el software ha sido protagonista activo en nume-
rosos cambios sociales, t´ecnicos y culturales. Gracias a ´el, hemos experimentando
una verdadera revoluci´on en el mundo de las t´ecnica, la medicina, las artes, las
relaciones personales, y por supuesto ha sido el motor de la inform´atica, sin duda
una industria que ha redefinido buena parte de las actividades humanas.
Para lograr esta revolucio´n, a la que au´n estamos asistiendo, ha sido necesario
que en torno al software surja una nueva forma de hacer ingenier´ıa. La necesidad
de desarrollar nuevas formas viene dado por la propia naturaleza intangible del
software. En su libro “The Pragmatic Programmer” Andrew Hunt [1] destaca las
diferencias entre la ingenier´ıa tradicional y la ingenier´ıa de software de la siguiente
manera:
While you can plan a house or a skyscraper, such as an analogy for software
engineering can hardly be used [...] Software is more like gardening. Plan the
garden, plant the plants. Then see whats growing, remove weeds and plant
new plants.
A simple vista la visio´n de Hunt es la de que el software tiene ma´s de proceso
art´ıstico que ingenieril. Sin embargo, si hacemos una lectura minuciosa de las
palabras de Hunt, vemos que en realidad est´a describiendo una serie de procesos:
planificar,hacer,comprobar yactuar.Estosnodistandesersimilaresalosprocesos
quenosencontrar´ıamosenotrasramasdelaingenier´ıa,peroenelcasodelsoftware
veremos que los modelos tradicionales de trabajo presentan serios problemas e
inconvenientes que deber´an ser atajados con otros modelos que permitan afrontar
lasdificultadesplanteadasporlayamencionadanaturalezaintangibledelsoftware.
Co´mo organizar los procesos de desarrollo software de forma que el resulta-
do sea un software barato, de calidad, que satisfaga las expectativas del cliente,
mantenible y obtenido en un tiempo razonable se ha convertido en el uno de los
grandes retos de la ingenier´ıa de software.
9