Modelo para la gestión del conocimiento y la … · Modelo para la gestión del conocimiento y la...
393
UNIVERSIDAD POLITECNICA DE MADRID FACULTAD DE INFORMATICA Modelo para la gestión del conocimiento y la experiencia integrada a las prácticas y procesos de desarrollo software TESIS DOCTORAL MC D. Gerardo Matturro Mazoni 2010
Transcript of Modelo para la gestión del conocimiento y la … · Modelo para la gestión del conocimiento y la...
UNIVERSIDAD POLITECNICA DE MADRID
FACULTAD DE INFORMATICA
Modelo para la gestión del conocimiento y la experiencia integrada a las prácticas y procesos
de desarrollo software
TESIS DOCTORAL
MC D. Gerardo Matturro Mazoni 2010
i
Resumen
Los conocimientos y experiencia que los miembros de los equipos de proyecto crean y
adquieren durante los proyectos software constituyen un valioso activo para las
organizaciones que buscan mejorar sus prácticas y procesos software.
Los enfoques existentes para capturar y gestionar esos conocimientos y experiencia se
basan esencialmente en la creación y mantenimiento de repositorios de experiencias pero
no prescriben la manera ni el momento en que los diferentes procesos de gestión del
conocimiento deben llevarse a cabo.
En esta tesis se propone un modelo para la gestión del conocimiento y la experiencia cuyas
fases y tareas se integran a las actividades de los proyectos software así como a las de
mejora de las prácticas y procesos software en uso en una organización.
Se propone también una herramienta para capturar los conocimientos y experiencias en
forma simultánea a la realización de las actividades de proyecto, que se diferencia de los
modos tradicionales basados en el análisis post mortem de proyectos y técnicas similares.
Finalmente, se presenta el estudio de caso de una implementación práctica del modelo y la
herramienta propuestos. Este estudio permitió determinar que el modelo es viable de ser
implementado, que su integración a las actividades de proyecto no constituye una
sobrecarga de trabajo para los miembros de los equipos de proyecto, y que a partir de su
aplicación es posible identificar lecciones aprendidas y mejores prácticas relativas a las
prácticas y procesos software en uso en la organización.
ii
Abstract
The knowledge and experience that team members create and acquire during software
projects constitute a valuable asset for organizations that seek to improve their software
development practices and processes.
The existing approaches for capturing and managing that knowledge and experience are
based essentially on the creation and maintenance of repositories of experiences but they
don't prescribe the way in that the different knowledge management processes should be
carried out.
In this thesis a model for knowledge and experience management is proposed, whose
phases and tasks are integrated into the software projects activities as well as into those for
improving the software practices and processes in use in an organization.
It is also proposed a tool for capturing knowledge and experience in a simultaneous way to
the project activities that differs from traditional approaches based on project postmortem
analysis and similar techniques.
Finally, a case study of a practical implementation of the model and tool is presented. This
study allowed to determine that the proposed model is viable of being implemented, that its
integration to the project tasks doesn't means an overwork for the members of the project
teams, and that from its application it is possible to identify lessons learned and best
practices related to the software practices and processes in use in the organization.
iii
Agradecimientos
El largo período de estudio y de trabajo que implicó la realización de esta tesis doctoral
ha supuesto estar vinculado en forma constante a dos prestigiosas universidades como lo
son la Universidad ORT Uruguay y la Universidad Politécnica de Madrid.
En ambas, muchas personas han colaborado y me han brindado su apoyo y aliento
permanentes, y quiero aquí expresar mi agradecimiento a todos ellos.
En la Universidad ORT Uruguay, al Rector Dr. Jorge Grünberg, al Decano de
desarrollo académico Ing. Julio Fernández, al Decano de la Facultad de Ingeniería Ing.
Mario Fernández, a la Secretaria Docente de la Escuela de Ingeniería Dra. Patricia Corbo, al
Secretario Docente de la Escuela de Tecnología Víctor Paulós, así como también a Marta
Castro, Armando Gervaz, Marcos Delgado, Roberto Ambrosoni, Carmen Signorelli y Daniel
Pereyra.
Agradezco también a la Dra. Inés Friss de Kereki y al Dr. Pedro Salvetto por los
valiosos comentarios y consejos que me brindaron a lo largo de todo el proceso.
Un particular reconocimiento a la Lic. Laura Rodríguez y a la Lic. Ana Estela, quienes
colaboraron en forma eficaz y profesional en la investigación de campo llevada a cabo en el
marco de esta tesis.
También deseo expresar mi agradecimiento a los integrantes del Departamento de
Ingeniería de Software, Gastón Mousqués, Amalia Alvarez, Mariel Feder, Rafel Bentancur,
Alvaro Ortas, Martín Solari y Leonardo Scafarelli.
Fuera de ámbito universitario, mi agradecimiento al Programa de Desarrollo
Tecnológico (PDT) del Ministerio de Educación y Cultura de Uruguay que colaboró en el
financiamiento de mis estudios.
En la Universidad Politécnica de Madrid, un particular y profundo agradecimiento a mi
director de tesis, Dr. Andrés Silva, por su constante apoyo y dedicación, sus críticas y
comentarios constructivos, sus inteligentes consejos y por estar siempre bien dispuesto a
responder prestamente a mis consultas, tanto en sus períodos de actividad académica como
en sus momento de vacaciones.
También deseo expresar mi particular agradecimiento a los Dres. Juan Pazos,
Edmundo Tovar y Gonzalo Cuevas por sus valiosos consejos y comentarios que ciertamente
contribuyeron a mejorar la calidad de este trabajo.
Agradezco también al Dr. José Luis Morant, quien colaboró con todas las gestiones y a
la Sra. Alicia Andrés que me asistió en los diversos trámites administrativos.
Montevideo, diciembre de 2008
iv
v
Contenido
RESUMEN ................................................................................................................................ I ABSTRACT ............................................................................................................................. II 1. INTRODUCCIÓN ................................................................................................................. 1
1.1 La gestión del conocimiento en ingeniería de software ................................................. 1
1.2 Finalidad de la tesis ....................................................................................................... 4
1.3 Estructura de la tesis ...................................................................................................... 5
1.4 Aportes de la tesis .......................................................................................................... 7
2. ESTADO DE LA CUESTIÓN .............................................................................................. 9 2.1 El conocimiento y su gestión .......................................................................................... 9
2.2 Aprendizaje individual y organizacional ....................................................................... 33
2.3 Conocimiento y aprendizaje en Ingeniería de Software ............................................... 41
2.4 La organización software que aprende ........................................................................ 43
2.5 Fábricas y bases de experiencia .................................................................................. 44
2.6 Mejora de las prácticas y procesos software ............................................................... 47
2.7 Conocimiento y aprendizaje para la mejora del proceso ............................................. 56
2.8 Valoración de conocimientos, experiencia y aprendizaje ............................................ 60
2.9 Trabajos relacionados .................................................................................................. 66
2.10 Problemas de los enfoques existentes ...................................................................... 81
3. PLANTEAMIENTO DEL PROBLEMA .............................................................................. 85 3.1 Críticas a los trabajos relacionados ............................................................................. 85
3.2 El problema .................................................................................................................. 88
4. SOLUCIÓN PROPUESTA ................................................................................................ 89 4.1 Consideraciones iniciales ............................................................................................. 89
4.2 La solución propuesta .................................................................................................. 89
4.3 Presentación del modelo .............................................................................................. 91
4.4 Descripción del modelo ................................................................................................ 94
4.5 Otros elementos constitutivos del modelo ................................................................. 110
4.6 Conclusiones .............................................................................................................. 123
5. DEMOSTRACIÓN EMPÍRICA ......................................................................................... 129 5.1 El contexto general de la investigación ...................................................................... 131
5.2 El diseño de la investigación ...................................................................................... 133
5.3 Desarrollo general de la investigación ....................................................................... 142
5.4 Resultados obtenidos ................................................................................................. 151
5.5 Análisis de los resultados ........................................................................................... 167
vi
5.6 Conclusiones del estudio ........................................................................................... 173
5.7 Validez y fiabilidad del estudio ................................................................................... 174
6. CONCLUSIONES ............................................................................................................ 177 7. FUTURAS LÍNEAS DE INVESTIGACIÓN ...................................................................... 181 8. BIBLIOGRAFÍA ............................................................................................................... 183 APÉNDICE 1. SOBRE LA METODOLOGÍA DE INVESTIGACIÓN SELECCIONADA ...... 201
A1.1 Paradigmas de investigación ................................................................................... 201
A1.2 Elección del método de investigación ...................................................................... 202
A1.3 El estudio de casos en Ingeniería de Software ........................................................ 204
A1.4 Diseño de la investigación ....................................................................................... 204
APÉNDICE 2. INSTRUMENTOS DE RECOLECCIÓN DE DATOS .................................... 211 APÉNDICE 3. BASE DE DATOS DEL ESTUDIO ............................................................... 231 APÉNDICE 4. MANUAL DE IMPLEMENTACIÓN DEL MODELO ..................................... 335
vii
Contenido detallado
RESUMEN ................................................................................................................................ I ABSTRACT ............................................................................................................................. II 1. INTRODUCCIÓN ................................................................................................................. 1
1.1 La gestión del conocimiento en ingeniería de software ................................................. 1
1.2 Finalidad de la tesis ....................................................................................................... 4
1.3 Estructura de la tesis ...................................................................................................... 5
1.4 Aportes de la tesis .......................................................................................................... 7
2. ESTADO DE LA CUESTIÓN .............................................................................................. 9 2.1 El conocimiento y su gestión .......................................................................................... 9
2.1.1 Conocimiento ........................................................................................................... 9
2.1.2 Taxonomías del conocimiento ............................................................................... 12
2.1.3 Gestión del conocimiento ...................................................................................... 15
2.1.4 Estrategias para la gestión del conocimiento ........................................................ 16
2.1.4.1 Codificación y personalización ........................................................................ 16
2.1.4.2 Exploración y explotación ............................................................................... 17
2.1.5 Procesos de la gestión del conocimiento .............................................................. 18
2.1.5.1 Alineación con Estrategia Organizacional ...................................................... 19
2.1.5.2 Identificación ................................................................................................... 19
2.1.5.3 Incorporación .................................................................................................. 21
2.1.5.4 Preservación ................................................................................................... 22
2.2.5.5 Diseminación .................................................................................................. 22
2.1.5.6 Utilización ........................................................................................................ 22
2.1.6 Técnicas y herramientas para la gestión del conocimiento ................................... 23
2.1.6.1 Análisis FADO ................................................................................................. 23
2.1.6.2 Pruebas comparativas .................................................................................... 24
2.1.6.3 Mapas de conocimientos ................................................................................ 26
2.1.6.4 Lecciones aprendidas ..................................................................................... 28
2.1.6.5 Mejores prácticas ............................................................................................ 29
2.1.6.6 Comunidades de práctica ............................................................................... 30
2.1.6.7 Programas de capacitación ............................................................................ 31
2.1.6.8 Mentoring y Coaching ..................................................................................... 31
2.1.7 Sistemas de gestión del conocimiento .................................................................. 32
2.2 Aprendizaje individual y organizacional ....................................................................... 33
2.2.1 Aprendizaje ............................................................................................................ 33
viii
2.2.2 Aprendizaje experiencial ........................................................................................ 34
2.2.3 Reflexión y la práctica reflexiva ............................................................................. 36
2.2.4 Aprendizaje organizacional .................................................................................... 37
2.2.5 La Organización que aprende ............................................................................... 39
2.3 Conocimiento y aprendizaje en Ingeniería de Software ............................................... 41
2.4 La organización software que aprende ........................................................................ 43
2.5 Fábricas y bases de experiencia .................................................................................. 44
2.5.1 Fábrica de experiencia .......................................................................................... 44
2.5.2 Bases de experiencia software .............................................................................. 46
2.6 Mejora de las prácticas y procesos software ............................................................... 47
2.6.1 Modelos de mejora de procesos ............................................................................ 47
2.6.1.1 Plan-Do-Check-Act ......................................................................................... 47
2.6.1.2 Modelo IDEAL ................................................................................................. 48
2.6.1.3 CMMI ............................................................................................................... 49
2.6.2 El conocimiento en la mejora del proceso software .............................................. 51
2.6.3 El aprendizaje en la mejora del proceso software ................................................. 53
2.6.4 Factores claves para el éxito ................................................................................. 54
2.7 Conocimiento y aprendizaje para la mejora del proceso ............................................. 56
2.7.1 La perspectiva de creación de conocimiento ......................................................... 57
2.7.2 La perspectiva del aprendizaje experiencial .......................................................... 58
2.7.3 La perspectiva integrada ....................................................................................... 59
2.8 Valoración de conocimientos, experiencia y aprendizaje ............................................. 60
2.8.1 Valoración del conocimiento y la experiencia ........................................................ 60
2.8.2 Valoración del aprendizaje .................................................................................... 61
2.8.3 Valoraciones en el ámbito de la Ingeniería de Software ....................................... 65
2.9 Trabajos relacionados .................................................................................................. 66
2.9.1 Fábricas de experiencia ......................................................................................... 67
2.9.1.1 Software Experience Center ........................................................................... 67
2.9.1.2 Experience Engine .......................................................................................... 67
2.9.1.3 Knowledge Dust to Pearls ............................................................................... 67
2.9.1.4 EPG/ER ........................................................................................................... 68
2.9.1.5 Komi-Sirvio y colegas ...................................................................................... 68
2.9.2 Métodos y técnicas para captura de experiencia .................................................. 69
2.9.2.1 Análisis post mortem de proyectos ................................................................. 70
2.9.2.2 Sesiones Legacy ............................................................................................. 71
2.9.2.3 Revisiones post-proyecto ................................................................................ 71
2.9.2.4 Reportes de experiencias y Revisiones post mortem ..................................... 71
ix
2.9.3 Herramientas software y entornos de trabajo ........................................................ 72
2.9.3.1 Semantic Reuse System ................................................................................. 72
2.9.3.2 BORE .............................................................................................................. 72
2.9.3.3 RAMALA ......................................................................................................... 73
2.9.3.4 ProKnowHow .................................................................................................. 73
2.9.3.5 PAKME ........................................................................................................... 74
2.9.3.6 PM-CAKE ........................................................................................................ 74
2.9.3.7 El entorno TABA ............................................................................................. 75
2.9.3.8 Well of Experience .......................................................................................... 75
2.9.3.9 Competente blocks ......................................................................................... 76
2.9.3.10 Skills Manager .............................................................................................. 76
2.9.3.11 People Knowledge Map ................................................................................ 76
2.9.3.12 Process Asset Database ............................................................................... 76
2.9.4 Wikis, wikis semánticos y ontologías ..................................................................... 77
2.9.4.1 Riki .................................................................................................................. 77
2.9.4.2 Wikitología ...................................................................................................... 78
2.9.4.3 MASE .............................................................................................................. 78
2.9.5 Mejora del proceso software y CMMI .................................................................... 78
2.9.5.1 Arent y Norbjerg .............................................................................................. 78
2.9.5.2 KM framework for CMMI ................................................................................. 79
2.9.5.3 KM-CORE ....................................................................................................... 79
2.9.5.4 KDM for SPI .................................................................................................... 80
2.9.5.5 SPI-KM ............................................................................................................ 80
2.10 Problemas de los enfoques existentes ...................................................................... 81
2.10.1 Fábricas de experiencia ...................................................................................... 81
2.10.2 Análisis post mortem y similares ......................................................................... 82
2.10.3 Herramientas software y entornos de trabajo ...................................................... 83
2.10.4 Wikis y wikis semánticas ..................................................................................... 83
2.10.5 Mejora del proceso software y CMMI .................................................................. 83
3. PLANTEAMIENTO DEL PROBLEMA .............................................................................. 85 3.1 Críticas a los trabajos relacionados ............................................................................. 85
3.1.1 Crítica 1 ................................................................................................................. 85
3.1.2 Crítica 2 ................................................................................................................. 86
3.1.3 Crítica 3 ................................................................................................................. 86
3.1.4 Crítica 4 ................................................................................................................. 87
3.2 El problema .................................................................................................................. 88
4. SOLUCIÓN PROPUESTA ................................................................................................ 89
x
4.1 Consideraciones iniciales ............................................................................................. 89
4.2 La solución propuesta .................................................................................................. 89
4.3 Presentación del modelo .............................................................................................. 91
4.3.1 El modelo ele ......................................................................................................... 91
4.3.2 Integración del modelo a las actividades de proyecto y de mejora ....................... 93
4.3.2.1 Integración con las actividades de proyectos ................................................. 93
4.3.2.2 Integración con las actividades de mejora ...................................................... 94
4.4 Descripción del modelo ................................................................................................ 94
4.4.1 Iniciación ................................................................................................................ 95
4.4.2 Preparación ........................................................................................................... 97
4.4.3 Familiarización ..................................................................................................... 100
4.4.4 Actuación ............................................................................................................. 102
4.4.5 Educción .............................................................................................................. 104
4.4.6 Integración ........................................................................................................... 105
4.4.7 Revisión ............................................................................................................... 107
4.4.8 Conclusión ........................................................................................................... 109
4.5 Otros elementos constitutivos del modelo .................................................................. 110
4.5.1 El Grupo de Gestión del Conocimiento y del Aprendizaje ................................... 111
4.5.2 El Catálogo de Conocimientos y Experiencia ...................................................... 112
4.5.2.1 Elementos del catálogo ................................................................................. 112
4.5.2.2. Ejemplo de catálogo de conocimientos y experiencia ................................. 113
4.5.3 El Inventario de Conocimientos y Experiencia .................................................... 114
4.5.3.1 Elementos de conocimientos y de experiencia a inventariar ........................ 114
4.5.3.2 Valoración de los conocimientos y experiencia ............................................ 115
4.5.3.3 Elaboración del inventario ............................................................................. 115
4.5.3.4 Identificación de las brechas de conocimientos y de experiencia ................. 116
4.5.3.5 Ejemplo de estructura del inventario de conocimientos y experiencia .......... 116
4.5.3.6 Ejemplos de preguntas de valoración ........................................................... 117
4.5.4 Las Guías de Reflexión ....................................................................................... 118
4.5.4.1 Tipos de preguntas o sentencias .................................................................. 118
4.5.4.2 Formulación de las preguntas de reflexión ................................................... 119
4.5.4.3 Ejemplos de preguntas o sentencias de reflexión ......................................... 120
4.5.5 El Taller de Educción de Conocimientos y Experiencia ...................................... 121
4.5.5.1 Participantes ................................................................................................. 121
4.5.5.2 Insumos ......................................................................................................... 121
4.5.5.3 Desarrollo del taller ....................................................................................... 122
4.5.5.4 Productos ...................................................................................................... 122
xi
4.5.6 Repositorio de Lecciones Aprendidas y Mejores Prácticas ................................. 122
4.6 Conclusiones .............................................................................................................. 123
4.6.1 Sustentación de los proceso de gestión del conocimiento .................................. 123
4.6.2 Consideración de los procesos de conversión y creación de conocimientos ...... 125
4.6.3 Consideración de los procesos de aprendizaje experiencial ............................... 125
4.6.4 Cumplimiento de los objetivos teóricos de la solución ........................................ 126
4.6.5 Diferencias con los modelos de mejora de procesos .......................................... 127
5. DEMOSTRACIÓN EMPÍRICA ......................................................................................... 129 5.1 El contexto general de la investigación ...................................................................... 131
5.1.1 El Grupo de Gestión del Conocimiento y del Aprendizaje ................................... 132
5.1.2 Los Grupos de Proyectos Software ..................................................................... 132
5.1.3 El Grupo de Ingeniería de Procesos ................................................................... 133
5.2 El diseño de la investigación ...................................................................................... 133
5.2.1 Preguntas de investigación ................................................................................. 133
5.2.2 Proposiciones ...................................................................................................... 133
5.2.3 La unidad de análisis ........................................................................................... 134
5.2.4 Lógica que enlaza los datos con las proposiciones ............................................ 137
5.2.5 Criterios para analizar los datos .......................................................................... 140
5.2.6 La base de datos del caso de estudio ................................................................. 141
5.3 Desarrollo general de la investigación ....................................................................... 142
5.3.1 Reuniones de trabajo en el GGCA ...................................................................... 142
5.3.2 Cronograma de actividades ................................................................................. 143
5.3.3 Proceso de implementación del modelo .............................................................. 144
5.3.3.1 Iniciación ....................................................................................................... 145
5.3.3.2 Preparación ................................................................................................... 145
5.3.3.3 Familiarización .............................................................................................. 146
5.3.3.4 Actuación ...................................................................................................... 147
5.3.3.5 Educción ....................................................................................................... 147
5.3.3.6 Integración .................................................................................................... 147
5.3.3.7 Revisión ........................................................................................................ 147
5.3.4 Las guías de reflexión ......................................................................................... 148
5.3.5 El Taller de educción de conocimientos y experiencia ........................................ 150
5.4 Resultados obtenidos ................................................................................................. 151
5.4.1 Sobre el proceso de implementación del modelo ................................................ 152
5.4.2 Sobre las Guías de Reflexión .............................................................................. 153
5.4.3 Sobre el taller de educción de conocimientos y experiencia ............................... 164
5.5 Análisis de los resultados ........................................................................................... 167
xii
5.6 Conclusiones del estudio ........................................................................................... 173
5.7 Validez y fiabilidad del estudio ................................................................................... 174
5.7.1 Validez de la construcción ................................................................................... 174
5.7.1.1 Múltiples fuentes de evidencia ...................................................................... 174
5.7.1.2 Cadena de evidencia .................................................................................... 175
5.7.2 Validez interna ..................................................................................................... 175
5.7.3 Validez externa .................................................................................................... 175
5.7.4 Fiabilidad ............................................................................................................. 176
6. CONCLUSIONES ............................................................................................................ 177 7. FUTURAS LÍNEAS DE INVESTIGACIÓN ...................................................................... 181 8. BIBLIOGRAFÍA ............................................................................................................... 183 APÉNDICE 1. SOBRE LA METODOLOGÍA DE INVESTIGACIÓN SELECCIONADA ...... 201
A1.1 Paradigmas de investigación ................................................................................... 201
A1.2 Elección del método de investigación ...................................................................... 202
A1.3 El estudio de casos en Ingeniería de Software ........................................................ 204
A1.4 Diseño de la investigación ....................................................................................... 204
A1.4.1 La pregunta de investigación ............................................................................ 205
A1.4.2 Las proposiciones ............................................................................................. 205
A1.4.3 La unidad de análisis y los informantes claves ................................................. 205
A1.4.4 Lógica que enlaza los datos con las proposiciones .......................................... 206
A1.4.4.1 Observación participante ............................................................................ 207
A1.4.4.2 Documentos ................................................................................................ 207
A1.4.4.3 Cuestionarios .............................................................................................. 207
A1.4.5 Criterios para analizar los datos ........................................................................ 208
A1.4.5.1 Datos cualitativos ........................................................................................ 208
A1.4.5.2 Datos cuantitativos ..................................................................................... 208
A1.4.6 La base de datos del estudio ............................................................................ 209
A1.5 Sobre los estudios empíricos con estudiantes ..................................................... 209
APÉNDICE 2. INSTRUMENTOS DE RECOLECCIÓN DE DATOS .................................... 211 APÉNDICE 3. BASE DE DATOS DEL ESTUDIO ............................................................... 231 APENDICE 4. MANUAL DE IMPLEMENTACIÓN DEL MODELO ..................................... 335
xiii
Indice de figuras
Figura 2.1: Ciclo de conversión de conocimientos …………………………………………….. 29
Figura 2.2: Identificación del conocimiento estratégico………………………………………… 38
Figura 2.3: Identificación de los activos de conocimiento estratégico……………………….. 38
Figura 2.4: Brechas estratégica y de conocimientos...………………………………………… 39
Figura 2.5: Ciclo de aprendizaje experiencial (Kolb)...………………………………………… 53
Figura 2.6: Fábrica de experiencia (Basili et al.)……...………………………………………… 63
Figura 2.7: Modelo IDEAL ……………………………...………………………………………… 66
Figura 2.8: Perspectiva de creación de conocimientos...……………………………………… 76
Figura 2-9: Perspectiva de aprendizaje experiencial...………………………………………… 77
Figura 4.1: Esquema funcional de la solución propuesta……………………………………. 108
Figura 4.2: Modelo ele ……………………………...…………………………………………… 109
Figura 4.3: Integración del modelo a las actividades de proyecto y de mejora…………… 111
Figura 4.4: Flujo de tareas para la fase de Iniciación………………………………………… 114
Figura 4.5: Flujo de tareas para la fase de Preparación……………………………………… 117
Figura 4.6: Flujo de tareas para la fase de Familiarización..………………………………… 119
Figura 4.7: Flujo de tareas para la fase de Actuación………………………………………… 121
Figura 4.8: Flujo de tareas para la fase de Educción………………………………………… 123
Figura 4.9: Flujo de tareas para la fase de Integración………………………………………. 124
Figura 4.10: Flujo de tareas para la fase de Revisión………………………………………… 126
Figura 4.11: Flujo de tareas para la fase de Conclusión……………………………………… 128
Figura 4.12: Elaboración del catálogo de conocimientos y experiencia……………………. 131
Figura 4.13: Formulación de preguntas de valoración de conocimientos….……………… 134
Figura 4.14: Formulación de preguntas de reflexión………………………….……………… 138
Figura 4.15: Educción de conocimientos y experiencia………………….….……………… 140
Figura 4.16: Integración de conocimientos y experiencia al repositorio….………………… 141
Figura 5.1: Esquema del contexto de investigación….………………………………………. 150
Figura 5.2: Cronograma de actividades….……………………………………………………. 161
xv
Indice de tablas
Tabla 2.1: Procesos de conversión de conocimientos……………………………………….. 28
Tabla 2.2: Tipos de conocimiento profesional…………………………………………………. 30
Tabla 2.3: Tipos de conocimientos……………………………………………………………… 32
Tabla 2.4: Procesos de gestión del conocimiento…………………………………………….. 36
Tabla 2.5: Comunidades de práctica, grupos y equipos……………………..………………. 48
Tabla 2.6: Areas de proceso y sus categorías y niveles de madurez asociados…….……. 68
Tabla 2.7: Comparación entre niveles de capacidad y de madurez………..………………. 69
Tabla 2.8: Perspectiva integrada…………………………..……………………………………. 77
Tabla 2.9: Niveles de capacidad personal (Wiig)……..…………………………………….. 79
Tabla 210: Escala de conocimientos y habilidades (Mayo)………………………………….. 79
Tabla 2.11: Taxonomía de objetivos educacionales (Bloom)………………………………… 80
Tabla 2.12: Dimensión del proceso cognitivo (Anderson et al.)……………………………… 81
Tabla 2.13: Dimensión de conocimientos (Anderson et al.)…..……………………………… 82
Tabla 2.14: Niveles de capacidad (McConnell)………………..………………………………. 84
Tabla 4.1:Estructura del catálogo de conocimientos y experiencia………………………… 132
Tabla 4.2: Taxonomía de valoración de conocimientos y experiencia……………………… 133
Tabla 4.3: Estructura del inventario de conocimientos y experiencia………………………. 135
Tabla 4.4: Ejemplos de preguntas de valoración………………..……………………………. 136
Tabla 4.5: Ejemplos de preguntas o sentencias de reflexión………………..………………. 138
Tabla 5.1: Relación de proposiciones a unidad y subunidades de análisis……………….. 153
Tabla 5.2: Datos de la planilla de oportunidades de mejora………………..………………. 154
Tabla 5.3: Proyectos seleccionados para el estudio………………..………………………… 155
Tabla 5.4: Proposiciones con sus fuentes de datos e instrumentos de recolección……… 156
Tabla 5.5: Tiempos dedicados, en minutos, a responder las guías de reflexión…………. 178
Tabla 5.6: Tiempos dedicados, en horas, a responder las guías de reflexión……………. 178
Tabla 5.7: Tiempos de actividades y de proyecto………………..…………………………… 179
Tabla 5.8: Porcentajes de tiempos de respuestas a las guías de reflexión……………….. 179
Tabla 5.9: Respuestas al cuestionario de la proposición 4…………………………………. 180
Tabla 5.10: Agrupación de respuestas por actitud…………………………………………… 180
Tabla 5.11: Respuestas a la pregunta 1 del cuestionario…………………………………… 180
Tabla 5.12: Respuestas a la pregunta 2 del cuestionario…………………………………… 181
Tabla 5.13: Respuestas a la pregunta 3 del cuestionario…………………………………… 181
Tabla 5.14: Respuestas a la pregunta 4 del cuestionario…………………………………… 181
Tabla 5.15: Respuestas a la pregunta 5 del cuestionario…………………………………… 181
xvi
Tabla 5.16: Respuestas a la pregunta 6 del cuestionario…………………………………… 182
Tabla 5.17: Respuestas al cuestionario de la proposición 6………………………………… 184
Tabla 5.18: Agrupación de respuestas por actitud……………………………………………. 184
Tabla 5.19: Sobre la organización del taller (preguntas 1 a 4) ……………………………… 185
Tabla 5.20: Sobre la participación personal en el taller (preguntas 5 a 8)…………………. 185
Tabla 5.21: Sobre el contenido del taller (pregunta 9) ………………………………………. 185
Tabla 5.22: Conclusiones del taller y respuestas en las guías de reflexión………………. 190
Tabla 5.23: Nuevos aportes relacionados a los temas del taller……………………………. 190
Tabla A1.1: Actividades privadas de los estudiantes…………..……………………………. 227
Tabla A3.1: Planilla de análisis de reportes de revisión……..………………………………. 260
1
1. Introducción
1.1 La gestión del conocimiento en ingeniería de software
La IEEE Computer Society [IEEE, 1990] define la ingeniería de software, en lo
sucesivo IS, como un enfoque sistemático, disciplinado y cuantificable para el desarrollo, la
operación y el mantenimiento de software; es decir, la aplicación de ingeniería al software.
Según comenta Ye [Ye, Y., 2006], si bien el desarrollo de software comparte muchas
características con otras disciplinas de la ingeniería, presenta, sin embargo, nuevos desafíos
de investigación puesto que también depende fuertemente de la creatividad y del
conocimiento de los individuos desarrolladores de software.
Por su parte, la gestión del conocimiento, en adelante GC, puede definirse como el
conjunto de procesos que gobiernan la creación, diseminación y utilización del conocimiento
[Gupta, J., et al., 2004].
Una definición más amplia y comprensiva de GC la proporcionan del Moral y colegas
[del Moral, A., et al., 2007], para quienes se entiende por GC al conjunto de principios,
métodos, técnicas, herramientas, métricas y tecnologías que permiten obtener los
conocimientos precisos, para quienes los necesitan, del modo adecuado, en el tiempo
oportuno de la forma más eficiente y sencilla, con el fin de conseguir una actuación
institucional lo más inteligente posible.
Lai, Wang y Chow [Lai, J-Y. et al., 2008] consideran que, desde que el conocimiento
ha sido considerado por las organizaciones como un activo crucial para sobrevivir en un
entorno altamente competitivo, la GC es considerada definitivamente como una actividad
esencial para adaptarse y sobrevivir en un ambiente de tal característica.
Para Piirainen, Kivijarvi y Touminen [Piirainen, K. et al., 2008], a medida que las
organizaciones se han vuelto más grandes y diversificadas, y que los roles y las tareas
individuales se han vuelto más especializadas, existe una creciente necesidad de convertir
el conocimiento personal para su uso a nivel organizacional y afirman que esta convergencia
de los conocimientos personales y organizacionales constituye una significativa y justificada
área de investigación.
Para Muhammed, Doll y Deng [Muhammed, S. et al., 2008], a nivel individual, un
recurso clave para provocar una acción organizacional efectiva es el conocimiento relativo a
las tareas de los individuos y consideran que este conocimiento refleja el aprendizaje
2
individual que tiene lugar dentro del contexto organizacional y puede ser realzado
gestionando de manera efectiva las actividades que contribuyen a tal conocimiento.
Diversos autores destacan la conveniencia y la necesidad de estrechar los vínculos
entre las disciplinas de la IS y de la GC por cuanto consideran que la ingeniería de software
se caracteriza precisamente por ser una actividad intensiva en conocimientos.
Así, Kukko, Helander y Virtanen [Kukko, M. et al., 2008] consideran que el proceso de
desarrollo software se caracteriza típicamente como intensivo en conocimientos y que el
resultado del proceso, esto es, el software, es igualmente un producto intensivo en
conocimientos.
Falbo y colegas [Falbo, R. et al., 2004b], así como Falbo, Pezzin y Schwambach
[Falbo, R. et al., 2005] también caracterizan el desarrollo de software como un proceso
intensivo en conocimientos y como un esfuerzo colectivo, complejo y creativo, y consideran
que para producir productos software de calidad, las organizaciones software han
reconocido como esencial hacer un mejor uso de sus conocimientos organizacionales sobre
IS.
Para Handzic [Handzic, M., 2003] en IS las personas han sido reconocidas como los
poseedores claves de conocimiento valioso y, por lo tanto, identificar, localizar y capturar los
conocimientos de los individuos y de los grupos de desarrolladores software es de
importancia crítica para la sobrevivencia en el negocio del software.
Wohlin [Wohlin, C., 2003] por su parte considera que la habilidad para gestionar el
conocimiento en IS es un factor clave de éxito para los proyectos y para las organizaciones
software en el futuro.
Para Rus y Lindvall [Rus, I. et al., 2002] el conocimiento en IS es diverso, sus
proporciones son inmensas y sostenidamente crecientes, y entienden que las
organizaciones tienen problemas para identificar el contenido, ubicación y el uso de ese
conocimiento.
Una de las actividades mas importantes en el ámbito de la actual IS es la relativa a la
mejora de las prácticas y los procesos de desarrollo y, en esta área, la perspectiva de la GC
se torna particularmente importante.
En este sentido, Alagarsamy, Justus y Iyakutti [Alagarsamy, K. et al., 2008],
mencionan que si bien en el pasado los trabajos relativos a la mejora del proceso software
han considerado un amplio rango de iniciativas, la GC debe considerarse como un enfoque
contemporáneo para refinar las actividades de mejora del proceso software dado que, para
estos autores, los procesos software han evolucionado desde ser procesos conducidos por
datos, pasando por ser procesos conducidos por información hasta los actuales procesos
conducidos por conocimientos.
3
Bjornson [Bjornson, F., 2007] sostiene que las ideas valiosas y la perspicacia
(“insights”) desde el campo de la GC son potencialmente útiles en los esfuerzos de mejora
del proceso software para facilitar la creación, modificación y compartición de los procesos
software en una organización.
Para Montoni, Santos y Rocha [Montoni, M. et al., 2007] es esencial gestionar
eficientemente el conocimiento de IS para aspirar a mantener las implementaciones de
mejora del proceso software y para incrementar las oportunidades de obtener resultados
positivos de las inversiones en mejora de procesos.
Elisberg, Norjberg y Pries-Heje [Elisberg, T. et al., 2006] consideran que una
organización software que apunte a mejorar la calidad de sus procesos y de sus productos
debe definir e implementar una estrategia apropiada de GC que le permita identificar los
procesos software con potencial de ser mejorados, definir nuevos procesos, documentarlos
y diseminar el conocimiento de estos nuevos procesos entre los profesionales de desarrollo
de software de la organización.
Por su parte, Falbo, Pezzin y Schwambach [Falbo, R. et al., 2005] sostienen que en el
contexto preciso del desarrollo software, la GC puede usarse para gestionar los
conocimientos y la experiencia generados durante los procesos software y consideran que si
bien cada proyecto es, en cierto sentido, único, experiencias similares pueden ayudar a los
desarrolladores en la realización de sus actividades.
Similar opinión tienen Antunes, Seco y Gomes [Antunes, B. et al., 2007] en el sentido
de que el conocimiento generado durante el proceso de desarrollo software puede resultar
un activo valioso para una organización software y que para obtener ventajas de estos
conocimientos, la organización debe adquirirlos, almacenarlos y gestionarlos para su
reutilización.
Para Komi-Sirvio, Mantyniemi y Seppanen [Komi-Sirvio, S. et al., 2002], un uso de la
GC es apoyar las actividades de mejora del proceso software y consideran que este apoyo
es importante pues tanto las técnicas de IS como de gestión de la calidad fallan si las
mismas no están basadas en un conocimiento minucioso de lo que se necesita y de lo que
se ha hecho en una organización de desarrollo software.
Para Aurum y colegas [Aurum, A. et al., 2003], los desarrolladores de software poseen
un conocimiento altamente valioso en relación con el desarrollo de productos, con el
proceso de desarrollo software, con la gestión de proyectos y con la tecnología, y estos
conocimientos, tanto tácitos como explícitos, son dinámicos y evolucionan con la tecnología,
la cultura organizacional y con las necesidades cambiantes de las prácticas de desarrollo
software. Estos autores afirman, además, que mejorar los procesos y los productos software
son casos especiales de GC, que la experiencia juega también un rol principal en estas
actividades relacionadas con el conocimiento y que, en consecuencia, existe una necesidad
4
de recopilar experiencias y conocimientos de IS y reutilizarlos para mejorar los procesos
software [Aurum, A. et al., 2003].
Briand [Briand, L., 2003], por su parte, considera que en las organizaciones software,
la experiencia y los conocimientos adquiridos en proyectos software anteriores pueden
utilizarse para mejorar las prácticas en proyectos futuros y que el aprendizaje organizacional
basado en la experiencia resulta clave para la efectiva adopción de nuevas prácticas y para
mejorar tanto la productividad como la calidad.
Desouza, Dingsoyr y Awazu [Desouza, K. et al., 2005] también coinciden en
caracterizar los proyectos software como altamente basados en el conocimiento al
considerar que el conocimiento es la materia prima (“raw-material”) y contribuye al proceso y
al resultado de los esfuerzos de la IS.
Según menciona Edwards [Edwards, J., 2003], si bien la literatura general sobre GC
contiene muchos ejemplos de sistemas de GC en uso exitoso en compañías relacionadas
con las tecnologías de la información, relativamente pocos de estos ejemplos están
específicamente relacionados con la IS. En opinión de este autor, a pesar de que hay una
activa comunidad de GC en IS, sus trabajos están distanciados de la corriente principal
(“mainstream”) sobre la GC [Edwards, J., 2003]. Este mismo comentario es recogido por
Bjornson [Bjornson, F., 2007] en su tesis doctoral, quien agrega que la IS ha abordado
principalmente el almacenamiento y la recuperación de conocimiento mientras que tópicos
tales como la creación, transferencia y aplicación de conocimiento necesitan aún mayor
atención.
Para Mathiassen y Pedersen [Mathiassen, L. et al., 2005], en la literatura estándar
sobre el desarrollo de sistemas no se da un tratamiento explícito a la creación y
compartición de conocimientos y poca investigación sobre desarrollo de sistemas se publica
en esta área.
Similar opinión tienen Ward y Aurum [Ward, J. et al., 2004], para quienes en la
literatura existe un vacío en lo referente a los procesos de GC en IS.
1.2 Finalidad de la tesis
La finalidad de esta tesis es realizar una contribución al ámbito de la IS en un área de
importancia permanente como lo es el de la mejora de las prácticas y procesos software,
desde la perspectiva de la GC y de la experiencia.
La meta de este trabajo es definir un modelo para la GC y de la experiencia que los
miembros de los equipos de proyectos adquieren durante el desarrollo de los proyectos
5
software, con el propósito de que esos conocimientos y experiencias sustenten las
actividades de mejora de las prácticas y procesos software en uso en una organización.
1.3 Estructura de la tesis
Al comienzo de este capítulo se estableció el ámbito en el que se enmarca este
trabajo, se hizo referencia a la importancia siempre actual de la mejora de las prácticas y
procesos software en uso en una organización y se definió que el tratamiento a dar al tema
es desde la perspectiva, considerada contemporánea, de la GC y de la experiencia.
En el capítulo 2, referido al estado de la cuestión, se presentan los principales
conceptos relativos al conocimiento y a los diferentes procesos para su gestión, al
aprendizaje individual basado en la experiencia y al aprendizaje organizacional.
Posteriormente, en ese mismo capítulo, el tratamiento de estos temas se enfoca al ámbito
específico de la IS, particularmente en lo referente a la manera en que la GC y de la
experiencia contribuye a las actividades de mejora de las prácticas y procesos software en
uso en una organización. El capítulo continúa con la presentación de diversas iniciativas,
estudios y enfoques para la gestión del conocimiento y de la experiencia en el ámbito
particular de la ingeniería de software, para finalizar con una serie de comentarios críticos a
diversos aspectos de los trabajos y enfoques descriptos.
En el capítulo 3, se presentan de manera formal las críticas a los trabajos analizados
previamente, lo cual da lugar a la definición del problema a abordar, formulado en los
siguientes términos: ¿Cómo incorporar a las prácticas y procesos de desarrollo software de
una organización, procedimientos y artefactos específicos para orientar y gestionar el
conocimiento y el aprendizaje basado en la experiencia que se adquiere en el marco de los
proyectos de desarrollo software?
El capítulo 4, está dedicado a presentar la solución propuesta al problema planteado y
a describir en detalle la estructura y los componentes del modelo propuesto para la GC y del
aprendizaje basado en la experiencia, en forma integrada tanto a las actividades de los
proyectos software como a las actividades de mejora de las prácticas y procesos software
en uso en una organización.
El modelo propuesto, denominado modelo “ele”, contempla todos los procesos de
creación y de GC y del aprendizaje basado en la experiencia que fueron expuestos en el
capítulo 2, así como también resuelve los inconvenientes y críticas planteados a las
iniciativas y enfoques preexistentes, formulados en el capítulo 3.
Junto con el modelo, y como uno de sus componentes principales, se presentan las
denominadas guías de reflexión como una nueva herramienta para capturar los
conocimientos y la experiencia que los miembros de los equipos de proyectos adquieren
6
durante la ejecución de sus actividades de proyecto. El aspecto distintivo de esta
herramienta es que posibilita capturar esos conocimientos y experiencia en forma
contemporánea a la propia ejecución de las actividades de proyecto.
El enfoque propuesto con esta herramienta contrasta con la utilización de otras
técnicas tales como el análisis post mortem de proyectos y similares, analizados en el
capítulo 2, donde la captura de conocimientos y experiencia se lleva a cabo después de
finalizado el proyecto o luego de que se haya alcanzado un hito significativo.
En el capítulo 5, se presenta el trabajo de investigación de campo referido a la
implementación práctica del modelo propuesto y de la herramienta mencionada, con el
propósito de mostrar su viabilidad y utilidad en un ámbito de desarrollo de proyectos
software. En este sentido, se describe el diseño de la investigación siguiendo la metodología
del estudio de casos donde se definen la pregunta de investigación y las proposiciones
derivadas de la misma, se establece la unidad de análisis del caso, se determinan los
informantes claves para el estudio, se identifican las fuentes de los datos, y se establecen
los instrumentos para su recolección y los criterios para analizarlos.
En este mismo capítulo se describe también el desarrollo general de la investigación y
se presentan y analizan los resultados obtenidos, para culminar con la exposición de las
conclusiones del estudio y con el análisis de su validez y fiabilidad.
La implementación del modelo y su estudio empírico se llevaron a cabo en el
Laboratorio de Ingeniería de Software de la Facultad de Ingeniería de la Universidad ORT
Uruguay. Este laboratorio, denominado ORT Software Factory, tiene como misión la
formación de profesionales que desarrollen productos que satisfagan a sus clientes,
focalizando la atención en la producción de software en forma industrial y en proveer
tecnología probada al mercado.
En el capítulo 6, por su parte, se presentan las conclusiones finales del trabajo que,
brevemente expuestas, establecen que el modelo propuesto es viable de ser implementado
e integrado a las actividades de los proyectos software y a las de mejora de las prácticas y
procesos software en uso en una organización, y permite gestionar el conocimiento y la
experiencia que los miembros de los equipos de proyectos adquieren durante la ejecución
de sus actividades de proyecto.
El capítulo 7 presenta las líneas futuras de desarrollo y de investigación que surgen a
partir de la definición última del modelo y de la implementación práctica realizada.
El capítulo 8 contiene las referencias bibliográficas utilizadas en la elaboración de este
trabajo.
La parte final de esta memoria está constituida por cuatro apéndices.
El apéndice 1, contiene una descripción más detallada de la metodología de
investigación adoptada para esta tesis y, en particular, refiere a dos aspectos importantes: la
7
utilización de la estrategia del estudio de casos en la investigación en IS, y la utilización de
estudiantes de grado en estudio empíricos, también en IS.
En el apéndice 2, se presentan los instrumentos de recolección de datos, tanto
cualitativos como cuantitativos, utilizados en el proceso de investigación.
El apéndice 3, contiene la base de datos del caso con toda la documentación e
información recolectada durante el desarrollo del estudio.
Finalmente, en el apéndice 4, se incluye el manual de implementación del modelo,
elaborado como parte de las actividades de investigación.
1.4 Aportes de la tesis
Los aportes realizados con esta tesis son:
A) La definición y especificación de un modelo para la GC y de la experiencia que se
integra tanto a las actividades de los proyectos software como a las de mejora de
las prácticas y procesos software en uso en una organización.
B) Una herramienta para capturar los conocimientos y la experiencia que los
miembros de los equipos de proyecto adquieren durante la ejecución de sus
actividades de proyecto.
C) Un ejemplo de implementación práctica del modelo propuesto, estudiado en forma
simultánea al propio proceso de implementación siguiendo la estrategia de
investigación del estudio de casos.
9
2. ESTADO DE LA CUESTIÓN
2.1 El conocimiento y su gestión
En esta sección se introducen los conceptos más relevantes relativos al conocimiento
y a los diferentes procesos, técnicas y herramientas para su gestión.
2.1.1 Conocimiento
En la literatura sobre GC puede encontrarse una multiplicidad de definiciones y de
caracterizaciones acerca de qué se entiende por conocimiento.
Así, para Davenport y Prusak [Davenport, T. et al., 1998] conocimiento es una
mezcla fluida de experiencia estructurada, valores, información contextualizada y
discernimiento experto que provee un marco de referencia para evaluar e incorporar nuevas
experiencias e informaciones.
Probst, Raub y Romhardt [Probst, G. et al., 2001], por su parte, definen conocimiento
como todo el cúmulo de aprendizajes y habilidades que los individuos utilizan para
solucionar problemas.
Un enfoque diferente para lograr una mejor aproximación al concepto de conocimiento
es establecer la distinción entre conocimiento e información, así como la distinción entre
información y datos.
Según lo expone Wiig [Wiig, K., 1993], datos pueden ser números, palabras o
imágenes para los cuales no se ha especificado un contexto de significación o una
organización. Para que los datos se conviertan en información deben ser presentados en un
contexto, con algún propósito y con una organización discernible de modo que tengan
relevancia para una situación, problema o condición. El conocimiento es subsecuentemente
aplicado para interpretar la información disponible sobre una situación en particular y para
decidir como manejarla. El conocimiento es lo que se usa para determinar el significado de
una situación o condición.
Alavi [Alavi, M., 2001] afirma que lo que es clave para distinguir efectivamente entre
información y conocimiento no se encuentra en el contenido, estructura o utilidad de la
supuesta información o conocimiento sino que conocimiento es información procesada por
las mentes de los individuos; es información personalizada relativa a hechos,
procedimientos, conceptos, ideas y juicios.
10
A partir de los trabajos de Polanyi [Polanyi, M., 1966], Nonaka y Takeuchi [Nonaka, I.
et al., 1999] hacen una distinción entre dos tipos de conocimiento, a los que denominan
tácito y explícito.
Por tácito se entiende el conocimiento que reside en las mentes de las personas y
que es difícil de formalizar y de articular. Koskinen [Koskinen, K., 2001] considera que el
conocimiento tácito se adquiere principalmente a través de la práctica y la experiencia, y se
expresa en las acciones humanas en las formas de evaluaciones, actitudes, puntos de vista,
motivaciones y juicios. Para Choo [Choo, C. W., 1999], el conocimiento tácito es el
conocimiento implícito que utilizan los miembros de una organización para realizar su
trabajo. Para este autor, este tipo de conocimiento es difícil de expresar verbalmente porque
se manifiesta en destrezas que se basan en acciones y no puede reducirse a reglas y
recetas. Esta clase de conocimientos se aprende a través de largos períodos de
experimentación y realización de una tarea durante los cuales el individuo desarrolla un
“tacto” y una capacidad para hacer juicios intuitivos sobre la ejecución satisfactoria de una
tarea. Este autor concluye que el conocimiento tácito es vital para una organización pues la
misma sólo puede aprender e innovar al sustentarse en el conocimiento implícito de sus
miembros.
Por conocimiento explícito se entiende aquél que puede transmitirse utilizando el
lenguaje formal y sistemático, y que puede ser o ha sido capturado y codificado en
manuales, libros, procedimientos, y reglas. A partir de esta distinción entre conocimientos
tácito y explícito, Nonaka y Takeuchi [Nonaka, I. et al., 1999] han propuesto un modelo de
cuatro pasos que se muestra en la tabla 2.1 para explicar el proceso de creación de nuevo conocimientos en una organización. Según estos autores, la creación de conocimiento es
un proceso cíclico de transformación o conversión de conocimiento tácito en explícito y de
conocimiento explícito en tácito. Las cuatro formas de conversión de conocimiento se
denominan Socialización, Externalización, Combinación e Internalización:
A Tácito A Explícito
De Tácito
Socialización
Externalización
De Explícito
Internalización
Combinación
Tabla 2.1: Procesos de conversión de conocimientos (Nonaka y Takeuchi)
• Socialización es el proceso de conversión de conocimiento tácito en conocimiento
tácito. Ocurre cuando el conocimiento de un individuo es compartido con otros
11
mediante el trabajo colaborativo, la observación y la imitación de comportamientos.
La clave para obtener conocimiento tácito es la experiencia.
• Externalización es el proceso de conversión de conocimiento tácito en explícito.
Ocurre cuando se enuncia el conocimiento tácito en forma de conceptos explícitos.
La externalización se observa típicamente en el proceso de creación de conceptos y
es generada por el diálogo o la reflexión colectiva.
• Combinación es el proceso de conversión de conocimiento explícito en
conocimiento explícito. Ocurre cuando el conocimiento explícito preexistente se
combina con el conocimiento externalizado en el paso anterior para generar un
nuevo cuerpo de conocimientos.
• Internalización es el proceso de conversión de conocimiento explícito en
conocimiento tácito y está muy relacionado con el “aprender haciendo”. Para que el
conocimiento explícito se vuelva tácito es de gran ayuda que, previamente, el
conocimiento se verbalice o diagrame en documentos, manuales o historias orales.
La documentación ayuda a los individuos a interiorizar lo que han experimentado,
enriqueciendo, por tanto, su conocimiento tácito.
Figura 2.1: Ciclo de conversión de conocimientos
La creación de conocimiento organizacional consiste, entonces, en una interacción
continua y dinámica entre conocimiento tácito y conocimiento explícito. Esta interacción
tiene lugar a través de la intercalación de las diferentes formas de conversión de
conocimiento, tal como se muestra en la figura 2.1.
La socialización se inicia generalmente con la creación de un ámbito de interacción
que permita que los miembros de un equipo compartan sus experiencias y modelos
mentales. La externalización comienza a partir de un diálogo o reflexión colectiva que
permita a los miembros del equipo enunciar el conocimiento tácito generado en el paso
previo. La combinación se inicia cuando el conocimiento recién creado y el existente se
distribuyen a otros sectores de la organización. Finalmente, la internalización se origina en el
“aprender haciendo”, es decir, mediante la aplicación práctica de nuevo conocimiento.
12
2.1.2 Taxonomías del conocimiento
Además de la distinción entre conocimientos tácito y explícito analizada en el
apartado anterior, otros autores han propuesto sus propias clasificaciones del conocimiento.
Choo [Choo, C. W., 1999] agrega, a la distinción entre conocimientos tácito y explícito,
una tercera categoría a la que denomina conocimiento cultural. El conocimiento cultural consiste en las estructuras cognoscitivas y afectivas que los miembros de una organización
utilizan en forma habitual para percibir, explicar, evaluar y construir la realidad.
Bollinger y Smith [Bollinger, A. et al., 2001], por su parte, distinguen entre
conocimiento individual y conocimiento colectivo, de acuerdo a las siguientes descripciones:
• Individual: o conocimiento personal es el entendimiento, toma de conciencia o
familiaridad acerca de un tema, adquirido por medio del estudio, la investigación, la
observación o la experiencia práctica a lo largo del tiempo. Es una interpretación
personal de información basada en la experiencia, habilidades y competencias
personales.
• Colectivo: o conocimiento organizacional es, en general, lo que las personas
conocen acerca de los clientes, productos, procesos, políticas, cultura y forma de
actuar de la organización. Reside en lugares tan diversos como bases de datos,
documentos y manuales de procedimientos, al tiempo que también se comparte por
medio de experiencias y mejores prácticas.
El conocimiento individual, si no es compartido con otras personas, tiene muy poco
efecto sobre la base de conocimientos de la organización. Por esto, una de las tareas más
importantes de los gerentes es la de facilitar y fomentar los procesos de interacción entre los
empleados, de modo que puedan intercambiar ideas y opiniones, así como sus experiencias
y conocimientos.
Lam [Lam, A., 2000] también adhiere a esta distinción entre conocimiento individual y
colectivo. En base a ella, y en conjunción con la clasificación en tácito y explícito analizada
anteriormente, Mathiassen y Pedersen [Mathiassen, L. et al, 2005] mencionan cuatro
diferentes tipos de conocimiento profesional, según la tabla 2.2:
Tácito Explícito
Individual
Incorporado
Innato
Colectivo
Incrustado
Codificado
Tabla 2.2: Tipos de conocimiento profesional (Mathiassen y Pedersen)
13
Mathiassen y Pedersen [Mathiassen, L. et al, 2005] describen estos cuatro tipos de
conocimiento en los siguientes términos:
• Innato es conocimiento que depende de las habilidades cognitivas del individuo y
abarca el conocimiento racional o científico.
• Incorporado es conocimiento práctico y orientado a la acción. Se construye a partir
de la experiencia práctica, está vinculado a un contexto específico y su creación no
puede separarse de su aplicación.
• Codificado es conocimiento que está codificado en procedimientos, estándares,
reglas y especificaciones escritas.
• Incrustado es conocimiento que está almacenado en rutinas, normas, valores y
cultura organizacionales.
Zack [Zack, M., 1999], por su parte, distingue tres tipos de conocimiento en función de
su valor para apoyar la posición competitiva de una organización. En este sentido, afirma
Zack, el conocimiento puede clasificarse en esencial, avanzado e innovador.
• Esencial refiere al conocimiento mínimo necesario para que la organización pueda
estar en el negocio o sector industrial hacia el cual orienta sus actividades. Poseer
este nivel de conocimientos y capacidades no asegura la viabilidad competitiva de la
organización a largo plazo sino que solamente constituye una barrera básica de
entrada de nuevos competidores a ese sector industrial.
• Avanzado refiere al conocimiento que hace a la organización viable desde el punto
de vista competitivo. Tal conocimiento permite a la organización diferenciar sus
productos y servicios de sus competidores por medio de la aplicación de
conocimiento superior en ciertas áreas.
• Innovador refiere al conocimiento que permite a una organización liderar en su
sector industrial y diferenciarse de manera significativa de sus competidores.
Boisot [Boisot, M., 1998] propone una clasificación en la que toma en cuenta dos
dimensiones: si el conocimiento es codificable o no, y si el conocimiento se puede difundir
con facilidad o no. Para este autor, el conocimiento codificable es el que se puede
almacenar o poner por escrito sin que se incurra en pérdidas indebidas de información,
mientras que el no codificable es aquel que no puede ser capturado por escrito ni
almacenado sin perder los aspectos esenciales de la experiencia a la que se refiere.
En la otra dimensión, el conocimiento difundido es el que se comparte con otras
personas, mientras que el no difundido permanece en la mente de la persona que lo posee,
ya sea porque es difícil de expresar o porque se decida mantenerlo ahí.
14
En base a estas dos dimensiones, Boisot [Boisot, M., 1998] propone cuatro tipos de
conocimientos, según la tabla 2.3:
Difundido No difundido
Codificable
Conocimiento público
Conocimiento registrado
propio
No codificable
Conocimiento de sentido
común
Conocimiento personal
Tabla 2.3: Tipos de conocimientos (Boisot)
Boisot [Boisot, M., 1998] concibe estos cuatro tipos de conocimiento en los siguientes
términos:
• Público: es lo que convencionalmente se considera como conocimiento en sociedad
y puede hallarse estructurado y registrado en libros, revistas y otras fuentes
impresas, formales o informales.
• De sentido común: es el que una persona adquiere gradualmente a lo largo de su
vida, en base a experiencias personales y a la interacción con otros miembros de la
comunidad donde se desenvuelve.
• Personal: es el que surge de la propia experiencia de un individuo pero que no es
accesible a otros.
• Registrado propio: es el conocimiento que una persona o grupo desarrolla y
codifica por su cuenta a fin de percibir situaciones similares. Al ser codificado, este
conocimiento es técnicamente difundible aunque puede no ser significativo difundirlo
por cuanto su pertinencia está limitada a las circunstancias y necesidades de la
persona o grupo que lo origina.
Schunk [Schunk, D., 1997], por su parte distingue entre tres tipos de conocimientos:
declarativo, procedimental y condicional, según las siguientes caracterizaciones:
• Declarativo: es el conocimiento referido a hechos, creencias, opiniones y teorías.
• Procedimental: refiere al conocimiento que permite entender cómo llevar a cabo
actividades y procedimientos, y se presenta en forma de conceptos, reglas y
algoritmos.
• Condicional: es el tipo de conocimiento que permite discernir que qué condiciones
emplear los conocimientos declarativos y procedimentales.
15
En el ámbito más específico de la IS, Rus y Lindvall [Rus, I. et al., 2002] proponen que,
dependiendo del conjunto de actividades en IS al cual pertenezcan los conocimientos, éstos
pueden ser de diferentes clases, tales como conocimiento organizacional, conocimiento de
gestión, conocimiento técnico y conocimiento del dominio:
• Organizacional: refiere, entre otros, al conocimiento para gestionar la organización,
cuales son los objetivos del negocio y la gestión de los recursos humanos.
• de Gestión: refiere, ente otros, al conocimiento para planificar, liderar y realizar el
seguimiento de un proyecto.
• Técnico: refiere al conocimiento para realizar análisis de requisitos, diseño,
programación y pruebas de software.
• del Dominio: refiere al conocimiento del dominio de aplicación tales como banca,
seguros, telecomunicaciones.
2.1.3 Gestión del conocimiento
Así como variadas son las definiciones de conocimiento, también pueden encontrarse
diferentes enfoques y aproximaciones al concepto de GC.
Así, para Wiig [Wiig, K., 1995] la GC es un marco conceptual que abarca todas las
actividades y perspectivas requeridas para obtener una visión general, crear, tratar con y
beneficiarse de los activos corporativos de conocimientos y de sus roles particulares como
soporte para el negocio y las operaciones de la corporación.
Quintas y colegas [Quintas, P. et al., 1997] consideran que la GC es cualquier proceso
o práctica para crear, adquirir, capturar, compartir y usar conocimiento, cualquiera sea el
lugar donde resida, para mejorar el aprendizaje y el desempeño en las organizaciones
Para Gupta y Sharma [Gupta, J., et al., 2004] la GC es la colección de procesos que
gobiernan la creación, diseminación, y utilización de conocimiento.
Bhatt [Bhatt, G., 2001] afirma que GC es el proceso de creación, validación,
presentación, distribución y aplicación del conocimiento.
Para Alavi y Leidner [Alavi, M. et al., 1999], la GC refiere a un proceso sistemático y
organizacionalmente especificado para adquirir, organizar y comunicar tanto el conocimiento
tácito como el explícito de los empleados, de modo que otros empleados puedan hacer uso
de él para ser mas efectivos y productivos en sus trabajos.
Por su parte, Handzic [Handzic, M., 2003] sostiene que el principal propósito de la GC
es asegurar que las personas correctas tengan el conocimiento correcto en el momento
adecuado.
Para del Moral y colegas [del Moral, A. et al., 2007], la meta primaria de la GC la
mejora de las prestaciones organizativas por la captación de los individuos para capturar,
16
compartir y aplicar sus conocimientos colectivos para tomas decisiones óptimas en tiempo
real. Por tiempo real, estos autores entienden el tiempo disponible para tomar la decisión y
ejecutar la acción que afectará materialmente el resultado.
2.1.4 Estrategias para la gestión del conocimiento
Para Bierly y Dale [Bierly, P., Dale, P., 2002], una estrategia de conocimiento se
define como un conjunto de elecciones estratégicas que realiza la empresa en cuanto a dos
dimensiones: por un lado, la creación o adquisición de nuevo conocimiento y, por otro, la
capacidad organizativa para utilizar el conocimiento existente con el fin de crear nuevos
productos y procesos organizativos.
Por su parte, Ventura y Ordoñez [Ventura, J., Ordoñez, P., 2007] mencionan que
dentro de la literatura se diferencia entre estrategia de conocimiento y estrategia de GC y
definen ésta última como un conjunto de actuaciones desarrolladas para cerrar las brechas
de conocimiento existentes en una organización, una vez que ésta ha identificado las
oportunidades, fortalezas, amenazas y debilidades respecto a los recursos basados en el
conocimiento.
2.1.4.1 Codificación y personalización Las organizaciones en general pueden adoptar diferentes estrategias o enfoques para
la GC. Los estudios que en este sentido llevaron a cabo Hansen, Mohria y Tierney [Hansen,
M. et al., 1999] revelan que las organizaciones que están en el negocio de la consultoría
emplean dos estrategias bien diferentes para la GC. Los autores denominaron codificación y
personalización a estas estrategias.
La estrategia de codificación se centra en la codificación del conocimiento y en su
almacenamiento en algún repositorio, desde donde puede ser posteriormente accedido y
utilizado por otros individuos en la organización. Este enfoque permite a las personas buscar
y recuperar conocimiento codificado sin necesidad de tomar contacto con la persona que lo
desarrolló originalmente.
La estrategia de personalización se basa en el hecho de que el conocimiento está
íntimamente ligado a la persona que lo posee y es compartido principalmente a través del
contacto interpersonal directo.
Los autores citados sostienen que la elección entre codificación y personalización es
una elección central que toda organización deberá enfrentar al momento de definir cual ha
de ser su estrategia para la GC. Sin embargo, la adopción de una de las estrategias no
implica dejar de lado por completo a la otra. El estudio desarrollado por estos autores
mostró, luego de un análisis mas profundo, que las organizaciones en realidad enfatizan en
uso de una de las estrategias y utilizan la otra en un rol de soporte.
17
La elección de la estrategia principal debe estar en directa relación con la estrategia
competitiva de la organización. En tal sentido, Talisayon [Talisayon, S., 2001] considera que
aquellas compañías que ofrecen productos y servicios repetitivos, similares o modularizados
y que, en consecuencia, pueden hacer un reuso importante del conocimiento, deben
seleccionar como principal la estrategia de codificación. Para aquellas compañías que, por
el contrario, ofrecen servicios y productos particularizados a cada cliente o que requieren de
un alto grado de experiencia, la estrategia de personalización ha de ser la que se adopte
como la principal.
No obstante estos lineamientos generales para la selección de la estrategia principal,
una organización puede utilizar ambas estrategias, enfatizando la más adecuada en función
del tipo de proyecto o de actividad de que se trate en cada caso. La estrategia de
codificación puede aplicarse a aquellos proyectos, actividades o situaciones en las cuales es
frecuente la reutilización de conocimiento, mientras que puede aplicarse la estrategia de
personalización en aquellas actividades o situaciones donde el conocimiento tácito y las
habilidades y experiencias personales son más importantes.
2.1.4.2 Exploración y explotación Las estrategias de exploración y de explotación son debidas a Zack [Zack, M., 1999] y
las mismas están relacionadas con su propuesta de utilizar el análisis FADO tradicional a los
aspectos relacionados con las capacidades y recursos intelectuales de una organización.
El análisis FADO orientado al conocimiento, en paralelo con el análisis FADO
tradicional, describe el enfoque general que una organización se propone tomar para alinear
sus capacidades y recursos de conocimiento a los requerimientos intelectuales de su
estrategia competitiva [Zack, M., 1999].
La estrategia de explotación de conocimiento apunta a que la organización enfatice
el uso del conocimiento que posee para afianzar su posición estratégica en su sector
industrial y para superar y aventajar a sus competidores.
La estrategia de exploración de conocimiento, por su parte, apunta a enfocar a la
organización a desarrollar nuevo conocimiento que la ayude a crear nuevos nichos de
mercado para sus productos y servicios, así como para crear productos y servicios nuevos.
Estas dos estrategias no son mutuamente excluyentes. Una organización puede
necesitar desarrollar una determinada área de conocimiento, al tiempo que,
simultáneamente, explotar otra. En última instancia, asegura Zack, lo ideal para muchas
organizaciones es mantener un balance entre exploración y explotación en todas las áreas
de conocimiento estratégico.
La exploración de conocimiento provee el capital intelectual que ha de propulsar a la
organización a nuevos nichos de mercado al tiempo que le permite mantener la viabilidad de
18
sus nichos actuales. La explotación de ese conocimiento provee el capital financiero
necesario para alimentar y soportar sucesivas rondas de innovación y exploración.
2.1.5 Procesos de la gestión del conocimiento
Las definiciones de GC expuestas anteriormente hacen uso, implícita o explícitamente,
del concepto de proceso.
Los autores mencionados en ese apartado, y otros que se presentan a continuación,
han propuesto diferentes modelos o “ciclos de vida” para la GC en una organización. Estos
diferentes modelos están constituidos por una serie de fases o procesos, según la
terminología propia de cada autor, que varían en cantidad y en denominación. No obstante
estas diferencias, el análisis de estos modelos revela importantes similitudes en los
propósitos y objetivos de los diferentes procesos.
A los efectos de unificar la terminología, se propone aquí un modelo que, sin ser
original, recoge lo más significativo de estos modelos. La tabla 2.4 presenta los procesos
propuestos por el autor y los correspondientes procesos o fases tomados de los modelos
estudiados. Estos otros modelos son los de Probst, Raub y Romhardt [Probst, G. et al.,
2001], Bhatt [Bhatt, G., 2001], Abou-Zeid [Abou-Zeid, E.-S., 2001] y Davenport y Prusak
[Davenport, T. et al., 1998].
Probst, Raub y Romhardt Bhatt Abou-Zeid Davenport y
Prusak
Alineación con Estrategia
Organizacional
Definición de objetivos
Identificación Identificación Identificación
Incorporación
Adquisición
Desarrollo
Creación
Generación
Elaboración
Generación
Preservación Preservación Preservación Codificación
Diseminación
Compartición y Distribución
Distribución
Movilización
Transferencia
Utilización Utilización Aplicación
Tabla 2.4: Procesos de gestión del conocimiento
19
2.1.5.1 Alineación con Estrategia Organizacional Una organización de cualquier índole, pública o privada, con o sin fines de lucro,
orientada a la producción de bienes o a la prestación de servicios, tiene un propósito o
misión que da razón de ser a su existencia. Para cumplir con su misión, la organización
debe establecer una serie de metas y objetivos a largo plazo, determinar las líneas
generales de acción y asignar recursos humanos y materiales para alcanzar esos objetivos,
es decir, debe establecer su estrategia de negocios. Cualquiera sea la estrategia de
negocios que defina y adopte, una organización deberá contar con una serie de
conocimientos, habilidades y capacidades que le permita desarrollar de manera eficiente las
líneas de acción orientadas a cumplir con sus metas y objetivos estratégicos. La elección
estratégica que una organización hace en relación con la tecnología, los mercados, los
productos, los servicios y los procesos tienen un impacto directo en el conocimiento, las
habilidades y las competencias que necesita para competir [Zack, M., 1999].
En consecuencia, esos conocimientos, habilidades y capacidades se tornan
estratégicos en cuanto a que son necesarios (aunque no suficientes) para que la
organización pueda desarrollar su estrategia general. De este modo, junto con la
planificación estratégica tradicional (que habitualmente refiere a mercados y competencia)
las organizaciones deben establecer lo que Probst, Raub y Romhardt [Probst, G. et al.,
2001] denominan objetivos de conocimiento estratégico. Estos objetivos estratégicos definen
el conocimiento medular para la organización y especifican qué conocimiento, habilidades y
experiencias serán necesarias en el futuro. Alineado con esta posición, Zack [Zack, M.,
2002] considera que las organizaciones deben definir un estrategia del conocimiento
orientada a propiciar un entendimiento acerca de cual conocimiento es estratégico y porqué
lo es. De este modo, dicen Probst, Raub y Romhardt [Probst, G. et al., 2001], la estrategia
se convierte en una herramienta para dirigir la organización hacia la acumulación
sistemática de conocimiento y experiencia, tanto individual como colectiva, y para la
administración deliberada del conocimiento.
2.1.5.2 Identificación El proceso de Identificación del conocimiento consiste de la identificación de tres
elementos esenciales, discutidos a continuación, y que son el conocimiento que es
estratégico para la organización, los activos de conocimiento de la organización y los vacíos
o brechas de conocimiento entre los dos anteriores.
O bien, en términos propuestos por del Moral y colegas [del Moral, A. et al., 2007], se
trata de identificar, respectivamente, “lo que es necesario saber”, “lo que se sabe” y “lo que
no se sabe”.
20
A) Identificación del Conocimiento Estratégico
A partir de la discusión anterior, la Identificación del Conocimiento Estratégico implica,
tal y como se muestra en la figura 2.2, establecer cual es el conjunto de conocimientos,
habilidades y experiencias que la organización debe poseer para llevar adelante su
estrategia de negocios. La estrategia de negocios indica que es lo que la organización debe
hacer y el objetivo de la Identificación del Conocimiento Estratégico es determinar que es lo
que la organización debe conocer.
Figura 2.2: Identificación del conocimiento estratégico
B) Identificación de los Activos de Conocimiento
La Identificación de los Activos de Conocimiento implica relevar y construir un
inventario de los conocimientos, habilidades y experiencia existentes en la organización.
Estos conocimientos y habilidades, esto es, lo que la organización conoce, condiciona lo que
la organización es capaz de hacer, tal como se representa en la figura 2.3.
Figura 2.3: Identificación de los activos de conocimiento
C) Identificación de brechas de conocimiento
En la gestión estratégica tradicional, la diferencia entre lo que la organización debe
hacer y lo que en realidad está haciendo se denomina brecha estratégica. Esta brecha
estratégica puede implicar la existencia de una potencial brecha de conocimiento, es decir,
dada una brecha entre lo que la organización debe hacer y lo que puede hacer, puede
también haber una brecha entre lo que esa organización debe conocer para ejecutar su
estrategia y lo que efectivamente conoce. La figura 2.4 muestra la relación entre la
estrategia de negocio y la estrategia de conocimientos, así como las brechas respectivas.
21
Figura 2.4: Brechas estratégica y de conocimientos
Para Zack [Zack, M., 2002], estas brechas de conocimiento estratégico son de dos
tipos: interna y externa. La brecha interna de conocimiento estratégico es la que hay entre
el conocimiento que tiene hoy la organización y el que necesita tener para ejecutar su
estrategia. En el análisis FADO orientado al conocimiento que propone Zack, esta brecha
interna es análoga a la parte de análisis de fortalezas y debilidades del análisis FADO
tradicional. La brecha externa de conocimiento estratégico es la que hay entre el
conocimiento de la organización y el de sus competidores, en el presente y en el futuro. Esta
brecha representa el análisis de las oportunidades y amenazas en el análisis FADO
tradicional. El análisis FADO se expone con mayor detalle más adelante en este capítulo.
2.1.5.3 Incorporación Las brechas de conocimiento identificadas en el proceso anterior indican a la
organización hacia dónde enfocar sus esfuerzos para procurarse ese conocimiento ausente
o limitado. En tal sentido, el proceso de incorporación de conocimiento debe orientarse a
eliminar esas brechas entre lo que la organización conoce y lo que debe conocer, tanto para
ejecutar su estrategia como para competir contra sus competidores
En proceso de incorporación de conocimiento puede dividirse en adquisición de
conocimiento a partir de fuentes externas a la organización y creación o desarrollo de nuevo
conocimiento generado internamente. Para Davenport y Prusak [Davenport, T. et al., 1998],
la forma más directa y a menudo más efectiva de adquirir conocimiento es “comprándolo”;
esto es, comprando una organización o contratando personal que lo posea. También puede
adquirirse conocimiento mediante la compra de patentes, derechos de autor, propiedad
intelectual de inventos, etc. Respecto a la desarrollo de conocimiento, Probst, Raub y
Romhardt [Probst, G. et al., 2001] consideran que este proceso incluye todas las actividades
administrativas mediante las cuales se procura adquirir las competencias con que no se
cuenta o crear aquellas que todavía no existen ni dentro ni fuera de la organización.
22
2.1.5.4 Preservación Este proceso refiere a todas las actividades orientadas a salvaguardar el conocimiento
existente en la organización y a asegurar que dicho conocimiento continúe perteneciendo a
la misma. Para el caso de conocimiento explícito, las actividades de preservación consisten
de la formalización, codificación, organización y almacenamiento de ese conocimiento en
diferentes medios. Si se trata de conocimiento tácito, su preservación depende en buena
medida de la permanencia en la organización de los poseedores de ese conocimiento.
2.2.5.5 Diseminación El conocimiento existente en la organización debe ser distribuido y compartido a
diferentes niveles de la misma antes de que pueda ser efectivamente utilizado a nivel
organizacional. Probst, Raub y Romhardt [Probst, G. et al., 2001] sostienen que una de la
actividades más difíciles de la GC es distribuirlo a las personas correctas o hacerlo
disponible en el punto en que se necesite.
De acuerdo con el contexto, compartición y distribución del conocimiento puede
significar un proceso dirigido desde un centro de distribución de conocimiento hacia grupos
específicos de empleados, o puede ser la transferencia de conocimiento entre individuos o
dentro de un equipo o grupo de trabajo. Para Probst, Raub y Romhardt [Probst, G., et al.,
2001], las dos principales estrategias para la diseminación del conocimiento son las
denominadas de empuje (“push”) y de extracción (“pull”).
La estrategia de empuje implica que las decisiones acerca de qué conocimiento
distribuir y quienes deben recibirlo se toman desde el centro de distribución y luego se
“empuja” ese conocimiento hacia la organización a través de canales claramente definidos,
tales como sesiones de capacitación o mediante empleados cuya función es “hacer circular”
el conocimiento. La estrategia de extracción, por el contrario, se basa en que es el usuario
del conocimiento, en base a sus necesidades, el que busca y accede al conocimiento.
Para una diseminación eficaz del conocimiento a nivel organizacional se requiere de
infraestructuras adecuadas desde el punto de vista organizacional y técnico, Sin embargo,
sostienen Probst, Raub y Romhardt [Probst, G., et al., 2001], la creación de infraestructuras
no es suficiente para poner el proceso en movimiento ya que existen diversas barreras
individuales y culturales a la compartición de conocimiento.
2.1.5.6 Utilización Para Probst, Raub y Romhardt [Probst, G. et al., 2001], una de las funciones de la GC
es asegurar que la organización utilice su conocimiento puesto que, si no se aplica, el
conocimiento no tiene valor. Para estos autores, el uso del conocimiento puede verse con la
fase de ejecución en el proceso de GC ya que es aquí donde el conocimiento se transforma
en resultados concretos.
23
Según Bhatt [Bhatt, G., 2001], la aplicación del conocimiento significa hacer más activo
y relevante el conocimiento para la creación de valor por parte de la organización.
Gottschalk [Gottschalk, P., 2004], por su parte, considera que la fuente de ventaja
competitiva de una organización reside en la utilización del conocimiento más que en el
conocimiento en sí.
2.1.6 Técnicas y herramientas para la gestión del conocimiento
En este apartado se presentan y describen un conjunto de técnicas y herramientas
para la GC y se muestra en cual o cuales de los procesos de GC expuestos anteriormente
con aplicables. Las técnicas y herramientas que se presentan son las siguientes:
2.1.6.1 Análisis FADO El marco de referencia conocido como FADO (Fortalezas, Amenazas, Debilidades y
Oportunidades) es, tal vez, el enfoque más conocido para definir la estrategia competitiva de
una organización. Llevar a cabo este análisis implica describir y analizar las capacidades
internas de una organización; es decir, sus fortalezas y debilidades en relación con las
oportunidades y amenazas de su entorno competitivo.
Tal como lo comenta Friss de Kereki [Friss de Kereki, I., 2003], los componentes del
marco de referencia FADO pueden explicarse separando el análisis en interno y externo.
A) Interno, que incluye el análisis de las fortalezas y debilidades de la organización.
Una fortaleza es un recurso interno que posee la organización, cuya utilización le permite
competir en mejores condiciones al proporcionarle una eventual ventaja frente a sus
competidores. Una debilidad, por el contrario, es una limitación, defecto o inconsistencia que
constituye un obstáculo para el logro de los objetivos de la organización.
B) Externo, que incluye el análisis de las oportunidades y amenazas. Una oportunidad
es una circunstancia o situación que es potencialmente favorable a los intereses de la
organización. Por su parte, una amenaza es una circunstancia o situación desfavorable para
la organización, que puede afectar negativamente su desempeño en relación con la
competencia.
El análisis FADO, tal como se lo ha aplicado tradicionalmente, apunta a definir la
estrategia organizacional en términos de productos y de posicionamiento en el sector
industrial de acuerdo a una estrategia genérica de competencia en base a costo o a
diferenciación [Porter, M., 1987].
Tal como lo expone Zack [Zack, M., 1999], el marco de referencia FADO tradicional
provee la base para describir una estrategia en base al conocimiento. Según este autor,
[Zack, M., 2002a], una estrategia de conocimiento implica la noción de una estrategia
competitiva construida alrededor de las capacidades y los recursos intelectuales de la
24
organización. El propio Zack [Zack, 2002b], propone un proceso general para realizar el
análisis FADO orientado al conocimiento. Este proceso, en ocho pasos, es el siguiente:
1. Describir el sector industrial de la organización en términos de dominios claves de
conocimientos.
2. Identificar la estrategia actual de la organización.
3. Identificar los conocimientos requeridos para formular y ejecutar de manera exitosa
esa estrategia.
4. Comparar los conocimientos requeridos con los conocimientos existentes en la
organización, para identificar sus brechas internas de conocimiento; esto es, sus
fortalezas y debilidades de conocimiento.
5. Comparar las posiciones de conocimientos existentes y deseadas de la organización
contra las de los competidores para identificar brechas externas de conocimiento;
esto es, las oportunidades y amenazas de conocimiento.
6. Evaluar las habilidades de aprendizaje de la organización en relación con la
necesidad de realinear el conocimiento existente y en relación con las habilidades de
aprendizaje de los competidores.
7. Determinar si el conocimiento y la estrategia de la organización están alineados. Si
no lo están, determinar si la organización es capaz de modificar su conocimiento o si,
en cambio, debería modificar su estrategia.
8. Independientemente de la posición de estrategia del conocimiento que
eventualmente adopte, determinar si los programas de GC y de aprendizaje
organizacional están enfocados en las brechas de conocimiento interna o externa.
La técnica del análisis FADO es aplicable, pues, a los procesos de Alineación con
Estrategia Organizacional y de Identificación del conocimiento.
2.1.6.2 Pruebas comparativas Las pruebas comparativas o benchmarking consisten de una serie de actividades
mediante las cuales una organización compara la forma en que desarrolla sus procesos de
negocio y otros aspectos de su funcionamiento organizacional con la forma en que lo hacen
otras organizaciones en su mismo sector industrial. Mediante esta técnica, una organización
puede identificar las prácticas relevantes de sus competidores bien posicionados en el
mercado y luego evaluar el estado actual de sus proceso análogos para identificar
diferencias, carencias o problemas de diseño o ejecución de esos procesos [Gupta, J.,
2002].
Para Spendolini [Spendolini, I., 1994], el benchmarking es un proceso sistemático y
continuo para evaluar los productos, servicios y procesos de trabajo de las organizaciones
25
que son reconocidas como representantes de las mejores prácticas, con el propósito de
realizar mejoras organizacionales. Según este autor, pueden distinguirse tres tipos de
benchmarking:
A) Interno. En el benchmarking interno se asume que existen diferencias entre los
diferentes procesos de trabajo de una organización y que algunos de esos
procesos pueden ser más eficientes o eficaces que los de otras partes de la misma
organización. El objetivo del benchmarking interno es, pues, identificar las mejores
prácticas dentro de una organización. Probst, Raub y Romhardt [Probst, G., et al.,
2001] consideran que las pruebas comparativas internas son valiosas como
proceso de identificación del conocimiento ya que pone de manifiesto las áreas
donde hay potencial para acrecentar la eficiencia.
B) Competitivo. El benchmarking competitivo comprende la identificación de
productos, servicios y procesos de trabajo de los competidores directos de la
organización; es decir, de otras organizaciones dentro de su mismo sector de
mercado. El objetivo del benchmarking competitivo es, pues, identificar información
de los productos, los servicios y los resultados comerciales de los competidores y
compararlos con los de la organización.
C) Funcional. El benchmarking funcional comprende la identificación de productos,
servicios y procesos de trabajo de organizaciones que pueden o no ser
competidores directos de la organización. Se usa la palabra funcional porque en
este campo el benchmarking principalmente comprende actividades específicas en
un área funcional determinada. El objetivo del benchmarking funcional es, pues,
identificar las mejores prácticas de cualquier tipo de organización que se haya
ganado la reputación de excelencia en el área específica que se esté sometiendo a
benchmarking.
Asimismo, para este autor [Spendolini, I., 1994], el proceso de benchmarking consiste
de cinco etapas.
1. Establecer objetivos: esta etapa consiste en definir el tipo de benchmarking a
realizar (según la clasificación anterior) y en determinar las actividades o asuntos
específicos sobre los cuales se va a enfocar el benchmarking.
2. Definir el equipo de benchmarking: esta etapa consiste en definir los miembros del
equipo de benchmarking y en la asignación de roles y responsabilidades.
3. Identificar los “socios” del benchmarking: En esta etapa se identifican las fuentes
de información que se utilizarán para recopilar la información de benchmarking y
también la identificación de las mejores prácticas a nivel organizacional o del sector
industrial, según el tipo de benchmarking definido en la primera etapa. Por “socio” del
26
benchmarking se entiende cualquier persona u organización que va a proporcionar
información relacionada con la investigación de benchmarking.
4. Recopilar y analizar la información: en esta etapa se seleccionan los métodos
específicos para recolectar la información, se contacta a los socios del benchmarking
y se recopila y luego analiza la información.
5. Elaborar el informe final: en esta última etapa se genera el informe final del
bechmarking el cual, además de los hallazgos realizados, debería contener una serie
de recomendaciones para la implementación del cambio a nivel organizacional,
relacionado con las actividades o asuntos sobre los cuales se enfocó la
investigación.
La técnica de benchmarking es aplicable, pues, los procesos de Identificación y de
Incorporación de Conocimiento.
2.1.6.3 Mapas de conocimientos Un mapa de conocimientos en una representación textual o gráfica de los
conocimientos existentes en una organización y muestra dónde están ubicados o quien los
posee. Como señalan Davenport y Prusak [Davenport, T. et al., 1998], un mapa de
conocimientos apunta al conocimiento pero no lo contiene; es una guía y no un repositorio.
Por su parte, Vail [Vail, E., 1999] considera que los mapas de conocimiento son una
excelente vía para capturar y compartir conocimiento explícito, así como para servir de
apuntadores a los poseedores de conocimiento implícito o tácito.
En el contexto de una organización pueden distinguirse varios tipos de mapas de
conocimientos, orientados a visualizar los conocimientos desde diferentes puntos de vista o
enfocados hacia diferentes objetivos. En este sentido, Eppler [Eppler, M., 2001] propone una
distinción en cinco tipos de mapas de conocimientos, de acuerdo con la siguiente
descripción:
A) Fuentes de Conocimientos: son una guía de los conocimientos existentes en la
organización y muestran dónde están ubicados o quien los posee.
B) Activos de Conocimientos: muestran los conocimientos existentes en la
organización y en qué grado se los posee.
C) Estructura de Conocimientos: permiten delinear la arquitectura global de un
dominio de conocimientos y muestran como sus partes se relacionan unas con otras.
D) Aplicación de Conocimientos: muestran qué tipos de conocimientos deben ser
aplicados en una cierta etapa de un proceso o en una situación de negocios
específica.
27
E) Desarrollo de Conocimientos: permiten describir las etapas necesarias para
desarrollar o evolucionar una determinada competencia o habilidad
Plumley [Plumley, D., 2003] hace referencia a otra clasificación de los mapas de
conocimiento, expuesta por Caldwell [Caldwell, F., 2002] Los cuatro tipos de mapas a los
que refiere son:
A) De procesos: muestran el conocimiento (y las fuentes de conocimiento) mapeados a
procesos de negocios, que pueden ser de cualquier tipo. Según Cladwell, uno de los
principales usos de este tipo de mapas es la planificación e implementación de
iniciativas de GC en una organización.
B) Conceptuales: o “taxonomías” como también los refiere Cladwell, son una forma de
organizar jerárquicamente y clasificar contenido. Estas taxonomías pueden ser
utilizadas para organizar contenidos en un repositorio.
C) De Competencias: estos mapas pueden utilizarse para documentar los
conocimientos, habilidades y posiciones de los miembros de una organización; esto
es, para crear un perfil de competencias. Estos mapas pueden convertirse en
directorios del tipo de “páginas amarillas” que permitan a los empleados encontrar
expertos sobre temas o asuntos específicos en la organización.
D) De Redes Sociales: estos mapas muestran las redes de conocimiento y patrones de
interacción entre miembros de un grupo de personas y pueden ser utilizados para
analizar los flujos y la compartición de información y conocimientos en un contexto
social.
Según lo menciona Plumley [Plumley, D., 2003], la técnica de confección de mapas
tiene varias ventajas. En primer lugar, un mapa de conocimientos se representa en un
formato visual claro y simple que es fácil de entender, fácil de actualizar y fácil de usar por
los usuarios en la organización. Segundo, la confección de los mapas fuerza a sus
constructores a identificar áreas claves de conocimientos que sean las más estratégicas y/o
críticas para la organización y su negocio. Tercero, el análisis de los mapas genera ideas
para compartir el conocimiento que es más adecuado para la organización y su contexto de
negocios.
Vail [Vail, E., 1999] presenta una metodología genérica en nueve pasos para iniciar el
proceso de desarrollo de un mapa de conocimiento. Estos pasos son los siguientes:
1. Identificar al patrocinador y sus objetivos.
2. Determinar para qué se va a utilizar el mapa, el alcance del mismo y los requisitos
específicos del usuario.
28
3. Iniciar un proceso de “educación” acerca de los beneficios y requerimientos de
proceso de mapeo, comenzando con el patrocinador.
4. Identificar los interesados claves (“stakeholders”).
5. Crear un comité con representantes directos del patrocinador, de los interesados
claves y con personal técnico.
6. Crear el correspondiente comité técnico del mapa de conocimiento.
7. Desarrollar un proceso de evaluación y selección de la herramienta con la cual se
va a construir el mapa.
8. Identificar al “custodio” del mapa, la ubicación del repositorio y el proceso de
mantenimiento.
9. Crear el mapa de conocimiento organizacional inicial.
La técnica de mapas de conocimiento es aplicable, pues, el proceso de Identificación
de Conocimiento.
2.1.6.4 Lecciones aprendidas Según la definición que propone Sacchi [Sacchi, 1999], una lección aprendida es
conocimiento o entendimiento adquirido por experiencia. Esta experiencia puede ser
positiva, tal como en una prueba o misión exitosa, o negativa, como en un accidente o falla.
Harrison [Harrison, W., 2002], por su parte, define lección aprendida como una buena
práctica de trabajo y enfoque innovador que es capturado y compartido para promover la
repetición de su aplicación, o una experiencia o práctica adversa de trabajo que es
capturada y compartida para evitar su repetición. Para del Moral y colegas [del Moral, A. et
al., 2007], una lección aprendida es cualquier experiencia o percepción positiva o negativa
que se puede usar para mejorar el rendimiento de una organización en el futuro.
Una pieza de conocimiento, para ser considerada una lección aprendida, debe poseer
ciertos atributos tales como, ser significativa, correcta y aplicable. Una lección debe ser
significativa en cuanto a que tiene un impacto real o asumido en las operaciones, válida en
cuanto a que es correcta desde el punto de vista técnico o factual, y aplicable en cuanto a
que identifica un diseño, un proceso y una decisión específica que reduce o elimina la
posibilidad de un fallo o accidente, o refuerza un resultado positivo.
Según Weber, Aha y Becerra-Fernandez [Weber, R. et al., 2001], el proceso de
Lecciones Aprendidas consiste de cinco tareas:
1. Recolección: hay esencialmente dos formas de recolectar información: activa y
pasiva. La recolección activa se da cuando la organización establece un mecanismo
activo de búsqueda de lecciones aprendidas, mientras que la recolección pasiva
29
ocurre cuando las personas, por su propia iniciativa, proponen nuevas lecciones
aprendidas.
2. Verificación: las lecciones aprendidas deben ser validadas en relación con su
relevancia, corrección, no redundancia y consistencia. Esta validación implica,
además, decidir qué hacer con una candidata a lección aprendida: aceptarla,
modificarla o rechazarla.
3. Almacenamiento: Las lecciones aprendidas deben ser almacenadas en algún
repositorio para su preservación y posterior recuperación.
4. Diseminación: hay dos enfoques principales para la diseminación, denominadas
también activa y pasiva. La diseminación pasiva o de extracción (“pull”) consiste en
que las personas busquen por sí mismas las lecciones aprendidas de su interés,
mientras que en la diseminación activa o de empuje (“push”) los usuarios son
notificados de las lecciones en las que están interesados.
5. Reutilización: para que una lección aprendida sea reutilizable, debe incluir alguna
recomendación que indique si es adecuada a una determinada situación.
Este proceso de lecciones aprendidas puede llevarse a cabo, por ejemplo, una vez
finalizado un proyecto. En tal sentido, Probst, Raub y Romhardt [Probst, G., et al., 2001]
indican que, después que un proyecto ha finalizado, los integrantes del equipo pueden
reunirse para analizar el trabajo realizado, lo que han aprendido y lo que deberían tener en
mente los equipo de trabajo futuros cuando se enfrenten a problemas o situaciones
similares. De este modo, el proceso de lecciones aprendidas permite depurar e incorporar
actividades pasadas y aprender de los éxitos y de los errores anteriores.
La técnica de Lecciones Aprendidas es aplicable, pues, los procesos de Preservación
y de Diseminación de Conocimiento.
2.1.6.5 Mejores prácticas La American Society for Quality define mejor práctica como un método superior o una
innovación práctica que contribuye a un mejor desempeño de una organización, usualmente
reconocida como “la mejor” por otras organizaciones colegas (“peer organizations”).
Probst, Raub y Romhardt [Probst, G. et al, 2001] mencionan dos factores por los
cuales la transferencia de mejores prácticas casi siempre fracasa. Uno de ellos refiere a que
la unidad receptora no tiene suficiente conocimiento para reconocer el valor de la mejor
práctica y el uso significativo de la misma para sus propios propósitos. El otro aspecto
refiere a la incertidumbre acerca de los factores que determinan el funcionamiento de la
práctica o que conducen a sus buenos resultados.
30
La técnica de Mejores Prácticas es aplicable, pues, los procesos de Preservación y
Diseminación de Conocimiento.
2.1.6.6 Comunidades de práctica La expresión comunidad de práctica fue utilizada por primera vez por Wenger y Lave
[Wenger, E. et al., 1991]. Desde entonces, diferentes definiciones y conceptualizaciones han
sido propuestas las que, en general, refieren a dos aspectos esenciales: la importancia de
compartir información, conocimiento y experiencias entre un grupo de personas y el valor
que esa actividad provee a los miembros de ese grupo y a la organización a la que
pertenecen.
Wenger, McDermott y Snyder [Wenger, E. et al., 2002] definen comunidad de práctica
como un grupo de personas que comparten un interés, un conjunto de problemas o una
pasión por un tema y que profundizan sus conocimientos y experiencias en esa área
interactuando de manera habitual.
Por su parte, Lesser y Storck [Lesser, E. et al., 2001] consideran que una comunidad
de práctica es un grupo de personas cuyos miembros se comprometen de manera regular a
compartir y aprender, basados en sus intereses comunes.
Las comunidades de práctica difieren en varios aspectos de otras formas de
organización. La tabla 2.5, debida a Wenger y Snyder [Wenger, E. et al., 2000], compara las
comunidades de práctica con los grupos formales de trabajo y con los equipos de proyecto:
Comunidad de práctica
Grupo formal de trabajo
Equipo de proyecto
Propósito
Desarrollar las capacidades de sus miembros; construir e intercambiar conocimientos
Proveer un producto o un servicio
Cumplir con un tarea específica
Quienes pertenecen
Las personas que voluntariamente deciden integrarse
Los empleados que reportan al gerente del grupo
Los empleados que han sido asignados al proyecto
Qué los mantiene unidos
El interés por los temas tratados
Los requerimientos del trabajo y las metas comunes
Las metas y objetivos del proyecto
Duración Mientras el grupo mantenga interés
Hasta la próxima reorganización
Hasta que el proyecto haya sido completado
Tabla 2.5: Comunidades de práctica, grupos y equipos
Lesser y Storck [Lesser, E. et al., 2001], en un estudio realizado sobre el tema,
describen de qué manera las comunidades de práctica incrementan el capital social y el
31
desempeño organizacional, además de reportar la generación de resultados valiosos
relativos a la creación de nuevas oportunidades de negocios, suavizar la curva de
aprendizaje de los nuevos empleados, reducir el retrabajo y responder mejor y más
rápidamente a las requerimientos y necesidades de los clientes.
De acuerdo con Wenger, McDermott y Snyder [Wenger, E. et al., 2002], cada
comunidad de práctica es una combinación de tres elementos fundamentales: un dominio de
conocimiento, que define un conjunto de temas o asuntos, una comunidad de personas que
tienen interés en ese dominio y la práctica compartida que estas personas desarrollan para
ser efectivos en su dominio.
La técnica de Comunidades de Práctica es aplicable, pues, los procesos de
Incorporación, de Preservación y de Diseminación de conocimiento.
2.1.6.7 Programas de capacitación Según Gore [Gore, E., 2003], las organizaciones utilizan los programas de
capacitación como una de las herramientas usuales para incorporar nuevas conductas y
modificar rutinas. Este autor define capacitación como un proceso planificado de
adquisición de nuevos conocimientos susceptibles de ser transferidos a las rutinas de
trabajo, para modificarlas en parte o sustancialmente, y no sólo para resolver problemas
sino para cuestionar los criterios a partir de los cuales éstos son resueltos.
2.1.6.8 Mentoring y Coaching El término mentor tiene un origen mitológico y fue utilizado por Homero [Homero,
1997], en su obra La Odisea. Hace referencia a Mentor, personaje de esta novela, que
quedó a cargo de educar (en el sentido de formar, guiar y aconsejar) a Telémaco, hijo de
Ulises, para ser rey y sustituir a su padre llegado el momento.
Adey y Early [Adey, M., 1993] entienden que el mentoring ocurre cuando una persona
ayuda a otra en su desarrollo personal a adquirir nuevas habilidades, interiorizar puntos de
vista y a desarrollar su potencial. Para Conway [Conway, C., 1995] el mentoring es una
relación privada entre dos personas, basada en un deseo mutuo para el desarrollo personal
y profesional hacia un objetivo organizacional. Para Mumford [Mumford, A., 1997] se trata de
una relación interpersonal de tipo proteccionista en la cual se da un aprendizaje y un cambio
para experimentar y desarrollar habilidades, conocimientos, e interiorizar puntos de vista.
Allen [Allen, M., 1998] entiende el mentoring como la ayuda que una persona proporciona a
otra para que progrese en su conocimiento, su trabajo o su pensamiento. Finalmente, Soler
[Soler, R., 2003] define la estrategia del mentoring como el proceso mediante el cual una
persona con más experiencia (el mentor) enseña, aconseja, guía y ayuda a otra (el tutelado)
en su desarrollo personal y profesional, invirtiendo tiempo, energía y conocimientos.
32
El mentoring tiene tres componentes, que son: el mentor, el tutelado y un coordinador
que establece que el proceso de guía sea estructurado y el fiel a los procedimientos, a la
cultura y a las políticas de la organización.
El proceso del mentoring no sólo es aplicable a los nuevos empleados sino que
también es eficaz para los empleados que ya llevan un tiempo en la organización y que
eventualmente puedan ser promocionados en el futuro. Es una buena forma para retener
talento y una manera de asegurar que el conocimiento se mantiene en la organización y que
no se vaya con su poseedor cuando éste se retira.
El término coach significa preceptor y, cuando se usa en el contexto deportivo, su
acepción es la de entrenador [Cuyás, A., 1972]. Para Edwards [Edwards, L., 2003] la
diferencia esencial entre mentoring y coaching es que mediante el mentoring se enseña y se
brindan consejos mientras que el coaching facilita el aprendizaje.
Para esta autora, un gran coach hará uso de su pericia (“expertise”) para facilitar y
acelerar el aprendizaje individual e incrementar dramáticamente la efectividad personal del
entrenado (“coachee”). Soler [Soler, M., 2003] ha identificado, entre otras, las siguientes
características que debe tener un buen coach: entusiasta, digno de confianza, observador,
respetuoso, asertivo, reflexivo, profesional y abierto.
Según esta autora, el proceso de coaching es un proceso cíclico que consta de cinco
fases:
1. Analizar la situación: donde el coach debe identificar el tipo de carencia del
entrenado: conocimientos, habilidades, actitudes, motivación, etc.
2. Fijar objetivos: donde el coach y el entrenado fijan y priorizan los objetivos del
entrenamiento, habitualmente en base a una entrevista personal.
3. Determinar el plan de acción: es una relación de todas las tareas precisas para
lograr los objetivos fijados
4. Observar y medir el rendimiento: que implica observar y evaluar en forma
regular el desempeño del entrenado
5. Proporcionar retroalimentación: lo cual es la esencia del coaching e implica
corregir y modificar conductas sin causar resentimiento en el entrenado
2.1.7 Sistemas de gestión del conocimiento
Según lo definen Alavi y Leidner [Alavi, M. et al., 2001], los sistemas de GC son una
clase de sistemas de información aplicados a la GC organizacional, es decir, sistemas
basados en tecnologías de la información desarrollados para apoyar y mejorar los procesos
33
organizacionales de creación, almacenamiento y recuperación, transferencia y aplicación del
conocimiento. Estas autoras consideran que los sistemas de GC pueden concebirse y
diseñarse en base a dos modelos a los que denominan Modelo de Repositorio y Modelo de
Red.
Para el modelo de repositorio, el conocimiento se considera como objetos que
pueden ser recolectados, almacenados, organizados y distribuidos. Bajo esta perspectiva,
estos sistemas se enfocan principalmente a la GC explícito, apoyando los aspectos de
incorporación, preservación y distribución del mismo. Para esta clase de sistemas, las
tecnologías de la información tales como bases de datos relacionales y sistemas de
administración de documentos juegan un rol dominante en el desarrollo e implementación de
los mismos.
En contraste con el modelo de repositorio, el modelo de red se enfoca a proveer
acceso al conocimiento que reside en los individuos por medio del establecimiento de
enlaces directos entre las personas en lugar de apuntar a extraer y codificar el conocimiento
individual y capturarlo en repositorios o bases de conocimiento. Los sistemas de este tipo
apoyan principalmente los procesos de gestión de conocimiento tácito, que implican
interacciones sociales y los contactos y comunicaciones directas entre las personas.
2.2 Aprendizaje individual y organizacional
En esta sección se presentan las definiciones de aprendizaje, tanto individual como
organizacional, y se introduce el concepto de organización que aprende.
2.2.1 Aprendizaje
El diccionario de la Real Academia Española [RAE, 2001] define aprendizaje como
“acción y efecto de aprender algún arte, oficio u otra cosa”, y define aprender como “adquirir
el conocimiento de algo por medio del estudio o de la experiencia”.
Para Nadler y Nadler [Nadler, L. et al., 1994], aprendizaje es la adquisición de nuevas
habilidades, actitudes y conocimientos.
Schunk [Schunk, D., 1997] considera que el aprendizaje implica la adquisición y la
modificación de conocimiento, habilidades, estrategias, creencias, actitudes y conductas y
que se trata de un cambio perdurable de la conducta o en la capacidad de conducirse de
manera dada como resultado de la práctica o de otras formas de experiencia.
Para Swieriga y Wierdsma [Swieriga, J., et al., 1994], aprender es cambiar de
conducta, y el propósito de este cambio es alcanzar una forma de conducta que convenga
mejor a las metas de aquel que aprende, esto es, una conducta más efectiva.
34
Según Cohen y Levinthal [Cohen, W. et al, 1990], la investigación cognoscitiva sobre
el aprendizaje individual indica que la acumulación y la riqueza del conocimiento
preexistente aumenta la capacidad para colocar nuevo conocimiento en la memoria, así
como la capacidad para recordarlo y utilizarlo. Para estos autores, el aprendizaje es
acumulativo y la capacidad de aprendizaje es mayor cuando lo que se ha de aprender se
relaciona con lo que ya se conoce.
Choudrie y Salamat [Choudrie, J. et al., 2006], refieren a Meso y Smith, quienes
vinculan el aprendizaje con los procesos de conversión de conocimiento propuestos por
Nonaka y Takeuchi [Nonaka, I. et al., 1999]. Para ellos, el conocimiento emana del proceso
iterativo de externalización e internalización del conocimiento y explican que la
externalización ocurre cuando el conocimiento tácito de un individuo se captura como
conocimiento explícito, y la internalización ocurre cuando este conocimiento explícito
capturado es luego transformado en conocimiento tácito en otro individuo.
Para Gottschalk [Gottschalk, P., 2004], el aprender haciendo, el entrenamiento en el
trabajo, el aprendizaje por observación y las reuniones cara a cara son algunos procesos de
internalización por los cuales las personas adquieren conocimientos.
2.2.2 Aprendizaje experiencial
Los vínculos entre aprendizaje y experiencia han sido estudiados por diferentes
autores. Así, para Kolb [Kolb, D., 1984], aprender es un proceso por el cual el conocimiento
se crea a través de la transformación de la experiencia. Su modelo de aprendizaje
experiencial se basa en la noción de que el entendimiento no es un elemento fijo e
inmutable del pensamiento, sino que se forma y reforma por medio de la experiencia.
El modelo de aprendizaje de Kolb, que se muestra gráficamente en la figura 2.5, es
cíclico y requiere del aprendiz cuatro habilidades para que el aprendizaje sea exitoso:
experiencia concreta, observación reflexiva, conceptualización abstracta y experimentación
activa.
35
Experiencia Concreta
Experimentación Activa
Observación Reflexiva
Conceptualización Abstracta
Figura 2.5: Ciclo de aprendizaje experiencial (Kolb)
Hoag [Hoag, K., 2001] describe el ciclo de Kolb de la siguiente manera. En primer
término, el aprendiz se involucra completa y abiertamente en nuevas experiencias
(experiencia concreta). A esto le sigue la creación de un ambiente en el cual los aprendices
trabajan en forma conjunta (eventualmente bajo la guía de un instructor o “facilitador”), de
modo de interpretar y de reflexionar sobre esas nuevas experiencias desde diferentes
perspectivas (observación reflexiva). El tercer paso del modelo implica tomar como base los
antecedentes (backgrounds) del aprendiz para integrar de manera lógica estas nuevas
experiencias a sus capacidades previas (conceptualización abstracta). Finalmente, las
nuevas capacidades resultantes son aplicadas y ejercitadas en la toma de decisiones y en la
resolución de problemas en situaciones nuevas (experimentación activa).
El elemento central para el aprendizaje por la experiencia es el involucramiento activo
del aprendiz en el proceso de aprendizaje. Según Kolb [Kolb, D., 1984], además, el
aprendizaje se maximiza cuando el aprendiz se mueve a través de estas cuatro fases
durante el proceso de aprendizaje. En este mismo sentido, Marsick y O’Neil [Marsick, V. et
al., 1999] comentan, sobre el citado ciclo de aprendizaje de Kolb [Kolb, D., 1984] que acción,
reflexión, teoría y práctica son elementos de igual importancia.
Para Newell y Galliers [Newell, S. et al., 2006], una vez que un individuo, un grupo o
una organización han iterado a través de los cuatro procesos del ciclo de aprendizaje,
habrán adquirido nuevo conocimiento.
Cooper, Majchrzak y Faraj [Cooper, L. et al., 2005] comentan que el aprendizaje es el
resultado de la acción y la reflexión. Las acciones asociadas con hacer el trabajo en un
proyecto proveen las experiencias que establecen el escenario para el aprendizaje.
Agregan, sin embargo, que cerrar el ciclo de aprendizaje requiere reflexionar y pensar
acerca de esas experiencias.
Para Swieriga y Wierdsma [Swieriga, J., et al., 1994] aprender tiene relación con el
trabajo cuando el proceso de aprendizaje está orientado a la solución de problemas; es
36
decir, el aprendizaje se lleva a cabo mientras se trabaja. El ámbito donde se realiza una
determinada tarea es también una situación en la que se puede aprender y la propia tarea
es así mismo un ejercicio de aprendizaje.
A nivel de grupos de personas, Kayes, Kayes y Kolb [Kayes, A. et al., 2005] sostienen
que los equipos aprenden de la experiencia, según el modelo de Kolb [Kolb, D., 1984], si
tales equipos están conformados por miembros que:
A) Estén involucrados y comprometidos con el equipo y sus propósitos, y creando
nuevos conocimientos e identificando desafíos (experiencia concreta).
B) Se involucren en la reflexión y la conversación acerca de las experiencias del
equipo y hagan observaciones para asegurar que todo el conocimiento disponible
haya sido tratado (observación reflexiva).
C) Piensen críticamente acerca de cómo trabaja el equipo y presenten nuevas
teorías, conciban planes o modelos y sitúen eventos abstractos en explicaciones
concretas y sencillas (conceptualización abstracta).
D) Tomen decisiones, realicen acciones y experimenten con diversos enfoques y
estrategias para resolver problemas (experimentación activa).
2.2.3 Reflexión y la práctica reflexiva
Raelin [Raelin, J., 2002] define la reflexión como la actividad de dar periódicamente
un paso atrás (“stepping-back”) para ponderar el significado personal de lo que
recientemente ha ocurrido.
Para Boud, Cohen y Walker [Boud, D. et al., 1985] la reflexión es una actividad
humana importante en la cual las personas recapturan sus experiencias, piensan, meditan y
realizan sus evaluaciones acerca de ellas.
Cooper, Majchrzak y Faraj [Cooper, L. et al., 2005] consideran que el aprendizaje es el
resultado de combinar acción y reflexión puesto que las acciones asociadas a la realización
del trabajo en los proyectos proporcionan experiencias que establecen el escenario para el
aprendizaje, pero que, para cerrar el ciclo de aprendizaje se requiere pensar y reflexionar
acerca de esas experiencias.
Clifford y Thorpe [Clifford, J. et al., 2007], por su parte, consideran que la reflexión es
una parte esencial en el proceso de aprendizaje y que la práctica reflexiva es el método
por medio del cual el reflexionar se vuelve una actividad consiente y estructurada. Para
estos autores, la reflexión debería insertarse en toda actividad, proyecto o elemento de
trabajo a los efectos de maximizar el aprendizaje a partir de las actividades diarias.
37
La denominada perspectiva del profesional (“practitioner”) reflexivo fue introducida por
Schön [Schön, D., 1987] para referir al hecho según el cual los profesionales (arquitectos y
músicos, entre otros) repiensan y examinan su trabajo durante y después de haber
acometido un proceso creativo. Según este autor, pueden distinguirse dos tipos de reflexión,
a las que denomina reflexión en la acción y reflexión sobre la acción. La reflexión en la acción se realiza a medida que los eventos se desarrollan, mientras que la reflexión sobre la acción es un pensar en retrospectiva acerca de una experiencia, luego de haber
realizado la actividad o durante una pausa o interrupción.
En el ámbito particular de la IS, Hazzan y Tomayko [Hazzan, O. et al., 2005]
consideran que el tipo de trabajo que usualmente realizan los ingenieros de software son
adecuados para aplicar esta perspectiva de la práctica reflexiva.
2.2.4 Aprendizaje organizacional
El concepto de aprendizaje también ha sido aplicado al ámbito más amplio de las
organizaciones para definir el concepto de “organización que aprende”.
Argyris [Argyris, C., 1977] define el aprendizaje organizacional como un proceso de
detección y corrección de errores. Para Probst y Büchel [Probst, G. et al., 1997] se trata de
la habilidad de una institución como un todo de descubrir errores y corregirlos, y de cambiar
los valores y la base de conocimientos de la organización de modo tal de generar nuevas
habilidades para la resolución de problemas y nuevas capacidades para la acción.
Fiol y Lyles [Fiol, C. et al., 1985] consideran el aprendizaje organizacional como el
proceso de mejorar las acciones por medio de un mejor conocimiento y entendimiento. Por
su parte, para DiBella y Nevis [DiBella, A. et al., 1998] es la capacidad o proceso dentro de
una organización para mantener o mejorar su desempeño basándose en la experiencia.
Para Huysman [Huysman, M., 2002], el aprendizaje organizacional es el proceso por
medio del cual las organizaciones aprenden, ya sea de su propia experiencia o de la de
otros.
Gore [Gore, E., 20023] prefiere la expresión aprendizaje colectivo y lo define como el
proceso amplio, planificado o no, de generación de conocimientos que lleva a la adquisición
de nuevos desempeños compartidos y disponibles para ser puestos en acción. Para este
autor, el aprendizaje colectivo refiere a la construcción y transmisión de capacidades
colectivas y define las capacidades colectivas como los desempeños que los individuos
pueden lograr actuando colectivamente en el contexto organizacional.
Para Kim [Kim, D., 1993], el aprendizaje puede ser definido como el incremento de la
propia capacidad para emprender una acción eficaz. El aprendizaje se produce cuando se
38
sabe algo nuevo y se sabe cómo trasladarlo a la acción. Lo mismo es cierto para el
aprendizaje organizativo.
Sánchez y Heene [Sánchez, R., et al., 1997] consideran que el aprendizaje organizacional está relacionado con las formas en que las empresas construyen, aumentan
y organizan el conocimiento y las rutinas alrededor de sus actividades y dentro de sus
culturas.
Para Swieriga y Wierdsma [Swieriga, J., et al., 1994] consideran que el término
aprendizaje organizacional refiere a un cambio en el comportamiento de la organización.
Sostienen que una organización sólo puede aprender porque sus miembros lo hacen; es
decir, que si no hay aprendizaje individual, no puede haber aprendizaje organizacional. Sin
embargo, una organización no aprende de manera automática cuando sus miembros
aprenden algo. El aprendizaje individual es una condición necesaria, pero no suficiente, para
el aprendizaje organizacional. Para estos autores una organización aprende no solo cuando
alguien hace mejor el trabajo sino cuando, como resultado de esto, otros miembros actúan
de manera diferente.
Argyris y Schön [Argyris, C. et al, 1978], [Argyris, C., 1991] distinguen, en relación con
el aprendizaje organizacional, entre lo que denominan aprendizaje de bucle simple y
aprendizaje de bucle doble. El aprendizaje de bucle simple ocurre cuando los miembros
de una organización responden a cambios en los entornos interno y externo de la misma
mediante la detección y corrección de errores, pero sin cuestionar las causas o las razones
por las cuales esos errores han tenido lugar. El nivel de aprendizaje de bucle doble refiere
a aquellos tipos de autocrítica organizativa que resuelven incompatibilidades en las normas
mediante la asignación de nuevas prioridades y ponderaciones a las mismas, o mediante la
reestructuración de esas normas junto con las estrategias y asunciones asociadas. Estos
autores consideran, además, un tercer nivel de aprendizaje, al que denominan “aprender a
aprender” y que consiste en la capacidad de una organización para cuestionar su propia
capacidad de aprendizaje en los dos niveles anteriores. Una organización que “aprende a
aprender” es capaz de aumentar en forma continua su capacidad de aprendizaje.
Para del Moral y colegas [del Moral, A. et al., 2007], dos formas de aprendizaje pueden
distinguirse en una organización:
1. Aprendizaje analítico o de arriba abajo: también conocido como aprendizaje
estratégico. Se centra en la adquisición de conocimientos en un área concreta que
se ha identificado como prometedora en algún nivel de gestión de la organización.
2. Aprendizaje sintético o de abajo arriba: también conocido como aprendizaje
operativo. Se refiere al proceso en el cual un miembro de la organización, bien sea
del nivel de gestión o de trabajo, aprende algo que puede ser útil, siendo
distribuida es “lección aprendida” a lo largo y ancho de la organización.
39
Sandoe y colegas, citados por Jennex y Olfman [Jennex, M. et al., 2003], entienden
que el ciclo de Kolb [Kolb, D., 1984], analizado en 2.3.2, es también aplicable a nivel
organizacional. Según esos autores, durante el trabajo, las personas ganan experiencia,
observan y reflexionan para dar sentido a lo que están haciendo. Al tiempo que analizan
estas experiencias en abstracciones generales, cambian sus percepciones acerca de cómo
debería hacerse ese trabajo. A medida que estas personas influencian a sus colegas de
trabajo (co-workers), la organización aprende y gradualmente se cambia el proceso. En
suma, sostienen Jennex y Olfman [Jennex, M. et al., 2003], el aprendizaje organizacional es el proceso por el cual una organización asimila las experiencias de sus miembros y utiliza
esa experiencia para modificar las acciones potenciales de la organización.
Swieriga y Wierdsma [Swieriga, J., et al., 1994] han rediseñado el ciclo de aprendizaje
experiencial de Kolb [Kolb, D., 1984] como un ciclo de hacer – reflexionar – pensar – decidir
– (re)hacer. Con esta visión, el aprendizaje orientado a la resolución de problemas es,
entonces, cíclico. Sostienen que en el aprendizaje organizacional, pensar y hacer no están
separados, sino ligados mediante reflexionar y decidir. En un sentido análogo, Choudrie y
Salamat [Choudrie, J. et al., 2006] entienden que el aprendizaje organizacional ocurre en
la intersección de conocimientos tácitos y explícitos durante la interacción de varios
miembros de staff, equipos o departamentos en una organización.
2.2.5 La Organización que aprende
Para Confessore [Confessore, S., 1997], una organización que aprende constituye
un ambiente en el cual el aprendizaje organizacional está estructurado de modo tal que el
trabajo en equipo, la colaboración, la creatividad y los procesos de conocimiento tienen un
significado colectivo y son valorados. Senge [Senge, P., 1990] define a una organización que aprende como aquella que está continuamente expandiendo sus capacidades para
crear su futuro. Garvin [Garvin, D. 1993] define una organización que aprende como una
organización que es hábil en la creación, adquisición y transferencia de conocimientos, y en
la modificación de su comportamiento para reflejar nuevos conocimientos y comprensiones
(insights).
Para King [King, W., 2001] una organización que aprende es una organización que
crea, adquiere y comunica información y conocimiento, se comporta en forma diferentes a
causa de eso y, al hacerlo, produce mejores resultados organizacionales. Para este autor,
además, la organización que aprende es una meta a ser perseguida más que un estado de
situación a alcanzar.
40
Para Pedler, Burgoyone y Boydell [Pedler, M. et al., 1996] una organización que aprende es aquella que facilita el aprendizaje de todos sus miembros y continuamente se
transforma a sí misma.
Para Swieriga y Wierdsma [Swieriga, J., et al., 1994], los procesos de aprendizaje en
una organización que aprende se orientan a la resolución de problemas y entienden que
dichos procesos se inician y controlan a partir de problemas ya existentes o previstos. Para
estos autores ([Swieriga, J., et al., 1994]), además, los problemas determinan no sólo qué
debe aprenderse y cómo debe hacerse ese aprendizaje, sino también quiénes deben
participar en el proceso de aprendizaje; esto es, las personas que, debido a su competencia
o incumbencia, estén relacionadas con el problema o su solución.
Harrison [Harrison, W., 2004], por su parte, considera que una organización que aprende está incrementando continuamente su capacidad para producir resultados. Para
este autor, una organización que aprende debe dominar un proceso en tres pasos. Primero,
la organización aprende algo; segundo, gestiona este conocimiento; tercero, el
comportamiento organizacional se modifica en virtud de ese nuevo conocimiento. Para este
autor, estos tres pasos constituyen lo que denomina cadena aprendizaje-distribución-
cambio.
King [King, W., 2001] describe seis estrategias por las cuales puede optar una
organización que pretenda convertirse en una organización que aprende. Estas
estrategias son las de:
A) Sistemas de información: apunta a la recolección de datos y a su incorporación a
bases de datos diseñadas para hacer esa información más rápidamente accesible
a los usuarios, en forma de reportes consolidados o repuestas a consultas.
B) Gestión de la propiedad intelectual: consiste en maximizar el uso de activos
intelectuales que la organización tenga en la forma de patentes, marcas
comerciales, fórmulas de productos, reportes de investigación y elementos
similares, con el objetivo de crear valor adicional a partir de ellos.
C) Aprendizaje individual: enfatiza la capacitación y la educación de los empleados,
y se enfoca en el acrecentamiento del valor del capital humano de la organización.
Este enfoque busca maximizar las oportunidades de aprendizaje, tanto formal
como informal, por medio de programas de capacitación, entrenamiento en el
trabajo (“on-the-job”) y el establecimiento de programas de mentoring.
D) Aprendizaje organizacional: la base conceptual para esta estrategia es la de que
el capital social, en la forma de las variadas competencias y capacidades
organizacionales pueden ser desarrolladas, refinadas y mejoradas para permitir a
la organización adaptarse a circunstancias y demandas cambiantes.
41
E) Gestión del conocimiento: se enfoca en la adquisición, explicación y
comunicación de la pericia (“expertise”) profesional (que es de naturaleza
principalmente tácita) de los miembros de la organización. Esta pericia profesional
puede ser apuntalada mediante la explicación y la compartición, lo cual puede
facilitarse por medio del desarrollo y la operación de programas y actividades de
GC.
F) Innovación: es un proceso proactivo que puede ser llevado adelante por una
organización que tenga el propósito de generar, evaluar, desarrollar e implementar
productos, procesos y técnicas nuevas, así como soluciones novedosas a los
problemas.
King [King, W., 2001] presenta estas estrategias no como excluyentes una de las otras
sino como un escalonamiento temporal en el cual cada estrategia se sustenta en la anterior.
Asimismo, considera que para la implementación de cada estrategia superior no debe
esperarse a haber establecido completamente la anterior, sino cuando ésta haya alcanzado
el grado de madurez adecuado a las necesidades y características de la organización.
2.3 Conocimiento y aprendizaje en Ingeniería de Software
Rus y Lindvall [Rus, I. et al., 2002] sostienen que el conocimiento en IS es diverso y
sus proporciones inmensas y crece de manera constante. Destacan, además, que las
organizaciones tienen problemas en identificar el contenido, la ubicación y la utilización del
conocimiento.
Mathiassen y Pourkomeylian [Mathiassen, L. et al., 2003] por su parte, consideran que
la IS es una actividad altamente intensiva en conocimientos y las organizaciones de
software necesitan constantemente adoptar nuevas tecnologías y mejorar sus prácticas.
Birk, Surmann y Althoff [Birk, A. et al., 1999] sostienen que la IS involucra una
multiplicidad de actividades intensivas en conocimiento y, a modo de ejemplo, indican, entre
otras, la educción de requisitos de usuarios para un nuevo sistema software, la identificación
de mejores prácticas para el desarrollo de software, la recolección de experiencia sobre
planificación de proyectos y la gestión del riesgo.
Para Wei, Hu y Chen [Wei, C. et al., 2002], dificultades tales como requisitos definidos
pobremente, la frecuentes rotación del personal y la volatilidad de las plataformas de
hardware y de software desafían en forma constante a los proyectos de IS. Consideran
estos autores que tales desafíos requieren de un enfoque basado en casos para un
aprendizaje organizacional de lecciones importantes derivadas de experiencias previas.
Agregan, finalmente, que una organización de IS puede mejorar la planificación,
42
implementación y control de sus proyectos si acompasa un proceso de GC y un aprendizaje
efectivo de prácticas previas
Para Desouza, Awazu y Baloh [Desouza, K. et al., 2006], el conocimiento debe ser
gestionado en todos los escenarios del desarrollo de software, desde el encapsulamiento de
requisitos de diseño, pasando por la creación y prueba de programas, hasta la instalación y
el mantenimiento del software, e incluso extenderlo hasta la mejora de las prácticas y
procesos organizacionales de desarrollo de software.
Similar opinión tienen Falbo, Mota y Rosa [Falbo, R. et al., 2004a] al afirmar que la GC
puede ser usada para apoyar de mejor manera diversas actividades, tales como la definición
del proceso software, asignación de recursos humanos, estimación, análisis de requisitos y
planificación de la calidad, entre otras.
Por su parte, Aurum [Aurum, A., 2003] afirma que los procesos de desarrollo de
software se apoyan fuertemente en el conocimiento y la creatividad tanto de los individuos
como de los equipos de desarrollo de software, y sostiene que el principio básico en IS es
que la calidad general del software puede mejorarse cuando el conocimiento se hace
disponible y se lo utiliza de manera competente. Para este autor, la necesidad de fomentar
el desarrollo de las prácticas de IS en las organizaciones es un agregado a la demanda de
gestionar sistemáticamente el conocimiento y las destrezas en todas las etapas del ciclo de
vida del software. Concluye que desarrollar maneras efectivas de gestionar el conocimiento
relativo al software es de interés para los desarrolladores.
Para Ramasubramanian y Jagadeesan [Ramasubramanian, S., et al., 2003] la GC es
más importante para un proyecto de software en particular que para la organización en su
conjunto. Sostienen que los beneficios de gestionar y compartir conocimientos en un equipo
de proyecto incluyen las habilidades para reaccionar de manera más fácil a los requisitos de
los clientes, mejorar la productividad por medio de menores defectos y retrabajo, y mejorar
el trabajo en equipo.
Para Desouza, Dingsoyr y Awazu [Desouza, K. et al., 2005], el aprendizaje en y
alrededor de los proyectos software no es una opción, sino una obligación (“a must”) para la
sobrevivencia organizacional. Agregan que la reutilización de conocimiento es apropiada en
IS, pero que el conocimiento anterior debe reutilizarse para mejorar las operaciones futuras
y no para repetir errores cometidos en el pasado.
Handzic [Handzic, M., 2003] sostiene que identificar, localizar y capturar lo que es
conocido por los individuos y grupos de desarrolladores de software es de importancia
crítica para la sobrevivencia en el negocio del software.
43
2.4 La organización software que aprende
El concepto de “organización que aprende” analizado anteriormente ha sido aplicado
por Ruhe y Bomarius [Ruhe, G. et al., 2000] para definir una organización software que aprende como aquella organización que aprende en el dominio del desarrollo, la evolución y
la aplicación del software. Objetos de aprendizaje son todo tipo de modelos, conocimientos y
lecciones aprendidas relativos a los diferentes procesos, productos, herramientas, técnicas y
métodos aplicados durante las diferentes etapas del proceso de desarrollo software.
En el contexto de una organización software que aprende, los enfoques de GC y el
aprendizaje son vistas complementarias del proceso de manejo del conocimiento. Para los
autores precitados, el concepto de organización software que aprende extiende el
enfoque de la Experience Factory [Basili, V. et al., 1994] para acelerar los procesos de
aprendizaje apoyados por la organización que aprende, para extender el alcance de la GC a
todos los procesos, productos, métodos, técnicas, herramientas y comportamientos que,
directa o indirectamente, son relevantes en el contexto del desarrollo de software y para
extender el enfoque de GC para manejar el conocimiento tácito disponible en la
organización.
Para Henninger [Henninger, S., 2002] el enfoque de aprendizaje organizacional
aplicado al desarrollo de software tiene por intensión capturar información relativa a
proyectos durante la creación de los productos software y está diseñado para diseminar
conocimiento a medida que es creado en la organización, de modo que las personas
puedan comenzar a construir una cultura basada en el éxito, evitar la duplicación de
esfuerzos y también evitar la repetición de errores.
Con una visión más operacional, el propio Henninger [Henninger, S., 2001], detalla
que la organización software que aprende define un ciclo de uso de los recursos de
desarrollo de software para crear nuevos productos, lo cual conduce a la creación de nuevos
conocimientos que, a su vez, se convierten en nuevos recursos para el desarrollo de
software, normalmente luego de una fase de análisis que sintetiza y empaqueta
experiencias. Este autor considera a la organización software que aprende como
extremadamente importante en el desarrollo de software debido a los productos altamente
variables que requieren de un ajuste y mejora continuos de los procesos.
Harrison [Harrison, W., 2004] afirma que, en el caso particular de las organizaciones
de desarrollo de software, si bien son muchas las que pugnan por convertirse en
organizaciones que aprenden, son verdaderamente muy pocas las que tienen éxito.
44
2.5 Fábricas y bases de experiencia
El diccionario de la Real Academia Española [RAE, 2001] define experiencia como la
práctica prolongada que proporciona conocimiento o habilidad para hacer algo.
Kamel, Chandra y Sorenson [Kamel, A. et al., 2001] consideran la experiencia como
conocimientos o destrezas prácticas abstraídas u observadas directamente por la
participación en una actividad particular.
Schneider y colegas [Schneider, K. et al., 2002] entienden que, a diferencia del
conocimiento fáctico, no puede encontrarse experiencia en los libros de texto. Las
experiencias están relacionadas con el entorno y el contexto en el cual ocurrieron, y que
cuando se las reutiliza en su contexto original, pueden guiar las actividades de mejora en el
proceso software.
Para Althoff y colegas [Althoff, K. et al., 2001], la gestión de la experiencia define y
desarrolla métodos para estructurar y tratar con la experiencia de expertos en un campo
particular, y se está convirtiendo en un dominio cada vez más importante de la GC.
2.5.1 Fábrica de experiencia
El enfoque denominado Experience Factory, propuesto por Basili, Caldeira y Rombach
[Basili, V. et al., 1994] y cuya organización se presenta esquemáticamente en la figura 2.6,
apunta esencialmente a la captura, análisis y empaquetado de experiencias de todo tipo
adquiridas durante el desarrollo de proyectos software con el objetivo de reutilizar esa
experiencia en nuevos proyectos de desarrollo de software.
La “fábrica de experiencia” es una infraestructura física y/o lógica que apoya los
proyectos de desarrollo analizando y sintetizando experiencias de todo tipo, actuando como
repositorio de esa experiencia y proporcionando, a demanda, esa experiencia a otros
proyectos de desarrollo
Este enfoque divide los esfuerzos de desarrollo de software en dos unidades con
responsabilidades separadas de desarrollar proyectos de software y capturar experiencias.
La unidad de Experience Factory es responsable de desarrollar, actualizar y proveer
experiencias reutilizables a los equipos de desarrollo de software. Los artefactos de
experiencia pueden ser generados a demanda de alguna unidad de desarrollo de software
(la denominada Organización Proyecto) o por un análisis independiente de información
obtenida de proyectos existentes.
45
Figura 2.6: Fábrica de experiencia (Basili et al.)
La implementación física de una fábrica de experiencia es un Sistema de
Administración de Experiencia, compuesto de contenido, estructura, procedimientos y
herramientas [Basili, V. et al., 2001]. El contenido (que pueden ser datos, información,
conocimientos o experiencias) y la estructura (que es la forma en que está organizado el
contenido) constituyen lo que se denomina Base de Experiencia. Los procedimientos son
instrucciones acerca de cómo manejar la base de experiencias, y las herramientas soportan
la gestión del contenido y la ejecución de los procedimientos.
Una base de experiencia efectiva contiene un conjunto accesible e integrado de
modelos analizados, sintetizados y empaquetados de experiencia que capturan experiencias
anteriores.
Para Basili, Lindvall y Costa [Basili, V. et al., 2001], los valores centrales de una fábrica
de experiencia son que, a los efectos de mejorar, los empleados necesitan aprender de
experiencias pasadas y, para que los empleados aprendan, la organización necesita crear
un ambiente de aprendizaje.
Para Althoff y colegas [Althoff, K. et al., 2001], el enfoque de Experience Factory trata
de reconstruir de manera explícita el “aprender de la experiencia” de las personas para
apoyar aún más el aprendizaje organizacional.
Jedlitschka y colegas [Jedlitschka, A. et al., 2001] comentan que el enfoque de
Experience Factory incluye la recopilación, documentación, diseminación y almacenamiento
de experiencias (en la forma de “paquetes de experiencia”) en una base de experiencia, que
es la memoria organizacional para el conocimiento y la experiencia relevante de la
organización. De este modo se trata de hacer explícito el “aprender de la experiencia” a los
efectos de apoyar aún más el aprendizaje organizacional.
46
2.5.2 Bases de experiencia software
Ruhe y Bomarius [Ruhe, G. et al., 2000] detallan que el cuerpo de conocimiento en
una base de experiencia incluye típicamente distintos tipos de conocimientos (know-how,
know-why, know-what) y utiliza diferentes esquemas de representación, tales como modelos
explícitos, experiencias documentadas o lecciones aprendidas, así como conocimientos
tácitos y habilidades más o menos estructurados poseídos por las personas.
Para Henninger [Henninger, S., 2002] el objetivo de una base de experiencia no es
una cuestión de tratar de encontrar una aproximación universalmente aplicable al desarrollo
de software, sino el de comprender las circunstancias en las cuales una técnica, herramienta
o metodología dada es más apropiada en determinada ocasión.
Conradi, Lindvall y Seaman [Conradi, R. et al., 2000] destacan cuatro factores de éxito
para la implementación de una base de experiencia software: cambio cultural, estabilidad,
valor para el negocio, implementación incremental. En relación con el primer factor, estos
autores consideran que es importante que las personas provean conocimiento a la base de
experiencia y que también hagan uso del conocimiento que esté disponible en ella. El
segundo factor lo relacionan con la habilidad para gestionar los cambios de manera
controlada. Con respecto al tercer factor, consideran que es si la base de experiencia provee
un valor concreto y demostrable para el negocio, la misma se percibirá como un elemento
exitoso. Finalmente, en cuanto al último factor, la implementación y la introducción de una
base de experiencia serán exitosas si se realizan en pequeños incrementos y en estrecha
conexión con sus futuros usuarios recibiendo de estos una retroalimentación continua.
Bjornson y Stalhane [Bjornson, F. et al., 2005] refieren las bases de experiencia como
repositorios de experiencia. Para estos autores, un repositorio de experiencia que no es
usado por los desarrolladores no es de valor para la organización y mencionan los
siguientes factores que influencian el uso de tales repositorios:
A) debe contener una mínima cantidad de experiencia que pueda ser consultada. La
cantidad de experiencia disponible es crítica. Si hay poca experiencia disponible el
en repositorio, los desarrolladores no lo han de usar ni contribuirán al mismo con su
propia experiencia.
B) La experiencia que se encuentre debe ser considerada relevante para los
desarrolladores en su trabajo diario. Esta experiencia debe ayudarlos a hacer un
trabajo mejor y debe estar actualizada. Uno de los factores más desmotivantes que
pueden ocurrir cuando se usa un repositorio de experiencias es encontrar
experiencias con un título interesante pero con contenido desactualizado.
47
2.6 Mejora de las prácticas y procesos software
Para las organizaciones de desarrollo de software, aspectos tales como la mejora en
la calidad de los productos construidos, la reducción de costes, la finalización de los
proyectos en los plazos estimados y satisfacción de los clientes, entre otros, constituyen
siempre objetivos a alcanzar. Las iniciativas organizacionales tendientes al logro de estos
objetivos constituyen lo que en IS ha venido a denominarse “mejora del proceso software”.
La mejora del proceso software tiene por cometido analizar y definir cómo mejorar
las prácticas de desarrollo software de una organización, partiendo de una evaluación o
“assessment” del proceso en uso cuyo objetivo es poner de manifiesto el estado actual de
dicho proceso. La mejora del proceso software no es un evento de un solo paso, sino que se
desarrolla gradualmente mediante transiciones desde un nivel de madurez a otro.
Robillard [Robillard, P., 2005] define práctica como la manera generalmente aceptada
de hacer algo en un campo dado de la ingeniería, y define proceso como un conjunto
organizado de actividades, realizadas con un propósito específico.
Fuggetta [Fuggetta, A., 2000] define proceso software como un conjunto coherente
de políticas, estructuras organizacionales, tecnologías, procedimientos y artefactos que son
necesarios para concebir, desarrollar, instalar y mantener un producto software.
Mathiassen y Pourkomeyliam [Mathiassen, L. et al., 2003] definen la mejora del proceso software como un enfoque estructurado para mejorar las capacidades de una
organización software para proporcionar (“deliver”) servicios de calidad en forma
competitiva.
2.6.1 Modelos de mejora de procesos
Las iniciativas para la mejora de procesos de negocios en general, y de procesos
software en particular, suelen basarse en enfoques o modelos cíclicos tales como el
conocido PDCA (Plan-Do-Check-Act) de Shewhart (también conocido como ciclo de Deming
[Deming, E., 1986]) o el modelo IDEAL [McFeeley, B., 1996], y también, para el caso del
software en particular, en base a modelos de madurez tales como CMM o el más reciente
CMMI [SEI, 2006].
2.6.1.1 Plan-Do-Check-Act El modelo PDCA [Deming, E., 1986] es el más sencillo de los enfoques de mejora de
procesos y procede básicamente de la siguiente manera. En primer término, se planifica el
enfoque de mejora de procesos, identificando y analizando el problema que se pretende
resolver o la situación que se desea mejorar. A continuación se ejecuta el plan establecido,
48
por medio del desarrollo y la implementación de una solución. El tercer paso es evaluar los
resultados; es decir, verificar si los cambios y mejoras introducidos están funcionando como
se esperaba. Finalmente, si los resultados no son los esperados, se actúa para modificar los
procesos en base a las lecciones aprendidas, recomenzando así el ciclo.
2.6.1.2 Modelo IDEAL El modelo IDEAL [McFeeley, B., 1996] es también un modelo cíclico para la mejora de
procesos que, como lo indican Mutafelija y Stromberg [Mutafelija, B. et al., 2003], se basa en
la premisa de que mejorar es un proceso continuo que requiere de una implementación
incremental, revisiones periódicas de resultados, reimplementación de los pasos de mejora
basados en esos resultados y la ejecución de acciones correctivas.
El modelo IDEAL, que gráficamente se muestra en la figura 2.7, está constituido por
cinco fases: Initiating (“Iniciación”), Diagnosing (“Diagnóstico”), Establishing
(“Establecimiento”), Acting (“Actuación”) y Learning (“Aprendizaje”).
Figura 2.7: Modelo IDEAL (McFeeley)
La fase de Iniciación se establece la infraestructura inicial para apoyar y facilitar las
actividades de mejora del proceso, se definen los roles y responsabilidades y asignan los
recursos necesarios para apoyar la iniciativa.
En la fase de Diagnóstico se hace una valoración del estado actual de la organización
y se delinea un plan de acción para las actividades de mejora en concordancia con la visión
y los planes estratégicos de negocios.
Durante la fase de Establecimiento se priorizan los problemas que la organización ha
decidido enfocar y se definen metas medibles a ser incluidas en la versión final del plan de
acción.
En la fase de Actuación se crean, conducen y despliegan las soluciones para dar
tratamiento a las áreas a mejorar descubiertas en la fase de Diagnóstico.
49
La fase de Aprendizaje tiene por objetivo hacer más efectiva la siguiente iteración del
modelo. Se recopilan las métricas y las lecciones aprendidas, y estos artefactos se agregan
a la base de datos del proceso para servir como fuentes de información para el personal
involucrado en la siguiente pasada por el modelo.
2.6.1.3 CMMI El CMMI (Capability Maturity Model Integration) es un modelo de madurez de mejora
de procesos para el desarrollo de productos y servicios. Consiste de mejores prácticas que
abordan las actividades de desarrollo y mantenimiento que cubren el ciclo de vida de los
productos desde su concepción hasta su entrega y mantenimiento [SEI, 2006].
Según lo caracterizan Mutafelija y Stromberg [Mutafelija, B. et al., 2009], CMMI se
utiliza para planificar, definir, implementar, desplegar, comparar (“benchmark”) y mejorar
procesos en una organización.
La mas reciente versión de CMMI, la 1.2, introduce el concepto de constelación. Una
constelación es un agrupamiento de componentes del modelo que son únicos para un uso
específico pero que también contiene un conjunto central de áreas de proceso que no
cambian de una constelación a otra. Actualmente, el marco de trabajo de CMMI provee tres
constelaciones: CMMI para Desarrollo, CMMI para Servicios y CMMI para Adquisición.
CMMI para Desarrollo, en particular, consiste de mejores prácticas que abordan
actividades de desarrollo y mantenimiento aplicadas a productos y servicios. Aborda
prácticas que cubren el ciclo de vida de un producto, desde su concepción hasta su entrega
y mantenimiento. Los modelos en la constelación de CMMI para Desarrollo contienen
prácticas que cubren gestión de proyecto, gestión de proceso, ingeniería de sistemas,
ingeniería de hardware, ingeniería de software y otros procesos de apoyo usados en
desarrollo y mantenimiento.
Las mejores prácticas incluidas en CMMI están agrupadas en lo que se denominan
áreas de proceso. Según la definición dada por el SEI [SEI, 2006], un área de proceso es
un agrupamiento de mejores prácticas relacionadas entre sí que, cuando son
implementadas en forma colectiva, satisfacen un conjunto de metas consideradas
importantes para realizar una mejora significativa en esa área.
CMMI propone dos caminos de mejora, o representaciones, denominadas continua
(“continuous”) y por etapas (“staged”). Según las describen Mutafelija y Stromberg
[Mutafelija, B. et al., 2009], en la representación continua las áreas de proceso están
organizadas en categorías (Gestión de proceso, Gestión de proyecto, Ingeniería y Apoyo),
mientras que en la representación por etapas las áreas de proceso están organizadas en
niveles de madurez.
50
La representación continua permite a una organización la selección de una o más
áreas de proceso para su mejoramiento. El progreso en la mejora se mide en términos de
niveles de capacidad para cada área de proceso seleccionada, progresando desde un nivel
incompleto a uno optimizado a través de la satisfacción de un conjunto definido de prácticas.
La representación por etapas permite a una organización seleccionar un conjunto
predefinido de áreas de proceso y utiliza niveles de madurez para caracterizar la mejora de
procesos. Los procesos avanzan por cinco niveles de madurez, desde el inicial al
optimizado.
Las tablas 2.6 y 2.7 a continuación muestran, respectivamente, las áreas de proceso y
sus categorías y niveles de madurez asociados, y la comparación entre niveles de
capacidad y de madurez.
Area de proceso Gestión
de proceso
Gestión
de proy
ecto
Ingeniería
Apo
yo
Nivel de Mad
urez
Analisis de causas y resolucion x 5Gestión de la configuración x 2Análisis de decisiones y resolucion x 3Gestion integrada de proyectos x 3Medición y análisis x 2Innovación y despliegue organizacionales x 5Definición de procesos organizacionales x 3Enfoque organizacional en procesos x 3Rendimiento de procesos organizacionales x 4Formación organizacional x 3Integración de producto x 3Monitorización y control de proyecto x 2Planificación de proyecto x 2Aseguramiento de calidad de procesos y productos x 2Gestión cuantitativa de proyectos x 4Gestión de requisitos x 3Desarrollo de requisitos x 2Gestión de riesgos x 3Gestión de acuerdos con proveedores x 2Solucion técnica x 3Validación x 3Verificación x 3
Categoría
Tabla 2.6: Areas de proceso y sus categorías y niveles de madurez asociados
51
Nivel Niveles de Capacidad Niveles de Madurez0 Incompleto No aplicable1 Ejecutado Inicial2 Administrado Administrado3 Definido Definido4 Quantitativamente administrado Quantitativamente administrado5 Optimizado Optimizado
Tabla 1.7: Comparación entre niveles de capacidad y de madurez
La especificación de la versión más reciente de CMMI para Desarrollo se encuentra en
[SEI, 2006].
2.6.2 El conocimiento en la mejora del proceso software
Considerando la distinción entre conocimiento tácito y conocimiento explícito analizada
en 2.2.1, Mathiassen y Pourkomeylian [Mathiassen, L. et al., 2003] entienden que el
conocimiento tácito juega un rol primordial en la mejora del proceso software porque es
necesaria una apreciación profunda de las prácticas para evaluar las capacidades actuales,
para diseñar procesos nuevos útiles y para implementar estos procesos como parte de la
operativa. Para estos autores, la idea clave en la mejora de procesos software no es
meramente explicar el conocimiento. Para estos autores, las iniciativas para la mejora de
procesos descansan en la ambiciosa idea de crear y compartir conocimiento a nivel
organizacional, a través de diferentes individuos, proyectos y departamentos.
Para Rus y Lindvall [Rus, I. et al., 2002], las organizaciones que desean mejorar las
capacidades de IS de un equipo pueden conducir la tarea de asegurar que el conocimiento
ganado en un proyecto no se pierda. Incluidas en esta tarea están todas las formas de
lecciones aprendidas y de análisis post mortem que identifican que estuvo bien y qué estuvo
mal en relación tanto con el proceso como con el producto software.
Por su parte, Arent y Norbjerg [Arent, J. et al., 2000] consideran que mejorar las
prácticas software significa crear nuevo y “mejor” conocimiento acerca de esas prácticas e
institucionalizar ese conocimiento como “la manera en que el software es desarrollado por
aquí”.
Aurum y colegas [Aurum, A. et al., 2003] sostienen que mejorar los productos y los
procesos software son casos especiales de GC. En este mismo sentido, Xu [Xu, P., 2005]
considera que, siendo la gestión y la adaptación (“tailoring”) del proceso software una de las
principales prácticas en IS, la misma puede beneficiarse de la idea de la GC.
52
Falbo, Mota y Rosa [Falbo, R. et al., 2004a] sostiene que, en el contexto específico del
desarrollo de software, la GC puede verse como el fundamento para la mejora continua del
proceso software y, en consecuencia, de los productos resultantes.
Pourkomeylian [Pourkomeylian, P., 2000] considera que para cambiar sus prácticas de
desarrollo de software, una organización debería mejorar el conocimiento, tanto tácito como
explícito, que sus profesionales (“practitioners”) tienen sobre esas prácticas y, además, que
ese conocimiento nuevo o modificado debería transferirse a todos los niveles de la
organización para formar parte del trabajo diario de los mismos. Considera, entonces, que la
creación de procesos nuevos o modificados de esta manera es un proceso de creación de
conocimientos, en el cual diferentes actores a diferentes niveles organizacionales están
involucrados en la creación de diferentes tipos de conocimientos.
Respecto al modelo IDEAL [McFeeley, B., 1996], Mathiassen, Pries-Heje y
Ngwenyama [Mathiassen, L. et al., 2001] opinan que este modelo es una expresión de una
estrategia para la GC. Sostienen que la GC no está explicada como parte del modelo, pero
que está implícitamente integrada en las ideas y las prácticas de la mejora del proceso
software.
Para Komi-Sirvio, Mantyniemi y Seppanen [Komi-Sirvio, S. et al., 2002] un uso de la
GC es el de apoyar las actividades de mejora del proceso software. Consideran que este
apoyo es importante pues tanto las técnicas de IS y de gestión de la calidad fallan si las
mismas no están basadas en un conocimiento detallado de lo que es necesario y de lo que
se ha hecho en el pasado en una organización de desarrollo software. Similar opinión
expone Briand [Briand, L., 2002], quien considera que en una organización, la experiencia y
el conocimientos adquiridos en proyectos software pasados puede utilizarse para mejorar
las prácticas en proyectos futuros. Agrega que, por ejemplo, puede ser importante conocer
si una técnica de ingeniería de requisitos ha funcionado bien o no en proyectos pasados,
cuales fueron los beneficios y desafíos de su utilización, y que opinan los participantes del
proyecto sobre qué debería hacerse para mejorar la forma en que la misma es usada. Con
este ejemplo, Briand [Briand, L., 2002] quiere decir que preguntas de este tipo son
pertinentes pues en IS es difícil saber “a priori” si una técnica o método dada es adecuada al
problema a resolver o a las prácticas en uso.
Mathiassen y Pourkomeylian [Mathiassen, L. et al., 2003] proponen tres sugerencias
en relación a cómo una organización software puede utilizar la GC para guiar sus esfuerzos
de mejora del proceso software:
A) El enfoque de GC debería definirse en forma temprana en el proyecto de mejora
del proceso software.
B) La estrategia de GC para la mejora del proceso software debería incluir a la vez los
enfoques de codificación y de personalización [Hansen, M. et al., 1999].
53
C) La estrategia de GC para una iniciativa de mejora del proceso software debería
cambiar a medida que la organización software se hace más madura.
2.6.3 El aprendizaje en la mejora del proceso software
Borjesson y Mathiassen [Borjesson, A. et al., 2004] afirman que cambiar, de manera
exitosa, las prácticas de software requiere aprendizaje y que las iteraciones apoyan el
aprendizaje al permitir corregir errores y modificar los procesos en base a la experiencia
práctica.
Rus y Lindvall [Rus, I. et al., 2002], por su parte, consideran que el aprendizaje es una
parte fundamental de la GC pues los empleados deben internalizar (aprender) conocimiento
compartido antes de que puedan usarlo para realizar tareas específicas.
Arent y Norbjerg [Arent, J. et al., 2000] entienden que la perspectiva del aprendizaje
organizacional tiene mucho que ofrecer a la comunidad de mejora del proceso software,
especialmente en lo relativo a introducir e institucionalizar mejores prácticas de desarrollo
software en una organización
Para Ravichandran y Rai [Ravichandran, T. et al., 2000], los enfoques metodológicos
que subyacen a la gestión del proceso software permiten el refinamiento progresivo del
diseño del proceso basado en el aprendizaje continuo y la compartición de conocimientos.
Para estos autores, además, la gestión del proceso software debe estar basada en la
habilidad de aprender de otros proyectos de desarrollo software. En este sentido, sostienen
que una de las metas de la gestión del proceso software debería ser la de crear una
infraestructura que facilite la codificación, transferencia y reutilización de activos de
conocimiento entre proyectos.
Para Arent, Pedersen y Norbjerg [Arent, J. et al., 2001], aprendizaje en el ámbito de la
mejora del proceso software es crear y sustentar un proceso de aprendizaje que se expanda
a los niveles individual, grupal y organizacional. Sostienen que este proceso de aprendizaje
debería incluir tanto la creación de conocimiento tácito por medio de cambios en las
prácticas como de conocimiento explícito en la forma de procedimientos, guías,
herramientas y plantillas (“templates”). Para alcanzar esta meta, estos autores han
identificado dos estrategias, que denominan exploración y explotación, y que describen en
los siguientes términos:
A) Exploración: en esta estrategia los procesos de aprendizaje claves son compartir
conocimiento y “aprender haciendo”. Estos dos procesos se enfocan más en
cambiar las prácticas (creando conocimiento tácito) que en documentar esas
prácticas (crear conocimiento explícito). El compartir de manera efectiva ocurre
cuando alguien en un proyecto ejecuta una buena práctica y los otros miembros
54
del equipo aprenden esa buena práctica por medio de la observación y la
imitación. Un “aprender haciendo” efectivo ocurre cuando un concepto explícito
sobre una buena práctica se utiliza para explorar otras prácticas que pueden ser
mejores.
B) Explotación: en esta estrategia, los procesos de aprendizaje dominantes son la
reflexión y la integración. La meta es crear conocimiento explícito en la
organización, en la forma de nuevos procesos y guías estándares. Esta estrategia
es buena para iniciar la reflexión sobre prácticas existentes en la organización y
para seleccionar futuras prácticas para la misma. La fortaleza de esta estrategia
está, precisamente, en que habilita a crear ese nuevo conocimiento por medio de
la reflexión y la integración de prácticas existentes.
2.6.4 Factores claves para el éxito
Mathiassen, Nielsen y Pries-Heje [Mathiassen, L. et al., 2001] han identificado cinco
principios centrales (“core”) que representan valores que una organización debería adoptar
para tener éxito en un emprendimiento de mejora del proceso software:
A) Centrarse en los problemas: la resolución de problemas es la esencia de la
intensión de mejorar. La mejora del proceso software comienza con las prácticas
de desarrollo existentes en la organización. Estas prácticas se evalúan en cuanto a
sus fortalezas y debilidades, luego se identifican y priorizan posibles mejoras y se
establece un equipo para diseñar e implementar prácticas y procesos nuevos o
mejores.
B) Enfatizar la creación de conocimiento: en esencia, mejorar es crear
conocimientos. La mejora del proceso software es conducida por el conocimiento
acerca de las prácticas y las necesidades percibidas, las comprensiones
adquiridas durante el proceso de mejora, los estándares de la industria del
software y por el “estado del arte” relativo a metodologías y herramientas. Los
esfuerzos de mejora del proceso software también dependen del conocimiento
individual de las personas.
C) Fomentar la participación: la participación hace que el mejoramiento ocurra. Es
necesario involucrar a las personas en las actividades de diseño y desarrollo de los
nuevos procesos de modo que éstos estén basados en sus propias experiencias y
juicios profesionales. Cuando las personas que van a utilizar el nuevo proceso han
ayudado a crearlo, ese nuevo proceso tendrá mayores posibilidades de quedar
integrado a sus prácticas futuras.
55
D) Liderazgo integrado: para tener éxito, los esfuerzos de mejora del proceso
software deben ser consistentes con la estrategia y visión de futuro de la
organización. La principal preocupación aquí es la habilidad de la dirección de la
organización para utilizar el liderazgo para motivar y fijar la orientación de esos
esfuerzos. Sin un liderazgo fuerte, los esfuerzos de mejora tienden a divergir y el
compromiso común desaparece.
E) Planificar para la mejora continua: La mejora debería ser un esfuerzo
continuado puesto que a medida que se alivian unos problemas, otros se hacen
visibles. Las iniciativas de mejora son necesariamente continuas pues siempre hay
nuevos problemas y desafíos, y las soluciones a viejos problemas deben
mantenerse y desarrollarse más.
Dyba [Dyba, T., 2000], [Dyba, T., 2003], en otra investigación realizada para identificar
y medir factores de éxito de las iniciativas para la mejora del proceso software, ha
identificado que, entre otros, la participación de los empleados y la explotación del
conocimiento existente son considerados factores “facilitadores” para el éxito de una
iniciativa de este tipo en una organización. Para estos dos factores en particular, Dyba
[Dyba, T., 2000] propone una serie de indicadores que pautan los aspectos a tener en
cuenta en una iniciativa de mejora del proceso software:
A) Participación de los empleados a) Grado del participación en las decisiones acerca de qué es lo mejor que
debería hacerse a su propio nivel de actividad.
b) Grado de participación en la formalización de rutinas.
c) Grado en el cual contribuyen con propuestas de mejora.
d) Grado de responsabilidad en las actividades de mejora del proceso software
e) Grado de participación en el establecimiento de metas, análisis de datos e
interpretación. f) Grado de discusión y diálogo acerca del desarrollo software. g) Grado de discusión y diálogo acerca de las actividades de mejora del
proceso software.
B) Explotación del conocimiento existente a) Grado en el cual el conocimiento existente es explotado.
b) Grado de aprendizaje a partir de experiencias anteriores.
c) Grado en el cual las rutinas formales están basadas en la experiencia
pasada.
d) Grado de transferencia interna de experiencia.
56
En este mismo estudio, Dyba [Dyba, T., 2000] propone los siguientes otros cuatro
factores facilitadores: orientación al negocio, implicación del liderazgo, preocupación por las
mediciones y exploración de nuevo conocimiento (aprendizaje por la experimentación).
Por otra parte, Ravichandran y Rai [Ravichandran, T. et al., 2000] consideran que,
desde el punto de vista del aprendizaje organizacional, la gestión del proceso software
debería incluir los siguientes cuatro aspectos críticos.
Primero, un proceso de desarrollo eficaz debe diseñarse de modo que refleje el
“estado del arte” en las herramientas, técnicas, métodos y procedimientos para el desarrollo
de sistemas.
Segundo, deben establecerse mecanismos para promover el aprendizaje por medio de
compartir y reutilizar los conocimientos de tipos declarativo y procedimental (en la definición
de éstos dada por Schunk [Schunk, D., 1997]).
Tercero, deben implementarse mecanismos para aprender por medio de un análisis
sistemático de los problemas de calidad de los sistemas y la identificación de sus causas.
Este análisis provee un conocimiento valioso sobre el proceso que puede utilizarse para
refinar el proceso de desarrollo y para evolucionar estándares y resultados.
Cuarto, estos estándares evolucionados de desempeño deberían utilizarse para
controlar el proceso de desarrollo, de modo de asegurar que los resultados se alcancen de
manera eficiente.
2.7 Conocimiento y aprendizaje para la mejora del proceso
Los modelos para la mejora de procesos PDCA e IDEAL analizados anteriormente,
más allá de los detalles específicos de cada uno, se basan en el concepto de “mejora
continua” y proceden de manera cíclica e iterativa en una serie de pasos que pueden
resumirse como sigue:
1. Analizar y evaluar las prácticas y procesos tal cual se utilizan en el presente y se
identifican aquellos aspectos que requieran una mejora.
2. Diseñar nueva prácticas y procesos a partir de los existentes, incorporando las
mejoras requeridas, identificadas en el paso anterior.
3. Institucionalizar la adopción de las nuevas prácticas y procesos.
4. Aplicar las nuevas prácticas y procesos.
A partir del paso 4, el ciclo se repite volviendo al paso 1 en una nueva iteración que
tiene el propósito de realizar una nueva mejora a las prácticas y procesos en uso.
57
Este modelo simplificado para la mejora de procesos puede interpretarse desde las
perspectivas de los modelos de creación de conocimiento de Nonaka y Takeuchi [Nonaka, I.
et al., 1999] y de aprendizaje experiencial de Kolb [Kolb, D., 1984].
2.7.1 La perspectiva de creación de conocimiento
Elaborando a partir del trabajo de Arent y Norbjerg [Arent, J. et al., 2000], se puede
reinterpretar el ciclo genérico de mejora de las prácticas y procesos software anterior en
base al modelo de creación de conocimiento de Nonaka y Takeuchi [Nonaka, I. et al., 1999]
en los términos siguientes y cuya representación gráfica se muestra en la figura 2.8:
1. El paso de Socialización ocurre durante la aplicación práctica del proceso
software cuando los integrantes de un equipo de trabajo aplican el proceso en un
proyecto de desarrollo.
2. En el paso de Externalización los integrantes del equipo de trabajo, que han
estado aplicando el proceso software, explicitan los conocimientos tácitos
adquiridos durante la aplicación del mismo. Esta externalización debería conducir a
la generación de sugerencias y de propuestas de mejora a las prácticas y procesos
aplicados.
3. En el paso de Combinación, las propuestas de mejora derivadas del paso
anterior, una vez analizadas y definidas, se incorporan al proceso software en uso
para generar un nuevo proceso.
4. El paso de Internalización da inicio en el aprendizaje y la familiarización con el
nuevo proceso.
Puesto de este modo, desde esta perspectiva se pueden distinguir dos grupos de
actividades:
• Grupo I: actividades que tienen que ver con la creación de conocimiento explícito
acerca de las prácticas y procesos en uso.
• Grupo II: actividades que tienen que ver con la adquisición y formación de
conocimiento tácito.
58
Socialización
Internalización
Externalización
Combinación
Grupo II Grupo I
Figura 2.8: Perspectiva de creación de conocimientos
2.7.2 La perspectiva del aprendizaje experiencial
El ciclo genérico de mejora de las prácticas y procesos software descrito en 4.1
también puede analizarse, en los siguientes términos, desde la perspectiva del modelo de
aprendizaje experiencial de Kolb [Kolb, D., 1984], y cuya representación gráfica se muestra
en la figura 2.9:
1. La Experiencia Concreta se da en la instancia de aplicación del proceso software
en un proyecto de desarrollo.
2. La Observación Reflexiva que debe seguir al paso anterior debe consistir en el
análisis y la reflexión acerca de esa experiencia previa de aplicación del proceso.
3. La Conceptualización Abstracta subsiguiente debe dar lugar a la creación de
conceptos e ideas que conduzcan a la generación de propuestas y sugerencias
acerca de cómo mejorar las prácticas y el proceso software aplicadas.
4. Finalmente, la Experimentación Activa consistirá en la puesta a prueba de las
nuevas prácticas y procesos, con las mejoras introducidas como consecuencia del
paso anterior.
Puesto de este modo, desde esta perspectiva también es posible distinguir dos grupos
de actividades:
• Grupo I: actividades que tienen que ver con el análisis y la reflexión acerca de las
prácticas y procesos en uso.
• Grupo II: actividades que tienen que ver con la puesta a prueba de las
conclusiones de ese análisis y reflexión.
59
Figura 2.9: Perspectiva de aprendizaje experiencial
2.7.3 La perspectiva integrada
Las dos perspectivas anteriores pueden integrarse en una única que combina los
aspectos de creación de conocimientos y de aprendizaje por medio de la experiencia. En
efecto, ambas perspectivas presentan un paralelismo interesante en cuanto a que, en
ambas, pueden distinguirse dos grupos de actividades:
• Grupo I: actividades de adquisición de conocimientos y de aplicación práctica de
esos conocimientos en situaciones reales conducentes, a su vez, a la generación de
nuevos conocimientos, de aprendizajes y de experiencia.
• Grupo II: actividades de reflexión, análisis y síntesis de esos nuevos conocimientos,
aprendizajes y experiencias.
La tabla 2.8 muestra estos dos grupos de actividades en relación con las fases del
modelo genérico de mejora y los respectivos pasos de los modelos de creación de
conocimientos y de aprendizaje experiencial.
Paso del ciclo simplificado de
mejora
Grupo de actividades
Paso del modelo de Nonaka y Takeuchi
Paso del modelo de Kolb
4 Grupo II Socialización Experiencia Concreta
1 Grupo I Externalización Observación Reflexiva
2 Grupo I Combinación Conceptualización Abstracta
3 Grupo II Internalización Experimentación Activa
Tabla 2.8: Perspectiva integrada
60
Desde la perspectiva de creación de conocimientos, las actividades del Grupo I
tienen que ver con la creación de conocimiento explícito acerca de las prácticas y procesos
en uso, mientras que las actividades del Grupo II tienen que ver con la adquisición y
formación de conocimiento tácito.
Desde la perspectiva del aprendizaje experiencial, las actividades del Grupo I
constituyen la instancia de análisis y de reflexión acerca de las prácticas y procesos en uso,
mientras que las actividades del Grupo II tienen que ver con la puesta a prueba de las
conclusiones de ese análisis y reflexión.
2.8 Valoración de conocimientos, experiencia y aprendizaje
Cuando se deben considerar los conocimientos y la experiencia que una persona tiene
en una determinada área, se hace necesario poder expresar de algún modo su nivel de
conocimientos. De modo similar, cuando una actividad ha de ser realizada, es necesario
identificar y describir el nivel de conocimientos requerido para realizar esa actividad de
manera adecuada.
2.8.1 Valoración del conocimiento y la experiencia
Para McConnell [McConnell, S., 2003], la capacidad (en el sentido de “ser capaz de
hacer algo”) es una combinación de experiencia y conocimientos. Afirma que no se puede
verdaderamente poseer conocimientos de vanguardia (“leading-edge”) en una disciplina de
la ingeniería a menos que el conocimiento esté fundado en la experiencia y, a la inversa,
una experiencia de vanguardia no es posible a menos que la misma esté completamente
basada en el conocimiento más actualizado.
Por su parte, Wiig [Wiig, K., 1993] sostiene que una categorización de los niveles de
conocimientos relativa a un área de conocimientos es una herramienta importante que
puede utilizarse para diversos fines, tales como:
A) Expresar cuán capaz es una persona en una determinada área o tipo de actividad.
B) Especificar la habilidad y la capacidad requerida para realizar un trabajo de
calidad.
C) Identificar las brechas de conocimientos en una determinada función de negocio.
El propio Wiig [Wiig, K., 1993] propone una categorización en siete niveles para la
descripción de la capacidad o habilidad (“proficiency”), que se explicitan en la tabla 2.9:
61
Nivel Explicación Ignorant Sin conocimientos ni entendimiento de la disciplina
Beginner Vagamente consiente de la disciplina; sin experiencia real
Advanced beginner Consiente e informado, pero relativamente incompetente en amplias áreas
Competent performer Comienza a tener un entendimiento más profundo
Proficient performer Competente y ampliamente habilidoso; entendido en áreas específicas
Expert Altamente competente en un área particular
Master Altamente experto en diversas áreas y ampliamente entendido
Grand Master Experto de “clase mundial” en todas las áreas de un dominio de conocimientos
Tabla 2.9: Niveles de capacidad personal (Wiig)
Asimismo, Wiig [Wiig, K., 1993] menciona, sin entrar en sus detalles, otras posibles
categorizaciones, tales como las de Dreyfus y Dreyfus (Novice, Advanced Beginner,
Competente, Proficiency y Expertise) y la de Lange (Innocence, Awareness, Understanding,
Competente y Excellence).
Mayo [Mayo, A., 2001], por su parte, propone una escala de cinco niveles para juzgar
la amplitud y la profundidad de los conocimientos y habilidades de una persona en un
determinado dominio de conocimientos, que se muestran en la tabla 2.10.
Nivel Descripción Aware Puede hablar el lenguaje de la disciplina Basic Tiene un conocimiento rudimentario de la disciplina Competent Es capaz de discutir y de trabajar en forma competente
Distinguished Es alguien a quien sus colegas de trabajo se dirigen en busca de consejos
Expert Es conocido en y más allá de la organización por su pericia Tabla 2.10: Escala de conocimientos y habilidades (Mayo)
2.8.2 Valoración del aprendizaje
En el ámbito de la enseñanza y el aprendizaje también han sido desarrolladas diversas
clasificaciones o taxonomías para categorizar los niveles de aprendizaje a lograr o logrados
por los aprendices.
Una categorización muy difundida en este ámbito, que se muestra en la tabla 2.11, es
la denominada taxonomía de objetivos de aprendizaje de Bloom [Bloom, B. et al., 1979].
La misma consta de seis niveles que representan diferentes operaciones cognitivas de
complejidad creciente, desde el simple recuerdo de hechos o eventos hasta la síntesis y
62
evaluación de información. Cada nivel de la taxonomía tiene asociados una serie de verbos
que denotan las operaciones cognitivas correspondientes.
Nivel Descripción Verbos asociados Conocimiento Habilidad para recordar material
previamente aprendido Conocer, recordar, repetir, definir, listar, describir, identificar, nombrar
Comprensión Habilidad para captar el significado de un material, traducir de una forma a otra, explicar dando ejemplos, estimar tendencias futuras
Clasificar, convertir, explicar, ilustrar, generalizar, ejemplificar, resumir, parafrasear, discutir, relatar, traducir
Aplicación Habilidad para usar un material aprendido en situaciones nuevas o concretas aplicando reglas, métodos, conceptos, principios, leyes y teorías
Articular, calcular, construir, determinar, extender, resolver, mostrar, predecir, desarrollar, usar, aplicar, proporcionar, descubrir
Análisis Habilidad para descomponer un material en sus partes constituyentes de modo de entender su estructura y organización. Identificación de partes y de relaciones entre partes
Descomponer, inferir, diferenciar, diagramar, distinguir, reconocer, separar, comparar, contrastar, inspeccionar, examinar, relacionar, discriminar
Síntesis Habilidad para reunir partes para formar un todo nuevo, creatividad para formular algo nuevo
Adaptar, combinar, compilar, generar, integrar, modelar, planear, organizar, ensamblar, formular, diseñar, crear, individualizar, categorizar, componer, proponer
Evaluación Habilidad para juzgar el valor de un material basado en criterios definidos
Concluir, criticar, decidir, defender, juzgar, justificar, evaluar, priorizar, valorar, apoyar
Tabla 2.11: Taxonomía de objetivos educacionales (Bloom)
En época más reciente, Anderson y colegas [Anderson, L. et al., 2001] realizaron una
revisión de la mencionada taxonomía de Bloom. En contraste con la dimensión única de la
taxonomía original, la taxonomía revisada tiene dos dimensiones: proceso cognitivo y
conocimiento.
La dimensión del Proceso Cognitivo tiene, tal como se muestra en la tabla 2.12, seis
categorías: Recordar, Entender, Aplicar, Analizar, Evaluar y Crear. Cada categoría implica
un proceso cognitivo mas complejo que el anterior.
63
Proceso Descripción Recordar Refiere a recuperar conocimiento relevante de la memoria de
largo plazo. Este proceso cognitivo es el usado cuando el objetivo de aprendizaje es provocar la retención del material presentado.
Entender Se dice que alguien “entiende” cuando es capaz de construir significado a partir de mensajes que recibe, incluyendo comunicación oral, escrita o gráfica, presentada en conferencias, libros y otros medios de comunicación. Las personas “entienden” cuando construyen conexiones entre el “nuevo” conocimiento adquirido y sus conocimientos previos.
Aplicar Implica utilizar procedimientos para realizar ejercicios o resolver problemas. Aplicar está íntimamente ligado al conocimiento procedimental.
Analizar Implica descomponer un material en sus partes constitutivas y determinar cómo esas partes están relacionadas unas con otras, y con la estructura general. Los objetivos clasificados como Analizar incluyen aprender a determinar las piezas relevantes o importantes de un mensaje (diferenciar), las maneras en las que las piezas de un mensaje están organizadas (organizar) y el propósito subyacente del mensaje (atribuir).
Evaluar Implica hacer juicios en base a criterios y estándares. Los criterios usados más habitualmente son calidad, efectividad, eficiencia y consistencia. Los estándares pueden ser cualitativos o cuantitativos.
Crear Implica reunir elementos para formar un todo coherente o funcional. Si bien Entender, Aplicar y Analizar pueden involucrar detectar relaciones entre elementos, Crear es diferente porque involucra además la construcción de un producto original.
Tabla 2.6: Dimensión del proceso cognitivo (Anderson et al.)
Por su parte, la dimensión del Conocimiento tiene, según se muestra en la tabla 2.13,
cuatro categorías: Factual, Conceptual, Procedimental y Metacognitivo. En este caso, cada
categoría implica un nivel de abstracción mayor que la anterior.
64
Conocimiento Descripción Factual Abarca los elementos básicos que los expertos utilizan en la
comunicación sobre sus disciplinas académicas, entenderla y organizarla sistemáticamente. Estos elementos usualmente son utilizados por las personas que trabajan en la disciplina, en la forma tal cual presentados.
Conceptual Incluye conocimiento de categorías y clasificaciones, y de las relaciones entre y dentro de ellas, así como de esquemas, modelos y teorías que representan el conocimiento que tiene una persona acerca de cómo está organizada y estructurada una disciplina o área de conocimientos.
Procedimental Es conocimiento acerca de “cómo hacer algo”. Este conocimiento toma con frecuencia la forma de series o secuencias de pasos a ser seguidos, e incluye conocimiento de destrezas, algoritmos, técnicas y métodos, denominados colectivamente como “procedimientos”. También incluye conocimiento acerca de criterios usados para determinar cuando utilizar un determinado procedimiento.
Metacognitivo Refiere a las habilidades que hacen que los aprendices sean conscientes de de sus propios conocimientos y de sus habilidades personales para entender, controlar y manipular sus propios procesos cognitivos.
Tabla 2.7: Dimensión de conocimientos (Anderson et al.)
En el ámbito de la educación, estas taxonomías pueden utilizarse para diversos fines.
Anderson y colegas [Anderson, L. et al., 2001] reconocen cuatro aspectos de uso:
A) Como establecer objetivos de aprendizaje.
B) Como planificar y llevar a cabo un proceso de instrucción.
C) Cómo seleccionar o diseñar instrumentos de evaluación.
D) Cómo asegurar la consistencia de los tres aspectos anteriores.
Por su parte, Dalkir [Dalkir, K., 2005] considera que la taxonomía de Bloom, referida
anteriormente, también proporciona una buena base para evaluar la aplicación de
conocimientos. Según este autor, para los niveles inferiores de la taxonomía (conocimiento,
comprensión), el simple estar al tanto (“being aware”) de la existencia de cierto conocimiento
en la organización es fácilmente observable cuando un trabajador es capaz de localizar ese
conocimiento en un repositorio, mientras que la aplicación de ese conocimiento requiere que
el trabajador haya alcanzado niveles superiores de comprensión tales como análisis,
síntesis y evaluación puesto que sólo a estos niveles puede decirse que el conocimiento es
aplicado.
65
2.8.3 Valoraciones en el ámbito de la Ingeniería de Software
Cuando se pretende describir la capacidad o habilidad (“proficiency”) en dominios de
conocimientos amplios, Wiig [Wiig, K., 1993] recomienda dividir el dominio de conocimientos
en áreas más pequeñas, de modo de proporcionar una categorización de los conocimientos
del dominio más clara y específica. En el ámbito de la IS en particular, una división tal se
encuentra en la Guide to the Software Engineering Body of Knowledge (SWEBOK) [Abran,
A. et al., 2004]. En esta guía, el conjunto de conocimientos relativos a IS está organizado en
diez áreas de conocimientos: Requisitos, Diseño, Construcción, Prueba, Mantenimiento,
Gestión de la Configuración, Gestión de Ingeniería, Procesos, Calidad y Herramientas y
Métodos. El conocimiento relativo a cada una de estas áreas, a su vez, está organizado en
una jerarquía de sub-áreas, proporcionando así un mayor nivel de detalle. Por ejemplo, el
área de conocimientos Requisitos Software está estructurada en siete sub-áreas:
Fundamentos, Proceso, Educción, Análisis, Especificación, Validación, y una última
categoría de Consideraciones Prácticas.
El SWEBOK hace uso de la taxonomía de Bloom [Bloom, B. et al., 1979] para que la
propia guía pueda utilizarse como herramienta para, entre otros fines, describir puestos de
trabajo, describir roles en la definición de un proceso software, establecer planes de carrera
y planificar programas de entrenamiento. La propuesta del SWEBOK está enfocada
específicamente al perfil de un graduado en IS con cuatro años de experiencia.
Otros autores han incursionado también en la utilización de la taxonomía de Bloom en
el ámbito de la IS. En este sentido, Bourque y colegas [Bourque, P. et al., 2003] han
propuesto la aplicación de esta taxonomía para describir tres perfiles de ingenieros de
software: un recientemente graduado, un graduado con cuatro años de experiencia y un
miembro experimentado de un grupo de proceso de IS.
Azuma, Collier y Garbajosa [Azuma, M. et al., 2004], por su parte, han propuesto un
esquema, también basado en la taxonomía de Bloom, estructurado en dos dimensiones
denominadas Categorización de áreas de conocimientos y Niveles de capacidad
operacional. La dimensión Categorización de áreas de conocimiento está estructurada en
seis categorías: Conceptos, Marcos de trabajo y modelos de referencia, Principios y teoría,
Métodos y técnicas, Medición y evaluación, Aplicación y casos, y Herramientas. La
dimensión de Niveles de capacidad operacional, es la que está basada en la taxonomía
de Bloom, cuyos niveles se han expandido para incorporar lo que estos autores denominan
la “perspectiva operacional”. Esta expansión incorpora, para los cuatro niveles superiores de
la taxonomía de Bloom, los denominados Niveles de Capacidad que se utilizan en la
empresa Construx. En esta empresa, McConnell [McConnell, S., 2003] reporta el desarrollo
de una Escala de Desarrollo Profesional (Professional Development Ladder) para
66
categorizar los niveles de conocimientos y experiencia de sus ingenieros de software. Esta
categorización está conformada por dos dimensiones, denominadas Áreas de
Conocimientos y Niveles de Capacidad (“capability”). La dimensión de Áreas de Conocimiento está basada en las diez áreas de conocimiento contenidas en la Guide to the
Software Engineering Body of Knowledge [Abran, A. et al., 2004]. Por su parte, la dimensión
de Niveles de Capacidad está definida en cuatro niveles, según la descripción que se
muestra en la tabla 2.14:
Nivel Descripción
Introductory El empleado realiza el trabajo básico en un área, generalmente bajo supervisión. El empleado está dando pasos efectivos para desarrollar sus conocimientos y habilidades.
Competency El empleado realiza un trabajo efectivo e independiente en un área, sirve como modelo de rol para empleados menos expertos y ocasionalmente entrena a otros.
Leadership
El empleado realiza un trabajo ejemplar en un área, entrena a otros empleados de manera regular y proporciona liderazgo a nivel de proyectos. El empleado es reconocido como un recurso importante en el área de conocimientos.
Mastery
El empleado realiza un trabajo de referencia en un área y posee conocimientos profundos en múltiples proyectos, proporciona liderazgo a nivel de la industria y es reconocido fuera de la organización por su pericia en el área.
Tabla 2.8: Niveles de capacidad (McConnell)
Es en base a estas dos dimensiones que en Construx se ha desarrollado la referida
Escala de Desarrollo Profesional. Esta escala está organizada en siete niveles y para una
persona, pasar de un nivel al siguiente, se requiere que la misma adquiera tanto más
amplitud (más áreas de conocimientos) como mayor profundidad (mayor capacidad) en sus
conocimientos y experiencia [McConnell, S., 2003].
2.9 Trabajos relacionados
En esta sección se presentan y describen los principales trabajos y propuestas
relacionados con la GC y la experiencia en el ámbito particular de la IS.
Los trabajos presentados están organizados en las siguientes categorías:
1. Fábricas de experiencia.
2. Métodos y técnicas para captura de experiencias.
3. Herramientas software y entornos de trabajo.
67
4. Wikis y wikis semánticas.
5. Mejora del proceso software y CMMI
2.9.1 Fábricas de experiencia
Los trabajos presentados en este apartado están relacionados, en mayor o menor
medida, con el enfoque de Experience Factory [Basili, V. et al., 1994] y con la utilización de
bases o repositorios de experiencias como elementos centrales en la GC.
2.9.1.1 Software Experience Center Schneider, von Hunnius y Basili [Schneider, K. et al., 2002] reportan la implementación
de un proyecto en DaimlerChrysler denominado Software Experience Center (SEC), basado
en el concepto de la Experience Factory [Basili, V. et al., 1994]. El objetivo operacional del
SEC fue proveer a las unidades de negocio de los conceptos de una organización que
aprende y un prototipo de una base de experiencia. El SEC apoyaba todas las actividades,
desde la educción de experiencias hasta hacer disponible esas experiencias para la tarea de
software entre manos. Los autores mencionan que el Software Experience Center ha
mejorado muchos procesos en la organización y que el aprendizaje por medio de la
experiencia se ha convertido en una parte más natural de la vida diaria de las unidades de
negocio.
2.9.1.2 Experience Engine Johansson, Hall y Coquard [Johansson, C. et al., 1999] reportan de la implementación
en la empresa Ericsson Software Technology AB de una variante de la Experience Factory
[Basili, V. et al., 1994] denominada Experience Engine. Esta variante, a diferencia de la
Experience Factory, que se basa en experiencias almacenadas en bases de experiencia, se
sustenta en el conocimiento tácito.
Para hacer accesible el conocimiento tácito a un grupo mayor de personas, se han
definido dos roles nuevos en la organización. Se trata del comunicador de experiencia
(“experience communicator”) y del agente de experiencias (“experience broker”). El primero
corresponde a una persona que posee un conocimiento profundo acerca de uno o más
temas, mientras que el agente de experiencias tiene como misión conectar al comunicador
con la o las personas que tienen un problema. La función del comunicador no es resolver el
problema sino la de educar y asistir al poseedor del mismo acerca de cómo resolverlo.
2.9.1.3 Knowledge Dust to Pearls Basili y colegas [Basili, V. et al., 2002] han propuesto un enfoque que aborda algunos
de los problemas de la GC al proveer mecanismos que facilitan la iniciación rápida de una
base de experiencia. Este enfoque, denominado Knowledge Dust to Pearls combina los
68
beneficios del AnswerGarden y de la Experience Factory [Basili, V. et al., 1994]. El
AnswerGarden atiende las necesidades de corto plazo, utiliza una metodología ad-hoc y
permite la recolección de elementos unitarios (“fine-granular”) de conocimiento. La
Experience Factory, por su parte, atiende las necesidades de largo plazo y, tal como se
comentó al respecto anteriormente, está basada en una metodología de análisis y síntesis
más sofisticada, utiliza bucles de retroalimentación y reconoce la necesidad de que las
actividades de análisis y de síntesis estén en manos de una organización separada (el grupo
de Experience Factory).
En el enfoque Knowledge Dust to Pearls, la idea es capturar las partículas de
conocimiento (“knowledge dust”) que los empleados utilizan e intercambian diariamente en
sus actividades e, inmediatamente y con mínimas modificaciones, hacerlas disponibles a
través de toda la organización. En forma paralela, estas partículas de conocimiento son
analizadas, sintetizadas y transformadas en perlas de conocimiento (“knowledge pearls”)
que representan elementos de conocimiento más sofisticados, refinados y valiosos.
2.9.1.4 EPG/ER Scott, Carvalho y Jeffery [Scott, L. et al., 2002], Scott y Stalhane [Scott, L. et al., 2003],
así como Scott y Jeffery [Scott, L. et al., 2005], reportan la implementación de un repositorio
de experiencia (ER – Experience Repository) que opera también como una guía electrónica
de procesos (EPG – Electronic Process Guide), y hacen uso de la técnica del análisis post
mortem para poblar (“populate”) el repositorio. El propósito de la EPG es proveer a gerentes
y desarrolladores de herramientas y de información actualizada para el proceso de
desarrollo software. El repositorio de experiencias es una simple extensión de la EPG y su
contenido, que se enlaza con las tareas y objetos del modelo de proceso, está organizado
en cuatro categorías de experiencias: listas de comprobación, plantillas, ejemplos y
experiencias genéricas. Según los autores, la implementación web de la EPG/ER permite
que cualquier persona incorpore una experiencia en cualquiera de las categorías
predefinidas o agregar en forma no estructurada comentarios, observaciones, fragmentos de
código, enlaces a páginas web y anécdotas en la categoría genérica. Para capturar las
experiencias a incorporar se hace uso del análisis post mortem (con sus métodos habituales
como sesiones KJ y diagramas de Ishikawa) y también en base a entrevistas semi-
estructuradas.
2.9.1.5 Komi-Sirvio y colegas Komi-Sirvio, Mantyniemi y Seppanen [Komi-Sirvio, S. et al., 2002] han propuesto un
enfoque, ligeramente diferente al de la Experience Factory [Basili, V. et al., 1994], en el cual
el conocimiento a recolectar a partir de proyectos pasados está guiado por las necesidades
inmediatas y específicas de un proyecto en curso. Este enfoque consiste de un “proyecto de
69
captura de conocimientos” y “proyectos clientes”. El proyecto de captura de conocimientos
recolecta conocimientos a partir de fuentes relevantes, los “empaqueta” y los provee a un
proyecto cliente para su reutilización a demanda, de manera análoga a como funciona una
Experience Factory [Basili, V. et al., 1994]. Esta solución, mencionan los autores, no
modifica el entorno (“setting”) organizacional ni requiere de nuevas herramientas. El
conocimiento proviene de fuentes existentes tales como reportes finales de proyectos, bases
de datos de errores, foros de discusión y, mas importante aún, de las personas. El proceso
de captura de conocimientos utiliza como técnica principal la entrevista semi-estructurada.
2.9.1.6 Xie, Zhang y Xu Xie, Zhang y Xu [Xie, X. et al., 2005] han propuesto un modelo para la gestión de la
experiencia, parcialmente basado en el enfoque de Experience Factory, que soporta operar
como memoria corporativa para el desarrollo software y que permite capturar, compartir y
reutilizar experiencias de proyectos anteriores. Estos autores han presentado un meta-
modelo cuyos componentes pueden especializarse e instanciarse para producir modelos e
instancias de gestión de experiencia. Los tres componentes de este meta-modelo son:
“stakeholders”, “experiencias”, “fases de desarrollo” software.
Los “stakeholders” representan los principales roles en el ciclo de vida del desarrollo
software, tales como gerentes de proyecto, analistas, diseñadores y testers entre otros,
mientras que las “experiencias” se producen y documentan en diversos estados de las
“fases de desarrollo”. Los “stakeholders” gestionan las fases del desarrollo software y
capturan experiencias que se representan en “paquetes de experiencia”. Estos paquetes de
experiencia transitan por cuatro fases en su ciclo de vida: crear, almacenar, adquirir y
reutilizar. Este ciclo de vida es descripto de manera muy elemental por los autores en los
siguientes términos: en la fase de creación, la organización captura el conocimiento y lo
empaqueta en un paquete de experiencia que se almacena en la base de experiencia.
Cuando la organización necesita encontrar conocimiento relacionado, un individuo adquiere
un paquete de experiencia correcto por medio de una interface de consulta y entonces la
organización puede reutilizar y actualizar los datos de la experiencia en el formulario (“form”)
de paquetes de experiencia.
2.9.2 Métodos y técnicas para captura de experiencia
En este apartado se presentan técnicas y métodos para identificar, educir y capturar
conocimientos y experiencia a partir de proyectos software. En la literatura, estos métodos
se conocen como análisis retrospectivo y reciben también otras denominaciones, tales como
análisis post mortem, revisiones post-proyecto (“postproject review”), análisis retrospectivo,
70
retrospectivas de proyecto (“project retrospectives”) y revisiones después de la acción (“after
action review”), entre otras.
Dingsoyr [Dingsoyr, T., 2005] define el análisis retrospectivo como una actividad
colectiva de aprendizaje que pueden organizarse para proyectos cuando éstos hayan
finalizado una fase o hayan sido completados.
2.9.2.1 Análisis post mortem de proyectos Birk, Dingsoyr y Stalhane [Birk, A. et al., 2002] han propuesto la utilización de la
técnica del análisis post mortem de proyectos (APM) con el propósito de capturar
experiencias y sugerencias de mejora a partir de proyectos completados o cuando en el
proyecto se haya alcanzado un hito (“milestone”) significativo. Circunscriben la técnica a
proyectos de software y sostienen que en cada proyecto de este tipo, los miembros del
equipo ganan nuevo conocimiento y experiencia que pueden ser beneficiosos tanto para
futuros proyectos como para el propio desarrollo profesional de los miembros del equipo.
Según estos autores, la técnica asegura que los miembros de un equipo de proyecto
reconozcan y recuerden lo que han aprendido durante el proyecto.
La aplicación de esta técnica consiste de tres fases:
1) Preparación: en esta fase se recorre la historia del proyecto para obtener un mejor
entendimiento de lo que ha ocurrido y se revisan todos los documentos
disponibles, tales como planes del proyecto, la estructura de desglose de tareas
(“work breakdown structure”) y los reportes de revisión. En esta fase también se
determinan los objetivos específicos para el análisis a realizar.
2) Recolección de datos: esta fase está dedicada a obtener la experiencia relevante
del proyecto consistente no sólo de los problemas o aspectos negativos que
deberían haberse evitado sino también de los aspectos exitosos. Una vez
identificados los temas importantes, se debe priorizarlos antes de proceder al
análisis. El establecimiento de prioridades asegura que se traten en primera
instancia los aspectos de mayor significación.
3) Análisis: en esta fase un moderador conduce una sesión de retroalimentación
(“feedback”) para discutir e intercambiar ideas y puntos de vista sobre los temas
identificados en la fase anterior y finaliza con la elaboración de un informe con las
conclusiones a las que se llegó y las recomendaciones que correspondan.
Los autores afirman que si los equipos de proyecto aplican el análisis post mortem de
manera adecuada, el mismo constituye un excelente paso en la gestión continua del
conocimiento y en las actividades de mejoramiento [Birk, A. et al., 2002].
71
El uso del análisis post mortem de proyectos también es reportado por Scott y
Stalhane [Scott, L. et al., 2003] para capturar experiencias pasadas en conjunción con la
herramienta EPG/ER referida anteriormente.
2.9.2.2 Sesiones Legacy Cooper, Majchrzak y Faraj [Cooper, L. et al., 2005] han propuesto un enfoque
denominado de sesiones legacy que refiere a sesiones de trabajo donde los miembros de
un equipo de proyecto identifican innovaciones y mejoras que han realizado en sus
proyectos y que tienen un valor potencial para futuros usuarios. Para los autores, la
característica que diferencia este enfoque de otros similares tales como las after-action
reviews o las project lessons learned reviews es que se enfoca en las oportunidades de
reutilización en lugar de sobre el riesgo de repetir errores pasados. Según la descripción
dada por sus autores una sesión legacy consiste de cuatro partes.
La primera parte consiste de una sesión de tormenta de ideas (“brainstorming”) para
identificar potenciales legados (“legacies”). Estos legados representan aprendizajes que
tienen el potencial de ser reutilizados por los miembros del equipo de proyecto o por otros
miembros de la organización.
En la segunda parte, los participantes sintetizan los resultados de la parte anterior
combinando elementos similares, quitando elementos disímiles y categorizando los
resultados según sean procesos, productos, personas u otros. De la lista final se selecciona
luego un elemento para su posterior discusión.
El tercer paso es la discusión detallada del elemento seleccionado para, en el cuarto
paso, elaborar un sumario de la discusión, siguiendo una plantilla de estructura predefinida.
2.9.2.3 Revisiones post-proyecto Harrison [Harrison, W., 2002] comenta la realización de revisiones post-proyecto
(post-project reviews) como forma de proveer un mecanismo formal para transferir la
experiencia de un equipo de proyecto a una memoria corporativa una vez que se ha
completado un proyecto y mientras esas experiencias están aún frescas en las mentes de
los participantes. La experiencia capturada se vuelca a un repositorio de lecciones
aprendidas cuyo propósito es facilitar la organización, mantenimiento y diseminación del
conocimiento capturado. El repositorio está basado en tecnología web y dispone de una
interfase basada en formularios para que los suministradores de lecciones aprendidas
puedan agregar nuevas experiencias al mismo.
2.9.2.4 Reportes de experiencias y Revisiones post mortem Dingsoyr, Moe y Nytro [Dingsoyr, T., 2001] mencionan otros dos métodos para
capturar experiencias a partir de proyectos: los reportes de experiencias y las revisiones
72
post mortem. Un reporte de experiencia es un documento de estructura predefinida
redactado usualmente por el gerente de proyecto luego de que el mismo ha finalizado,
mientras que la revisión postmortem refiere a una reunión cuyo objetivo es recabar
información de los participantes, hacerlos discutir sobre la manera en que se llevó a cabo el
proyecto y finalmente analizar las causas de por qué las cosas funcionaron bien o no
durante el desarrollo del proyecto. Para las revisiones post mortem, los autores menciona la
utilización de técnicas tales como la denominada KJ para la realización de una tormenta de
ideas (“brainstorming”) y los diagramas de Ishikawa para analizar las causas de los aspectos
importantes identificados en la técnica anterior.
2.9.3 Herramientas software y entornos de trabajo
Los trabajos presentados en este apartado refieren a herramientas y entornos de
desarrollo software que incorporan funcionalidades de GC y de captura de experiencias.
2.9.3.1 Semantic Reuse System Antunes, Seco y Gomez [Antunes, B. et al., 2007] han propuesto un sistema basado
en tecnologías de la web semántica para la adquisición, gestión y reutilización de
conocimientos sobre desarrollo software. Este sistema, denominado Semantic Reuse
System (SRS) se basa en el uso de mecanismos tales como RDF (Resource Description
Framework), RDFS y OWL (Ontology Web Language), y apunta a proveer mecanismos
eficientes para capturar, almacenar, recuperar y administrar conocimientos. Según lo
describen sus autores, el SRS provee medios para capturar y almacenar diferentes
elementos que resultan de los procesos de desarrollo software, tales como documentos de
especificación, diagramas de diseño y código fuente, entre otros. Los autores mencionan
que el SRS provee también diversas formas de reutilizar y compartir conocimientos,
incluyendo una manera proactiva de sugerir conocimiento relevante al desarrollador
software en función del contexto de trabajo del usuario.
2.9.3.2 BORE BORE (Building an Organizacional Repository of Experiences) es una herramienta
prototipo diseñada para explorar y refinar los requisitos de herramientas que sustenten el
enfoque basado en la experiencia. Según describe Henninger [Henninger, S., 2003], esta
herramienta ha evolucionado desde ser inicialmente sólo una tecnología de repositorio hasta
el punto de utilizar un proceso software definido como principio organizador de la
información. Crea un marco de trabajo (“framework”) para una fábrica de experiencia
combinando una estructura de desglose de tareas (“work breakdown structure”) con
herramientas de repositorio para diseñar metodologías de proceso software, así como
73
mediante el empleo de tecnologías de repositorio para capturar y aplicar artefactos de
conocimiento. Agrega Henninger [Henninger, S., 2003] que la herramienta BORE y su
metodología extienden el concepto de fábrica de experiencia mediante adaptación de
procesos basada en reglas, apoyo para el modelado y la representación de procesos y
facilidades de aprendizaje organizacional basado en casos.
2.9.3.3 RAMALA Ramawi y colegas [Ramawi, Y. et al., 2005] reportan el desarrollo de una base de
conocimientos denominada RAMALA, apoyada por una herramienta software también
denominada RAMALA. Los principales alcances y metas del trabajo que dio lugar al
desarrollo de RAMALA fueron modelar y desarrollar una base de conocimientos para la
mejora del proceso software, apoyada por una herramienta software que posibilitara la
definición, la evaluación (“assessment”) y la mejora del proceso software de una
organización. La base de conocimientos contiene un marco de trabajo (“framework”) de
proceso software basado principalmente en el PMBOK [PMI, 2000], utiliza las mejores
prácticas de modelos de referencia de procesos software tales como CMMI [SEI, 2002] e
ISO 15504 [ISO, 1997], y enriquecida por activos de procesos de las más destacadas
metodologías de desarrollo software. Los autores comentan que las organizaciones software
pueden obtener varios beneficios de la utilización de RAMALA, entre los cuales destacan
que todos los conocimientos de los procesos de desarrollo software pueden ser recopilados,
clasificados y asociados con sus correspondientes elementos del proceso, y que la base de
datos histórica de activos de procesos puede reutilizarse en futuros proyectos además de
proveer buenos indicadores del grado de institucionalización del proceso software en la
organización.
2.9.3.4 ProKnowHow Falbo, Mota y Rosa [Falbo, R. et al., 2004a] presentan una herramienta basada en GC,
ProKnowHow, desarrollada para apoyar la definición del proceso software de un proyecto a
partir de un proceso software estándar y de mejoras basadas en la recolección de métricas
de proyectos anteriores. En relación con el proceso software, la herramienta fue
desarrollada para alcanzar las siguientes metas:
A) Apoyar la adaptación del proceso estándar a cada proyecto particular.
B) Recolectar y diseminar el conocimiento adquirido durante la adaptación del
proceso software.
C) Apoyar la actualización del proceso software estándar a partir de la
retroalimentación recibida de los proyectos.
74
Con respecto a las actividades de estimación y la recolección y uso de métricas, las
metas a alcanzar eran:
A) Apoyar la estimación de proyectos por medio de la recuperación de datos de
proyectos similares previos.
B) Derivar indicadores a partir de clases de proyectos realizados por la organización.
C) Permitir relacionar métricas software con las metas organizacionales.
El elemento central de esta herramienta es una memoria organizacional donde se
almacenan conocimientos formales (por ejemplo, los artefactos producidos durante el
desarrollo de software) e informales (lecciones aprendidas).
2.9.3.5 PAKME Babar y Gorton [Babar, M. et al., 2007], describen una herramienta web denominada
PAKME (Process-centric Architecture Knowledge Management Environment) orientada
específicamente a proveer apoyo para gestionar el conocimiento sobre el proceso de
arquitectura software. Según la describen sus autores, esta herramienta soporta las
estrategias de codificación y de personalización [Hansen, M. et al., 1999], y provee servicios
de adquisición, mantenimiento, recuperación y presentación para la GC. Para la educción y
codificación de conocimientos, la herramienta provee varias plantillas (“templates”) que
asisten a los usuarios en educir y estructurar el conocimiento antes de almacenarlo en el
repositorio. Los autores mencionan que actualmente la herramienta está siendo probada en
un proceso industrial de evaluación de arquitectura y esperan que la misma ayude a
sistematizar el proceso de evaluación gestionando el conocimiento requerido para tal
actividad.
2.9.3.6 PM-CAKE Martínez y colegas [Martínez, P. et al., 2005] ha propuesto un entorno de trabajo
denominado PM-CAKE, “Process Management Computer Aided Knowledge Environment”,
que es un marco de trabajo (“framework”) para la GC de proyectos y procesos en una
organización software y para ser utilizado por gerentes de proyectos, ingenieros de software,
grupos de gestión de procesos y gerentes de unidades de Tecnología de la Información.
Para sus autores, este entorno de trabajo permitirá transferir desde las personas hacia la
organización todo el know-how sobre ejecución de proyectos software y provee un
repositorio para gestionar las prácticas de gestión, las que se agrupan en procesos que
pueden luego utilizarse para introducir nuevas prácticas o para modificar las existentes.
Según lo describen los autores, PM-CAKE permite definir el proceso software a seguir en un
nuevo proyecto, seleccionar valores estimados para el ciclo de vida, los factores de
complejidad y características del equipo de desarrollo así como también indicar parámetros
75
estimados de tamaño del proyecto, esfuerzo, duración, costos y calidad. A partir de esta
información, un gerente de proyecto usa PM-CAKE para buscar en las experiencias previas
almacenadas en el repositorio la información necesaria para definir las actividades del
proyecto y su estructura de desglose de tareas (“work breakdown structure”). Una vez
finalizado el proyecto, el gerente ingresa al sistema la información del mismo referente, por
ejemplo a requisitos, diseño, pruebas de software y código fuentes, así como las estructuras
de desglose de tareas y de productos. Los autores mencionan que PM-CAKE y su
repositorio se utilizarán para la extracción de procesos software en forma automática a partir
de la experiencia de proyectos y también para la evaluación del desempeño organizacional.
2.9.3.7 El entorno TABA Santos y colegas [Santos, G. et al., 2005] reportan la implementación de un entorno de
desarrollo software denominado TABA que combina la utilización de herramientas CASE
con un enfoque basado en la GC para ayudar a los desarrolladores en la ejecución de sus
actividades de proyecto al proveerles de conocimientos cuando más los necesitan. Según
mencionan los autores, el enfoque de adquisición de conocimientos integrado en las
herramientas CASE habilita la evolución gradual del repositorio de conocimientos con la
adquisición y diseminación de lecciones aprendidas, mejores prácticas e ideas para mejorar
los procesos software. Los autores, sin embargo, no describen la manera en que se lleva a
cabo el proceso de adquisición de conocimientos ni las características del repositorio
mencionado.
Más recientemente, Montoni, Santos y Rocha [Montoni, M. et al., 2007] comentan que
en los últimos años el entorno de trabajo TABA ha evolucionado para apoyar las actividades
de GC integradas al proceso software con el propósito de preservan el conocimiento
organizacional y para fomentar la institucionalización de una organización software que
aprende.
2.9.3.8 Well of Experience Dingsoyr [Dingsoyr, T., 2002], Dingsoyr y Royrvik [Dingsoyr, T. et al., 2003a], así como
Dingsoyr y Conradi [Dingsoyr, T. et al., 2003b] describen una herramienta denominada Well
of Experience (WoX). Se trata de una pequeña herramienta para capturar esa clase de
conocimiento que normalmente se escribiría en pequeños trozos de papel adhesivo
(stickers), y dispone de un mecanismo para proporcionar retroalimentación (“feedback”) a la
persona que escribió la nota en la forma de comentarios. Ejemplos de este tipo de notas
son: “cómo configurar Smalltalk en una plataforma especial”, “como reducir el tamaño del
perfil de usuario en Windows NT”, y “una implementación del algoritmo “soundex” en Java”.
Cada nota contiene un asunto, un texto descriptivo, palabras claves (“keywords”) e
76
información sobre el autor de la misma. Los autores han encontrado cinco tipos de uso del
repositorio de conocimientos que se crea con esta herramienta:
1. Resolver un problema técnico específico.
2. Obtener una visión de conjunto de áreas problemáticas.
3. Evitar el retrabajo de tener que explicar una misma solución a varias personas.
4. Mejorar la situación individual de trabajo por medio del ajuste de herramientas
técnicas.
5. Encontrar quien tiene una competencia específica en la organización.
2.9.3.9 Competente blocks Esta herramienta, también mencionada por Dingsoyr [Dingsoyr, T., 2002] y por
Dingsoyr y Conradi [Dingsoyr, T. et al., 2003a], consiste de una lista de cursos internos en
la compañía. Para cada curso se proporciona una breve descripción, junto con información
de calendario y de quien es el responsable. Esta herramienta es también utilizada cuando
alguien quiere participar en un curso o preparar el dictado de uno.
2.9.3.10 Skills Manager Esta otra herramienta, también mencionada por Dingsoyr [Dingsoyr, T., 2002] y por
Dingsoyr y Conradi [Dingsoyr, T. et al., 2003a], es un sistema donde todos los empleados
pueden declarar el nivel de conocimientos que tienen en diferentes áreas que son de interés
para la compañía tales como, por ejemplo, tecnología de orientación a objetos o su habilidad
para programar en Visual Basic. Esta herramienta se usa para asignar personas a proyectos
(staffing) y para encontrar a alguien que pueda ayudar a otros a resolver un problema. Esta
herramienta también puede ser utilizada por las personas para establecer qué desean
aprender en el futuro y no sólo lo que saben hoy.
2.9.3.11 People Knowledge Map Ramasubramanian y Jagadeesan [Ramasubramanian, S., et al., 2003] reportan la
implementación de esta herramienta que es, en esencia, un directorio de expertos en
diferentes campos y mediante la cual los empleados pueden buscar y localizar expertos.
Mencionan los autores que la usabilidad de este directorio es enorme puesto que provee
múltiples nodos o tópicos y sirve como puente entre dos tipos de trabajadores del
conocimiento: el usuario y el proveedor (experto).
2.9.3.12 Process Asset Database Esta otra herramienta, también reportada por Ramasubramanian y Jagadeesan
[Ramasubramanian, S., et al., 2003] permite capturar entregables de proyectos tales como
planes de proyectos, documentos de diseño y planes de prueba. Los usuarios pueden
buscar estos documentos en base a diferentes criterios como son: tipo de proyecto,
77
tecnología involucrada, dominio o área de conocimientos y por nombre del cliente, entre
otros. Mencionan los autores que esta herramienta ayuda a proveer a los nuevos proyectos
de información relativa a proyectos similares ejecutados en el pasado, así como a establecer
metas cuantitativas para los mismos.
2.9.4 Wikis, wikis semánticos y ontologías
Según lo define Schaffert [Schaffert, S., 2006a], un wiki es esencialmente una
colección de sitios web conectados por vínculos de hipertexto. Por su parte, Schaffert,
Westenthaler y Gruber [Schaffert, S., 2006b] definen los wikis semánticos como la
combinación de wikis con tecnologías de la web semántica. Para Oren y colegas [Oren, E. et
al., 2006], los wikis se están transformando en herramientas populares de GC, tanto a nivel
personal como organizacional.
Para Decker y colegas [Decker, B. et al., 2005], los wikis pueden verse como una
plataforma liviana (“lightweight”) para intercambiar artefactos reutilizables dentro y entre
proyectos software, y entienden que también pueden ser considerados como formas de
memorias organizacionales o fábricas de experiencias.
Con respecto a las ontologías, Corcho, Fernández-López y Gómez-Pérez [Corcho, O.
et al., 2006] establecen que una ontología define los términos y relaciones básicas que
componen el vocabulario de un área tópica, así como las reglas para combinar términos y
relaciones para definir extensiones a ese vocabulario.
En este apartado, entonces, se presentan algunos trabajos recientes que se apoyan
en estos conceptos para proponer herramientas orientadas a facilitar la compartición de
conocimientos de IS en forma colaborativa.
2.9.4.1 Riki Rech, Bogner y Haas [Rech, J. et al., 2007] reportan el desarrollo de un wiki,
denominado Riki, que utiliza tecnologías de razonamiento basado en casos (“case-based
reasoning”) y ontologías para proveer un marco formal y consistente para describir
conocimientos y experiencias, y cuyo propósito es implementar un sistema de
documentación orientada a la reutilización de conocimientos sobre proyectos software.
Mencionan los autores que la ontología y las plantillas de documentos (“templates”)
enriquecen el contenido de Riki con semántica que permite a los usuarios aumentar el
conocimiento incorporado en Riki con información adicional y experiencias documentadas,
así como compartir experiencias y reutilizar conocimiento relativo a proyectos.
78
2.9.4.2 Wikitología Klein, Hoecht y Decker [Klein, B. et al., 2005] han propuesto un enfoque denominado
wikitología que aúna técnicamente wikis y ontologías, y cuyo propósito es que el
conocimiento sobre IS pueda ser constantemente mantenido y cultivado por los ingenieros
de software. Respecto a este enfoque, los autores mencionan que, a largo plazo, este
enfoque debería resultar en una calidad superior de los sistemas software debido a una
mejor disponibilidad de los conocimientos relativos a IS. Un uso de este enfoque de
wikitología es reportado por Decker y colegas [Decker, B. et al., 2005] con un ejemplo de su
aplicación para capturar conocimientos de IS en base a una serie de plantillas de
documentos que mejoran la documentación de uso habitual para describir y especificar
casos de uso en ingeniería de requisitos.
2.9.4.3 MASE Chau y Maurer [Chau, T. et al., 2005] describen la utilización de wikis en una
herramienta, denominada MASE, orientada a mejorar los mecanismos de compartición de
experiencias entre diferentes equipos de desarrollo software en una organización. En base
al uso de wikis, esta herramienta permite a los usuarios registrar información de manera
informal y no estructurada, así como también definir las tareas de un proyecto y almacenar
información sobre las mismas en base a formatos específicos (estructurados). La
herramienta, además, provee capacidades de búsqueda de texto en cualquiera de las
páginas wiki y apoya el trabajo colaborativo tanto en forma sincrónica como asincrónica.
2.9.5 Mejora del proceso software y CMMI
En este apartado se presentan trabajos y estudios relacionados con la GC en el
ámbito particular de la mejora de procesos software y el modelo CMMI.
2.9.5.1 Arent y Norbjerg Con el objetivo puesto en la mejora del proceso software, Arent y Norbjerg [Arent, J. et
al., 2000] utilizaron el modelo de creación de conocimiento de Nonaka y Takeuchi [Nonaka,
I. et al., 1999] como marco de referencia para analizar tres proyectos industriales de mejora
de proceso software. Según estos autores, este trabajo mostró de qué forma el nuevo
conocimiento se crea a través de la interacción entre conocimientos tácito y explícito y sus
casos de estudio mostraron que hay varias vías para iniciar la creación de conocimiento
organizacional y obtener algún éxito inicial. Otro de los hallazgos de este trabajo sugiere que
los grupos de proyectos constituyen un punto de comienzo factible para el proceso de
creación de conocimiento en las organizaciones de desarrollo de software. En este sentido,
consideran que el grupo de proyecto es la fuente primaria de conocimiento acerca de las
79
prácticas de desarrollo y un escenario natural para someter a prueba (“try out”) y aprender
acerca de nuevas prácticas. Este estudio relevó, por otra parte, que es difícil sustentar la
creación de conocimiento y expandirla más allá de los primeros pasos exitosos.
2.9.5.2 KM framework for CMMI Chongsringam y Prompoon [Chongsringam, P. et al., 2007] presentan un framework
de GC adoptado por organizaciones CMMI para apoyar la adaptación organizacional de
áreas de proceso y las prácticas de mejora de procesos basadas en la experiencia. Este
framework, basado en la aplicación del enfoque de Experience Factory [Basili, V. et al.,
1994] analizado anteriormente, propone tres niveles para su sistema de GC: definición de
procesos de GC, infraestructura de GC y un repositorio de conocimientos.
La definición de procesos de GC implica establecer las fases, las actividades y los
roles relativos a la GC. La infraestructura de GC involucra la identificación y el análisis de
activos de conocimiento (existentes y requeridos) y de los procesos de conocimiento
relacionados a ellos, y la subsecuente planificación y control de acciones para desarrollar
tanto los activos como los procesos a los efectos de satisfacer los objetivos
organizacionales. Es éste el nivel directamente basado en el enfoque de Experience
Factory. Existen una organización proyecto que usa conocimiento empaquetado para
desarrollar procesos y productos, y una factoría de conocimiento que apoya el desarrollo de
software proveyendo activos de conocimiento adaptados a los proyectos que se integran a
las actividades que ejecuta la organización proyecto. El repositorio de conocimientos está
organizado en una taxonomía para organizar el conocimiento organizacional para la mejora
de procesos software, específica para CMMI. La taxonomía clasifica estos conocimientos en
tres categorías: conocimiento de evaluación del proceso, activos de proceso y conocimiento
de mejora del proceso. El diseño del repositorio basado en esta taxonomía tiene el propósito
de almacenar el conocimiento de modo de facilitar su acceso, uso y modificación.
Este framework ha sido utilizado en la implementación del área de proceso de Gestión
de Acuerdos con Proveedores (Supplier agreement management) para el nivel 2 del CMMI y
los autores mencionan, sin dar mas detalles, que podría aplicarse a todas las áreas de
proceso en cualquier organización CMMI.
2.9.5.3 KM-CORE Montoni y colegas [Montoni, M. et al., 2008] han propuesto un enfoque de GC para
apoyar iniciativas de implementación de mejora de proceso software. La arquitectura de este
enfoque consta de tres grupos de componentes. El primer grupo tiene el objetivo de
administrar el conocimiento relativo a factores críticos de éxito que tiene influencia en la
implementación de iniciativas de mejora de procesos software y a las estrategias de mejora
de procesos software que guían las iniciativas de implementación de una organización de
80
consultoría en mejora de procesos. El segundo grupo de componentes trata de la aplicación
de técnicas de benchmarking en proyectos de implementación de mejora de procesos
software. El tercer grupo de componentes se enfoca en la gestión y evaluación de proyectos
de implementación de mejora de procesos software.
Para apoyar la aplicación de este enfoque, los autores mencionan que se han
desarrollado un conjunto de herramientas específicas para cada uno de los grupo de
componentes mencionados y que se las ha integrado en un ambiente denominado KM-
CORE (Customizable Organizational Environment with Knowledge Management).
Mencionan los autores que el enfoque descripto y sus herramientas están siendo
actualmente aplicados en una organización de consultoría en mejora de procesos software y
esperan concluir el estudio en abril de 2009.
2.9.5.4 KDM for SPI A partir de un extensivo estudio de la literatura sobre mejora de procesos software y al
análisis de las estrategias de mejora practicadas en organizaciones de desarrollo software,
Alagarsamy y colegas [Alagarsamy, K. et al., 2008] aspiran a derivar un nuevo modelo
dirigido por el conocimiento (KDM – knowledge driven model) para programas de mejora de
procesos software basados en el modelo IDEAL.
Siguiendo las fases de este modelo, los autores proponen una serie de actividades
para su modelo dirigido por el conocimiento. Para la fase de Iniciación, entender la
necesidad de mejorar, establecer el patrocinio y representar la infraestructura de mejora.
Para la fase de Diagnóstico, recolectar la literatura existente y adquirir conocimiento tácito.
Para la fase de Establecimiento, empaquetar conocimiento para las operaciones,
implementar técnicas de ingeniería del conocimiento y operar herramientas de GC para
soporte a las decisiones. Para la fase de Actuación, derivar el conocimiento requerido para
planificar y ejecutar la mejora del proceso software, y caracterizar los atributos para los
procesos individuales. Para la fase de Apalancamiento, poblar los repositorios y analizar
información, adquirir conocimiento explícito, derivar conocimiento híbrido mediante
combinación.
Reportan los autores que el modelo propuesto ha sido implementado en una
organización software trabajando el nivel 1 del modelo CMM.
2.9.5.5 SPI-KM Santos y colegas [Santos, G. et al., 2007a], [Santos, G. et al., 2007b] han propuesto
una estrategia, denominada SPI-KM, que consiste de un conjunto de fases definidas que se
enfocan en aspectos específicos relacionados al despliegue de iniciativas de mejora de
procesos software y que cuenta con apoyo de gestión del conocimiento. Esta estrategia está
estructurada en las siguientes fases: Diagnóstico, Planificación de SPI, Definición del
81
proceso, Entrenamiento, Mentoring, Adquisición de conocimientos, Adquisición y evaluación
de recomendaciones de mejora del proceso, Preparar a la organización para la evaluación,
Proceso de evaluación.
Las fases relacionadas específicamente con la GC son Entrenamiento, Mentoring,
Adquisición de conocimientos, Adquisición y evaluación de recomendaciones de mejora del
proceso.
En la fase de Entrenamiento se proporciona entrenamiento en ingeniería de software a
los miembros de la organización mediante un programa adaptado a las características y
necesidades de la organización, y a su iniciativa de mejora del proceso software. La fase de
Mentoring tiene lugar durante la ejecución de los proyectos e implica la transferencia directa
de conocimientos a los miembros de la organización. Consultores en ingeniería de software
están presentes mientras los desarrolladores software llevan a cabo por primera vez
cualquier actividad de proceso, explicándoles cómo ejecutar la actividad y lso beneficios
esperados. La fase de Adquisición de conocimientos implica adquirir conocimientos relativos
a las actividades del proceso software y a la iniciativa de mejora para permitir la
preservación y diseminación del conocimiento organizacional. Luego de recolectar el
conocimiento, éste es filtrado, empaquetado, almacenado en un repositorio de conocimiento
organizacional y puesto a disposición para guiar la ejecución del proceso y la revisión de los
planes de mejora. Finalmente, las actividades de adquisición de recomendaciones de
mejora del proceso ocurren en paralelo con la ejecución de los proyectos. Las ideas de
mejoras del proceso aparecen mientras que los desarrolladores obtienen una mejor
comprensión acerca del proceso. Estas sugerencias de mejora son recolectadas y
evaluadas por el grupo de procesos de la organización y, si son aprobadas, se incorporan al
proceso software estándar y pueden influir en la revisión futura de los planes de mejora de
procesos.
2.10 Problemas de los enfoques existentes
Diversas críticas y comentarios pueden encontrarse en la literatura acerca de los
enfoques y propuestas analizados en el apartado anterior.
2.10.1 Fábricas de experiencia
De los diversos trabajos y propuestas considerados en la sección anterior puede verse
que el enfoque más comprehensivo para la GC y de la experiencia en el ámbito de la IS lo
constituyen la Experience Factory y los que son derivaciones o adaptaciones del mismo y
que hacen uso de repositorios de experiencias.
82
Sin embargo, como apuntan Chau y Maurer [Chau, T. et al., 2005], el marco de trabajo
de la Experience Factory establece cuales son las actividades de GC que es necesario
realizar (educción, análisis, generalización, empaquetado y diseminación) pero presenta la
carencia de no prescribir cómo deben llevarse a cabo esas actividades, así como el estar
basados, la mayoría, en la estrategia de codificación de conocimientos.
Similar opinión tienen Zhu, Staples y Gorton [Zhu, L. et al., 2007], quienes consideran
que uno de los problemas en la investigación actual sobre repositorios de experiencia es
que la mayoría de la misma se enfoca sobre el aspecto tecnológico para la construcción de
repositorios en lugar de hacerlo respecto a cómo ocurre realmente la compartición de
experiencias.
Otra de las críticas que ha recibido este enfoque refiere a que el acceso a los
“paquetes de experiencia” que se proveen a través del repositorio de experiencias son
mantenidos por un grupo especial dedicado a la tarea de generalizar esas experiencias lo
más posible para su reutilización, lo cual implica que para alimentar o actualizar el contenido
de ese repositorio es necesario pasar por un proceso controlado y habitualmente lento
[Chau, T. et al., 2005],
2.10.2 Análisis post mortem y similares
En relación con los trabajos que refieren al análisis post mortem de proyectos o
similares (revisiones post-proyectos, reportes de experiencia y revisiones post mortem) para
educir y capturar experiencias, si bien los mismos parecen cumplir con esa finalidad tal
como lo indican los artículos referidos, presentan igualmente el inconveniente de ser
extemporáneos respecto del momento de ocurrencia de las experiencias que se pretenden
capturar. En este sentido, Basili, Lindvall y Costa [Basili, V. et al., 2001] sentencian que el
problema con los post mortem es que se realizan muy tarde en la vida de un proyecto, si es
que se llevan a cabo alguna vez.
Por su parte, Desouza, Dingsoyr y Awazu [Desouza, K. et al., 2005], califican como
una situación desafortunada el hecho de que la mayoría de los ingenieros de software no
tienen tiempo para “finalizar” un proyecto cuando ya están siendo reasignados a otros.
Cooper [Cooper, L., 2007] menciona precisamente el hecho de que los equipos de
proyecto son, por definición, entidades temporales y que una vez completado un proyecto
sus miembros retornan y se distribuyen en la organización llevándose con ellos sus
conocimientos individuales.
Bjornson [Bjornson, F., 2007], por su parte, considera que en las ajetreadas jornadas
laborales de un proyecto software, raramente hay tiempo para tales revisiones.
83
Zedtwitz, citado por Myllyaho y colegas [Myllyaho, M. et al., 2004], también menciona
las restricciones y la falta de tiempo como los principales motivos para saltarse por completo
el análisis post mortem al decir que algunas organizaciones tienen tantos proyectos
entrantes que los potenciales gerentes y miembros de los equipos de trabajo son
inmediatamente reasignados a nuevos proyectos apenas han finalizado los anteriores. El
propio Zedtwitz comenta que las personas no suelen estar dispuestas dedicar tiempo y
esfuerzo a problemas de ayer dado que en forma natural tienden a favorecer el avanzar al
siguiente problema en lugar de desperdiciar tiempo valioso en revisar un proyecto
recientemente completado [Myllyaho, M. et al., 2004].
En cuanto al enfoque de sesiones legacy mencionado anteriormente, los propios
autores reconocen que en el estudio exploratorio reportado en el artículo referido, de los
nueve equipos de proyecto contactados para llevar a cabo estas sesiones, si bien todos
estuvieron interesados en participar, sólo cuatro estuvieron finalmente disponibles para
hacerlo [Cooper, L. et al., 2005].
2.10.3 Herramientas software y entornos de trabajo
Con respecto a las herramientas y entornos de trabajo puede decirse que, en general,
los mismos se orientan a apoyar actividades particulares dentro de la IS, tales como la
arquitectura software, la gestión de los proyectos, la instanciación de procesos software y la
estimación y recolección de métricas.
2.10.4 Wikis y wikis semánticas
En relación con el grupo particular de herramientas basadas en tecnología wiki, las
mismas apuntan más que nada a apoyar el trabajo colaborativo de gestión documental para
facilitar la reutilización de los conocimientos plasmados en esos documentos.
2.10.5 Mejora del proceso software y CMMI
Para Capote y colegas [Capote, J. et al., 2008], la mayoría de los modelos de mejora
de procesos, tales como el modelo IDEAL, no cuentan aún con un mecanismo que permita
realizar la gestión del conocimiento y que facilite la captura y utilización de todas aquellas
experiencias valiosas durante la ejecución de cada uno de los ciclos de mejora, o dejan esta
decisión en manos de los ejecutores del programa. Para estos autores, los programas de
mejora de procesos software mantienen una base de conocimientos en la cual se
almacenan todas las lecciones aprendidas y experiencias adquiridas, tanto positivas como
negativas, durante cada ciclo de mejora. El problema en sí es que este conocimiento no es
84
gestionado de manera que les facilite a los desarrolladores el acceso al conocimiento
adecuado en el momento adecuado, además de que no se especifica cómo se debe realizar
esta base de conocimientos, qué roles deben ser involucrados en su creación y gestión y, lo
más importante, cómo contribuir de manera organizada con la base de conocimientos para
que todos busquen una retroalimentación continua.
Ventura y Rodriguez de Silva [Ventura, P. et al., 2008] mencionan que existe una vasta
literatura acerca de enfoque de mejora de procesos tales como CMM y CMMI entre otros
pero que, sin embargo, estos enfoques no dicen cómo mejorar y cuales son los medios
específicos para alcanzar un nivel de madurez particular y no muestran cómo se recopila el
conocimiento y las prácticas de proyectos para contribuir a la mejora de los procesos. En
forma más explícita, estos autores consideran que los modelos de mejora de procesos
software existentes identifican QUE hay que mejorar pero no proporcionan ninguna
información acerca de cómo hacerlo.
Por su parte, Montoni y colegas [Montoni, M. et al., 2008] también entienden que la
mayoría de los enfoque de mejora de procesos software solo dan apoyo a la identificación
de QUE actividades deben ser implementadas, pero no acerca de COMO implementar esas
actividades.
Para Humphrey y colegas [Humphrey, W. et al., 2007], las organizaciones necesitan
orientación específica sobre cómo hacer el trabajo de desarrollo y entienden que, por el
modo en que está diseñado, CMMI no provee una orientación de este tipo.
Finalmente, y en la misma línea que las opiniones anteriores, Mutafelija y Stromberg
[Mutafelija, B. et al., 2009] mencionan que CMMI describe mejores prácticas pero no
especifica cómo implementar esas prácticas. Según estos autores, las organizaciones
deben interpretar el modelo para satisfacer sus propias aplicaciones y procesos de
desarrollo que serán implementados para satisfacer de la mejor manera sus objetivos de
negocio. CMMI describe “qué” se espera que haya en los procesos, pero no cómo
implementar procesos; la decisión del “cómo” se deja a criterio de cada organización.
85
3. PLANTEAMIENTO DEL PROBLEMA
3.1 Críticas a los trabajos relacionados
A partir de las diferentes propuestas y trabajos analizados en el capítulo anterior y en
base a los comentarios sobre las mismas incluidos al final de ese capítulo, pueden
formularse las siguientes críticas a los enfoques relacionados con la Experience Factory y
con el uso de la técnica del análisis post mortem de proyectos y sus similares que permiten
establecer la necesidad de un nuevo enfoque para gestionar el conocimiento y la
experiencia en el ámbito de la IS.
3.1.1 Crítica 1
Ambos enfoques se centran en el resultado o producto final de la adquisición de experiencia, esto es, en la experiencia misma adquirida, pero no establecen ningún mecanismo relacionado con el propio proceso de adquisición de esa experiencia.
En efecto, en todos ellos lo que se entiende por “experiencia” se considera que se da
de manera “natural” y pasiva, esto es, que se adquiere experiencia o se aprende algo por el
solo hecho de estar participando en un proyecto de desarrollo. Si bien es indudable que
“algo se aprende” al realizar una determinada actividad, ese aprendizaje no es tan efectivo
como pudiera serlo si el mismo no va acompañado de alguna instancia de análisis y de
reflexión acerca de lo actuado. Para lograr esa maximización del aprendizaje (en términos
de Kolb) no se trata, por decirlo de algún modo, de “obligar” a alguien a reflexionar, sino más
bien de establecer pautas o mecanismos que motiven y orienten esa reflexión y conduzcan
a un aprendizaje activo.
Para ilustrar mejor este punto resulta adecuado traer a colación, desde el ámbito de la
educación, el método de enseñanza denominado “estudio de casos”. En esencia, un caso
de estudio es una narrativa de una situación o problema que se presenta a los alumnos para
su lectura y análisis. Según Wassermann [Wassermann, S., 1994], un buen caso es el
vehículo por medio del cual se lleva al aula un trozo de realidad a fin de que los alumnos y el
profesor lo examinen minuciosamente. Un buen caso mantiene centrada la atención en
alguno de los hechos con los que uno debe enfrentarse en ciertas situaciones de la vida
real. La narrativa del caso concluye con una serie de “preguntas críticas”; es decir, tales que
86
obligan a los alumnos a examinar ideas importantes, nociones y problemas relacionados con
el caso.
En base a lo anterior, y con cierta libertad, se podría considerar que, para el ámbito
específico de los proyectos de desarrollo software, el “caso de estudio” sea, no la
especificación del proceso a seguir, sino el propio hacer o ejecutar el proceso en las
actividades de trabajo diarias. De este modo, la inclusión en el propio proceso de elementos
análogos a las “preguntas críticas” puede constituir un mecanismo facilitador del aprendizaje
y para la creación de nuevo conocimiento respecto a las prácticas y procesos software, así
como un generador de ideas y de propuestas para mejorarlas.
3.1.2 Crítica 2
Tanto los enfoques de Experience Factory como los de análisis post mortem de proyectos y similares no delimitan, a priori, los tipos de conocimientos y de experiencias a capturar.
En efecto, para el caso del enfoque de Experience Factory [Basili, V. et al., 1994] la
premisa es la captura de experiencia “de todo tipo” sin definir previamente qué aspectos de
las prácticas y procesos se pretende mejorar o qué tipos de experiencias son de interés para
la organización en función de sus necesidades actuales o futuras.
En el caso del análisis post mortem de proyectos [Birk, A. et al, 2002], la definición de
objetivos (goals) puede, pero no necesariamente, proporcionar un foco para el análisis.
Incluso, la definición de objetivos tales como “identificar los principales logros del proyecto” o
“desarrollar recomendaciones para una mejor adherencia al calendario” (ejemplificados en el
artículo referido) se muestran como demasiado genéricos.
Esta crítica es igualmente aplicable a los otros métodos análogos al análisis post
mortem donde los aspectos de proyecto que se van a analizar se definen “en el momento”
mediante, por ejemplo, sesiones de “brainstorming”.
3.1.3 Crítica 3 Lo que en la aplicación de las técnicas de análisis post mortem de proyectos y similares se denomina “captura de conocimientos” o “captura de experiencia” ocurre generalmente a partir de proyectos completados, lo cual presenta algunos inconvenientes.
87
Esta crítica es igualmente aplicable a los enfoques basados en la Experience Factory
como el EPG/ER y el de Komi-Sirvio y colegas que utilizan el análisis post mortem de
proyectos y las entrevistas semi-estructuradas para capturar experiencias.
El esperar a que finalice un proyecto o a que se alcance un hito significativo en el
mismo para recolectar o capturar las experiencias adquiridas por los participantes presenta
los siguientes inconvenientes:
1. Una vez finalizado el proyecto, algunos o todos los miembros del equipo pueden
no estar disponibles o no tener tiempo para participar de las actividades post
mortem por diferentes motivos tales como haber sido asignados a otro proyecto o
incluso haberse retirado de la organización.
2. Si el proyecto ha tomado un tiempo largo en su desarrollo y hasta su finalización,
eventos que ocurrieron en etapas tempranas del mismo pueden recordarse con
poca exactitud o incluso haber sido olvidados.
3. Eventos que, a los efectos de análisis, se considerarían importantes, pueden haber
pasado desapercibidos si en el momento de su ocurrencia no se prestó adecuada
atención a los mismos.
Las consideraciones anteriores llevan a proponer que las actividades de análisis y de
reflexión, esto es, la “observación reflexiva” de la que habla Kolb [Kolb, D., 1984] y la
“reflexión en la acción” que propone Schon [Schon, D., 1987], se lleven a cabo durante el
período en el que se desarrolla el proyecto, y que las pautas para realizar esa reflexión y
ese análisis estén integradas en las propias actividades del proyecto, de modo que los
procesos de captura de conocimientos y experiencia ocurran en forma contemporánea a las
actividades de proyecto y de aplicación de las prácticas de desarrollo software.
3.1.4 Crítica 4
Tanto los enfoques de Experience Factory como los de análisis post mortem de proyectos y similares, los mecanismos de captura de conocimientos y de experiencia no están debidamente formalizados.
La crítica anterior conduce a esta última. Al no estar definidos explícitamente los tipos
de experiencia y de conocimientos a recolectar y analizar, no es posible definir
adecuadamente cómo se ha de realizar su captura y análisis. Por ejemplo, una de las
técnicas utilizadas en el análisis post mortem de proyectos [Birk, A. et al, 2002] es la
denominada “sesiones KJ” donde los participante proponen hasta cuatro experiencias
positivas y negativas que luego se ordenan por tema y se priorizan. Sin objetivos
88
previamente establecidos, las experiencias propuestas pueden ser tan diversas que resulte
difícil establecer la importancia relativa de una respecto a las otras. Por otra parte, y aún
cuando se hayan priorizado las experiencias a discutir, esa misma diversidad puede implicar
que haya participantes de la sesión que, al no haber estado involucrados en las experiencias
prioritarias a discutir, no tengan nada propio que aportar.
En el enfoque de Experience Factory, Basili y colegas [Basili, V. et al., 1984] apuntan
al uso de herramientas software tales como Frecuently Asked Questions, e-mail y sesiones
de chat para la captura y el intercambio de experiencias, pero no establecen lineamientos
acerca de cómo utilizar de manera eficiente estas herramientas con tales fines.
3.2 El problema
En base a las consideraciones anteriores, el problema a abordar en la tesis puede
enunciarse en los siguientes términos:
¿Cómo incorporar a las prácticas y procesos de desarrollo software de una
organización, procedimientos y artefactos específicos para orientar y gestionar el
conocimiento y el aprendizaje basado en la experiencia que se adquiere en el marco de los
proyectos de desarrollo software?
89
4. SOLUCIÓN PROPUESTA
4.1 Consideraciones iniciales
La solución que se proponga para el problema planteado en el capítulo anterior debe
necesariamente contemplar las críticas formuladas a las propuestas y trabajos analizados.
En consecuencia, la solución debe cumplir con los siguientes cuatro criterios:
1. Que no sólo incorpore elementos relacionados con el conocimiento, el aprendizaje
y la experiencia sino que, además, establezca de qué manera gestionarlos.
2. Que los procesos de captura de conocimientos y de experiencias puedan también
ser realizados durante la ejecución de los proyectos software y no sólo a partir de
proyectos completados.
3. Que delimite los conocimientos y experiencia a ser capturados y gestionados en
base a un conjunto de objetivos claramente definidos.
4. Que contenga mecanismos y herramientas formales para la captura de
conocimientos y experiencia.
4.2 La solución propuesta
En base a las consideraciones anteriores, la solución que se propone para el problema
planteado en el capítulo anterior consiste en la definición de un modelo iterativo para la gestión del conocimiento y del aprendizaje basado en la experiencia que:
1. Refleja las instancias de creación de conocimientos (según el modelo de Nonaka y
Takeuchi) y de aprendizaje experiencial (según el modelo de Kolb).
2. Se integra a las actividades habituales de trabajo en el marco de los proyectos de
desarrollo de software.
3. Se alinea con los objetivos organizacionales de mejora de las prácticas y procesos
software en uso en una organización.
4. Incorpora procedimientos y artefactos para la gestión del conocimiento y la
experiencia.
90
Para proporcionar una visión general de la solución propuesta, la figura 4.1 presenta
un esquema funcional de la misma donde pueden identificarse sus principales componentes.
Figura 4.1: Esquema funcional de la solución propuesta
Se parte del presupuesto de que existe una organización software que, en base a la
GC y de la experiencia en la participación en proyectos software de sus miembros, tiene por
objetivo mejorar sus prácticas y procesos software. Se entiende aquí por “organización” una
empresa o una unidad de negocios dentro de una organización cuya actividad principal es el
desarrollo de software y en la que se llevan a cabo las actividades de mejora de sus
prácticas y procesos software.
A partir del conjunto de prácticas y procesos software en uso en la organización se
define una serie de objetivos de aprendizaje y de nuevos conocimientos para aquellas
prácticas y procesos software que la organización considera necesario mejorar. En base a
estos objetivos se elaboran las denominadas guías de reflexión. Estas guías contendrán
una serie de preguntas o sentencias de reflexión cuyo propósito será el de orientar y facilitar
el análisis y la reflexión sobre la realización de las tareas de proyecto por parte de los
miembros del equipo de proyecto.
Una vez elaboradas estas guías, las mismas son asignadas a los miembros de los
equipos de proyectos software quienes, al tiempo que ejecutan sus tareas de proyecto,
utilizan las guías para ir registrando sus reflexiones e impresiones, las dificultades
encontradas, imprevistos y consideraciones similares en relación a la manera en que se
llevan a cabo esas tareas.
Una vez finalizadas las tareas de proyecto y respondidas las preguntas de reflexión de
las guías, las mismas son recolectadas para su análisis primario y para la identificación
inicial de los nuevos conocimientos y experiencias capturadas en las respuestas.
Esta última actividad provee los insumos de nuevos conocimientos y experiencias
personales para preparar y llevar a cabo un proceso colectivo análisis y discusión de los
91
mismos con los propósitos de extraer lecciones aprendidas durante la ejecución de las
actividades de proyecto y de elaborar propuestas de mejores prácticas que se incorporan a
un Repositorio de Lecciones Aprendidas y de Mejores Prácticas.
Estos nuevos conocimientos y aprendizajes impactarán en la manera en que se lleven
a cabo en el futuro las actividades de proyecto así como constituirán la base para la
incorporación de mejoras a las prácticas y procesos software en uso en la organización.
Esta secuencia de actividades se repite de manera iterativa para permitir a la
organización gestionar de manera incremental la creación de conocimientos y el aprendizaje
organizacional, integrando las actividades de gestión del conocimiento y de la experiencia a
los proyectos software y a las actividades de mejora de sus prácticas y procesos.
4.3 Presentación del modelo
Se presenta a continuación la estructura general del modelo “ele” con una breve
descripción del propósito de cada una de sus fases para, posteriormente, exponer la manera
en que esas fases se integran tanto a las actividades de los proyectos como a las
actividades de mejora de las prácticas y procesos software.
4.3.1 El modelo ele
El modelo propuesto, denominado “ele” por la representación gráfica dada al mismo,
está estructurado en ocho fases, según se muestra en la figura 4.2:
Figura 4.2: Modelo "ele"
92
El propósito del modelo es delinear una serie de fases y tareas para la GC y del
aprendizaje basado en la experiencia que los miembros de los equipos de proyectos
software adquieren durante la realización de sus actividades de proyecto.
El modelo parte de una fase de Iniciación, cuyo propósito principal es establecer las
bases para la puesta en marcha del modelo. Aquí es donde se definen las áreas y
actividades de IS sobre las que se aplicará el modelo, se fijan los objetivos de aprendizaje y
de creación de nuevos conocimientos y se establecen los roles y las responsabilidades de
los diferentes actores que estarán involucrados en la ejecución de las siguientes fases y
tareas del modelo.
A esta fase le sigue un ciclo iterativo conformado por las fases siguientes:
La fase de Preparación que tiene como propósito preparar a la organización para una
nueva iteración en la ejecución del modelo, y es donde se elaboran los principales artefactos
de GC y del aprendizaje que se utilizarán en las restantes fases del ciclo.
El propósito de la fase de Familiarización es lograr que los miembros de los equipos
de proyectos conozcan y comprendan los objetivos de aprendizaje y de creación de
conocimientos establecidos y adquieran los conocimientos básicos necesarios para
desarrollar las actividades de proyecto que le fueron asignadas.
En la fase de Actuación, los miembros de los equipos de proyectos, al tiempo que
desarrollan las actividades asignadas en los mismos, van analizando su quehacer en
función de los criterios provistos en las guías de reflexión y respondiendo a las preguntas
correspondientes. También durante esta fase los miembros de los equipos de proyectos, en
forma individual o colectiva, comienzan a delinear las sugerencias y propuestas de mejora
que serán posteriormente analizadas y discutidas en la posterior fase de Educción.
Para la fase de Educción, el propósito es capturar, analizar y sintetizar los
conocimientos y los aprendizajes logrados en la fase de Actuación, con los objetivos de
extraer lecciones aprendidas a partir de la ejecución práctica de las tareas de proyecto, y la
generación de propuestas de mejores prácticas para las prácticas y procesos software
seleccionados al comienzo.
La fase de Integración tiene como propósito incorporar, al denominado Repositorio de
lecciones aprendidas y de mejores prácticas, los conocimientos y la experiencia capturados
en la fase anterior.
La fase siguiente de Revisión tiene como propósito evaluar la aplicación del modelo
hasta el momento, de modo de identificar las eventuales desviaciones respecto a los
objetivos iniciales de aprendizaje y de creación de nuevos conocimientos, así como
identificar aspectos a mejorar en la ejecución de las diferentes actividades propias del
modelo.
93
Finalmente, luego del ciclo iterativo, la fase de Conclusión tiene como propósito
cerrar, de manera formal, el ciclo iterativo de aplicación del modelo para el conjunto de
prácticas y procesos establecidos inicialmente. Se llega a esta fase una vez que, a juicio de
la organización, se ha alcanzado un nivel de aprendizaje y de creación de nuevos
conocimientos compatibles con los objetivos definidos al comienzo.
4.3.2 Integración del modelo a las actividades de proyecto y de mejora
Las fases y tareas del modelo se integran tanto a las actividades de los proyectos
software como a las de mejora de las prácticas y procesos software en uso, de modo que el
conocimiento, el aprendizaje y la experiencia ganados por los miembros de los equipos de
proyecto durante la ejecución de las actividades de proyecto puedan ser utilizados como
base para la elaboración e incorporación de mejoras en las prácticas y procesos software en
uso en la organización. El momento de integración variará en función de la fase del modelo
en que se esté en cada instancia, según se muestra gráficamente en la figura 4.3:
Figura 4.3: Integración del modelo a las actividades de proyecto y de mejora
4.3.2.1 Integración con las actividades de proyectos La integración del modelo a las actividades de los proyectos software se da
fundamentalmente durante la fase de Actuación. En efecto, las guías de reflexión contienen
preguntas y sentencias de reflexión relativas a las actividades de proyecto a ejecutar,
técnicas a aplicar o procesos a seguir por parte de los miembros de los equipos de proyecto
y el propósito de esas preguntas o sentencias es el de motivar y orientar el análisis y la
reflexión sobre la ejecución práctica de esas actividades, técnicas y procesos.
94
4.3.2.2 Integración con las actividades de mejora La integración del modelo en las actividades de mejora de las prácticas y procesos
software se da esencialmente en las fases de Iniciación, de Preparación y de Integración.
En la fase de Iniciación es donde, a partir de los objetivos de mejora que establezca la
organización, se seleccionan las prácticas y procesos software a mejorar y donde se definen
los objetivos de aprendizaje y de creación de conocimientos.
En la fase de Preparación es donde estos objetivos de aprendizaje y de creación de
conocimientos se traducen en las preguntas o sentencias de reflexión a incluir en las guías
de reflexión. Estas preguntas o sentencias deben apuntar, precisamente, a motivar el
análisis y la reflexión sobre aquellos aspectos de las prácticas y procesos software que se
pretende mejorar.
Finalmente, en la fase de Integración es donde los nuevos conocimientos y la
experiencia adquiridos se incorporan al Repositorio de lecciones aprendidas y de mejores
prácticas y que pueden ser utilizados como base para la reformulación de las prácticas y
procesos software en uso en la organización.
4.4 Descripción del modelo
Para la descripción detallada del modelo que se expone a continuación, se ha seguido
un esquema similar al propuesto por Persee [Persee, J., 2006], donde cada fase del modelo
está descripta en función de los siguientes elementos:
A) Propósito: es una breve descripción del propósito general de la fase.
B) Objetivos: es una lista de las metas a alcanzar mediante la ejecución de las tareas
definidas para la fase.
C) Criterios de entrada: son las precondiciones necesarias para poder dar inicio a la
fase.
D) Criterios de salida: son las poscondiciones necesarias para dar por finalizada la
fase.
E) Insumos: describe los artefactos requeridos para realizar las tareas de la fase.
F) Productos: describen los resultados a obtener como consecuencia de las tareas
realizadas en la fase.
G) Diagrama: es la representación gráfica del flujo de tareas.
H) Tareas: constituyen los pasos a seguir en el desarrollo de la fase.
Los productos generados en cada fase, además de un nombre descriptivo, se
identificarán mediante un código del estilo Xxx-##, donde:
95
• Xxx: refiere a la fase en la cual se genera el producto.
• ##: refiere a un número de identificación.
Los insumos de una fase pueden ser documentos u otros artefactos generados en
alguna fase previa del modelo (como producto de esa fase), o bien documentos u otros
artefactos que han sido generados externamente al mismo. Cuando el insumo corresponda
a un producto generado en una fase previa, se hará referencia a su código de identificación
original. Para el caso de un insumo que ha sido generado externamente al modelo, el código
de fase será Ext.
4.4.1 Iniciación
A) Propósito El propósito de la fase de Iniciación es establecer las bases para la puesta en marcha
del modelo. Aquí es donde se definen las áreas y prácticas de IS sobre las que se aplicará
el modelo, se fijan los objetivos de aprendizaje y de creación de nuevos conocimientos y se
establecen los roles y las responsabilidades de los diferentes actores que estarán
involucrados en la ejecución de las siguientes fases.
B) Objetivos a) Definir las prácticas y áreas del proceso software sobre las que se va a aplicar el
modelo.
b) Definir objetivos de aprendizaje y necesidades de nuevos conocimientos.
c) Conformar el grupo de trabajo responsable de gestionar las actividades propuestas
en el modelo.
C) Criterios de entrada a) La organización ha lanzado o se apresta a lanzar una iniciativa para la mejora de sus
prácticas y procesos de desarrollo software.
b) La organización ha tomado conciencia de la conveniencia de gestionar el
conocimiento, el aprendizaje y la experiencia como forma de apoyar las actividades
de mejora.
D) Criterios de salida a) Las prácticas y procesos sobre los que se ha de aplicar el modelo han sido
establecidas.
b) Los objetivos de aprendizaje y de nuevos conocimientos han sido definidos.
96
c) El grupo de trabajo responsable de aplicar el modelo ha sido conformado.
E) Insumos a) Ext-01: Documento de especificación del proceso software (si existe).
b) Ext-02: Documento con la evaluación (“assessment”) de las prácticas y procesos en
uso, junto con los objetivos de mejora previamente establecidos (si existe).
F) Productos a) Ini-01: Documento de conformación del Grupo de Gestión del Conocimiento y el
Aprendizaje.
b) Ini-02: Documento de especificación de las prácticas y procesos sobre los que se va
a aplicar el modelo, junto con los objetivos de aprendizaje y de creación de
conocimientos.
c) Ini-03: Documento de Plan de difusión.
G) Diagrama
La figura 4.4 muestra el flujo de tareas para la fase de Iniciación.
Figura 4.4: Flujo de tareas para la fase de Iniciación
97
H) Tareas
a) Conformar el Grupo de Gestión del Conocimiento y el Aprendizaje (GGCA)
El GGCA es responsable de la planificación, la ejecución y la supervisión de las
diferentes actividades definidas en el modelo. Este grupo tendrá diferentes cometidos,
según la fase del modelo en el que se esté en un momento determinado. Estos cometidos
se exponen con detalle en 4.5.1.
b) Seleccionar prácticas y procesos software sobre las que se aplicará el modelo
De las diferentes prácticas y procesos software en uso en la organización, se
seleccionan aquí aquellas que la organización determina que pretende mejorar y respecto
de las cuales se implementará el modelo.
c) Definir objetivos de aprendizaje y de nuevos conocimientos
En función de los objetivos de mejora fijados por la organización, corresponde aquí
establecer los correspondientes objetivos de creación de nuevos conocimientos y de
aprendizaje a alcanzar como consecuencia de la aplicación del modelo.
d) Iniciar proceso de gestión del conocimiento y del aprendizaje
Con esta tarea se da inicio formal a las actividades GC y del aprendizaje. Corresponde
aquí comunicar a la organización acerca de la iniciativa a llevarse a cabo, procurando que
todas las personas que estarán involucradas en la misma conozcan el alcance y los
objetivos de las actividades a ser desarrolladas y cómo estas actividades se insertarán en
sus actividades de trabajo habituales.
4.4.2 Preparación
A) Propósito El propósito de la fase de Preparación es el de preparar a la organización para una
nueva iteración en la ejecución del modelo y elaborar los principales artefactos de gestión
del conocimiento y del aprendizaje que se utilizarán en las restantes fases del ciclo iterativo.
Estos artefactos son el Catálogo de conocimientos y experiencia, el Inventario de
conocimientos y experiencia y las Guías de reflexión.
B) Objetivos a) Elaborar las guías de reflexión en función de los objetivos de aprendizaje y de
nuevos conocimientos previamente definidos.
98
b) Identificar y evaluar las brechas de conocimientos de los miembros de los equipos de
proyecto relativas a las tareas de proyecto que tendrán que desarrollar.
C) Criterios de entrada a) Las prácticas y procesos software sobre los que se aplicará el modelo han sido
establecidos.
b) Los objetivos de aprendizaje y de nuevos conocimientos han sido definidos.
c) Los miembros del GGCA han sido nombrados.
D) Criterios de salida a) Las guías de reflexión han sido elaboradas y asignadas a los miembros de los
proyectos.
b) Las necesidades de nuevos conocimientos de los miembros de los equipos de
proyecto han sido identificadas.
E) Insumos a) Ini-02: Documento de especificación de las prácticas y procesos sobre los que se va
a aplicar el modelo, junto con los objetivos de aprendizaje y de creación nuevos
conocimientos.
b) Ext-03: Documentos de asignación y de especificación de actividades de proyectos.
F) Productos a) Pre-01: Catálogo de conocimientos y experiencia.
b) Pre-02: Guías de reflexión.
c) Pre-03: Documento de asignación de las guías de reflexión.
d) Pre-04: Inventario de conocimientos y de experiencia.
e) Pre-05: Plan de adquisición inicial de conocimientos.
G) Diagrama La figura 4.5 muestra el flujo de tareas para la fase de Preparación.
99
Figura 4.5: Flujo de tareas para la fase de Preparación
H) Tareas
a) Elaborar o actualizar el catálogo de conocimientos y experiencia
El Catálogo de conocimientos y experiencia es una lista nominal y ordenada de los
conocimientos, conceptos, actividades y técnicas relativos a las prácticas y procesos
software respecto de las cuales se definieron los objetivos de aprendizaje y de creación de
conocimientos.
b) Elaborar o actualizar las guías de reflexión
Las Guías de Reflexión son una herramienta para motivar y orientar la reflexión y el
análisis sobre las actividades de proyecto que han de llevar a cabo los miembros de los
equipos de proyecto y respecto de las cuales se establecieron los objetivos de aprendizaje y
de creación de conocimientos. El método general para la elaboración de las guías de
reflexión se expone el 4.5.4.
c) Asignar guías de reflexión
Los miembros de los equipos de proyectos deben recibir, junto con las asignaciones
de tareas propias del proyecto en el que participan, las correspondientes guías de reflexión
que les orientarán en las actividades de reflexión y análisis durante la ejecución de dichas
tareas.
100
d) Elaborar o actualizar el inventario de conocimientos y experiencia
El Inventario de conocimientos y experiencia es un relevamiento de los conocimientos
y de la experiencia que cada miembro de los equipos de proyectos tiene en relación con los
roles y las actividades de proyecto que le corresponderá desempeñar durante el desarrollo
del mismo. El propósito de este inventario y el método general para su elaboración se
presentan en el apartado 4.5.3.
e) Identificar brechas de conocimientos
En base al relevamiento de conocimientos y experiencia realizado en la tarea anterior,
corresponde aquí identificar las posibles carencias de conocimientos de los miembros de los
equipos de proyecto en relación con los elementos de conocimientos y experiencia
considerados en la elaboración del inventario. El método general para la identificación de las
brechas de conocimientos se presenta en el apartado 4.5.3.
f) Definir plan de adquisición inicial de conocimientos
Para eliminar, o al menos reducir, las brechas de conocimientos que se hayan
identificado en la tarea anterior, pueden definirse una variedad de mecanismos, tales como
el estudio individual o grupal de material bibliográfico, impartir cursos específicos y la
realización de talleres, entre otros.
4.4.3 Familiarización
A) Propósito El propósito de la fase de Familiarización es que los miembros de los equipos de
proyectos conozcan los objetivos de aprendizaje y de creación de conocimientos
establecidos, que comprendan el propósito y contenido de las guías de reflexión, y que
adquieran los conocimientos básicos necesarios para desarrollar las actividades de proyecto
asignadas a cada uno.
B) Objetivos a) Que los miembros de los equipos de proyecto conozcan el propósito y el contenido
de las guías de reflexión.
b) Que los miembros de los equipos de proyecto adquieran los conocimientos básicos
necesarios para realizar las tareas de proyecto que le fueron asignadas.
101
C) Criterios de entrada a) Las guías de reflexión han sido asignadas a los miembros de los equipos de
proyecto.
b) Las necesidades de adquisición de conocimientos han sido determinadas.
D) Criterios de salida a) Las guías de reflexión han sido analizadas y comprendidas por los miembros del
equipo de proyecto.
b) Los miembros de los equipos de proyecto han adquirido los conocimientos básicos
necesarios relativos a las actividades de proyecto que tendrán que realizar.
E) Insumos a) Pre-02: Guías de reflexión.
b) Pre-03: Documento de asignación de las guías de reflexión.
c) Pre-05: Plan de adquisición inicial de conocimientos.
F) Productos a) Pre-04: Inventario de conocimientos y de experiencia (actualizado).
G) Diagrama La figura 4.6 muestra el flujo de tareas para la fase de Familiarización.
Figura 4.6: Flujo de tareas para la fase de Familiarización
H) Tareas
a) Analizar y comprender las guías de reflexión
La finalidad de esta tarea es comunicar a los miembros de los equipos de proyecto el
propósito y contenidos de las guías de reflexión, así como explicar la manera en que deben
102
proceder para responder las preguntas o sentencias de reflexión a partir de la experiencia
práctica de realizar sus actividades de proyecto.
b) Adquirir conocimientos básicos
En base al plan de adquisición de conocimientos establecido en la fase anterior (tarea
f), corresponde aquí instrumentar los mecanismos definidos en el mismo. Estos mecanismos
pueden consistir, por ejemplo, en la asignación de lecturas de material técnico o la
realización de cursos o talleres enfocados específicamente a los temas en los que se han
detectado esas carencias de conocimientos.
Los conocimientos a adquirir han de referir, por ejemplo, a conceptos, técnicas y
métodos a utilizar durante las actividades de proyecto, así como a criterios para determinar
cuando es más adecuada la utilización de cada técnica o método.
4.4.4 Actuación
A) Propósito Durante la fase de Actuación, los miembros de los equipos de proyectos, al tiempo
que desarrollan sus actividades de proyecto, van analizando su quehacer siguiendo los
criterios provistos en las guías de reflexión y respondiendo a las preguntas incluidas en las
mismas. También durante esta fase los miembros de los equipos de proyectos, en forma
individual o colectiva, pueden comenzar a delinear las sugerencias y propuestas de mejora
que serán posteriormente analizadas y discutidas en la siguiente fase de Educción.
B) Objetivos a) Lograr el aprendizaje basado en la experiencia práctica de realización de las
actividades de proyecto inicialmente asignadas.
C) Criterios de entrada a) Los objetivos de aprendizaje y las guías de reflexión han sido analizados y
comprendidos por los miembros de los equipos de proyectos.
b) Los conocimientos básicos para la realización de sus respectivas tareas han sido
adquiridos.
D) Criterios de salida a) Los miembros de los equipos de proyecto han concluido las actividades de proyecto
que les fueron asignadas.
103
b) Los miembros de los equipos de proyecto han respondido a todas las preguntas
incluidas en sus respectivas guías de reflexión.
E) Insumos a) Pre-02: Guías de reflexión.
F) Productos a) Act-01: Guías de reflexión con las preguntas respondidas.
G) Diagrama La figura 4.7 muestra el flujo de tareas para la fase de Actuación.
Figura 4.7: Flujo de tareas para la fase de Actuación
H) Tareas
a) Responder preguntas de las guías de reflexión
A medida que los miembros de los equipos de proyecto avanzan en la realización de
sus tareas de proyecto, van respondiendo a las preguntas o sentencias incluidas en las
guías de reflexión, siguiendo los lineamientos que éstas proporcionan. Estas respuestas
deberán estar basadas en la experiencia práctica de estar realizando o haber realizado las
actividades de proyecto que le fueron asignadas. Como parte de las respuestas, los
miembros de los equipos de proyecto pueden incluir ideas y propuestas de mejora a las
actividades y prácticas que están realizando.
b) Revisar la completitud de respuestas a preguntas de reflexión
Para poder dar por concluida esta fase, es necesario que cada miembro de los
equipos de proyecto haya respondido a todas las preguntas incluidas en sus respectivas
guías de reflexión.
104
4.4.5 Educción
A) Propósito El propósito de la fase de Educción es obtener, analizar y sintetizar los conocimientos
y los aprendizajes basados en la experiencia logrados en la fase de Actuación, así como
discutir y consolidar las diferentes propuestas de mejora que se hayan elaborado en esa
fase.
B) Objetivos a) Capturar los conocimientos creados y los aprendizajes logrados durante la
ejecución de las tareas de proyectos.
b) Evaluar las propuestas preliminares de mejora que hayan sido formuladas por los
miembros de los equipos de proyecto.
c) Alcanzar un consenso respecto a las propuestas de mejora a ser eventualmente
introducidas en las prácticas y procesos software.
C) Criterios de entrada a) Los miembros de los equipos de proyecto han seguido las guías de reflexión que les
fueron asignadas.
b) Los miembros de los equipos de proyecto han respondido las preguntas de reflexión.
D) Criterios de salida a) La captura de nuevos conocimientos y de experiencia ha sido realizada.
b) Las lecciones aprendidas y las propuestas de mejores prácticas han sido elaboradas.
E) Insumos a) Act-01: Guías de reflexión con las preguntas respondidas.
F) Productos a) Edu-01: Documento de educción de conocimientos y experiencias.
b) Edu-02: Documento de síntesis de lecciones aprendidas.
c) Edu-03: Documento de propuestas de mejores prácticas.
G) Diagrama La figura 4.8 muestra el flujo de tareas para la fase de Educción.
105
1. Educir nuevos conocimientos y aprendizajes
2. Sintetizar lecciones aprendidas
Act-01
Edu-02Edu-01
Insumo
Producto
Edu-01
3. Elaborar propuestas de mejores prácticas
Edu-03Edu-01
Figura 4.8: Flujo de tareas para la fase de Educción
H) Tareas
a) Educir nuevos conocimientos y aprendizajes
El propósito de esta tarea es identificar y capturar los conocimientos y la experiencia
adquiridos por los miembros de los equipos de proyecto durante la realización de sus
actividades de proyecto.
b) Sintetizar las lecciones aprendidas
El propósito de esta tarea es sintetizar los conocimientos y la experiencia que puedan
considerarse como “lecciones aprendidas” durante la ejecución de las actividades de
proyecto y que fueron identificadas y discutidas en el proceso de educción anterior.
c) Elaborar las propuestas de mejores prácticas
El propósito de esta tarea es elaborar las propuestas de mejores prácticas que hayan
sido identificadas y discutidas durante el proceso de educción anterior.
4.4.6 Integración
A) Propósito El propósito de la fase de Integración es el de incorporar al repositorio de lecciones
aprendidas y de mejores prácticas los conocimientos y la experiencia capturados en la fase
anterior. Esta integración implica la incorporación de elementos nuevos así como la
reformulación de las existentes para reflejar en el mismo las propuestas de mejora
elaboradas en la fase anterior.
106
B) Objetivos a) Seleccionar e incorporar al repositorio de lecciones aprendidas y de mejores
prácticas las propuestas de mejora elaboradas en la fase anterior.
C) Criterios de entrada a) El proceso de educción de conocimientos y experiencia ha finalizado.
b) Las lecciones aprendidas y las propuestas de mejores prácticas han sido elaboradas.
D) Criterios de salida a) Las lecciones aprendidas y propuestas de mejores prácticas se han incorporado al
Repositorio.
E) Insumos a) Edu-02: Documento de síntesis de lecciones aprendidas.
b) Edu-03: Documento de propuestas de mejores prácticas.
c) Int-01: Repositorio de lecciones aprendidas y de mejores prácticas.
F) Productos a) Int-01: Repositorio de lecciones aprendidas y de mejores prácticas actualizado.
G) Diagrama La figura 4.9 muestra el flujo de tareas para la fase de Integración.
Figura 4.9: Flujo de tareas para la fase de Integración
107
H) Tareas
a) Incorporar lecciones aprendidas al repositorio
El propósito de esta tarea es incorporar al Repositorio de Lecciones Aprendidas y
Mejores Prácticas las lecciones aprendidas elaboradas en la fase anterior.
b) Integrar mejores prácticas al repositorio
El propósito de esta tarea es incorporar al Repositorio de Lecciones Aprendidas y
Mejores Prácticas las propuestas de mejores prácticas elaboradas en la fase anterior.
4.4.7 Revisión
A) Propósito El propósito de la fase de Revisión es el de evaluar la aplicación del modelo hasta el
momento, de modo de identificar las eventuales desviaciones respecto a los objetivos
iniciales de aprendizaje. También en esta fase se analiza el proceso general seguido, así
como los diferentes productos que han sido generados durante la ejecución de las diferentes
actividades del modelo.
B) Objetivos a) Identificar los eventuales desvíos respecto a los objetivos de aprendizaje y de
creación de nuevos conocimientos definidos en la fase de Iniciación.
b) Evaluar el proceso general seguido y los productos generados en cada fase del
modelo.
c) Formular recomendaciones de mejora al propio proceso de gestión del conocimiento
y del aprendizaje definido por el modelo.
C) Criterios de entrada a) Las lecciones aprendidas y las mejores prácticas han sido incorporadas al
Repositorio.
D) Criterios de salida a) Los eventuales desvíos respecto a los objetivos iniciales de aprendizaje han sido
identificados y analizados.
b) Los productos generados y las actividades realizadas han sido analizados, y se han
formulado recomendaciones de mejora para las mismas.
108
E) Insumos a) Ini-02: Documento de especificación de las prácticas y procesos sobre los que se va
a aplicar el modelo, junto con los objetivos de aprendizaje y de creación de
conocimientos.
b) Pre-02: Guías de reflexión.
c) Pre-04: Inventario de conocimientos y de experiencia.
d) Act-01: Guías de reflexión con las preguntas respondidas.
F) Productos a) Rev-01: Documento de evaluación de las actividades realizadas y de los productos
generados.
b) Rev-02: Documento de objetivos alcanzados y no alcanzados.
c) Rev-03: Documento de decisión de realizar o no una nueva iteración.
G) Diagrama La figura 4.10 muestra el flujo de tareas para la fase de Revisión.
2. Identificar desvíos respecto a los objetivos de aprendizaje
Act-01
Rev-02Ini-02
1. Evaluar el proceso seguido y los productos generados
Ini-02Rev-01
Pre-02
3. Decidir si es necesaria una nueva iteración
Rev-03Ini-02
Pre-01
Act-01
Insumo
Producto
Rev-02
Figura 4.10: Flujo de tareas para la fase de Revisión
H) Tareas
a) Evaluar el proceso seguido y los productos generados
La evaluación del proceso seguido refiere a analizar la manera en que las diferentes
actividades del modelo se han llevado a cabo en la presente iteración y las dificultades
encontradas en su implementación, así como identificar aspectos a modificar y mejorar en
una próxima iteración.
109
La evaluación de los productos refiere a determinar si los productos generados en las
diferentes fases del modelo (inventario de conocimientos y experiencia, guías de reflexión)
son adecuados, en cuanto a sus estructuras y contenidos, a los fines para los cuales fueron
creados.
b) Identificar desvíos respecto a los objetivos de aprendizaje
En esta tarea se analizan los aprendizajes y los nuevos conocimientos logrados por
los miembros de los equipos de proyecto en la presente iteración y se los compara con los
objetivos establecidos al comienzo de modo de poder determinar en qué grado esos
objetivos fueron alcanzados.
c) Decidir si es necesaria una nueva iteración
En base al análisis efectuado en la tarea anterior, corresponde aquí decidir si es
necesario realizar una nueva iteración del modelo. En tal caso, se retorna a la fase de
Preparación para reiniciar el ciclo redefiniendo los procesos a seguir y reelaborando, si
corresponde, los artefactos que se crean en esa fase teniendo en consideración el análisis
de procesos y productos realizado.
4.4.8 Conclusión
A) Propósito El propósito de la fase de Conclusión es cerrar, de manera formal, el ciclo iterativo de
aplicación del modelo para el conjunto de prácticas y procesos establecidos inicialmente. Se
llega a esta fase una vez que se consideren alcanzados los objetivos de aprendizaje y de
creación de conocimientos establecidos en la fase de Iniciación.
B) Objetivos a) Evaluar la aplicación general del modelo en base al conjunto de iteraciones
realizadas.
C) Criterios de entrada a) Los objetivos de aprendizaje y de creación de conocimientos establecidos en la fase
de Iniciación han sido alcanzados.
b) Se ha decidido que no es necesaria una nueva iteración.
D) Criterios de salida a) La aplicación general del modelo ha sido analizada y evaluada.
110
E) Insumos a) Rev-01: Documento de evaluación de las actividades realizadas y de los productos
generados.
b) Rev-03: Documento de decisión de realizar o no una nueva iteración.
F) Productos a) Con-01: Documento final de cierre con el análisis general de aplicación del modelo.
G) Diagrama La figura 4.11 muestra el flujo de tareas para la fase de Conclusión.
Figura 4.11: Flujo de tareas para la fase de Conclusión
H) Tareas
a) Evaluar la aplicación general del modelo
El propósito de esta tarea es realizar un análisis general de la aplicación del modelo
teniendo en consideración todas las iteraciones efectuadas y evaluar los resultados
obtenidos como consecuencia de la implementación de las actividades de gestión del
conocimiento y del aprendizaje basado en la experiencia.
4.5 Otros elementos constitutivos del modelo
Se exponen a continuación otros elementos relativos al modelo que, por razones de
claridad, fueron solamente mencionados en la descripción anterior de las fases del modelo.
Estos elementos son:
1. El Grupo de Gestión del Conocimiento y del Aprendizaje.
2. El Catálogo de Conocimientos y Experiencia.
3. El Inventario de Conocimientos y Experiencia.
4. Las Guías de Reflexión.
5. El Taller de Educción de Conocimientos y Experiencia.
6. Repositorio de Lecciones Aprendidas y de Mejores Prácticas.
111
4.5.1 El Grupo de Gestión del Conocimiento y del Aprendizaje
El Grupo de Gestión del Conocimiento y del Aprendizaje (CCGA) es responsable de
establecer, supervisar y apoyar las actividades de gestión del conocimiento y del
aprendizaje a lo largo de todo el proceso de ejecución del modelo.
Los principales cometidos de este grupo, en cada una de las fases, son los que se
indican a continuación:
A) Iniciación:
a) Definir, junto con los responsables de las actividades de mejora, cuales serán
las prácticas y procesos sobre los que se aplicará el modelo.
b) Definir los objetivos de aprendizaje y de nuevos conocimientos.
c) Definir el plan general de actividades para las siguientes fases del modelo.
d) Comunicar a la organización la naturaleza y características de las futuras
actividades de GC y del aprendizaje, y de qué manera éstas se insertarán en
las actividades propias de los proyectos y también en las actividades de
mejora.
B) Preparación:
a) Elaborar o actualizar el catálogo de conocimientos y experiencia.
b) Elaborar o actualizar las guías de reflexión.
c) Preparar y llevar a cabo el relevamiento para confeccionar o actualizar el
inventario de conocimientos y de experiencia de los miembros de los equipos
de proyectos.
d) Identificar las brechas de conocimientos y definir los mecanismos de
adquisición de los mismos.
C) Familiarización:
a) Preparar y coordinar las sesiones de explicación de las guías de reflexión.
b) Preparar y coordinar las actividades de adquisición de conocimientos.
D) Actuación:
a) Colaborar con los miembros de los equipos de proyectos en la facilitación de
las discusiones y en el seguimiento de las guías de reflexión.
E) Educción:
a) Preparar y llevar a cabo las actividades de educción de conocimientos y
experiencia.
b) Analizar las respuestas a las preguntas de reflexión y las propuestas de
lecciones aprendidas y de mejores prácticas formuladas por los miembros de
los equipos de proyectos.
112
F) Integración:
a) Seleccionar, junto con los responsables de las actividades de mejora, las
lecciones aprendidas y las propuestas de mejores prácticas a incorporar al
repositorio.
G) Revisión:
a) Identificar los desvíos respecto a los objetivos de aprendizaje definidos
inicialmente.
b) Evaluar los productos generados y el proceso general seguido, y formular las
recomendaciones de mejora que correspondan.
c) Decidir si es necesaria una nueva iteración de la ejecución del modelo.
H) Conclusión:
a) Evaluar la aplicación general del modelo.
b) Redactar el informe final de cierre.
Adicionalmente a los cometidos anteriores para cada fase, el GGCA tiene a su cargo
otras actividades a lo largo de toda la ejecución del modelo, tales como:
A) Elaborar y hacer el seguimiento del plan general de actividades y realizar los ajustes
que correspondan.
B) Mantener reuniones con los gerentes o líderes de proyectos para determinar
eventuales inconvenientes en la ejecución de las actividades del modelo.
C) Apoyar a los miembros de los equipos de proyectos en la correcta interpretación de
los objetivos definidos en las guías de reflexión.
4.5.2 El Catálogo de Conocimientos y Experiencia
El Catálogo de conocimientos y experiencia es una lista nominal y ordenada de los
conocimientos, conceptos, actividades y técnicas relativos a las prácticas y procesos
software respecto de las cuales se definieron los objetivos de aprendizaje y de creación de
conocimientos. El esquema de su elaboración se muestra en la figura 4.12.
4.5.2.1 Elementos del catálogo Para definir los elementos de conocimientos y de experiencia a incluir en el catálogo
se propone una clasificación de los mismos en dos categorías [Matturro, G., Silva, A., 2005]:
A) Generales: conocimientos y experiencia relativos a las prácticas y procesos
software generalmente aceptados. Se incluyen aquí los elementos definidos en la
Guide to the Software Engineering Body of Knowledge [Abran, A. et al., 2004].
113
B) Particulares: conocimientos y experiencia relativos a las prácticas y procesos
software desarrolladas y aplicadas por la organización, y que son variaciones o
adaptaciones propias de los incluidos en la categoría anterior. Se incluyen aquí los
conocimientos y la experiencia educidos y capturados en forma de lecciones
aprendidas y de mejores prácticas obtenidas a partir de proyectos anteriores y que
residen en el Repositorio de lecciones aprendidas y de mejores prácticas (4.4.6).
Figura 4.12: Elaboración del catálogo de conocimientos y experiencia
Los elementos de conocimiento y experiencia que se incluyan en este catálogo
constituyen la base para, posteriormente:
A) elaborar el inventario de conocimientos y experiencia de los miembros de los
equipos de proyecto.
B) elaborar las preguntas o sentencias de las guías de reflexión.
C) organizar las lecciones aprendidas y las mejores prácticas que se incorporen al
Repositorio de Lecciones Aprendidas y Mejores Prácticas.
4.5.2.2. Ejemplo de catálogo de conocimientos y experiencia Para ilustrar la estructura y el contenido del catálogo, se propone el siguiente ejemplo
para el área de conocimientos de Requisitos Software. En la tabla 4.1, los elementos
precedidos de un signo “+” indican ramas que pueden expandirse para mostrar elementos
de conocimiento y experiencia más específicos y solo se han expandido aquellas a las que
se hará referencia en ejemplo posteriores.
114
Area de Conocimiento: Requisitos Software
+ Fundamentos+ ProcesoEducción+ Concepto o definición+ Fuentes de requisitos
Técnicas de educciónEntrevistas
Elección del entrevistadoPlanificación de la entrevistaInteracción con el entrevistado
:+ Escenarios+ Prototipos+ Reuniones de facilitación+ Observación+ Joint Application Development+ Viewpoints
:Análisis de requisitos+ Concepto o definición
Clasificación de requisitosFuncionales y no funcionalesDel producto y del procesoPriorización
:+ Modelado conceptual+ Diseño arquitectónico+ Negociación de requisitos+ Especificación de requisitos+ Validación de requisitos+ Consideraciones prácticas
Tabla 4.1: Estructura del catálogo de conocimientos y experiencia
4.5.3 El Inventario de Conocimientos y Experiencia
El Inventario de conocimientos y de experiencia es un relevamiento de los
conocimientos y de la experiencia que poseen los miembros de la organización. La
elaboración de este inventario como parte de las actividades definidas en el modelo tiene
como propósitos:
A) Determinar los niveles de conocimientos y experiencia de los miembros de los
equipos de proyecto en relación con las prácticas y procesos software en uso en la
organización que fueron seleccionadas en la fase de Iniciación.
B) Permitir la identificación de brechas entre los conocimientos y experiencia
considerados necesarios para la ejecución de las tareas de proyecto y los que
actualmente poseen los miembros de los equipos de proyecto que tienen que
ejecutar esas tareas.
4.5.3.1 Elementos de conocimientos y de experiencia a inventariar A los efectos de su utilización en el modelo, los conocimientos y la experiencia que
son de interés relevar, serán los que posean los miembros de los equipos de proyecto
115
respecto a las lecciones aprendidas y a las propuestas de mejores prácticas relativas a las
prácticas y procesos sobre los que se esté aplicando el modelo y que han sido incluidos en
el Catálogo de conocimientos y experiencia.
4.5.3.2 Valoración de los conocimientos y experiencia La valoración de los conocimientos y experiencia implica determinar en qué grado
esos conocimientos y experiencia son poseídos por los miembros de los equipos de
proyecto. En forma análoga al uso que en la Guide to the Software Engineering Body of
Knowledge [Abran, A. et al., 2004] se le da la taxonomía de objetivos educacionales de
Bloom [Bloom, B. et al., 1979], se propone utilizar los niveles de esa taxonomía, redefinidos
de la manera en que se muestran en la tabla 4.2.
Nivel Descripción Conocimiento La persona (conoce, recuerda, puede describir, …) las lecciones
aprendidas y las propuestas de mejores prácticas relativas a <elemento de conocimientos y experiencia>
Comprensión La persona es capaz de (explicar, ilustrar, ejemplificar, …) las lecciones aprendidas y las propuestas de mejores prácticas relativas a <elemento de conocimientos y experiencia>
Aplicación La persona ha (aplicado, utilizado, tenido en cuenta, …) las lecciones aprendidas y las propuestas de mejores prácticas relativas a <elemento de conocimientos y experiencia>
Análisis La persona ha participado del (análisis, discusión, elaboración, …) de las lecciones aprendidas y las propuestas de mejores prácticas relativas a <elemento de conocimientos y experiencia>
Tabla 4.2: Taxonomía de valoración de conocimientos y experiencia
4.5.3.3 Elaboración del inventario Para elaborar el inventario es necesario determinar, para cada miembro de los equipos
de proyecto, cual de los niveles anteriores describe mejor sus conocimientos y experiencia
para cada elemento de conocimientos y de experiencia a inventariar. Esta determinación se
hace en base a una serie de preguntas a formular, para las que se tienen en cuenta dos
componentes:
A) los elementos de conocimientos y de experiencia relativos al área de
conocimientos, actividad, técnica o proceso software que se van a inventariar,
incluidos en el catálogo de conocimientos y experiencia.
B) los niveles de conocimiento y experiencia definidos arriba, con los
correspondientes verbos asociados a los mismos.
Para redactar, entonces, las preguntas de valoración para un determinado nivel se
combinan el elemento de conocimiento o de experiencia a valorar con alguno de los verbos
asociados al mismo.
116
Figura 4.13: Formulación de preguntas de valoración de conocimientos
En base a las preguntas elaboradas se confecciona un cuestionario a administrar a
cada miembro de los equipos de proyecto y, en función de las respuestas obtenidas, se
asigna el nivel que mejor describa los conocimientos y experiencia que éste posee. El nivel
asignado en cada caso será más un juicio de valor que una medida verdadera debido a la
dificultad inherente de asignar un valor exacto y objetivo a los conocimientos y experiencia
que posee una persona [Matturro, G., Silva, A., 2005]. Todo el proceso anterior se muestra
gráficamente en la figura 4.13.
4.5.3.4 Identificación de las brechas de conocimientos y de experiencia Para identificar las brechas de conocimientos y experiencia es necesario establecer
previamente una valoración de referencia para cada elemento de conocimiento incluido en el
Catálogo de conocimientos y experiencia, y tenido en cuenta en la elaboración del
inventario. En una primera instancia se propone utilizar como referencia valores análogos a
los propuestos en la Guide to the Software Engineering Body of Knowledge [Abran, A. et al.,
2004]. Estos valores iniciales pueden ser luego ajustados en función de los objetivos de
aprendizaje y de creación de conocimientos definidos.
La identificación, entonces, de las brechas de conocimientos y experiencia de cada
miembro de los equipos de proyecto consiste en comparar las valoraciones de referencia
con los niveles asignados a partir del relevamiento realizado para confeccionar el inventario.
4.5.3.5 Ejemplo de estructura del inventario de conocimientos y experiencia Para ilustrar la estructura y el contenido del inventario, se propone el ejemplo
mostrado en la tabla 4.3 para el área de conocimientos de Requisitos Software.
Las primeras tres columnas corresponden a los elementos incluidos en el catálogo de
conocimiento y experiencia. La columna múltiple “Nivel personal” está reservada para indicar
el nivel de conocimiento y experiencia a asignar al miembro del equipo de proyecto para el
cual se confeccione el inventario. La columna múltiple “Referencia” contiene los niveles de
117
conocimientos y experiencia definidos como de referencia. Finalmente, la columna “Dif.” se
utiliza para indicar la diferencia entre el nivel personal y el nivel de referencia.
Area de Conocimiento: Requisitos Software
Dif.Cn Cp Ap An Cn Cp Ap An
+ Fundamentos+ ProcesoEducción+ Concepto o definición x+ Fuentes de requisitos x
Técnicas de educciónEntrevistas
Elección del entrevistado xPlanificación de la entrevista xInteracción con el entrevistado x
:+ Escenarios x+ Prototipos x+ Reuniones de facilitación x+ Observación x+ Joint Application Development x+ Viewpoints x
:Análisis de requisitos+ Concepto o definición x
Clasificación de requisitosFuncionales y no funcionales xDel producto y del proceso xPriorización x
:+ Modelado conceptual+ Diseño arquitectónico+ Negociación de requisitos+ Especificación de requisitos+ Validación de requisitos+ Consideraciones prácticas
Nivel personal Referencia
Códigos: Cn = Conocimiento, Cp = Comprensión, Ap = Aplicación, An = Análisis
Tabla 4.3: Estructura del inventario de conocimientos y experiencia
4.5.3.6 Ejemplos de preguntas de valoración Para ilustrar el procedimiento de formulación de las preguntas de valoración, se
propone el ejemplo de la tabla 4.4 en el cual los “elementos de conocimiento y experiencia”
están tomados del catálogo de conocimientos y experiencia descripto anteriormente.
118
Área de conocimientos Ingeniería de requisitos Sub-área de conocimiento Educción de requisitos Técnica Entrevista Elementos de conocimientos y experiencia
Elección del entrevistado, planificación de la entrevista, interacción con el entrevistado, …
Preguntas Nivel 1: conocimiento – Operación cognitiva: Describir ¿Puede describir las lecciones aprendidas relativas a la planificación de entrevistas? Nivel 2: comprensión – Operación cognitiva: Ejemplificar ¿Puede proporcionar algún ejemplo de situación en la cual utilizaría las lecciones
aprendidas relativas a la elección del entrevistado? Nivel 3: aplicación – Operación cognitiva: Aplicar ¿Ha aplicado anteriormente las mejores prácticas relativas a la interacción con el
entrevistado? Nivel 4: análisis – Operación cognitiva: Elaborar ¿Ha participado anteriormente en la elaboración de las propuestas de mejores
prácticas relativas a la planificación de entrevistas?
Tabla 4.4: Ejemplos de preguntas de valoración
4.5.4 Las Guías de Reflexión
Las guías de reflexión tienen por propósito orientar el análisis y la reflexión por parte
de los miembros de los equipos de proyecto sobre la realización de sus actividades de
proyecto y constituyen la principal herramienta del modelo para dirigir las actividades de
aprendizaje basado en la experiencia y en la creación de conocimientos. Estas guías, tal
como se las propone en el modelo, constituyen un tipo especial de diario de reflexión, e
incluyen una serie de preguntas o de sentencias de reflexión cuyo propósito es motivar y
facilitar las actividades de reflexión personal, dirigiendo la atención de los miembros de los
equipos de proyecto a aquellos aspectos de las tareas de proyecto respecto de las cuales
fueron inicialmente fijados los objetivos de aprendizaje y de creación de nuevos
conocimientos.
4.5.4.1 Tipos de preguntas o sentencias Para la formulación de las preguntas o sentencias de reflexión se propone la utilización
del marco de referencia provisto por la taxonomía de objetivos educacionales de Bloom
[Bloom, B. et al., 1979]. En base a los seis niveles de esta taxonomía, analizados en el
capítulo 2, pueden formularse preguntas o sentencias que pongan en juego diferentes
operaciones cognitivas que pueden ir desde el simple recuerdo de hechos o datos hasta
procesos más complejos de síntesis y evaluación de información.
119
Las preguntas o sentencias que se incluyan en una guía han de estar referidas a las
prácticas, actividades, técnicas o procesos software incluidos en el Catálogo de
conocimientos y experiencia, y respecto de los cuales se formularon los objetivos iniciales
de aprendizaje y de creación de conocimientos.
Las preguntas o sentencias de niveles 1 (conocimiento) y 2 (comprensión) han de
referir a conocimientos que ya posee o que deberían poseer los miembros de los equipos de
proyecto y que deberán poner en juego al momento de llevar a cabo sus actividades de
proyecto. Estos tipos de preguntas o sentencias deben motivar la reflexión para la acción.
Las preguntas de niveles 3 (aplicación) y 4 (análisis) han de referir a la utilización o
aplicación práctica de los conocimientos o de la experiencia previa que posean los
miembros de los equipos de proyecto y que aplican durante la realización de sus actividades
de proyecto. Estos tipos de preguntas o sentencias deben motivar la reflexión en la acción. Las preguntas de niveles 5 (síntesis) y 6 (evaluación) han de referir a sintetizar y
evaluar la experiencia por vivida los miembros de los equipos de proyecto al haber realizado
sus actividades de proyecto. Estos tipos de preguntas o sentencias deben motivar la
reflexión sobre la acción.
4.5.4.2 Formulación de las preguntas de reflexión Para la formulación de las preguntas o sentencias de reflexión se tienen en cuenta tres
elementos:
A) Los conceptos relativos al área de conocimientos, actividad, técnica o proceso
software respecto de los cuales se pretende motivar la reflexión, incluidos en el
Catálogo de conocimientos y experiencia.
B) Los objetivos de aprendizaje y de creación de conocimientos establecidos en la
fase de Iniciación.
C) Los diferentes niveles de la taxonomía de objetivos educacionales de Bloom
[Bloom, B. et al., 1979] para el dominio cognitivo con los correspondientes verbos
que denotan las operaciones cognitivas asociadas a cada nivel.
Para redactar, entonces, las preguntas o sentencias de reflexión de un determinado
nivel de la taxonomía de Bloom se combinan, tal y como se muestra en la figura 4.14, el
concepto al que ha de referir la pregunta o sentencia con el verbo que adecuado para
indicar la operación cognitiva que se pretende motivar.
120
Catálogo de conocimientos y
experiencia
Taxonomía de objetivos
educacionales
Elaborar preguntas de
reflexión
Elementos de conocimientos y experiencia
Niveles de la taxonomía de Bloom
Preguntas de reflexión
Objetivos de aprendizaje y de
creación de conocimientos
Objetivos de aprendizaje y de
nuevos conocimientos Guía de reflexión
Figura 4.14: Formulación de preguntas de reflexión
La cantidad de preguntas a incluir en una guía dependerá de la amplitud y variedad de
los objetivos de aprendizaje y de creación de conocimientos definidos.
4.5.4.3 Ejemplos de preguntas o sentencias de reflexión Para ilustrar el método de formulación de preguntas o sentencias, se propone en la
tabla 4.5 el siguiente ejemplo en el cual los “conceptos asociados” están tomados del
catálogo de conocimientos y experiencia descripto anteriormente.
Area de conocimientos Ingeniería de requisitos Sub-área de conocimiento Educción de requisitos Técnica Entrevista Conceptos asociados Elección del entrevistado, planificación de la entrevista,
conocimiento de la terminología del entrevistado, requisitos funcionales y no funcionales, tipos de preguntas a formular
Preguntas Nivel 1: conocimiento – Operación cognitiva: Listar Confeccione una lista de los pasos a seguir para planificar la entrevista Nivel 2: comprensión – Operación cognitiva: Comparar Compare los diferentes tipos de preguntas que puede preparar para formularle al
entrevistado Nivel 3: aplicación – Operación cognitiva: Seleccionar ¿Qué criterios debe tener en cuenta para seleccionar adecuadamente las personas
a entrevistar? Nivel 4: análisis – Operación cognitiva: Examinar Examinando el desarrollo de la entrevista, ¿qué dificultades o imprevistos encuentra
en su interacción con el entrevistado? Nivel 5: síntesis – Operación cognitiva: Modificar ¿Qué aspectos de la planificación de una entrevista considera que deberá
modificar para una próxima instancia? Nivel 6: evaluación – Operación cognitiva: Juzgar ¿Cómo juzga el proceso seguido en la entrevista en función de la información
obtenida para poder identificar los requisitos funcionales y no funcionales?
Tabla 4.5: Ejemplos de preguntas o sentencias de reflexión
121
4.5.5 El Taller de Educción de Conocimientos y Experiencia
El Taller de educción de conocimientos y experiencia es la instancia de reflexión y
análisis colectivo tendiente a identificar y capturar los conocimientos y la experiencia
adquiridos por los miembros de los equipos de proyecto durante la ejecución de sus
actividades de proyecto. La realización de este taller como parte de las actividades definidas
en el modelo tiene como propósitos:
A) Discutir y analizar las respuestas dadas a las preguntas o sentencias de las guías
de reflexión por parte de los miembros de los equipos de proyecto.
B) Capturar los conocimientos y la experiencia adquiridos durante la realización de las
actividades de proyecto mediante la formulación de lecciones aprendidas y la
generación de propuestas de mejores prácticas.
4.5.5.1 Participantes En el taller participan los miembros de los equipos de proyecto que llevaron a cabo las
tareas de proyecto relativas a las prácticas y procesos software seleccionados en la fase de
Iniciación y respecto de las cuales se definieron los objetivos de creación de conocimientos
y de aprendizaje. También participan del taller los miembros del GGCA que actuarán como
moderadores, propiciando la participación activa de los asistentes y orientando el análisis y
la discusión sobre los temas a tratar.
4.5.5.2 Insumos Uno de los insumos para la realización del taller lo constituyen las respuestas dadas
por los miembros de los equipos de proyecto a las preguntas o sentencias incluidas en sus
guías de reflexión. En base a estas respuestas se elabora un documento que contiene, para
cada pregunta o sentencia, las distintas reflexiones registradas por todos los participantes.
El otro insumo importante para la realización del taller son la experiencia y los
conocimientos tácitos de los participantes, que se buscará hacer explícitos durante el
desarrollo del mismo.
122
Figura 4.15: Educción de conocimientos y experiencia
4.5.5.3 Desarrollo del taller El taller se inicia comunicando a los participantes los objetivos definidos para el
mismo, los temas a tratar y el procedimiento general a seguir. Luego, se distribuye a los
participantes el documento mencionado en el apartado anterior y se da a cada participante
un tiempo para que lea y conozca las respuestas y reflexiones realizadas por los demás.
Concluida esta actividad, se pasa a la etapa de análisis y reflexión colectiva, siguiendo
en orden en que las preguntas de reflexión estaban organizadas en las guías de reflexión.
En esta etapa en donde los participantes relatan y comparten sus experiencias sobre las
actividades de proyecto que realizaron, aportan nuevos elementos y detalles que no fueron
explícitamente incluidos en sus respuestas a las preguntas de reflexión, y donde cada uno
aporta, a su vez, sus puntos de vista, reflexiones y comentarios.
El moderador del taller participa de esta actividad registrando los aportes realizados
por los participantes, orientando la discusión y propiciando la participación de todos.
4.5.5.4 Productos El taller concluye con la redacción de un resumen de los aportes realizados por los
participantes y con la elaboración de las lecciones aprendidas y las propuestas de mejores
prácticas, según se muestra en la figura 4.15.
4.5.6 Repositorio de Lecciones Aprendidas y Mejores Prácticas
El Repositorio de lecciones aprendidas y mejores prácticas es la base de
conocimientos y experiencia que se construye a partir de los conocimientos y experiencias
adquiridos por los miembros de los equipos de proyecto durante la realización de sus
actividades de proyecto, y que fueron educidos y capturados en el Taller de Educción de
conocimientos y experiencia. La estructura organizativa propuesta para este repositorio es
análoga a la del Catálogo de conocimientos y experiencia.
123
Figura 4.16: Integración de conocimientos y experiencia al Repositorio
Las lecciones aprendidas y las mejores prácticas que se incorporen al Repositorio se
asocian a los correspondientes conceptos, actividades y técnicas definidos en el catálogo,
permitiéndose de este modo mantener un vínculo entre estos conocimientos y experiencias
con los objetivos iniciales de aprendizaje y de creación de conocimiento a partir de los
cuales se estructuró el Catálogo. Todo el proceso de integración se muestra en la figura
4.16.
4.6 Conclusiones
En base a la exposición anterior, en la que se presentó y describió la estructura y los
componentes del modelo “ele” para la gestión del conocimiento y del aprendizaje basado en
la experiencia, puede concluirse que el modelo propuesto:
1. sustenta los diferentes proceso para la gestión del conocimiento
2. considera los procesos de conversión y creación de conocimiento organizacional
3. considera los procesos de aprendizaje basado en la experiencia
4. cumple con los objetivos teóricos definidos para la solución propuesta
4.6.1 Sustentación de los proceso de gestión del conocimiento
El modelo propuesto sustenta la gestión del conocimiento pues tiene en
consideración los siguientes procesos de GC que fueron analizados en el capítulo 2:
A) La alineación con la estrategia organizacional, que refiere a establecer los
objetivos de conocimientos estratégicos para la organización. Se realiza en la fase
de Iniciación cuando se establecen las prácticas y procesos software sobre las
124
cuales se va a aplicar el modelo y se definen los objetivos de aprendizaje basado
en la experiencia y de creación de conocimientos.
B) La identificación de conocimientos, que refiere a identificar los activos de
conocimientos de la organización así como también a identificar las brechas entre
los conocimientos que la organización posee y los que debería poseer para
desarrollar su estrategia. Se realizan en la fase de Preparación cuando se
construye o actualiza el Inventario de conocimientos y de experiencia, y cuando se
identifican las brechas de conocimientos entre los que la organización posee y los
que considera necesario poseer para alcanzar los objetivos de aprendizaje y de
creación de conocimientos definidos.
C) La incorporación de conocimientos, que refiere a la adquisición de
conocimientos a partir de fuentes externas así como a la creación o desarrollo de
nuevos conocimientos generados internamente. Se realizan, respectivamente, en
la fase de Familiarización cuando, una vez identificadas las brechas de
conocimiento, se ponen en ejecución los diferentes mecanismos para la
adquisición de conocimientos por parte de los miembros de los equipos de
proyecto, y en la fase de Actuación cuando, al realizar las actividades de
proyecto, se “aprende haciendo” por medio de la experiencia.
D) La preservación del conocimiento, que refiere a las actividades orientadas a
salvaguardar el conocimiento existente en la organización. Se realiza en la fase de
Integración cuando los conocimientos y la experiencia educidos y capturados se
incorporan al Repositorio de lecciones aprendidas y de mejores prácticas.
E) La diseminación del conocimiento, que refiere a distribuir y compartir el
conocimiento. Se realiza en la fase de Familiarización cuando en las actividades
de adquisición de conocimientos se incluye la difusión de las lecciones aprendidas
y las mejores prácticas incorporadas en el Repositorio de lecciones aprendidas y
de mejores prácticas.
F) La utilización del conocimiento, que refiere a aplicar y hacer uso de los nuevos
conocimientos creados o adquiridos. Se realiza en la fase de Actuación cuando
los miembros de los equipos de proyecto aplican las mejores prácticas y utilizan las
lecciones aprendidas capturadas de proyectos anteriores y que están disponibles
en el Repositorio de lecciones aprendidas y de mejores prácticas.
125
4.6.2 Consideración de los procesos de conversión y creación de conocimientos
El modelo contempla los cuatro procesos de conversión de conocimientos según el
modelo de creación de conocimientos de Nonaka y Takeuchi:
A) La socialización, que es el proceso de conversión de conocimiento tácito en
conocimiento tácito. Ocurre en la fase de Actuación cuando los miembros de los
equipos de proyecto tienen la oportunidad de intercambiar ideas, opiniones y
puntos de vista durante la ejecución de las actividades de proyecto.
B) La externalización, que es el proceso de conversión de conocimiento tácito en
conocimiento explícito. Ocurre en la fase de Actuación cuando las personas
reflexionan sobre su práctica y registran esas reflexiones al responder las
preguntas incluidas en las guía de reflexión, y también en la fase de Educción
durante la realización del taller de educción de conocimientos y experiencia
cuando realizan nuevos aportes de conocimientos y experiencias y se elaboran las
lecciones aprendidas y las propuestas de mejores prácticas.
C) La combinación, que es el proceso de conversión de conocimiento explícito en
conocimiento explícito. Ocurre en la fase de Integración cuando los conocimientos
y la experiencia educidos y capturados se incorporan al Repositorio de lecciones
aprendidas y de mejores prácticas. Esta incorporación puede dar lugar a la
reformulación de los conocimientos preexistentes en el repositorio para ajustarlos a
los nuevos conocimientos que se incorporen.
D) La internalización, que es el proceso de conversión de conocimiento explícito en
conocimiento tácito. Ocurre en la fase de Familiarización cuando se llevan a
cabo las actividades de adquisición de conocimientos y también en la fase de
Actuación cuando las lecciones aprendidas y las mejores prácticas son aplicadas
por los miembros de los equipos de proyecto en la ejecución de las actividades de
proyecto.
4.6.3 Consideración de los procesos de aprendizaje experiencial
El modelo contempla las cuatro etapas del ciclo de aprendizaje experiencial según el
modelo de Kolb, etapas que se dan esencialmente en la fase de Actuación:
126
A) La experiencia concreta, que refiere a involucrarse en nuevas experiencias de
aprendizaje. Ocurre cuando los miembros de los equipos llevan a cabo las
actividades de proyecto que les fueron asignadas.
B) La observación reflexiva, que refiere a interpretar y reflexionar sobre las
nuevas experiencias. Ocurre cuando los miembros de los equipos de proyecto
reflexionan en la acción sobre la realización de sus actividades de proyecto y
registran esas reflexiones al responder a las preguntas de las guías de
reflexión.
C) La conceptualización abstracta, que refiere a integrar de manera lógica las
nuevas experiencias a las capacidades personales previas. Ocurre cuando los
miembros de los equipos de proyecto reflexionan sobre la acción de haber
realizado sus actividades de proyecto y registrar también estas nuevas
reflexiones al responder a las preguntas de las guías de reflexión.
D) La experimentación activa, que refiere a aplicar a situaciones nuevas las
capacidades resultantes de la etapa anterior. Ocurre cuando en un nuevo
proyecto o en una nueva instancia de realización de sus actividades de
proyecto, los miembros de los equipos de proyecto ponen en práctica las
lecciones aprendidas y las mejores prácticas capturadas de proyectos
anteriores.
4.6.4 Cumplimiento de los objetivos teóricos de la solución
Finalmente, el modelo propuesto cumple con los cuatro criterios definidos al comienzo,
en el apartado 4.1. Estos criterios fueron derivados de las críticas formuladas en el capítulo
3 a los enfoques existentes sobre gestión del conocimiento y la experiencia en ingeniería de
software que fueron analizados, a su vez, en el capítulo 2.
En efecto:
1. En cuanto a que la solución no sólo debe incorporar elementos relativos al
conocimiento y la experiencia sino, además, establecer de qué manera
gestionarlos, el modelo propuesto define instancias y procedimientos específicos
para la identificación, adquisición, captura, preservación, diseminación y utilización
del conocimiento y la experiencia.
2. En cuanto a que la captura de conocimientos y experiencia pueda realizarse
durante la ejecución de los proyectos y no sólo a partir de proyectos completados,
la solución propuesta incorpora el uso de las guías de reflexión como herramienta
para estos fines.
127
3. En cuanto a que los conocimientos y experiencias a ser capturados y gestionados
estén claramente definidos y delimitados, las preguntas o sentencias que se
incluyan en las guías de reflexión tienen, precisamente, esta finalidad al orientar el
análisis y la reflexión sobre aspectos concretos de las actividades de proyecto de
interés, derivados de objetivos previamente establecidos.
4. Finalmente, en cuanto a que la solución propuesta contenga mecanismos y
herramientas formales para la captura de conocimientos y experiencias, el modelo
propone el uso de las guías de reflexión como herramienta de captura inicial de
conocimientos y experiencias, y la realización de un taller como segunda instancia
de captura y elaboración de esos conocimientos y experiencias.
4.6.5 Diferencias con los modelos de mejora de procesos
Los modelos de mejora de procesos presentados en el capítulo 2 se caracterizan por
proponer o prescribir qué actividades deberían llevarse a cabo en la implementación de una
iniciativa de mejora de procesos software, pero no establecen maneras posibles acerca de
cómo llevar a cabo esas actividades.
El modelo presentado en este capítulo, en cambio, propone actividades y
procedimientos específicos para derivar lecciones aprendidas y mejores prácticas en base a
herramientas y técnicas de gestión del conocimiento y la experiencia.
Tal como se mencionó al comienzo del capítulo, a partir del conjunto de prácticas y
procesos software en uso en la organización se seleccionan aquellas prácticas que la
organización pretende mejorar. Para estas prácticas seleccionadas se define luego un
conjunto de objetivos de mejora que se expresan en las preguntas o sentencias de las guías
de reflexión, y que los miembros de los equipos de proyecto han de responder en base a la
experiencia adquirida al realizar sus tareas de proyecto y haciendo énfasis en aquellos
aspectos que deberían mejorarse.
Con la captura inicial de esta experiencia en las guías de reflexión, la instancia de
análisis y reflexión colectiva que implica el Taller de educción de conocimientos y
experiencia permite identificar y consensuar lecciones aprendidas y generar propuestas de
mejores prácticas que se integran al Repositorio de Lecciones Aprendidas y mejores
Prácticas, y que constituyen la base para incorporar mejoras a las prácticas y procesos
seleccionados al comienzo.
La aplicación del modelo en forma iterativa sobre ese mismo conjunto de prácticas
permite posteriormente evaluar y refinar en forma continua esas lecciones aprendidas y
mejores prácticas que luego pueden ser incorporadas a la especificación del proceso
software.
128
129
5. DEMOSTRACIÓN EMPÍRICA
Para mostrar la viabilidad y utilidad del modelo propuesto se llevó a cabo una
implementación práctica del mismo en el ámbito de una organización de desarrollo software.
El propósito de este capítulo es presentar el estudio de carácter exploratorio-
descriptivo de dicho proceso de implementación. El punto de partida para el estudio fue una
especificación preliminar del modelo propuesto, consistente de los siguientes elementos:
A) Una definición del propósito general del modelo.
B) Una descripción de alto nivel de las fases en las que se estructuró inicialmente el
modelo, junto con una lista inicial de las actividades consideradas necesarias para
implementar cada fase.
Los objetivos definidos para este estudio fueron:
A) Obtener una definición más acabada de los propósitos particulares de cada fase
del modelo, identificar y definir las actividades que deben llevarse a cabo para
implementar cada fase, determinar los insumos requeridos por cada fase, así como
los productos que cada fase debe generar (y que serán insumos de alguna fase
posterior), y definir los criterios de “entrada” o precondiciones para el inicio de cada
fase así como los criterios de “salida” o poscondiciones para darlas por finalizadas.
B) Mostrar que las guías de reflexión constituyen una herramienta eficaz para
capturar los conocimientos y la experiencia que se adquieren durante la ejecución
de las actividades de los proyectos software.
C) Mostrar que el taller de educción de conocimientos y experiencia permite
consensuar las lecciones aprendidas y las propuestas de mejores prácticas
identificadas en las guías de reflexión así como obtener nuevos aportes de
conocimientos y experiencia adquiridos durante la realización de las actividades de
proyecto.
La metodología seleccionada para llevar a cabo la investigación es la del estudio de casos. Yin [Yin, R., 2003] define el estudio de casos como una investigación empírica que
indaga un fenómeno contemporáneo dentro del contexto de su vida real, especialmente
cuando los límites entre el fenómeno y el contexto no son claramente evidentes.
Estas características del estudio de caso contrastan, por ejemplo, con las de los
experimentos, los cuales se realizan cuando el investigador quiere tener el control de la
situación, con una directa, precisa y sistemática manipulación del comportamiento del
130
fenómeno a ser estudiado (Wohlin et al. 2000). En este sentido, y de acuerdo con Sjøberg,
Dyba y Jørgensen (Sjøberg et al., 2007), mientras que un experimento divorcia
deliberadamente el fenómeno de su contexto, el caso de estudio apunta deliberadamente a
cubrir esas condiciones de contexto. Para este estudio, las condiciones de contexto son
particularmente importantes de ser tenidas en cuenta, pues se trata de estudiar la
implementación del modelo propuesto como elemento inserto en las actividades de trabajo
habituales de los miembros de los equipos de proyecto en proyectos de desarrollo software
reales.
Por otra parte, un estudio de carácter estadístico no es aplicable a este caso pues el
enfoque dado al mismo es principalmente cualitativo, y la “población” de proyectos
disponibles al momento de realizar el estudio se limitaba a solo cuatro proyectos que
cumplían con las características deseadas de ser proyectos de desarrollo software y con
clientes reales, según se expone más adelante en este mismo capítulo.
El estudio realizado tiene, tal como se mencionó arriba, características tanto
exploratorias como descriptivas. El carácter descriptivo del estudio se refleja en el hecho
de que se buscará, precisamente, describir el proceso de implementación del modelo,
mientras que su aspecto exploratorio tiene por objetivo examinar la manera en que las
fases y tareas del modelo se insertan en las actividades de los proyectos software, así como
indagar en la utilización de las guías de reflexión y en la dinámica de participación del taller
de educción de conocimientos y experiencia.
El resto del capítulo está organizado de la siguiente manera. En la sección 5.1, se
describen el contexto organizacional donde se llevó a cabo el estudio y los diferentes
actores involucrados en el mismo. En la sección 5.2, se presenta el diseño de la
investigación donde se establece la pregunta de investigación y las proposiciones derivadas
de la misma, se define la unidad de análisis para el estudio y se describen las fuentes de
datos y los instrumentos para su recolección. En la sección 5.3, se describe el proceso
general seguido durante el desarrollo de la investigación, el procedimiento definido para
implementar el modelo, las actividades de elaboración y distribución de las guías de
reflexión, y la preparación y el desarrollo del taller de educción de conocimientos y
experiencia. La sección 5.4, está dedicada a presentar los resultados obtenidos, mientras
que en la sección 5.5 se analizan y discuten estos resultados. Ambas secciones están
organizadas en base a las proposiciones derivadas de la pregunta general de investigación.
Finalmente, en la sección 5.6 se exponen las conclusiones del estudio y en la sección 5.7 su
análisis de validez y fiabilidad.
131
5.1 El contexto general de la investigación
El estudio del proceso de implementación del modelo se llevó a cabo en el marco del
Laboratorio de Ingeniería de Software de la Facultad de Ingeniería de la Universidad ORT
Uruguay. El Laboratorio, denominado ORT Software Factory (ORTsf), es una organización
académica dedicada a la enseñanza de prácticas de Ingeniería de Software, a la mejora de
procesos software, a la transferencia de tecnología a la industria y a la producción de
software. Su sentencia de misión establece que: “El Laboratorio de Ingeniería de Software
es una organización abocada a la formación de profesionales que desarrollen productos que
satisfagan a sus clientes, focalizando la atención en la producción de software de forma
industrial y en proveer tecnología probada al mercado”.
Los proyectos que se llevan a cabo en el ámbito de ORT Software Factory son
proyectos finales de las carreras de Ingeniería en Sistemas y de Licenciatura en Sistemas.
Los planes de estudio de ambas carreras establecen, en relación con estos proyectos, que:
“la carrera culmina con una experiencia de trabajo real, a efectos de que el alumno esté
apoyado por la Universidad en sus primeras experiencias laborales e implica la resolución
de todos los pasos de un proyecto de ingeniería”. Los proyectos referidos son llevados a
cabo por grupos de entre dos y cinco estudiantes del último año de las carreras
mencionadas. El trabajo de cada grupo es apoyado por un tutor de proyecto y cada proyecto
suele tener un cliente “real”, esto es, una empresa u organización externa a la Universidad y
que es la destinataria final del producto del proyecto. Esta característica hace que el trabajo
de los grupos de proyectos se asemeje en buena medida al que puede encontrarse en una
organización de desarrollo de software: varios proyectos de desarrollo en ejecución
simultánea, prácticas de desarrollo quizás no uniformes a través de los diferentes proyectos,
así como plazos, entregables y compromisos diferentes con sus respectivos clientes.
Los diferentes actores involucrados en el estudio se muestran en la figura 5.1,
contextualizados en el marco que proporciona la organización ORTsf:
132
InvestigadorImplementación del Modelo “ele”
GGCA
GGCA: Grupo de Gestión del Conocimiento y del Aprendizaje
GPs: Grupos de proyectos software
GPs
La organización (ORTsf)
GIP
GIP: Grupo de Ingeniería de Procesos
Figura 5.1: Esquema del contexto de la investigación
5.1.1 El Grupo de Gestión del Conocimiento y del Aprendizaje
El Grupo de Gestión del Conocimiento y del Aprendizaje (GGCA) está íntimamente
ligado a todo el proceso de planificación y ejecución del modelo, tal como se expuso en el
capítulo anterior. En el marco de este estudio, el GGCA fue el responsable de definir,
supervisar y apoyar las actividades de gestión del conocimiento y del aprendizaje en el
ámbito de la organización ORTsf y acerca de las prácticas y actividades de los grupos de
proyectos.
5.1.2 Los Grupos de Proyectos Software
Tal como se estableció en el capítulo 4, el propósito del Modelo “ele” es orientar las
actividades de GC y del aprendizaje basado en la experiencia durante la ejecución de
proyectos de desarrollo software. En consecuencia, para llevar a cabo el estudio, era
necesario contar con grupos de proyectos cuyos conocimientos, experiencias y aprendizajes
gestionar.
Como se detallará más adelante, en este mismo capítulo, fueron cuatro los proyectos
seleccionados para participar del trabajo de investigación.
Es importante resaltar que estos grupos de proyectos no fueron concebidos
específicamente con el propósito de la investigación en sí, sino que los mismos tenían “su
propia agenda”; esto es, su principal foco de esfuerzo y de trabajo era cumplir con las
metas, plazos y entregables acordados con sus respectivos clientes.
133
5.1.3 El Grupo de Ingeniería de Procesos
El Grupo de Ingeniería de Procesos (GIP) es una unidad dentro de ORTsf cuyos
objetivos son auditar, medir y mejorar la arquitectura del proceso de desarrollo de software,
de forma de obtener un producto de calidad con un proceso eficiente y efectivo. Este grupo
está conformado por dos miembros del Laboratorio de Ingeniería de Software. La
participación de este grupo en el estudio estuvo vinculada a proporcionar la información
preliminar necesaria para seleccionar las prácticas del proceso software sobre las cuales
realizar la implementación el modelo y que permitieron delimitar el alcance de la misma.
5.2 El diseño de la investigación
Yin [Yin, R., 2003] ha identificado los siguientes componentes del diseño de una
investigación que son importantes para el estudio de casos:
1. Las preguntas de investigación.
2. Sus proposiciones.
3. La unidad de análisis.
4. La lógica que enlaza los datos con las proposiciones.
5. Los criterios para interpretar los datos.
6. La base de datos de caso de estudio.
5.2.1 Preguntas de investigación
Para iniciar la planificación de una investigación, Creswell [Creswell, J., 1994] propone
la formulación de una pregunta de tipo “grand tour”, que es una sentencia de la cuestión a
examinar en el estudio, formulada en su forma más general. Para este estudio se definió,
entonces, la siguiente pregunta general de investigación:
¿Cómo incorporar a las prácticas y procesos de desarrollo software de una
organización, procedimientos y artefactos específicos para orientar y gestionar el
conocimiento y el aprendizaje basado en la experiencia que se adquiere en el
marco de los proyectos de desarrollo software?
5.2.2 Proposiciones
Siguiendo a Creswell [Creswell, J., 1994], esta pregunta general es seguida de varias
sub-preguntas o proposiciones que delimitan el enfoque del estudio y que constituirán
134
tópicos específicamente explorados en entrevistas, cuestionarios, observaciones y
materiales documentales. Las proposiciones definidas para el estudio son las siguientes:
1. Cuáles son las actividades a llevarse a cabo en cada una de las fases del modelo,
cuáles son los insumos requeridos por cada fase y los productos que cada fase
debe generar, que criterios pueden definirse como de “entrada” o precondiciones
para el inicio de cada fase y que criterios pueden definirse como de “salida” o
poscondiciones para darla por finalizada.
2. Las guías de reflexión constituyen una herramienta eficaz para realizar una captura
primaria de los conocimientos y experiencia que se adquieren durante la ejecución
de las tareas de proyecto.
3. Responder a las preguntas o sentencias de reflexión tiene una baja incidencia
respecto al tiempo total del proyecto.
4. Qué valoración dan los miembros de los grupos de proyecto a las guías de
reflexión.
5. El taller de educción de conocimientos y experiencia permite consensuar las
lecciones aprendidas y las propuestas de mejores prácticas identificadas en las
guías de reflexión, así como obtener nuevos aportes de conocimientos y
experiencia adquiridos durante la realización de las actividades de proyecto.
6. Qué valoración dan los miembros de los grupos de proyecto al taller de educción
de conocimientos y experiencias.
5.2.3 La unidad de análisis
Para Yin [Yin, R., 2003], en el estudio de casos, la unidad de análisis puede ser un
individuo o grupo de individuos, pero también un caso puede estar enfocado en el estudio de
la economía de un país, una industria o una política económica, así como también la
evaluación de un programa, una iniciativa de cambio organizacional o la implementación de
un determinado proceso.
Para Patton [Patton, M., 2002], el elemento clave en la selección de la unidad de análisis apropiada es decidir “acerca de qué cosa se quiere ser capaz de decir algo al
finalizar el estudio”.
Para este estudio, la unidad de análisis seleccionada es el proceso de implementación del Modelo “ele”, dentro de la cual se definieron dos subunidades de
análisis: las guías de reflexión y el taller de educción de conocimientos y experiencia.
135
Las seis proposiciones definidas en el apartado anterior están relacionadas con la
unidad de análisis y las dos subunidades, de la manera en que se muestra en la tabla 5.1.
Unidad o subunidad de análisis Proposiciones Proceso de implementación del modelo 1 Guías de reflexión 2, 3, 4 Taller de educción de conocimientos y experiencia 5, 6
Tabla 5.1: Relación de proposiciones a unidad y subunidades de análisis
5.2.3.1 Delimitación del alcance de la implementación Inserto este estudio en el ámbito de la organización ORTsf, se entendió adecuado,
para los fines del mismo, circunscribir la implementación del modelo a aquellas prácticas de
IS que, históricamente, suelen presentar deficiencias en su realización por parte de los
grupos de proyectos.
Para determinar cuales son estas prácticas se solicitó al Grupo de Ingeniería de
Procesos (GIP) de ORTsf los denominados Informes de Revisión relativos a grupos de
proyectos de períodos anteriores.
Los Informes de Revisión son documentos elaborados por los miembros del GIP en
ocasión de las instancias de revisión periódicas que, durante el desarrollo de los proyectos,
se realizan a los grupos de proyectos.
En estas revisiones, cada grupo de proyecto presenta los avances en su proyecto,
junto con una descripción de las actividades de IS realizadas hasta el momento de la
instancia de revisión.
En base a estas presentaciones, el miembro revisor señala las fortalezas del trabajo
realizado por el grupo, así como las debilidades u “oportunidades de mejora” que el grupo
debe tener en cuenta en el futuro. Finalizada la revisión, el miembro revisor elabora el
correspondiente Informe de Revisión donde se da cuenta, precisamente, de las fortalezas y
debilidades encontradas.
La organización ORTsf proveyó al autor de los informes de revisión de trece grupos de
proyecto de períodos anteriores, abarcando los años 2004 a 2006.
Para analizar estos informes y categorizar las oportunidades de mejora incluidas en
los mismos, se procedió a clasificarlas en base a la taxonomía de áreas de conocimiento de
ingeniería de software propuesta en la Guide to the Software Engineering Body of
Knowledge (SWEBOK) [Abran, A. et al., 2004]. A partir de esta clasificación, se elaboró una
planilla para determinar la frecuencia de “oportunidades de mejora” para cada área de
conocimientos del SWEBOK y sus respectivas sub-áreas. Los informes de revisión y la
planilla de frecuencia se encuentran en el Anexo 3.
136
La tabla 5.2 muestra, en forma resumida, los datos de la planilla mencionada,
totalizando la cantidad de oportunidades de mejora por área de conocimiento:
Area de conocimientos TotalRequisitos Software 13Diseño del software 2Construcción del software ‐‐‐Prueba del software 3Gestión de Ingenieria Software 16Proceso de Ingeniería Software 4Mantenimiento del Software ‐‐‐Gestión de Configuración 3Herramientas y Métodos ‐‐‐Calidad del software 6
Tabla 5.2: Datos de la planilla de oportunidades de mejora
Como puede observarse en la tabla precedente, las áreas Requisitos Software y
Gestión de IS son las que, históricamente, presentan mayor cantidad de indicaciones de
“oportunidades de mejora”. En función de estos hallazgos, se convino con el Grupo de
Ingeniería de Procesos de ORTsf llevar a cabo la implementación del modelo para los
siguientes aspectos de estas dos áreas:
A) Ingeniería de Requisitos
a. Planificación de entrevistas para educción de requisitos
b. Interacción con el usuario durante la entrevista
c. Habilidades personales del ingeniero de requisitos
d. Clasificación de requisitos en “funcionales” y “no funcionales”
B) Gestión de Ingeniería de Software
a. Definición de las métricas de gestión de proyecto a recolectar
5.2.3.2 Elección de los informantes claves Para este estudio se consideraron los siguientes dos grupos de informantes claves:
A) El Grupo de Gestión del Conocimiento y el Aprendizaje Este grupo estuvo conformado por el autor, en su carácter de observador participante
(término que se explica más adelante), y por dos estudiantes del último semestre de la
carrera de Licenciatura en Sistemas.
137
B) Los grupos de proyectos Tal como se mencionó al comienzo, los proyectos que se desarrollan en el ámbito de
ORTsf son proyectos finales de las carreras de Ingeniería de Sistemas y de Licenciatura en
Sistemas. Los proyectos de Ingeniería de Sistemas tienen una duración de un año e inician
en el mes de Abril de cada año, mientras que los proyectos de Licenciatura en Sistemas
tienen una duración de seis meses e inician en los meses de Abril y Octubre. De los nueve
proyectos disponibles al momento de planificar e iniciar este estudio (abril de 2007), se
seleccionaron los que se muestran en la tabla 5.3:
Id. Nombre del proyecto Código IntegrantesGP 1 Sistema de gestión de acreditaciones GESA 3 GP 2 Software de gestión para COODESOR COODESOR 4 GP 3 Seguimiento y control de proyectos de
inversión SCPI 5
GP 4 Portal de inversiones InvPortal 3 Tabla 5.3: Proyectos seleccionados para el estudio
En la selección de estos proyectos se tuvieron en cuenta los siguientes criterios:
A) Son proyectos específicamente de desarrollo de software.
B) Tienen un cliente “real” externo a la organización ORTsf, de modo que el principal
compromiso del grupo de proyecto es con el cliente y no con esta investigación.
C) Deben realizar en forma completa las actividades correspondientes a las áreas de
conocimientos Requisitos Software y Gestión de IS (según están definidas en el
SWEBOK [Abran, A. et al., 2004]).
5.2.4 Lógica que enlaza los datos con las proposiciones
Este componente del diseño refiere a establecer qué datos se consideran necesarios
recolectar durante el proceso de investigación de modo de poder dar respuesta a las
proposiciones iniciales, y cuales son los instrumentos a utilizar para su recolección.
En la tabla 5.4 se muestran, para cada proposición, la fuente de datos y el o los
instrumentos de recolección de datos a utilizar.
138
Proposición Fuentes de datos e instrumentos de recolección 1 Documentos elaborados por el GGCA. Observación participante en el GGCA 2 Guías de reflexión completadas por los miembros de los grupos de proyectos
3 Documentos propios de los grupos de proyectos Guías de reflexión completadas por los miembros de los grupos de proyectos
4 Cuestionario a los miembros de los grupos de proyecto
5 Documento de resultados del Taller de educción de conocimientos y experiencia Observación participante en el GGCA
6 Cuestionario a los miembros de los grupos de proyecto
Tabla 5.4: Proposiciones con sus fuentes de datos e instrumentos de recolección
Los instrumentos de recolección de datos utilizados en este estudio son los siguientes:
A) Observación participante.
B) Documentos.
C) Cuestionarios.
5.2.4.1 Observación participante Para Yin [Yin, R., 2003], la observación participante es un modo especial de
observación en el cual el investigador no es un mero observador pasivo sino que, por el
contrario, puede asumir una variedad de roles dentro de una situación del caso de estudio y
puede efectivamente participar en los eventos que están siendo estudiados. En este estudio,
el autor trabajó de manera integrada al GGCA, participando en las siguientes actividades:
A) Definiendo del propósito general del Modelo “ele” y de los propósitos y objetivos
particulares de cada fase.
B) Elaborando la planificación general del proceso de implementación del modelo.
C) Facilitando los contactos personales con los integrantes de la organización ORTsf
y con los miembros de los grupos de proyectos.
D) Proporcionando a los otros miembros del GGCA información de contexto respecto
a los conceptos más relevantes relativos a la gestión del conocimiento, el modelo
de aprendizaje experiencial de Kolb, la taxonomía de objetivos educacionales de
Bloom y la práctica reflexiva de Schon.
5.2.4.2 Documentos Los documentos que se utilizarán en este estudio son los siguientes:
A) Elaborados por el GGCA relativos al proceso de implementación del modelo.
B) Propios de los grupos de proyectos participantes.
C) Guías de reflexión completadas por los miembros de los equipos de proyectos
participantes.
D) De resultados del Taller de educción de conocimientos y experiencia.
139
Otros documentos a utilizar los constituyen las notas y registros de observación
participante y los reportes de las reuniones de trabajo junto a los otros miembros del GGCA.
5.2.4.3 Cuestionarios Los cuestionarios utilizados en este estudio apuntan a medir la actitud de los
miembros de los grupos de proyectos en relación con dos herramientas claves del modelo:
las Guías de Reflexión y el Taller de Educción de Conocimientos y Experiencia.
En este estudio se utilizarán, entonces, dos cuestionarios: el cuestionario de
Evaluación de las Guías de Reflexión y el cuestionario de Evaluación del Taller de Educción
de Conocimientos y Experiencia.
Las preguntas incluidas en ambos cuestionarios son de tipo cerrado con respuesta a
escala en forma de valores borrosos, presentadas a modo de afirmaciones. Las respuestas
posibles son: Muy en desacuerdo, En desacuerdo, Indiferente, De acuerdo, Muy de acuerdo.
Cuestionario de Evaluación de las Guías de reflexión Las preguntas de este cuestionario apuntarán a medir la actitud de los participantes en
relación con los siguientes aspectos de las Guías de Reflexión:
A) Momento de disponibilidad de la guía (pregunta 1).
B) Origen de las respuestas (pregunta 2).
C) Efecto personal de las reflexiones (preguntas 3 a 5).
D) Utilidad de la guía (pregunta 6).
Las preguntas incluidas en el cuestionario fueron las siguientes:
1. La lectura de la Guía de Reflexión en forma previa a la realización de mis tareas de
proyecto me hubiera permitido prepararme mejor para llevar a cabo esas tareas.
2. La respuesta dada a cada pregunta estuvo directamente vinculada a mi
experiencia personal adquirida en el proyecto.
3. Las preguntas me instaron a reflexionar detenidamente las respuestas a dar a las
mismas.
4. Haber reflexionado y respondido a las preguntas me permitió identificar “brechas”
en mis conocimientos relativos a los temas abordados en las mismas.
5. Haber reflexionado y respondido a las preguntas me permitió identificar aspectos
de mi actuación en el proyecto que considero deberé mejorar en una próxima
instancia.
6. En general, considero a las Guías de Reflexión como un instrumento útil para
facilitar la reflexión sobre mis conocimientos y mi actuación profesional.
140
Cuestionario de Evaluación del Taller de Educción de Conocimientos y Experiencia
Las preguntas de este cuestionario apuntarán a medir la actitud de los participantes en
relación con los siguientes aspectos del Taller:
A) Organización del taller (preguntas 1 a 4).
B) Participación personal (preguntas 5 a 8).
C) Contenido del taller (pregunta 9).
Las preguntas incluidas en el cuestionario fueron las siguientes:
1. Los objetivos del taller estuvieron claramente definidos.
2. La duración del taller fue adecuada.
3. El material recibido como insumo para la realización del taller fue satisfactorio en
cuanto a su estructura y contenido.
4. El lugar físico elegido para realizar el taller fue adecuado.
5. Valoro como muy positivo el haber podido conocer y discutir, durante el taller, las
experiencias de los otros participantes.
6. Con la participación en el taller considero que he aumentado mis conocimientos
sobre los temas tratados en el mismo.
7. Los conocimientos adquiridos en el taller me permitirán realizar un mejor
desempeño en proyectos futuros.
8. En general, considero que el taller fue una experiencia positiva.
9. De los cuatro temas tratados en el taller, el o los más interesantes fueron … (incluir
aquí los temas que se definan para el Taller)
5.2.5 Criterios para analizar los datos
Los datos a recolectar durante el estudio serán tanto de tipo cualitativo como de tipo
cuantitativo.
5.2.5.1 Datos cualitativos
Los datos cualitativos a recolectar provendrán esencialmente de los documentos que
el GGCA elabore durante el proceso de implementación del modelo, así como de las notas
de campo (también considerados como “documentos”) que se registren durante las sesiones
de observación participativa.
También serán de tipo cualitativo las respuestas que los miembros de los grupos de
proyecto den a las preguntas o sentencias de reflexión que se incluyan en las guías de
reflexión y los resultados que se obtengan a partir de la realización del Taller de educción de
conocimientos y experiencia.
141
Para el análisis de estos datos se procederá a la lectura analítica de estos
documentos, buscando extraer de los mismos aquellos elementos que aporten a responder
a las proposiciones de investigación.
5.2.5.1 Datos cuantitativos
Los datos cuantitativos a recolectar provendrán de las respuestas a los cuestionarios
a administrar a los miembros de los grupos de proyecto.
Para Blaxter, Hughes y Tight [Blaxter, L. et al., 2000] los estudios de investigación en
pequeña escala que recolectan datos por medio de cuestionarios no necesitan ir más allá de
la estadística descriptiva y, eventualmente, de la exploración de las interrelaciones entre
pares de variables. Para analizar estos datos se procederá entonces a tabularlos,
clasificando y contabilizando las respuestas en base a los cinco valores de las escalas de
respuestas posibles.
También se obtendrán datos cuantitativos de las guías de reflexión completadas por
los miembros de los grupos de proyectos y de los registros propios de los grupos de
proyectos en relación con los tiempos insumidos en la ejecución de sus actividades de
proyecto.
De las guías de reflexión se obtendrán los tiempos que los respondientes insumieron
en responder a las preguntas o sentencias de reflexión, y de los registros propios de los
grupos de proyectos se obtendrán los tiempos dedicados a las actividades de
gerenciamiento de los proyectos y de ingeniería de requisitos, así como los tiempos totales
de los proyectos.
Para analizar estos datos se procederá a realizar, para cada grupo de proyecto, las
siguientes comparaciones:
A) Tiempo total para responder a las guías de reflexión respecto al tiempo total del
proyecto.
B) Tiempo dedicado a responder las guías de reflexión para ingeniería de requisitos
respecto al tiempo de proyecto para las actividades de ingeniería de requisitos.
C) Tiempo dedicado a responder las guías de reflexión para métricas de gestión de
proyectos respecto al tiempo de proyecto para las actividades de gerencia.
5.2.6 La base de datos del caso de estudio
La base de datos del estudio está conformada por las siguientes clases de
documentos e información:
142
A) Documentos propios de la organización ORTsf.
B) Procedimientos de implementación del modelo, elaborados durante el desarrollo
del estudio.
C) Guías de reflexión completadas por los miembros de los equipos de proyectos.
D) Cuestionarios administrados a los miembros de los equipos de proyectos.
E) Resúmenes de reuniones con el GGCA.
Toda la información y la documentación de la base de datos de este estudio se
encuentran en el Apéndice 3.
5.3 Desarrollo general de la investigación
Tal como se expuso al comienzo, el punto de partida del trabajo de investigación
consistió en aportar al GGCA una versión preliminar del modelo “ele” que incluyó la
siguiente información:
A) Propósito general del modelo.
B) Una descripción de alto nivel de las fases en las que inicialmente se estructuró el
modelo junto con la propuesta inicial de actividades a realizar en cada una de las
fases.
5.3.1 Reuniones de trabajo en el GGCA
El trabajo de planificación e implementación del modelo se desarrollo desde Abril a
Setiembre de 2007, coincidiendo con el tiempo de duración de los proyectos de desarrollo
software seleccionados para el estudio.
A lo largo de este lapso, el autor (en calidad de observador participante) y los otros
miembros del GGCA mantuvieron reuniones periódicas de trabajo en las cuales se fueron
definiendo en detalle e implementando las diferentes actividades correspondientes a cada
fase del modelo.
Estas reuniones permitieron al autor ir obteniendo información de primera mano
acerca de las decisiones de implementación que se fueron tomando en forma conjunta, así
como de las dificultades que se iban encontrando y las maneras en que las mismas fueron
superadas.
El reporte de estas reuniones, que incluyen los temas tratados y las decisiones
tomadas en cada una, se encuentran en el Apéndice 3 (Base de datos del estudio).
143
5.3.2 Cronograma de actividades
Dadas las características del presente estudio, las actividades propias de la
investigación ocurrieron en forma simultánea con el desarrollo del fenómeno bajo estudio,
esto es, con el proceso de implementación del modelo.
Por ejemplo, las actividades de elaboración de las guías de reflexión, así como el
análisis de las respuestas obtenidas en las mismas son actividades tanto de implementación
de modelo como del proceso de recolección de datos.
Por otra parte, la distribución de los cuestionarios de evaluación, tanto de las guías de
reflexión como del taller de educción de conocimientos y experiencia, si bien son actividades
propias del estudio del caso, las mismas también se llevaron a cabo durante el proceso de
implementación bajo estudio.
En el cronograma que se da en la figura 5.2 se muestran los principales eventos
realizados a lo largo del período que ocupó el estudio.
IniciaciónSeleccionar prácticasDefinir objetivos de aprendizajeSeleccionar proyectos
PreparaciónCapacitación del GGCA
Elaborar guías de reflexión para Ing. Req.
Elaborar guías de reflexión para Métricas
Asignar guías de reflexión
FamiliarizaciónPreparar sesiones de familiarización
Realizar reuniones de familiarización
ActuaciónResponder guías de reflexión para Ing. Req.
Responder guías de reflexión para Métricas
Analizar respuestas
ElicitaciónPreparar taller
Realizar taller
Identificar L.A. y M.P.
IntegraciónDefinir estructura del repositorio
Integrar L.A. y M.P. al repositorio
RevisiónRevisión del proceso y de los productos
Conclusión
OctubreAbr. Mayo Junio Julio Agosto Setiembre
Figura 5.2: Cronograma de actividades
144
5.3.3 Proceso de implementación del modelo
El hilo conductor del proceso de implementación del modelo fue el orden de fases en
que inicialmente se estructuró el mismo. En términos generales, el proceso de
implementación se realizó siguiendo un ciclo Definir – Implementar, de la siguiente manera:
A) Definir: etapa que refiere a definir QUÉ hacer en cada fase; esto es:
a) Definir una lista de tareas conducentes al logro del propósito establecido para la
fase.
b) Establecer un orden de precedencia para esas tareas.
c) Definir los insumos y productos en función del orden de precedencia de las tareas.
d) Definir las precondiciones y las poscondiciones, en función tanto del orden de
precedencia de las tareas como de los insumos y productos definidos.
e) Establecer el cronograma de implementación.
B) Implementar: etapa que refiere a establecer CÓMO llevar a cabo las tareas definidas
previamente:
a) Documentar la manera que se van a implementar las tareas definidas.
b) Determinar qué personas van a estar involucradas en cada tarea y en qué
momento deben ser contactadas.
c) Elaborar los insumos definidos para cada tarea.
d) Llevar a cabo las tareas en el orden establecido.
e) Generar los productos definidos para cada tarea.
Este ciclo Definir – Implementar se repetía al interior de cada fase así como al
momento de finalizar una fase y pasar a la siguiente, de modo de ir evaluando de manera
continua los siguientes aspectos:
A) Si resultaba necesario o conveniente realizar una tarea antes o después de otra.
B) Si una tarea era muy compleja y convenía separarla en dos.
C) Si era necesario que el producto de una tarea estuviera disponible antes.
D) Si un insumo podía efectivamente obtenerse en forma previa a la ejecución de la
tarea que lo requiriera.
E) Si el producto generado por una tarea era adecuado como insumo a ser utilizado
por otra.
F) Si las precondiciones de una tarea podían cumplirse antes de dar inicio a la
misma.
145
En conjunto, las actividades anteriores permitieron ir construyendo y ajustando la
especificación del modelo en base a su puesta en práctica y a los comentarios recibidos de
los participantes involucrados en las diferentes tareas.
En los siguientes sub-apartados se detallan las actividades realizadas en la
implementación de cada fase del modelo.
5.3.3.1 Iniciación En la implementación de esta fase se llevaron a cabo las siguientes actividades:
a) Conformar el GGCA: este grupo estuvo integrado por dos estudiantes de grado de
la Licenciatura en Sistemas y por el autor, según se indicó en el apartado 5.2.3.2.
b) Seleccionar prácticas y procesos sobre los que aplicar el modelo: La selección
de estas prácticas y procesos se llevó a cabo a partir del análisis de datos históricos
de ORTsf relativos a las evaluaciones de la actuación de los grupos de proyectos de
generaciones anteriores, según se ha descripto en el apartado 5.2.3.1.
c) Definición de objetivos de aprendizaje y de nuevos conocimientos: Según se
expuso en el apartado 5.2.3.1, de las diferentes actividades de Ingeniería de
Requisitos, se convino con el Grupo de Ingeniería de Procesos de ORTsf hacer
énfasis en los siguientes aspectos a mejorar: planificación de entrevistas, interacción
con los usuarios en las entrevistas, habilidades personales del ingeniero de
requisitos y clasificación de requisitos en funcionales y no funcionales. Con respecto
al área de Gestión de Proyectos, el aspecto a considerar fue la definición de las
métricas de gestión de proyectos a recolectar.
d) Iniciar proceso de gestión de conocimientos y aprendizajes: Luego de
seleccionados los grupos de proyectos en base a los criterios expuestos en 5.2.3.2,
se llevó a cabo una reunión con los miembros de los equipos de proyecto en la que
se les propuso participar de la investigación y se les informó de los objetivos y del
proceso general a seguir.
5.3.3.2 Preparación En la implementación de esta fase se llevaron a cabo las siguientes actividades:
a) Elaborar el catálogo de conocimientos y experiencia: consistió en definir las
palabras claves que denotan conceptos, actividades y técnicas relativos a las
prácticas y procesos software seleccionados en la fase anterior. Para ello se utilizó
como base el SWEBOK y bibliografía general sobre ingeniería de software, tales
como [Pressman, R., 2005] y [Sommerville, I., 2005], entre otros.
146
b) Elaborar las guías de reflexión: consistió en definir la cantidad y el tipo de
preguntas o sentencias de reflexión a incluir en las mismas, así como en determinar
a qué aspectos de las prácticas seleccionadas iban a estar enfocadas las preguntas
o sentencias de reflexión. El procedimiento seguido se expone en el apartado 5.3.4.
c) Asignar guías de reflexión: consistió en determinar a cuales miembros de los
equipos de proyectos se les entregarán las guías para su uso durante la ejecución de
los proyectos, en función de los roles a desempeñar en sus respectivos proyectos.
d) Elaborar inventario de conocimientos y experiencia: esta tarea no se llevó a
cabo en esta implementación del modelo en virtud de que todos los miembros de los
equipos de proyectos son alumnos de grado que ya han cursado y aprobado las
asignaturas de Ingeniería de Requisitos y de Gestión de Proyectos.
e) Identificar brechas de conocimiento: esta tarea tampoco se llevó a cabo por las
mismas razones por las que no se realizó la tarea anterior.
f) Definir plan de adquisición de conocimientos iniciales: a los efectos de
uniformizar el nivel de conocimientos de los miembros de los equipos de proyecto
sobre las prácticas de ingeniería de software seleccionadas para implementar el
modelo, se planificaron dos cursos cortos sobre Ingeniería de Requisitos y sobre
Gestión de Proyectos en los que se hizo énfasis en los aspectos específicos a los
que refieren las guías de reflexión.
5.3.3.3 Familiarización En la implementación de esta fase se llevaron a cabo las siguientes actividades:
a) Analizar y comprender las guías de reflexión: para implementar esta tarea se
llevaron a cabo reuniones con los ingenieros de requisitos y con los gerentes de
proyectos de los grupos de proyecto participantes con los propósitos de entregarles
las guías de reflexión correspondientes a cada rol, comentar y discutir el propósito,
contenido y alcance de cada guía, y explicar la manera en que se espera que utilicen
las guías durante el período en que deben realizar sus respectivas actividades de
proyecto.
b) Adquirir conocimientos básicos: esta tarea se implementó en base a los dos
cursos cortos mencionados arriba y que versaron sobre los aspectos de ingeniería
de requisitos y de definición de métricas de proyecto que son los temas centrales de
las guías de reflexión. Estos cursos se impartieron en forma previa a que los
miembros de los equipos de proyecto iniciaran sus propias actividades de proyecto.
147
5.3.3.4 Actuación En la implementación de esta fase se llevaron a cabo las siguientes actividades:
a) Responder preguntas de las guías de reflexión: tanto los ingenieros de requisitos
como los gerentes de proyecto llevaron a cabo esta tarea durante el período de
realización de sus actividades de proyecto. En base a la orientación proporcionada
por las diferentes preguntas o sentencias de reflexión y a la experiencia de estar
realizando sus actividades de proyecto, fueron redactando las respuestas a cada
pregunta exponiendo sus reflexiones e impresiones personales.
b) Revisar completitud de las respuestas: A medida que cada miembro de los
equipos de proyecto devolvía su guía de reflexión, se verificaba que las preguntas
hubiesen sido respondidas y que se hubiese indicado también la cantidad de tiempo
dedicado a redactar cada respuesta.
5.3.3.5 Educción Las tres tareas de esta fase, a) Educir nuevos conocimientos y aprendizajes, b)
Sintetizar las lecciones aprendidas y c) Elaborar propuestas de mejores prácticas, se
implementaron en el Taller de educción de conocimientos y experiencia, cuya preparación,
desarrollo y resultados se describen en el apartado 5.3.5.
5.3.3.6 Integración Las dos tareas definidas para esta fase, a) Incorporar lecciones aprendidas al repositorio, y b) Integrar mejores prácticas al repositorio, se llevaron a cabo en forma
simultánea. Para esta primera ejecución del modelo, el Repositorio de lecciones aprendidas
y mejores prácticas se implementó utilizando una carpeta en el sistema de archivos del
servidor central de ORTsf, con una serie de sub-carpetas organizadas según las áreas y
sub-áreas de conocimiento del SWEBOK. Las lecciones aprendidas y las propuestas de
mejores prácticas elaboradas en la fase anterior se incorporaron a esta estructura del
repositorio en las sub-carpetas correspondientes a los temas a los que refieren las mismas.
5.3.3.7 Revisión En la implementación de esta fase se llevaron a cabo las siguientes actividades:
a) Evaluar el proceso seguido y los productos generados: consistió en analizar y
evaluar la preparación y ejecución de las tareas realizadas en las fases anteriores,
así como en analizar los productos resultantes de esas tareas. Este análisis permitió
identificar una serie de oportunidades de mejora a aplicar en futuras
implementaciones del modelo, que se describen en el apartado 5.4.1.
148
b) Identifica desvíos respecto a objetivos de aprendizaje: consistió en evaluar si las
lecciones aprendidas y las propuestas de mejores prácticas derivadas del Taller de
educción de conocimientos y experiencias, e incorporadas al repositorio, permitirán
ser reutilizadas en proyectos futuros como forma de mejorar la manera de llevar a
cabo las actividades de ingeniería de requisitos y de definición de métricas de
gestión de proyectos. Esta evaluación se llevó a cabo con la participación de los
miembros del grupo de ingeniería de procesos de ORTsf, como representantes de la
organización.
c) Decidir si es necesaria una nueva iteración: A partir del análisis y evaluación
realizados en la tarea anterior, se consideró que es necesaria una nueva iteración en
los aspectos relacionados con la definición de métricas de gestión de proyectos,
mientras que en lo relativo a los objetivos de ingeniería de requisitos se consideró
que es necesario poner en práctica los resultados obtenidos en los próximos
proyectos que se lleven a cabo en el marco de ORTsf.
5.3.4 Las guías de reflexión
Tal como fueron definidas en el capítulo anterior, las guías de reflexión son un tipo
especial de diario de reflexión cuyo propósito es orientar el análisis y la reflexión por parte
de los miembros de los equipos de proyecto sobre la realización de sus actividades de
proyecto.
En base a las actividades de IS definidas inicialmente para implementar el modelo, se
elaboraron dos guías de reflexión: una para ingeniería de requisitos y la otra para métricas
de gestión de proyectos.
5.3.4.1 Elaboración de las guías La guía de reflexión para Ingeniería de Requisitos contiene nueve preguntas o
sentencias de reflexión relativas a la planificación de entrevistas de educción de requisitos,
interacción con el usuario durante las entrevistas y clasificación de requisitos en
“funcionales” y “no funcionales”.
En relación con los niveles de la taxonomía de Bloom utilizados para definir los tipos
de preguntas, se incluyeron, en esta guía, una pregunta de Aplicación, dos de Análisis,
cuatro de Evaluación y dos de Síntesis.
Por su parte, la guía de reflexión para Gestión de Ingeniería Software contiene ocho
preguntas relativas a la definición y recolección de métricas de gestión de proyectos.
En relación con los niveles de la taxonomía de Bloom, se incluyeron en esta guía una
pregunta de Aplicación, una de Análisis, cuatro de Evaluación y dos de Síntesis.
149
En ambas guías se incluyó, a solicitud del Grupo de Ingeniería de Procesos de ORTsf,
una pregunta relativa a las características que debería tener el entrenamiento inicial a
proporcionar a los miembros de los grupos de proyecto que desempeñen los roles de
ingeniero de requisitos y de gerente de proyecto.
También en cada guía se incluyó, para cada pregunta o sentencia de reflexión, un
campo donde el respondiente debe indicar el tiempo dedicado a responderla.
5.3.4.2 Distribución de las guías Una vez que la elaboración de las Guías de Reflexión estuvo finalizada, las mismas
fueron entregadas a los miembros de los grupos de proyectos que cumplían los roles de
Ingeniero de Requisitos y de Gerente de Proyecto. Para esta entrega se coordinaron
reuniones en las que participaron los miembros del GGCA y los Gerentes de Proyecto e
Ingenieros de Requisitos de los cuatros grupos de proyectos seleccionados para el estudio.
Estas reuniones tuvieron por objetivos:
A) Informar a los asistentes acerca del propósito de la investigación y el rol que van a
cumplir en la misma.
B) Presentar de manera general el propósito y la estructura del modelo “ele”.
C) Explicar los objetivos y los contenidos de las Guías de Reflexión.
D) Entregar las guías a los ingenieros de requisitos y a los gerentes de proyecto de
los grupos de proyectos.
E) Solicitar la devolución de las guías completadas en el plazo acordado.
Estas reuniones resultaron muy beneficiosas puesto que se logró despertar el interés
de los asistentes en el modelo en general y en las guías de reflexión en particular, así como
obtener el compromiso de los ingenieros de requisitos y de los gerentes de proyecto en
cuanto a responder a las preguntas de la guía en base a sus experiencias personales de
realizar las actividades de proyectos a que refieren las mismas.
5.3.4.3. Devolución de las guías Una vez que los ingenieros de requisitos y los gerentes de proyecto de los grupos
participantes hubieron completado las Guías respondiendo a las preguntas, las mismas
fueron devueltas al GGCA para su análisis. Este análisis consistió en verificar que todas las
preguntas estuvieran respondidas y que, para cada pregunta, el respondiente haya indicado
el tiempo que insumió redactar la respuesta. Finalizado el análisis anterior, se solicitó a los
respondientes de las guías que completaran el Cuestionario de Evaluación de las Guías de
Reflexión. La plantilla del cuestionario se encuentra en el Apéndice 2 y los cuestionarios
completados por los respondientes en el Apéndice 3.
150
5.3.5 El Taller de educción de conocimientos y experiencia
Tal como fue definido en el capítulo anterior, el Taller de educción de conocimientos y experiencia es la instancia de reflexión y análisis colectivo tendiente a identificar y
capturar los conocimientos y la experiencia adquiridos por los miembros de los equipos de
proyecto durante la ejecución de sus actividades de proyecto.
5.3.5.1 Preparación del Taller Para la preparación del Taller se tuvieron en cuenta los siguientes aspectos:
A) La disponibilidad de tiempo de los ingenieros de requisitos de los grupos de
proyectos que habrían de participar en el mismo.
B) Las respuestas dadas por los ingenieros de requisitos a las preguntas incluidas en
las Guías de Reflexión.
En relación con el primer aspecto, luego de varias consultas con los potenciales
asistentes se convino realizar el taller el lunes 27 de agosto de 2007, a la hora 20:00 en la
sala de reuniones 224 de la Facultad de Ingeniería.
En cuanto al segundo aspecto, se analizaron las respuestas recibidas y, a partir de
este análisis, se elaboró el documento de Resumen de Respuestas en el cual, para cada
pregunta o sentencia de la guía, se sintetizaron los aspectos relevantes de las respuestas
dadas por cada grupo.
A partir de este documento se elaboró la lista de temas a tratar durante la realización
del taller. Este documento, además, se distribuyó a los participantes en forma previa a la
realización del taller con el propósito de que cada uno conociera las respuestas y reflexiones
realizadas por los demás. De este modo, este documento se constituyó en uno de los dos
insumos a utilizar durante el desarrollo del taller. El segundo insumo utilizado fue la Guía
para la Realización del Taller, el cual sigue la estructura de planificación de un taller
propuesta por García [García, D., 2003]: Definición de objetivos, Actividad disparadora,
Momento de reflexión y Evaluación.
5.3.5.2 Desarrollo del taller Como representantes de los grupos proyectos, asistieron al taller las personas que
cumplían el rol de ingenieros de requisitos: Carlos Geribón (GESA), Daniel Nicolich
(COODESOR) y Andrés Lapachian (SCPI). La representante del grupo InvPortal, Alicia Pino,
finalmente se excusó de asistir en virtud de un problema personal.
Por parte del GGCA asistieron sus integrantes, Laura Rodríguez y Ana Estela, y
también el autor en calidad de observador participante.
151
El desarrollo del taller estuvo guiado por Laura Rodríguez, que actuó como
moderadora, mientras que el registro de los aspectos relevantes de la discusión estuvo a
cargo de Ana Estela.
Siguiendo la Guía para la Realización del Taller, como actividad inicial se procedió a
explicitar y comentar los objetivos del taller (paso 1 de la guía).
A continuación, y como actividad disparadora (paso 2 de la guía), se solicitó a los
representantes de los grupos de proyectos que leyeran y analizaran las respuestas y
reflexiones dadas por los otros participantes y que identificaran las coincidencias y las
discrepancias respecto de sus propias respuestas y reflexiones.
Una vez finalizada esta actividad, se procedió a abrir la discusión grupal según el
orden de temas definido en la Guía para la Realización del Taller (paso 3 de la guía).
Durante esta discusión, los ingenieros de requisitos contaron sus experiencias
relacionadas a las actividades de proyecto que estaban incluidas en las guías de reflexión,
expusieron las situaciones personales vividas que dieron origen a las respuestas dadas a
las preguntas y discutieron las semejanzas y diferencias con las experiencias vividas por los
demás.
Concluida esta parte del taller, se realizó la evaluación de la discusión (paso 4 de la
guía), en base a la cual se fue construyendo una respuesta consensuada a los cuatro temas
inicialmente propuestos para el taller.
Esta última actividad dio como resultado el documento de conclusiones del taller con el
resumen de las lecciones aprendidas y las propuestas de mejores prácticas identificadas.
Una vez finalizada la sesión del taller, se solicitó a los asistentes que respondieran al
Cuestionario de Evaluación del Taller. La plantilla del cuestionario se encuentra en el
Apéndice 2 y los cuestionarios completados por los participantes en el Apéndice 3.
5.4 Resultados obtenidos
Los resultados obtenidos que se presentan a continuación están organizados según
los tres grupos de proposiciones a los cuales estuvo orientado el estudio:
1. Sobre el proceso de implementación del modelo.
2. Sobre las guías de reflexión.
3. Sobre el taller de educción de conocimientos y experiencia.
152
5.4.1 Sobre el proceso de implementación del modelo
Proposición 1: Cuáles son las actividades a llevarse a cabo en cada una de las fases del modelo, cuáles son los insumos requeridos por cada fase y los productos que cada fase debe generar, que criterios pueden definirse como de “entrada” o precondiciones para el inicio de cada fase y que criterios pueden definirse como de “salida” o poscondiciones para darla por finalizada.
Como resultado de las actividades de implementación descriptas en 5.5.3, se
obtuvieron los siguientes dos productos:
A) La descripción detallada del modelo “ele”, presentada en el capítulo 4.
B) El manual de implementación del modelo, incluido en el Apéndice 4.
Adicionalmente a los resultados anteriores, el proceso de implementación del modelo
permitió identificar una serie de “lecciones aprendidas” que se describen a continuación:
1. No debe esperarse que la organización donde vaya a implementarse el modelo
disponga de evaluaciones formales y documentadas sobre las prácticas y
procesos software en uso. En consecuencia, para establecer los objetivos
aprendizaje y de creación de conocimientos puede ser necesario indagar en la
historia de proyectos de la organización, consultar la documentación que exista y
recabar las opiniones de los interesados para determinar sobre cuales prácticas
implementar el modelo y cuales aspectos de esas prácticas y procesos la
organización considera necesario mejorar.
2. De la lectura de las respuestas a las preguntas de las guías de reflexión (apartado
5.4.2, proposición 2a) y de las respuestas a las preguntas 4 y 5 del cuestionario de
evaluación de las guías (apartado 5.4.2, proposición 2c) puede verse que no todas
las preguntas y no todos los respondientes identificaron brechas en sus
conocimientos. Para que las preguntas de las guías sean más efectivas en este
sentido, al formularse tales preguntas deberían tenerse en cuenta los
conocimientos y la experiencia previos de quienes vaya a responderlas.
3. De la lectura de las respuestas a las preguntas de las guías de reflexión (apartado
5.4.2, proposición 2a) y de los resultados del taller de educción de conocimientos y
experiencia (apartado 5.4.3, proposición 3a) puede verse que en este último se
reiteran la mayoría de los conceptos e ideas expresados previamente en las
153
respuestas a las guías de reflexión. Para que el taller sea más efectivo en la
elaboración de lecciones aprendidas y en la generación de propuestas de mejores
prácticas, el contenido temático del taller y su desarrollo deberían enfocarse de
manera más específica en las lecciones aprendidas, las fuentes de conocimientos
y las potenciales propuestas de mejores prácticas que surgen del análisis de las
respuestas a las guías de reflexión (apartado 5.5, proposición 2a).
4. Los miembros del GGCA deben capacitarse en los conceptos y procesos
generales sobre gestión del conocimiento, conocer el modelo de aprendizaje
experiencial de Kolb y comprender los conceptos principales sobre la práctica
reflexiva de Schon. Es particularmente importante que conozcan la taxonomía de
objetivos educacionales de Bloom puesto que la misma es un elemento clave en la
elaboración de las preguntas o sentencias de reflexión.
5. Adicionalmente al punto anterior, los miembros del GGCA deben conocer los
conceptos y procesos de las áreas de conocimiento de IS sobre los cuales se vaya
a implementar el modelo y es conveniente que al grupo se integre un
representante de la organización que conozca las prácticas y procesos software en
uso.
5.4.2 Sobre las Guías de Reflexión
Proposición 2: Las guías de reflexión constituyen una herramienta eficaz para realizar una captura primaria de los conocimientos y experiencia que se adquieren durante la ejecución de las tareas de proyecto.
Para dar respuesta a esta proposición se procedió a la lectura analítica de las
respuestas dadas a cada pregunta o sentencia de reflexión, buscando extraer de los textos
de respuesta aquellos párrafos que, tal como están redactados, se interpretan como
expresiones de aprendizajes logrados en base a la experiencia. Los extractos de respuestas
que se transcriben a continuación han sido mínimamente editados para corregir errores
ortográficos o de escritura.
154
Guía de reflexión para Requisitos software Pregunta 1 de la Guía de reflexión: ¿Qué aspectos considera usted que es importante que se tomen en cuenta a la hora de planificar una entrevista? COODESOR Creo que lo más importante en mi caso fueron tres aspectos:
- La coordinación específica de la entrevista. Esto fue fundamental para dejar bien establecida la inversión de tiempo que supone la entrevista tanto para el entrevistado como para nosotros y denotar la seriedad de la misma. - Fue muy bueno generar una lista de posibles preguntas o temas que debíamos abordar en la entrevista para poder hacer una especie de checklist de los aspectos que teníamos que relevar. - Informar previamente al entrevistado sobre la temática y el contenido de la entrevista para que el entrevistado pueda llegar a la entrevista con un esquema claro de lo que se va a tratar.
GESA … realizar una lista de preguntas o una guía para la entrevista la cual será diferente según la persona que vayamos a entrevistar. Antes de seleccionar la persona a la cuál vamos a entrevistar, sería aconsejable hablar antes con algún superior (si éste es el caso) de ésta, para asegurarnos que estamos entrevistando a la persona correcta… Otro punto importante es cómo vamos a registrar lo conversado en la entrevista... que el acta de la reunión se realice lo más pronto posible, después pasa el tiempo y podemos perder “pequeños” detalles que al final son grandes requerimientos del Sistema… También está bueno y sirve de mucho mandarle al Cliente las preguntas o los temas que se van a tratar en la reunión antes por mail, para que éste se prepare en caso de que sea necesario. Otra de las cosas que he aprendido en el transcurso de las entrevistas es a formular preguntas correctas (desde el punto de vista de lo que deseo relevar).
SCPI … lo que se realizó es confeccionar una Minuta de Reunión y enviársela a todos los integrantes que van a participar con varios días de anticipación a la fecha estipulada de dicha reunión … Se realizó un documento con las preguntas a realizarle al usuario …
InvPortal En primer lugar se debe saber con quién se va a tener la entrevista, conocer la persona, ser puntual, etc. Se debe planificar el alcance de la entrevista y que temas se van a tratar en la misma,… realizando una guía con las preguntas más importantes, sin necesidad de seguirla paso a paso, pero si para asegurarnos de aclarar todos los puntos para los cuales se solicito la entrevista. Otra cosa importante a tener en cuenta es la posición del equipo (si es que va más de una persona a la entrevista) el grupo se debe comportar como uno, hablar de a uno, y sobre todas las cosas estar de acuerdo de antemano en lo que se pregunta, en lo que se dice y en lo que se defiende, nunca debe discutir el grupo frente al cliente o a cualquier persona externa al equipo de trabajo, se debe apoyar el grupo entre si y ponerse de acuerdo internamente de todo.
Pregunta 2 de la Guía de reflexión: Una buena comunicación con el usuario es clave para lograr recolectar información. Exponga los problemas más relevantes que ha tenido para establecer una comunicación efectiva y cómo los ha superado. COODESOR … el principal problema que tuvimos a nivel de comunicación fue el no tener una
instancia de conocimiento a la contraparte del cliente en nuestra entrevista. GESA … la comunicación con el usuario es clave, por eso la importancia de conocer el
tema que vamos a tratar en la reunión y la terminología que utiliza el usuario. SCPI En nuestro caso, no se tuvo mayores inconvenientes de comunicación con el
usuario, debido a que este es Ingeniero en Sistemas y la comunicación era fluida dado que conocía a la perfección el dominio.
InvPortal … lo que nos ha resultado más problemático es la coordinación de entrevistas por el tema de los horarios, ya que en el horario que al cliente le servía la entrevista, nosotros trabajamos, pero logramos un acuerdo y encontrar una media que nos convenga a las dos partes.
155
Pregunta 3 de la Guía de reflexión: ¿Qué recomendaría usted a un ingeniero de requerimientos que se enfrenta a un usuario con necesidades poco claras? COODESOR Recomiendo que la investigación comience a bajo nivel, indagando en las tareas
más frecuentes que realiza el usuario o las tareas que se llevan a cabo en el entorno del cliente. También creo que es bueno analizar y realizar un esquema de los procesos que realiza el usuario o el cliente en general para hacerle esquematizar de alguna forma las tareas que realiza el cliente y lograr definir claramente sus necesidades y sus objetivos.
GESA … pienso que lo mejor es profundizar en el tema a tratar, analizar todo en detalle para sacar conclusiones y obtener así las verdaderas necesidades. Evidentemente el aporte del Cliente es muy valioso ya que nosotros no somos expertos en su área, por eso creo que en este tipo de casos hay que trabajar conjuntamente y demostrarle sus necesidades. Nuestro planteamiento debe ser de la mejor manera posible para evitar roces con el Cliente, no podemos olvidar que él es el que conoce el área y eso puede llevar a que piense que somos nosotros los equivocados.
SCPI … lo mejor a mi entender, es proponerle soluciones a los problemas que el usuario posee. Estos problemas el usuario los tiene claro, pero no sabe cuales son las necesidades o lo que necesita para resolverlos y para esto con un estudio importante del dominio en que se movería la aplicación, lo mejor es proponerle soluciones para que éste vaya teniendo más claras cuales son las necesidades y poder llegar así a un mejor entendimiento de la aplicación a realizar.
InvPortal Se debería realizar un estudio de las necesidades del cliente, estudiando la empresa, las ventajas y desventajas de la misma, oportunidades en el mercado, sector de mercado, etc., y a partir de éste realizar un documento con conclusiones de lo estudiado, para presentarle al cliente …
Pregunta 4 de la Guía de reflexión: Relate, en no menos de cuatro o cinco líneas, aquella experiencia de entrevista que usted considera que fue la más exitosa y que volvería a repetir. COODESOR Creo que la entrevista más exitosa fue la sostenida con el presidente de la
cooperativa (responsable de la misma). En ella no solo logré obtener más información sobre las necesidades y expectativas del cliente sobre el producto final, sino que logré un grado importante del cliente en el proyecto y en las características del mismo.
GESA En la cuarta entrevista (como en el resto) le mandamos por mail a nuestro Cliente la lista de temas que íbamos a tratar así como las preguntas que le íbamos a realizar. Cuando llegó el momento de la entrevista, nuestro Cliente ya había contestado las preguntas y se había informado más acerca de los temas que creyó conveniente para poder de esta manera colaborar más con nosotros.
SCPI La mejor entrevista con el cliente que tuvimos fue aquella en la que previamente decidimos armar como se mencionó una minuta de reunión, el cual nos posibilitó realizar en forma mucho más ágil la reunión. Otro aspecto exitoso a mi entender fue grabar en formato audio las reunión. Esto sirvió para, luego de escuchar de nuevo la reunión, no perdernos de nada importante.
InvPortal Las entrevistas que hemos realizado, nos parecen todas muy exitosas ya que de cada una de ellas aprovechamos la mayor cantidad del tiempo, logramos aclarar todas las preguntas que teníamos para el cliente… Logramos un buen entendimiento siempre con el cliente, respetamos muchísimo su punto de vista, como también hacemos respetar las cosas que escapan al alcance del proyecto por causa del tiempo.
156
Pregunta 5 de la Guía de reflexión: En base a su experiencia, ¿qué dificultades encontró para distinguir los requerimientos funcionales de los no funcionales?COODESOR Básicamente la dificultad partió del poco conocimiento que tenía de la diferencia
entre los requerimientos funcionales y no funcionales y lo que involucraba cada uno de estos conceptos
GESA … pero con respecto a los requerimientos no funcionales tuve que leer acerca de ellos porque no se me ocurrían muchos.
SCPI No se encontraron dificultades en este tema. InvPortal … podemos decir que no encontramos dificultades para distinguirlos.
Pregunta 6 de la Guía de reflexión: ¿Cómo logró superar las dificultades anteriormente expresadas? COODESOR Varias instancias de aprendizaje y de consulta a los tutores permitieron definir
claramente los conceptos que abarcaban los conceptos anteriores permitiendo diferenciarlos con más claridad.
GESA Investigando acerca de los mismos, en Internet y en diapositivas de semestres anteriores.
SCPI El respondiente no incluyó respuesta a esta pregunta. InvPortal No hubo dificultades.
Pregunta 7 de la Guía de reflexión: Los miembros del proyecto que se dedican a la ingeniería de requerimientos necesitan un entrenamiento inicial para prepararse para la tarea. ¿De qué manera planearía usted este entrenamiento? COODESOR … sería bueno hacer un taller entre los participantes de IR aplicando técnicas de
análisis de casos y role playing para experimentar en un entorno académico los diferentes aspectos de la IR.
GESA En mi caso, no tenía nada de experiencia práctica y creo que la capacitación de Ingeniería de Requerimientos me sirvió para recordar algo del teórico que aprendí en semestres anteriores.
SCPI A nosotros nos vino muy bien el Taller de Ingeniería de Requerimientos que tuvimos. Este entrenamiento para mi, tendría una parte “teórica” y una parte “práctica”. La parte teórica mostraría cuales son las perspectivas de la ingeniería de requerimientos; funcional, metodológica, de resultado, de comportamiento y organizacional. Teniendo claras las 5 perspectivas, realizar un ejemplo práctico para solventar estos conocimientos teóricos y lo más importante transmitir las experiencias de uno.
InvPortal No me parece que debiera haber un entrenamiento, a menos que éste sea práctico, esta claro que para la mayoría nos resulta como algo nuevo ya que no lo realizamos a lo largo de la carrera, pero sí tenemos los conocimientos teóricos de ello, el tema principal es que es la primera vez de alguna manera que ponemos en práctica todo eso que hemos aprendido a lo largo de la carrera … La manera de llegar con un entrenamiento al proyecto final podría ser realizando un mini-proyecto … pero que en vez de ser orientado a diseño en sí, que también tenga como misión el aprender a interactuar con el cliente, que el mismo alumno sea el que releve lo que el cliente quiere y como lo quiere …
Pregunta 8 de la Guía de reflexión: A su juicio, ¿qué habilidades personales facilitarían las tareas del ingeniero de requerimientos? COODESOR Creo que serían las siguientes: saber escuchar, facilidad de comunicación
adecuándola a las características del cliente, poder lograr empatía con el cliente, nunca está de más una buena presencia que demuestre seriedad.
GESA … además de tener que ser responsable y todo lo demás, debe ser una persona bastante abierta, y que no tenga problemas de diálogo, creo que ésta es la clave.
SCPI La organización, la comunicación con otros, la proactividad, conocer el dominio, ponerse del lado del cliente.
InvPortal Comunicación, entendimiento, comprensión, disponibilidad, detallista, analítico
157
Pregunta 9 de la Guía de reflexión: De las actividades relativas a IR que llevo acabo en el presente proyecto, ¿cuales considera que realizó adecuadamente y cuáles considera que deberá mejorar la próxima vez? COODESOR … lo que mejoraría para una próxima oportunidad sería la incorporación de una
instancia inicial de conocimiento del cliente y la contraparte en el proceso de entrevistas.
GESA Lo que debo mejorar para las próximas entrevistas es el tiempo, la mayoría de las veces por ser cortés con el Cliente lo dejo explayarse en cosas poco relevantes para el proyecto y esto lleva a que la reunión se extienda más de lo planificado sin agregarle nada productivo a la entrevista. Supongo que esto se debe a la falta de experiencia en entrevistas…
SCPI La actividad que nos dio mayor problema fue documentar todo lo extraído, dado que se posee en la página Web institucional muchas herramientas para llevar adelante la ingeniería de requerimientos y en principio se decidió utilizar la mayoría de ellas, pero mediante charlas con el tutor de rol, éste nos fue comunicando que mantener todos los documentos llevaría tiempo y que es necesario manejar una relación costo/beneficio y poder realizar documentos que le aporte al cliente, a la academia y a nosotros mismos.
InvPortal … el único problema si se puede considerar como problema de ingeniería de requerimientos, fue la disponibilidad horaria del cliente y la nuestra en el momento de concretar una entrevista.
Espacio libre de la Guía de reflexión COODESOR En nuestro caso nos sucedió que planificamos la etapa de relevamiento y entrevistas
en una única instancia. … Para esto habíamos realizado formularios de relevamiento y guías de entrevista que en el momento de llevarlas a cabo no fueron de mucha ayuda – sobre todo los formularios – ya que los mismos se habían elaborado considerando una empresa de mayores dimensiones, con más usuarios del sistema actual e instalaciones de mayor envergadura, pero cuando llegamos a hacer el relevamiento vimos que el cliente contaba sólo con dos usuarios del sistema y dos PCs. Sin duda esto nos hizo ver que la planificación que habíamos realizado no fue del todo efectiva y en cierta forma resultó en un mal aprovechamiento del tiempo empleado.
GESA Me parece que este es el momento justo para realizar esta actividad, ya que de realizarse una vez finalizado el proyecto, creo que nos olvidaríamos de detalles que pueden ser muy importantes. El responder a estas preguntas, me hizo recordar o plantearme cosas que quizás las creía tener solucionadas, y que, a decir verdad, se me habían “olvidado” de tenerlas en cuenta (por ejemplo: pensar como puedo hacer para, de una manera cortés, hacerle entender al Cliente que lo que está diciendo no sirve de nada y que es una total perdida de tiempo) por no haberlas registrado en algún documento debido a que he priorizado a otras tareas antes que la mencionada. Una cosa que creo que les puede servir de mucho a los responsables de IR, es informarle previamente al Cliente los temas que se tratarán y la lista de preguntas que se le realizarán en la reunión. Personalmente, esta metodología me ha servido de mucho y creo que gracias a esto, es que siempre al finalizar las entrevistas logramos nuestros objetivos.
SCPI El respondiente no hizo uso de este espacio. InvPortal El respondiente no hizo uso de este espacio.
158
Guía de reflexión para Métricas de gestión de proyectos Pregunta 1 de la Guía de reflexión: ¿Qué métricas planificó recolectar para su proyecto? ¿Por qué considera que estas métricas son adecuadas para su proyecto en particular? COODESOR Desfasaje en tiempo o calendario, Desfasaje en esfuerzo, Desfasaje en costo,
Efectividad de pruebas. Las tres primeras permiten ver la diferencia entre lo estimado y lo real, y ello sirve para darte cuenta si es necesario hacer modificaciones en lo que tienes planificado para el futuro. Sobre la de Efectividad de pruebas, permite ver la relación existente entre los errores encontrados por las pruebas unitarias y las pruebas cruzadas.
GESA … la dedicación horaria de todo el grupo en cada iteración que dura aproximadamente 15 días. Y por otro lado se contabiliza la dedicación horaria de cada integrante en particular en la iteración. También se realiza el desvío de la estimación realizada para cada tarea de la iteración, obteniendo así el desvío de tiempo entre lo estimado y el tiempo real de las tareas.
SCPI Esfuerzo estimado y real: nos permite conocer la desviación en la planificación de las actividades, ya sea por persona, fase o actividad … Evolución de los riesgos: … pretendemos monitorear su avance en el tiempo, en principio por iteración. Fallas: Medimos las fallas a lo largo de las fases del proyecto para conocer el nivel de calidad del producto y detectar las causas de las mismas.
Pregunta 2 de la Guía de reflexión: ¿Cómo llevó a cabo el análisis de los datos obtenidos a partir de la recolección de las métricas? COODESOR … algo que hemos podido apreciar es que las diferencias que hemos tenido en
tiempo o calendario digamos, nos permitieron darnos cuenta que la planificación inicial que teníamos era totalmente utópica, por lo cual nos ha ayudado a realizar modificaciones a la planificación para que fuera más realista.
GESA … primero estudiando las horas dedicadas por cada integrante para una iteración, luego se agruparon para obtener el tiempo dedicado por todos los integrantes a la iteración. En cuanto al estudio de la estimación de cuanto nos llevaría cada tarea de la iteración en principio se hizo una estimación a ciegas y se comparó con el tiempo real, así se obtuvieron datos para la siguiente iteración ya partiendo de datos anteriores.
SCPI … la única métrica que hemos analizado es el esfuerzo. Hemos utilizado esta métrica para corregir las estimaciones …
Pregunta 3 de la Guía de reflexión: En base a su experiencia, ¿qué dificultades encontró para identificar las métricas que son útiles para su proyecto en particular? COODESOR … no he tenido dificultades, pero creo que tal vez sea necesaria alguna otra métrica,
sobre lo cual aún estoy investigando. GESA Las dificultades para encontrar las métricas fueron bastante grandes, ya que
anteriormente se hizo un estudio de métricas que fueron descartadas en la primera revisión ya que nos darían resultados post mortem y no es ésa la finalidad de las métricas sino la de prevención.
SCPI Al principio del proyecto nos basamos mucho en el marco teórico y planteamos un conjunto de métricas que, más adelante, concluimos que no nos eran de utilidad. Esto se debía a que la información que nos aportaban era de muy poca aplicación al contexto del proyecto o que el tipo de datos que necesitábamos recaudar para generar la métrica era muy difícil de medir adecuadamente.
159
Pregunta 4 de la Guía de reflexión: ¿Cómo logró superar las dificultades anteriormente expresadas? COODESOR … la dificultad que tenemos hoy en día es identificar alguna métrica que desde
nuestro punto de vista estaría faltando… para superar esto, estaré leyendo documentación al respecto y además pretendo reunirme con el tutor del rol Gerente, para que pueda indicarme cómo estamos en relación a las métricas.
GESA … se recurrieron a estudios de proyectos anteriores, de reuniones con los tutores de rol de la parte de gerencia de proyecto y reuniones con el tutor de grupo.
SCPI Con ayuda de la tutora de proyecto, del revisor y de la tutora de rol de SQA, …
Pregunta 5 de la Guía de reflexión: ¿Qué aconsejaría usted hacer para asegurar que las métricas seleccionadas son las adecuadas para un proyecto en particular? COODESOR … tener siempre a la vista el tema de costos, de tiempos, etc., … un gerente debe
tener en cuenta para tomar métricas que sean útiles, es que debe poder ver de manera clara, o sea a primer vista, cuál es el estado actual del proyecto, a nivel de tiempos, costos, etc.
GESA … recomiendo que vean si el tiempo es primordial en el proyecto o no. A partir de ahí saldrán algunas métricas fundamentales para tener información respecto a cómo se va en el proyecto ...
SCPI Una primera recomendación que aprendimos… es evaluar el esfuerzo que requiere obtener un dato necesario para elaborar una métrica. Si el esfuerzo es muy elevado, o requiere de hacer varios cambios en la forma de trabajo…, tal vez es mejor tomar una métrica similar, no tan precisa, pero que sea fácil de medir y REAL.
Pregunta 6 de la Guía de reflexión: Relate, en no menos de cuatro o cinco líneas, las lecciones aprendidas durante el proceso de planificación de métricas. COODESOR … lo que sí puedo expresar es que ya que trabajo en un proyecto de mantenimiento,
he observado sí la diferencia entre las métricas para un proyecto de mantenimiento y de desarrollo…
GESA … las métricas utilizadas en otros proyectos no siempre se pueden ser reutilizadas, cada proyecto debe ser evaluado por si mismo y definidas métricas particulares para ese proyecto. Que lo visto en clase o en libros no es siempre aplicable al proyecto que estamos llevando a cabo.
SCPI … nos dimos cuenta que sólo con el marco “teórico” no sirve, ya que hay que bajar las métricas a la realidad del proyecto.
Pregunta 7 de la Guía de reflexión: Los miembros del proyecto que se dedican a la planificación y gestión de métricas necesitan un entrenamiento inicial para prepararse para la tarea. ¿De qué manera planearía usted este entrenamiento? COODESOR … lo principal para poder llevar a cabo la recolección de métricas es concienciar a
todos los recursos del equipo para que registren adecuadamente los tiempos insumidos en las distintas tareas y luego deberían leer bibliografía al respecto de métricas…
GESA … sería bueno que se tuviera unas clases guía por lo menos, indicando pasos a seguir… el entrenamiento sería más bien práctico con planteos puntuales de cómo llevar a cabo las tareas que se deben realizar, planteando ejemplos concretos.
SCPI … que los involucrados en dichas áreas participen de las charlas informativas que brindan los tutores de rol … nos resultó muy útil todo el material que se encuentra disponible en el sitio de Software Factory …
160
Pregunta 8 de la Guía de reflexión: De las actividades relativas a la planificación y gestión de métricas que llevó acabo en el presente proyecto, ¿cuáles considera que realizó adecuadamente y cuáles considera que debería mejorar la próxima vez? COODESOR … realizar una charla con el equipo para que entiendan la importancia del registro de
horas … establecer las métricas a utilizar al comienzo mismo del proyecto, cosa que por falta de experiencia no lo hice y al establecerlas ya con un tiempo x de transcurrido el proyecto, se hace más difícil recopilar información necesaria para que las métricas representen una realidad … se ha realizado bien fue la selección de las métricas a utilizar … evitando así la recolección de métricas que no aportan demasiado e insumen mayor tiempo del proyecto.
GESA Las que considero que se llevaron a cabo correctamente son los registros de actividades de los integrantes del grupo. La que mejoraría es la tarea de estimación de cada iteración …
SCPI … todavía no podemos decir que hicimos bien o mal… más adelante, cuando utilicemos los datos obtenidos, vamos a saber realmente que errores cometimos en la planificación.
Proposición 3: Responder a las preguntas o sentencias de reflexión tiene una baja incidencia respecto al tiempo total del proyecto
Para responder a esta proposición se utilizaron dos fuentes de datos:
A) los tiempos de respuesta indicados en las guías de reflexión completadas por los
respondientes.
B) los tiempos totales de proyecto obtenidos a partir de la documentación propia de
gestión del proyecto de los grupos participantes.
En la tabla 5.5 se muestran, expresados en minutos, los tiempos dedicados por cada
grupo de proyecto a responder a todas las preguntas de las guías de reflexión.
COODESOR GESA SCPI InvPortalGuía para ingeniería de requisitos 80 76 46 67 Guía para métricas de gestión de proyecto 90 49 70 0
Totales en minutos 170 125 116 67Tabla 5.5: Tiempos, en minutos, dedicados a responder las guías de reflexión
Expresados en horas, los tiempos reportados se muestran en la tabla 5.6. COODESOR GESA SCPI InvPortalGuía para ingeniería de requisitos 1,33 1,27 0,77 1,17 Guía para métricas de gestión de proyecto 1,50 0,82 1,17 0
Totales en horas 2,83 2,09 1,94 1,17Tabla 5.6: Tiempos, en horas, dedicados a responder las guías de reflexión
De la revisión de los documentos de proyectos de los grupos participantes se
obtuvieron los siguientes tiempos insumidos en los proyectos en general y en las actividades
de ingeniería de requisitos y de gestión del proyecto en particular, que se muestran en la
tabla 5.7.
161
COODESOR GESA SCPI InvPortalActividades de ingeniería de requisitos 372h 232,8h 262,1h 27h Actividades de gestión del proyecto 95h 204,3h 116,5h ----- Tiempo total del proyecto 1.371h 1.261,7h 2912,0h 1.480h
Tabla 5.7: Tiempos de actividades y de proyecto
Los proyectos COODESOR, GESA e InvPortal finalizaron en Octubre de 2007,
mientras que el proyecto SCPI finalizó en Marzo de 2008.
Por otra parte, en el reporte final del proyecto InvPortal no está discriminado el tiempo
dedicado a las actividades específicas de gerenciamiento del proyecto, y del análisis de la
documentación no fue posible obtener de manera precisa ese tiempo.
La tabla 5.8 muestra los porcentajes de tiempo dedicados a responder las guías de
reflexión en relación con los tiempos insumidos en las actividades de ingeniería de
requisitos, en las actividades de gestión del proyecto y en el total del proyecto:
COODESOR GESA SCPI InvPortalActividades de ingeniería de requisitos 0,36% 0,55% 0,29% 4,33% Actividades de gestión del proyecto 1,58% 0,40% 1,00% ----- Tiempo total del proyecto 0,21% 0,17% 0,07% 0,08%
Tabla 5.8: Porcentajes de tiempos de respuestas a las guías de reflexión
Proposición 4: Que valoración dan los miembros de los grupos de proyecto a las guías de reflexión
Para dar repuesta a esta proposición se utilizó el cuestionario de Evaluación de las
Guías de Reflexión.
Se distribuyeron ocho cuestionarios, uno a cada Ingeniero de Requisitos y a cada
Gerente de Proyecto de los grupos de proyecto participantes, de los cuales se recibieron
siete respondidos.
Las respuestas obtenidas se resumen en tabla 5.9.
162
Muy
en de
sacuerdo
En desacue
rdo
Indiferente
De acue
rdo
Muy
de acue
rdo
Pregunta1 2 52 1 21 383 10 33 174 13 19 20 85 3 3 14 28 126 6 1
Totales 3 16 46 113 76 Tabla 5.9: Respuestas al cuestionario de la proposición 4
Si se agrupan las respuestas en cuanto a una actitud general Favorable, Indiferente o
Desfavorable, los resultados obtenidos se muestran en la tabla 5.10.
Actitud Respuestas consideradas Cantidad %Favorable Muy de acuerdo, De acuerdo 189 74,41%Indiferente Indiferente 46 18,11%Desfavorable En desacuerdo, Muy en desacuerdo 19 7,48%
254 100,00% Tabla 5.10: Agrupación de respuestas por actitud
Cuando las respuestas se discriminan individualmente para cada pregunta del
cuestionario, los resultados obtenidos fueron:
1. La lectura de la Guía de Reflexión en forma previa a la realización de mis tareas de
proyecto me hubiera permitido prepararme mejor para llevar a cabo esas tareas
(tabla 5.11).
Actitud Respuestas consideradas Cantidad %Favorable Muy de acuerdo, De acuerdo 5 71,43%Indiferente Indiferente 2 28,57%Desfavorable En desacuerdo, Muy en desacuerdo 0 0,00%
7 100,00%
Tabla 5.11: Respuestas a la pregunta 1 del cuestionario
163
2. La respuesta dada a cada pregunta estuvo directamente vinculada a mi
experiencia personal adquirida en el proyecto (tabla 5.12).
Actitud Respuestas consideradas Cantidad %Favorable Muy de acuerdo, De acuerdo 59 98,33%Indiferente Indiferente 1 1,67%Desfavorable En desacuerdo, Muy en desacuerdo 0 0,00%
60 100,00%
Tabla 5.12: Respuestas a la pregunta 2 del cuestionario
3. Las preguntas me instaron a reflexionar detenidamente acerca de las respuestas a
dar a las mismas (tabla 5.13).
Actitud Respuestas consideradas Cantidad %Favorable Muy de acuerdo, De acuerdo 50 83,33%Indiferente Indiferente 10 16,67%Desfavorable En desacuerdo, Muy en desacuerdo 0 0,00%
60 100,00% Tabla 5.13: Respuestas a la pregunta 3 del cuestionario
4. Haber reflexionado y respondido a las preguntas me permitió identificar “brechas”
en mis conocimientos relativos a los temas abordados en las mismas (tabla 5.14).
Actitud Respuestas consideradas Cantidad %Favorable Muy de acuerdo, De acuerdo 28 46,67%Indiferente Indiferente 19 31,67%Desfavorable En desacuerdo, Muy en desacuerdo 13 21,67%
60 100,00% Tabla 5.14: Respuestas a la pregunta 4 del cuestionario
5. Haber reflexionado y respondido a las preguntas me permitió identificar aspectos
de mi actuación en el proyecto que considero deberé mejorar en una próxima
instancia (tabla 5.15).
Actitud Respuestas consideradas Cantidad %Favorable Muy de acuerdo, De acuerdo 40 66,67%Indiferente Indiferente 14 23,33%Desfavorable En desacuerdo, Muy en desacuerdo 6 10,00%
60 100,00%
Tabla 5.15: Respuestas a la pregunta 5 del cuestionario
6. En general, considero a las Guías de Reflexión como un instrumento útil para
facilitar la reflexión sobre mis conocimientos y mi actuación profesional (tabla
5.16).
164
Actitud Respuestas consideradas Cantidad %Favorable Muy de acuerdo, De acuerdo 7 100,00%Indiferente Indiferente 0 0,00%Desfavorable En desacuerdo, Muy en desacuerdo 0 0,00%
7 100,00%
Tabla 5.16: Respuestas obtenidas a la pregunta 6 del cuestionario
5.4.3 Sobre el taller de educción de conocimientos y experiencia
Proposición 5: El taller de educción de conocimientos y experiencia permite consensuar las lecciones aprendidas y las propuestas de mejores prácticas identificadas en las guías de reflexión, así como obtener nuevos aportes de conocimientos y experiencia adquiridos durante la realización de las actividades de proyecto.
Para dar respuesta a esta proposición se consideraron los diferentes aportes
realizados por los participantes durante la discusión de los temas definidos para el taller.
Se trascriben a continuación los conceptos y conclusiones mas relevantes resultantes
de esa discusión y que han permitido identificar lecciones aprendidas y propuestas de
mejores prácticas.
Tema 1 del taller: Planificación de las entrevistas 1.1 Previamente a la realización de la entrevista es imprescindible informarse acerca del
negocio del cliente. Realizar una investigación previa del cliente y su dominio. Esto permitirá llegar a la entrevista con un mayor conocimiento y por lo tanto facilitará la comprensión de los problemas y necesidades del cliente.
1.2 Realizar un listado de las preguntas a efectuar al entrevistado y enviarla previamente a la entrevista. De esta forma el entrevistado tendrá conocimiento de los temas a tratar durante la entrevista y podrá prepararse para la misma y asegurarse de contar con toda la información y documentación de apoyo necesaria para responder a las preguntas.
1.3 Elaborar un guión de la entrevista en base al número de entrevistados y a la duración prevista para la misma. Esto permitirá establecer un orden durante la entrevista y asegurarse de tratar todos los temas.
1.4 Establecer el tiempo de duración de la entrevista y comunicársela previamente al entrevistado. Fijar la hora de inicio y la hora de fin y tratar siempre de respetar esas horas. Si llega la hora de finalización de la entrevista sin haberse discutidos todos los temas previstos, tratar de agendar en el momento una nueva instancia para tratar los temas faltantes. Adicionalmente, analizar los motivos por los cuales no se trataron todos los temas previstos de modo de evitar esta situación en una próxima instancia.
1.5 Realizar acta de la entrevista inmediatamente después de efectuada la misma para no olvidar detalles o aspectos trabajados durante la entrevista.
165
Tema 2 del taller: Interacción con el entrevistado 2.1 Durante el desarrollo de la entrevista los entrevistadores deben dirigir su atención a muchos
aspectos como ser: los temas que se están abordando, la dinámica de la entrevista, aspectos del negocio, posibles necesidades del usuario. Por ello es muy importante, si el entrevistado no tiene objeciones, grabar la entrevista de manera que la atención se centre en los aspectos clave y no se desvíe hacia el registro de los temas que se están desarrollando.
2.2 Si en la entrevista participará más de un entrevistador, entonces presentarse frente a los entrevistados como un grupo, actuar de forma organizada y uniforme.
2.3 Conocer el lenguaje propio del entrevistado.
Tema 3 del taller: Habilidades personales del ingeniero de requisitos 3.1 Debe ser buen comunicador, debe tener empatía, flexibilidad, capacidad de adaptarse al
cliente (a sus tiempos, a su lenguaje, etc.) 3.2 Debe tener conocimientos sobre ingeniería de requisitos y sobre arquitectura 3.3 Debe tener poder de negociación con el equipo de desarrollo.
Tema 4 del taller: Entrenamiento inicial para ingenieros de requisitos 4.1 El entrenamiento debería de estar organizado de tal forma de tener un 50% de teoría y un
50% de práctica. 4.2 Realizar una experiencia práctica y luego participar en un taller en el que se intercambien las
experiencias de cada uno. 4.3 Durante el entrenamiento, poner énfasis en el proceso que se debe llevar a cabo para
analizar la información relevada, es decir, como realizar el análisis de dicha información.
Proposición 6: Qué valoración dan los miembros de los grupos de proyecto al Taller de Educción de Conocimientos y Experiencias.
Para dar respuesta a esta proposición se utilizó el cuestionario de Evaluación del
Taller. Las preguntas de este cuestionario apuntaron a medir la actitud de los participantes
en relación con los siguientes aspectos del Taller:
A) Organización del taller (preguntas 1 a 4).
B) Participación personal (preguntas 5 a 8).
C) Contenido del taller (pregunta 9).
Las preguntas incluidas en el cuestionario fueron las siguientes:
1. Los objetivos del taller estuvieron claramente definidos.
2. La duración del taller fue adecuada.
3. El material recibido como insumo para la realización del taller fue satisfactorio en
cuanto a su estructura y contenido.
4. El lugar físico elegido para realizar el taller fue adecuado.
5. Valoro como muy positivo el haber podido conocer y discutir, durante el taller, las
experiencias de los otros participantes.
166
6. Con la participación en el taller considero que he aumentado mis conocimientos
sobre los temas tratados en el mismo.
7. Los conocimientos adquiridos en el taller me permitirán realizar un mejor
desempeño en proyectos futuros.
8. En general, considero que el taller fue una experiencia positiva.
9. De los cuatro temas tratados en el taller, el o los más interesantes fueron:
a) Planificación de la entrevista.
b) Interacción con el entrevistado.
c) Habilidades personales del ingeniero de requisitos.
d) Entrenamiento inicial sobre ingeniería de requisitos.
Las respuestas obtenidas se resumen en la tabla 5.17:
Muy
en de
sacuerdo
En desacue
rdo
Indiferente
De acue
rdo
Muy
de acue
rdo
Pregunta1 2 12 1 23 1 24 1 25 1 26 2 17 2 18 39 7 5
Totales 1 18 17 Tabla 5.17: Respuestas al cuestionario de la proposición 6
Si se agrupan las respuestas en cuanto a una actitud general Favorable, Indiferente o
Desfavorable, los resultados obtenidos fueron los que aparecen en la tabla 5.18.
Actitud Respuestas consideradas Cantidad %Favorable Muy de acuerdo, De acuerdo 35 97,22%Indiferente Indiferente 1 2,78%Desfavorable En desacuerdo, Muy en desacuerdo 0 0,00%
36 100,00% Tabla 5.18: Agrupación de respuestas por actitud
167
Cuando las respuestas se discriminan según los tres grupos de preguntas, los
resultados obtenidos se presentan en las tablas 5.19, 5.20 y 5.21.
Actitud Respuestas consideradas Cantidad %Favorable Muy de acuerdo, De acuerdo 11 91,67%Indiferente Indiferente 1 8,33%Desfavorable En desacuerdo, Muy en desacuerdo 0 0,00%
12 100,00% Tabla 5.19: Sobre la organización del taller (preguntas 1 a 4)
Actitud Respuestas consideradas Cantidad %
Favorable Muy de acuerdo, De acuerdo 12 100,00%Indiferente Indiferente 0 0,00%Desfavorable En desacuerdo, Muy en desacuerdo 0 0,00%
12 100,00% Tabla 5.20: Sobre la participación personal en el taller (preguntas 5 a 8)
Actitud Respuestas consideradas Cantidad %Favorable Muy de acuerdo, De acuerdo 12 100,00%Indiferente Indiferente 0 0,00%Desfavorable En desacuerdo, Muy en desacuerdo 0 0,00%
12 100,00%
Tabla 5.21: Sobre el contenido del taller (pregunta 9)
5.5 Análisis de los resultados
Proposición 1: Cuáles son las actividades a llevarse a cabo en cada una de las fases del modelo, cuáles son los insumos requeridos por cada fase y los productos que cada fase debe generar, que criterios pueden definirse como de “entrada” o precondiciones para el inicio de cada fase y que criterios pueden definirse como de “salida” o poscondiciones para darla por finalizada.
La implementación práctica del modelo en un entorno real de desarrollo de software
permitió obtener una descripción más acabada del mismo que, ahora, difiere de la versión
preliminar con la cual se inició la implementación. Las diferencias entre esa versión
preliminar y la que finalmente se presentó en el capítulo 4 tienen que ver principalmente con
las tareas que conforman cada fase del modelo y, como consecuencia de esto, en los
insumos y productos de cada fase así como con la definición de las precondiciones y
poscondiciones para iniciar y dar por finalizada cada una de las mismas.
168
Los aspectos más importantes que la implementación permitió descubrir son:
A) La necesidad de incorporar al modelo la definición y elaboración del catálogo de
conocimientos y experiencia como forma de establecer una terminología unificada
para nombrar los elementos de conocimientos y de experiencia que serán luego
referenciados en el inventario de conocimientos y experiencia, en las guías de
reflexión y en el repositorio de lecciones aprendidas y de mejores prácticas.
B) Definir en detalle y probar el procedimiento general para la elaboración de las
preguntas o sentencias de reflexión a incluir en las guías de reflexión.
C) Identificar de manera más ajustada los cometidos y las responsabilidades del
GGCA.
Proposición 2: Las guías de reflexión constituyen una herramienta eficaz para realizar una captura primaria de los conocimientos y la experiencia que se adquieren durante la ejecución de las tareas de proyecto.
A partir del análisis de las respuestas presentadas en el apartado anterior pueden
formularse una serie de comentarios que reflejan los aprendizajes y nuevos conocimientos
capturados en las guías de reflexión.
Para referir las citas, se utiliza la siguiente codificación: (Nombre del proyecto, Guía de
reflexión, Número de pregunta de la cual se extrajo la respuesta); IR refiere a la guía de
reflexión para ingeniería de requisitos y GP refiere a la guía de reflexión para métricas de
gestión de proyectos.
1. Las preguntas o sentencias incluidas en las guías de reflexión orientaron las
actividades de reflexión precisamente sobre aquellos aspectos de las tareas de
proyecto directamente relacionados con los objetivos de aprendizaje y de creación
de conocimientos definidos inicialmente.
2. Las respuestas a las preguntas de reflexión denotan aprendizajes basado en la
experiencia práctica de haber realizado las actividades de proyecto. Expresiones
tales como “… fue muy bueno generar una lista de posibles preguntas…”
(COODESOR,IR,1), “…sirve de mucho mandarle al Cliente las preguntas …”
(GESA,IR,1), “...lo que mejoraría para una próxima oportunidad sería …”
(COODESOR,IR,9), “ …lo que debo mejorar para las próximas entrevistas es el
tiempo…” (GESA,IR,9) expresan reflexiones sobre las actividades realizadas que
denotan un aprendizaje basado en la experiencia sobre acciones exitosas que
169
deberían repetirse en el futuro como forma de mejorar la manera en que tales
actividades se llevan a cabo.
3. Las respuestas permiten identificar fuentes de conocimientos en la organización,
tanto tácitos como explícitos. Expresiones tales como “…consulta a los tutores…”
(COODESOR,IR,6), “… reuniones con tutores de rol … y con el tutor de grupo …”
(GESA,GP,4), “… con la ayuda de la tutora de de proyecto, del revisor y de la
tutora del rol de SQA…” (SCPI,GP,4) permiten identificar fuentes de conocimientos
tácitos. En forma análoga, expresiones como “…en internet y en diapositivas de
semestres anteriores…” (GESA,IR,6), “…se recurrieron a estudios de proyectos
anteriores…” (GESA,GP,4), “…el material que se encuentra disponible en el sitio
de Software Factory…” (SCPI,GP,7) identifican fuentes de conocimientos
explícitos.
4. Los conocimientos y la experiencia capturados en las guías permiten identificar
lecciones aprendidas, derivadas de la realización de las tareas de proyecto.
Expresiones tales como “…cosa que por falta de experiencia no lo hice y al
establecerlas ya con un tiempo x de transcurrido el proyecto se hace más difícil
recopilar…” (COODESOR,GP,8), “…si el esfuerzo es muy elevado … es mejor
tomar una métrica similar, no tan precisa, pero que sea fácil de medir y real…”
(SCPI,GP,5), “…hay que bajar las métricas a la realidad del proyecto…”
(SCPI,GP,6) denotan lecciones aprendidas durante la realización de las
actividades de proyecto.
5. Los conocimientos y la experiencia capturados en las guías permiten identificar
potenciales propuestas de mejores prácticas. Expresiones tales como “…realizar
una charla con el equipo para que entiendan la importancia del registro de
horas…” (COODESOR,GP,8), “…establecer las métricas a utilizar al comienzo
mismo del proyecto…” (COODESOR,GP,8) pueden considerarse
recomendaciones a seguir y que, convenientemente desarrolladas, pueden dar
lugar a la formulación de mejores prácticas.
170
Proposición 3: Responder a las preguntas o sentencias de reflexión tiene una baja incidencia respecto al tiempo total del proyecto.
Para los tres proyectos respecto de los cuales se tienen todos los datos de tiempos,
COODESOR, GESA y SCPI, puede verse que los porcentajes de tiempos insumidos en
responder a las preguntas de las guías de reflexión respecto de los tiempos totales de los
proyectos fueron del 0,21%, 0,17% y 0,07% respectivamente.
La diferencia en los porcentajes de tiempos entre el proyecto SCPI y los otros dos se
debe a que el proyecto SCPI tuvo una duración de 2912 horas mientras que para
COODESOR y GESA los tiempos de proyecto fueron, respectivamente, de 1371 y de 1261
horas. En consecuencia, para esos tres proyectos puede afirmarse que haber integrado a
las tareas propias de los proyectos las actividades de reflexión y de responder a las
preguntas de las guías, no implicó una sobrecarga de trabajo para los ingenieros de
requisitos y para los gerentes de los grupos de proyectos.
Proposición 4: Qué valoración dan los miembros de los grupos de proyecto a las guías de reflexión.
De las respuestas obtenidas al cuestionario de evaluación de las guías de reflexión
puede verse que:
A) Cinco de los siete respondientes consideraron que de haber dispuesto de las guías
de reflexión antes de iniciar sus actividades de proyecto, habrían podido
prepararse mejor para llevar a cabo tales actividades (pregunta 1 del cuestionario).
B) En el 98,33% de las respuestas dadas a las diferentes preguntas de las guías,
esas respuestas estuvieron basadas en la experiencia que los respondientes
adquirieron durante la realización de sus tareas de proyecto (pregunta 2 del
cuestionario).
C) En el 83,33% de los casos los respondientes consideran que las preguntas o
sentencias incluidas en las guías motivaron su reflexión acerca de las actividades
de proyecto realizadas (pregunta 3 del cuestionario).
D) En el 46,67% de las preguntas, el haber tenido que reflexionar sobre la respuesta
a dar a las mismas permitió a los respondientes identificar brechas en sus
conocimientos (pregunta 4 del cuestionario). Es revelador, en este caso, la
reflexión del ingeniero de requisitos del grupo GESA: “…el responder a estas
preguntas me hizo recordar o plantearme cosas que quizás las creía tener
solucionadas y que, a decir verdad, se me habían olvidado de tenerlas en
cuenta…”.
171
E) En el 66,67% de los casos, los respondientes estuvieron “de acuerdo” o “muy de
acuerdo” en cuanto a que haber reflexionado sobre su actuación en sus proyectos
les permitió identificar aspectos que consideran deberán mejorar en futuras
instancias (pregunta 5 del cuestionario).
F) Todos los respondientes (7 en 7) consideraron a las guías de reflexión como una
herramienta útil para propiciar y facilitar la reflexión sobre sus conocimientos y
sobre su actuación durante el desarrollo de los proyectos (pregunta 6 del
cuestionario).
Proposición 5: El taller de educción de conocimientos y experiencia permite consensuar las lecciones aprendidas y las propuestas de mejores prácticas identificadas en las guías de reflexión, así como obtener nuevos aportes de conocimientos y experiencia adquiridos durante la realización de las actividades de proyecto.
En base a los resultados del taller que fueron presentados en el apartado 5.4.3 pueden
formularse los siguientes comentarios:
1. La participación en el taller permitió a los asistentes compartir sus experiencias y
conocer las experiencias de los otros asistentes, propiciándose así la compartición
y la diseminación de los conocimientos y los aprendizajes adquiridos durante la
realización de sus actividades de proyecto.
2. Tal como se muestra en la tabla 5.22, diez de las catorce conclusiones resultantes
del taller pueden trazarse “hacia atrás” hasta los objetivos de aprendizaje y de
creación de conocimientos establecidos inicialmente, pasando por las respuestas
dadas a las preguntas de las guías de reflexión para ingeniería de requisitos.
172
Conclusiones del taller
Respuesta en la guía de reflexión
Objetivos iniciales de aprendizaje y de creación de conocimientos
1.1 COODESOR.IR.3, GESA.IR.2, InvPortal,IR.3
Planificación de entrevistas para educción de requisitos
1.2 COODESOR.IR.1, GESA.IR.1, SCPI.IR.1
Planificación de entrevistas para educción de requisitos
1.3 InvPortal.IR.1 Planificación de entrevistas para educción de requisitos
1.5 GESA.IR.1 Planificación de entrevistas para educción de requisitos
2.1 COODESOR.IR.1, SCPI.IR.4 Interacción con el entrevistado
2.2 InvPortal.IR.1 Interacción con el entrevistado
2.3 GESA.IR.2, SCPI.IR.8 Interacción con el entrevistado
3.1 COODESOR.IR.8, SCPI.IR.8 Habilidades personales del ingeniero de requisitos
4.1 SCPI.IR.7 Entrenamiento inicial para ingenieros de requisitos
4.2 COODESOR.IR.7, SCPI.IR.7, InvPortal.IR.7
Entrenamiento inicial para ingenieros de requisitos
Tabla 5.22: Conclusiones del taller y respuestas en las guías de reflexión
3. Como también puede verse en la tabla 5.22, la no asistencia a la sesión de taller
de la ingeniera de requisitos de uno de los grupos de proyecto (InvPortal) no
impidió tener en consideración sus reflexiones y la experiencia que adquirió
durante la realización de sus tareas de proyecto dado que fue posible tomarlas
directamente de sus respuestas a la guía de reflexión para ingeniería de requisitos.
Este resultado, además, refuerza el resultado precedente (proposición 2a) en
cuanto a la eficacia de las guías de reflexión como herramienta para capturar
conocimientos y experiencia durante la realización de las actividades del proyecto.
4. La sesión de taller permitió obtener de los asistentes nuevos aportes relativos a los
temas en discusión que no estaban presentes en las respuestas a las preguntas
de las guías de reflexión pero que están directamente relacionados a los objetivos
de aprendizaje y de creación de conocimientos establecidos inicialmente. Dichos
aportes se muestran en la tabla 5.23.
Conclusiones del taller
Objetivos iniciales de aprendizaje y de creación de conocimientos
1.4 Planificación de entrevistas para educción de requisitos
3.2 Habilidades personales del ingeniero de requisitos
3.3 Habilidades personales del ingeniero de requisitos
4.3 Entrenamiento inicial para ingenieros de requisitos
Tabla 5.23: Nuevos aportes relacionados a los temas del taller
173
Proposición 6: Qué valoración dan los miembros de los grupos de proyecto al Taller de Educción de Conocimientos y Experiencias.
De las respuestas obtenidas al cuestionario de evaluación del taller de educción de
conocimientos y experiencia puede verse que:
A) En relación con los aspectos organizativos del taller, 11 de las 12 respuestas
(91,67%) indican estar de acuerdo o muy de acuerdo en que los objetivos del taller
estuvieron claramente definidos, que el material proporcionado como insumo fue
satisfactorio y que la duración del taller y el lugar donde se desarrolló fueron
adecuados.
B) En cuanto a la participación de los asistentes, todos estuvieron de acuerdo o muy
de acuerdo en valorar de manera positiva esa instancia de participación y que el
haber podido compartir sus experiencias y conocer las experiencias de los demás
participantes les permitió aumentar sus conocimientos sobre los temas tratados.
C) En relación con los temas tratados durante el taller, todos los asistentes estuvieron
de acuerdo o muy de acuerdo en que los mismos resultaron de interés personal.
5.6 Conclusiones del estudio
En base al análisis anterior pueden formularse las siguientes conclusiones generales
del estudio:
1. El modelo “ele” es viable de ser implementado e integrado a las actividades de
los proyectos software y permite gestionar el conocimiento y el aprendizaje basado
en la experiencia que se adquiere durante la realización de las tareas de proyecto.
2. Las guías de reflexión fueron bien aceptadas por los respondientes, orientaron la
reflexión sobre aspectos concretos de las actividades de proyecto, cumplieron su
finalidad de ser una herramienta eficaz para capturar nuevos conocimientos y
aprendizajes basados en la experiencia, y que integrarlas a las actividades de
proyecto no constituye una sobrecarga de trabajo para los miembros de los
equipos de proyectos.
3. El taller de educción de conocimientos y experiencia permitió a los asistentes
compartir sus conocimientos y conocer las experiencias de los demás, así como
obtener y capturar nuevos aportes de conocimientos y experiencia sobre los temas
en discusión que no fueron inicialmente capturados en las guías de reflexión pero
que estaban presentes en forma tácita.
174
4. La secuencia de actividades “establecer objetivos de aprendizaje y de creación de
conocimientos”, “elaborar, distribuir y responder a las guías de reflexión”,
“desarrollar el taller de educción de conocimientos y experiencia” constituye el eje
central del modelo que permite progresar desde un conjunto de prácticas y
procesos software que la organización busca mejorar hasta la obtención de
lecciones aprendidas y de propuestas de mejores prácticas relativas a esas
prácticas y procesos.
5.7 Validez y fiabilidad del estudio
De acuerdo con Yin [Yin, R., 2003], cuatro tipos de pruebas son comúnmente
utilizados para establecer la calidad de un estudio de casos:
A) Validez de construcción: refiere al establecimiento de las medidas operacionales
correctas para los conceptos que están siendo estudiados.
B) Validez interna: refiere al establecimiento de relaciones causales por medio de las
cuales se muestra que ciertas condiciones conducen a otras que, a su vez, se
distinguen de condiciones espurias.
C) Validez externa: refiere a establecer el dominio al que pueden generalizarse los
hallazgos del estudio.
D) Fiabilidad: refiere a mostrar que las operaciones del estudio, tales como los
procedimientos de recolección de datos, pueden repetirse con los mismos
resultados.
5.7.1 Validez de la construcción
Para establecer la validez de construcción, Yin [Yin, R., 2003] propone como tácticas
el uso de múltiples fuentes de evidencia y el establecimiento de una cadena de evidencia.
5.7.1.1 Múltiples fuentes de evidencia Con respecto a la proposición 1, se utilizaron las notas de observación participante del
autor en las reuniones del GGCA y el documento del manual de implementación del modelo,
elaborado a partir del proceso de implementación seguido.
Para el grupo de proposiciones relativas a las guías de reflexión (proposiciones 2, 3 y
4) se utilizaron las guías de reflexión respondidas por los miembros de los grupos de
proyecto participantes, los cuestionarios de evaluación de esas guías y los datos relativos a
los tiempos de proyecto provenientes de los documentos propios de los grupos
participantes.
175
Para el grupo de proposiciones relativas al taller de educción de conocimientos y
experiencia (proposiciones 5 y 6) se utilizaron como fuentes la observación participante del
autor en ese taller, el reporte de resultados elaborado por los miembros del GGCA y el
cuestionario de evaluación del taller.
5.7.1.2 Cadena de evidencia Este aspecto de la validez de construcción fue el elemento que guió la definición de la
estructura del reporte del estudio en este capítulo. En efecto, yendo desde atrás hacia
delante en el reporte, el análisis de los resultados (5.5), la presentación de estos resultados
(5.4) y la descripción del desarrollo general de la investigación (5.3) fueron expuestos en el
mismo orden y en correspondencia lineal con las proposiciones del estudio (5.2.2) que se
derivaron de las pregunta inicial de investigación (5.2.1).
Esta pregunta general de investigación se formuló a partir de las críticas expuestas en
el capítulo 3, las cuales reflejan los comentarios finales expuestos en el capítulo 2 sobre el
estado de la cuestión.
Por otra parte, y siguiendo la recomendación de Yin [Yin, R., 2003], el reporte cita
porciones relevantes de los documentos y cuestionario usados en la investigación, los
cuales se encuentran en la base de datos del estudio.
5.7.2 Validez interna
Tanto Yin [Yin, R., 2003] como Perry, Sim y Easterbrook [Perry, D. et al., 2004]
comparten la opinión de que este tipo de validez aplica a los estudios explicativos y
causales, y no a los de carácter exploratorio o descriptivo como los que ha tenido este
estudio.
5.7.3 Validez externa
Yin [Yin, R., 2003] reconoce que el problema de la validez externa ha sido uno de las
mayores barreras para el estudio de casos, básicamente porque sus críticos contrastan
implícitamente la situación con la investigación mediante encuestas en las cuales la muestra
(si se selecciona correctamente) se generaliza a un universo poblacional más grande. Sin
embargo, el propio Yin [Yin, R., 2003], así como Perry, Sim y Easterbrook [Perry, D. et al.,
2004] consideran que esta analogía de muestras y universos es incorrecta cuando se trata
de estudio de casos. A este respecto, tanto Yin [Yin, R., 2003] como Eisenhardt [Eisenhardt,
K., 1989] proponen el uso de lo que denominan “lógica de replicación”, entendida ésta como
análoga a la que se utiliza en la realización de experimentos múltiples.
176
La decisión inicial del diseño de la investigación realizada en cuanto a incluir cuatro
grupos de proyecto en lugar de uno estuvo motivada precisamente por este aspecto. En
este sentido, los cuatro grupos de proyecto recibieron igual tratamiento en todos los
aspectos del estudio:
A) Utilizaron las mismas guías de reflexión.
B) Los miembros de los equipos de proyecto participaron de las mismas reuniones de
explicación de esas guías.
C) Se les administró los mismos cuestionarios de evaluación, tanto sobre las guías de
reflexión como sobre el taller de educción de conocimientos y experiencia.
D) Participaron del mismo taller de educción de conocimientos y experiencia.
Corresponde mencionar, además, que a los miembros de los equipos de proyecto
participantes no se les proporcionó ningún tipo de incentivo por participar en este estudio.
5.7.4 Fiabilidad
Para establecer la fiabilidad de un estudio de casos, tanto Yin [Yin, R., 2003] como
Perry, Sim y Easterbrook [Perry, D. et al., 2004] proponen la construcción de una base de
datos del estudio con todos los datos e informaciones recolectadas durante el estudio. La
base de datos para este estudio se encuentra en el Apéndice 3.
177
6. CONCLUSIONES
El ámbito en el que se enmarca esta tesis doctoral es el de la GC y del aprendizaje
basado en la experiencia que los miembros de los equipos de proyecto adquieren durante el
desarrollo de proyectos software con el propósito de utilizar esos conocimientos y
aprendizajes como sustento para las actividades de mejora a las prácticas y procesos
software en uso en una organización.
En el capítulo 2, referido al estado de la cuestión, se presentaron los principales
conceptos relativos al conocimiento y a los diferentes procesos para su gestión, al
aprendizaje individual basado en la experiencia y al aprendizaje organizacional.
Posteriormente, en ese mismo capítulo se enfocó el tratamiento de estos temas al ámbito
específico de la IS, particularmente en lo referente a la manera en que la GC y de la
experiencia contribuye a las actividades de mejora de las prácticas y procesos software en
uso en una organización. Este capítulo finalizó con la presentación de diversas iniciativas y
herramientas para la gestión del conocimiento y de la experiencia en el ámbito particular de
la ingeniería de software.
El análisis y la discusión de esas iniciativas y herramientas revelaron carencias en las
propuestas analizadas, lo cual dio lugar a la formulación de las críticas presentadas en el
capítulo 3 y a la definición del problema abordado en la tesis.
El capítulo 4, estuvo dedicado a presentar la solución propuesta al problema planteado
y a describir en detalle la estructura y los componentes del modelo propuesto para la GC y
del aprendizaje basado en la experiencia en forma integrada tanto a las actividades de los
proyectos software como a las actividades de mejora a las prácticas y procesos software en
uso en una organización.
El modelo propuesto, denominado modelo “ele”, contempla todos los procesos de
creación y de GC y del aprendizaje experiencial que fueron expuestos en el capítulo 2, así
como también resuelve los problemas y críticas planteados a las iniciativas preexistentes,
formuladas en el capítulo 3.
Junto con el modelo propuesto, en ese mismo capítulo, se presentaron las
denominadas guías de reflexión como una nueva herramienta para capturar los
conocimientos y los aprendizajes basados en la experiencia que los miembros de los
equipos de proyecto adquieren durante la realización de sus actividades de proyecto y
también se expuso un método para elaborar las preguntas o sentencias de reflexión que
conforman las guías.
178
Como otros elementos constitutivos del modelo se presentaron las definiciones, los
propósitos y los procedimientos de implementación del catálogo de conocimientos y experiencia, del inventario de conocimientos y experiencia, del taller de educción de conocimientos y experiencia y del repositorio de lecciones aprendidas y de mejores prácticas.
Para mostrar la viabilidad y utilidad del modelo propuesto, se llevó a cabo una
implementación práctica del mismo en una organización de desarrollo software. En este
sentido, en el capítulo 5 se presentó el estudio del caso de implementación del modelo en
general y de las guías de reflexión y el taller de educción de conocimientos y experiencia en
particular. En ese capítulo se presentó el diseño de la investigación siguiendo la
metodología del estudio de casos, donde se definieron la pregunta de investigación y las
proposiciones derivadas de la misma, se estableció la unidad de análisis del caso, se
identificaron las fuentes de los datos, y se describieron los instrumentos para su recolección
y los criterios para analizarlos.
La investigación realizada permitió mostrar que el modelo propuesto es viable de ser
implementado e integrado a las actividades de los proyectos software, que esta integración
no implica una sobrecarga excesiva de trabajo para los miembros de los equipos de
proyectos, y que, a partir de la aplicación del modelo, es posible identificar lecciones
aprendidas y propuestas de mejores prácticas relativas a las prácticas y procesos software
en uso en una organización.
Los aportes realizados por esta tesis son los siguientes:
A) Teóricos:
a. Un modelo iterativo para la GC y de la experiencia cuyas fases, tareas,
procedimientos y artefactos constitutivos se integran tanto a las actividades
de los proyectos software como a las de mejora de las prácticas y procesos
(capítulo 4).
b. Un estudio de las diversas propuestas y enfoques existentes para la GC y de
la experiencia en el ámbito particular de la IS (capítulo 2).
B) Metodológicos:
a. Una herramienta, denominada Guía de Reflexión, que formaliza el proceso y
las actividades de captura de conocimientos y experiencia (capítulo 4).
b. Un método para definir y elaborar las preguntas o sentencias de reflexión a
ser incluidas en las guías de reflexión, a partir de un conjunto de objetivos de
aprendizaje y de creación de conocimientos previamente establecidos
(capítulo 4).
179
c. Un estudio del caso de la implementación del modelo propuesto, siguiendo la
metodología correspondiente a este tipo de estudio y que combina aspectos
tanto cualitativos como cuantitativos (capítulo 5).
C) Prácticos:
a. Una implementación práctica del modelo propuesto que muestra la manera
en que se llevan a cabo las diferentes actividades del modelo (apéndice 4).
181
7. FUTURAS LÍNEAS DE INVESTIGACIÓN
A partir del diseño último del modelo “ele” y de su implementación práctica, surgen
varias líneas de desarrollo y de investigación futuras.
En primer término, y con respecto al modelo en general, se buscará estudiar su
implementación en otras áreas de la IS, tales como diseño arquitectónico, construcción y
calidad del software, así como a las actividades de gerenciamiento de los proyectos.
En segundo lugar, y también con respecto al modelo, se propone investigar y analizar
la necesidad de incorporarle ajustes de modo que sus actividades y herramientas de GC y la
experiencia puedan integrarse de manera explícita a modelos establecidos para la mejora
de procesos software como el CMMI.
Una tercera línea de trabajo la constituye el desarrollo de una herramienta software
que soporte las diferentes fases y tareas del modelo para, posteriormente, hacerla
evolucionar hasta convertirla en un sistema integral para la gestión del conocimiento y de la
experiencia.
Con respecto a las guías de reflexión, su utilización en la implementación realizada
apuntó esencialmente a los aspectos de proceso; es decir, a la manera en que se llevaron a
cabo las actividades de proyecto a las que referían las preguntas o sentencias de reflexión.
Una nueva vertiente para estas guías es la de incluir también preguntas o sentencias
de reflexión relativas a los productos que son generados en esas actividades.
Por ejemplo, en relación con la arquitectura software, dos aspectos son
particularmente importantes: las decisiones de diseño y la justificación de esas decisiones
(“design rationale”). En este sentido, Farenhorst, Lago y van Vliet [Farenhorst, R. et al.,
2007] mencionan que las decisiones de diseño arquitectónico están plasmadas (“embodied”)
en la arquitectura software y que la fundamentación de esas decisiones a menudo no se
almacena ni se comunica en forma explícita, y que, en consecuencia, ese valioso
conocimiento se disipa.
Por otra parte, y en virtud de los resultados obtenidos con la aplicación de las guías,
se considera que las mismas pueden adquirir “vida propia”; es decir, que su utilización como
herramienta de captura de conocimientos y experiencia se extienda más allá del modelo
propuesto, a otros ámbitos y actividades no necesariamente relacionados con la IS.
182
Finalmente, el carácter exploratorio del estudio realizado ha permitido identificar
nuevas preguntas de investigación a abordar en el futuro, entre las que se destacan las
siguientes:
A) En comparación con la manera tradicional de realizar un análisis post mortem de
proyectos, ¿es posible obtener mejores resultados si las fases de preparación y de
recolección de datos se realizan durante el desarrollo del proyecto utilizando las
guías de reflexión en lugar de hacerlas luego que el proyecto ha finalizado o
después de haber alcanzado un hito significativo?
B) ¿Es posible que las reflexiones que los miembros de los equipos de proyecto
registran en las guías de reflexión se tornen más ricas y detalladas si se los asiste
con la figura de un facilitador?
183
8. BIBLIOGRAFÍA
1. Abou-Zeid, 2001 Abou-Zeid, E.: A knowledge management reference model, Journal of Knowledge Management, 5 (5), 2001, pp. 486-499.
2. Abran, A. et al., 2004 Abran, A., Moore, J. (eds.): Guide to the software engineering body of knowledge), Los Alamitos, IEEE Computer Society, 2004.
3. Adey, M., et al., 1999 Adey, M., Early, F., Foster, M.: The mentors handbook, Londres, Herts Tech, 1999.
4. Alavi, M. et. al., 2001 Alavi, M., Leidner, D.: Knowledge management and knowledge management systems: conceptual foundations and research issues, MIS Quarterly, Vol. 25, Nº 1, 2001, pp. 107-136.
5. Alavi, M., 2001 Alavi, M.: Managing organizational knowledge, en Zmud, R. (ed.), Framing the domains of IT management, Cincinnati, Pinnaflex Educational Resources, 2000, pp. 15-28.
6. Alagarsamy, K. et al., 2008
Alagarsamy, K., Justus S., Iyakutti, K.: The knowledge based software process improvement program. A rational analysis, Proceedings of the 41th Hawaii International Conference on System Sciences, 2008, p. 61.
7. Allen, M., 1998 Allen, M.: Mentoring, Sunnyvale, Echelon Learning, 1998.
8. Althoff, K. et al., 2001 Althoff, K., Decker, B., Hartkopf, S., Jedlitschka, A., Nick, M., Rech, J.: Experience management. The Fraunhofer IESE experience factory, Proceedings of the Industrial Conference Data Mining, Liepzig, 2001, pp. 12-29.
9. Anderson, L. et al, 2001 Anderson, L., Krathwohl, D. (eds.): A taxonomy for learning, teaching and assessing, New York, Addison Wesley, 2001.
10. Antunes, B. et al., 2007 Antunes, B., Seco N., Gomes, P.: Knowledge management using semantic web technologies: An application in software development, Proceedings of the Fourth International Conference on Knowledge Capture, 2007, pp. 187-188.
11. Arent, J. et al., 2000 Arent, J., Norbjerg, J.: Software Process Improvement as Organizational Knowledge Creation: A Multiple Case Analysis, Proceedings of the 33rd Hawaii International Conference on System Sciences, 2000, p. 4045.
12. Arent, J. et al., 2001 Arent, J., Pedersen, M., Norbjerg, J.: Strategies for organizational learning in SPI, en: Mathiassen, L., Pries-Heje, J., y Ngwenyama, O. (eds.): Improving software organizations. From principles to practice, Upper Saddle River, Addison-Wesley, 2001, pp. 235-253.
184
13. Argyris, C., 1977 Argyris, C.: Double loop learning in organizations, Harvard Business Review, 55 (5), 1977, pp. 115-125.
14. Argyris, C. et al, 1978 Argyris, C., Schön, S.: Organizational Learning: A theory in action perspective, Addison-Wesley, 1978.
15. Aurum, A. 2003 Aurum, A. Supporting structures for managing software engineering knowledge, en Aurum, A. et al. (eds.) Managing Software Engineering Knowledge, Berlin, Springer, 2003, pp. 69-72.
16. Aurum, A. et al., 2003 Aurum, A., Jeffery, R., Wohlin, C., Handzic, M. (eds.) Managing Software Engineering Knowledge, Berlin, Springer, 2003.
17. Azuma, M. et al., 2004 Azuma, M., Coallier, F., Garbajosa, J.: How to apply the Bloom Taxonomy to Software Engineering, Proceedings of the 11th International Workshop on Software Technology and Engineering Practice (STEP 04), 2004, pp. 117-122.
18. Babar, M. et al., 2007 Babar, M., Gorton, I.: A tool for managing software architecture knowledge, Proceedings of the 2nd Workshop on Sharing and Reusing architectural, SHARK-ADI, 2007, pp. 11-18.
19. Basili, V. et al., 1994 Basili, V., Caldeira, G., Rombach, H.: The experience factory, en Marciniak, J. (ed.) Encyclopedia of software engineering, New York, J. Wiley & Sons, 1994, pp. 469-476.
20. Basili, V. et al., 2001 Basili, V., Lindvall, M., Costa, P.: Implementing the experience factory as a set of experience bases, International Conference on Software Engineering and Knowledge Engineering (SEKE ’01), Buenos Aires, 2001, pp. 102-109.
21. Basili, V. et al., 2001 Basili, V., Costa, P., Lindvall, M., Mendonca, M., Seaman, C., Tesoriero, R., Zelkowitz, M.: An experience management system for a software engineering research organization, 26th Annual NASA Goddard Software Engineering Workshop. 2001, pp. 29-35.
22. Basili, V. et al., 2002 Basili, V., Seaman, C.: The experience factory organization, IEEE Software, 19 (3), May/June 2002, pp. 30-31.
23. Bernal, C., 2006 Bernal, C.: Metodología de la investigación, México, Pearson, 2da. ed., 2006.
24. Bhatt, G., 2001 Bhatt, G.: Knowledge management in organizations: examining the interactions between technologies, techniques and people, Journal of Knowledge Management, Vol. 5, Nº 1, 2001, pp. 68-75.
185
25. Bierly, P., Dale, P., 2002
Bierly, P., Dale, P.: Aligning human resource management practices and knowledge strategies. A theoretical framework, en Choo, C. W. y Bontis, N.: The Strategic Management of Intellectual Capital and Organizational Knowledge, Oxford, Oxford University Press, 2002, pp. 277-296.
26. Birk, A. et al., 1999 Birk, A., Surmann S., y Althoff, K.: Applications of knowledge acquisition in experimental software engineering, European Knowledge Acquisition Workshop, EKAW’99, 1999, pp. 67-84.
27. Birk, A. et. al., 2002 Birk, A., Dingsoyr, T., Stalhane, T.: Postmortem: never leave a project without it, IEEE Software,19(3), May/June 2002, pp. 43-45.
28. Bjornson, F., 2007 Bjornson, F.: Knowledge management in software process improvement, Tesis doctoral, Department of Computer and Information Science, Norwegian University of Science and Technology, 2007.
29. Blaxter, L. et al., 2000 Blaxter, L., Hughes, C. y Tight, M.: Cómo se hace una investigación, Barcelona, Gedisa, 2000.
30. Bloom, B. et al., 1979 Bloom, B. (Ed.), Engelhart, M., Furst, E., Hill, W., Krathwohl, D.: Taxonomía de los objetivos de educación. La clasificación de las metas educacionales, Buenos Aires, El Ateneo, 7ma. ed., 1979.
31. Boisot, M., 1998 Boisot, M.: Knowledge assets: securing competitive advantage in the information economy, Oxford, Oxford University Press, 1998.
32. Bollinger, A., et al., 2001
Bollinger, A., Smith, R.: Managing organizational knowledge as a strategic asset, Journal of Knowledge Management, Vol. 5, N° 1, 2001, pp. 8-18.
33. Bonache, J., 1999 Bonache, J.: El estudio de casos como estrategia de construcción teórica: características, críticas y defensas, Universidad Carlos III de Madrid, Madrid, 1999.
34. Borjesson, A. et al., 2004
Borjesson, A., Mathiassen, L.: Successful process implementation, IEEE Software, 21 (4), July/August 2004, pp. 36-44.
35. Boud, D. et al., 1985 Boud, D., Cohen, R, Walker, D.: Reflection: turning experience into learning, Kogan Page, 1985.
36. Bourque, P. et al, 2003 Bourque, P., Buglione, L., Abran, A., April, A.: Bloom’s taxonomy levels for three software engineer profiles, Proceedings of the 10th International Workshop on Software Technology and Engineering Practice (STEP 03), 2003, pp. 123-129.
186
37. Briand, L., 2002 Briand, L.: On the many ways software engineering can benefit from knowledge engineering, Proceedings of the 14th International Conference on Software Engineering and Knowledge Engineering, Ischia, Italy, 2002, pp. 3-6.
38. Budgen, D. et al., 2007 Budgen, D., Brereton, P.: Realising evidence-based software engineering (REBSE-2). A report from the Workshop helded at ICSE 2007, ACM SIGSOFT Software Engineering Notes, 32 (4), July 2007, pp. 36-39.
39. Caldwell, F., 2002 Caldwell, F.: Knowledge management, Intranets & portals. What’s next?, Closing Keynote, KMWorld & Intranets 2002 Conference, 2002.
40. Capote, J. et al., 2008 Capote, J., Llanten, C., Pardo, C., González, A., Collazos, A.: Gestión del conocimiento como apoyo para la mejora de procesos software en las micro, pequeñas y medianas empresas, Revista Ingeniería e Investigación, 28 (1), 2008, pp. 137-145.
41. Carver, J. et al., 2003 Carver, J., Jaccheri, L., Morasca, S., Shull, F.: Issues in using students in empirical studies in software engineering education, Proceedings of the 9th International Symposium on Software Metrics, 2003, pp. 239-251.
42. Chau, T. et al., 2005 Chau, T., Maurer, F.: A case study of wiki-based experience repository at a medium-sized software company, University of Calgary, Department of Computer Science, 2005.
43. Chongsringam, P. et al., 2007
Chongsringam, P., Prompoon, N.: A knowledge management system for supporting CMMI organizational knowledge, 11th National Computer Science and Engineering Conference, Thailand, 2007.
44. Choudrie, J. et al., 2006 Choudrie, J., Selamat, M.: The consideration of meta-abilities in tacit knowledge externalization and organizational learning, Proceedings of the 39th Hawaii International Conference on System Sciences, 2006, p. 149
45. Clifford, J. et al., 2007 Cliford, J., Thorpe, S.: Workplace learning and development, London, Kogan-Page, 2007.
46. Cohen, W. et al, 1990 Cohen, W., Levinthal, D.: Absorptive capacity: A new perspective on learning and innovation, Administrative Science Quarterly, 35 (1), Special Issue: Technology, Organizations, and Innovation, 1990, pp. 128-152.
47. Confessore, S., 1997 Confessore, S.: Building a learning organization: Communities of practice, self-directed learning, and continuing medical education, The Journal of Continuing Education in the Health Professions, Volume 17, 1997, pp. 5-11.
187
48. Conradi, R. et al., 2000 Conradi, R., Lindvall M., Seaman, C.: Success factors for software experience bases: what we need to learn from other disciplines, ICSE ‘2000, Limerick, 2000, pp. 113-119.
49. Conway, C., 1998 Conway, C.: Strategies for mentoring: a blueprint for successful organizational development, Toronto, Wiley, 1998.
50. Cooper, L., 2007 Cooper, L.: Converting project team experience to organizational learning. A case study, Proceedings of the 40th Hawaii International Conference on System Sciences, 2007, p. 195.
51. Cooper, L. et al., 2005 Cooper, L., Majchrzak, A., Faraj, S.: Learning from project experiences using a legacy-based approach, Proceedings of the 38th Hawaii International Conference on System Sciences, 2005, p. 253
52. Corbetta, P., 2003 Corbetta, P.: Metodología y técnicas de investigación social, Madrid, McGraw Hill, 2003
53. Corcho, O. et al., 2006 Corcho, O., Fernández-López, M., Gómez-Perez, A.: Ontological engineering. Principles, methods, tools and languages, en: Calero, C., Ruiz, F., Piattini, M. (eds.): Ontologies for software engineering and software technology, Berlin, Springer, 2006, pp. 1-39
54. Creswell, J., 1994 Creswell, J.; Research design. Quantitative and qualitative approaches, Thousand Oaks, Sage, 1994
55. Dalkir, K., 2005 Dalkir, K.: Knowledge management in theory and practice, Oxford, Elsevier, 2005
56. Davenport, T. et al., 1998
Davenport, T., Prusak, L.: Working knowledge. How organizations manage what they know, Boston, Harvard Business School Press, 1998
57. Decker, B. et al., 2005 Decker, B., Ras., E., Rech, J., Klein, B., Hoecht, C.: Self-organized reuse of software engineering knowledge supported by semantic wikis, Workshop on Semantic Web Enabled Software Engineering, Galway, Irlanda, 2005
58. del Moral, A. et al., 2007
del Moral, A., Pazos, J., Rodríguez Fernández, E., Rodríguez-Patón, A., Suárez, S.: Gestión del conocimiento, Madrid, Paraninfo, 2007
59. Deming, E., 1986 Deming, E.: Out of the crisis, Cambridge, MIT Press, 1986
60. Desouza, K. et al., 2005
Desouza, K., Dingsoyr, T., Awazu Y.: Experiences with conducting project postmortems, Proceedings of the 38th Hawaii International Conference on System Sciences, 2005, p. 233
188
61. Desouza, K. et al., 2006
Desouza, K., Awazu Y., Baloh, P.: Managing knowledge in global software development efforts: Issues and practices, IEEE Software, September/October 2006, pp. 30-37
62. DiBella, A., et al., 1998 DiBella, A., Nevis, E.: How organizations learn: An integrated strategy for building learning capability, San Francisco, Jossey-Bass, 1998
63. Dingsoyr, T. et al., 2001 Dingsoyr, T., Moe, N., Nytro, O.: Augmenting experience reports with lightweight postmortem reviews, en Bomarius, F., Komi.Sirvio, S. (eds.): PROFES 2001, LNCS 2188, 2001, pp. 167-181
64. Dingsoyr, T., 2002 Dingsoyr, T.: Knowledge management in medium-sized software consulting companies, Tesis Doctoral, Norwegian University of Science and Technology, Trondheim, Noruega, 2002
65. Dingsoyr, T. et al., 2003a
Dingsoyr, T., Conradi, R.: Usage of intranet tools for knowledge management y a medium-sized software consulting company, en Aurum, A. et al.: Managing Software Engineering Knowledge, Berlin, Springer-Verlag, 2003, pp. 49-68
66. Dingsoyr, T. et al., 2003b
Dingsoyr, T., Royrvik, E.: An empirical study of an informal knowledge repository in a medium–sized software consulting company, Proceedings of the International Conference on Software Engineering, Portland, USA, 2003, pp. 84-92
67. Dyba, T., 2000 Dyba, T.: An instrument for measuring the key factors of success in software process improvement, Empirical Software Engineering, Nº 5, 2000, pp. 357-390
68. Dul, J. et al., 2008 Dul, J., Hak., T.: Case study methodology in business research, Burlington, Butterworth-Heinemann, 2008
69. Easterbrook, S. et al., 2008
Easterbrook, S., Singer, J., Storey, M., Damian, D.: Selecting empirical methods for software engineering, research, en: Shull, F., Singer, J., Sjøberg, D. (eds.): Guide to advanced empirical software engineering, Berlin, Springer, 2008, pp. 285-311
70. Edwards, L., 2003 Edwards, L.: Coaching: the latest buzzword or a truly effective management tool?, Industrial and Commercial Training, Vol. 35, N° 7, 2003, pp. 298-300
71. Eisenhardt, K., 1989 Eisenhardt, K.: Building theories from case study research, Academy of Management Review, 14 (4), 1989, pp. 532-550
189
72. Elisberg, T. et al., 2006 Elisberg, T., Norjberg, J., Pries-Heje, J.: Advantages and limitations of knowledge networks as a mechanism for sustaining software process improvement, Proceedings of the 8th International Workshop on Learning Software Organizations, 2006
73. Eppler, M., 2001 Eppler, M.: Making knowledge visible through intranet knowledge maps: concepts, elements, cases, Proceeding of the 34th Annual Hawaii International Conference on System Sciences, 2001, p. 4030
74. Falbo, R. et al., 2004a de Almeida Falbo, R., Mota Borges, L., Rosa Valente, F.: Using knowledge management to improve software process performance in a CMM level 3 organization, Proceedings of the Fourth International Conference on Quality Software, 2004, pp. 162-169
75. Falbo, R. et al., 2004b de Almeida Falbo, R., Ruy., F., Bertollo, G., Togneri, D.: Learning how to manage risks using organizational knowledge, Proceedings of the 6th International Workshop on Learning Software Organizations, 2004, pp. 7-18
76. Falbo, R. et al., 2005 de Almeida Falbo, R., Pezzin, J., Schwambach,M.,: A multi-agent system for knowledge delivery in a software engineering environment, 17th International Conference on Software Engineering and Knowledge Engineering, 2005, pp. 253-258
77. Farenhorst, R. et al., 2007
Farenhorst, R., Lago, P., van Vliet, H.: Prerequisites for successful architectural knowledge sharing, Proceedings of the 2007 Australian Software Engineering Conference, 2007, pp. 27-58
78. Fiol, C., et al., 1985 Fiol, C., Lyles, M.: Organizational learning, Academy of Management Review, 10 (4), October 1985, pp. 803-813
79. Friss de Kereki, I., 2003 Friss de Kereki, I.: Modelo para la creación de entornos de aprendizaje basados en técnicas de gestión del conocimiento, Tesis doctoral, Facultad de Informática, Universidad Politécnica de Madrid, Madrid, España, 2003
80. Fuggetta, A., 2000 Fuggetta, A.: Software process: A roadmap, Proceeding of the 22 International Conference on Software Engineering, 2000
81. García, D., 1997 García, D.: El grupo. Métodos y técnicas participativas, Buenos Aires, Espacio, 1997
82. Garvin, D., 1993 Garvin, D.: Building a learning organization, Harvard Business Review, July/August 1993, pp. 78-90
83. Gore, E., 2003 Gore, E.: Conocimiento colectivo, Buenos Aires, Gránica, 2003
190
84. Gottschalk, P., 2004 Gottschalk, P.: Strategic knowledge management technology, Harshey, Idea Group, 2004
85. Gupta, J., et. al., 2004 Gupta, J., Sharma, S.: Creating knowledge-based organizations, Harshey, Idea Group Inc., 2004
86. Hansen, M. et al., 1999 Hansen, M., Nohria, N., Tierney, T.: What’s your strategy for managing knowledge?, Harvard Business Review, Vol. 77, Nº 2, 1999, pp. 106-116
87. Handzic, M., 2003 Handzic, M.: Why it is important to manage knowledge?, en Aurum, A. et al.: Managing software engineering knowledge, Berlin, Springer-Verlag, 2003, pp. 1-4
88. Harrison, W., 2003 Harrison, W.: A software engineering lessons learned repository, Proceedings of the 27th Annual NASA Goddard/IEEE Software Engineering Workshop, 2003, pp. 139-143
89. Hays, P., 2004 Hays, P.: Case study research, en: deMarrais, K., Lapan, S. (eds.): Foundations for research. Methods of inquiry in education and the social sciences, New Jersey, L. Erlbaum, 2004, pp. 217-234.
90. Hazzan, O. et al., 2005, Hazzan, O., Tomayko, J.: Reflection and abstraction in learning software engineering’s human aspects, IEEE Computer 38 (6), 2005, pp. 39-45.
91. Henninger, S., 2001 Henninger, S.: Organizational learning in dynamics domains, en Althoff, K., Feldmann, R., Muller, W. (eds.): Advanced in learning software organization, Berlin, Springer, 2001, p. 8.
92. Henninger, S., 2002 Henninger, S.: Tool support for experience-based methodologies, en: Henninger, S., Maurer, F. (eds.): Learning software organizations 2002, LNCS 2640, Berlin, Springer, 2003, pp. 44-59.
93. Hernandez, R. et al., 2003
Hernández, R., Fernández, C., Baptista, P.: Metodología de la investigación, México, McGraw Hill, 3ra. ed., 2003.
94. Hoag, K., 2001 Hoag, K.: Skill development for engineers. An innovative model for advanced learning in the workplace, London, IEEE, 2001.
95. Homero, 1997 Homero: Odisea, Madrid, Planeta-De Agostini, 1997.
96. Humphrey, W. et al., 2007
Humphrey, W., Konrad, M., Over, J., Peterson, W.: Future directions in process improvement, CrossTalk, 20 (2), 2007, pp. 17-22.
191
97. Huysman, M., 2002 Huysman, M.: Organizational learning and communities of practice. A social constructivist perspective, Proceeding of the 3rd European Conference on Organizational Knowledge, Learning and Capabilities, Athens, Greece, 2002.
98. IEEE, 1990 IEEE Computer Society: IEEE standard glossary for software engineering terminology, IEEE, Piscataway, 1990.
99. ISO, 1997 International Organization for Standardization: ISO/IEC 15504 Software Process Improvement and Capabilities Determination Model (SPICE), 1997.
100. Jedlitschka, A. et al., 2001
Jedlitschka, A., Althoff, K., Decker, B., Harrtkopf, S., Nick, M.: Corporate information network (COIN): The Fraunhofer IESE experience factory, 2001, pp. 54-60.
101. Jennex, M. et al., 2003 Jennex, M., Olfman, L.: Organizational memory, en Holsapple, C. (ed.): Handbook on knowledge management, Berlin, Springer, 2003, pp. 207-234.
102. Johansson, C. et al., 1999
Johansson C., Hall, P., Coquard, M.: Talk to Paula and Peter; they are experienced. The experience engine in a nutshell, Proceedings of the 11th International Conference on Software Engineering and Knowledge Engineering, Learning Software Organizations, Methodology and Applications, 1999, pp. 171-185.
103. Kautz, K. et al., 2007 Kautz, K., Kjoergaard, A.: Towards an integrated model of knowledge sharing in software development, International Journal of Knowledge Management, Vol. 3, Nro. 2, 2007, pp. 91-117
104. Kim, D., 1993 Kim, D. H.: The link between individual and organizational learning, Sloan Management Review, Vol. 35, 1993, pp. 37-50.
105. King, G. et al., 1994 King, G., Keohane, R., Verba, S.: Designing social inquiry, Princeton, Princeton University Press, 1994.
106. King, W., 2001 King, W., Strategies for creating a learning organization, Information Systems Management, 18 (1), 2001, pp. 1-9.
107. Kitchenham, B. et al., 1995
Kitchenham, B., Pickard, L., Pfleeger, S.: Case studies for method and tool evaluation, IEEE Software, July 1995, pp. 52-62.
108. Klein, B. et al., 2005 Klein, B., Hoecht, C., Decker, B.: Beyond capturing and maintaining software engineering knowledge. Wikitology as shared semantics, Knowledge Engineering and Software Engineering Workshop, 28th German Conference on Artificial Intelligence, Koblenz, Alemania, 2005.
192
109. Kokkoniemi, J., 2006 Kokkoniemi, J.: A preliminary model for generating experience knowledge based artifacts, Proceedings of the 39th Hawaii International Conference on System Sciences, 2006, p. 153.
110. Kokkoniemi, J., 2008 Kokkoniemi, J.: Gathering experience knowledge from iterative software development processes, Proceedings of the 41st Hawaii International Conference on System Sciences, 2008, p. 333.
111. Kolb, D., 1984 Kolb, D.: Experiential learning. Experience as the source of learning and development, New Jersey, Prentice Hall, 1984.
112. Komi-Sirvio, S. et al., 2002
Komi-Sirvio, S., Mantyniemi, A., Seppanen, V.: Toward a practical solution for capturing knowledge for software projects, IEEE Software, 19 (3), May/June 2002, pp. 60-62
113. Koskinen, K., 2001 Koskinen, K.: Tacit knowledge as a promoter of success in technology firms, Proceedings of the 34th Hawaii International Conference on System Sciences, 2001.
114. Kukko, M. et al., 2008 Kukko, M., Helander, N., Virtanene, P.: Knowledge management in renewing software development process, Proceedings of the 41th Hawaii International Conference on System Sciences, 2008, p. 332.
115. Kulpa, M. et al., 2008 Kulpa, M., Johnson, K.: Interpreting the CMMI. A process improvement approach, Boca Ratón, Auerbach, 2ed. 2008
116. Lai, J-Y. et al., 2008 Lai, J-Y., Wang C-T., Chow, C-Y.: How knowledge map and personalization affect effectiveness of KMS in high-tech firms, Proceedings of the 41st Hawaii International Conference on System Sciences, 2008, p. 355
117. Lam, A., 2000 Lam, A.: Tacit knowledge, organizational learning and societal institutions. An integrated framework, Organizational Studies, Vol. 21, Nº 3, 2000, pp. 487-513
118. Lesser, E. et al., 2001 Lesser, E., Storck, J., Communities of practices and organizational performance, IBM Systems Journal, Vol. 40, N° 4, 2001, pp. 831-841
119. Marsick, V. et al., 1999 Marsick, V., O’Neil, J.: The many faces of action learning, Management Learning, Vol. 30, Nº 2, 1999, pp. 159-176
120. Martinez, P. et al., 2005 Martinez, P., Amescua, A., García, J., Cuadra, D., Llorens, J., Fuentes, J., Martín, D., Cuevas, G., Calvo-Manzano, J., San Feliú, T.: Requirements for a knowledge management framework to be used in software intensive organizations, Proceedings of the International Conference on Information Reuse and Integration, IRI-2005, 2005, pp. 554-559
193
121. Mathiassen, L. et al., 2001
Mathiassen, L., Pries-Heje, J., y Ngwenyama, O. (eds.): Improving software organizations. From principles to practice, Upper Saddle River, Addison-Wesley, 2001
122. Mathiassen, L. et al., 2001
Mathiassen, L., Nielsen, P.,Pries-Heje, J.: Learning SPI in practice, en: Mathiassen, L., Pries-Heje, J., y Ngwenyama, O. (eds.): Improving software organizations. From principles to practice, Upper Saddle River, Addison-Wesley, 2001, pp. 3-21
123. Mathiassen, L. et al., 2003
Mathiassen, L., Pourkomeylian, P., Managing knowledge in a software organization, Journal of Knowledge Management, Nº 7, 2003, pp. 63-80
124. Mathiassen, L. et al., 2005
Mathiassen, L., Pedersen, K.: The dynamics of knowledge in systems development practice, Proceedings of the 38th Hawaii International Conference on System Sciences, 2005
125. Matturro, G., Silva, A., 2005
Matturro, G., Silva, A.: A knowledge-based perspective for preparing the transition to a software product line approach, en: Obbink, H., Pohl, K. (eds.): Software Product Lines, 9th
International conference, SPLC 2005, LNCS 3714, Berlin, Springer, 2005, pp. 96-101
126. McConnell, S., 2003 McConnell, S.: Professional software development, New York, Addison Wesley, 2003
127. McFeeley, B., 1996 McFeeley, B.: IDEAL. A user’s guide for software process improvement, Pittsburgh, Carnegie Mellon University, 1996
128. Montoni, M. et al., 2007 Montoni, M., Santos, G., Rocha, A.: MPS model and TABA workstation: implementing software process improvement initiatives in small settings, Proceedings of the Fifth International Workshop on Software Quality (WoSQ’07), 2007, p. 4
129. Montoni, M. et al., 2008 Montoni, M., Cerdeiral, C., Zanetti, D., Rocha, A.: A knowledge management approach to support software process improvement implementation initiatives, en O’Connor, R. et al. (eds.), Software Process Improvement, Proceeding of the 15th European Conference EuroSPI 2008, Springer, 2008, pp. 164-175.
130. Muhammed, S. et al., 2008
Muhammed, S., Doll, W., Deng, X.: Exploring the relationship among individual knowledge management outcomes, Proceedings of the 41st Hawaii International Conference on System Sciences, 2008, p. 357
131. Mumford, A., 1997 Mumford, A., How to choose the right development method, Londres, Peter Honey, 1997
132. Mutafelija, B. et al., 2003
Mutafelija, B., Stromberg, H.: Systematic process improvement using ISO 9001:2000 and CMMI, Norwood, Artech House, 2003
194
133. Mutafelija, B. et al., 2009
Mutafelija, B., Stromberg, H.: Process improvement with CMMI v1.2 and ISO standards, Boca Ratón, Auerbach, 2009
134. Myllyaho, M. et al., 2004
Myllyaho, M., Salo, O., Kaariainen, J., Hyysalo, J., Koskela, J.: A review of small and large post-mortem analysis methods, ICSSEA, 2004
134. Nadler, L. et al., 1994 Nadler, L., Nadler, Z.: Designing training programs. The critical events mode, Huston, Gulf Publishing, 2da. ed., 1994
136. Newell, S. et al, 2006 Newell, S., Galliers, R.: Knowledge transfer: Short-circuiting the learning cycle?, Proceedings of the 39th Hawaii International Conference on System Sciences, 2006, p. 149
137. Nonaka, I. et al., 1999 Nonaka, I., Takeuchi, H.: La organización creadora de conocimiento, México, Oxford University Press, 1999
138. Oren, E. et al., 2006 Oren, E., Volkel, M., Breslin, J., Decker, S.: Semantic wikis for personal knowledge management, Lecture Notes in Computer Science, Vol. 4080, 2006, pp. 509-518
139. Patton, M., 2002 Patton, M.: Qualitative research and evaluation methods, Thousand Oaks, Sage, 3ra. ed., 2002
140. Pedler, M., et al., 1996 Pedler, M, Burgoyone, J., Boydell, T., The learning company: A strategy for sustainable development, London, McGraw-Hill, 1996
141. Pérez Serrano, G., 1998
Pérez Serrano, G.: Investigación cualitativa. Retos e interrogantes, Madrid, La Muralla, 2da. ed., 1998
142. Perry, D., et al., 2004 Perry, D., Sim, S., Easterbrook, S.: Case studies for software engineers, Proceedings of the 26th International Conference on Software Engineering (ICSE’04), 2004
143. Persee, J., 2006 Persee, J., Process improvement essentials, Sebastopol, O’Reilly, 2006
144. Piirainen, K. et al., 2008 Piirainen, K., Kivijarvi, H., Touminen, M.: Supporting strategic innovativeness: scenario planning for driving organizational knowledge sharing, Proceedings of the 41st Hawaii International Conference on System Sciences, 2008, p. 351
145. Plumley, D., 2003 Plumley, D., Process-based knowledge mapping, en http://www.destinationkm.com/articles/default.asp?ArticleID=1041, accedido el 28/07/2004
146. Polanyi, M., 1966 Polanyi, M.: The tacit dimension, London, Routledge, 1966
147. Porter, M., 1987 Porter, M.: Ventaja competitiva, México, CECSA, 1987
195
148. Pourkomeylian, P., 2000
Pourkomeylian, P.: Knowledge creation in improving a software organization, Proceedings of IRIS 23, 2000
149. Pressman, R., 2005 Pressman, R.: Ingeniería de software, México, McGraw Hill, 7ma. ed., 2005
150. Probst, G. et al., 2001 Probst, G., Raub, S., Romhardt, K., Administre el conocimiento, México, Pearson, 2001
151. Quintas, P. et al, 1997 Quintas, P., Lefrere, H., Jones, G., Knowledge management: A strategic agenda, Long Range Planning, Vol. 30, Nº 3, 1997, pp. 385-391
152. RAE, 2001 Real Academia Española: Diccionario de la lengua española, Madrid, Espasa, 22 ed., 2001
153. Raelin, J., 2002 Raelin, J.: Work-based learning, Upper Saddle, Prentice Hall, 2002
154. Ramasubramanian, S., et al., 2003
Ramasubramanian, S., Jagadeesan, G.: Knowledge management at Infosys, IEEE Software, 20 (3) May/June 2003, pp. 53-55
155. Ravichandran, T. et al., 2000
Ravichandran, T., Rai, A.: Software process management: an organizational learning perspective, Proceedings of the 8th European Conference on Information Systems, 2000
156. Rech, J. et al., 2007 Rech, J., Bogner, C., Haas, V.: Using wikis to tackle reuse in software projects, IEEE Software, 24 (6), pp. 99-104
157. Rimawi, Y. et al., 2005 Rimawi, Y., Amescua, A., Cuevas, G., San Feliú, T., García, J.: RAMALA: A knowledge base for software process improvement, 2nd International Conference on Innovations in Information Technology, 2005
158. Robillard, P., 2005 Robillard, P.: Oportunistic problem solving in software engineering, IEEE Software, 22 (5), November/December 2005, pp. 60-67
159. Ruhe, G. et al., 2000 Ruhe, G., Bomarius, F. (eds.): Learning software organizations, Berlin, Springer, 2000
160. Rus, I. et al., 2002 Rus, I., Lindvall, M., Knowledge management in software engineering, IEEE Software, 19 (3) May/June 2002, pp. 26-38
161. Sabino, C., 1996 Sabino, C.: El proceso de investigación, Buenos Aires, Lumen, 1996
162. Sacchi, P., et al., 1999 Sacchi, P., Ciaschi, R., Spence, D., A concept for an ESA lessons learned system, Proceedings of Alerts and Lessons Learned: An effective way to prevent failures and problems, Noordwijk, The Netherlands, 1999
196
163. Sánchez, R. et al., 1997
Sánchez, R., Heene, A.: Strategic learning and knowledge management, New York, J. Wiley & Sons, 1997
164. Santos, G. et al., 2005 Santos, G., Montoni, M., Rocha, A., Figueiredo, S., Mafra, S., Albuquerque, A., Diaz, B., Amaral., M.: Using a software development environment with knowledge management to support deploying software process in small and medium size companies, Proceedings of the 7th International workshop on Learning Software Organizations, 2005, pp. 72-76
165. Santos, G. et al., 2007a Santos, G., Montoni, M., Vasconcellos, J., Figueiredo, S., Cabral, R., Cerdeiral, C., Katsurayama, A., Lupo, P., Zanetti, D., Rocha, A.: Implementing software process improvement initiatives in small and medium-size enterprises in Brazil, 6th International Conference on the Quality of Information and Communications Technology (QUATIC), 2007, pp. 187-198.
166. Santos, G. et al., 2007b Santos, G., Montoni, M., Figueiredo, S., Rocha, A.: SPI-KM. Lessons learned from applying a software process improvement strategy supported by knowledge management, en Munch, J., Abrahamsson, P. (eds.) Proceedings of the PROFES 2007, LNCS 4589, Berlin, Springer, 2007, pp. 81-95.
167. Schaffert, S., 2006a Schaffert, S.: IkeWiki: a semantic wiki for collaborative knowledge management, International Workshop on Enabling Technologies: Infrastructure for Collaborative Enterprises, (WETICE’06), 2006, pp. 388-393
168. Schaffert, S., 2006b Schaffert, S., Westenthaler, R., Gruber, A.: IkeWiki: A user-friendly semantic wiki, 3rd European Semantic Web Conference (ESWC’06), 2006
169. Schneider, K. et al., 2002
Schneider, K., von Hunnius, J., Basili, V., Experience in implementing a learning software organization, IEEE Software, 19 (3), May/June 2002, pp. 46-49
170. Schön, D., 1987 Schön, D.: Educating the reflective practitioner, San Francisco, Jossey-Bass, 1987
171. Schunk, D., 1997 Schunk, D.: Teorías del aprendizaje, Madrid, Prentice Hall, 2da. ed., 1997
172. Scott, L. et al., 2002 Scott, L., Carvalho, L., Jeffery, R.: A process-centred experience repository for a small software organization, Proceedings of the Ninth Asia-Pacific Software Engineering Conference (APSEC’02), 2002, pp. 603-609
173. Scott, L. et al., 2003a Scott, L., Jeffery, R.: The anatomy of an experience repository, Proceedings of the 2003 International Symposium on Empirical Software Engineering (ISESE’03), 2003, p. 163
197
174. Scott, L. et al., 2003b Scott, L., Stalhane, T.: Experience repositories and postmortem, Workshop Learning Software Organizations, 2003
175. SEI, 2002 Software Engineering Institute: Capability maturity model integration (CMMI), version 1.1, Carnegie Mellon University, Pittsburgh, 2002
176. SEI, 2006 Software Engineering Institute: CMMI for Development, Version 1.2, Carnegie Mellon University, Pittsburgh, 2006
177. Senge, P., 1990 Senge, P.: La quinta disciplina, Barcelona, Gránica, 1992
178. Sjoberg, D. et al., 2005 Sjoberg, D., Hannay, J., Hansen, O., Kampenes, V., Karahasanovic, A., Liborg, N., Rekdal, A.: A Survey of controlled experiments in software engineering, IEEE Transactions on Software Engineering, 31 (9), September 2005, pp. 733-753
179. Sjoberg, D. et al., 2007 Sjoberg, D., Dyba, T., Jorgensen, M.: The future of empirical methods in software engineering research, Proceedings of the International Conference on Software Engineering, 2007 Future of Software Engineering, 2007, pp. 358-378
180. Soler, R., 2003 Soler, M. R.: Mentoring. Estrategia para el desarrollo de recursos humanos, Madrid, Gestión 2000, 2003
181. Sommerville, I., 2005 Sommerville, I.: Ingeniería de software, México, Pearson, 7ma. ed., 2005
182. Spendolini, M.,1994 Spendolini, M., Benchmarking, Barcelona, Norma, 1994
183. Swieringa, J., et al., 1995
Swieringa, J., Wierdsma, A.: La organización que aprende, Wilmington, Delaware, Addison-Wesley Iberoamericana, 1995
184. Talisayon, S., 2001 Talisayon, S., IT focus or people focus, Business World Internet Edition, Manila, 30 Julio 2001
185. Vail, E., 1999 Vail, E.: Knowledge mapping: getting started with knowledge management, Information Systems Management, Vol. 16, Issue 1, 1999, pp. 16-23
186. Ventura, J., Ordoñez, P., 2007
Ventura, J., Ordoñez, P.: Análisis de estrategias de conocimiento en la industria manufacturera española, Tribuna de economía, Nro. 836, Mayo-Junio 2007, pp. 141-161
187 Ventura, P. et al., 2008 Ventura Martins, P., Rodriguez da Silva, A.: ProPAMet: A metric for process and project Alignment, en O’Connor, R. et al. (eds.), Software Process Improvement, Proceeding of the 15th European Conference EuroSPI 2008, Springer, 2008, pp. 201-212.
198
188. Wake, W., 2001 Wake, W.: Extreme programming explored, Boston, Addison Wesley, 2001
189. Ward, J. et al., 2004 Ward, J., Aurum, A.: Knowledge management in software engineering. Describing the process, Proceedings of the 2004 Australian Software Engineering Conference, 2004, pp. 137-146
190. Wassermann, S., 1994 Wassermann, S.: El estudio de casos como método de enseñanza, Buenos Aires, Amorrortu, 1994
191. Weber, R. et al., 2001 Weber, R., Aha, D., Becerra-Fernández, I., Intelligent lessons learned systems, Expert Systems with Applications, N° 17, 2001, pp. 17-34
192. Wei, C. et al., 2002 Wei, P., Hu, P., Chen, H.: Design and evaluation of a knowledge management system, IEEE Software, 19 (3), May/June 2002, pp. 56-59
193. Wenger, E. et al., 1991 Wenger E., Lave, J.: Situated learning: legitimate peripheral participation, Cambridge, Cambridge University Press, 1991
194. Wenger, E., et al., 2000 Wenger, E., Snyder, W. M.: Communities of practice: the organizational frontier, Harvard Business Review, Vol. 78, N° 1, 2000, pp. 139-146
195. Wenger, E. et al., 2002 Wenger, E., McDermott, R., Snyder, W.: Cultivating communities of practice, Boston, Harvard Business School Press, 2002
196. Wiener, N., 1967 Wiener, N.: Dios y Golem, México, Siglo XXI Editores, 1967
197. Wiig, K., 1993 Wiig, K.:, Knowledge management foundations, Arlington, Texas, Schema Press, 1993
198. Wohlin, C., 2000 Wohlin C, Runeson P, Höst P.: Experimentation in software engineering. An introduction, Boston, Kluwer, 2000
199. Wohlin, C., 2003 Wohlin, C.: Applications of knowledge management in software engineering, en: Jeffery, R., Wohlin, C., Handzic, M. (eds.): Managing software engineering knowledge, Berlin, Springer, 2003, pp. 177-180
200. Wohlin, C. et al., 2003 Wohlin, C., Höst, M., Henningsson, K.: Empirical research methods in software engineering, en Conradi, R., Wang, A. (eds.): Empirical Methods and Studies in Software Engineering, Berlin, Sprimger, 2003, pp. 7-23
201. Xie, X. et al., 2005 Xie, X., Zhang, W., Xu, L.: A lightweight description model to support experience management, Proceedings of the 2005 IEEE/WIC/ACM International Conference on Intelligent Agent Technology, 2005, pp. 694-697
199
202. Xu, P., 2005 Xu, P.: Knowledge support in software process tailoring, Proceedings of the 38th Hawaii International Conference on System Sciences, 2005
203. Ye, Y., 2006 Ye, Y.: Supporting software development as knowledge intensive and collaborative activity, Proceedings of (WISER’06), 2006, pp. 15-22
204. Yin, R., 2003 Yin, R.: Case Study Research. Design and Methods, Thousand Oaks, Sage, 3ra. ed., 2003
205. Zack, M., 1999 Zack, M.: Developing a knowledge strategy, California Management Review, Vol. 41, N° 3, 1999, pp. 125-145
206. Zack, M., 2002a Zack, M.: Developing a knowledge strategy: epilogue, en: Bontis, N., Choo, C. (eds.) The strategic management of intellectual capital and organizational knowledge: a collection of readings, Oxford, Oxford University Press, 2002.
207. Zack, M., 2002b Zack, M.: A strategic pretext for knowledge management, Proceedings of the Third European Conference on Organizational Knowledge, Learning and Capabilities, Athens, Greece, 2002.
208. Zhu, L. et al., 2007 Zhu, L., Staples, M., Gorton, I.: An infrastructure for indexing and organizing best practices, Proceedings of the 2nd International Workshop on Realizing Evidence-based Software Engineering (REBSE ’07), 2007.
201
Apéndice 1. SOBRE LA METODOLOGÍA DE INVESTIGACIÓN SELECCIONADA
A1.1 Paradigmas de investigación
Creswell [Creswell, J., 1994] distingue dos paradigmas o enfoques generales para
plantear y llevar a cabo una investigación, particularmente en ciencias sociales. Estos
paradigmas, denominados “cuantitativo” y “cualitativo”, son caracterizados por Creswell en
los siguientes términos:
• Un estudio de carácter cualitativo se define como un proceso de indagación
(“inquiry”) para entender un problema social o humano, basado en la construcción
de una imagen holística y compleja, formada por palabras, que reporta visiones
detalladas de los informantes y que es conducido en su entorno natural.
• Un estudio cuantitativo, en cambio, es la indagación en un problema social o
humano, basado en probar una teoría compuesta por variables, medidas con
números y analizadas, aunque no necesariamente siempre, mediante
procedimientos estadísticos, a los efectos de determinar, en ese caso, si las
generalizaciones predictivas de la teoría resultan verdaderas.
Por su parte, King, Keohane y Verba [King, G. et al., 1994] consideran que las
investigaciones cualitativas y cuantitativas tienen estilos bien diferentes y que, tanto unas
como las otras pueden ser sistemáticas y científicas. Estos autores caracterizan estos dos
estilos de investigación en los siguientes términos:
• Una investigación cuantitativa utiliza números y, en ocasiones, métodos
estadísticos. Tiende a basarse en mediciones numéricas de aspectos específicos
de un fenómeno, realiza abstracciones de instancias particulares para buscar
descripciones generales o probar hipótesis causales.
• Una investigación cualitativa cubre un amplio rango de enfoques pero, por
definición, ninguno de esos enfoques depende de mediciones numéricas. Estos
estudios han tendido a centrarse en uno o en un número pequeño de casos, a usar
entrevistas intensivas o un análisis en profundidad de materiales históricos, a ser
discursivos en sus métodos y a interesarse en una descripción comprensiva de
algún evento o unidad de estudio.
202
Según Wohlin, Höst y Henningsson [Wohlin, C. et al., 2003], es posible para las
investigaciones cualitativas y cuantitativas investigar los mismos tópicos, pero cada una
abordando un tipo de pregunta o cuestión diferente.
Hernández, Fernández y Baptista [Hernández, R. et al., 2003] hacen una distinción en
cuatro tipos de estudios que denominan explicativos, correlacionales, exploratorios y
descriptivos, y que definen en los siguientes términos:
• Los estudios explicativos son aquellos que están dirigidos a responder a las
causas de los eventos físicos o sociales bajo estudio.
• Los estudios correlacionales tienen como propósito evaluar la relación entre dos
o más conceptos o variables, es decir, saber cómo se puede comportar un
concepto o una variable conociendo el comportamiento de otras variables
relacionadas.
• Los estudios exploratorios son aquellos que se efectúan cuando el objetivo es
examinar un tema o problema de investigación poco estudiado o que no ha sido
abordado antes, y agregan que tales estudios sirven para familiarizarse con
fenómenos relativamente desconocidos.
• Los estudios descriptivos buscan especificar las propiedades o aspectos
importantes de personas, grupos o cualquier otro fenómeno que sea sometido a
análisis.
A1.2 Elección del método de investigación
Sjøberg, Dyba y Jørgensen [Sjøberg, D. et al., 2007] definen la investigación primaria como aquella que involucra la recolección y el análisis de datos originales, y
mencionan el estudio de caso, la experimentación, las encuestas y la investigación-acción
como métodos posibles para llevar a cabo una investigación de ese tipo.
El estudio de caso es definido por [Sabino, C., 1996], como el estudio profundizado y
exhaustivo de uno o unos pocos objetos de investigación, lo que permite obtener un
conocimiento amplio y detallado de los mismos.
Angüera, por su parte, citado por Pérez Serrano [Pérez Serrano, G., 2003], considera
que el estudio de casos implica el examen intensivo y en profundidad de diversos aspectos
de un fenómeno específico, como ser un programa, un evento, una persona, un proceso,
una institución o un grupo de social.
Dul y Hak [Dul, J. et al., 2008] definen el estudio de casos como un estudio en el cual
(a) un caso (estudio de caso simple) o una cantidad pequeña de casos (estudio de casos
203
comparativo) se seleccionan en el contexto de su vida real, y (b) los valores (“scores”)
obtenidos de estos casos son analizadas en forma cualitativa.
Yin [Yin, R., 2003], por su parte, define el estudio de casos como una investigación
empírica que indaga un fenómeno contemporáneo dentro del contexto de su vida real,
especialmente cuando los límites entre el fenómeno y el contexto no son claramente
evidentes.
Estas dos últimas definiciones, en particular, hacen referencia al concepto de
“contexto”. El diccionario de la Real Academia Española [RAE, 2001] define contexto como
“el entorno físico o de situación, ya sea político, histórico, cultural o de cualquier otra índole,
en el cual se considera un hecho”.
Tal como se expuso en el capítulo 5, para el estudio llevado a cabo en el marco de
esta tesis, los aspectos de contexto fueron particularmente interesantes de ser tenidos en
cuenta, pues el mismo se enfocó a estudiar el proceso de implementación del modelo
propuesto en forma integrada a las actividades habituales de los miembros de los equipos
de proyecto, trabajando en proyectos de desarrollo software reales.
Esta consideración de los aspectos del contexto donde se implementó el modelo hizo
que no se considerara adecuada la realización de un experimento pues, como mencionan
Sjøberg, Dyba y Jørgensen (Sjøberg et al., 2007), un experimento divorcia deliberadamente
el fenómeno a estudiar de su contexto.
En cuando al uso de encuestas, si bien se utilizaron cuestionarios para recabar las
opiniones de los participantes respecto de las guías de reflexión y del taller de educción de
conocimientos y experiencia, el uso exclusivo de este instrumento no hubiera permitido
obtener los resultados necesarios para dar respuesta a las proposiciones 2 y 5 del estudio.
Finalmente, y en relación con la investigación-acción, Easterbrook y colegas
[Easterbrook, S. et al., 2008] mencionan que, con la utilización de este método, el
investigador intenta resolver un problema real, al tiempo que estudia la propia experiencia
de resolver el problema, y agregan que, mientras que la mayoría de los métodos de
investigación empíricos tienden a observar el mundo tal como existe en el presente, la
investigación acción tiene por finalidad intervenir en la situación estudiada con el propósito
explícito de mejorar esa situación.
En virtud de esta caracterización de la investigación-acción, se descartó su utilización
para el estudio llevado a cabo en esta tesis, puesto que el propósito no era resolver un
problema particular de la organización ORTsf o de la forma de trabajo de los equipos de
proyectos participantes.
En base, entonces, a las consideraciones anteriores, fue que se seleccionó el estudio de caso como estrategia general para el estudio realizado.
204
Antes de finalizar este apartado, es importante resaltar aquí la diferencia entre las
expresiones “estudio de casos” y “caso de estudio”. Como lo explica Patton [Patton, M.,
2002], el enfoque del estudio de casos constituye una manera específica de recolectar,
organizar y analizar datos. En este sentido, el estudio de casos representa un proceso de
análisis, y su propósito es reunir información comprensiva, sistemática y en profundidad
acerca de cada caso de interés. El caso de estudio, por su parte, es el resultado o
producto obtenido a partir de ese proceso de análisis.
A1.3 El estudio de casos en Ingeniería de Software
Perry, Sim y Easterbrook [Perry, D. et al., 2004] caracterizan el estudio de casos como
un poderoso y flexible método empírico, consideran que los mismos se han vuelto populares
en IS, y que son frecuentemente utilizados en artículos técnicos para entender, explicar o
demostrar las capacidades de una nueva técnica, método, herramienta, proceso, tecnología
o estructura organizacional. Por su parte, Kitchanham, Pickard y Pfleeger [Kitchanham, B. et
al., 1995] consideran que los estudios de casos son particularmente importantes para la
evaluación industrial de métodos y herramientas de IS.
El estudio de casos ha sido adoptado por numerosos autores como estrategia de
investigación sobre diversos aspectos de la gestión del conocimiento en el ámbito de la
ingeniería de software. Las siguiente lista, sin ser exhaustiva, refiere a una serie de trabajos
al respecto: [Kukko,M, et al., 2008], [Farenhorst, R. et al., 2007], [Kautz, K. et al., 2007],
[Cooper, L., 2007], [Alagarsamy, K. et al., 2007], [Elisberg, T. et al., 2006], [Mathiassen, L. et
al., 2005], [Desouza, K. et al., 2005], [Chau, T. et al., 2005], [Ward, J. et al., 2004], [Myllyaho,
M. et al., 2004], [Falbo, R. et al., 2004], [Scott, L. et al., 2003], [Komi-Sirvio, S. et al., 2002],
[Arent, J. et al., 2000].
A1.4 Diseño de la investigación
En términos coloquiales, sostiene Yin [Yin, R., 2003], el diseño de una investigación
es un plan lógico para ir “desde acá hasta allá”, donde el “acá” puede definirse como el
conjunto inicial de preguntas a ser respondidas, mientras que el “allá” es algún conjunto de
conclusiones (respuestas) acerca de esas preguntas. El principal propósito del diseño es
ayudar a evitar la situación en la cual la evidencia no conduzca a las cuestiones iniciales de
investigación.
Para Sabino [Sabino, C., 1996], el diseño de la investigación es una estrategia
general de trabajo que el investigador determina una vez que ya ha alcanzado suficiente
205
claridad respecto a su problema y que orienta y esclarece las etapas que habrán de
acometerse posteriormente.
Por su parte, Earterbook y colegas [Easterbook, S. et al., 2008], consideran que una
precondición para llevar a cabo un estudio de caso es tener una pregunta de investigación
claramente definida concerniente a cómo o porqué cierto fenómeno ocurre. Esta pregunta es
utilizada para derivar las proposiciones del estudio, que establecen de manera precisa qué
es lo que el estudio tiene por intensión mostrar, y para guiar la elección de los casos y los
tipos de datos a recolectar.
A1.4.1 La pregunta de investigación
Para Hays [Hays, P., 2004], el propósito del investigador en un estudio de casos no es
estudiar todo lo que ocurre en el lugar donde se lleva a cabo el estudio, sino enfocarse en
situaciones, problemas o eventos específicos. Una manera de delimitar el estudio es
mediante el uso de preguntas de investigación, dado que estas preguntas son las que
mantendrán enfocado al investigador a lo largo de todo el estudio. En este sentido, Creswell
[Creswell, J., 1994] propone iniciar la planificación de una investigación mediante un tipo de
pregunta que denomina “grand tour”. Una pregunta “grand tour” es una sentencia de la
cuestión a examinar en el estudio, formulada en su forma más general. Sostiene Creswell
[Creswell, J., 1994] que una pregunta de este tipo constituye una guía de trabajo más que
una “verdad” a ser probada.
A1.4.2 Las proposiciones
Siguiendo a Creswell [Creswell, J., 1994], esta pregunta general es seguida de varias
sub-preguntas o proposiciones que delimitan el enfoque del estudio y que constituirán
tópicos específicamente explorados en entrevistas, cuestionarios, observaciones y
materiales documentales.
A1.4.3 La unidad de análisis y los informantes claves
Para Yin [Yin, R., 2003], en el estudio de casos la unidad de análisis puede ser un
individuo o grupo de individuos, pero también un caso puede estar enfocado en el estudio de
la economía de un país, una industria o una política económica, así como también la
evaluación de un programa, una iniciativa de cambio organizacional o la implementación de
un determinado proceso.
206
Para Patton [Patton, M., 2002], el elemento clave en la selección de la unidad de análisis apropiada es decidir “acerca de qué cosa se quiere ser capaz de decir algo al
finalizar el estudio”.
Easterbrook y colegas [Easterbrook, S. et al., 2008] mencionan que, en IS, la unidad
de análisis podría ser una organización, un proyecto, un equipo, un desarrollador individual,
un evento o episodio particular o un producto de trabajo específico, entre otros.
En cuanto a los informantes claves, para Patton [Patton, M., 2002], son personas
particularmente conocedoras de los aspectos relacionados con la investigación; es decir,
personas cuyo discernimiento (“insights”) puede resultar particularmente útil para ayudar al
investigador en entender qué está ocurriendo y por qué.
A1.4.4 Lógica que enlaza los datos con las proposiciones
Mencionan Blaxter, Hughes y Tight [Blaxter, L. et al., 2000] que toda investigación
implica la recolección y el análisis de datos, sea a través de la lectura, la observación, la
medición, las preguntas o una combinación de algunas o de todas esas estrategias.
Para Sabino [Sabino, C., 1996], por dato se entiende cada uno de los elementos de
información que se recoge durante el desarrollo de una investigación y en base a los cuales,
convenientemente sintetizados, podrán extraerse conclusiones de relevancia en relación con
el problema inicial planteado.
Para Blaxter, Hughes y Tight [Blaxter, L. et al., 2000], los datos consisten, por
ejemplo, en respuestas a cuestionarios, transcripciones de entrevistas, análisis de
documentos y notas u otros registros de observaciones o de experimentos.
Patton [Patton, M., 2002], en referencia específica al estudio de casos, considera que
los datos del caso consisten de toda la información que se tiene acerca del mismo:
entrevistas, documentos, cuestionarios, observaciones e información del contexto.
Para Hays [Hays, P., 2004], una vez que las proposiciones o preguntas de
investigación han sido establecidas, deben determinarse las fuentes de datos para cada una
de ellas y el o los instrumentos para recolectarlos.
Para Sabino [Sabino, C., 1996], un instrumento de recolección de datos es
cualquier recurso de que se vale el investigador para acercarse a los fenómenos bajo
estudio y extraer de ellos información.
De los diversos instrumentos que están disponibles para los investigadores, se
describen a continuación aquellos que han sido utilizados en esta tesis.
207
A1.4.4.1 Observación participante Para Sabino [Sabino, C., 1996], la observación puede definirse como el uso
sistemático de nuestros sentidos en la búsqueda de los datos que se necesitan para
resolver un problema de investigación. Más específicamente, observar científicamente es
percibir activamente la realidad exterior con el propósito de obtener los datos que,
previamente, han sido definidos como de interés para la investigación.
La observación puede ser simple o participante. La observación simple resulta útil y
viable cuando se trata de conocer hechos o situaciones que, de algún modo, tienen cierto
carácter público o que, por lo menos, no pertenecen estrictamente a la esfera de las
conductas privadas de los individuos. La observación participante, por el contrario, implica
la necesidad de un trabajo más dilatado y cuidadoso, pues el investigador debe
primeramente integrarse al grupo, comunidad o institución en estudio para, una vez allí, ir
realizando una doble tarea: desempeñar algunos roles dentro del conjunto, a la par de ir
recogiendo los datos que desea conseguir.
Para Yin [Yin, R., 2003], la observación participante es un modo especial de
observación en el cual el investigador no es un mero observador pasivo sino que, por el
contrario, puede asumir una variedad de roles dentro de una situación del caso de estudio y
puede efectivamente participar en los eventos que están siendo estudiados.
A1.4.4.2 Documentos Corbetta [Corbetta, P., 2003] entiende por documento aquél material informativo
sobre un determinado fenómeno social que existe con independencia de la acción del
investigador. Agrega que, por tanto, el documento es generado por los individuos o por las
instituciones para fines eventualmente distintos de los de la investigación pero que, no
obstante, ésta puede apropiarse de él para utilizarlos en sus propios fines cognoscitivos.
A1.4.4.3 Cuestionarios Para Bernal [Bernal, C., 2006], un cuestionario es un conjunto de preguntas
diseñadas para generar los datos necesarios para alcanzar los objetivos del estudio, y
permite estandarizar y uniformizar el proceso de recolección de esos datos.
Las preguntas de un cuestionario pueden ser de dos tipos: abiertas o cerradas. Las
preguntas abiertas permiten al respondiente responder con sus propias palabras, es decir,
el investigador no limita las opciones de respuesta. Las preguntas cerradas, por el
contrario, contienen categorías o alternativas de respuesta que han sido previamente
definidas por el investigador. En este caso, el respondiente debe seleccionar la opción que
describa más adecuadamente su respuesta.
208
Hernández, Fernández y Baptista [Hernández, R. et al., 2003] definen actitud como
una predisposición aprendida para responder consistentemente de una manera favorable o
desfavorable ante un objeto o situación.
En la elaboración de los cuestionarios de este estudio se utilizó una clase particular de
preguntas cerradas que se denominan preguntas con respuesta a escala, que son
aquellas preguntas básicamente dirigidas a medir la intensidad o el grado de sentimiento
respecto a un rasgo o una variable a medir. Según Hernández, Fernández y Baptista
[Hernández, R. et al., 2003], este tipo de preguntas consisten de un conjunto de elementos
presentados en forma de afirmaciones o juicos, ante las cuales se pide la reacción del
respondiente y donde las afirmaciones pueden tener dirección favorable o positiva, o bien,
desfavorable o negativa.
Si la afirmación es positiva, significa que el respondiente califica favorablemente al
objeto de actitud y, cuanto más de acuerdo está el respondiente, más favorable será su
actitud. En este caso, las afirmaciones se califican comúnmente según la siguiente escala:
Muy de acuerdo, De acuerdo, Indiferente, En desacuerdo, Muy en desacuerdo.
A1.4.5 Criterios para analizar los datos
Para Blaxter, Hughes y Tight [Blaxter, L. et al., 2000], analizar los datos recolectados
comporta dos procesos íntimamente vinculados: (a) organizar los datos reduciendo su
longitud y alcance a fin de brindar información adecuada y útil, y (b) analizar el conjunto de
datos ya organizados, abstrayendo a partir de ellos y llamando la atención sobre lo que se
considera importante o significativo.
A1.4.5.1 Datos cualitativos Según Blaxter, Hughes y Tight [Blaxter, L. et al., 2000], el análisis de los documentos procede abstrayendo de los mismos aquellos elementos que se juzguen
importantes o pertinentes, y agrupando esos hallazgos o colocándolos junto a otros con los
cuales aparentemente se relacionan.
A1.4.5.2 Datos cuantitativos Para Blaxter, Hughes y Tight [Blaxter, L. et al., 2000] los estudios de investigación en
pequeña escala que recolectan datos por medio de cuestionarios no necesitan ir más allá de
la estadística descriptiva y, eventualmente, de la exploración de las interrelaciones entre
pares de variables.
209
A1.4.6 La base de datos del estudio Para Yin [Yin, R., 2003] la base de datos del estudio es el repositorio de toda la
información y documentación creada o recopilada a lo largo de todo el proceso de
investigación.
A1.5 Sobre los estudios empíricos con estudiantes
Carver y colegas [Carver, J. et al., 2003] consideran que antes de llevar a cabo
estudios empíricos en una compañía software es útil realizarlos con estudiantes en un
entorno académico. Para estos autores, los estudios empíricos con estudiantes constituyen
una manera de reducir los riesgos técnicos y organizacionales y consideran este aspecto
como uno de los principales beneficios para el investigador.
Otros beneficios que identifican son la obtención de evidencia preliminar para
confirmar o refutar hipótesis, mostrar a las compañías de software la relevancia de la
investigación, poder ajustar (“fine-tune”) la organización y los detalles del estudio empírico
antes de llevarlo a cabo en un ambiente industrial y, finalmente, producir un “kit”
experimental.
En cuanto a las desventajas, los autores señalan que la utilización de estudiantes en
estudios empíricos ha sido criticada puesto que suponen un menor grado de validez externa
y que, si bien consideran esto como un problema importante, señalan asimismo que:
• La validez externa es un aspecto a tener en cuenta en cualquier estudio empírico y
no sólo en los que se realizan con estudiantes.
• Tener evidencia empírica con estudiantes acerca de algún fenómeno de interés,
hipótesis e idea novedosa es mejor que no tener ninguna validación.
• La línea que separa los estudiantes brillantes de los profesionales novatos es cada
vez más difusa y, a veces, es favorable a los primeros.
Con respecto al último punto en particular, debe señalarse que, para el caso de los
miembros de los equipos de proyecto que participaron en el estudio realizado, del total de 15
estudiantes, 12 de ellos tienen actividad laboral relacionada con la IS.
En base a la información proporcionada por los propios estudiantes participantes en
comunicación personal al autor, la tabla A1.1 muestra las diferentes actividades que realizan
en forma privada.
210
Actividad privada Nombres Cant. Análisis y desarrollo de sistemas Alicia Pino, Alicia Pereira, Rodrigo Robaina 3 Desarrollo software Mario Romero, Ricardo Leite, Matías
Núñez, Federico Fontes, Felipe Herrera 5
Ingeniería de requisitos Carlos Geribón 1 Asistencia técnica a usuarios Alejandra Pera 1 Gerenciamiento de proyectos Yairo Vettorello 1 Responsable de IT Federico Gordillo 1 Actividades no relacionadas Daniel Nicolich, Andrés Lapachián, Sergio
Gambini 3
Tabla A2.1: Actividades privadas de los estudiantes
211
Apéndice 2. INSTRUMENTOS DE RECOLECCIÓN DE DATOS
Item. Documento A2.1 Guías de reflexión para Ingeniería de Requisitos A2.2 Guías de reflexión para Métricas de gestión de proyectos A2.3 Cuestionario de evaluación de las Guías de reflexión para ingeniería de
requisitos A2.4 Cuestionario de evaluación de las Guías de reflexión para métricas de
gestión de proyectos A2.5 Plantilla para el documento de Resumen de respuestas de las Guías de
reflexión para ingeniería de requisitos A2.6 Plantilla para el documento de Resumen de respuestas de las Guías de
reflexión para métricas de gestión de proyectos A2.7 Cuestionario de evaluación del Taller de educción de conocimientos y
experiencia A2.8 Guía para la realización del Taller de educción de conocimientos y
experiencia A2.9 Plantilla para el documento de Resultados del taller de educción de
conocimientos y experiencia
212
A2.1 Guía de Reflexión para Ingeniería de Requisitos
Guía de Reflexión para Requisitos Software Estimado, La presente lista de preguntas tiene por objetivo guiar su reflexión respecto de las actividades realizadas en su rol de ingeniero de requerimientos. La misma permitirá capturar información que será de un valor inestimable para mejorar las prácticas del proceso de ingeniería de requerimientos. Las preguntas formuladas no tienen como propósito evaluar el conocimiento teórico que usted posee sobre el área de ingeniería de requerimientos, lo que se pretende, es capturar los aprendizajes que surjan de su experiencia al realizar las distintas actividades. Por lo tanto, no hay respuestas correctas o incorrectas; debe responderla de manera honesta y en base a su experiencia personal. ¿Cómo completar esta guía? El proceso de completar la presente guía, consiste en que, a medida que usted lleve a cabo las actividades correspondientes a su rol, dedique un espacio de reflexión sobre las mismas dando respuesta a las preguntas que se han formulado. Al final de la lista de preguntas, encontrará un espacio denominado “Espacio Libre”, el cual ha sido creado para que usted pueda expresar inquietudes y/o sugerencias sobre el proceso de ingeniería de requerimientos, que usted considere relevantes y que no hayan sido consideradas en las preguntas. Dado el objetivo primordial de la guía, el cual es la obtención de información, se espera que cada pregunta sea contestada en no menos de cuatro líneas. Debajo de cada pregunta, encontrará el siguiente cuadro:
Tiempo Dedicado El mismo tiene por finalidad conocer el tiempo que usted debió dedicar para dar respuesta a cada una de las preguntas. ¿A dónde recurrir en caso de necesitar asistencia? Estaremos a su disposición para responder cualquier duda. Usted puede optar por cualquiera de las siguientes formas de comunicación: Correo electrónico: [email protected] Teléfonos: Laura Rodríguez, 3228785 Ana Estela, 7101843 En nombre del grupo responsable de la gestión del conocimiento y el aprendizaje (GGCA) le agradecemos su invalorable aporte, que será de fundamental importancia para el logro de nuestro objetivo de mejorar el proceso de ingeniería de software Preguntas
Pregunta 1 Req.Eli.An.01
¿Qué aspectos considera usted que es importante que se tomen en cuenta a la hora de planificar una entrevista?
Respuesta
Tiempo Dedicado
Pregunta 2 Req.Eli.Ap.01
Una buena comunicación con el usuario es clave para lograr recolectar información. Exponga los problemas más relevantes que ha tenido para establecer una comunicación efectiva y cómo los ha superado.
Respuesta
Tiempo Dedicado
213
Pregunta 3 Req.Eli.Ev.01
¿Qué recomendaría usted a un ingeniero de requerimiento que se enfrenta a un usuario con necesidades poco claras?
Respuesta
Tiempo Dedicado
Pregunta 4 Req.Eli.Si.01
Relate, en no menos de cuatro o cinco líneas, aquella experiencia de entrevista que usted considera que fue la más exitosa y que volvería a repetir.
Respuesta
Tiempo Dedicado
Pregunta 5 Req.An.An.01
En base a su experiencia, ¿qué dificultades encontró para distinguir los requerimientos funcionales de los no funcionales?
Respuesta
Tiempo Dedicado
Pregunta 6 Req.An.Ev.01
¿Cómo logro superar las dificultades anteriormente expresadas?
Respuesta
Tiempo Dedicado
Pregunta 7 Req.Prep.Si.01
Los miembros del proyecto que se dedican a la ingeniería de requerimiento necesitan un entrenamiento inicial para prepararse para la tarea. ¿De qué manera planearía usted este entrenamiento?
Respuesta
Tiempo Dedicado
Pegunta 8 Req.Prep.Ev.01
A su juicio, ¿qué habilidades personales facilitarían las tareas del ingeniero de requerimientos?
Respuesta
Tiempo Dedicado
Pegunta 9 Req..Ev.01
De las actividades relativas a IR que llevo acabo en el presente proyecto, ¿cuales considera que realizó adecuadamente y cuáles considera que deberá mejorar la próxima vez?
Respuesta
Tiempo Dedicado
Espacio libre:
214
A2.2 Guía de Reflexión para Métricas de gestión de proyecto
Guía de Reflexión para Métricas de Gestión de Proyectos Estimado, La presente lista de preguntas tiene por objetivo guiar su reflexión respecto de las actividades realizadas en su rol de Gerente de Proyecto, específicamente en lo relacionado a la planificación y gestión de métricas. La misma nos permitirá capturar información que será de un valor inestimable para mejorar las prácticas del proceso de planificación y gestión de las métricas del proyecto. Las preguntas formuladas no tienen como propósito evaluar el conocimiento teórico que usted posee sobre la planificación y gestión de las métricas, lo que se pretende, es capturar los aprendizajes que surjan de su experiencia al realizar las distintas actividades. Por lo tanto, no hay respuestas correctas o incorrectas; debe responderla de manera honesta y en base a su experiencia personal. ¿Cómo completar esta guía? El proceso de completar la presente guía, consiste en que a medida que usted lleve a cabo las actividades correspondientes a su rol, dedique un espacio de reflexión sobre las mismas dando respuesta a las preguntas que se han formulado. Al final de la lista de preguntas, encontrará un espacio denominado “Espacio Libre”, el cual ha sido creado para que usted pueda expresar inquietudes y/o sugerencias sobre el proceso de planificación y gestión de métricas, que usted considere relevantes y que no hayan sido consideradas en las preguntas. Dado el objetivo primordial de la guía, el cual es la obtención de información, se espera que cada pregunta sea contestada en no menos de cuatro líneas. Debajo de cada pregunta, encontrará el siguiente cuadro:
Tiempo Dedicado El mismo tiene por finalidad conocer el tiempo que usted dedicó a dar respuesta a cada una de las preguntas. ¿A dónde recurrir en caso de necesitar asistencia? Estaremos a su disposición para responder cualquier duda. Usted puede optar por cualquiera de las siguientes formas de comunicación: Correo electrónico: [email protected] Teléfonos: Laura Rodríguez, 3228785 Ana Estela, 7101843 En nombre del grupo responsable de la gestión del conocimiento y el aprendizaje (GGCA) le agradecemos su invalorable aporte, que será de fundamental importancia para el logro de nuestro objetivo de mejorar el proceso de planificación y gestión de métricas. Preguntas
Pregunta 1 Ge.Me.Ev.01
¿Qué métricas planificó recolectar para su proyecto? ¿Por qué considera que estas métricas son adecuadas para su proyecto en particular?
Respuesta
Tiempo Dedicado
Pregunta 2 Ge.Me.Ap.01
¿Cómo llevó a cabo el análisis de los datos obtenidos a partir de la recolección de las métricas?
Respuesta
Tiempo Dedicado
215
Pregunta 3 Ge.Me.An.01
En base a su experiencia, ¿qué dificultades encontró para identificar las métricas que son útiles para su proyecto en particular?
Respuesta
Tiempo Dedicado
Pregunta 4 Ge.Me.Ev.02
¿Cómo logró superar las dificultades anteriormente expresadas?
Respuesta
Tiempo Dedicado
Pregunta 5 Ge.Me.Ev.03
¿Qué aconsejaría usted hacer para asegurar que las métricas seleccionadas son las adecuadas para un proyecto en particular?
Respuesta
Tiempo Dedicado
Pregunta 6 Ge.Me.Si.01
Relate, en no menos de cuatro o cinco líneas, las lecciones aprendidas durante el proceso de planificación de métricas.
Respuesta
Tiempo Dedicado
Pregunta 7 Ge.Me.Si.02
Los miembros del proyecto que se dedican a la planificación y gestión de métricas necesitan un entrenamiento inicial para prepararse para la tarea. ¿De qué manera planearía usted este entrenamiento?
Respuesta
Tiempo Dedicado
Pegunta 8 Ge.Me.Ev.04
De las actividades relativas a la planificación y gestión de métricas que llevó a cabo en el presente proyecto, ¿cuáles considera que realizó adecuadamente y cuáles considera que debería mejorar la próxima vez?
Respuesta
Tiempo Dedicado
Espacio Libre
216
A2.3 Cuestionario de evaluación de las guías de reflexión para Ingeniería de Requisitos
Cuestionario de Evaluación de la Guía de Reflexión – Ingeniería de Requisitos Proyecto: ____________________________ Nombre: _________________________________ Propósito: Recabar opinión acerca de las Guías de Reflexión como herramienta para facilitar la reflexión. 1. La lectura de la Guía de Reflexión en forma previa a la realización de mis tareas de proyecto me hubiera
permitido prepararme mejor para llevar a cabo esas tareas.
Muy en desacuerdo En desacuerdo Indiferente De acuerdo Muy de acuerdo
2. La respuesta dada a cada pregunta estuvo directamente vinculada a mi experiencia personal adquirida
en el proyecto.
Muy
en
desc
uerd
o En
des
acue
rdo
Indi
fere
nte
De
acue
rdo
Muy
de
acue
rdo
Pregunta 1 Req.Eli.An.01 2 Req.Eli.Ap.01 3 Req.Eli.Ev.01 4 Req.Eli.Si.01 5 Req.An.An.01 6 Req.An.Ev.01 7 Req.Prep.Si.01 8 Req.Prep.Ev.01 9 Req.-.Ev.01
3. La pregunta me instó a reflexionar detenidamente acerca de la respuesta a dar a la misma.
Muy
en
desc
uerd
o En
des
acue
rdo
Indi
fere
nte
De
acue
rdo
Muy
de
acue
rdo
Pregunta 1 Req.Eli.An.01 2 Req.Eli.Ap.01 3 Req.Eli.Ev.01 4 Req.Eli.Si.01 5 Req.An.An.01 6 Req.An.Ev.01 7 Req.Prep.Si.01 8 Req.Prep.Ev.01 9 Req.-.Ev.01
217
4. Haber reflexionado y respondido a la pregunta me permitió identificar “brechas” en mis conocimientos
relativos a los temas abordados en las mismas.
Muy
en
desc
uerd
o En
des
acue
rdo
Indi
fere
nte
De
acue
rdo
Muy
de
acue
rdo
Pregunta 1 Req.Eli.An.01 2 Req.Eli.Ap.01 3 Req.Eli.Ev.01 4 Req.Eli.Si.01 5 Req.An.An.01 6 Req.An.Ev.01 7 Req.Prep.Si.01 8 Req.Prep.Ev.01 9 Req.-.Ev.01
5. Haber reflexionado y respondido a la pregunta me permitió identificar aspectos de mi actuación en el
proyecto que considero deberé mejorar en una próxima instancia.
Muy
en
desc
uerd
o En
des
acue
rdo
Indi
fere
nte
De
acue
rdo
Muy
de
acue
rdo
Pregunta 1 Req.Eli.An.01 2 Req.Eli.Ap.01 3 Req.Eli.Ev.01 4 Req.Eli.Si.01 5 Req.An.An.01 6 Req.An.Ev.01 7 Req.Prep.Si.01 8 Req.Prep.Ev.01 9 Req.-.Ev.01
6. En general, considero a las Guías de Reflexión como un instrumento útil para facilitar la reflexión sobre
mis conocimientos y mi actuación profesional.
Muy en desacuerdo En desacuerdo Indiferente De acuerdo Muy de acuerdo
218
A2.4 Cuestionario de evaluación de las Guías de reflexión para métricas de gestión de proyectos
Cuestionario de Evaluación de la Guía de Reflexión – Métricas de Proyecto
Proyecto: ____________________________ Nombre: _________________________________ Propósito: Recabar opinión acerca de las Guías de Reflexión como herramienta para facilitar la reflexión. 1. La lectura de la Guía de Reflexión en forma previa a la realización de mis tareas de proyecto me hubiera
permitido prepararme mejor para llevar a cabo esas tareas.
Muy en desacuerdo En desacuerdo Indiferente De acuerdo Muy de acuerdo
2. La respuesta dada a cada pregunta estuvo directamente vinculada a mi experiencia personal adquirida
en el proyecto.
Muy
en
desc
uerd
o
En d
esac
uerd
o
Indi
fere
nte
De
acue
rdo
Muy
de
acue
rdo
Pregunta 1 Ge.Me.Ev.01 2 Ge.Me.Ap.01 3 Ge.Me.An.01 4 Ge.Me.Ev.02 5 Ge.Me.Ev.03 6 Ge.Me.Si.01 7 Ge.Me.Si.02 8 Ge.Me.Ev.04
219
3. La pregunta me instó a reflexionar detenidamente acerca de la respuesta a dar a la misma.
Muy
en
desc
uerd
o
En d
esac
uerd
o
Indi
fere
nte
De
acue
rdo
Muy
de
acue
rdo
Pregunta 1 Ge.Me.Ev.01 2 Ge.Me.Ap.01 3 Ge.Me.An.01 4 Ge.Me.Ev.02 5 Ge.Me.Ev.03 6 Ge.Me.Si.01 7 Ge.Me.Si.02 8 Ge.Me.Ev.04
4. Haber reflexionado y respondido a la pregunta me permitió identificar “brechas” en mis conocimientos
relativos a los temas abordados en las mismas.
Muy
en
desc
uerd
o
En d
esac
uerd
o
Indi
fere
nte
De
acue
rdo
Muy
de
acue
rdo
Pregunta 1 Ge.Me.Ev.01 2 Ge.Me.Ap.01 3 Ge.Me.An.01 4 Ge.Me.Ev.02 5 Ge.Me.Ev.03 6 Ge.Me.Si.01 7 Ge.Me.Si.02 8 Ge.Me.Ev.04
220
5. Haber reflexionado y respondido a la pregunta me permitió identificar aspectos de mi actuación en el
proyecto que considero deberé mejorar en una próxima instancia.
Muy
en
desc
uerd
o
En d
esac
uerd
o
Indi
fere
nte
De
acue
rdo
Muy
de
acue
rdo
Pregunta 1 Ge.Me.Ev.01 2 Ge.Me.Ap.01 3 Ge.Me.An.01 4 Ge.Me.Ev.02 5 Ge.Me.Ev.03 6 Ge.Me.Si.01 7 Ge.Me.Si.02 8 Ge.Me.Ev.04
6. En general, considero a las Guías de Reflexión como un instrumento útil para facilitar la reflexión sobre
mis conocimientos y mi actuación profesional.
Muy en desacuerdo En desacuerdo Indiferente De acuerdo Muy de acuerdo
221
A2.5 Plantilla para el documento de Resumen de respuestas de las Guías de reflexión para ingeniería de requisitos
Resumen de respuestas de las Guías de Reflexión – Requisitos Software Pregunta 1 – ¿Qué aspectos considera usted que es importante que se tomen en cuenta a la hora de planificar una entrevista?
Proyecto GESA
Proyecto COODESOR
Proyecto SCPI .
Proyecto InvPortal
Pregunta 2 – Una buena comunicación con el usuario es clave para lograr recolectar información. Exponga los problemas más relevantes que ha tenido para establecer una comunicación efectiva y cómo los ha superado.
Proyecto GESA
Proyecto COODESOR
Proyecto SCPI
Proyecto InvPortal
Pregunta 3 – ¿Qué recomendaría usted a un ingeniero de requerimiento que se enfrenta a un usuario con necesidades poco claras?
Proyecto GESA
Proyecto COODESOR
Proyecto SCPI
Proyecto InvPortal
222
Pregunta 4 – Relate en no menos de cuatro o cinco líneas aquella experiencia de entrevista que usted considera que fue la más exitosa y que volvería a repetir.
Proyecto GESA
Proyecto COODESOR
Proyecto SCPI
Proyecto InvPortal
Pregunta 5 – En base a su experiencia, ¿qué dificultades encontró para distinguir los requerimientos funcionales de los no funcionales?
Proyecto GESA
Proyecto COODESOR
Proyecto SCPI
Proyecto InvPortal
Pregunta 6 – ¿Cómo logro superar las dificultades anteriormente expresadas?
Proyecto GESA
Proyecto COODESOR
Proyecto SCPI
Proyecto InvPortal
223
Pregunta 7 – Los miembros del proyecto que se dedican a la ingeniería de requerimiento necesitan un entrenamiento inicial para prepararse para la tarea. ¿De qué manera planearía usted este entrenamiento?
Proyecto GESA
Proyecto COODESOR
Proyecto SCPI
Proyecto InvPortal
Pregunta 8 – A su juicio, ¿qué habilidades personales facilitarían las tareas de ingeniero de requerimientos?
Proyecto GESA
Proyecto COODESOR
Proyecto SCPI
Proyecto InvPortal
Pregunta 9 – De las actividades de IR que llevó a cabo en el presente proyecto, ¿cuáles considera que realizó adecuadamente y cuales considera que deberá mejorar la próxima vez?
Proyecto GESA
Proyecto COODESOR
Proyecto SCPI
Proyecto InvPortal
224
A2.6 Plantilla para el documento de Resumen de respuestas de las Guías de reflexión para métricas de gestión de proyectos
Resumen de respuestas de las Guías de Reflexión – Métricas de gestión de proyectos Pregunta 1 – ¿Qué métricas planificó recolectar para su proyecto? ¿Por qué considera que estas métricas son adecuadas para su proyecto en particular?
Proyecto GESA
Proyecto COODESOR
Proyecto SCPI .
Proyecto InvPortal
Pregunta 2 – ¿Cómo llevó a cabo el análisis de los datos obtenidos a partir de la recolección de las métricas?
Proyecto GESA
Proyecto COODESOR
Proyecto SCPI .
Proyecto InvPortal
Pregunta 3 – En base a su experiencia, ¿qué dificultades encontró para identificar las métricas que son útiles para su proyecto en particular?
Proyecto GESA
Proyecto COODESOR
Proyecto SCPI
Proyecto InvPortal
225
Pregunta 4 – ¿Cómo logró superar las dificultades anteriormente expresadas?
Proyecto GESA
Proyecto COODESOR
Proyecto SCPI
Proyecto InvPortal
Pregunta 5 – ¿Qué aconsejaría usted hacer para asegurar que las métricas seleccionadas son las adecuadas para un proyecto en particular?
Proyecto GESA
Proyecto COODESOR
Proyecto SCPI
Proyecto InvPortal
Pregunta 6 – Relate, en no menos de cuatro o cinco líneas, las lecciones aprendidas durante el proceso de planificación de métricas.
Proyecto GESA
Proyecto COODESOR
Proyecto SCPI
Proyecto InvPortal
226
Pregunta 7 – Los miembros del proyecto que se dedican a la planificación y gestión de métricas necesitan un entrenamiento inicial para prepararse para la tarea. ¿De qué manera planearía usted este entrenamiento?
Proyecto GESA
Proyecto COODESOR
Proyecto SCPI
Proyecto InvPortal
Pregunta 8 – De las actividades relativas a la planificación y gestión de métricas que llevó a cabo en el presente proyecto, ¿cuáles considera que realizó adecuadamente y cuáles considera que debería mejorar la próxima vez?
Proyecto GESA
Proyecto COODESOR
Proyecto SCPI
Proyecto InvPortal
227
A2.7 Cuestionario de evaluación de Taller de Educción de Conocimientos y Experiencia
Cuestionario de Evaluación del Taller Proyecto: ___________________________ Nombre: _________________________________ Propósito: Recabar la opinión del participante sobre los siguientes tres aspectos del Taller de Educción de
Conocimientos:
• Organización (preguntas 1 a 4) • Participación (preguntas 5 a 8) • Contenido (pregunta 9)
1. Los objetivos del taller estuvieron claramente definidos.
Muy en desacuerdo En desacuerdo Indiferente De acuerdo Muy de acuerdo
2. La duración del taller fue adecuada.
Muy en desacuerdo En desacuerdo Indiferente De acuerdo Muy de acuerdo
3. El material recibido como insumo para la realización del taller fue satisfactorio en cuanto a su estructura y
contenido.
Muy en desacuerdo En desacuerdo Indiferente De acuerdo Muy de acuerdo
4. El lugar físico elegido para realizar el taller fue adecuado.
Muy en desacuerdo En desacuerdo Indiferente De acuerdo Muy de acuerdo
5. Valoro como muy positivo el haber podido conocer y discutir, durante el taller, las experiencias de los
otros participantes.
Muy en desacuerdo En desacuerdo Indiferente De acuerdo Muy de acuerdo
228
6. Con la participación en el taller considero que he aumentado mis conocimientos sobre los temas tratados
en el mismo.
Muy en desacuerdo En desacuerdo Indiferente De acuerdo Muy de acuerdo
7. Los conocimientos adquiridos en el taller me permitirán realizar un mejor desempeño en proyectos
futuros.
Muy en desacuerdo En desacuerdo Indiferente De acuerdo Muy de acuerdo
8. En general, considero que el taller fue una experiencia positiva.
Muy en desacuerdo En desacuerdo Indiferente De acuerdo Muy de acuerdo
9. De los cuatro temas tratados en el taller, el o los más interesantes fueron:
Muy
en
desc
uerd
o
En d
esac
uerd
o
Indi
fere
nte
De
acue
rdo
Muy
de
acue
rdo
Tema 1 Planificación de entrevistas 2 Interacción con el entrevistado 3 Habilidades personales del Ing. de Req. 4 Entrenamiento inicial sobre Ing. de Req
229
A2.8 Guía para la realización del Taller de educción de conocimientos y experiencia
Guía para la realización del Taller Propósito: Analizar en forma colectiva las respuestas dadas a las preguntas de las Guías de Reflexión. Fecha: __ / __ / 2007 Lugar: Sala de reuniones (Salón ___) Hora inicio: __ : __ Hora fin: __ : __ Participantes: Laura Rodríguez, Ana Estela, Gerardo Matturro (GCCA) Carlos Geribón [email protected] (Proyecto OUA) Andrés Lapachian [email protected] (Proyecto SCPI) Daniel Nicolich [email protected] (Proyecto COODESOR) Alicia Pino [email protected] (Proyecto InvPortal) Temario: Planificación de entrevista Interacción con el entrevistado Clasificación de requerimientos en “funcionales” y “no funcionales” Entrenamiento inicial sobre Ingeniería de Requerimientos 1. Objetivos
• Capturar los conocimientos y aprendizajes logrados durante la realización de las actividades de proyecto. • Obtener lecciones aprendidas y generar propuestas de mejora a las prácticas de Ingeniería de
Requisitos referidas en el temario. 2. Actividad disparadora
• Distribuir a los participantes el documento de respuestas consolidadas. • Solicitar a cada participante que analice las respuestas dadas por los otros participantes y que identifique
las coincidencias y las discrepancias respecto de sus propias respuestas. 3. Momento de reflexión Analizar y discutir las coincidencias y las discrepancias identificadas en la actividad anterior. 3.1 Planificación de la entrevista: Pregunta 1
Análisis de coincidencias y de discrepancias 3.2 Interacción con el entrevistado: Preguntas 2 y 3
Análisis de coincidencias y de discrepancias 3.3 Habilidades personales del ingeniero de requisitos: Pregunta 8
Análisis de coincidencias y de discrepancias 3.4 Entrenamiento inicial sobre Ingeniería de Requerimientos: Pregunta 7
Análisis de coincidencias y de discrepancias 4. Evaluación 4.1 Planificación de la entrevista: Pregunta 1 4.2 Interacción con el entrevistado: Preguntas 2 y 3 4.3 Habilidades personales del ingeniero de requisitos: Pregunta 8 4.4 Entrenamiento inicial sobre Ingeniería de Requerimientos: Pregunta 7
230
A2.9 Plantilla para el documento de Resultados del taller de educción de conocimientos y experiencia
Reporte del Taller de educción de conocimientos y experiencia Fecha: __ / __ / ____
Lugar: _________________
Hora inicio: __:__
Hora fin: __:__
Asistentes: Asistente 1 Asistente 2 Asistente 3 : 1. Planificación de la entrevista 2. Interacción con el entrevistado 3. Habilidades personales del Ingeniero de Requerimientos 4. Entrenamiento inicial del responsable de la Ingeniería de Requerimientos
231
Apéndice 3. BASE DE DATOS DEL ESTUDIO
Se incluye en este apéndice la información creada, recolectada y utilizada durante
todo el proceso de la investigación.
Item. Documento A3.1 Informes de Revisión de proyectos anteriores desarrollados en ORTsf A3.2 Planilla de análisis de los reportes de revisión A3.3 Descripción de los proyectos seleccionados para el estudio A3.4 Guías de reflexión para Ingeniería de Requisitos, completadas por los
ingenieros de requisitos de los grupos de proyectos participantes A3.5 Documento de Resumen de Respuestas de las guías de reflexión para
Ingeniería de Requisitos A3.6 Cuestionarios de evaluación de las Guías de reflexión para ingeniería de
requisitos, respondidos por los ingenieros de requisitos de los grupos de proyectos participantes
A3.7 Guía de Reflexión para Métricas de Gestión de Proyecto, completadas
por los gerentes de proyecto de los grupos de proyectos participantes A3.8 Documento de Resumen de Respuestas de las guías de reflexión para
Métricas de Gestión de Proyecto A3.9 Cuestionario de evaluación de las Guías de reflexión para Métricas de
gestión de proyectos, respondidos por los gerentes de proyecto de los grupos de proyectos participantes
A3.10 Reporte de resultados del Taller de Educción de Conocimientos y
Experiencia A3.11 Cuestionarios de evaluación del Taller de educción de conocimientos y
experiencia, respondidos por los ingenieros de requisitos que asistieron al mismo
A3.12 Resumen de reuniones con el GGCA A3.13 Documentos de los grupos de proyecto participantes (extractos)
232
A3.1 Informes de Revisión de proyectos anteriores desarrollados en ORTsf GRUPO: Desarrollo para la Cooperativa Bancaria FECHA: 22/06/2004 EVALUADORES: [AO, EM] NOTA: Es importante que el grupo recuerde que este es un instrumento para ayudar al grupo a analizar, entender y mejorar su forma de trabajo; y que es el resultado de una instancia breve de evaluación. Por esta razón es recomendable analizar y evaluar la pertinencia de las observaciones aquí registradas. Si hubiese dudas sobre su contenido es importante que el grupo contacte a los evaluadores con el fin de clarificar aquellos aspectos poco claros. PUNTOS FUERTES 1. Se observa un grupo cohesivo, que mantiene una buena comunicación interna y con el cliente. 2. Buena presentación de los procesos de Ingeniería de Software definidos. 3. Buen relevamiento de Requerimientos Funcionales. OPORTUNIDADES DE MEJORA 1. Rever los riesgos relacionados con la tecnología. 2. Definir y acordar claramente con el Cliente los mecanismos de integración e interoperabilidad con otros
sistemas de la organización y de MontevideoCOM. 3. Definir claramente como funciona todo el proceso de pedidos y distribución, incluyendo los pasos ajenos
al sistema a desarrollar, de forma poder proveer la mejor solución al Cliente. 4. Realizar una planificación que incluya objetivos claros de corto plazo, y al menos de alto nivel para la
totalidad del proyecto. SUGERENCIAS 1. Evaluar si todas las actividades y procesos de Ingeniería de Software definidos son aplicables y generan
valor; los que no, descartarlos y justificar. 2. Revisar los procesos de SCM, especialmente para las actividades de Desarrollo. 3. Realizar una validación de las decisiones técnicas tomadas. GRUPO: Lotario – Data View Generator FECHA: 28/07/2004 EVALUADORES: [GM, RB] NOTA: Es importante que el grupo recuerde que este es un instrumento para ayudar al grupo a analizar, entender y mejorar su forma de trabajo; y que es el resultado de una instancia breve de evaluación. Por esta razón es recomendable analizar y evaluar la pertinencia de las observaciones aquí registradas. Si hubiese dudas sobre su contenido es importante que el grupo contacte a los evaluadores con el fin de clarificar aquellos aspectos poco claros. PUNTOS FUERTES - Grupo cohesivo - Arquitectura del producto apropiada a los requerimientos funcionales - Prototipación como herramienta de validación / descubrimiento de nuevos requerimientos. - Marcado interés por tener establecido un proceso de desarrollo, al que tratan de mantener actualizado a
las necesidades de producto y del proyecto. - El riesgo relativo al uso de una dll para implementar Prolog está identificado. Recomendamos mantener seguimiento cercano. OPORTUNIDADES DE MEJORA - Confirmar la lista de requerimientos no funcionales, por ejemplo, sobre testeabilidad, documentación de
interfases que ofrece el producto, tiempos de respuesta, volúmenes a manejar. - Analizar el orden del algoritmo de conversión de los metadatos a especificación Genexus. - Acompañar la agilidad del proceso seleccionado con estrategias de aseguramiento de la calidad. Por
ejemplo, pensar en la prueba antes de la codificación. - Hacer un esfuerzo para determinar claramente el alcance de cada iteración, tanto en lo relativo a la
funcionalidad a alcanzar, como en el nivel de prueba a que piensan someterla, y contraponerlo con el esfuerzo disponible.
SUGERENCIAS - Fomentar la participación de todos los integrantes en la presentación, más que nada pensando en la
defensa final. - Analizar la estrategia de comunicación del producto y de los resultados obtenidos, de modo de que
optimice el tiempo disponible en las defensas. Es decir, identificar qué material es más útil como información escrita, cual es más útil para ser comunicada oralmente. En particular, piensen que su producto no es fácil de evaluar para alguien que no conoce de la naturaleza del problema. ¿Cual será la forma de que una demo sea interesante? Convendrá mostrar el resultado una vez que se consolida en Genexus?
- El uso de estándares de nomenclatura facilita la comprensión por parte de terceros (p.ej. UML en todos los diagramas)
233
GRUPO: GDSTool FECHA: 23/06/2005 EVALUADORES: [AA, EM] NOTA: Es importante que el grupo recuerde que este es un instrumento para ayudar al grupo a analizar, entender y mejorar su forma de trabajo; y que es el resultado de una instancia breve de evaluación. Por esta razón es recomendable analizar y evaluar la pertinencia de las observaciones aquí registradas. Si hubiese dudas sobre su contenido es importante que el grupo contacte a los evaluadores con el fin de clarificar aquellos aspectos poco claros. PUNTOS FUERTES 1. Elección de un proyecto ambicioso y altamente desafiante por la complejidad tecnológica involucrada y el
escaso conocimiento del dominio del problema por parte de los integrantes del grupo. 2. Planificación de la capacitación e investigación por parte de los integrantes del grupo. OPORTUNIDADES DE MEJORA 1. Revisar la estrategia escogida para abordar la problemática planteada por el proyecto: a. Ciclo de vida, b. organización del trabajo del equipo, c. definición de productos del proyecto (intermedios y finales), d. asignación de roles y e. estrategia de desarrollo. 2. Orientar el foco del proyecto a las actividades vinculadas al proceso de Ingeniería (IR, ARQ, Desarrollo y
Testing). 3. Organizar la forma de trabajo y el plan del proyecto de acuerdo al tipo de proceso que el grupo plantea
seguir. Si van a trabajar con un proceso ágil, sería importante definir las reglas de funcionamiento y las prácticas a utilizar.
SUGERENCIAS 1. En la descripción de los riesgos del proyecto se recomienda realizar una descripción lo más precisa
posible del riesgo y tratar de evitar hacerlo en términos del posible problema. 2. Incluir en la presentación una descripción de la empresa ICA que permita comprender mejor el por qué
del relacionamiento con la misma. ACCIONES Dada la importancia de las oportunidades de mejora detectadas, nos gustaría agendar una nueva revisión abreviada al grupo en un período de 15 días para evaluar las decisiones tomadas por el grupo luego de la revisión. GRUPO: ArqNet FECHA: 10/06/2004 EVALUADORES: [MS, RB] NOTA: Es importante que el grupo recuerde que este es un instrumento para ayudar al grupo a analizar, entender y mejorar su forma de trabajo; y que es el resultado de una instancia breve de evaluación. Por esta razón es recomendable analizar y evaluar la pertinencia de las observaciones aquí registradas. Si hubiese dudas sobre su contenido es importante que el grupo contacte a los evaluadores con el fin de clarificar aquellos aspectos poco claros. PUNTOS FUERTES 1. Se muestra como un grupo cohesivo y comprometido con el resultado final del proyecto, tanto desde el
punto de vista del cliente, del producto como del académico. 2. El enfoque seleccionado para la ingeniería de requerimientos parece adecuada al producto y a las
características de los usuarios, ya que están descubriendo el producto a medida que avanza el proyecto. 3. Se valora el esfuerzo de definir su propia forma de trabajo, y se comparte la decisión por metodologías
ágiles. 4. También se valora la iniciativa de trabajar en la integración de dos paradigmas: Genexus y XP. 5. La presentación fue clara y concisa. OPORTUNIDADES DE MEJORA 1. Los procesos de apoyo (SQA, Gestión) no parecen tener el mismo grado de aplicación que el proceso de
Construcción. Sugerimos se piense en dos riesgos: 2. Los recursos están establecidos, y los plazos también. Por lo tanto la figura de la administración del
proyecto podrá requerir más presencia en el proceso de desarrollo. Este rol permitiría contar con una mirada en perspectiva del proyecto.
3. Por la misma razón, y a los efectos de que las decisiones deriven en mejoras en la eficiencia, es útil contar con indicadores objetivos, como tasas de defectos, índices de productividad por pareja de desarrolladores, etc.
4. Existen requerimientos (acceso a planos CAD, tiempos de transferencia) que podrían evaluarse tempranamente para minimizar riesgos.
234
5. Los requerimientos de control de acceso a la información, auditoría, no parecen estar totalmente especificados. Evaluar el impacto sobre el diseño.
6. El proceso de transferencia al personal del cliente debería participar de la lista de entregables del proyecto.
7. Analizar la definición de un circuito de cambios, adaptado a la metodología ágil. Recibiría las solicitudes de cambio, que se originen por feedback del cliente o defectos encontrados.
SUGERENCIAS 1. La arquitectura de la solución será evaluada en la próxima revisión. 2. Considerar la complejidad del proceso de migración de datos y posibilidad de automatizar la prueba del
mismo. GRUPO: ArqNet FECHA: 05/08/2004 EVALUADORES: [MS, RB] NOTA: Es importante que el grupo recuerde que este es un instrumento para ayudar al grupo a analizar, entender y mejorar su forma de trabajo; y que es el resultado de una instancia breve de evaluación. Por esta razón es recomendable analizar y evaluar la pertinencia de las observaciones aquí registradas. Si hubiese dudas sobre su contenido es importante que el grupo contacte a los evaluadores con el fin de clarificar aquellos aspectos poco claros. PUNTOS FUERTES 1. Se muestra como un grupo cohesivo y comprometido con el resultado final del proyecto, tanto desde el
punto de vista del cliente, del producto como del académico. 2. La solución técnica que se dio a los requerimientos no funcionales como usabilidad y control de acceso
parecen adecuados. 3. Adecuado manejo del proceso de cambio, fundamentalmente cuando lo solicita el cliente. 4. La facilidad para realizar los ajustes sobre el proceso de desarrollo han mostrado que la opción por
metodologías ágiles les dio resultado. 5. La decisión de incluir opciones para registrar sugerencias dentro de la aplicación es un aspecto a
resaltar. 6. A partir de la evaluación temprana del avance proyecto, se renegoció el alcance y calendario con el
cliente. 7. Se gestionó el riesgo potencial de un cambio en la integración del equipo, realizando una reestructura de
roles y estableciendo un nuevo lugar de trabajo. OPORTUNIDADES DE MEJORA 1. A los efectos de que las decisiones deriven en mejoras en la eficiencia, es útil contar con indicadores
objetivos, como tasas de defectos, índices de productividad por pareja de desarrolladores, distribución de esfuerzo por actividad, etc. Poner el esfuerzo, en el contexto de otros indicadores.
2. Sugerimos pensar alternativas para minimizar el riesgo de que una nueva migración de información (en este caso los planos CAD) no deriven en otro proceso difícil de controlar. Por ejemplo, realizar muestreos que permitan medir tiempos y tasas de incongruencia en los datos.
3. Otro riesgo potencial es el tiempo requerido para implantar la solución en el ambiente final de producción. Sugerimos analizar detalladamente los entregables requeridos (documentación del producto, instructivos de instalación, productos derivados de requerimientos de seguridad y/o control de acceso, etc. De allí pueden derivarse tareas adicionales.
4. Formalizar las actividades de aseguramiento de la calidad, ya sean preventivas o correctivas, para medirlas y evaluarlas. Permitiría hacer un análisis costo-beneficio de las mismas, para mejorar el proceso.
SUGERENCIAS 1. La arquitectura del producto es información relevante para comprender la solución. Sugerimos se le
reserve tiempo en la defensa final. 2. En la defensa final se espera que todos los integrantes participen de alguna manera. GRUPO: Métricas FECHA: 16/06/2004 EVALUADORES: [AA, MS] NOTA: Es importante que el grupo recuerde que este es un instrumento para ayudar al grupo a analizar, entender y mejorar su forma de trabajo; y que es el resultado de una instancia breve de evaluación. Por esta razón es recomendable analizar y evaluar la pertinencia de las observaciones aquí registradas. Si hubiese dudas sobre su contenido es importante que el grupo contacte a los evaluadores con el fin de clarificar aquellos aspectos poco claros.
235
PUNTOS FUERTES 1. Se observa un grupo cohesivo y con buena comunicación, motivado para resolver el problema
académico planteado. 2. Se realizo un relevamiento del problema interactuando con el cliente-tutor y otros docentes del área.
También se profundizo a partir de un artículo técnico, que sirvió como base para el modelo de métricas. 3. Están definidos los principales requerimientos del sistema y los distintos tipos de usuarios del mismo. 4. Se cuenta con una primera versión de la arquitectura, modelo de datos y una selección de herramientas
de desarrollo, en base a las restricciones planteadas (base de datos, servidor web, etc.). 5. El ciclo de vida utilizado parece adecuado a las necesidades del proyecto, estableciendo puntos de
planificación y evaluación en cada iteración. OPORTUNIDADES DE MEJORA 1. Obtener a corto plazo resultados de desarrollo, permitiría mitigar varios riesgos, como el
desconocimiento de las herramientas y contar con estimación realistas. También permitiría evaluar la forma de trabajo planificada.
2. Analizar planificar con mayor detalle la actividad de capacitación, poniendo una cota temporal o resultados concretos como objetivo de la misma. Estos resultados se podrían integrar con los objetivos del proyecto.
3. Considerar el uso de la prototipación como forma de profundizar el relevamiento y validación de los requerimientos, aprovechando como marco de colaboración y disponibilidad del cliente.
4. Profundizar en la definición de responsabilidades internas del equipo. Cada rol aportaría una visión en distintas áreas del proyecto y la posibilidad de distribuir el trabajo.
5. Seleccionar un grupo reducido de métricas para controlar el proyecto y evaluarlas en plazos cortos, por ejemplo por iteración. Evaluar sólo un conjunto de métricas que de utilidad para tomar decisiones.
6. A partir de las iteraciones de desarrollo, se podría realizar una planificación de alto nivel para el resto del proyecto y definir el alcance.
7. En función de las próximas fases del proyecto, profundizar las prácticas de ingeniería de software de construcción, integración y prueba.
SUGERENCIAS 1. En la presentación, realizar una presentación del grupo, detenerse y profundizar en los conceptos sobre
métricas, que son claves para el proyecto y la meta modelo del software. 2. Revisar la estructura del plan de la calidad. 3. Darle un nombre propio al proyecto y al producto. GRUPO: Métricas FECHA: 16/06/2004 EVALUADORES: [AA, MS] NOTA: Es importante que el grupo recuerde que este es un instrumento para ayudar al grupo a analizar, entender y mejorar su forma de trabajo; y que es el resultado de una instancia breve de evaluación. Por esta razón es recomendable analizar y evaluar la pertinencia de las observaciones aquí registradas. Si hubiese dudas sobre su contenido es importante que el grupo contacte a los evaluadores con el fin de clarificar aquellos aspectos poco claros. PUNTOS FUERTES 1. Se observa un grupo cohesivo y con buena comunicación, motivado para resolver el problema
académico planteado. 2. Se realizo un relevamiento del problema interactuando con el cliente-tutor y otros docentes del área.
También se profundizo a partir de un artículo técnico, que sirvió como base para el modelo de métricas. 3. Están definidos los principales requerimientos del sistema y los distintos tipos de usuarios del mismo. 4. Se cuenta con una primera versión de la arquitectura, modelo de datos y una selección de herramientas
de desarrollo, en base a las restricciones planteadas (base de datos, servidor web, etc.). 5. El ciclo de vida utilizado parece adecuado a las necesidades del proyecto, estableciendo puntos de
planificación y evaluación en cada iteración. OPORTUNIDADES DE MEJORA 1. Obtener a corto plazo resultados de desarrollo, permitiría mitigar varios riesgos, como el
desconocimiento de las herramientas y contar con estimación realistas. También permitiría evaluar la forma de trabajo planificada.
2. Analizar planificar con mayor detalle la actividad de capacitación, poniendo una cota temporal o resultados concretos como objetivo de la misma. Estos resultados se podrían integrar con los objetivos del proyecto.
3. Considerar el uso de la prototipación como forma de profundizar el relevamiento y validación de los requerimientos, aprovechando como marco de colaboración y disponibilidad del cliente.
4. Profundizar en la definición de responsabilidades internas del equipo. Cada rol aportaría una visión en distintas áreas del proyecto y la posibilidad de distribuir el trabajo.
5. Seleccionar un grupo reducido de métricas para controlar el proyecto y evaluarlas en plazos cortos, por ejemplo por iteración. Evaluar sólo un conjunto de métricas que de utilidad para tomar decisiones.
6. A partir de las iteraciones de desarrollo, se podría realizar una planificación de alto nivel para el resto del
236
proyecto y definir el alcance. 7. En función de las próximas fases del proyecto, profundizar las prácticas de ingeniería de software de
construcción, integración y prueba. SUGERENCIAS 1. En la presentación, realizar una presentación del grupo, detenerse y profundizar en los conceptos sobre
métricas, que son claves para el proyecto y la meta modelo del software. 2. Revisar la estructura del plan de la calidad. 3. Darle un nombre propio al proyecto y al producto. GRUPO: Framework PPC FECHA: 17/06/2004 EVALUADORES: [EM, MS] NOTA: Es importante que el grupo recuerde que este es un instrumento para ayudar al grupo a analizar, entender y mejorar su forma de trabajo; y que es el resultado de una instancia breve de evaluación. Por esta razón es recomendable analizar y evaluar la pertinencia de las observaciones aquí registradas. Si hubiese dudas sobre su contenido es importante que el grupo contacte a los evaluadores con el fin de clarificar aquellos aspectos poco claros. PUNTOS FUERTES 1. Se observa un grupo cohesivo, que mantiene una buena comunicación interna y con el cliente. 2. Cuentan con la colaboración del cliente para desarrollar el proyecto, realizaron reuniones semanales
para relevar requerimientos. 3. Las investigaciones realizadas permitieron tomar decisiones sobre el proceso y la arquitectura del
producto. También prepararon al equipo para las próximas fases del proyecto. 4. Identifican los principales riesgos tecnológicos y de gestión del proyecto. 5. Presentación clara y concisa. OPORTUNIDADES DE MEJORA 1. Por la complejidad del desarrollo de un framework de infraestructura, profundizar en la definición inicial
de requerimientos del mismo. 2. Definir los atributos de calidad y especificar los casos de uso más importantes podrían facilitar un diseño
arquitectónico temprano. 3. Considerar realizar un prototipo a corto plazo, que permita evaluar el rendimiento del equipo en las
actividades de diseño y construcción, ajustar la estimación y la metodología de trabajo. 4. El proceso de desarrollo presentado contiene actividades de alto nivel, (QFD, plan de métricas,
estándares) considerar utilizar prácticas más concretas, ajustadas por el aprendizaje obtenido en cada iteración.
5. Evaluar la desviación del esfuerzo invertido. Considerar las causas, para ajustar en forma objetiva la planificación del proyecto.
SUGERENCIAS 1. En la presentación dar detalles sobre la funcionalidad del sistema de información, ejemplificar con
escenarios de uso del PPC. GRUPO: MAIS FECHA: 14/06/2004 EVALUADORES: [MU, MS] NOTA: Es importante que el grupo recuerde que este es un instrumento para ayudar al grupo a analizar, entender y mejorar su forma de trabajo; y que es el resultado de una instancia breve de evaluación. Por esta razón es recomendable analizar y evaluar la pertinencia de las observaciones aquí registradas. Si hubiese dudas sobre su contenido es importante que el grupo contacte a los evaluadores con el fin de clarificar aquellos aspectos poco claros. PUNTOS FUERTES 1. Se observa un grupo trabajando en un problema de alta complejidad e interactuando con el cliente para
especificar una solución. 2. Las investigaciones realizadas han sido evaluadas positivamente por el cliente y han permitido tomar
decisiones importantes a nivel arquitectónico. 3. La utilización de diversas técnicas para la ingeniería de requerimientos (tormenta de ideas, cuestionarios,
ingeniería reversa, investigaciones) permitió obtener una lista priorizada de requerimientos funcionales y no funcionales concretos para el producto.
4. Se han planificado las comunicaciones y el proceso en función de un equipo que trabaja en forma distribuida y sus integrantes están sujetos a viajes.
OPORTUNIDADES DE MEJORA 1. Algunas actividades del proceso cuentan con planes detallados, analizar poner en marcha estos planes y
elegir prácticas de desarrollo concretas para evaluarlas en cada iteración.
237
2. Considerar la construcción temprana de prototipos, que permitan validar aspectos complejos de la arquitectura.
3. Estimar a alto nivel el tamaño (a partir de casos de uso o de la arquitectura) para la negociación del alcance del producto.
4. Profundizar en la definición de estrategias de integración y prueba. Considerar las necesidades de simulación y automatización de la prueba.
SUGERENCIAS 1. Acortar el tiempo de presentación y permitirse hablar de a uno. 2. Incluir escenarios de utilización para ejemplificar la arquitectura. GRUPO: MAIS FECHA: 30/08/2004 EVALUADORES: [MU, MS] NOTA: Es importante que el grupo recuerde que este es un instrumento para ayudar al grupo a analizar, entender y mejorar su forma de trabajo; y que es el resultado de una instancia breve de evaluación. Por esta razón es recomendable analizar y evaluar la pertinencia de las observaciones aquí registradas. Si hubiese dudas sobre su contenido es importante que el grupo contacte a los evaluadores con el fin de clarificar aquellos aspectos poco claros. PUNTOS FUERTES 1. Se percibe un buen clima y motivación en el equipo. 2. Investigación de tecnologías para confirmar la factibilidad técnica de partes importantes del producto. Se
ha logrado un acuerdo con el cliente sobre la plataforma a utilizar y la funcionalidad a desarrollar. 3. Realización de un prototipo que permite probar la plataforma celular y mostrar resultados tempranos al
cliente. 4. Se adaptó el proceso desarrollo, quitando elementos que no aportaban valor. OPORTUNIDADES DE MEJORA 1. Tendiendo en cuenta que el ciclo de vida es evolutivo, analizar la distancia entre la arquitectura
planificada y el prototipo actual, para evaluar los cambios necesarios. 2. Considerar aplicar las prácticas de aseguramiento de la calidad mencionadas, en forma continua, desde
la construcción de prototipos. 3. Se sugiere que cada liberación sea un conjunto de funcionalidad completo y probado, esto puede afectar
la estimación de retrabajo para la siguiente iteración. 4. Profundizar en el monitoreo y evaluación del esfuerzo invertido en cada iteración, para mejorar la
estimación y planificación en forma progresiva. SUGERENCIAS 1. Revisar que los diagramas presentados sean claros. 2. Detenerse para explicar la arquitectura y la demostración del prototipo. GRUPO: Acuario FECHA: 06/09/2005 EVALUADORES: AA, RB NOTA: Es importante que el grupo recuerde que este es un instrumento para ayudar al grupo a analizar, entender y mejorar su forma de trabajo; y que es el resultado de una instancia breve de evaluación. Por esta razón es recomendable analizar y evaluar la pertinencia de las observaciones aquí registradas. Si hubiese dudas sobre su contenido es importante que el grupo contacte a los evaluadores con el fin de clarificar aquellos aspectos poco claros. PUNTOS FUERTES 1. Elección de un proyecto desafiante con elementos que requieren investigación por parte de ambos
integrantes del equipo. 2. Inclusión de actividades de capacitación e investigación en el ciclo de vida elegido, coherente con la
problemática planteada. 3. Elección de una estrategia de desarrollo regida por la prueba, la cual ha sido justificada de acuerdo al
tipo de proyecto y la forma de trabajo. 4. Desarrollo temprano de casos de prueba y datos de prueba. 5. Realización de un análisis de riesgos periódico en el que se revisa la evolución de los riesgos
identificados inicialmente. OPORTUNIDADES DE MEJORA 1. Incluir información de contexto en la introducción de la presentación para asegurar que los revisores
comprendan exactamente la problemática a resolver. 2. Revisar la forma de planificación utilizada, incluyendo especialmente el mecanismo utilizado para estimar
el tamaño del producto y de los componentes, así como también el esfuerzo requerido para su desarrollo y prueba. Podría ser útil para el grupo detallar una lista de todas las tareas a realizar desde la fecha de hoy hasta la finalización del proyecto, en la cual se incluya el esfuerzo estimado requerido para cada una
238
de ellas. Esto luego podría ser divido en semanas de acuerdo al número de horas que el grupo es capaz de hacer por semana y así poder tener una estimación inicial de la fecha posible de finalización y evaluar de forma más precisa, la posibilidad de finalizar en diciembre con el producto desarrollado y probado (por el grupo y por el cliente) completamente.
3. Profundizar en la definición de la estrategia de pruebas del producto, prestando especial atención a las pruebas de integración y de sistema. Evaluar la posibilidad de utilizar casos de prueba que incluyan datos con errores, que podrían originar la necesidad de contemplar funcionalidad valorada para el cliente.
4. Profundizar en la definición y formalización de la arquitectura del producto de forma de evitar posibles problemas ocasionados por la estrategia de desarrollo elegida: modular e independiente entre los integrantes.
5. Revisar la forma de definir las actividades de Aseguramiento de la calidad y la forma de presentar los elementos a evaluar. Recordar que la revisión es una actividad y no un producto. Revisar los elementos que se incluyen bajo el título “Atributos de calidad” dado que no son atributos de calidad.
6. Incluir al cerrar una iteración una actividad que tenga por objetivo evaluar la aplicabilidad de la forma de trabajo definida, así como también, procurar identificar aspectos de la forma de trabajo que difieran con los definidos inicialmente.
7. Evaluar si el porcentaje de esfuerzo dedicado a actividades de gestión en el proyecto es adecuado para el tamaño del grupo. Sería bueno que se identifique en la presentación el período comprendido en los datos detallados.
SUGERENCIAS 1. Se recomienda definir los criterios a utilizar para seleccionar tecnologías para el proyecto y validarlas con
el cliente. De esta forma se puede reducir el tiempo requerido para llegar a un acuerdo sobre las decisiones tomadas.
GRUPO: Swing Improver FECHA: 07/09/2005 EVALUADORES: AA, MS NOTA: Es importante que el grupo recuerde que este es un instrumento para ayudar al grupo a analizar, entender y mejorar su forma de trabajo; y que es el resultado de una instancia breve de evaluación. Por esta razón es recomendable analizar y evaluar la pertinencia de las observaciones aquí registradas. Si hubiese dudas sobre su contenido es importante que el grupo contacte a los evaluadores con el fin de clarificar aquellos aspectos poco claros. PUNTOS FUERTES 1. Definición de XP e investigación de la metodología para poder utilizarla en el proyecto. Muestran
evidencias de aplicación y conocimiento de la metodología. 2. Satisfacción del cliente con el proyecto y los elementos vistos hasta el momento. 3. Definición de historias del usuario, validación y priorización por parte del cliente de las mismas. 4. Realización de prototipos tecnológicos (Spikes) para los aspectos más complejos de la arquitectura. OPORTUNIDADES DE MEJORA 1. Organización de la presentación: a. Revisar el orden de los temas para asegurar la comprensión de los mismos por parte de los revisores. b. Priorizar la información a presentar en las ppts para evitar sobrecargarlas. c. Presentar a los integrantes del grupo al comenzar la presentación. 2. Revisar las prácticas utilizadas para conocer el problema y especificar requerimientos complementando
la distancia que existe con el cliente especificador de forma de asegurar que se cuenta con una visión completa del problema. Por ejemplo:
a. Prototipos en papel. b. Filmación a golfistas. c. Mostrar prototipos e interacción con otros golfistas. 3. Avanzar en la definición de la estrategia de pruebas de usuarios finales y la ejecución de estas. Asegurar
que se cuenta con mecanismos para obtener retroalimentación de los clientes una vez que puedan utilizar el producto.
4. Evaluar el impacto de los requerimientos 3D en el alcance del proyecto. 5. Medir el esfuerzo dedicado a actividades imprevistas y preverlo en la planificación. 6. Incluir en el cierre de la Iteración la evaluación de la forma de trabajo definida. 7. Analizar cómo tratar las historias y otras actividades en forma común para asignar recursos. Considerar
la unidad hora/hombre como unidad para medir el esfuerzo y clarificar la diferencia entre estimado y real. 8. Revisar la identificación de “Revisiones” como productos del área de SQA. Las revisiones deberían
identificarse como Actividades de SQA y no como productos.
239
GRUPO: Conquest FECHA: 13/12/2005 EVALUADORES: AA, LS NOTA: Es importante que el grupo recuerde que este es un instrumento para ayudar al grupo a analizar, entender y mejorar su forma de trabajo; y que es el resultado de una instancia breve de evaluación. Por esta razón es recomendable analizar y evaluar la pertinencia de las observaciones aquí registradas. Si hubiese dudas sobre su contenido es importante que el grupo contacte a los evaluadores con el fin de clarificar aquellos aspectos poco claros. PUNTOS FUERTES 1. Proceso seguido para la definición de requisitos y arquitectura del juego y resultado obtenido. 2. Se evidencia una buena planificación y seguimiento del proyecto, organizando el trabajo en iteraciones
claramente definidas que han permitido conocer en todo momento el estado del proyecto con respecto a los objetivos trazados.
3. Definición de un proceso de trabajo a partir de diversas fuentes consultadas. 4. Estrategia de SQA implementada y planificada. OPORTUNIDADES DE MEJORA 1. Presentación: a. Revisar el tamaño de la letra a presentar. SE recomienda usar fuentes de tamaño 24 puntos o superior. b. Presentar los procesos seguidos en IR y en SQA. c. Incluir una introducción en la que se comente quién es el cliente y en qué marco se ha desarrollado el
proyecto. d. Incluir conclusiones sobre el proyecto (cumplimiento de objetivos y lecciones aprendidas). 2. Incluir la justificación de las principales decisiones de diseño: a. Elección de las tecnologías. b. Relación entre los atributos de calidad y la arquitectura. c. Estrategia de desarrollo elegida (por qué las iteraciones se hicieron en ese orden). 3. Profundizar en la definición del requisito “jugabilidad” para este juego. 4. Incluir en la presentación la estrategia a seguir para absorber el atraso generado en las iteraciones 2 y 3.
A su vez, sería bueno incluir el análisis de los riesgos más importantes del proyecto bajo este título. 5. Revisar las métricas presentadas en SQA: a. Algunas de ellas sería más adecuado presentarlas dentro del capítulo de Gerencia del proyecto (nro. de
requisitos implementados – alcance). b. La medición de COQ no debería incluir los costos de desarrollo. SUGERENCIAS Revisar el contenido previsto para la Iteración 4 y evaluar dividir esta iteración en iteraciones más pequeñas, de forma de poder adelantar lo más posible las etapas de pruebas, tanto alfa como beta. GRUPO: NetDealer FECHA: 12/12/2005 EVALUADORES: LC, AA NOTA: Es importante que el grupo recuerde que este es un instrumento para ayudar al grupo a analizar, entender y mejorar su forma de trabajo; y que es el resultado de una instancia breve de evaluación. Por esta razón es recomendable analizar y evaluar la pertinencia de las observaciones aquí registradas. Si hubiese dudas sobre su contenido es importante que el grupo contacte a los evaluadores con el fin de clarificar aquellos aspectos poco claros. PUNTOS FUERTES 1. El equipo se presenta muy cohesivo y seguro con la solución presentada. 2. El equipo lleva un registro de horas el cual le permite analizar los desvíos. 3. También destaca el hecho de llevar un registro de reuniones, tanto internas como con el cliente. 4. El equipo decidió utilizar un beta test “escalable”, no solo para identificar problemas del juego, sino
también para relevar el interés de los jugadores por otros juegos. 5. El equipo realiza un análisis causal periódico para evaluar el curso del proyecto y las acciones a seguir. 6. Se explicó muy claramente la decisión que se tomó al utilizar la Gestión de Proyectos dirigida por la
arquitectura. OPORTUNIDADES DE MEJORA 1. Explicar más en detalle el tratamiento que se le da a los riegos, sobre todo los más importantes. 2. Brindar una visión del cronograma del proyecto (previsto vs actual) para explicar retrasos, medidas que
se tomaron, etc. 3. Definir un con más precisión el atributo “Jugabilidad” como parte de la definición de la aplicación cliente.
Dentro de este atributo se recomienda dividir su especificación en: a. Enseñar al jugador (brindar información sobre las reglas básicas, incorporar alguna forma de ayuda
interactiva para entender las acciones, etc.) b. Entrada y salida (input y output del juego, más de un botón para una misma acción, etc.) c. Tiempos de respuesta deseables
240
d. Incorporar como sub atributo a la Usabilidad del juego. Explicar en la presentación que la aplicación cliente es una forma de evaluar la funcionalidad.
4. Brindar en la presentación un marco general de los requerimientos del juego. Detallar un poco más los requerimientos más importantes. Presentar alguna clasificación.
5. Definir alguna clasificación simple para los errores que se vayan encontrando en las actividades de testing, para luego priorizarlos y realizar correcciones sobre los más importantes (ej. Simple, medio y complejo)
6. Dentro del plan de SQA se sugiere agregar, en la sección de actividades registrales, los resultados del testing y quitar el registro de horas. Esto debería ir dentro de las actividades de gestión del proyecto.
7. Aclarar un poco más la ponderación de los casos de uso y mostrar algunos de los casos de uso más importantes.
8. Incorporar a la presentación mayor detalle sobre las decisiones más importantes al diseñar la arquitectura, incluyendo diagramas de arquitectura y diseño para clarificar la planificación y las actividades realizadas.
SUGERENCIAS 1. Tratar de definir la encuesta que se va a realizar y definir lo que se desea evaluar. a. Definir un número mínimo de juegos para luego habilitar la encuesta. Tratar de averiguar por qué la
gente dejó de jugar antes de realizar la encuesta. b. Realizar un ranking entre los jugadores y ofrecer alguna recompensa. c. Invitar a un mayor número de jugadores de la que se prevé realizar el beta test, ya que muchos de ellos
se van de vacaciones en los meses de enero y febrero. d. Al finalizar agregar una sección de sugerencias y comentarios. 2. Definir la documentación que se va a entregar, tanto para el cliente como para SF. a. Tratar de definir el índice de los documentos más importantes, para quién es el documento y para que
(objetivo) va a ser utilizado, etc. b. Planificar el tiempo para preparar la documentación en el cronograma (como referencia se toma al
menos 10 días para la preparación y 3 para la revisión del material). 3. Darle al cliente una lista de requerimientos para que la priorice y así clarificar cuáles son los
requerimientos que se deben realizar y cuales se pueden recortar. 4. También definir claramente con el cliente cuáles serán los entregables que se el brindarán para evitar
malos entendidos. 5. En el beta test tratar de elegir usuarios potenciales y representativos. GRUPO: SPACEWARS FECHA: 04/12/2006 EVALUADORES: Amalia Álvarez, Luis Calabria IMPORTANTE: Es importante que el grupo recuerde que este es un instrumento para ayudar al grupo a analizar, entender y mejorar su forma de trabajo; y que es el resultado de una instancia breve de evaluación. Por esta razón es recomendable analizar y evaluar la pertinencia de las observaciones aquí registradas. Si hubiese dudas sobre su contenido es importante que el grupo contacte a los evaluadores con el fin de clarificar aquellos aspectos poco claros. PUNTOS FUERTES
1. Se destaca la presentación de la demo del juego para aclarar ideas. 2. La forma de llevar adelante el trabajo y la organización del mismo. 3. Enfoque y desarrollo de las pruebas del producto. Lo bien organizado que se presentó el testing. 4. La presentación de alternativas a la arquitectura del sistema. 5. La forma de asignar el trabajo y el seguimiento del avance. 6. La política de respaldo y versionado.
OPORTUNIDADES DE MEJORA 1. Presentar una lista más detallada de los requerimientos más importantes del juego, explicando qué
requerimientos eran negociables y cuales no. 2. Presentar la estrategia de desarrollo que se utilizó, destacando cómo se divide el trabajo, cómo se
trabajaba en grupo equipo, cómo se hace un integración, cómo se testea, etc. 3. Explicar qué estrategia utilizaron para cumplir con cada sub atributo de la jugabilidad y cómo se llevó a
cabo finalmente. 4. Considerar los requerimientos de hardware como requerimientos mínimos o deseables y no como
requerimientos funcionales. 5. Explicar los criterios de selección de las distintas alternativas de arquitectura. 6. Presentar de forma más clara la planilla en la cual se asignan los requerimientos, explicando su uso. 7. Incorporar al atributo de calidad “mantenibilidad” y explicar la forma con la cual se logró llegar a esto, por
ejemplo, mediante el uso de estándares de programación. SUGERENCIAS
1. Indicar gráficamente el esfuerzo dedicado a cada rol en todo el proyecto, diferenciando por ejemplo, el esfuerzo para gestión, requerimientos y programación.
2. La distribución de las PPT debe es recomendable que reflejar la proporción de trabajo que le dedicaron
241
al desarrollo del tema, haciendo énfasis en este punto. 3. Dar una Profundizar en la explicación un poco más detallada de la tecnología DirectX y sus distintos
componentes (Direct Sound, Direct Play, etc.) para aclarar ideas. 4. Reducir la cantidad de ppt en la parte de gerencia, haciendo alguna agrupación de conceptos. 5. Presentar de manera más clara algunas de las gráficas de estimación de esfuerzo. 6. Definir los criterios para la solución de bugs durante las etapas de prueba. 7. En el caso de utilizar Mantis para el Beta Test, revisar bien que información será solicitada. 8. Presentar al final de la presentación una lista de lecciones aprendidas.
242
A3.2 Planilla de análisis de los reportes de revisión
En la tabla A3.1, las áreas para las cuales no se muestran sus sub-áreas (Construcción del software, Mantenimiento del software y Herramientas y Métodos) no se evalúan en las revisiones.
Análisis de frecuencia de "oportunidades de mejora" y de "sugerencias" a partir de los
Informes de Revisión
Coop
Bancaria
Lotario
‐ DVG
GDSToo
l
ArqNet
Métricas
Parix
Fram
eworkPPC
Mais
Acuario
SwingImprover
Conq
uest
NetDealer
Spacew
ars
TotalesAreas de conocimiento del SWBOK
Requisitos Software 131. Fundamentos
2. Proceso x 13. Educción x x 24. Análisis x x x x x x x 7
5. Especificación x x x 36. Validación
7. Consideraciones prácticasDiseño del software 2
1. Fundamentos2. Aspectos clave
3. Arquitectura y estructura software x x 24. Análisis y evaluación de la calidad
5. Notaciones de diseño6. Métodos y estrategias de diseño
Construcción del software ‐‐‐Prueba del software 3
1. Fundamentos2. Niveles de prueba x x 2
3. Técnicas de prueba4. Mediciones relativas a las pruebas
5. Proceso de pruebas x 1Gestión de Ingenieria Software 16
1. Iniciación y definición de alcance x 12. Planificación del proyecto x x x x x x x x x 9
3. Ejecución del proyecto x 14. Revisión y evaluación x 1
5. Cierre6. Mediciones x x x x 4
Proceso de Ingeniería Software 41. Implementación y cambio del proceso
2. Definición del proceso x x 23. Evaluación
4. Medición de productos y del proceso x x 2Mantenimiento del Software ‐‐‐Gestión de Configuración 3
1. Gestión del proceso de SCM x x 22. Identificación de la configuración
3. Control de la configuración x 14. Status de la configuración
5. Auditoría de la configuración6. Gestión y entrega de "releases"
Herramientas y Métodos ‐‐‐Calidad del software 6
1. Fundamentos x x 22. Proceso de gestión de la calidad x x x x 4
3. Consideraciones prácticas
Tabla A3.1: Planilla de análisis de reportes de revisión
243
A3.3 Descripción de los proyectos seleccionados para el estudio Software de gestión para COODESOR (Cooperativa Odontológica de Soriano) Integrantes: Alejandro Romero, Yairo Vettorello, Federico Gordillo, Daniel Nicolich Tutor: Leonardo Scafarelli Descripción del Cliente La cooperativa COODESOR es la cooperativa de asistencia odontológica mutual del departamento de Soriano, la cual está integrada por catorce odontólogos que ofrecen su asistencia profesional a una importante masa de asociados de todo el departamento de Soriano. La cooperativa cuenta con una sede central en la ciudad de Mercedes que centraliza toda la gestión administrativa, logística y comercial de la empresa, y sus filiales son los propios consultorios particulares de los odontólogos, los cuales se encuentran dispersos en varios puntos geográficos, tanto de la ciudad de Mercedes como de localidades cercanas. En la actualidad el cliente cuenta con herramientas informáticas según el siguiente detalle: LOCAL CENTRAL - Sistema central de gestión administrativa de la cooperativa Este sistema es una herramienta que fue
desarrollada en Clipper hace más de 10 años y la misma se ha vuelto obsoleta ante las necesidades cambiantes del mercado actual.
La misma provee los siguientes servicios entre otros: o Gestión administrativa de los abonados. o Cuentas corrientes de los abonados. o Gestión de stocks y venta de insumos odontológicos para abonados y para los cooperativistas. o Liquidación a cooperativistas por trabajos realizados. FILIALES (consultorios particulares) - Software particular en cada filial Actualmente solo algunos de los odontólogos cooperativistas adquirieron un software propietario (totalmente independiente del sistema central) el cual supuestamente gestionaría y proveería las siguientes funcionalidades entre otras: o Gestión de pacientes. o Registro de consultas. o Gestión de historias clínicas. o Agenda. o Gestión de planes de tratamiento. Lamentablemente el producto que adquirieron no satisfizo sus expectativas ni brinda utilidad alguna a sus actividades, debido a que la herramienta les resulta muy difícil de utilizar, no es intuitivo en su manejo, no ofrece conectividad a una base de datos centralizada, y no recibieron capacitación alguna para el uso de dicha herramienta. Además de los aspectos planteados anteriormente, una de las mayores problemáticas a las que se enfrenta la cooperativa en la actualidad, es la imposibilidad de acceder a un único registro de historias clínicas de los abonados ya que estos pueden ser atendidos por el odontólogo de guardia, que puede no coincidir con el profesional que está llevando a cabo su plan de tratamiento. Esto ocasiona que el profesional de guardia carezca de la información histórica necesaria para enfocar la asistencia de acuerdo al tratamiento general que está teniendo el paciente, y por consiguiente no pudiendo registrar oportunamente la asistencia brindada. Descripción del Proyecto El proyecto en su totalidad consiste en el análisis, diseño y desarrollo de una herramienta informática que permita la gestión general de la cooperativa, integrando las funcionalidades que brindan las herramientas informáticas actuales e incorporando nuevas funcionalidades derivadas de la conectividad entre el sistema central y los sistemas de las filiales. En principio, no se plantea esto como una solución de reingeniería de los sistemas actuales, sino que se plantea la generación de una nueva herramienta en su totalidad que integre todos los aspectos antes mencionados. En una primera aproximación al proyecto, el mismo se podría plantear como dos sistemas interconectados entre si: el sistema de administración central de la cooperativa y el sistema particular que dispondrá cada odontólogo en su consultorio. Ambos sistemas compartirán información que alimentará un registro único centralizado, logrando una mayor integridad y accesibilidad a los datos por todos los usuarios del sistema. Sistema Central El sistema central de la cooperativa brindará entre otras las siguientes funcionalidades: - Registro único de abonados a la cooperativa. - Cuenta corriente de los abonados con gestión del pago de cuotas mutuales, tratamientos específicos
244
recibidos, etc. - Registro único de historias clínicas de los abonados. - Gestión de stocks y venta de insumos odontológicos para abonados y para los cooperativistas. - Gestión contable general de la cooperativa. - Liquidación a cooperativistas por trabajos realizados e información de saldos de pago. La idea de este sistema es que unifique los datos de toda la cooperativa y permita la accesibilidad de los odontólogos a un único registro. Dada la complejidad de este sistema, se plantea la división del mismo en módulos independientes y acoplables que permitan un desarrollo incremental, subdividiendo inicialmente al sistema en los siguientes módulos: - Módulo de gestión de abonados (datos de abonado, convenios, cuentas corrientes, etc.) - Módulo de gestión odontológica (historias clínicas, tratamientos, etc.) - Módulo de gestión administrativa (contabilidad general, aranceles, liquidaciones, stocks, etc.) Sistemas en filiales Los sistemas en las filiales odontológicas (consultorios particulares de los odontólogos) serán sistemas independientes que pueden consultar los registros de los abonados a la cooperativa en el sistema central, así como también consultar y modificar datos de los tratamientos, historias clínicas y trabajos realizados a los abonados por cada odontólogo. Las funcionalidades que proveerán estos sistemas entre otras serán las siguientes: - Consultas al registro único de abonados a la cooperativa. - Registro de las consultas realizadas y los trabajos llevados a cabo en el paciente. - Consultas y modificaciones a los planes de tratamiento de los abonados. - Agenda de consultas. - Consulta y registro de historias clínicas. - Consulta de aranceles. Al igual que en el sistema central, se plantea la modularización de este sistema de la siguiente manera: - Módulo de gestión de abonados (consulta de abonados al registro único, cuentas corrientes, etc.) - Módulo de Historias clínicas (consulta y modificación de historias clínicas, registro de consultas, etc.) - Agenda (Agenda y reserva de consultas, etc.) Eventualmente se verá la posibilidad de incorporar a este sistema la gestión de los pacientes particulares de cada odontólogo. Desarrollo del proyecto Metodología En una primera aproximación al problema, vemos la posibilidad de desarrollar este sistema utilizando la metodología incremental por varias razones: - El desarrollo de módulos sucesivos permitirá ir entregando los mismos al cliente y obtener un “feedback”
de la aceptación del mismo por parte del cliente. - Dado el poco acercamiento que tienen los usuarios involucrados con este tipo de herramientas, el ir
anexando nuevas funcionalidades a la herramienta paulatinamente permitirá un mayor grado de asimilación de la tecnología en sus ámbitos de trabajo de modo gradual, minimizando el impacto de la incorporación de la nueva herramienta.
- Dado el porte del proyecto general y los tiempos acotados del proyecto académico esta metodología permitirá suministrar al cliente parte de lo acordado en completa funcionalidad, sin perjuicio del desarrollo posterior del resto de la herramienta.
Tecnología La intención en primer instancia es la de desarrollar este proyecto sobre plataforma de programación .NET. La principal razón de esto es que siendo alumnos del plan 96 de la universidad, no hemos tenido la oportunidad de enfrentarnos a estas nuevas herramientas tan difundidas en el mercado laboral actual, y consideramos esta una excelente oportunidad para investigar e incursionar en la misma. Comentarios Resultando del interés planteado por el cliente y en virtud de que es nuestra intención poder mejorar y comercializar el producto final de esta experiencia, queremos solicitar que los derechos comerciales del mismo permanezcan en nuestras personas aceptando las obligaciones y derechos que esto implica.
245
Portal de Inversiones - InvPortal Integrantes: Alejandra Pera, Alicia Pino, Alicia Pereira Tutor: Mariana Lasarte Cliente Unidad de Promoción de la Inversión y Desarrollo del Sector Privado - Ministerio de Economía y Finanzas Descripción Dentro del Plan de Estrategia 2005 – 2010 del Gobierno Nacional, y en lo vinculado al Clima de Negocios y Competitividad del país, se creó la Unidad de Promoción de la Inversión y Desarrollo del Sector en el Sector Privado dependiente del Ministerio de Economía y Finanzas (MEF), presentada en diciembre de 2006, con la misión de asesorar, proponer, implementar y facilitar la coordinación de políticas y acciones que mejoren el clima de negocios y favorezcan el desarrollo del sector privado y la inversión productiva. Con el compromiso de desarrollar, como política de calidad, procesos que promuevan la mejora continua en un marco de transparencia con la prioridad de brindar información calificada a inversores y suministrar información de soporte, presentó en un punto de su agenda la creación de un sitio Web en dos fases (la primera de carácter informativo y de consolidación de la información de inversores, y la segunda, con carácter transaccional y de interacción con el inversor), surgiendo la propuesta de desarrollar el InvPortal: Sitio Web para la Oficina de Desarrollo Sector Privado – MEF. Con estos antecedentes, el InvPortal como proyecto es propuesto por el Ing. Bruno Delgado, encargado de la Oficina Desarrollo del Sector Privado, a la Universidad ORT, concretamente a ORT Software Factory (Laboratorio de ingeniería Software). El objetivo del InvPortal fue desarrollar un sitio Web, cuyas características derivaron del trabajo de investigación del estado de la práctica y del arte, así como de un trabajo de Ingeniería de Requerimientos adecuado al proyecto. Se decidió “dividir” al proyecto en dos grandes etapas: una primera etapa en la cual las tareas más importantes y destacadas fueran la investigación, capacitación y requerimientos, y una segunda donde lo primordial fuera el análisis, diseño e implementación del Sitio. Sin perjuicio de esta división, las tareas se fueron realizando a lo largo de todo el proyecto con mayor o menor dedicación de tiempo, según las necesidades, a veces superponiéndose y en todo momento complementándose unas con otras. Al terminar la primera etapa (sobre todo en lo referente a la investigación), se elaboró el producto de la investigación (conclusiones) y un conocimiento cabal de las funcionalidades y características que tendría luego el producto final (el sitio Web). En la segunda etapa se comenzó a avanzar en la implementación del Sitio, codificando, implementando las diferentes funcionalidades, así como también comenzó a cobrar importancia la tarea de “testing”. En esta segunda etapa, cada integrante tuvo a su cargo diferentes funcionalidades principales que fue implementando, codificando y testeando, para luego unificarlas, para ser mostradas al cliente para su aprobación o desaprobación. Cabe aclarar que el cliente acompañó en casi todo el desarrollo del proyecto (excepto en un corto período que estuvo de viaje), aportando ideas, conceptos, sugerencias para la investigación y validando o solicitando cambios en el producto en esa segunda etapa, que culminó con la entrega del sitio Web plenamente funcional. El producto final no solo cumplió con las expectativas y requerimientos planteados por el cliente, al igual que con las del equipo de proyecto, sino que además en algunos casos fueron superadas debido al agregado de algunas y características que le aportan al producto un valor agregado importante. Sistema de Gestión de Acreditaciones – GESA Integrantes: Carlos Geribón, Rodrigo Robaina, Ricardo Leite Tutor: Amalia Álvarez Cliente Organismo Uruguayo de Acreditación Descripción El sistema GESA fue realizado como proyecto de grado para la carrera Licenciatura en Análisis de Sistemas de Información de la Facultad de Ingeniería de la Universidad ORT Uruguay, dentro del marco académico del Laboratorio de Ingeniería de Software. El proyecto consta de un cliente externo, que es el Organismo Uruguayo de Acreditación (OUA). El proyecto surge a partir de la necesidad que el OUA tiene de automatizar la gestión del proceso de acreditación para mejorar su eficiencia y la satisfacción de sus clientes. El mismo consiste en la creación de una solución de software que asista la gestión del proceso de acreditación. Dicho proceso se divide en dos subprocesos: a) Tramitación de la solicitud de acreditación: ésta comienza cuando un organismo que desea ser acreditado se pone en contacto con el OUA y finaliza con la obtención de la acreditación por parte de este organismo. b) Seguimiento de acreditaciones.
246
Con ello se busca: 1. Facilitar a las autoridades del OUA la ejecución y seguimiento del proceso de acreditación. 2. Facilitar al personal del OUA la comunicación y envío de documentos a las partes interesadas. 3. Facilitar a los evaluadores el acceso a la documentación de la organización en proceso de acreditación. 4. Brindar visibilidad a los organismos en proceso de certificación sobre el avance de su solicitud. 5. Facilitar la difusión de organismos acreditados a todas las partes interesadas. En cuanto a los usuarios destacamos a todos los involucrados en el proceso de acreditación, funcionarios del OUA, el equipo evaluador (evaluadores) y el organismo a ser acreditado (cliente). Las tecnologías utilizadas fueron PHP5 junto al framework CakePHP con un servidor Apache y como base de datos se utilizó MySQL. Seguimiento y control de proyectos de inversión - SCPI Integrantes: Sergio Gambini, Andrés Lapachian, Matías Núñez, Federico Fontes, Felipe Herrera Tutor: Mariel Feder Cliente Unidad de Desarrollo del Sector Privado – Ministerio de Economía y Finanzas Descripción La Unidad de Desarrollo del Sector Privado es una oficina de reciente creación, dependiente del Ministerio de Economía y Finanzas que tiene como misión asesorar, proponer, implementar y facilitar la coordinación de políticas y acciones que mejoren el clima de negocios y favorezcan el desarrollo del sector privado y la inversión productiva, aspirando a convertirse en un referente institucional para la atención, promoción y desarrollo del sector privado. El proyecto consiste en implementar un sistema de seguimiento y control centralizado de los proyectos de inversores privados, pertenecientes al portafolio de inversiones de la Unidad de Desarrollo de Sector Privado. El proyecto incluye el relevamiento de requerimientos, investigación de herramientas, diseño e implementación de la solución. El objetivo central es optimizar a nivel electrónico el trabajo de seguimiento y control de proyectos para el otorgamiento de beneficios y su control posterior, mejorando el acceso a la información correspondiente a los distintos actores del proceso de inversión, ya que en la actualidad este proceso es todo mediante “papel” y no existen de conocimiento adecuado para la gestión del estado y/o ubicación de las solicitudes de beneficios para proyectos de inversión. Las principales funcionalidades del sistema son: representar el flujo de los expedientes de inversión a través de los distintos procesos de la oficina, llevar el seguimiento del estado de cada trámite de inversión (solicitud de beneficios de fiscales del proyecto presentado), así como quienes son el/los responsables de cada actividad asociada al estado, permitir la calificación los proyectos de acuerdo a un conjunto de parámetros variables como empleo, producción limpia, IDH (índice de desarrollo humano) monto de la inversión, y otros. El sistema también permite a los Inversores la consulta a través de la página Web de la Oficina del estado de sus proyectos.
247
A3.4 Guías de reflexión para Ingeniería de Requisitos, completadas por los ingenieros de requisitos de los grupos de proyectos participantes Proyecto: COODESOR Preguntas
Pregunta 1 Req.Eli.An.01
¿Qué aspectos considera usted que es importante que se tomen en cuenta a la hora de planificar una entrevista?
Respuesta Creo que lo más importante en mi caso fueron tres aspectos: La coordinación específica de la entrevista. Esto fue fundamental para dejar bien establecida la inversión de tiempo que supone la entrevista tanto para el entrevistado como para nosotros y denotar la seriedad de la misma. Fue muy bueno generar una lista de posibles preguntas o temas que debíamos abordar en la entrevista para poder hacer una especie de checklist de los aspectos que teníamos que relevar. Informar previamente al entrevistado sobre la temática y el contenido de la entrevista para que el entrevistado pueda llegar a la entrevista con un esquema claro de lo que se va a tratar.
Tiempo Dedicado 10 minutos
Pregunta 2 Req.Eli.Ap.01
Una buena comunicación con el usuario es clave para lograr recolectar información. Exponga los problemas más relevantes que ha tenido para establecer una comunicación efectiva y cómo los ha superado.
Respuesta Creo que el principal problema que tuvimos a nivel de comunicación fue el no tener una instancia de conocimiento a la contraparte del cliente en nuestra entrevista. Cuando llegamos a la entrevista la comunicación no fue efectiva en una primera instancia ya que no conocíamos personalmente a los entrevistados y tuvimos que adecuar nuestro lenguaje y nuestra actitud inquisitiva a una postura más coloquial llevando la entrevista a una aparentemente sencilla conversación sobre las necesidades del cliente. Posteriormente se llegó a un grado de confianza con el cliente que permitió una comunicación más efectiva y dinámica.
Tiempo Dedicado 15 minutos
Pregunta 3 Req.Eli.Ev.01
¿Qué recomendaría usted a un ingeniero de requerimiento que se enfrenta a un usuario con necesidades poco claras?
Respuesta Recomiendo que la investigación comience a bajo nivel, indagando en las tareas más frecuentes que realiza el usuario o las tareas que se llevan a cabo en el entorno del cliente. También creo que es bueno analizar y realizar un esquema de los procesos que realiza el usuario o el cliente en general para hacerle esquematizar de alguna forma las tareas que realiza el cliente y lograr definir claramente sus necesidades y sus objetivos. Si bien esto se enmarca en una actividad de “consultoría” hacia el cliente esto resulta muy útil a la hora de definir claramente las características del sistema a desarrollar.
Tiempo Dedicado 10 minutos
Pregunta 4 Req.Eli.Si.01
Relate, en no menos de cuatro o cinco líneas, aquella experiencia de entrevista que usted considera que fue la más exitosa y que volvería a repetir.
Respuesta Creo que la entrevista más exitosa fue la sostenida con el presidente de la cooperativa (responsable de la misma). En ella no sólo logré obtener más información sobre las necesidades y expectativas del cliente sobre el producto final, sino que logré un grado importante del cliente en el proyecto y en las características del mismo. Aparte de esto se generó una conciencia en el cliente de lo necesario que resulta para la empresa la incorporación de una nueva herramienta informática, haciéndole ver la potencialidad del producto no solo en esta primer etapa sino en las etapas sucesivas.
Tiempo Dedicado 10 minutos
248
Pregunta 5 Req.An.An.01
En base a su experiencia, ¿qué dificultades encontró para distinguir los requerimientos funcionales de los no funcionales?
Respuesta Básicamente la dificultad partió del poco conocimiento que tenía de la diferencia entre los requerimientos funcionales y no funcionales y lo que involucraba cada uno de estos conceptos.
Tiempo Dedicado 5 minutos
Pregunta 6 Req.An.Ev.01
¿Cómo logró superar las dificultades anteriormente expresadas?
Respuesta Varias instancias de aprendizaje y de consulta a los tutores permitieron definir claramente los conceptos que abarcaban los conceptos anteriores permitiendo diferenciarlos con más claridad. También un análisis exhaustivo de las entrevistas con el cliente y de las características definidas para el producto permitieron clasificar los requerimientos más racionalmente.
Tiempo Dedicado 5 minutos
Pregunta 7 Req.Prep.Si.01
Los miembros del proyecto que se dedican a la ingeniería de requerimiento necesitan un entrenamiento inicial para prepararse para la tarea. ¿De qué manera planearía usted este entrenamiento?
Respuesta Creo que sería bueno hacer un taller entre los participantes de IR aplicando técnicas de análisis de casos y “role playing” para experimentar en un entorno académico los diferentes aspectos de la IR. Así mismo el aporte de cada uno de los participantes puede contribuir a esclarecer las tareas de un IR.
Tiempo Dedicado 5 minutos
Pegunta 8 Req.Prep.Ev.01
A su juicio, ¿qué habilidades personales facilitarían las tareas del ingeniero de requerimientos?
Respuesta Creo que serían las siguientes: Saber escuchar. Facilidad de comunicación adecuando la misma a las características del cliente. Poder lograr empatía con el cliente Nunca está de más una buena presencia que demuestre seriedad en el emprendimiento.
Tiempo Dedicado 5 minutos
Pegunta 9 Req..Ev.01
De las actividades relativas a IR que llevó a cabo en el presente proyecto, ¿cuales considera que realizó adecuadamente y cuáles considera que deberá mejorar la próxima vez?
Respuesta En general creo que en su conjunto las actividades se desarrollaron adecuadamente considerando la inexperiencia en este campo. De cualquier manera creo que lo que mejoraría para una próxima oportunidad sería la incorporación de una instancia inicial de conocimiento del cliente y la contraparte en el proceso de entrevistas. Sin esta instancia no se pudo prever las características de esta primera entrevista de relevamiento.
Tiempo Dedicado 5 minutos
Espacio Libre En nuestro caso nos sucedió que planificamos la etapa de relevamiento y entrevistas en una única instancia. Esto se debe a que el cliente se encuentra en la ciudad de Mercedes y debíamos optimizar el encuentro con el cliente. Para esto habíamos realizado formularios de relevamiento y guías de entrevista que en el momento de llevarlas a cabo no fueron de mucha ayuda – sobre todo los formularios – ya que los mismos se habían elaborado considerando una empresa de mayores dimensiones, con más usuarios del sistema actual e instalaciones de mayor envergadura, pero cuando llegamos a hacer el relevamiento vimos que el cliente contaba sólo con dos usuarios del sistema y dos PCs. Sin duda esto nos hizo ver que la planificación que habíamos realizado no fue del todo efectiva y en cierta forma resultó en un mal aprovechamiento del tiempo.
Tiempo Dedicado 10 minutos.
249
Proyecto GESA Preguntas
Pregunta 1 Req.Eli.An.01
¿Qué aspectos considera usted que es importante que se tomen en cuenta a la hora de planificar una entrevista?
Respuesta Primero deberíamos definir las metas y el alcance de la entrevista. Después tendríamos que realizar una lista de preguntas o una guía para la entrevista la cual será diferente según la persona que vayamos a entrevistar. Antes de seleccionar la persona a la cuál vamos a entrevistar, sería aconsejable hablar antes con algún superior (si éste es el caso) de ésta, para asegurarnos que estamos entrevistando a la persona correcta. Además probablemente la persona entrevistada colabore más, si sabe que su superior es consiente de la entrevista (creo que así evitaríamos que el entrevistado piense que la entrevista es una perdida de tiempo). Quizás esto no aporte mucho dada su obviedad, pero creo que es bastante importante como para no comentarlo (por lo menos a nosotros no sirvió de sobremanera), es fundamental la familiarización con la terminología que utiliza el entrevistado, así como el conocimiento del tema que se va a tratar en la entrevista. Esto hace que la entrevista sea mucho más jugosa y fluida. Cuando conocemos el tema del que estamos hablando, sabemos si el Cliente se está “yendo por las ramas” y así podemos ir guiando la entrevista. En las primeras entrevistas notamos que era el Cliente el que la guiaba, esto se debió a que nosotros recién nos estábamos familiarizando con el proceso de acreditación. A medida que ha pasado el tiempo, nos hemos familiarizado mas con el proceso y esto ha llevado a que las entrevistas sean más productivas. Otro punto importante es cómo vamos a registrar lo conversado en la entrevista. En nuestro caso decidimos no sacar apuntes durante la entrevista debido al reducido número de integrantes y porque nuestro Cliente no planteó objeción alguna cuando le propusimos grabar las entrevistas; entonces luego que finalizaba cada entrevista escuchábamos la cinta y realizábamos el acta de la reunión y el análisis de la información relevada. Si bien la grabación registra lo que se conversó es altamente recomendable que el acta de la reunión se realice lo más pronto posible, después pasa el tiempo y podemos perder “pequeños” detalles que al final son grandes requerimientos del Sistema. Bueno, creo que no tengo nada más que aportar, no hay que olvidar establecer un tiempo suficiente para cubrir todos los temas a tratar en la reunión y agradecerle siempre el tiempo dedicado a nuestro Cliente. También está bueno y sirve de mucho mandarle al Cliente las preguntas o los temas que se van a tratar en la reunión antes por mail, para que éste se prepare en caso de que sea necesario. Otra de las cosas que he aprendido en el transcurso de las entrevistas, es a formular preguntas correctas (desde el punto de vista de lo que deseo relevar).
Tiempo Dedicado 20 minutos.
Pregunta 2 Req.Eli.Ap.01
Una buena comunicación con el usuario es clave para lograr recolectar información. Exponga los problemas más relevantes que ha tenido para establecer una comunicación efectiva y cómo los ha superado.
Respuesta Bueno, creo que en la pregunta anterior mencioné algo de esto. Como Uds. plantean la comunicación con el usuario es clave, por eso la importancia de conocer el tema que vamos a tratar en la reunión y la terminología que utiliza el usuario.
Tiempo Dedicado 3 minutos
Pregunta 3 Req.Eli.Ev.01
¿Qué recomendaría usted a un ingeniero de requerimiento que se enfrenta a un usuario con necesidades poco claras?
Respuesta Un punto fundamental en este caso y que a menudo se presenta, es que muchas veces el usuario dice saber lo que quiere y somos nosotros quienes debemos establecer que es lo que realmente el usuario necesita. Lo que el Cliente quiere, a veces no es lo que realmente necesita y por eso es responsabilidad del Ingeniero de requerimientos explicarle y demostrarle sus verdaderas necesidades. Para esto, pienso que lo mejor es profundizar en el tema a tratar, analizar todo en detalle para sacar conclusiones y obtener así las verdaderas necesidades. Evidentemente el aporte del Cliente es muy valioso ya que nosotros no somos expertos en su área, por eso creo que en este tipo de casos hay que trabajar conjuntamente y demostrarle sus necesidades. Nuestro planteamiento debe ser de la mejor manera posible para evitar roces con el Cliente, no podemos olvidar que él es el que conoce el área y eso puede llevar a que piense que somos nosotros los equivocados.
Tiempo Dedicado 5 minutos.
250
Pregunta 4 Req.Eli.Si.01
Relate, en no menos de cuatro o cinco líneas, aquella experiencia de entrevista que usted considera que fue la más exitosa y que volvería a repetir.
Respuesta En realidad me cuesta elegir una entrevista y plantearla como la más exitosa, porque en todas pudimos alcanzar nuestros objetivos. Así que la que relato a continuación, no se destaca demasiado sobre el resto. En la cuarta entrevista (como en el resto) le mandamos por mail a nuestro Cliente la lista de temas que íbamos a tratar así como las preguntas que le íbamos a realizar. Cuando llegó el momento de la entrevista, nuestro Cliente ya había contestado las preguntas y se había informado más acerca de los temas que creyó conveniente para poder de esta manera colaborar más con nosotros. Todo esto llevó a que la entrevista durara no mas de 60 minutos y que nos volviéramos con todas las dudas saciadas.
Tiempo Dedicado 10 minutos.
Pregunta 5 Req.An.An.01
En base a su experiencia, ¿qué dificultades encontró para distinguir los requerimientos funcionales de los no funcionales?
Respuesta A decir verdad no tuve dificultades para distinguirlos porque tenía claro lo que se entiende por requerimientos funcionales, pero con respecto a los requerimientos no funcionales tuve que leer acerca de ellos porque no se me ocurrían muchos.
Tiempo Dedicado 3 minutos.
Pregunta 6 Req.An.Ev.01
¿Cómo logró superar las dificultades anteriormente expresadas?
Respuesta Investigando acerca de los mismos, en Internet y en diapositivas de semestres anteriores.
Tiempo Dedicado 2 minutos.
Pregunta 7 Req.Prep.Si.01
Los miembros del proyecto que se dedican a la ingeniería de requerimiento necesitan un entrenamiento inicial para prepararse para la tarea. ¿De qué manera planearía usted este entrenamiento?
Respuesta Bueno, creo que esto depende un poco de la experiencia de cada uno. En mi caso, no tenía nada de experiencia práctica y creo que la capacitación de Ingeniería de Requerimientos me sirvió para recordar algo del teórico que aprendí en semestres anteriores, por ejemplo en las materias: Diseño de Aplicaciones 1 e Ingeniería de Software. La ingeniería de requerimientos es vital en el proyecto y pienso que su capacitación es muy importante, pero hay todo un tema tiempo del que no nos podemos olvidar. Creo que a esta altura de la carrera, todos somos responsables y sabemos que tenemos que ampliar todo lo que se nos menciona y enseñan, así que supongo que con la capacitación inicial más lo aprendido en semestres anteriores da para manejarnos. Una buena ayuda a todo esto, sería que en los semestres anteriores se dejara bien claro la importancia de esto y el uso que se debe hacer del mismo en el proyecto final. Evidentemente si se puede hacer un curso de Ingeniería de Requerimientos bienvenido será.
Tiempo Dedicado 10 minutos.
Pegunta 8 Req.Prep.Ev.01
A su juicio, ¿qué habilidades personales facilitarían las tareas del ingeniero de requerimientos?
Respuesta Creo que mas que nada es importantísimo el tema comunicación. El Ingeniero de Requerimientos además de tener que ser responsable y todo lo demás, debe ser una persona bastante abierta, y que no tenga problemas de diálogo, creo que ésta es la clave.
Tiempo Dedicado 3 minutos.
251
Pegunta 9 Req..Ev.01
De las actividades relativas a IR que llevó a cabo en el presente proyecto, ¿cuales considera que realizó adecuadamente y cuáles considera que deberá mejorar la próxima vez?
Respuesta Tanto la planificación de las entrevistas como el relevamiento y la creación del ESRE creo que fue lo mas fuerte. Lo que debo mejorar para las próximas entrevistas es el tiempo, la mayoría de las veces por ser cortés con el Cliente lo dejo explayarse en cosas poco relevantes para el proyecto y esto lleva a que la reunión se extienda mas de lo planificado sin agregarle nada productivo a la entrevista. Supongo que esto se debe a la falta de experiencia en entrevistas, digamos que siento como que en ese tipo de casos no tengo la “cintura” necesaria de decirle al Cliente que lo que está diciendo no sirve de nada, cortarlo y arrancar con la siguiente pregunta.
Tiempo Dedicado 5 minutos.
Espacio Libre Me parece que éste es el momento justo para realizar esta actividad, ya que de realizarse una vez finalizado el proyecto, creo que nos olvidaríamos de detalles que pueden ser muy importantes. El responder a estas preguntas, me hizo recordar o plantearme cosas que quizás las creía tener solucionadas, y que a decir verdad, se me habían “olvidado” de tenerlas en cuenta (por ejemplo: Pensar cómo puedo hacer para, de una manera cortes, hacerle entender al Cliente que lo que esta diciendo no sirve de nada y que es una total perdida de tiempo) por no haberlas registrado en algún documento debido a que he priorizado a otras tareas antes que la mencionada. Nuestro grupo es de solamente 3 personas y hay muchas cosas para hacer que bueno, llevan a este tipo de cosas. Una cosa que creo que les puede servir de mucho a los responsables de IR, es informarle previamente al Cliente los temas que se tratarán y la lista de preguntas que se le realizarán en la reunión. Personalmente, esta metodología me ha servido de mucho y creo que gracias a esto, es que siempre al finalizar las entrevistas logramos nuestros objetivos. También creo que esto ayuda a que el tiempo que consume el Cliente hablando de cosas poco importantes, se ve mitigado a la hora de comparar el tiempo consumido en la reunión con las cosas relevadas (¿Se cumplieron los objetivos?).
Tiempo Dedicado 15 minutos.
Proyecto SCPI Preguntas
Pregunta 1 Req.Eli.An.01
¿Qué aspectos considera usted que es importante que se tomen en cuenta a la hora de planificar una entrevista?
Respuesta Para planificar una entrevista lo que se realizó es confeccionar una Minuta de Reunión y enviársela a todos los integrantes que van a participar con varios días de anticipación a la fecha estipulada de dicha reunión. Dentro de esta Minuta se presento, el lugar físico de la reunión, los integrantes que van a participar con sus roles definidos, los temas a tratar, el día y la hora, el tiempo estipulado y el orden de los temas a tratar según su prioridad. Se realizó un documento con las preguntas a realizarle al usuario. Junto con la minuta de reunión se adjuntaba también la versión actualizada del ESRE para que el cliente leyese antes de la reunión.
Tiempo Dedicado 5 minutos
Pregunta 2 Req.Eli.Ap.01
Una buena comunicación con el usuario es clave para lograr recolectar información. Exponga los problemas más relevantes que ha tenido para establecer una comunicación efectiva y cómo los ha superado.
Respuesta En nuestro caso, no se tuvo mayores inconvenientes de comunicación con el usuario, debido a que este es Ingeniero en Sistemas y la comunicación era fluida dado que conocía a la perfección el dominio. Pero obviamente que la comunicación es muy importante y esto hay que tenerlo muy en cuenta a la hora de comunicarse con un usuario o cliente que no esté familiarizado con sistemas de información o tecnología en general.
Tiempo Dedicado 5 minutos
252
Pregunta 3 Req.Eli.Ev.01
¿Qué recomendaría usted a un ingeniero de requerimiento que se enfrenta a un usuario con necesidades poco claras?
Respuesta Cuando se tiene un usuario con las necesidades poco claras, lo mejor a mi entender, es proponerle soluciones a los problemas que el usuario posee. Estos problemas el usuario los tiene claro, pero no sabe cuales son las necesidades o lo que necesita para resolverlos y para esto con un estudio importante del dominio en que se movería la aplicación, lo mejor es proponerle soluciones para que éste vaya teniendo mas claras cuales son las necesidades y poder llegar así a un mejor entendimiento de la aplicación a realizar.
Tiempo Dedicado 5 minutos
Pregunta 4 Req.Eli.Si.01
Relate, en no menos de cuatro o cinco líneas, aquella experiencia de entrevista que usted considera que fue la más exitosa y que volvería a repetir.
Respuesta La mejor entrevista con el cliente que tuvimos fue aquella en la que previamente decidimos armar como se mencionó una minuta de reunión, el cual nos posibilitó realizar en forma mucho más ágil la reunión. Otro aspecto exitoso a mi entender fue grabar en formato audio las reunión. Esto sirvió para luego de escuchar de nuevo la reunión no perdernos de nada importante. También el dejarle al cliente en forma anticipada a la reunión el ESRE, permitió que en la reunión se nos indicarna errores que poseíamos en la especificación de los requerimientos.
Tiempo Dedicado 5 minutos
Pregunta 5 Req.An.An.01
En base a su experiencia, ¿qué dificultades encontró para distinguir los requerimientos funcionales de los no funcionales?
Respuesta No se encontraron dificultades en este tema.
Tiempo Dedicado 1 minuto
Pregunta 6 Req.An.Ev.01
¿Cómo logró superar las dificultades anteriormente expresadas?
Respuesta
Tiempo Dedicado 0 minutos
Pregunta 7 Req.Prep.Si.01
Los miembros del proyecto que se dedican a la ingeniería de requerimiento necesitan un entrenamiento inicial para prepararse para la tarea. ¿De qué manera planearía usted este entrenamiento?
Respuesta Se necesita si un entrenamiento previo. A nosotros nos vino muy bien el Taller de Ingeniería de Requerimientos que tuvimos. Este entrenamiento para mi, tendría una parte “teórica” y una parte “practica”. La parte teórica mostraría cuales son las perspectivas de la ingeniería de requerimientos; funcional, metodológica, de resultado, de comportamiento y organizacional. Teniendo claras las 5 perspectivas, realizar un ejemplo práctico para solventar estos conocimientos teóricos y lo más importante transmitir las experiencias de uno.
Tiempo Dedicado 10 minutos
Pegunta 8 Req.Prep.Ev.01
A su juicio, ¿qué habilidades personales facilitarían las tareas del ingeniero de requerimientos?
Respuesta La organización, la comunicación con otros, la proactividad, conocer el dominio, ponerse del lado del cliente.
Tiempo Dedicado 5 minutos
253
Pegunta 9 Req..Ev.01
De las actividades relativas a IR que llevó a cabo en el presente proyecto, ¿cuales considera que realizó adecuadamente y cuáles considera que deberá mejorar la próxima vez?
Respuesta De las actividades, la extracción de los requerimientos y la del conocimiento del dominio fueron a mí entender las que se realizó de la mejor forma. La actividad que nos dio mayor problema fue documentar todo lo extraído, dado que se posee en la página Web institucional muchas herramientas para llevar adelante la ingeniería de requerimientos y en principio se decidió utilizar la mayoría de ellas, pero mediante charlas con el tutor de rol, éste nos fue comunicando que mantener todos los documentos llevaría tiempo y que es necesario manejar una relación costo/beneficio y poder realizar documentos que le aporte al cliente, a la academia y a nosotros mismos.
Tiempo Dedicado 10 minutos
Espacio Libre
Tiempo Dedicado 0 minutos.
Proyecto InvPortal Preguntas
Pregunta 1 Req.Eli.An.01
¿Qué aspectos considera usted que es importante que se tomen en cuenta a la hora de planificar una entrevista?
Respuesta En primer lugar se debe saber con quién se va a tener la entrevista, conocer la persona, ser puntual, etc. Se debe planificar el alcance de la entrevista y que temas se van a tratar en la misma, esto se puede lograr realizando una guía con las preguntas mas importantes, sin necesidad de seguirla paso a paso, pero si para asegurarnos de aclarar todos los puntos para los cuales se solicitó la entrevista. Tratar de guiar nosotros la entrevista, a fin de asegurarnos de que no se vaya por las ramas la reunión, a menos que nos interese conocer un poco más de la empresa y del cliente, sino seria bueno tener el control de la misma, para poder manejar nuestro tiempo y asegurarnos de que nos vamos a ir con las respuestas que necesitamos y no con las manos vacías, ya que puede pasar si dejamos que el cliente tenga el control y nos diga un montón de cosas importantes, pero no para nosotros en ese momento. Otra cosa importante a tener en cuenta es la posición del equipo(si es que va más de una persona a la entrevista) el grupo se debe comportar como uno, hablar de a uno, y sobre todas las cosas estar de acuerdo de ante mano en lo que se pregunta, en lo que se dice y en lo que se defiende, nunca debe discutir el grupo frente al cliente o a cualquier persona externa al equipo de trabajo, se debe apoyar el grupo entre si y ponerse de acuerdo internamente de todo. También es importante llevar una planilla con las conclusiones de las entrevistas, de lo que se habló, a que se llegó y que dudas surgieron de ella, de manera que, podamos mejorar en caso de haber tenido errores o utilizarla como base para la próxima entrevista, aprender de las cosas en las que nos equivocamos y tratar de mejorarlas para que no vuelvan a pasar.
Tiempo Dedicado 15 min
Pregunta 2 Req.Eli.Ap.01
Una buena comunicación con el usuario es clave para lograr recolectar información. Exponga los problemas más relevantes que ha tenido para establecer una comunicación efectiva y cómo los ha superado.
Respuesta No hemos tenido problemas de comunicación con el cliente ya que siempre se intentó dejar muy claro y documentado cada uno de los requerimientos del mismo de manera de evitar malos entendidos, lo que nos ha resultado mas problemático es la coordinación de entrevistas por el tema de los horarios, ya que en el horario que al cliente le servía la entrevista, nosotros trabajamos, pero logramos un acuerdo y encontrar una media que nos convenga a las dos partes.
254
Tiempo Dedicado 10 min
Pregunta 3 Req.Eli.Ev.01
¿Qué recomendaría usted a un ingeniero de requerimiento que se enfrenta a un usuario con necesidades poco claras?
Respuesta Se debería realizar un estudio de las necesidades del cliente, estudiando la empresa, las ventajas y desventajas de la misma, oportunidades en el mercado, sector de mercado, etc. y a partir de este realizar un documento con conclusiones de lo estudiado, para presentarle al cliente, sacando de ese documento y de la entrevista con el cliente los requerimientos a tener en cuenta, ya que más allá de tener más claras las necesidades del cliente, éste, debe de estar de acuerdo con las mismas y aceptarlas. Una vez de acuerdo el cliente con las necesidades establecidas, se realiza la especificación de los requerimientos con la posterior aprobación del cliente.
Tiempo Dedicado 5 min
Pregunta 4 Req.Eli.Si.01
Relate, en no menos de cuatro o cinco líneas, aquella experiencia de entrevista que usted considera que fue la más exitosa y que volvería a repetir.
Respuesta Las entrevistas que realizadas, nos parecen todas muy exitosas ya que de cada una de ellas aprovechamos la mayor cantidad del tiempo, logramos aclarar todas las preguntas que teníamos para el cliente, sentir que habíamos avanzado en el proyecto, tanto en lo que veníamos haciendo, como en la claridad de las cosas que nos quedaban por hacer. Logramos un buen entendimiento con el cliente, respetamos su punto de vista, como también hacemos respetar las cosas que escapan al alcance del proyecto por causa del tiempo.
Tiempo Dedicado 5 min
Pregunta 5 Req.An.An.01
En base a su experiencia, ¿qué dificultades encontró para distinguir los requerimientos funcionales de los no funcionales?
Respuesta La mayor parte de los requerimientos identificados fueron extraídos del propio documento con la propuesta del proyecto, y cómo supimos diferenciar ambos conceptos, podemos decir que no encontramos dificultades para distinguirlos.
Tiempo Dedicado 5 min
Pregunta 6 Req.An.Ev.01
¿Cómo logró superar las dificultades anteriormente expresadas?
Respuesta No hubo dificultades.
Tiempo Dedicado 0 min
255
Pregunta 7 Req.Prep.Si.01
Los miembros del proyecto que se dedican a la ingeniería de requerimiento necesitan un entrenamiento inicial para prepararse para la tarea. ¿De qué manera planearía usted este entrenamiento?
Respuesta No me parece que debiera haber un entrenamiento, a menos que este sea practico, esta claro que para la mayoría nos resulta como algo nuevo ya que no lo realizamos a lo largo de la carrera, pero sí tenemos los conocimientos teóricos de ello, el tema principal es que es la primera vez de alguna manera que ponemos en practica todo eso que hemos aprendido a lo largo de la carrera, ya que lo habitual es que se entreguen los requerimientos del trabajo, sin la necesidad de que uno interactue directamente con el cliente, de manera que todo es nuevo a la hora de realizar el proyecto, como por ejemplo la realización de entrevistas y relevar los requerimientos según las necesidades que el cliente plantea, siempre y cuando éste tenga claro que es lo que quiere, y no se tenga que realizar una investigación previa a esto, para ofrecerle al cliente una serie de alternativas sobre lo que se puede hacer acorde a sus necesidades, como fue nuestro caso, esto implica un montón de tiempo extra, basado en investigación únicamente, que es difícil estimar, y que sea tenido en cuenta a la hora de evaluar el proyecto como trabajo final. La manera de llegar con un entrenamiento al proyecto final podría ser realizando un mini proyecto para obtener el titulo intermedio, que puede ser el mismo taller de genexus, pero que, en vez de ser orientado a diseño en si, también tenga como misión el aprender a interactuar con el cliente, que el mismo alumno sea el que releve lo que el cliente quiere y cómo lo quiere, eso puede ayudar bastante, ya que hay materias que te exigen esto pero no se les da la importancia que se debería.
Tiempo Dedicado 20 min
Pegunta 8 Req.Prep.Ev.01
A su juicio, ¿qué habilidades personales facilitarían las tareas del ingeniero de requerimientos?
Respuesta Comunicación, entendimiento, comprensión, expresión, disponibilidad, detallista, analítico.
Tiempo Dedicado 2 min
Pegunta 9 Req..Ev.01
De las actividades relativas a IR que llevo acabo en el presente proyecto, ¿cuáles considera que realizó adecuadamente y cuáles considera que deberá mejorar la próxima vez?
Respuesta No considero que hayamos tenido problemas a la hora de relevar los requerimientos, en sí, el único problema si se puede considerar como problema de ingeniería de requerimientos, fue la disponibilidad horaria del cliente y la nuestra en el momento de concretar una entrevista.
Tiempo Dedicado 5 min
Espacio Libre
Tiempo Dedicado 0 minutos.
256
A3.5 Documento de Resumen de Respuestas de las guías de reflexión para ingeniería de requisitos
Resumen de respuestas de las Guías de Reflexión – Requisitos Software Pregunta 1 – ¿Qué aspectos considera usted que es importante que se tomen en cuenta a la hora de planificar una entrevista?
Proyecto GESA Definir las metas y el alcance de la entrevista Elaborar lista de preguntas Seleccionar adecuadamente al entrevistado Familiarizarse con la terminología del entrevistado Enviarle previamente al entrevistado la lista de preguntas o temas a tratar
Proyecto COODESOR Generar una lista de posibles preguntas o temas Informar previamente al entrevistado sobre la temática y el contenido de la entrevista
Proyecto SCPI Para planificar una entrevista lo que se realizó es confeccionar una Minuta de Reunión y enviársela a todos los integrantes que van a participar con varios días de anticipación a la fecha estipulada de dicha reunión. Dentro de esta Minuta se presentó el lugar físico de la reunión, los integrantes que van a participar con sus roles definidos, los temas a tratar, el día y la hora, el tiempo estipulado y el orden de los temas a tratar según su prioridad. Se realizó un documento con las preguntas a realizarle al usuario.
Proyecto InvPortal En primer lugar se debe saber con quién se va a tener la entrevista, conocer la persona, ser puntual, etc. Se debe planificar el alcance de la entrevista y que temas se van a tratar en la misma, esto se puede lograr realizando una guía con las preguntas más importantes, sin necesidad de seguirla paso a paso, pero sí para asegurarnos de aclarar todos los puntos para los cuales se solicito la entrevista. Otra cosa importante a tener en cuenta es la posición del equipo (si es que va más de una persona a la entrevista) el grupo se debe comportar como uno, hablar de a uno, y sobre todas las cosas estar de acuerdo de antemano en lo que se pregunta, en lo que se dice y en lo que se defiende, También es importante llevar una planilla con las conclusiones de las entrevistas, de lo que se habló, a que se llegó y que dudas surgieron de ella.
Pregunta 2 – Una buena comunicación con el usuario es clave para lograr recolectar información. Exponga los problemas más relevantes que ha tenido para establecer una comunicación efectiva y cómo los ha superado.
Proyecto GESA No responde sobre los problemas que ha tenido.
Proyecto COODESOR El no tener una instancia previa de conocimiento de la contraparte del cliente en nuestra entrevista.
Proyecto SCPI En nuestro caso, no se tuvo mayores inconvenientes de comunicación con el usuario, debido a que éste es Ingeniero en Sistemas y la comunicación era fluida dado que conocía a la perfección el dominio. Pero obviamente que la comunicación es muy importante y esto hay que tenerlo muy en cuenta a la hora de comunicarse con un usuario o cliente que no esté familiarizado con sistemas de información o tecnología en general.
257
Proyecto InvPortalLo que nos ha resultado más problemático es la coordinación de entrevistas por el tema de los horarios, ya que en el horario que al cliente le servía la entrevista, nosotros trabajamos, pero logramos un acuerdo y encontrar una media que nos convenga a las dos partes.
Pregunta 3 – ¿Qué recomendaría usted a un ingeniero de requerimiento que se enfrenta a un usuario con necesidades poco claras?
Proyecto GESA Profundizar en el tema a tratar, analizar todo en detalle para sacar conclusiones y obtener así las verdaderas necesidades.
Proyecto COODESOR Indagar en las tareas más frecuentes que realiza el usuario o las tareas que se llevan a cabo en el entorno del cliente. También creo que es bueno analizar y realizar un esquema de los procesos que realiza el usuario o el cliente en general para hacerle esquematizar de alguna forma las tareas que realiza y lograr definir claramente sus necesidades y sus objetivos.
Proyecto SCPI Cuando se tiene un usuario con las necesidades poco claras, lo mejor a mi entender, es proponerle soluciones a los problemas que el usuario posee. Estos problemas el usuario los tiene claro, pero no sabe cuales son las necesidades o lo que necesita para resolverlos y para esto con un estudio importante del dominio en que se movería la aplicación, lo mejor es proponerle soluciones para que éste vaya teniendo mas claras cuales son las necesidades y poder llegar así a un mejor entendimiento de la aplicación a realizar.
Proyecto InvPortalSe debería realizar un estudio de las necesidades del cliente, estudiando la empresa, las ventajas y desventajas de la misma, oportunidades en el mercado, sector de mercado, etc. Y, a partir de éste, realizar un documento con conclusiones de lo estudiado, para presentarle al cliente, sacando de ese documento y de la entrevista con el cliente los requerimientos a tener en cuenta, ya que mas allá de tener más claras las necesidades del cliente, éste debe estar de acuerdo con las mismas y aceptarlas. Una vez de acuerdo el cliente con las necesidades establecidas, se realiza la especificación de los requerimientos con la posterior aprobación del cliente.
Pregunta 4 – Relate en no menos de cuatro o cinco líneas aquella experiencia de entrevista que usted considera que fue la más exitosa y que volvería a repetir.
Proyecto GESA En la cuarta entrevista (como en el resto) le mandamos por mail a nuestro Cliente la lista de temas que íbamos a tratar así como las preguntas que le íbamos a realizar. Cuando llegó el momento de la entrevista, nuestro Cliente ya había contestado las preguntas y se había informado más acerca de los temas que creyó conveniente para poder de esta manera colaborar más con nosotros. Todo esto llevo a que la entrevista durara no más de 60 minutos y que nos volviéramos con todas las dudas saciadas.
Proyecto COODESOR Creo que la entrevista más exitosa fue la sostenida con el presidente de la cooperativa (responsable de la misma). En ella no sólo logré obtener más información sobre las necesidades y expectativas del cliente sobre el producto final, sino que logré un grado importante del cliente en el proyecto y en las características del mismo. Aparte de esto se generó una conciencia en el cliente de lo necesario que resulta para la empresa la incorporación de una nueva herramienta informática, haciéndole ver la potencialidad del producto no sólo en esta primer etapa sino en las etapas sucesivas.
258
Proyecto SCPI Fue aquella en la que previamente decidimos armar, cómo se mencionó, una minuta de reunión, el cual nos posibilitó realizar en forma mucho más ágil la reunión. Otro aspecto exitoso a mi entender fue grabar en formato audio las reunión. Esto sirvió para luego de escuchar de nuevo la reunión no perdernos de nada importante. También el dejarle al cliente en forma anticipada a la reunión el ESRE, permitió que en la reunión se nos indicara errores que poseíamos en la especificación de los requerimientos.
Proyecto InvPortal Nos parecen todas muy exitosas ya que de cada una de ellas aprovechamos la mayor cantidad del tiempo, logramos aclarar todas las preguntas que teníamos para el cliente, sentir que habíamos avanzado en el proyecto, tanto en lo que veníamos haciendo, como en la claridad de las cosas que nos quedaban por hacer. Logramos un buen entendimiento siempre con el cliente, respetamos muchísimo su punto de vista, como también hacemos respetar las cosas que escapan al alcance del proyecto por causa del tiempo.
Pregunta 5 – En base a su experiencia, ¿qué dificultades encontró para distinguir los requerimientos funcionales de los no funcionales?
Proyecto GESA Tenía claro lo que se entiende por requerimientos funcionales, pero con respecto a los requerimientos no funcionales tuve que leer acerca de ellos porque no se me ocurrían muchos.
Proyecto COODESOR Poco conocimiento que tenía de la diferencia entre los requerimientos funcionales y no funcionales y lo que involucraba cada uno de estos conceptos.
Proyecto SCPI No se encontraron dificultades en este tema.
Proyecto InvPortal Podemos decir que no encontramos dificultades para distinguirlos.
Pregunta 6 – ¿Cómo logró superar las dificultades anteriormente expresadas?
Proyecto GESA Investigando acerca de los mismos, en Internet y en diapositivas de semestres anteriores.
Proyecto COODESOR Varias instancias de aprendizaje y de consulta a los tutores permitieron definir claramente los conceptos que abarcaban los conceptos anteriores permitiendo diferenciarlos con más claridad.
Proyecto SCPI No responde a la pregunta.
Proyecto InvPortal No responde a la pregunta.
259
Pregunta 7 – Los miembros del proyecto que se dedican a la ingeniería de requerimiento necesitan un entrenamiento inicial para prepararse para la tarea. ¿De qué manera planearía usted este entrenamiento?
Proyecto GESA Si se puede hacer un curso de Ingeniería de Requerimientos bienvenido será.
Proyecto COODESOR Hacer un taller entre los participantes de IR aplicando técnicas de análisis de casos y role playing para experimentar en un entorno académico los diferentes aspectos de la IR.
Proyecto SCPI Se necesita, sí, un entrenamiento previo. A nosotros nos vino muy bien el Taller de Ingeniería de Requerimientos que tuvimos. Este entrenamiento para mi, tendría una parte “teórica” y una parte “práctica”. La parte teórica mostraría cuales son las perspectivas de la ingeniería de requerimientos; funcional, metodológica, de resultado, de comportamiento y organizacional. Teniendo claras las 5 perspectivas, realizar un ejemplo práctico para solventar estos conocimientos teóricos y lo más importante transmitir las experiencias de uno.
Proyecto InvPortalNo me parece que debiera haber un entrenamiento, a menos que éste sea práctico. La manera de llegar con un entrenamiento al proyecto final podría ser realizando un mini proyecto para obtener el título intermedio, que puede ser el mismo taller de Genexus, pero que en vez de ser orientado a diseño en si, que también tenga como misión el aprender a interactuar con el cliente, que el mismo alumno sea el que releve lo que el cliente quiere y como lo quiere, eso puede ayudar bastante
Pregunta 8 – A su juicio, ¿qué habilidades personales facilitarían las tareas de ingeniero de requerimientos?
Proyecto GESA Creo que mas que nada es importantísimo el tema comunicación. El Ingeniero de Requerimientos además de tener que ser responsable y todo lo demás, debe ser una persona bastante abierta, y que no tenga problemas de diálogo, creo que ésta es la clave.
Proyecto COODESOR Saber escuchar, facilidad de comunicación adecuando la misma a las características del cliente, poder lograr empatía con el cliente, nunca está de más una buena presencia que demuestre seriedad en el emprendimiento.
Proyecto SCPI La organización, la comunicación con otros, la proactividad, conocer el dominio, ponerse del lado del cliente.
Proyecto InvPortalComunicación, Entendimiento, Comprensión, Expresión, Disponibilidad, Detallista, Analítico.
260
Pregunta 9 – De las actividades de IR que llevó a cabo en el presente proyecto, ¿cuáles considera que realizó adecuadamente y cuáles considera que deberá mejorar la próxima vez?
Proyecto GESA Tanto la planificación de las entrevistas como el relevamiento y la creación del ESRE creo que fue lo más fuerte. Lo que debo mejorar para las próximas entrevistas es el tiempo, la mayoría de las veces por ser cortés con el Cliente lo dejo explayarse en cosas poco relevantes para el proyecto y esto lleva a que la reunión se extienda más de lo planificado sin agregarle nada productivo a la entrevista. Supongo que ésto se debe a la falta de experiencia en entrevistas.
Proyecto COODESOR De cualquier manera creo que lo que mejoraría para una próxima oportunidad sería la incorporación de una instancia inicial de conocimiento del cliente y la contraparte en el proceso de entrevistas. Sin esta instancia no se pudo prever las características de esta primera entrevista de relevamiento.
Proyecto SCPI La actividad que nos dio mayor problema fue documentar todo lo extraído, dado que se posee en la página Web institucional muchas herramientas para llevar adelante la ingeniería de requerimientos y en principio se decidió utilizar la mayoría de ellas, pero mediante charlas con el tutor de rol, éste nos fue comunicando que mantener todos los documentos llevaría tiempo y que es necesario manejar una relación costo/beneficio y poder realizar documentos que le aporte al cliente, a la academia y a nosotros mismos.
Proyecto InvPortal El único problema si se puede considerar como problema de ingeniería de requerimientos, fue la disponibilidad horaria del cliente y la nuestra en el momento de concretar una entrevista.
261
A3.6 Cuestionarios de evaluación de las Guías de reflexión para ingeniería de requisitos, respondidos por los ingenieros de requisitos de los grupos de proyecto participantes
Cuestionario de Evaluación de la Guía de Reflexión – Ingeniería de Requisitos
Proyecto: Sistema Gestión COODESOR Nombre: Daniel Nicolich Propósito: Recabar opinión acerca de las Guías de Reflexión como herramienta para facilitar la reflexión. 1. La lectura de la Guía de Reflexión en forma previa a la realización de mis tareas de proyecto me hubiera
permitido prepararme mejor para llevar a cabo esas tareas.
Muy en desacuerdo En desacuerdo X Indiferente De acuerdo Muy de acuerdo
2. La respuesta dada a cada pregunta estuvo directamente vinculada a mi experiencia personal adquirida
en el proyecto.
Muy
en
desc
uerd
o
En d
esac
uerd
o
Indi
fere
nte
De
acue
rdo
Muy
de
acue
rdo
Pregunta 1 Req.Eli.An.01 X 2 Req.Eli.Ap.01 X 3 Req.Eli.Ev.01 X 4 Req.Eli.Si.01 X 5 Req.An.An.01 X 6 Req.An.Ev.01 X 7 Req.Prep.Si.01 X 8 Req.Prep.Ev.01 X 9 Req.-.Ev.01 X
262
3. La pregunta me instó a reflexionar detenidamente acerca de la respuesta a dar a la misma.
Muy
en
desc
uerd
o
En d
esac
uerd
o
Indi
fere
nte
De
acue
rdo
Muy
de
acue
rdo
Pregunta 1 Req.Eli.An.01 X 2 Req.Eli.Ap.01 X 3 Req.Eli.Ev.01 X 4 Req.Eli.Si.01 X 5 Req.An.An.01 X 6 Req.An.Ev.01 X 7 Req.Prep.Si.01 X 8 Req.Prep.Ev.01 X 9 Req.-.Ev.01 X
4. Haber reflexionado y respondido a la pregunta me permitió identificar “brechas” en mis conocimientos
relativos a los temas abordados en las mismas.
Muy
en
desc
uerd
o
En d
esac
uerd
o
Indi
fere
nte
De
acue
rdo
Muy
de
acue
rdo
Pregunta 1 Req.Eli.An.01 X 2 Req.Eli.Ap.01 X 3 Req.Eli.Ev.01 X 4 Req.Eli.Si.01 X 5 Req.An.An.01 X 6 Req.An.Ev.01 X 7 Req.Prep.Si.01 X 8 Req.Prep.Ev.01 X 9 Req.-.Ev.01 X
263
5. Haber reflexionado y respondido a la pregunta me permitió identificar aspectos de mi actuación en el
proyecto que considero deberé mejorar en una próxima instancia.
Muy
en
desc
uerd
o
En d
esac
uerd
o
Indi
fere
nte
De
acue
rdo
Muy
de
acue
rdo
Pregunta 1 Req.Eli.An.01 X 2 Req.Eli.Ap.01 X 3 Req.Eli.Ev.01 X 4 Req.Eli.Si.01 X 5 Req.An.An.01 X 6 Req.An.Ev.01 X 7 Req.Prep.Si.01 X 8 Req.Prep.Ev.01 X 9 Req.-.Ev.01 X
6. En general, considero a las Guías de Reflexión como un instrumento útil para facilitar la reflexión sobre
mis conocimientos y mi actuación profesional.
Muy en desacuerdo En desacuerdo Indiferente X De acuerdo Muy de acuerdo
Cuestionario de Evaluación de la Guía de Reflexión – Ingeniería de Requisitos
Proyecto: GESA Nombre: Carlos Geribón Propósito: Recabar opinión acerca de las Guías de Reflexión como herramienta para facilitar la reflexión. 1. La lectura de la Guía de Reflexión en forma previa a la realización de mis tareas de proyecto me hubiera
permitido prepararme mejor para llevar a cabo esas tareas.
Muy en desacuerdo En desacuerdo Indiferente
De acuerdo Muy de acuerdo
264
2. La respuesta dada a cada pregunta estuvo directamente vinculada a mi experiencia personal adquirida
en el proyecto.
Muy
en
desc
uerd
o
En d
esac
uerd
o
Indi
fere
nte
De
acue
rdo
Muy
de
acue
rdo
Pregunta 1 Req.Eli.An.01 2 Req.Eli.Ap.01 3 Req.Eli.Ev.01 4 Req.Eli.Si.01 5 Req.An.An.01 6 Req.An.Ev.01 7 Req.Prep.Si.01 8 Req.Prep.Ev.01 9 Req.-.Ev.01
3. La pregunta me instó a reflexionar detenidamente acerca de la respuesta a dar a la misma.
Muy
en
desc
uerd
o
En d
esac
uerd
o
Indi
fere
nte
De
acue
rdo
Muy
de
acue
rdo
Pregunta 1 Req.Eli.An.01 2 Req.Eli.Ap.01 3 Req.Eli.Ev.01 4 Req.Eli.Si.01 5 Req.An.An.01 6 Req.An.Ev.01 7 Req.Prep.Si.01 8 Req.Prep.Ev.01 9 Req.-.Ev.01
265
4. Haber reflexionado y respondido a la pregunta me permitió identificar “brechas” en mis conocimientos
relativos a los temas abordados en las mismas.
Muy
en
desc
uerd
o
En d
esac
uerd
o
Indi
fere
nte
De
acue
rdo
Muy
de
acue
rdo
Pregunta 1 Req.Eli.An.01 2 Req.Eli.Ap.01 3 Req.Eli.Ev.01 4 Req.Eli.Si.01 5 Req.An.An.01 6 Req.An.Ev.01 7 Req.Prep.Si.01 8 Req.Prep.Ev.01 9 Req.-.Ev.01
5. Haber reflexionado y respondido a la pregunta me permitió identificar aspectos de mi actuación en el proyecto que considero deberé mejorar en una próxima instancia.
Muy
en
desc
uerd
o
En d
esac
uerd
o
Indi
fere
nte
De
acue
rdo
Muy
de
acue
rdo
Pregunta 1 Req.Eli.An.01 2 Req.Eli.Ap.01 3 Req.Eli.Ev.01 4 Req.Eli.Si.01 5 Req.An.An.01 6 Req.An.Ev.01 7 Req.Prep.Si.01 8 Req.Prep.Ev.01 9 Req.-.Ev.01
266
6. En general, considero a las Guías de Reflexión como un instrumento útil para facilitar la reflexión sobre
mis conocimientos y mi actuación profesional.
Muy en desacuerdo En desacuerdo Indiferente
De acuerdo Muy de acuerdo
Cuestionario de Evaluación de la Guía de Reflexión – Ingeniería de Requisitos
Proyecto: SCPI (Seguimiento y Control de Proyectos de Inversión) Nombre: Andrés Lapachian Propósito: Recabar opinión acerca de las Guías de Reflexión como herramienta para facilitar la reflexión. 1. La lectura de la Guía de Reflexión en forma previa a la realización de mis tareas de proyecto me hubiera
permitido prepararme mejor para llevar a cabo esas tareas.
Muy en desacuerdo En desacuerdo Indiferente X De acuerdo Muy de acuerdo
2. La respuesta dada a cada pregunta estuvo directamente vinculada a mi experiencia personal adquirida
en el proyecto.
Muy
en
desc
uerd
o
En d
esac
uerd
o
Indi
fere
nte
De
acue
rdo
Muy
de
acue
rdo
Pregunta 1 Req.Eli.An.01 X 2 Req.Eli.Ap.01 X 3 Req.Eli.Ev.01 X 4 Req.Eli.Si.01 X 5 Req.An.An.01 X 6 Req.An.Ev.01 X 7 Req.Prep.Si.01 X 8 Req.Prep.Ev.01 X 9 Req.-.Ev.01 X
267
3. La pregunta me instó a reflexionar detenidamente acerca de la respuesta a dar a la misma.
Muy
en
desc
uerd
o
En d
esac
uerd
o
Indi
fere
nte
De
acue
rdo
Muy
de
acue
rdo
Pregunta 1 Req.Eli.An.01 X 2 Req.Eli.Ap.01 X 3 Req.Eli.Ev.01 X 4 Req.Eli.Si.01 X 5 Req.An.An.01 X 6 Req.An.Ev.01 X 7 Req.Prep.Si.01 X 8 Req.Prep.Ev.01 X 9 Req.-.Ev.01 X
4. Haber reflexionado y respondido a la pregunta me permitió identificar “brechas” en mis conocimientos
relativos a los temas abordados en las mismas.
Muy
en
desc
uerd
o
En d
esac
uerd
o
Indi
fere
nte
De
acue
rdo
Muy
de
acue
rdo
Pregunta 1 Req.Eli.An.01 X 2 Req.Eli.Ap.01 X 3 Req.Eli.Ev.01 X 4 Req.Eli.Si.01 X 5 Req.An.An.01 X 6 Req.An.Ev.01 X 7 Req.Prep.Si.01 X 8 Req.Prep.Ev.01 X 9 Req.-.Ev.01 X
268
5. Haber reflexionado y respondido a la pregunta me permitió identificar aspectos de mi actuación en el
proyecto que considero deberé mejorar en una próxima instancia.
Muy
en
desc
uerd
o
En d
esac
uerd
o
Indi
fere
nte
De
acue
rdo
Muy
de
acue
rdo
Pregunta 1 Req.Eli.An.01 X 2 Req.Eli.Ap.01 X 3 Req.Eli.Ev.01 X 4 Req.Eli.Si.01 X 5 Req.An.An.01 X 6 Req.An.Ev.01 X 7 Req.Prep.Si.01 X 8 Req.Prep.Ev.01 X 9 Req.-.Ev.01 X
6. En general, considero a las Guías de Reflexión como un instrumento útil para facilitar la reflexión sobre
mis conocimientos y mi actuación profesional.
Muy en desacuerdo En desacuerdo Indiferente X De acuerdo Muy de acuerdo
Cuestionario de Evaluación de la Guía de Reflexión – Ingeniería de Requisitos
Proyecto: InvPortal (Sitio Web del Estado para la Inversión Privada) Nombre: Alicia Pino Propósito: Recabar opinión acerca de las Guías de Reflexión como herramienta para facilitar la reflexión. 1. La lectura de la Guía de Reflexión en forma previa a la realización de mis tareas de proyecto me hubiera
permitido prepararme mejor para llevar a cabo esas tareas.
Muy en desacuerdo En desacuerdo Indiferente X De acuerdo Muy de acuerdo
269
2. La respuesta dada a cada pregunta estuvo directamente vinculada a mi experiencia personal adquirida
en el proyecto.
Muy
en
desc
uerd
o
En d
esac
uerd
o
Indi
fere
nte
De
acue
rdo
Muy
de
acue
rdo
Pregunta 1 Req.Eli.An.01 X 2 Req.Eli.Ap.01 X 3 Req.Eli.Ev.01 X 4 Req.Eli.Si.01 X 5 Req.An.An.01 X 6 Req.An.Ev.01 X 7 Req.Prep.Si.01 X 8 Req.Prep.Ev.01 X 9 Req.-.Ev.01 X
3. La pregunta me instó a reflexionar detenidamente acerca de la respuesta a dar a la misma.
Muy
en
desc
uerd
o
En d
esac
uerd
o
Indi
fere
nte
De
acue
rdo
Muy
de
acue
rdo
Pregunta 1 Req.Eli.An.01 X 2 Req.Eli.Ap.01 X 3 Req.Eli.Ev.01 X 4 Req.Eli.Si.01 X 5 Req.An.An.01 X 6 Req.An.Ev.01 X 7 Req.Prep.Si.01 X 8 Req.Prep.Ev.01 X 9 Req.-.Ev.01 X
270
4. Haber reflexionado y respondido a la pregunta me permitió identificar “brechas” en mis conocimientos
relativos a los temas abordados en las mismas.
Muy
en
desc
uerd
o
En d
esac
uerd
o
Indi
fere
nte
De
acue
rdo
Muy
de
acue
rdo
Pregunta 1 Req.Eli.An.01 X 2 Req.Eli.Ap.01 X 3 Req.Eli.Ev.01 X 4 Req.Eli.Si.01 X 5 Req.An.An.01 X 6 Req.An.Ev.01 X 7 Req.Prep.Si.01 X 8 Req.Prep.Ev.01 X 9 Req.-.Ev.01 X
5. Haber reflexionado y respondido a la pregunta me permitió identificar aspectos de mi actuación en el
proyecto que considero deberé mejorar en una próxima instancia.
Muy
en
desc
uerd
o
En d
esac
uerd
o
Indi
fere
nte
De
acue
rdo
Muy
de
acue
rdo
Pregunta 1 Req.Eli.An.01 X 2 Req.Eli.Ap.01 X 3 Req.Eli.Ev.01 X 4 Req.Eli.Si.01 X 5 Req.An.An.01 X 6 Req.An.Ev.01 X 7 Req.Prep.Si.01 X 8 Req.Prep.Ev.01 X 9 Req.-.Ev.01 X
271
6. En general, considero a las Guías de Reflexión como un instrumento útil para facilitar la reflexión sobre
mis conocimientos y mi actuación profesional.
Muy en desacuerdo En desacuerdo Indiferente De acuerdo X Muy de acuerdo
272
A3.7 Guía de Reflexión para Métricas de Gestión de Proyecto, completadas por los gerentes de proyecto de los grupos de proyectos participantes Proyecto COODESOR Preguntas
Pregunta 1 Ge.Me.Ev.01
¿Qué métricas planificó recolectar para su proyecto? ¿Por qué considera que estas métricas son adecuadas para su proyecto en particular?
Respuesta Desfasaje en tiempo o calendario, Desfasaje en esfuerzo, Desfasaje en costo, Efectividad de pruebas. Las tres primeras permiten ver la diferencia entre lo estimado y lo real, y ello sirve para darte cuenta si es necesario hacer modificaciones en lo que tienes planificado para el futuro. Sobre la de Efectividad de pruebas, permite ver la relación existente entre los errores encontrados por la pruebas unitarias y las pruebas cruzadas, o se puede aplicar en relación a las pruebas en desarrollo con las pruebas de usuario, lo que deja en claro la calidad o efectividad de las pruebas realizadas, allí se puede ver si están siendo útiles las pruebas unitarias, se puede ver algún problema en la metodología con la que se realizan las pruebas, etc.
Tiempo Dedicado 5 min
Pregunta 2 Ge.Me.Ap.01
¿Cómo llevó a cabo el análisis de los datos obtenidos a partir de la recolección de las métricas?
Respuesta Dado que apenas comenzamos a desarrollar, no hemos tenido demasiados problemas en relación a los datos obtenidos por estas métricas, incluso la de Efectividad de pruebas aún no la hemos utilizado, pero algo que hemos podido apreciar es que las diferencias que hemos tenido en tiempo o calendario digamos, nos permitieron darnos cuenta que la planificación inicial que teníamos era totalmente utópica, por lo cual nos ha ayudado a realizar modificaciones a la planificación para que fuera más realista.
Tiempo Dedicado 10 min
Pregunta 3 Ge.Me.An.01
En base a su experiencia, ¿qué dificultades encontró para identificar las métricas que son útiles para su proyecto en particular?
Respuesta Dado que hace ya algún tiempo trabajo en desarrollo de software y estoy en contacto con métricas, no he tenido dificultades, pero creo que tal vez sea necesaria alguna otra métrica, sobre lo cual aún estoy investigando.
Tiempo Dedicado 5 min
Pregunta 4 Ge.Me.Ev.02
¿Cómo logró superar las dificultades anteriormente expresadas?
Respuesta Dado lo expresado anteriormente, la dificultad que tenemos hoy en día es identificar alguna métrica que desde nuestro punto de vista estaría faltando, la misma entiendo deba apuntar a poder visualizar los costos acumulados del proyecto, para superar esto, estaré leyendo documentación al respecto y además pretendo reunirme con el tutor del rol Gerente, para que pueda indicarme cómo estamos en relación a las métricas y al resto de temas relacionados a los documentos de gerencia.
Tiempo Dedicado 15 min
273
Pregunta 5 Ge.Me.Ev.03
¿Qué aconsejaría usted hacer para asegurar que las métricas seleccionadas son las adecuadas para un proyecto en particular?
Respuesta El tema está en que, dependiendo del tipo de proyecto serán las métricas a utilizar, esto se debe a que para proyectos de desarrollo es importante por ej., tener siempre a la vista el tema de costos, de tiempos, etc., y para proyectos de mantenimiento seguramente además de estas también será importante saber por ej., tiempos de resolución de problemas, efectividad en la resolución de problemas, relación de problemas abiertos contra problemas solucionados, etc. Creo que lo que un gerente debe tener en cuenta para tomar métricas que sean útiles, es que debe poder ver de manera clara, o sea a primer vista, cuál es el estado actual del proyecto, a nivel de tiempos, costos, etc. También se puede hacer un estudio en el tiempo de las métricas que se hayan recolectado y tal vez se pueda ver que alguna de ellas no expresa fácilmente lo que se quiere ver y, a partir de ello, dejar de usarla o modificarla para que cumpla con los objetivos.
Tiempo Dedicado 20 min
Pregunta 6 Ge.Me.Si.01
Relate, en no menos de cuatro o cinco líneas, las lecciones aprendidas durante el proceso de planificación de métricas.
Respuesta En mi caso, que previo al proyecto ya estaba en contacto con métricas del mismo estilo, en realidad no puedo identificar lecciones aprendidas, lo que sí puedo expresar es que ya que trabajo en un proyecto de mantenimiento, he observado sí la diferencia entre las métricas para un proyecto de mantenimiento y de desarrollo, pero no mucho más que eso.
Tiempo Dedicado 10 min
Pregunta 7 Ge.Me.Si.02
Los miembros del proyecto que se dedican a la planificación y gestión de métricas necesitan un entrenamiento inicial para prepararse para la tarea. ¿De qué manera planearía usted este entrenamiento?
Respuesta Primero se debería concienciar a dichos miembros a que lo principal para poder llevar a cabo la recolección de métricas es concienciar a todos los recursos del equipo para que registren adecuadamente los tiempos insumidos en las distintas tareas y luego deberían leer bibliografía al respecto de métricas, si bien muchas de las métricas pueden surgir del sentido común, existen fórmulas para obtener ciertos índices que tal vez no sean tan fáciles de imaginarse
Tiempo Dedicado 10 min
Pegunta 8 Ge.Me.Ev.04
De las actividades relativas a la planificación y gestión de métricas que llevó a cabo en el presente proyecto, ¿cuáles considera que realizó adecuadamente y cuáles considera que debería mejorar la próxima vez?
Respuesta Primero, realizar una charla con el equipo para que entiendan la importancia del registro de horas, que si bien se ha recalcado continuamente la importancia de ello, es difícil obtener una respuesta adecuada, por lo cual entiendo que en esta tarea he fallado y debería mejorarla para próximas oportunidades. Luego, tal vez se podrían establecer las métricas a utilizar al comienzo mismo del proyecto, cosa que por falta de experiencia no lo hice y al establecerlas ya con un tiempo x de transcurrido el proyecto, se hace más difícil recopilar información necesaria para que las métricas representen una realidad. Algo que creo que se ha realizado bien fue la selección de las métricas a utilizar, si bien teníamos inicialmente un abanico amplio de métricas, entiendo que he optado por las que realmente aportan algo positivo, evitando así la recolección de métricas que no aportan demasiado e insumen mayor tiempo del proyecto
Tiempo Dedicado 15 min
Espacio Libre
274
Proyecto GESA Preguntas
Pregunta 1 Ge.Me.Ev.01
¿Qué métricas planificó recolectar para su proyecto? ¿Por qué considera que estas métricas son adecuadas para su proyecto en particular?
Respuesta Las métricas que están siendo recolectadas para el proyecto por mi parte, son métricas utilizadas para el área de gerencia de proyecto la cual está bajo mi responsabilidad. Estas métricas están enfocadas, mas que nada, a la parte de recursos humanos. Con ellas se trata de establecer el alcance del proyecto, si se van a poder cumplir las metas estimadas. Las métricas utilizadas son la dedicación horaria de todo el grupo en cada iteración que dura aproximadamente 15 días. Y por otro lado se contabiliza la dedicación horaria de cada integrante en particular en la iteración. También se realiza el desvío de la estimación realizada para cada tarea de la iteración, obteniendo así el desvío de tiempo entre lo estimado y el tiempo real de las tareas. Creo que estas métricas son genéricas a todos los proyectos en que tengamos un tiempo de entrega acotado, ya que con estas se puede estimar el tiempo que llevara el proyecto y sí la dedicación de tiempo por parte del personal es la suficiente o si hay que dedicarle más tiempo para cumplir las metas, así como también me permite saber si la dedicación al proyectos es igual entre los involucrados.
Tiempo Dedicado 13 ‘
Pregunta 2 Ge.Me.Ap.01
¿Cómo llevó a cabo el análisis de los datos obtenidos a partir de la recolección de las métricas?
Respuesta El análisis se hizo primero estudiando las horas dedicadas por cada integrante para una iteración, luego se agruparon para obtener el tiempo dedicado por todos los integrantes a la iteración. En cuanto al estudio de la estimación de cuanto nos llevaría cada tarea de la iteración en principio se hizo una estimación a ciegas y se comparó con el tiempo real, así se obtuvieron datos para la siguiente iteración ya partiendo de datos anteriores.
Tiempo Dedicado 5’
Pregunta 3 Ge.Me.An.01
En base a su experiencia, ¿qué dificultades encontró para identificar las métricas que son útiles para su proyecto en particular?
Respuesta Las dificultades para encontrar las métricas fueron bastante grandes, ya que anteriormente se hizo un estudio de métricas que fueron descartadas en la primera revisión ya que nos darían resultados “post mortem” y no es esa la finalidad de las métricas sino la de prevención. Esto nos costó bastante ya que las métricas propuestas para la primera revisión eran todas las vistas en clase de ingeniería de software. De ahí en más quedamos sin saber que camino seguir, hasta que se encontraron las métricas utilizadas actualmente.
Tiempo Dedicado 10‘
Pregunta 4 Ge.Me.Ev.02
¿Cómo logró superar las dificultades anteriormente expresadas?
Respuesta Para superar las dificultades encontradas se recurrieron a estudios de proyectos anteriores, de reuniones con los tutores de rol de la parte de gerencia de proyecto, y reuniones con el tutor de grupo.
Tiempo Dedicado 5’
275
Pregunta 5 Ge.Me.Ev.03
¿Qué aconsejaría usted hacer para asegurar que las métricas seleccionadas son las adecuadas para un proyecto en particular?
Respuesta En realizad como aconsejar no puedo ya que no tengo experiencia en esta área, si recomiendo que vean si el tiempo es primordial en el proyecto o no. A partir de ahí saldrán algunas métricas fundamentales para tener información respecto a cómo se va en el proyecto. También sirve evaluar el ciclo de vida del proyecto, dependiendo del ciclo de vida seleccionado pueden variar algunas métricas.
Tiempo Dedicado 5’
Pregunta 6 Ge.Me.Si.01
Relate, en no menos de cuatro o cinco líneas, las lecciones prendidas durante el proceso de planificación de métricas.
Respuesta Que las métricas utilizadas en otros proyectos no siempre pueden ser reutilizadas, cada proyecto debe ser evaluado por sí mismo y definidas métricas particulares para ese proyecto. Que lo visto en clase o en libros no es siempre aplicable al proyecto que estamos llevando a cabo.
Tiempo Dedicado 5’
Pregunta 7 Ge.Me.Si.02
Los miembros del proyecto que se dedican a la planificación y gestión de métricas necesitan un entrenamiento inicial para prepararse para la tarea. ¿De qué manera planearía usted este entrenamiento?
Respuesta Si considero que sería bueno que se tuviera unas clases guía por lo menos, indicando pasos a seguir. Para el entrenamiento sería más bien práctico con planteos puntuales de cómo llevar a cabo las tareas que se deben realizar, planteando ejemplos concretos.
Tiempo Dedicado 3’
Pegunta 8 Ge.Me.Ev.04
De las actividades relativas a la planificación y gestión de métricas que llevó a cabo en el presente proyecto, ¿cuáles considera que realizó adecuadamente y cuáles considera que debería mejorar la próxima vez?
Respuesta Las que considero que se llevaron a cabo correctamente son los registros de actividades de los integrantes del grupo. La que mejoraría es la tarea de estimación de cada iteración, en la cual por falta de experiencia resulto ser engorrosa de realizar.
Tiempo Dedicado 3’
Espacio Libre
Proyecto SCPI Preguntas
Pregunta 1 Ge.Me.Ev.01
¿Qué métricas planificó recolectar para su proyecto? ¿Por qué considera que estas métricas son adecuadas para su proyecto en particular?
Respuesta Las métricas que seleccionamos son: - Esfuerzo estimado y real: esta métrica nos permite conocer la desviación en la planificación de las actividades, ya sea por persona, fase o actividad. - Evolución de los riesgos: los riesgos identificados se cuantifican de acuerdo a su importancia. Pretendemos monitorear su avance en el tiempo, en principio por iteración. - Fallas: Medimos las fallas a lo largo de las fases del proyecto para conocer el nivel de calidad del producto y detectar las causas de las mismas.
Tiempo Dedicado 15 min
276
Pregunta 2 Ge.Me.Ap.01
¿Cómo llevó a cabo el análisis de los datos obtenidos a partir de la recolección de las métricas?
Respuesta Recién estamos en la primera etapa de desarrollo del proyecto, por lo que la única métrica que hemos analizado es el esfuerzo. Hemos utilizado esta métrica para corregir las estimaciones. Al final de cada iteración utilizamos el esfuerzo real para corregir la estimación de las iteraciones siguientes.
Tiempo Dedicado 5 min
Pregunta 3 Ge.Me.An.01
En base a su experiencia, ¿qué dificultades encontró para identificar las métricas que son útiles para su proyecto en particular?
Respuesta Al principio del proyecto nos basamos mucho en el marco teórico, y planteamos un conjunto de métricas que, más adelante, concluimos que no nos eran de utilidad. Esto se debía a que la información que nos aportaban era de muy poca aplicación al contexto del proyecto o que el tipo de datos que necesitábamos recaudar para generar la métrica era muy difícil de medir adecuadamente. Por esta razón, nos replanteamos las métricas a considerar y definimos las tres enunciadas en la pregunta 1.
Tiempo Dedicado 10 min
Pregunta 4 Ge.Me.Ev.02
¿Cómo logró superar las dificultades anteriormente expresadas?
Respuesta Con ayuda de la tutora de proyecto, del revisor y de la tutora de rol de SQA, redefinimos las métricas a tomar, teniendo en cuenta los aspectos que creíamos más importantes para el proyecto (por ejemplo, conocer la cantidad de fallas en cada iteración de forma de saber cómo avanza la calidad del producto y analizar de las mismas).
Tiempo Dedicado 5 min
Pregunta 5 Ge.Me.Ev.03
¿Qué aconsejaría usted hacer para asegurar que las métricas seleccionadas son las adecuadas para un proyecto en particular?
Respuesta Una primera recomendación que aprendimos con nuestra poca experiencia es evaluar el esfuerzo que requiere obtener un dato necesario para elaborar una métrica. Si el esfuerzo es muy elevado, o requiere de hacer varios cambios en la forma de trabajo del grupo para obtener una métrica precisa, tal vez es mejor tomar una métrica similar, no tan precisa, pero que sea fácil de medir y REAL.
Tiempo Dedicado 10 min
Pregunta 6 Ge.Me.Si.01
Relate, en no menos de cuatro o cinco líneas, las lecciones aprendidas durante el proceso de planificación de métricas.
Respuesta Dado a que no contamos con experiencia previa, tuvimos que recurrir a la ayuda de los tutores para poder encarar el tema. Nos dimos cuenta que sólo con el marco “teórico” no sirve, ya que hay que bajar las métricas a la realidad del proyecto.
Tiempo Dedicado 5 min
Pregunta 7 Ge.Me.Si.02
Los miembros del proyecto que se dedican a la planificación y gestión de métricas necesitan un entrenamiento inicial para prepararse para la tarea. ¿De qué manera planearía usted este entrenamiento?
Respuesta Al inicio es importante que los involucrados en dichas áreas participen de las charlas informativas que brindan los tutores de rol, ya que muestran los aspectos prácticos de cada área. Después nos resultó muy útil todo el material que se encuentra disponible en el sitio de Software Factory, donde se exponen una gran variedad de herramientas para aplicar en las tareas de cada rol.
Tiempo Dedicado 10 min
277
Pegunta 8 Ge.Me.Ev.04
De las actividades relativas a la planificación y gestión de métricas que llevó a cabo en el presente proyecto, ¿cuáles considera que realizó adecuadamente y cuáles considera que debería mejorar la próxima vez?
Respuesta En realidad consideramos que por el corto tiempo de vida que lleva nuestro proyecto, y como recién estamos comenzando con la aplicación de las métricas, todavía no podemos decir que hicimos bien o mal (máas allá de lo ya mencionado, como el consultar con expertos, o considerar métricas que son difíciles de medir). Creemos que más adelante, cuando utilicemos los datos obtenidos, vamos a saber realmente que errores cometimos en la planificación.
Tiempo Dedicado 10 min
Espacio Libre
278
A3.8 Documento de resumen de respuestas para Métricas de gestión de proyectos
Resumen de respuestas de las Guías de Reflexión – Métricas de gestión de proyectos Pregunta 1 – ¿Qué métricas planificó recolectar para su proyecto? ¿Por qué considera que estas métricas son adecuadas para su proyecto en particular?
Proyecto GESA … la dedicación horaria de todo el grupo en cada iteración que dura aproximadamente 15 días. Y por otro lado se contabiliza la dedicación horaria de cada integrante en particular en la iteración. También se realiza el desvío de la estimación realizada para cada tarea de la iteración, obteniendo así el desvío de tiempo entre lo estimado y el tiempo real de las tareas.
Proyecto COODESOR Desfasaje en tiempo o calendario, Desfasaje en esfuerzo, Desfasaje en costo, Efectividad de pruebas. Las tres primeras permiten ver la diferencia entre lo estimado y lo real, y ello sirve para darte cuenta si es necesario hacer modificaciones en lo que tienes planificado para el futuro. Sobre la de Efectividad de pruebas, permite ver la relación existente entre los errores encontrados por las pruebas unitarias y las pruebas cruzadas.
Proyecto SCPI Esfuerzo estimado y real: nos permite conocer la desviación en la planificación de las actividades, ya sea por persona, fase o actividad… Evolución de los riesgos: … pretendemos monitorear su avance en el tiempo, en principio por iteración. Fallas: Medimos las fallas a lo largo de las fases del proyecto para conocer el nivel de calidad del producto y detectar las causas de las mismas.
Proyecto InvPortal
Pregunta 2 – ¿Cómo llevó a cabo el análisis de los datos obtenidos a partir de la recolección de las métricas?
Proyecto GESA … primero estudiando las horas dedicadas por cada integrante para una iteración, luego se agruparon para obtener el tiempo dedicado por todos los integrantes a la iteración. En cuanto al estudio de la estimación de cuánto nos llevaría cada tarea de la iteración en principio se hizo una estimación a ciegas y se comparó con el tiempo real, así se obtuvieron datos para la siguiente iteración ya partiendo de datos anteriores.
Proyecto COODESOR …algo que hemos podido apreciar es que las diferencias que hemos tenido en tiempo o calendario digamos, nos permitieron darnos cuenta que la planificación inicial que teníamos era totalmente utópica, por lo cual nos ha ayudado a realizar modificaciones a la planificación para que fuera mas realista.
Proyecto SCPI … la única métrica que hemos analizado es el esfuerzo. Hemos utilizado esta métrica para corregir las estimaciones …
Proyecto InvPortal
Pregunta 3 – En base a su experiencia, ¿qué dificultades encontró para identificar las métricas que son útiles para su proyecto en particular?
Proyecto GESA Las dificultades para encontrar las métricas fueron bastante grandes, ya que anteriormente se hizo un estudio de métricas que fueron descartadas en la primera revisión ya que nos darían resultados “post mortem” y no es esa la finalidad de las métricas sino la de prevención.
279
Proyecto COODESOR … no he tenido dificultades, pero creo que tal vez sea necesaria alguna otra métrica, sobre lo cual aún estoy investigando.
Proyecto SCPI Al principio del proyecto nos basamos mucho en el marco teórico y planteamos un conjunto de métricas que, más adelante, concluimos que no nos eran de utilidad. Ésto se debía a que la información que nos aportaban era de muy poca aplicación al contexto del proyecto o que el tipo de datos que necesitábamos recaudar para generar la métrica era muy difícil de medir adecuadamente.
Proyecto InvPortal
Pregunta 4 – ¿Cómo logró superar las dificultades anteriormente expresadas?
Proyecto GESA … se recurrieron a estudios de proyectos anteriores, de reuniones con los tutores de rol de la parte de gerencia de proyecto y reuniones con el tutor de grupo.
Proyecto COODESOR … la dificultad que tenemos hoy en día es identificar alguna métrica que, desde nuestro punto de vista estaría faltando… para superar ésto, estaré leyendo documentación al respecto y además pretendo reunirme con el tutor del rol Gerente, para que pueda indicarme cómo estamos en relación a las métricas.
Proyecto SCPI Con ayuda de la tutora de proyecto, del revisor y de la tutora de rol de SQA, …
Proyecto InvPortal
Pregunta 5 – ¿Qué aconsejaría usted hacer para asegurar que las métricas seleccionadas son las adecuadas para un proyecto en particular?
Proyecto GESA … recomiendo que vean si el tiempo es primordial en el proyecto o no. A partir de ahí saldrán algunas métricas fundamentales para tener información respecto a cómo se va en el proyecto ...
Proyecto COODESOR … tener siempre a la vista el tema de costos, de tiempos, etc. … un gerente debe tener en cuenta para tomar métricas que sean útiles, es que debe poder ver de manera clara, o sea a primer vista, cuál es el estado actual del proyecto, a nivel de tiempos, costos, etc.
Proyecto SCPI Una primera recomendación que aprendimos… es evaluar el esfuerzo que requiere obtener un dato necesario para elaborar una métrica. Si el esfuerzo es muy elevado, o requiere de hacer varios cambios en la forma de trabajo…, tal vez es mejor tomar una métrica similar, no tan precisa, pero que sea fácil de medir y REAL.
Proyecto InvPortal
280
Pregunta 6 – Relate, en no menos de cuatro o cinco líneas, las lecciones aprendidas durante el proceso de planificación de métricas.
Proyecto GESA … las métricas utilizadas en otros proyectos no siempre se pueden ser reutilizadas, cada proyecto debe ser evaluado por sí mismo y definidas métricas particulares para ese proyecto. Que lo visto en clase o en libros no es siempre aplicable al proyecto que estamos llevando a cabo.
Proyecto COODESOR … lo que sí puedo expresar es que ya que trabajo en un proyecto de mantenimiento, he observado sí la diferencia entre las métricas para un proyecto de mantenimiento y de desarrollo…
Proyecto SCPI … nos dimos cuenta que sólo con el marco “teórico” no sirve, ya que hay que bajar las métricas a la realidad del proyecto.
Proyecto InvPortal
Pregunta 7 – Los miembros del proyecto que se dedican a la planificación y gestión de métricas necesitan un entrenamiento inicial para prepararse para la tarea. ¿De qué manera planearía usted este entrenamiento?
Proyecto GESA … sería bueno que se tuviera unas clases guía por lo menos, indicando pasos a seguir … el entrenamiento sería más bien práctico con planteos puntuales de cómo llevar a cabo las tareas que se deben realizar, planteando ejemplos concretos.
Proyecto COODESOR … lo principal para poder llevar a cabo la recolección de métricas es concienciar a todos los recursos del equipo para que registren adecuadamente los tiempos insumidos en las distintas tareas y luego deberían leer bibliografía al respecto de métricas…
Proyecto SCPI … que los involucrados en dichas áreas participen de las charlas informativas que brindan los tutores de rol … nos resultó muy útil todo el material que se encuentra disponible en el sitio de Software Factory …
Proyecto InvPortal
Pregunta 8 – De las actividades relativas a la planificación y gestión de métricas que llevóo a cabo en el presente proyecto, ¿cuáles considera que realizó adecuadamente y cuáles considera que debería mejorar la próxima vez?
Proyecto GESA Las que considero que se llevaron a cabo correctamente son los registros de actividades de los integrantes del grupo. La que mejoraría es la tarea de estimación de cada iteración …
281
Proyecto COODESOR … realizar una charla con el equipo para que entiendan la importancia del registro de horas … establecer las métricas a utilizar al comienzo mismo del proyecto, cosa que, por falta de experiencia, no lo hice y al establecerlas ya con un tiempo x de transcurrido el proyecto, se hace más difícil recopilar información necesaria para que las métricas representen una realidad … lo que se ha realizado bien fue la selección de las métricas a utilizar … evitando así la recolección de métricas que no aportan demasiado e insumen mayor tiempo del proyecto.
Proyecto SCPI … todavía no podemos decir que hicimos bien o mal… más adelante, cuando utilicemos los datos obtenidos, vamos a saber realmente que errores cometimos en la planificación.
Proyecto InvPortal
282
A3.9 Cuestionario de evaluación de las Guías de reflexión para Métricas de gestión del proyecto, respondidos por los gerentes de proyecto de los grupos de proyectos participantes
Cuestionario de Evaluación de las Guías de Reflexión – Métricas de Proyecto
Proyecto: Sistema Gestión COODESOR Nombre: Propósito: Recabar opinión acerca de las Guías de Reflexión como herramienta para facilitar la reflexión. 1. La lectura de la Guía de Reflexión en forma previa a la realización de mis tareas de proyecto me hubiera
permitido prepararme mejor para llevar a cabo esas tareas.
Muy en desacuerdo En desacuerdo X Indiferente De acuerdo Muy de acuerdo
2. La respuesta dada a cada pregunta estuvo directamente vinculada a mi experiencia personal adquirida
en el proyecto.
Muy
en
desc
uerd
o
En d
esac
uerd
o
Indi
fere
nte
De
acue
rdo
Muy
de
acue
rdo
Pregunta 1 Ge.Me.Ev.01 X 2 Ge.Me.Ap.01 X 3 Ge.Me.An.01 X 4 Ge.Me.Ev.02 X 5 Ge.Me.Ev.03 X 6 Ge.Me.Si.01 X 7 Ge.Me.Si.02 X 8 Ge.Me.Ev.04 X
283
3. La pregunta me instó a reflexionar detenidamente acerca de la respuesta a dar a la misma.
Muy
en
desc
uerd
o
En d
esac
uerd
o
Indi
fere
nte
De
acue
rdo
Muy
de
acue
rdo
Pregunta 1 Ge.Me.Ev.01 X 2 Ge.Me.Ap.01 X 3 Ge.Me.An.01 X 4 Ge.Me.Ev.02 X 5 Ge.Me.Ev.03 X 6 Ge.Me.Si.01 X 7 Ge.Me.Si.02 X 8 Ge.Me.Ev.04 X
4. Haber reflexionado y respondido a la pregunta me permitió identificar “brechas” en mis conocimientos
relativos a los temas abordados en las mismas.
Muy
en
desc
uerd
o
En d
esac
uerd
o
Indi
fere
nte
De
acue
rdo
Muy
de
acue
rdo
Pregunta 1 Ge.Me.Ev.01 X 2 Ge.Me.Ap.01 X 3 Ge.Me.An.01 X 4 Ge.Me.Ev.02 X 5 Ge.Me.Ev.03 X 6 Ge.Me.Si.01 X 7 Ge.Me.Si.02 X 8 Ge.Me.Ev.04 X
284
5. Haber reflexionado y respondido a la pregunta me permitió identificar aspectos de mi actuación en el
proyecto que considero deberé mejorar en una próxima instancia.
Muy
en
desc
uerd
o
En d
esac
uerd
o
Indi
fere
nte
De
acue
rdo
Muy
de
acue
rdo
Pregunta 1 Ge.Me.Ev.01 X 2 Ge.Me.Ap.01 X 3 Ge.Me.An.01 X 4 Ge.Me.Ev.02 X 5 Ge.Me.Ev.03 X 6 Ge.Me.Si.01 X 7 Ge.Me.Si.02 X 8 Ge.Me.Ev.04 X
6. En general, considero a las Guías de Reflexión como un instrumento útil para facilitar la reflexión sobre
mis conocimientos y mi actuación profesional.
Muy en desacuerdo En desacuerdo Indiferente X De acuerdo Muy de acuerdo
Cuestionario de Evaluación de las Guías de Reflexión – Métricas de Proyecto
Proyecto: GESA Nombre: Propósito: Recabar opinión acerca de las Guías de Reflexión como herramienta para facilitar la reflexión. 1. La lectura de la Guía de Reflexión en forma previa a la realización de mis tareas de proyecto me hubiera
permitido prepararme mejor para llevar a cabo esas tareas.
Muy en desacuerdo En desacuerdo Indiferente X De acuerdo Muy de acuerdo
285
2. La respuesta dada a cada pregunta estuvo directamente vinculada a mi experiencia personal adquirida
en el proyecto.
Muy
en
desc
uerd
o
En d
esac
uerd
o
Indi
fere
nte
De
acue
rdo
Muy
de
acue
rdo
Pregunta 1 Ge.Me.Ev.01 X 2 Ge.Me.Ap.01 X 3 Ge.Me.An.01 X 4 Ge.Me.Ev.02 X 5 Ge.Me.Ev.03 X 6 Ge.Me.Si.01 X 7 Ge.Me.Si.02 X 8 Ge.Me.Ev.04 X
3. La pregunta me instó a reflexionar detenidamente acerca de la respuesta a dar a la misma.
Muy
en
desc
uerd
o
En d
esac
uerd
o
Indi
fere
nte
De
acue
rdo
Muy
de
acue
rdo
Pregunta 1 Ge.Me.Ev.01 X 2 Ge.Me.Ap.01 X 3 Ge.Me.An.01 X 4 Ge.Me.Ev.02 X 5 Ge.Me.Ev.03 X 6 Ge.Me.Si.01 X 7 Ge.Me.Si.02 X 8 Ge.Me.Ev.04 X
286
4. Haber reflexionado y respondido a la pregunta me permitió identificar “brechas” en mis conocimientos
relativos a los temas abordados en las mismas.
Muy
en
desc
uerd
o
En d
esac
uerd
o
Indi
fere
nte
De
acue
rdo
Muy
de
acue
rdo
Pregunta 1 Ge.Me.Ev.01 X 2 Ge.Me.Ap.01 X 3 Ge.Me.An.01 X 4 Ge.Me.Ev.02 X 5 Ge.Me.Ev.03 X 6 Ge.Me.Si.01 X 7 Ge.Me.Si.02 X 8 Ge.Me.Ev.04 X
5. Haber reflexionado y respondido a la pregunta me permitió identificar aspectos de mi actuación en el
proyecto que considero deberé mejorar en una próxima instancia.
Muy
en
desc
uerd
o
En d
esac
uerd
o
Indi
fere
nte
De
acue
rdo
Muy
de
acue
rdo
Pregunta 1 Ge.Me.Ev.01 X 2 Ge.Me.Ap.01 X 3 Ge.Me.An.01 X 4 Ge.Me.Ev.02 X 5 Ge.Me.Ev.03 X 6 Ge.Me.Si.01 X 7 Ge.Me.Si.02 X 8 Ge.Me.Ev.04 X
6. En general, considero a las Guías de Reflexión como un instrumento útil para facilitar la reflexión sobre
mis conocimientos y mi actuación profesional.
Muy en desacuerdo En desacuerdo Indiferente X De acuerdo Muy de acuerdo
287
Cuestionario de Evaluación de las Guías de Reflexión – Métricas de Proyecto Proyecto: SCPI Nombre: Propósito: Recabar opinión acerca de las Guías de Reflexión como herramienta para facilitar la reflexión. 1. La lectura de la Guía de Reflexión en forma previa a la realización de mis tareas de proyecto me hubiera
permitido prepararme mejor para llevar a cabo esas tareas.
Muy en desacuerdo En desacuerdo Indiferente X De acuerdo Muy de acuerdo
2. La respuesta dada a cada pregunta estuvo directamente vinculada a mi experiencia personal adquirida
en el proyecto.
Muy
en
desc
uerd
o
En d
esac
uerd
o
Indi
fere
nte
De
acue
rdo
Muy
de
acue
rdo
Pregunta 1 Ge.Me.Ev.01 X 2 Ge.Me.Ap.01 X 3 Ge.Me.An.01 X 4 Ge.Me.Ev.02 X 5 Ge.Me.Ev.03 X 6 Ge.Me.Si.01 X 7 Ge.Me.Si.02 X 8 Ge.Me.Ev.04 X
288
3. La pregunta me instó a reflexionar detenidamente acerca de la respuesta a dar a la misma.
Muy
en
desc
uerd
o
En d
esac
uerd
o
Indi
fere
nte
De
acue
rdo
Muy
de
acue
rdo
Pregunta 1 Ge.Me.Ev.01 X 2 Ge.Me.Ap.01 X 3 Ge.Me.An.01 X 4 Ge.Me.Ev.02 X 5 Ge.Me.Ev.03 X 6 Ge.Me.Si.01 X 7 Ge.Me.Si.02 X 8 Ge.Me.Ev.04 X
4. Haber reflexionado y respondido a la pregunta me permitió identificar “brechas” en mis conocimientos
relativos a los temas abordados en las mismas.
Muy
en
desc
uerd
o
En d
esac
uerd
o
Indi
fere
nte
De
acue
rdo
Muy
de
acue
rdo
Pregunta 1 Ge.Me.Ev.01 X 2 Ge.Me.Ap.01 X 3 Ge.Me.An.01 X 4 Ge.Me.Ev.02 X 5 Ge.Me.Ev.03 X 6 Ge.Me.Si.01 X 7 Ge.Me.Si.02 X 8 Ge.Me.Ev.04 X
289
5. Haber reflexionado y respondido a la pregunta me permitió identificar aspectos de mi actuación en el
proyecto que considero deberé mejorar en una próxima instancia.
Muy
en
desc
uerd
o
En d
esac
uerd
o
Indi
fere
nte
De
acue
rdo
Muy
de
acue
rdo
Pregunta 1 Ge.Me.Ev.01 X 2 Ge.Me.Ap.01 X 3 Ge.Me.An.01 X 4 Ge.Me.Ev.02 X 5 Ge.Me.Ev.03 X 6 Ge.Me.Si.01 X 7 Ge.Me.Si.02 X 8 Ge.Me.Ev.04 X
6. En general, considero a las Guías de Reflexión como un instrumento útil para facilitar la reflexión sobre
mis conocimientos y mi actuación profesional.
Muy en desacuerdo En desacuerdo Indiferente X De acuerdo Muy de acuerdo
290
A3.10 Reporte de resultados del Taller de Educción de Conocimientos y Experiencia
Reporte del Taller de educción de conocimientos y experiencia Fecha: 27 / 08 / 2007 Lugar: Sala de reuniones 2do piso Hora inicio: 20:00 Hora fin: 21:00 Asistentes: Laura Rodríguez, Ana Estela, Gerardo Matturro (GCCA) Carlos Geribón [email protected] (Proyecto GESA) Andrés Lapachian [email protected] (Proyecto SCPI) Daniel Nicolich [email protected] (Proyecto COODESOR) 1. Planificación de la entrevista Previamente a la realización de la entrevista, informarse del negocio del cliente. Realizar una investigación previa del cliente y su dominio. Esto permitirá llegar a la entrevista con un mayor conocimiento y por lo tanto facilitará la comprensión de los problemas y necesidades del cliente. Si es posible, seleccionar a los entrevistados. En función de la información que se necesite relevar, seleccionar a las personas más adecuadas para brindar ese tipo de información. Realizar un listado de las preguntas a efectuar al entrevistado(s) y enviarla previamente a la entrevista. De esta forma el entrevistado tendrá conocimiento de los temas a tratar durante la entrevista y podrá prepararse para la misma y asegurarse de contar con toda la información necesaria para responder a las preguntas. Establecer el tiempo de duración de la entrevista. Fijar la hora de inicio y la hora de fin. Conocer la cantidad de entrevistados. Esto ayudara a determinar como organizar la entrevista y a determinar el tiempo que se necesitará para la misma. Elaborar un guión de la entrevista en base al número de entrevistados y a la duración determinada para la entrevista. Esto permitirá establecer un orden durante la entrevista y asegurarse de tratar todos los temas. Si en la entrevista participara más de un entrevistador, entonces presentarse frente a los entrevistados como un grupo, actuar de forma organizada y uniforme. Durante el desarrollo de la entrevista los entrevistadores deben dirigir su atención a muchos aspectos como son: los temas que se están abordando, la dinámica de la entrevista, aspectos del negocio, posibles necesidades del usuario. Por ello es muy importante grabar la entrevista de manera que la atención se centre en los aspectos clave y no se desvíe hacia el registro de los temas que se están desarrollando. Realizar acta de la entrevista inmediatamente después de efectuada la misma para no olvidar detalles o aspectos trabajados durante la entrevista. 2. Interacción con el entrevistado Conocer previamente el lenguaje del entrevistado. Saber si se va a entrevistar a un usuario final, el cual probablemente no maneje un vocabulario técnico, o si se entrevistará a un profesional del área de la tecnología de la Información que, por lo tanto, contara con un vocabulario más técnico. Esto facilitaría el dialogo durante la entrevista. Conocer previamente el negocio del cliente, como unidad de negocio y la empresa del cliente en particular. Cuando el entrevistado no tienen necesidades claras realizar un estudio de los procesos del negocio y de la empresa del cliente, esto permitirá identificar necesidades. Proponer soluciones a los problemas del usuario. El entrevistado informa sus problemas y el entrevistador propone soluciones, esto facilitará la identificación de requerimientos. 3. Habilidades personales del Ingeniero de Requerimientos Debe ser buen comunicador. Debe tener empatía, flexibilidad, capacidad de adaptarse al cliente (a sus tiempos, a su lenguaje, etc.). Debe tener habilidad para manejar el trato con el cliente. Debe tener habilidad para interactuar rápidamente con el cliente, para manejar el curso de la entrevista. Debe tener conocimiento de Ingeniería de Requerimientos y de Arquitectura. Debe tener capacidad analítica de los datos. Debe tener poder de negociación con el equipo de desarrollo. 4. Entrenamiento inicial del Ingeniero de Requerimientos Realizar una experiencia práctica y luego participar en un taller en el que se intercambien las experiencias de cada uno. El entrenamiento debería de estar organizado de tal forma de tener un 50% de teoría y un 50% de práctica. Durante el entrenamiento, poner énfasis en el proceso que se debe llevar a cabo para analizar la información relevada; es decir como realizar el análisis de dicha información.
291
A3.11 Cuestionarios de evaluación de Taller de educción de conocimientos y experiencia respondidos por los ingenieros de requisitos que asistieron al mismo
Cuestionario de Evaluación del Taller
Proyecto: Sistema de Gestión COODESOR Nombre: Daniel Nicolich Propósito: Recabar la opinión del participante sobre los siguientes tres aspectos del Taller de Educción de
Conocimientos:
• Organización (preguntas 1 a 4) • Participación (preguntas 5 a 8) • Contenido (pregunta 9)
1. Los objetivos del taller estuvieron claramente definidos.
Muy en desacuerdo En desacuerdo Indiferente
X De acuerdo Muy de acuerdo
2. La duración del taller fue adecuada.
Muy en desacuerdo En desacuerdo Indiferente De acuerdo
X Muy de acuerdo 3. El material recibido como insumo para la realización del taller fue satisfactorio en cuanto a su estructura y
contenido.
Muy en desacuerdo En desacuerdo Indiferente
X De acuerdo Muy de acuerdo
4. El lugar físico elegido para realizar el taller fue adecuado.
Muy en desacuerdo En desacuerdo
X Indiferente De acuerdo Muy de acuerdo
5. Valoro como muy positivo el haber podido conocer y discutir, durante el taller, las experiencias de los
otros participantes.
Muy en desacuerdo En desacuerdo Indiferente De acuerdo
X Muy de acuerdo
292
6. Con la participación en el taller considero que he aumentado mis conocimientos sobre los temas tratados
en el mismo.
Muy en desacuerdo En desacuerdo Indiferente
X De acuerdo Muy de acuerdo
7. Los conocimientos adquiridos en el taller me permitirán realizar un mejor desempeño en proyectos
futuros.
Muy en desacuerdo En desacuerdo Indiferente De acuerdo
X Muy de acuerdo 8. En general, considero que el taller fue una experiencia positiva.
Muy en desacuerdo En desacuerdo Indiferente De acuerdo
X Muy de acuerdo 9. De los cuatro temas tratados en el taller, el o los más interesantes fueron:
Muy
en
desc
uerd
o
En d
esac
uerd
o
Indi
fere
nte
De
acue
rdo
Muy
de
acue
rdo
Tema 1 Planificación de entrevistas X 2 Interacción con el entrevistado X 3 Habilidades personales del Ing. de Req. X 4 Entrenamiento inicial sobre Ing. de Req. X
Cuestionario de Evaluación del Taller
Proyecto: GESA Nombre: Carlos Geribón Propósito: Recabar la opinión del participante sobre los siguientes tres aspectos del Taller de Educción de
Conocimientos:
• Organización (preguntas 1 a 4) • Participación (preguntas 5 a 8) • Contenido (pregunta 9)
293
1. Los objetivos del taller estuvieron claramente definidos.
Muy en desacuerdo En desacuerdo Indiferente De acuerdo
Muy de acuerdo 2. La duración del taller fue adecuada.
Muy en desacuerdo En desacuerdo Indiferente De acuerdo
Muy de acuerdo 3. El material recibido como insumo para la realización del taller fue satisfactorio en cuanto a su estructura y
contenido.
Muy en desacuerdo En desacuerdo Indiferente De acuerdo
Muy de acuerdo 4. El lugar físico elegido para realizar el taller fue adecuado.
Muy en desacuerdo En desacuerdo Indiferente
De acuerdo Muy de acuerdo
5. Valoro como muy positivo el haber podido conocer y discutir, durante el taller, las experiencias de los
otros participantes.
Muy en desacuerdo En desacuerdo Indiferente De acuerdo
Muy de acuerdo 6. Con la participación en el taller considero que he aumentado mis conocimientos sobre los temas tratados
en el mismo.
Muy en desacuerdo En desacuerdo Indiferente
De acuerdo Muy de acuerdo
7. Los conocimientos adquiridos en el taller me permitirán realizar un mejor desempeño en proyectos
futuros.
Muy en desacuerdo En desacuerdo Indiferente
De acuerdo Muy de acuerdo
294
8. En general, considero que el taller fue una experiencia positiva.
Muy en desacuerdo En desacuerdo Indiferente De acuerdo
Muy de acuerdo 9. De los cuatro temas tratados en el taller, el o los más interesantes fueron:
Muy
en
desc
uerd
o
En d
esac
uerd
o
Indi
fere
nte
De
acue
rdo
Muy
de
acue
rdo
Tema 1 Planificación de entrevistas x 2 Interacción con el entrevistado x 3 Habilidades personales del Ing. de Req x 4 Entrenamiento inicial sobre Ing. de Req. x
Cuestionario de Evaluación del Taller
Proyecto: SCPI (Seguimiento y Control de Proyectos de Inversión) Nombre: Andrés Lapachian Propósito: Recabar la opinión del participante sobre los siguientes tres aspectos del Taller de Educción de
Conocimientos:
• Organización (preguntas 1 a 4) • Participación (preguntas 5 a 8) • Contenido (pregunta 9)
1. Los objetivos del taller estuvieron claramente definidos.
Muy en desacuerdo En desacuerdo Indiferente
X De acuerdo Muy de acuerdo
2. La duración del taller fue adecuada.
Muy en desacuerdo En desacuerdo Indiferente
X De acuerdo Muy de acuerdo
295
3. El material recibido como insumo para la realización del taller fue satisfactorio en cuanto a su estructura y
contenido.
Muy en desacuerdo En desacuerdo Indiferente De acuerdo
X Muy de acuerdo 4. El lugar físico elegido para realizar el taller fue adecuado.
Muy en desacuerdo En desacuerdo Indiferente
X De acuerdo Muy de acuerdo
5. Valoro como muy positivo el haber podido conocer y discutir, durante el taller, las experiencias de los
otros participantes.
Muy en desacuerdo En desacuerdo Indiferente
X De acuerdo Muy de acuerdo
6. Con la participación en el taller considero que he aumentado mis conocimientos sobre los temas tratados
en el mismo.
Muy en desacuerdo En desacuerdo Indiferente De acuerdo
X Muy de acuerdo 7. Los conocimientos adquiridos en el taller me permitirán realizar un mejor desempeño en proyectos
futuros.
Muy en desacuerdo En desacuerdo Indiferente
X De acuerdo Muy de acuerdo
8. En general, considero que el taller fue una experiencia positiva.
Muy en desacuerdo En desacuerdo Indiferente De acuerdo
X Muy de acuerdo
296
9. De los cuatro temas tratados en el taller, el o los más interesantes fueron:
Muy
en
desc
uerd
o
En d
esac
uerd
o
Indi
fere
nte
De
acue
rdo
Muy
de
acue
rdo
Tema 1 Planificación de entrevistas X 2 Interacción con el entrevistado X 3 Habilidades personales del Ing. de Req X 4 Entrenamiento inicial sobre Ing. de Req. X
297
A3.12 Resumen de reuniones del GGCA Fecha Inicio Fin Asuntos17/04 18:00 19:30 Reunión inicial de trabajo. Gerardo explica el proyecto de tesis doctoral, el propósito
y objetivos de la investigación, y aporta documentación sobre el estado de la cuestión, el problema planteado en la tesis y la versión preliminar del modelo “ele”.
24/04 18:00 19:00 Se discuten aspectos generales del modelo “ele”, la integración de sus fases y tareas a las actividades de los proyectos y se establece la manera en que se pretende llevar a cabo la implementación en ORTsf.
30/4 18:00 19:30 Se evacuan dudas y preguntas sobre los temas de la reunión anterior. Se decide relevar las características de los proyectos que inician este semestre para seleccionar aquellos que cumplan los criterios de ser de desarrollo software y que tengan que realizar en forma completa las actividades de ingeniería de requisitos y de gerenciamiento del proyecto.
4/5 18:30 20:15 Se inicia la discusión de las guías de reflexión y se explican la taxonomía de Bloom y el modelo de aprendizaje experiencial de Kolb Se seleccionan los cuatro proyectos sobre los cuales se implementará el modelo. Se decidió preguntar a los miembros de los equipos de estos proyectos si tienen algún inconveniente en participar de la investigación.
11/5 10:00 12:30 Ana y Laura plantean dudas respecto a la taxonomía de Bloom (es un tema desconocido para ambas). Se plantean algunos ejemplos de tipos de preguntas para clarificar los niveles de la taxonomía. Gerardo aporta una lista de palabras claves y de verbos que denotan acciones cognitivas para cada nivel. Se definió la estructura general que ha de tener el manual de implementación del modelo. Los miembros de los equipos de proyectos seleccionados manifestaron no tener inconvenientes en participar; de hecho, se mostraron interesados en la propuesta y aceptaron participar. Se les dejó en claro que este estudio no pretende interferir con sus propias actividades, pero que deben tomar las actividades como una más de las que deben realizar.
16/5 18:30 20:30 Se arma un primer borrador de la estructura de las guías de reflexión y se plantean algunas preguntas tentativas para ingeniería de requisitos. Se decide no incluir más de 8 o 10 preguntas bien concretas, de modo de cubrir todos los aspectos de interés pero sin que la guía sea tan grande que las personas se desalienten a responder. Laura y Ana consultarán al tutor de IR de ORTsf (como experto externo al GGCA) para su opinión sobre las preguntas que se están elaborando.
25/5 18:30 20:30 Se continuó con la elaboración de la guía para ingeniería de requisitos. El aporte del la visión del tutor de IR fue muy valioso para fijar las preguntas a incluir en la guía. Se definió el formato, el texto introductorio, a quienes contactar en caso de dudas, y se evaluaron y reelaboraron varias de las preguntas elaboradas en forma de borrador.
30/5 19:00 20:15 Se tiene la versión final de la guía para ingeniería de requisitos. Se evaluó como lo más difícil de este proceso el entender cómo usar los niveles de la taxonomía de Bloom. Se entendió que disponer de los verbos y de las palabras claves fue muy útil para la redacción de las preguntas. También se notó lo importante de conocer el tema para poder elaborar preguntas que sean significativas.
4/6 19:00 20:00 Se da por finalizada la guía para ingeniería de requisitos y se inicia la elaboración de la guía para métricas de gestión de proyecto. Ana y Laura comentan que haber confeccionado la guía anterior hace ahora más fácil preparar esta otra.
11/6 19:00 20:00 La guía de reflexión para métricas de gestión de proyecto está casi lista. Se consultará al tutor de ORTsf (como experto externo al GGCA) para obtener su opinión.
15/6 18:30 19:15 Se dio por finalizada la guía para métricas de gestión de proyectos. Se le incorporó una pregunta sobre entrenamiento inicial para gerentes de proyecto (a pedido del tutor de rol) y se decidió incorporar una pregunta similar a la guía para ingeniería de requisitos. Se preguntará a los grupos de proyecto quienes de sus integrantes realizan los roles de ingeniero de requisitos y de gerente de proyecto. Esto es necesario para la asignación de las guías a los miembros correctos.
24/6 Con las guías de reflexión terminadas, se planifican las sesiones de familiarización. Se buscará un lugar adecuado en la Facultad y se consultará a los futuros asistentes sobre la fecha y hora adecuadas. Las reuniones no pueden ir más allá de la primera semana de Julio. Se dio formato final uniforme a las guías para mejorar la presentación y el orden de las preguntas.
298
30/6 19:00 20:30 Se obtuvo consenso sobre la fecha de realización de las sesiones de familiarización. Se llevará a cabo una sesión conjunta para todos los participantes en la primera semana de Julio. Se les entregará una copia impresa de las guías y luego se les enviarán las mismas en formato electrónico para que puedan responder a las mismas directamente y luego revolverlas por correo electrónico. Se confecciona el formulario de evaluación de las guías. Se revisaron las preguntas que ya estaban definidas y se da formato adecuado al cuestionario.
4/7 20:00 21:15 Se realizó la reunión de familiarización. Asistieron integrantes de todos los grupos de proyecto: ingenieros de requisitos y gerentes, y también los miembros del GGCA. Se les solicitó devolver las guías completadas antes de finalizar el mes de Julio.
11/7 19:30 20:30 Se recibieron dos guías respondidas; se está a la espera de las demás. Se diseña el formulario de resumen de respuestas que facilitará el análisis de las mismas.
18/7 19:00 20:00 Se da por finalizado el diseño de los cuestionarios de evaluación de las guías. Se preparan las planillas para el resumen y análisis de los resultados del cuestionario.
8/8 19:00 19:45 Se tienen todas las guías de reflexión respondidas. Durante esta semana se procederá al análisis de las respuestas y a extraer de las mismas aquellos pasajes de interés para el estudio. Con la información extraída se confeccionará el resumen de respuestas. Se envía a los respondientes el cuestionario de evaluación de las guías.
15/8 19:00 21:00 Se inicia la preparación del taller de elicitación de conocimientos: temario, asistentes a invitar, dinámica que tendrá el taller. Se preparó la Guía para la realización del taller. El mismo se centrará en ingeniería de requisitos. Se finalizó el documento de resumen de respuestas a las guías. Se recibieron respondidos los cuestionarios de evaluación de las guías.
22/8 18:30 21:00 Se convino realizar el taller el día 27 de agosto en una sala de reuniones de la facultad. Se enviará mail a los participantes con el documento de resumen de respuestas para que cada uno pueda leerlo y conocer las reflexiones de los demás, antes de asistir al taller. Se procesaron los datos de los cuestionarios de evaluación de las guías de reflexión.
27/8 20:00 21:00 Realización del taller de elicitación de conocimientos y experiencias. Asistieron los ingenieros de requisitos de los grupos: Carlos Geribón (GESA), Daniel Nicolich (COODESOR) y Andrés Lapachian (SCPI). La representante del grupo InvPortal, Alicia Pino, no asistió por un problema personal. Por parte del GGCA asistieron Laura Rodríguez y Ana Estela, y también el autor en calidad de observador participante. El desarrollo del taller estuvo guiado por Laura Rodríguez, que actuó como moderadora, mientras que el registro de los aspectos relevantes de la discusión estuvo a cargo de Ana Estela. Siguiendo la Guía para la Realización del Taller, como actividad inicial se procedió a explicitar y comentar los objetivos del taller (paso 1 de la guía). A continuación, y como actividad disparadora (paso 2 de la guía), se solicitó a los representantes de los grupos de proyectos que leyeran y analizaran las respuestas y reflexiones dadas por los otros participantes y que identificaran las coincidencias y las discrepancias respecto de sus propias respuestas y reflexiones. Una vez finalizada esta actividad, se procedió a abrir la discusión grupal según el orden de temas definido en la Guía (paso 3 de la guía). Durante esta discusión, los ingenieros de requisitos contaron sus experiencias relacionadas a las actividades de proyecto incluidas en las guías de reflexión, expusieron las situaciones personales vividas que dieron origen a las respuestas dadas y discutieron las semejanzas y diferencias con las experiencias vividas por los demás. Concluida esta parte del taller, se realizó la evaluación de la discusión (paso 4 de la guía), en base a la cual se fue construyendo una respuesta consensuada a los cuatro temas inicialmente propuestos para el taller. Esta última actividad dio como resultado los insumos para confeccionar posteriormente el documento de conclusiones del taller con el resumen de las lecciones aprendidas y las propuestas de mejores prácticas identificadas.
3/9 18:30 21:00 Se elabora el reporte de los resultados del taller. Se evaluó como muy positiva la participación de los asistentes. Se envía por mail a los participantes el cuestionario de evaluación del taller.
10/9 18:30 21:30 Se recibieron respondidos los cuestionarios de evaluación del taller y se confeccionaron las planillas para procesarlos.
20/9 19:00 20:30 Se define la estructura del repositorio de lecciones aprendidas y de mejores prácticas. Se continuó elaborando el manual de implementación. Se decide incluir un capítulo o apéndice con la taxonomía de Bloom y detalles de cómo utilizarla en la elaboración de preguntas para las guías. También se incluirán los formularios de los cuestionarios utilizados.
299
27/9 19:00 20:00 Se ajusta estructura y contenido del manual de implementación. Se incluyen plantillas y ejemplos de las guías usadas en la implementación realizada.
3/10 19:00 19:30 Se solicita a los grupos de proyectos que remitan al GGCA los reportes de tiempos insumidos en actividades de ingeniería de requisitos, gerenciamiento de proyecto y tiempos totales de proyecto. Para el grupo SCPI se deberá esperar a fines de febrero para tener sus datos.
10/10 18:00 21:00 Se finaliza la elaboración del manual de implementación. Se hace la revisión general del proceso de implementación y de definen recomendaciones para una próxima implementación. En Octubre no inician nuevos proyectos en ORTsf, de modo que la próxima implementación se hará, de ser posible, a partir de abril de 2008, dependiendo de la cantidad y tipos de proyectos que eventualmente inicien en ese momento.
300
A3.13 Documentos de los grupos de proyecto participantes (extractos)
Se incluyen, a continuación, extractos de los documentos finales de los grupos de
proyecto participantes en el estudio. Estos extractos contienen los reportes de tiempos
insumidos por cada grupo en las actividades de ingeniería de requisitos, gerenciamiento del
proyecto y tiempos totales de cada proyecto.
La documentación completa de todos los proyectos se encuentra disponible en el
Servicio de documentación y biblioteca de la Universidad ORT Uruguay.
Universidad ORT Uruguay Facultad de Ingeniería
Sistema de Gestión COODESOR
Entregado como requisito para la obtención del título de Licenciado en Análisis de Sistemas de Información
Federico Gordillo - 121150 Daniel Nicolich - 61722
Alejandro Romero - 78096 Yairo Vettorello - 96472
Tutor: Leonardo Scafarelli
2007
3
ABSTRACT
Esta obra se enmarca en la realización del proyecto académico de fin de carrera de Licenciatura en Análisis de Sistemas de Información de la Facultad de Ingeniería de la Universidad ORT Uruguay.
En la misma se describe el proceso de producción del sistema informático denominado SGC (Sistema de Gestión COODESOR) aplicando conceptos y prácticas de la Ingeniería de Software. El destinatario final del sistema es COODESOR (Cooperativa Odontológica de Soriano), cooperativa de asistencia mutual odontológica con sede en la ciudad de Mercedes, capital del departamento de Soriano.
En este documento se encuentran explicadas todas las fases y actividades llevadas a cabo durante el proceso de producción. Las mismas incluyen actividades de relevamiento, gestión y desarrollo de las cuales se obtuvieron varios documentos y productos complementarios al producto final.
4
ÍNDICE
AGRADECIMIENTOS..............................................................................2
ABSTRACT..............................................................................................3
ÍNDICE .....................................................................................................4
CAPITULO 1 - INTRODUCCIÓN.............................................................9
1.1 PRESENTACIÓN DE SOFTWARE FACTORY ............................................9
1.2 INTRODUCCIÓN AL PROYECTO................................................................9 1.2.1 Motivación ....................................................................................................9 1.2.2 Propósito ......................................................................................................9 1.2.3 Descripción del Cliente.................................................................................9
1.3 PRESENTACIÓN DEL EQUIPO DE PROYECTO......................................10
1.4 ORGANIZACIÓN DEL DOCUMENTO........................................................11
CAPITULO 2 - DESCRIPCIÓN DEL PROYECTO.................................12
2.1 INTRODUCCIÓN ........................................................................................12
2.2 DESCRIPCIÓN GENERAL DEL PROYECTO............................................12 2.2.1 Alcance.......................................................................................................12 2.2.2 Descripción del cliente................................................................................12 2.2.3 Usuarios .....................................................................................................13 2.2.4 Alcance del proyecto ..................................................................................13 2.2.5 Resultados obtenidos .................................................................................14
2.3 DESCRIPCIÓN DEL GRUPO .....................................................................14
2.4 DESCRIPCIÓN DEL PROCESO UTILIZADO ............................................15 2.4.1 Narración del proceso ................................................................................15 2.4.2 Problemas y cambios .................................................................................16
CAPITULO 3 - INGENIERÍA DE REQUERIMIENTOS ..........................17
3.1 INTRODUCCIÓN ........................................................................................17 3.1.1 Estudio de Factibilidad ...............................................................................17 3.1.2 Obtención y Análisis de Requerimientos....................................................18 3.1.3 Validación de Requerimientos....................................................................19 3.1.4 Administración de Requerimientos.............................................................19
3.2 DESCRIPCIÓN DEL PROBLEMA..............................................................20 3.2.1 Descripción del Cliente...............................................................................20 3.2.2 El problema planteado por el cliente ..........................................................21 3.2.3 Factibilidad del proyecto.............................................................................21
5
3.3 ESTRATEGIA DE RELEVAMIENTO..........................................................22 3.3.1 Obtención y Análisis de Requerimientos....................................................22
3.3.1.1 Lista de elementos a relevar ....................................................................22 3.3.1.2 Entrevista con usuarios del sistema.........................................................22 3.3.1.3 Encuestas a los odontólogos ...................................................................23 3.3.1.4 Relevamiento directo del sistema actual de COODESOR ......................23
3.3.2 Seguimiento y validación de los requerimientos ........................................24 3.3.2.1 Validación de documentos por parte del cliente ......................................24 3.3.2.2 Generación de Prototipos ........................................................................24
3.4 ANALISIS DE LOS PROCESOS DEL CLIENTE........................................25
3.5 DESCRIPCION DEL SGC ..........................................................................27 3.5.1 Funcionalidades del SGC...........................................................................27
3.5.1.1 Gestión de Afiliados .................................................................................27 3.5.1.2 Gestión Odontológica...............................................................................27 3.5.1.3 Gestión Contable......................................................................................27 3.5.1.4 Gestión de Stocks ....................................................................................27 3.5.1.5 Otras Gestiones .......................................................................................27
3.5.2 Restricciones del sistema...........................................................................28 3.5.3 Requerimientos del sistema .......................................................................28
3.5.3.1 Requerimientos funcionales.....................................................................28 3.5.3.2 Requerimientos no funcionales................................................................29
3.5.4 Casos de uso..............................................................................................29 3.5.5 Criterio de priorización de requerimientos..................................................29
3.5.5.1 Importancia de los distintos procesos del cliente.....................................29 3.5.5.2 Elementos críticos del sistema actual ......................................................30 3.5.5.3 Precedencia de los casos de uso ............................................................30 3.5.5.4 Evaluación en base al cálculo de Puntos de Función..............................30 3.5.5.5 Dificultad aparente de los requerimientos................................................30
3.6 ANALISIS DE PROBLEMAS ENCONTRADOS.........................................31
CAPITULO 4 - DISEÑO ARQUITECTÓNICO .......................................33
4.1 INTRODUCCIÓN ........................................................................................33
4.2 SOLUCIÓN PARA EL SGC........................................................................33 4.2.1 Descripción de las principales tecnologías a utilizar ..................................33 4.2.2 Microsoft Visual Basic .NET (dot Net) ........................................................33
4.2.2.1 Características de la herramienta ............................................................33 4.2.2.2 Esquema de Arquitectura de la herramienta ...........................................34
4.2.3 Microsoft SQL Server Desktop Engine (MSDE) .........................................34 4.2.3.1 Características del MSDE 2000 ...............................................................34 4.2.3.2 Limitaciones del MSDE 2000 ...................................................................34
4.2.4 Diagramas de Clases del SGC...................................................................36 4.3 SOLUCIÓN PARA LA MIGRACIÓN DE DATOS .......................................47
4.3.1 Proceso de Migración de Datos .................................................................47 4.3.2 Microsoft Visual Basic 6 (Migración de datos)............................................47
4.3.2.1 Características de la herramienta ............................................................47 4.3.2.2 Limitaciones de la herramienta ................................................................47 4.3.2.3 Archivos generados..................................................................................48
4.3.3 Microsoft Visual FoxPro 6 (Migración de datos).........................................48 4.4 ESTRATEGIA DE DESARROLLO .............................................................49
4.5 DESVIACIONES SUFRIDAS AL PLAN ORIGINAL...................................49
4.6 PROBLEMAS SURGIDOS EN EL PROYECTO.........................................49
6
CAPITULO 5 - GESTIÓN DE LA CALIDAD..........................................50
5.1 INTRODUCCIÓN ........................................................................................50
5.2 ASEGURAMIENTO DE LA CALIDAD........................................................50 5.2.1 Actividades de SQA....................................................................................51
5.2.1.1 Actividades iniciales del proyecto ............................................................51 5.2.1.2 Actividades al inicio de cada nueva iteración ..........................................51 5.2.1.3 Actividades independientes de la fase.....................................................51 5.2.1.4 Fase 1: Relevamiento de Requerimientos y Análisis...............................51 5.2.1.5 Fase 2: Diseño .........................................................................................52 5.2.1.6 Fase 3: Construcción ...............................................................................52 5.2.1.7 Fase 4: Testing.........................................................................................52
5.2.2 Ciclo de SQA..............................................................................................53 5.2.3 Criterio de aprobación de los documentos .................................................53 5.2.4 Estándares y Normativas establecidos ......................................................53
5.3 PRODUCTOS RESULTANTES DE LAS ACTIVIDADES DE SQA............54 5.3.1 Plan de Calidad ..........................................................................................54 5.3.2 Reporte de Métricas ...................................................................................66 5.3.3 Plan de Testing y casos de prueba ............................................................66 5.3.4 Estándares y encuestas al cliente ..............................................................66
5.4 RESULTADOS DE LAS ACTIVIDADES DE SQA......................................67 5.4.1 Atributos de calidad del producto ESRE ....................................................67 5.4.2 Ausencia de defectos .................................................................................72 5.4.3 Cantidad de defectos por causa y tipo de error..........................................74
5.5 PRODUCTIVIDAD ......................................................................................76
5.6 CALIDAD DEL PROCESO DE DESARROLLO .........................................77 5.6.1 Medición y seguimiento del proceso ..........................................................77
5.7 SATISFACCIÓN DEL CLIENTE.................................................................80
5.8 LECCIONES APRENDIDAS.......................................................................81
CAPITULO 6 - SCM...............................................................................82
6.1 INTRODUCCION ........................................................................................82
6.2 DESCRIPCIÓN DEL PROCESO DE SCM .................................................83 6.2.1 Comunicación.............................................................................................83 6.2.2 Criterios de versionado...............................................................................83 6.2.3 Repositorio de componentes......................................................................84
6.3 PROBLEMAS ENCONTRADOS Y ACCIONES TOMADAS ......................86
CAPITULO 7 - GERENCIA....................................................................87
7.1 INTRODUCCIÓN ........................................................................................87
7.2 EFECTIVIDAD DE LA FUNCIÓN DE GERENCIA......................................88
7.3 PLAN DE PROYECTO ...............................................................................89 7.3.1 Alcance del proyecto ..................................................................................89 7.3.2 Accionistas .................................................................................................89
7.3.2.1 Cliente ......................................................................................................89 7.3.2.2 Equipo de desarrollo ................................................................................89
7
7.3.3 Requerimientos funcionales del producto ..................................................90 7.3.4 Requerimientos del sistema .......................................................................90 7.3.5 Actores del sistema ....................................................................................90 7.3.6 Medidas de éxito ........................................................................................90 7.3.7 Calendario ..................................................................................................90
7.3.7.1 Ciclo de Vida ............................................................................................90 7.3.8 WBS de tareas ...........................................................................................91 7.3.9 WBS de productos......................................................................................93 7.3.10 Cronograma................................................................................................94 7.3.11 Estimación ..................................................................................................95
7.3.11.1 Estimación en Puntos de función.............................................................95 7.3.11.2 Estimación en horas.................................................................................95 7.3.11.3 Horas estimadas vs Horas reales ............................................................96
7.4 ANALISIS DE RIESGOS ............................................................................97
7.5 RECURSOS................................................................................................98 7.5.1 Recursos Humanos ....................................................................................98 7.5.2 Recursos Materiales...................................................................................98
7.6 PRESUPUESTO .........................................................................................98 7.6.1 Costo x rol ..................................................................................................98 7.6.2 Horas x rol ..................................................................................................99
CAPITULO 8 - CONCLUSIONES........................................................100
8.1 CONCLUSIONES GENERALES ..............................................................100
8.2 RESUMEN DE PRODUCTOS RESULTANTES .......................................100
8.3 LECCIONES APRENDIDAS.....................................................................101
BIBLIOGRAFIA ...................................................................................102
ESTRUCTURA DEL CD ENTREGADO ..............................................103
ANEXO A - Documentos de Ingeniería de Requerimientos............104
A.1. Actividades de Relevamiento....................................................................105
A.2. Análisis de Procesos .................................................................................108
A.3. Encuesta a Odontólogos ...........................................................................107
A.4. Resultados de Encuesta ............................................................................108
A.5. Formularios de Relevamiento ...................................................................109
A.6. Resultados de Relevamiento.....................................................................110
A.7. Documento ESRE.......................................................................................111
ANEXO B - Documentos de Diseño y Arquitectura...................221112
B.1. Especificación de Arquitectura.................................................................113
8
B.2. Especificación de Diseño de Base de Datos ...........................................114
B.3. Precedencia de Casos de Uso...................................................................115
B.4. Especificación de Migración de Datos .....................................................116
ANEXO C - Documentos de Diseño y Arquitectura.........................117
C.1. Especificación de Convenciones..............................................................118
C.2. Plan de Testing...........................................................................................119
C.3. Encuesta de Satisfacción del Cliente .......................................................120
ANEXO D - Documentos de Gestión de Calidad .............................121
D.1. Estimaciones ..............................................................................................122
D.2. Documento COTA.......................................................................................123
D.3. Plan de Proyecto ........................................................................................124
D.4. Gestión de Riesgos ....................................................................................125
D.5. Planilla Reporte de Horas ..........................................................................126
D.6. Planilla de Gerente .....................................................................................127
ANEXO E - Manual de Usuario ..........................................................128
99
7.6.2 Horas x rol
Rol Horas
Gerente 95 SQA 67 Arquitecto 82 Analista 372 Desarrollador, SCM. Tester 756 TOTAL 1371
Hor
as Gerente
SQA
Arquitecto
Analista
Desarrollador, SCM. Te...
Total
0200400600800
100012001400
Horas x Rol
El costo final del proyecto asciende a la suma de U$S 12.323
Universidad ORT Uruguay Facultad de Ingeniería
GESA - Sistema de Gestión de Acreditaciones
Entregado como requisito para la obtención del título de Licenciado en Análisis de Sistemas de Información
Ricardo Leite - 137495 Rodrigo Robaina - 136850 Carlos Geribón - 136776
Tutora: Lic. Amalia Álvarez
2007
Sistema de Gestión de Acreditaciones
2
Abstract
El sistema GESA fue realizado como proyecto de grado para la carrera Licenciatura en Análisis de Sistemas de Información de la Facultad de Ingeniería de la Universidad ORT Uruguay, dentro del marco académico del Laboratorio de Ingeniería de Software.
El equipo de tres estudiantes de la generación 2002, conformado por Ricardo Leite, Carlos Geribón y Rodrigo Robaina fue el encargado de llevar a cabo el proyecto, con el apoyo de la tutora Lic. Amalia Álvarez de ORTsf.
El presente documento tiene como cometido describir el proceso utilizado para llevar a cabo la creación del sistema, de modo de permitirle al lector comprender la forma en que se trabajó.
El documento está enfocado a la Ingeniería de Software y se apoya en los procesos de está para las distintas fases del proyecto como ser Ingeniería de Requerimientos, Análisis y Diseño, Gestión de Configuración y Cambios, Gestión de Calidad y Gerencia.
Sistema de Gestión de Acreditaciones
3
Índice
1. GLOSARIO........................................................................................................................... 5
2. INTRODUCCIÓN.................................................................................................................. 6
2.1. ENTORNO CONCEPTUAL DE SOFTWARE FACTORY Y SUS OBJETIVOS.................................. 6 2.2. INTRODUCCIÓN AL PROYECTO ......................................................................................... 6
3. DESCRIPCIÓN DEL PROYECTO ....................................................................................... 7
3.1. INTRODUCCIÓN............................................................................................................... 7 3.2. DESCRIPCIÓN GENERAL DEL PROYECTO........................................................................... 8 3.3. ALCANCE DEL PROYECTO................................................................................................ 9 3.4. LIMITACIONES .............................................................................................................. 10 3.5. DESCRIPCIÓN DEL GRUPO............................................................................................. 10 3.6. DESCRIPCIÓN DEL PROCESO UTILIZADO ......................................................................... 11
4. INGENIERÍA DE REQUERIMIENTOS............................................................................... 15
4.1. INTRODUCCIÓN............................................................................................................. 15 4.2. DESCRIPCIÓN DEL PROBLEMA ....................................................................................... 15 4.3. CLIENTES Y USUARIOS ................................................................................................. 19 4.4. DESCRIPCIÓN DEL SISTEMA DE SOFTWARE..................................................................... 21 4.5. ESTRATEGIA DE RELEVAMIENTO .................................................................................... 24 4.6. ANÁLISIS DE LAS DIFICULTADES DURANTE EL RELEVAMIENTO .......................................... 25 4.7. ESPECIFICACIÓN DE REQUERIMIENTOS .......................................................................... 26 4.8. REQUERIMIENTOS NO IMPLEMENTADOS ......................................................................... 27
5. DISEÑO ARQUITECTÓNICO ............................................................................................ 31
5.1. INTRODUCCIÓN............................................................................................................. 31 5.2. DESCRIPCIÓN DE LA SOLUCIÓN...................................................................................... 31 5.3. ESTRATEGIA DE DESARROLLO ....................................................................................... 48
6. AMBIENTE DE DESARROLLO......................................................................................... 49
6.1. INTRODUCCIÓN............................................................................................................. 49 6.2. HERRAMIENTAS UTILIZADAS PARA EL DESARROLLO......................................................... 49
7. TESTING ............................................................................................................................ 50
7.1. INTRODUCCIÓN............................................................................................................. 50 7.2. DEFINICIÓN DEL PLAN DE TESTING ................................................................................ 50 7.3. ESTRATEGIA DE TESTING.............................................................................................. 50 7.4. MODALIDADES DE TESTING ........................................................................................... 53 7.5. CASOS DE PRUEBAS ..................................................................................................... 54 7.6. RESULTADOS DE LAS PRUEBAS ..................................................................................... 55
8. SQA .................................................................................................................................... 56
8.1. INTRODUCCIÓN............................................................................................................. 56 8.2. ENFOQUE DE CALIDAD.................................................................................................. 56 8.3. CALIDAD DEL PRODUCTO .............................................................................................. 56 8.4. PRODUCTOS RESULTANTES DE LA ACTIVIDAD DE SQA.................................................... 64 8.5. CALIDAD DEL PROCESO DE DESARROLLO ....................................................................... 67 8.6. MÉTRICAS.................................................................................................................... 67
9. SCM.................................................................................................................................... 70
9.1. INTRODUCCIÓN............................................................................................................. 70 9.2. DESCRIPCIÓN Y JUSTIFICACIÓN DEL PROCESO DE SCM.................................................. 70 9.3. PRODUCTOS RESULTANTES DE LA ACTIVIDAD DE SCM ................................................... 71 9.4. SELECCIÓN DE LA HERRAMIENTA SVN........................................................................... 72 9.5. PROBLEMAS ENCONTRADOS Y ACCIONES TOMADAS DURANTE LA EJECUCIÓN DE LA
ACTIVIDAD ................................................................................................................................. 72
Sistema de Gestión de Acreditaciones
4
10. GERENCIA......................................................................................................................... 74
10.1. INTRODUCCIÓN............................................................................................................. 74 10.2. PROCESO DE GERENCIA................................................................................................ 75 10.3. ACTIVIDADES................................................................................................................ 75 10.4. AVANCE DE FASES...................................................................................................... 100 10.5. MÉTRICAS RESULTANTES DEL PROCESO ...................................................................... 104
11. CONCLUSIONES............................................................................................................. 115
12. BIBLIOGRAFÍA................................................................................................................ 116
13. ESTRUCTURA DE LA DOCUMENTACIÓN EN CD ....................................................... 118
14. ANEXOS........................................................................................................................... 119
14.1. ANEXO 1: ATRIBUTOS DE CALIDAD PARA EL ESRE ....................................................... 120 14.2. ANEXO 2: ATRIBUTOS DE CALIDAD PARA LA DOCUMENTACIÓN ....................................... 122 14.3. ANEXO 3: ATRIBUTOS DE CALIDAD PARA LA CODIFICACIÓN............................................ 124 14.4. ANEXO 4: ATRIBUTOS DE CALIDAD PARA LA ARQUITECTURA .......................................... 125 14.5. ANEXO 5: PLAN DE V&V ............................................................................................. 126 14.6. ANEXO 6: PLAN DE TESTING........................................................................................ 130 14.7. ANEXO 7: JUSTIFICACIÓN DEL PLAN DE CALIDAD.......................................................... 135 14.8. ANEXO 8: ESPECIFICACIÓN DE REQUERIMIENTOS ......................................................... 136 14.9. ANEXO 9: REQUERIMIENTOS FUNCIONALES DETALLADOS.............................................. 150 14.10. ANEXO 10: ELECCIÓN DEL CICLO DE VIDA .................................................................... 162 14.11. ANEXO 11: DIAGRAMA DE ACTIVIDAD ........................................................................... 165 14.12. ANEXO 12: GUÍA PARA ENTREVISTAS........................................................................... 168 14.13. ANEXO 13: ACTA DE REUNIÓN CON CLIENTE................................................................. 171 14.14. ANEXO 14: EVALUACIÓN DEL MANEJADOR DE BASE DE DATOS ...................................... 173 14.15. ANEXO 15: PLANILLA DE DETECCIÓN Y SEGUIMIENTO DE ERRORES................................ 178 14.16. ANEXO 16: PLAN DE CALIDAD...................................................................................... 179 14.17. ANEXO 17: ESTÁNDAR DE CODIFICACIÓN ..................................................................... 182 14.18. ANEXO 18: PLANILLA DE CONTACTO ............................................................................ 186 14.19. ANEXO 19: PLANILLA DE COSTOS HORA POR ROL ......................................................... 187 14.20. ANEXO 20: ANÁLISIS DE RIESGOS ............................................................................... 188 14.21. ANEXO 21: CRONOGRAMA INICIAL ............................................................................... 206 14.22. ANEXO 22: CRONOGRAMA REAL.................................................................................. 208 14.23. ANEXO 23: PLANILLA DE TAREAS................................................................................. 210 14.24. ANEXO 24: PLANIFICACIÓN DESARROLLO - ESTIMADO................................................... 211 14.25. ANEXO 25: PLANIFICACIÓN DESARROLLO - REAL .......................................................... 213 14.26. ANEXO 26: PLAN DE SCM .......................................................................................... 215 14.27. ANEXO 27: OPCIONES DE HOSTING ............................................................................. 220 14.28. ANEXO 28: PROTOTIPOS............................................................................................. 221
Sistema de Gestión de Acreditaciones
113
10.5.4. Costo del proyecto
Descripción
A continuación se podrá visualizar lo correspondiente al costo total del proyecto en dólares americanos, discriminado por rol. Los valores hora fueron proporcionados por ORTsf.
Datos
Rol Costo / Hora
Cantidad de horas TOTAL
Gerente 15 204,3 3064,5 SQA 10 70,5 705 IR 8 232,8 1862,4 SCM 8 28,5 228 Arquitectura 15 111,5 1672,5 Tester 8 106,5 852 Desarrollo 8 461,6 3692,8 Tutor 30 46 1380
Tabla 18: Valores hora, cantidad de horas y costo total por rol
Gráfico 20: Distribución de los costos del proyecto por rol
Análisis
La actividad que representó una mayor inversión fue el desarrollo. Esto era esperado dadas las características del proyecto.
Alicia María Pino -137445 Alejandra Gabriela Pera -126530
Alicia Claudia Pereira -134021 Tutor: Mariana Lasarte
2007
Universidad ORT Uruguay
Facultad de Ingeniería
InvPortal: sitio Web de
Oficina de Desarrollo Sector Privado
Ministerio de Economía y Finanzas (MEF)
Entregado como requisito para la obtención del título de
Licenciado en Análisis de Sistemas de Información
Proyecto InvPortal Universidad ORT Uruguay – Software Factory
Entrega_InvPortal 3
Abstract Dentro del Plan de Estrategia 2005 – 2010 del Gobierno Nacional, y en lo vinculado al Clima de Negocios y Competitividad del país, se creó la Unidad de Promoción de la Inversión y Desarrollo del Sector en el Sector Privado dependiente del Ministerio de Economía y Finanzas (MEF), presentada en diciembre de 2006, con la Misión de asesorar, proponer, implementar y facilitar la coordinación de políticas y acciones que mejoren el clima de negocios y favorezcan el desarrollo del sector privado y la inversión productiva. Con el compromiso de desarrollar, como política de calidad, procesos que promuevan la mejora continua en un marco de transparencia con la prioridad de brindar información calificada a inversores y suministrar información de soporte, presentó en un punto de su agenda la creación de un sitio Web en dos fases (la primera de carácter informativo y de consolidación de la información de inversores, y la segunda, con carácter transaccional y de interacción con el inversor), surgiendo la propuesta de desarrollar el InvPortal: Sitio Web para la Oficina de Desarrollo Sector Privado – MEF. Con estos antecedentes, el InvPortal como proyecto es propuesto por el Ing. Bruno Delgado, encargado de la Oficina Desarrollo del Sector Privado, a la Universidad ORT, concretamente a ORT Software Factory (Laboratorio reingeniería Software). El objetivo del Invportal fue desarrollar un sitio Web, cuyas características derivaron del trabajo de investigación del estado de la práctica y del arte, así como de un trabajo de Ingeniería de Requerimientos adecuado al proyecto. La motivación del proyecto fue aprender y desarrollar las particularidades del diseño y desarrollo web, con la importancia y significado del tema hoy en día así como tomar conocimiento de los temas referentes al Gobierno Electrónico. Se decidió “dividir” al proyecto en dos grandes etapas: una primera etapa en la cual las tareas más importantes y destacadas fueran la investigación, capacitación y requerimientos, y una segunda donde lo primordial fuera el análisis, diseño e implementación del Sitio. Sin perjuicio de esta división, las tareas se fueron realizando a lo largo de todo el proyecto con mayor o menor dedicación de tiempo, según las necesidades, a veces superponiéndose y en todo momento complementándose unas con otras. Al terminar la primera etapa (sobre todo en lo referente a la investigación), se elaboró el producto de la investigación (conclusiones) y un conocimiento cabal de las funcionalidades y características que tendría luego el producto final (el sitio Web). En la segunda etapa se comenzó a avanzar en la implementación del Sitio, codificando, implementando las diferentes funcionalidades, así como también comenzó a cobrar importancia la tarea de testing. En esta segunda etapa, cada integrante tuvo a su cargo diferentes funcionalidades principales que fue implementando, codificando y testeando, para luego unificarlas, para ser mostradas al cliente para su aprobación o desaprobación. Cabe aclarar que el cliente acompañó en casi todo el desarrollo del proyecto (excepto en un corto período que estuvo de viaje), aportando ideas, conceptos, sugerencias para la investigación y validando o solicitando cambios en el producto en esa segunda etapa, que culminó con la entrega del sitio Web plenamente funcionante1. El producto final no solo cumplió con las expectativas y requerimientos planteados por el cliente, al igual que con las del equipo de proyecto, sino que además en algunos casos fueron superadas debido al agregado de algunas funcionalidades (Ej.: Google Analytics que
1 El sitio Web, si bien está plenamente funcionante, e instalado en el servidor proporcionado por el MEF, necesita una etapa final de prueba de stress (acto de asegurar que el sistema funciona como se espera bajo grandes volúmenes de transacciones, usuarios, carga y demás) que queda fuera del alcance del presente proyecto.
Proyecto InvPortal Universidad ORT Uruguay – Software Factory
Entrega_InvPortal 4
es un servicio de monitoreo de estadísticas de Google) y características (Ej.: que el publicador pueda manejar todo tipo de documentos) que le aportan al producto un valor agregado importante.
Proyecto InvPortal Universidad ORT Uruguay – Software Factory
Entrega_InvPortal 5
Índice
AGRADECIMIENTOS ................................................................................................ 2
ABSTRACT .............................................................................................................. 3
ÍNDICE ................................................................................................................... 5
1. INTRODUCCIÓN ............................................................................................. 9
1.1 Introducción al proyecto ................................................................................ 9 1.1.1 Antecedentes ........................................................................................... 9 1.1.2 Objetivos y Alcance ............................................................................... 10 1.1.3 Cliente, usuarios y equipo ...................................................................... 11
1.2 Descripción de la organización del documento ............................................. 11
2. DESCRIPCIÓN DEL PROYECTO ...................................................................... 13
2.1 Introducción a la sección ............................................................................. 13
2.2 Descripción general del proyecto ................................................................. 13
2.3 Alcance del proyecto .................................................................................... 14
2.4 Descripción del equipo ................................................................................. 15 2.4.1 Descripción de la forma de trabajo del grupo ......................................... 16
2.5 Descripción del proceso utilizado y Ciclo de Vida ......................................... 16
3. INGENIERÍA DE REQUERIMIENTOS .............................................................. 20
3.1 Introducción a la sección ............................................................................. 20
3.2 Descripción de problemas a resolver ............................................................ 20
3.3 Clientes y Usuarios ....................................................................................... 20 3.3.1 Cliente ................................................................................................... 20 3.3.2 Usuarios ................................................................................................ 21
3.4 Requerimientos ............................................................................................ 21 3.4.1 Requerimientos Funcionales .................................................................. 22 3.4.2 Requerimientos No Funcionales ............................................................. 22
3.5 Estrategia de Relevamiento .......................................................................... 24 3.5.1 Técnicas de relevamiento utilizadas ....................................................... 25 3.5.2 Validación de los requerimientos ........................................................... 25 3.5.3 Productos resultantes de la etapa .......................................................... 25
4. INVESTIGACIÓN DE PORTALES .................................................................... 27
4.1 Introducción a la sección ............................................................................. 27 4.1.1 Antecedentes ......................................................................................... 27
Proyecto InvPortal Universidad ORT Uruguay – Software Factory
Entrega_InvPortal 6
4.2 La investigación ........................................................................................... 28 4.2.1 Los comienzos… .................................................................................... 28 4.2.2 Planilla de Comparación de Sitios .......................................................... 28 4.2.3 Registro de sitios ................................................................................... 30 4.2.4 Finalizando la investigación ................................................................... 31
4.3 Números resultantes .................................................................................... 31 4.3.1 Respecto al proyecto ............................................................................. 31 4.3.2 Respecto de la tarea de Investigación .................................................... 32 4.3.3 Respecto de lo investigado y registrado ................................................. 33
4.4 Conclusiones particulares ............................................................................ 34 4.4.1 Página de inicio, de Bienvenida .............................................................. 34 4.4.2 Cabezales .............................................................................................. 36 4.4.3 Menú de recursos .................................................................................. 40 4.4.4 Ruta de Acceso ...................................................................................... 43 4.4.5 Pie de Página ......................................................................................... 44 4.4.6 Página Principal o de Contenidos ........................................................... 45 4.4.7 Mapa del Sitio ........................................................................................ 49 4.4.8 Publicadores de Documentos ................................................................. 51 4.4.9 Buscadores ............................................................................................ 55
4.5 Conclusiones generales de la Investigación ................................................. 58
5. DISEÑO ARQUITECTÓNICO .......................................................................... 59
5.1 Introducción a la sección ............................................................................. 59
5.2 Descripción de la solución ............................................................................ 59 5.2.1 Restricciones y Características de Calidad .............................................. 59 5.2.2 Descripción y Justificación de la arquitectura seleccionada .................... 62
5.2.2.1 Diagrama de Arquitectura ................................................................... 62 5.2.2.2 Arquitectura de red ............................................................................. 64 5.2.2.3 Persistencia del Sitio ........................................................................... 65
5.2.3 Tecnología utilizada ............................................................................... 66 5.2.4 Fundamentación de la Arquitectura seleccionada ................................... 67
5.3 Estrategia de Desarrollo ............................................................................... 68 5.3.1 Plan de versiones y su justificación ........................................................ 68 5.3.2 Herramientas y ambientes utilizados para el desarrollo ......................... 68
6. IMPLEMENTACIÓN ....................................................................................... 71
6.1 Introducción a la sección ............................................................................. 71
6.2 Estrategia de desarrollo ............................................................................... 71
6.3 Principales componentes implementados..................................................... 71 6.3.1 Iteración 1............................................................................................. 71 6.3.2 Iteración 2............................................................................................. 71 6.3.3 Iteración 3............................................................................................. 72 6.3.4 Iteración 4............................................................................................. 72 6.3.5 Iteración 5............................................................................................. 72
6.4 Prototipos realizados ................................................................................... 72
Proyecto InvPortal Universidad ORT Uruguay – Software Factory
Entrega_InvPortal 7
6.5 Pruebas unitarias realizadas ........................................................................ 72
6.6 Análisis de las dificultades y las acciones tomadas ...................................... 74
7. GESTIÓN DE CALIDAD .................................................................................. 75
7.1 Introducción a la sección ............................................................................. 75
7.2 Aseguramiento de la calidad del producto .................................................... 75
7.3 Productos resultantes de la actividad de SQA .............................................. 75 � Tareas de Calidad ..................................................................................... 75 � Métodos de Análisis .................................................................................. 76 � Tareas de Revisión ................................................................................... 76
7.4 Ciclo SQA-SCM .............................................................................................. 77
7.5 Resultados de las actividades de SQA .......................................................... 78 7.5.1 De documentación ................................................................................. 78 7.5.2 De la Estructura del Sitio ....................................................................... 78 7.5.3 De la Estructura de la Base de Datos ...................................................... 78 7.5.4 De las Funcionalidades .......................................................................... 79
7.6 Calidad del proceso de desarrollo ................................................................. 79 7.6.1 Justificación del Plan de Calidad ............................................................ 79 7.6.2 Medición y seguimiento del proceso ....................................................... 80
7.6.2.1 Atributos de Calidad del producto ....................................................... 81 7.6.2.2 Cantidad de Problemas de Módulos por Testing ................................... 81 7.6.2.3 Cantidad de Problemas por Causa ....................................................... 81 7.6.2.4 Cantidad de Problemas por Testing en el tiempo ................................. 82 7.6.2.5 Horas de Calidad ................................................................................. 83
7.6.3 Testing .................................................................................................. 84 7.6.3.1 Estrategia de pruebas ......................................................................... 84 7.6.3.2 Principales tipos de testing realizados ................................................ 85 7.6.3.3 Origen de Casos de prueba .................................................................. 85 7.6.3.4 Estado del producto / resultado de la etapa de pruebas ...................... 85
7.7 Efectividad de la gestión .............................................................................. 86
8. SCM (SOFTWARE CONFIGURATION MANAGEMENT) ..................................... 87
8.1 Introducción a la sección ............................................................................. 87
8.2 Proceso de SCM utilizado ............................................................................. 87 8.2.1 Actividades del LSCM ............................................................................. 87 8.2.2 Integración del código ........................................................................... 87 8.2.3 Ciclo de Control de Cambios (CCC) ......................................................... 88
8.3 Productos resultantes de las actividades de SCM ......................................... 89 8.3.1 Descripción del Repositorio ................................................................... 89 8.3.2 Estructura del Repositorio ..................................................................... 89 8.3.3 Versionado ............................................................................................ 90
8.4 Problemas encontrados y acciones tomadas ................................................ 90
Proyecto InvPortal Universidad ORT Uruguay – Software Factory
Entrega_InvPortal 8
9. GERENCIA .................................................................................................... 91
9.1 Introducción a la sección ............................................................................. 91
9.2 Proceso de Gerencia ..................................................................................... 91 9.2.1 Explicando Scrum y su “adaptación” ...................................................... 91 9.2.2 Planificación de actividades ................................................................... 92 9.2.3 Reporte de Esfuerzo .............................................................................. 93
9.2.3.1 Esfuerzo acumulado por tarea ............................................................. 94 9.2.3.2 Esfuerzo total por tipo de tarea ........................................................... 95 9.2.3.3 Esfuerzo total del equipo .................................................................... 96 9.2.3.4 Distribución del esfuerzo por tipo de tareas ........................................ 97
9.2.4 Mecanismos grupales de trabajo ............................................................ 99
9.3 Desarrollo de la función de Gerencia ............................................................ 99 9.3.1 Estimaciones realizadas ......................................................................... 99 9.3.2 Iteraciones y principales hitos del proyecto – Cronograma .................. 100 9.3.3 Ajustes realizados al Cronograma ........................................................ 102
9.4 Descripción de riesgos y actividades de prevención ................................... 103 9.4.1 Gestión de riesgos ............................................................................... 103 9.4.2 Ocurrencia de Riesgos ......................................................................... 104 9.4.3 Análisis de los principales Riesgos ....................................................... 104
9.5 Resultado de métricas, decisiones tomadas ............................................... 105
9.6 Análisis de la Gestión de Gerencia .............................................................. 106
10. CONCLUSIONES .......................................................................................... 108
11. BIBLIOGRAFÍA ........................................................................................... 109
12. ESTRUCTURA DE LA DOCUMENTACIÓN EN CD ............................................ 110
13. ANEXOS ...................................................................................................... 111
Proyecto InvPortal Universidad ORT Uruguay – Software Factory
Entrega_InvPortal 93
En cuanto a la planificación de la ejecución de las actividades, la misma se mantuvo en dependencia del número de integrante ya que al conformar un equipo poco numeroso, la responsabilidad se convirtió en el factor dominante. En este sentido se propuso la realización de actividades en conjunto y con la supervisión de un responsable. En el caso particular del diseño y desarrollo, se designó al propio equipo como responsable por tratarse de actividades enteramente implicadas en el funcionamiento del producto para lo cual lo más conveniente era igualar la responsabilidad.
Roles Responsable Gerencia Alicia C. Pereira SCM
Alicia M. Pino Arquitectura Ing. de Reqs.
Alejandra G. Pera SQA Diseño - Desarrollo El equipo
En cuanto a las actividades semanales, en las reuniones se marcaban las actividades concretas que se debían realzar, elaborando una lista informal (en el sentido de que no se documentaba propiamente) y se dividían las mismas según las características de las mismas entre las integrantes del equipo.
9.2.3 Reporte de Esfuerzo Para poder realizar los cálculos del esfuerzo del equipo se elaboró una planilla de horas (ver Anexo XIV – Reporte de Horas y Gráficas Gerenciales) para llevar el registro de la cantidad de horas invertidas por cada integrante en las distintas tareas del proceso del proyecto: Capacitación (tanto cursos dictados por de ORT Software Factory, como la particular que hacía cada integrante y que luego era transmitida al resto del equipo), Investigación, Requerimientos, Análisis, Diseño, Implementación, Testing, Documentación y Reuniones (solo del equipo, con el tutor, con el cliente, y en algunas oportunidades con personal de ORT Software Factory). Ejemplo de planilla individual:
Al final de cada quincena, cada integrante le enviaba el reporte de las horas a la gerencia, para reunir los datos y luego poder hacer los cálculos. En base a los datos de las planillas individuales, reuniendo los datos de las integrantes del equipo, se acumulaban los datos por quincena y por mes, para el equipo.
Proyecto InvPortal Universidad ORT Uruguay – Software Factory
Entrega_InvPortal 94
Tareas Abril Mayo Junio Julio Agosto Set Totales
(horas del equipo) Capacitación 18 33 27 2 0 80 Investigación 140 174 138 82 0 534 Requerimientos 0 5 14 8 0 27 Análisis 0 0 22 26 0 48 Diseño 0 0 10 13 21 44 Implementación 0 0 23 107 260 390 Testing 0 0 6 0 32 38 Documentación 0 9 29 43 52 133 Reuniones 36 44 26 36 44 186
Total 194 265 295 317 409 1480 A partir de estas acumulaciones, se calculó el esfuerzo real del equipo.
9.2.3.1 Esfuerzo acumulado por tarea45
Se graficaron las horas acumuladas para cada tarea en los meses en los cuales se desarrolló el proyecto.
Esfuerzo acumulado por tarea
0
20
40
60
80
100
120
140
160
180
200
220
240
260
280
Abril Mayo Junio Julio Agosto
Meses
Ho
ras
Capacitación
Investigación
Requerimientos
Análisis
Diseño
Implementación
Testing
Documentación
Reuniones
En este gráfico se puede observar, que en los primeros meses del proceso, las tareas que implicaban mayor carga horaria eran las de Capacitación y sobre todo la Investigación. A medida que fue pasando el tiempo, comienza a cobrar importancia la tarea de Implementación.
45 Es válido aclarar, que en las gráficas que serán mostradas en esta documentación, no se verá relejado el mes de setiembre, ya que por faltar la última quincena (utilizada sobre todo para preparar esta documentación), no se hicieron los cálculos pertinentes.
Universidad ORT Uruguay Facultad de Ingeniería
SCPI: Seguimiento y Control de Proyectos de Inversión
Entrega Proyecto Final
Entregado como requisito para la aprobación del título de Ingeniero en Sistemas
Andrés Lapachian - 130136 Felipe Herrera - 139116 Matías Núñez - 133512 Sergio Gambini - 138921 Federico Fontes - 138924
Tutor: Mariel Feder
2008
3
Abstract
El proyecto SCPI se lleva a cabo como requisito de la carrera Ingeniería en Sistemas de la Universidad ORT Uruguay.
La Unidad de Desarrollo del Sector Privado es una oficina dentro del Ministerio de
Economía y Finanzas que se encarga de la administración y el seguimiento de los inversores y proyectos de inversión que se llevan a cabo en el país. El proyecto surge a partir de las necesidades de dicha oficina de contar con una herramienta informática integral que facilite la gestión y monitoreo de la cartera de proyectos e inversores y permita modelar los flujos que siguen dichas entidades dentro de la oficina.
En la sección de Descripción General se describen las características principales del
proyecto, cuáles son los objetivos y la motivación para realizar el mismo. Se presenta al grupo de desarrollo y el proceso utilizado.
La sección de Ingeniería de Requerimientos describe como se llevó a cabo el proceso de
relevamiento de requerimientos, las herramientas y metodologías utilizadas. Se presenta una breve descripción del negocio de la oficina y las principales funcionalidades y restricciones del sistema.
En la sección de Investigación de Herramientas se presenta el trabajo realizado por el
equipo en la búsqueda de distintas tecnologías que se adecuen a los requerimientos planteados. Se detallan los diferentes temas de investigación, las herramientas candidatas y las seleccionadas.
La sección de Diseño Arquitectónico detalla las características de diseño del sistema a
construir, detallando las justificaciones de las decisiones arquitectónicas más relevantes y mostrando el trabajo realizado para construir un producto que cumpla con las características especificadas.
Las secciones de Gestión de la Calidad, Gestión de la Configuración y Gerencia
describen las actividades realizadas en cada una de las áreas durante todo el proceso. Al final de documento se detallan las conclusiones más importantes que el equipo destaca
luego de esta experiencia y se agrupan algunos anexos que permiten profundizar en cada uno de los temas expuestos.
4
Índice
1 GLOSARIO ....................................................................................................................................................... 6
2 DESCRIPCIÓN GENERAL ............................................................................................................................ 7
2.1 ENTORNO DEL PROYECTO ........................................................................................................................... 8 2.2 MOTIVACIÓN .............................................................................................................................................. 9 2.3 PRINCIPALES OBJETIVOS ............................................................................................................................ 9 2.4 COMPLEJIDAD DEL PROYECTO .................................................................................................................. 10 2.5 CLIENTES Y USUARIOS .............................................................................................................................. 11 2.6 INTEGRANTES DEL EQUIPO ........................................................................................................................ 11 2.7 PROCESO DE DESARROLLO ........................................................................................................................ 12
2.7.1 Descripción ......................................................................................................................................... 12 2.7.2 Principales dificultades....................................................................................................................... 13
3 INGENIERÍA DE REQUERIMIENTOS...................................................................................................... 14
3.1 ESTRATEGIA DE RELEVAMIENTO .............................................................................................................. 14 3.1.1 Justificación de la estrategia de relevamiento utilizada ..................................................................... 14 3.1.2 Descripción de los prototipos realizados ............................................................................................ 16 3.1.3 Descripción de las validaciones realizadas al ESRE.......................................................................... 16
3.2 ENTORNO DE LA ORGANIZACIÓN............................................................................................................... 17 3.2.1 Casos de uso del negocio .................................................................................................................... 18
3.3 CLIENTES Y USUARIOS ............................................................................................................................. 21 3.4 DESCRIPCIÓN DEL SISTEMA DE SOFTWARE................................................................................................ 22
3.4.1 Requerimientos funcionales ................................................................................................................ 22 3.4.2 Requerimientos no Funcionales .......................................................................................................... 23 3.4.3 Criterios priorización requerimientos................................................................................................. 23
3.5 PROBLEMAS ENCONTRADOS Y LECCIONES APRENDIDAS ........................................................................... 24
4 INVESTIGACIÓN DE HERRAMIENTAS.................................................................................................. 25
4.1 MOTOR DE WORKFLOW ............................................................................................................................ 25 4.2 CAPA DE PRESENTACIÓN WEB.................................................................................................................. 27 4.3 PERSISTENCIA ........................................................................................................................................... 28 4.4 EVALUACIÓN DE FÓRMULAS ..................................................................................................................... 28 4.5 CONSULTAS OLAP................................................................................................................................... 29
5 DISEÑO ARQUITECTÓNICO ..................................................................................................................... 31
5.1 INTRODUCCIÓN A LA SECCIÓN .................................................................................................................. 31 5.2 DESCRIPCIÓN Y JUSTIFICACIÓN DE LA ARQUITECTURA ............................................................................. 31
5.2.1 Fundamentación en función de los requerimientos............................................................................. 31 5.2.2 Diagramas........................................................................................................................................... 33 5.2.3 Fundamentación de características de calidad................................................................................... 39 5.2.4 Fundamentación de tecnologías utilizadas ......................................................................................... 40 5.2.5 Validaciones........................................................................................................................................ 40
5.3 EVOLUCIÓN DE LA ARQUITECTURA........................................................................................................... 41
6 GESTIÓN DE LA CALIDAD ........................................................................................................................ 42
6.1 INTRODUCCIÓN ......................................................................................................................................... 42 6.1.1 Objetivos del área de calidad.............................................................................................................. 42
6.2 ASEGURAMIENTO DE LA CALIDAD DEL PRODUCTO ................................................................................... 43 6.2.1 Gestión ................................................................................................................................................ 43
6.2.1.1 Organización ..............................................................................................................................................43 6.2.1.2 Responsabilidades ......................................................................................................................................44
6.2.2 Actividades .......................................................................................................................................... 45 6.2.3 Productos resultantes de las actividades de SQA ............................................................................... 51
6.3 CALIDAD DEL PROCESO DE DESARROLLO.................................................................................................. 52 6.3.1 Descripción y justificación del plan de calidad .................................................................................. 52
6.3.1.1 Actividades fuera de fase............................................................................................................................53
5
6.3.1.2 Fase de Ingeniería de requerimientos .........................................................................................................53 6.3.1.3 Fase de diseño ............................................................................................................................................54 6.3.1.4 Fase de Implementación.............................................................................................................................54 6.3.1.5 Fase de Testing...........................................................................................................................................55
6.4 ANÁLISIS DE MÉTRICAS ............................................................................................................................ 56 6.4.1 Cantidad de fallas detectadas por fase ............................................................................................... 56 6.4.2 Cantidad de fallas no resueltas por fase ............................................................................................. 57 6.4.3 Costo de corrección de fallas por fase ................................................................................................ 58 6.4.4 Cantidad de fallas introducidas/detectadas por fase de cada iteración ............................................. 60 6.4.5 Índice de calidad ................................................................................................................................. 61 6.4.6 Métricas del proceso ........................................................................................................................... 62
6.5 EFECTIVIDAD DEL ÁREA DE CALIDAD ....................................................................................................... 63
7 GESTIÓN DE LA CONFIGURACIÓN........................................................................................................ 64
7.1 INTRODUCCIÓN ......................................................................................................................................... 64 7.2 PROCESO................................................................................................................................................... 64 7.3 PRODUCTOS RESULTANTES ....................................................................................................................... 66 7.4 PROBLEMAS Y ACCIONES TOMADAS.......................................................................................................... 67
8 GERENCIA ..................................................................................................................................................... 69
8.1 INTRODUCCIÓN ......................................................................................................................................... 69 8.2 ETAPAS DEL PROYECTO ............................................................................................................................ 69 8.3 TAMAÑO DEL PROYECTO .......................................................................................................................... 70 8.4 MEDIDAS DE ÉXITO ................................................................................................................................... 71 8.5 CALENDARIO ............................................................................................................................................ 72
8.5.1 Ciclo de vida ....................................................................................................................................... 72 8.5.2 Cronograma ........................................................................................................................................ 74 8.5.3 Desviaciones del cronograma............................................................................................................. 76
8.6 ESFUERZO................................................................................................................................................. 78 8.6.1 Esfuerzo planificado............................................................................................................................ 78 8.6.2 Esfuerzo real ....................................................................................................................................... 79
8.7 PRESUPUESTO ........................................................................................................................................... 83 8.8 ANÁLISIS DE RIESGOS ............................................................................................................................... 84
8.8.1 Identificación de Riesgos .................................................................................................................... 84 8.8.2 Evolución de Riesgos .......................................................................................................................... 85
9 CONCLUSIONES ........................................................................................................................................... 90
10 BIBLIOGRAFÍA ............................................................................................................................................. 92
11 ESTRUCTURA DE LA DOCUMENTACIÓN EN CD ............................................................................... 93
12 ANEXOS .......................................................................................................................................................... 94
79
8.6.2 Esfuerzo real
Se compara en la siguiente tabla el esfuerzo planificado contra el esfuerzo real:
Iteración Horas Estimadas Horas Reales Diferencia Análisis de Negocio
1 57 67 -10 2 25 39,5 -14,5
Total 82 106,5 -24,5 Relevamiento
3 41 56 -15 4 89 94,5 -5,5 5 145 145 0
Total 275 295,5 -20,5 Prototipo
6 251 389,5 -138,5 Total 251 389,5 -138,5
Desarrollo 7 351 370 -19 8 351 159,5 191,5 9 285 319 -34 10 185 196 -11 11 325 293 32 12 325 329 -4
Total 1822 1666,5 155,5 Cierre
13 200 153 47 14 170 121 49 15 150 180 -30
Total 520 454 66 Totales 2950 2912 38
Cuadro de Esfuerzo Planificado y Esfuerzo Real
A primera vista se podría decir que la planificación del proyecto fue muy adecuada, ya que el total de horas estimadas es 2950 y el total de horas reales es 2912. Pero al hacer un análisis un poco más detallado se puede ver que en realidad el hecho de que los totales planificados y reales no nos dan ninguna información acerca de la efectividad de la planificación, ya que los errores en la estimación pueden ser por esfuerzo planificado de más o de menos.
Se decide entonces que la métrica para medir el desvío respecto a la estimación debe
considerar las horas planificadas de más y de menos de forma separadas, de forma de obtener una medición más real sobre el avance del proyecto.
82
Se muestra en las siguientes gráficas los porcentajes de esfuerzo del proyecto por cada rol y por cada actividad:
Esfuerzo por Rol
Desarrollador, 58%Gerente, 6%
Ing Requerimientos, 10%
Lider SCM, 2%
Lider SQA, 6%
Tester, 7%
Investigador, 5% Arquitecto, 6%
Gráfica de Esfuerzo por Rol
Esfuerzo por Actividad
Implementación, 58%Investigación, 5%
Relevamiento, 9%
Reunión, 3%
SCM, 2%
Testing, 8%
Gestión, 4%
SQA, 6% Diseño, 5%
Gráfica de Esfuerzo por Actividad
335
APENDICE 4. MANUAL DE IMPLEMENTACIÓN DEL MODELO
336
Modelo ele
Manual de Implementación
Manual de implementación del modelo “ele”
2
Manual de implementación del modelo “ele”
3
Tabla de contenidos
1 SOBRE EL MANUAL .................................................................................................................... 5
1.1 OBJETIVOS ..................................................................................................................................... 5 1.2 ORGANIZACIÓN ............................................................................................................................. 5 1.3 A QUIÉN VA DIRIGIDO ................................................................................................................... 5
2 INTRODUCCIÓN ........................................................................................................................... 6
2.1 EL MODELO ELE ............................................................................................................................ 6 2.2 INTEGRACIÓN ENTRE EL MODELO Y LOS PROYECTOS DE DESARROLLO DE SOFTWARE ......... 8
3 IMPLEMENTACIÓN DEL MODELO ELE ............................................................................... 9
3.1 ¿CUÁNDO COMENZAR LA IMPLEMENTACIÓN DEL MODELO? .................................................... 9 3.2 ¿QUÉ SE NECESITA PARA COMENZAR LA IMPLEMENTACIÓN DEL MODELO? ........................... 9 3.3 ¿CÓMO SE DESCRIBEN LAS FASES DEL MODELO? ....................................................................... 9 3.4 INICIACIÓN .................................................................................................................................. 10 3.4.1 PROPÓSITOS ............................................................................................................................... 10 3.4.2 INSUMOS Y PRODUCTOS ............................................................................................................. 10 3.4.3 ACTIVIDADES ............................................................................................................................ 11 3.4.3.1 Conformar el GGCA .............................................................................................................. 12 3.4.3.2 Definir las áreas y objetivos de aprendizaje ........................................................................... 12 3.4.3.3 Elaborar el plan general de actividades .................................................................................. 13 3.4.3.4 Definir las métricas del proceso ............................................................................................. 13 3.4.3.5 Elaborar el plan de comunicaciones ....................................................................................... 13 3.5 PREPARACIÓN ............................................................................................................................. 14 3.5.1 PROPÓSITO ................................................................................................................................. 14 3.5.2 INSUMOS Y PRODUCTOS ............................................................................................................. 14 3.5.3 ACTIVIDADES ............................................................................................................................ 15 3.5.3.1 Definir plan de actividades ..................................................................................................... 16 3.5.3.2 Elaborar o actualizar la lista de preguntas críticas ................................................................. 16 3.5.3.2.1 Conocimiento de las áreas de IS .......................................................................................... 17 3.5.3.2.2 Taxonomía de Bloom .......................................................................................................... 17 3.5.3.2.3 Tipos de preguntas & Operaciones Cognitivas ................................................................... 19 3.5.3.2.4 Proceso para la elaboración de preguntas ........................................................................... 21 3.5.3.2.5 Algunas sugerencias ............................................................................................................ 22 3.5.3.3 Elaborar o actualizar las Guías de Reflexión ......................................................................... 23 3.5.3.4 Asignar las Guías de Reflexión .............................................................................................. 24 3.5.3.5 Elaborar o actualizar inventario de conocimientos................................................................. 24 3.5.3.6 Identificar brechas de conocimiento ....................................................................................... 24 3.5.3.7 Definir plan de adquisición inicial de conocimientos ............................................................ 24 3.5.3.8 Preparar cuestionario para Guía de Reflexión ........................................................................ 24 3.5.3.9 Reuniones de preparación ...................................................................................................... 25 3.6 FAMILIARIZACIÓN ...................................................................................................................... 26 3.6.1 PROPÓSITOS ............................................................................................................................... 26 3.6.2 INSUMOS Y PRODUCTOS ............................................................................................................. 26 3.6.3 ACTIVIDADES ............................................................................................................................ 26
Manual de implementación del modelo “ele”
4
3.6.3.1 Analizar y comprender las Guías de Reflexión ...................................................................... 27 3.6.3.2 Adquirir conocimientos básicos ............................................................................................. 27 3.7 ACTUACIÓN ................................................................................................................................. 27 3.7.1 PROPÓSITOS ............................................................................................................................... 27 3.7.2 INSUMOS Y PRODUCTOS ............................................................................................................. 28 3.7.3 ACTIVIDADES ............................................................................................................................ 28 3.7.3.1 Responder Guías de Reflexión ............................................................................................... 29 3.7.3.2 Formular propuestas preliminares de mejora ......................................................................... 29 3.7.3.3 Revisar completud de respuestas de las Guía de Reflexión ................................................... 29 3.7.3.4 Responder cuestionario para Guía de Reflexión .................................................................... 29 3.8 EDUCCIÓN .................................................................................................................................... 30 3.8.1 PROPÓSITOS ............................................................................................................................... 30 3.8.2 INSUMOS Y PRODUCTOS ............................................................................................................. 30 3.8.3 ACTIVIDADES ............................................................................................................................ 31 3.8.3.1 Consolidar respuestas de las Guías de Reflexión ................................................................... 31 3.8.3.2 Planificar el taller ................................................................................................................... 32 3.8.3.3 Educir nuevos conocimientos y aprendizajes ......................................................................... 33 3.8.3.4 Elaborar cuestionario sobre taller .......................................................................................... 33 3.8.3.5 Responder el cuestionario sobre el taller ............................................................................... 33 3.9 INTEGRACIÓN .............................................................................................................................. 33 3.9.1 PROPÓSITOS ............................................................................................................................... 33 3.9.2 INSUMOS Y PRODUCTOS ............................................................................................................. 34 3.9.3 ACTIVIDADES ............................................................................................................................ 34 3.9.3.1 Seleccionar propuestas de mejores prácticas .......................................................................... 34 3.9.3.2 Integrar las propuestas de mejores prácticas al repositorio .................................................... 35 3.10 REVISIÓN ................................................................................................................................... 35 3.10.1 PROPÓSITOS ............................................................................................................................. 35 3.10.2 INSUMOS Y PRODUCTOS ........................................................................................................... 35 3.10.3 ACTIVIDADES .......................................................................................................................... 36 3.10.3.1 Análisis de los cuestionarios ................................................................................................ 37 3.10.3.2 Evaluar el proceso seguido ................................................................................................... 37 3.10.3.3 Evaluar los productos generados .......................................................................................... 37 3.10.3.4 Formular recomendaciones .................................................................................................. 37 3.10.3.5 Identificar desvíos con respecto a los objetivos de aprendizaje ........................................... 37 3.10.3.6 Decidir si es necesario una nueva iteración .......................................................................... 38 3.11 CONCLUSIÓN ............................................................................................................................. 38 3.11.1 PROPÓSITOS ............................................................................................................................. 38 3.11.2 INSUMOS Y PRODUCTOS ........................................................................................................... 38 3.11.3 ACTIVIDADES .......................................................................................................................... 39 3.11.3.1 Analizar la aplicación general del modelo y recabar lecciones aprendidas .......................... 39
4 PLANTILLAS ............................................................................................................................... 40
4.1 PLANTILLA DE CATÁLOGO DE PREGUNTAS .............................................................................. 40 4.2 PLANTILLA DE GUÍA DE REFLEXIÓN ......................................................................................... 41
5 BIBLIOGRAFÍA ........................................................................................................................... 43
6 GLOSARIO ................................................................................................................................... 44
Manual de implementación del modelo “ele”
5
1 Sobre el manual Lograr la mejora de las prácticas del proceso de desarrollo de software a través de una metodología para la gestión del conocimiento y el aprendizaje basado en la experiencia, es un gran reto para una organización productora de software. Hacer posible que esta mejora se transforme en un proceso continuo y sistemático capaz de incrementar la calidad del proceso y el producto, lo es aún más. Esperamos que el modelo presentado en este manual sea de gran ayuda para aquellas empresas que se atrevan a tomar este desafío. 1.1 Objetivos El objetivo de este manual es proporcionar un camino de acción para llevar a cabo la implementación del modelo “ele”, con el fin de proporcionar una guía a las organizaciones y a los grupos que aborden este modelo. La secuencia de fases y actividades que se presentan en el manual no intentan ser un camino exhaustivo, único y acabado de implementación del modelo, sino que el mismo está abierto a todas aquellas adaptaciones que surjan de futuras implementaciones. 1.2 Organización Este documento está organizado en capítulos, a través de ellos se exponen todos los aspectos relativos a la implementación del modelo “ele”. En el capítulo 2 se encontrará información acerca del manual: objetivos, organización, destinatarios. La introducción al modelo se desarrolla en el capítulo 3. En el capítulo 4 se describen las ocho fases del modelo, a través de los diferentes apartados de este capítulo se explica el propósito de cada fase, las actividades y se desarrollan las reseñas teóricas necesarias para una comprensión cabal de todo el proceso.
El manual contiene recomendaciones, plantillas y ejemplos para futuras implementaciones y un marco teórico con los conceptos, las teorías y los principios que dan fundamento al modelo. 1.3 A quién va dirigido Este manual va dirigido a todos aquellos profesionales informáticos que deseen mejorar el proceso de desarrollo de software, y consideren importante gestionar el conocimiento y el aprendizaje surgido de la experiencia para lograrlo. Y para todas aquellas empresas de desarrollo de software que necesitan un método capaz de mejorar sus prácticas; que pueda ser incorporado al quehacer diario de los profesionales informáticos. Un método, que le permita enfocarse en las debilidades del proceso actual, establecer prioridades y darles solución en forma progresiva, generando propuestas de mejora para ser integradas al proceso. Y para aquellas empresas que consideren el conocimiento de sus miembros como un activo de suma importancia para lograr una ventaja competitiva y desean propiciar y fomentar una actitud reflexiva, crítica y activa de sus profesionales. Para que sean ellos los principales agentes del cambio y la mejora de las prácticas de desarrollo de software.
Manual de implementación del modelo “ele”
6
2 Introducción Este manual describe paso a paso cómo implementar el modelo “ele”. Detalla las actividades a realizar en cada fase, junto con ejemplos y recomendaciones sobre el curso de acción a seguir para su implementación. También se incluyen plantillas para guiar la estructuración de los documentos necesarios para la implementación 2.1 El modelo ele El modelo “ele” es un modelo para la gestión del conocimiento y el aprendizaje basado en la experiencia. Tiene por propósito generar propuestas de mejoras de las prácticas y del proceso de desarrollo de software existente en una organización. Se caracteriza por: • Reflejar las instancias de creación de conocimiento y de aprendizaje experimental que se
producen durante el desarrollo de las actividades dirigidas a producir software. • Enfocarse en las debilidades del proceso actual, establecer prioridades y darles solución en
forma progresiva, generando propuestas de mejora para ser integradas al proceso actual de la organización.
• Integrarse a las actividades habituales de trabajo en el marco de los proyectos de
desarrollo de software. • Propiciar y fomentar una actitud reflexiva, crítica y activa de los profesionales
informáticos para que sean estos los principales agentes del cambio y la mejora de las prácticas de desarrollo de software.
El modelo está compuesto por ocho fases. Las mismas son, en orden de ejecución: Iniciación, Preparación, Familiarización, Actuación, Educción, Integración, Revisión y Conclusión. La figura 1 muestra las fases del modelo.
Manual de implementación del modelo “ele”
7
Fig. 1: Modelo ele
Es un modelo iterativo; el ciclo iterativo comienza en la fase de Preparación y culmina en la fase de Revisión. Incluye: Preparación, Familiarización, Actuación, Educción, Integración y Revisión. Abarca las seis fases ubicadas en la parte superior o cresta de la “ele”. Las iteraciones se producen hasta que se cumplan los objetivos propuestos en la fase de Iniciación. El modelo comienza en la fase de Iniciación, en ésta se definen los objetivos de aprendizaje a alcanzar y se establecen las bases para gestionar la implementación del modelo. Durante la fase de Preparación el GGCA elabora las preguntas críticas y las Guías de Reflexión, esta herramienta es la encargada de capturar los aprendizajes surgidos de la experiencia. Es durante la fase de Familiarización que los miembros de los proyectos conocen y comprenden los objetivos definidos y las herramientas de captura de aprendizaje creadas para tal fin. En la Actuación los miembros de los proyectos van respondiendo las preguntas críticas contenidas en la Guía de Reflexión a la vez que desarrollan sus actividades, de esta forma su reflexión sobre el quehacer diario está siendo enfocado hacia los objetivos definidos. El propósito de la fase de Educción es recolectar, analizar y sintetizar los conocimientos y aprendizajes logrados en la fase de Actuación para formular propuestas de mejores prácticas a ser incorporadas en la fase de Integración. En la fase de Revisión se evalúa la aplicación del modelo, se identifican desvíos y posibles mejoras. La fase de Conclusión tiene por objetivo cerrar la aplicación del modelo. Se llega a esta fase una vez que se ha alcanzado todos o partes de los objetivos definidos en la fase inicial del modelo.
Manual de implementación del modelo “ele”
8
2.2 Integración entre el modelo y los proyectos de desarrollo de software Las actividades del modelo se integran a las actividades del proyecto de desarrollo de software. Este nivel de integración varía según la fase del modelo en que nos encontremos. El mayor grado de integración se da en las fases de Familiarización, Actuación y Educción.
Fig. 2: Integración con las actividades de proyectos y de mejora
En la fase de Familiarización los equipos de proyecto de desarrollo de software conocen y comprender los objetivos de aprendizaje establecidos y las actividades a realizar durante la implementación del modelo. Para lograr esto, los miembros de GGCA trabajan juntos con los miembros del proyecto de desarrollo de software a través de reuniones. Durante la fase de Actuación se da el mayor grado de integración entre el modelo y el proyecto. Durante esta fase los miembros del proyecto desarrollan su trabajo a la vez que responden las preguntas o sentencias contenidas en las Guías de Reflexión. El análisis y las síntesis de la información se realizan en la fase de Educción. Los integrantes de los proyectos de desarrollo de software participan de esta instancia a través de talleres.
Manual de implementación del modelo “ele”
9
3 Implementación del modelo ele 3.1 ¿Cuándo comenzar la implementación del modelo? Las actividades de las fases de Iniciación, Preparación y Familiarización deben estar culminadas antes del comienzo de las actividades del proyecto sobre las cuales se aplicará el modelo. De esta forma lograremos una óptima integración entre proyecto y modelo, puesto que la captura de los conocimientos y aprendizajes surgidos de la experiencia (fase de Actuación) se realizará desde que los integrantes de los proyectos comienzan a desempeñar sus actividades. Si se produce un desfasaje entre captura de experiencias y comienzo de las actividades del proyecto corremos el riesgo de perder parte de las experiencias que queremos capturar. 3.2 ¿Qué se necesita para comenzar la implementación del modelo? Para comenzar la puesta en marcha del modelo es necesario conocer las áreas de ingeniería de software sobre las cuales el modelo ha de implementarse y los objetivos de aprendizaje que se persiguen con la implementación. Estos objetivos surgen de las necesidades y las oportunidades de mejora que la organización determine en función de la evaluación de su proceso de desarrollo de software. La manera de determinar los objetivos de aprendizaje a lograr durante la implementación, dependerá de la organización en la cual se implementa el modelo, de sus recursos y de la información que disponga. Podrá existir un grupo de mejora de proceso que sea quienes determinen y definan estos objetivos. O podrán ser determinados por el GGCA a partir de información aportada por la organización. Puede darse el caso que no exista información y que el GGCA deba establecer los mecanismos para obtener la información necesaria para poder definir los objetivos a alcanzar durante la implementación. 3.3 ¿Cómo se describen las fases del modelo? En las siguientes secciones del presente capítulos se describen las ocho fases del modelo. Para realizar una descripción detallada de cada fase seguimos un esquema similar al propuesto por el modelo IDEAL. (Mcfeeley, 1996) Nuestro esquema de descripción contiene los siguientes elementos:
- Propósitos: descripción del propósito de la fase. - Insumos y productos: descripción de todos los insumos y productos de la fase.
Los insumos son los artefactos necesarios para realizar las actividades de la fase. Los productos son los resultados a obtener como consecuencia de las actividades realizadas en la fase.
- Actividades: se presenta un listado de las actividades junto con el gráfico de flujo de las tareas de la fase.
- Descripción de la actividad: descripción detalla de la actividad junto con las reseñas teóricas necesarias para una comprensión cabal del proceso.
La ejecución de las actividades de las fases del modelo genera un conjunto de productos que representas los resultados obtenidos. Cada producto está identificado por código y nombre. El código está compuesto por un prefijo de 3 letras acompañado de numeración. El prefijo
Manual de implementación del modelo “ele”
10
indica la fase en la cual se originó el documento y la numeración es un indicador del ordinal. La tabla 1 muestra la lista de prefijos utilizados.
3.4 Iniciación 3.4.1 Propósitos El propósito de la fase de Iniciación es poner en marcha la implementación del modelo. En esta fase se conforma el Grupo de Gestión de Conocimiento y Aprendizaje (GGCA) que tendrá la responsabilidad de dirigir la ejecución del modelo. Se definen los objetivos de aprendizaje a alcanzar durante la implementación. Se da inicio a las tareas administrativas de planificación, control y evaluación del desarrollo del modelo a través de la elaboración del plan general de actividades, plan de métricas y plan de comunicaciones. 3.4.2 Insumos y productos
PREFIJOS FASES Ext Documento externo Ini Iniciación Pre Preparación Fam Familiarización Act Actuación Edu Educción Int Integración Rev Revisión Con Conclusión
Tabla 1: Codificación de los documentos
Manual de implementación del modelo “ele”
11
3.4.3 Actividades
Manual de implementación del modelo “ele”
12
3.4.3.1 Conformar el GGCA El GGCA es responsable de la puesta en marcha y ejecución del modelo. Sus miembros tendrán por cometido la planificación, ejecución, control y evaluación de todas las actividades, así como también la coordinación entre los diferentes involucrados en el proceso. ¿Qué conocimientos requieren los miembros del GGCA? Es preciso que el GGCA se capacite para cumplir con su cometido, esta preparación inicial incluye:
- Conocer en profundidad los procesos y prácticas de ingeniería de software usados en la empresa.
- Comprender el propósito de las fases y actividades del modelo. - Entender la taxonomía de Benjamín Bloom y los tipos de preguntas que se pueden
formular para cada nivel de la taxonomía. - Estar al tanto del fundamento teórico sobre el cual se apoya el modelo: gestión del
conocimiento, aprendizaje experimental, reflexión sobre la acción, aprendizaje organizacional.
El producto resultante de esta actividad es el documento Ini-001: Documento de conformación del GGCA. 3.4.3.2 Definir las áreas y objetivos de aprendizaje Los objetivos de aprendizaje son metas deseables a alcanzar y a las que se procura llegar a través de la implementación del modelo. Son enunciados expresados con claridad y precisión. En ellos se formulan lo que se pretende que se aprenda al realizar una actividad. Se definen en esta instancia un conjunto de objetivos de aprendizaje. Ellos representan las mejoras que se pretende lograr a través de la implementación del modelo. Para la determinar los objetivos de aprendizaje necesitamos que la organización aporte información sobre el proceso de software y las evaluaciones de las prácticas y procesos en uso en la organización. Los documentos externos Ext-001: Documento de especificación del proceso y Ext-002: Documento de evaluación de las prácticas y proceso en uso, nos aportarán esta información.
Manual de implementación del modelo “ele”
13
3.4.3.3 Elaborar el plan general de actividades El plan general de actividades es el instrumento a través del cual se planifican las actividades a desarrollar durante la implementación del modelo. Este plan permite establecer un orden en la secuencia de acciones a realizar y controlar el curso de ejecución de las mismas. Planificar actividades permite hacer viables los objetivos definidos. Durante la implementación del modelo se elaboran dos cronogramas de actividades, uno en la fase de Iniciación, con las actividades a desarrollar a lo largo de toda la implementación y otro en las respectivas fases de Preparación con las actividades a desarrollar durante cada iteración. Recomendamos que las actividades se presenten en orden cronológico, y agrupadas por fase del modelo. El plan puede incluir fecha de inicio y fin, tiempos de duración, recursos, costos, prioridades de cada actividad u otras consideraciones que estime relevantes y sean útiles para realizar la administración y el control de las actividades a desarrollar. El producto resultante de esta actividad es el Ini-003: Documento de plan general de actividades. 3.4.3.4 Definir las métricas del proceso Una métrica es la medición de un atributo, propiedad o aspecto del proceso. Se miden aquellos aspectos que se quieren controlar y administrar (Sommerville, 2005). Corresponde en esta instancia establecer un plan general de métricas para la evaluación y control de distintos atributos durante la implementación del modelo. Estas métricas podrán estar orientadas a medir aspectos tales como:
- Tiempos insumidos en la implementación del modelo. - Costos generales de implementación. - Impactos que las actividades del modelo tendrán sobre los proyectos de desarrollo. - Tiempos insumidos por los integrantes del proyecto en la realización de actividades
del modelo. - Mejoras logradas durante la implementación. - Cantidad de horas de trabajo dedicadas a la implementación del modelo.
Existe variada bibliografía sobre cómo establecer un plan de métricas. Cada organización podrá optar por la propuesta que más se adapte a su forma de trabajo. Se sugiere el paradigma GQM (Goal-Question-Metric) propuesto por Basili, por ser éste el usado con éxito durante la primera implementación del modelo. Para elaborar un plan de métricas, Basili propone la siguiente secuencia: fijar objetivos, hacerse preguntas para alcanzar los objetivos, establecer las métricas. Para cada métrica definida plantear por qué recolectarla, qué datos se necesitan, cómo serán recolectados, quién debe recolectarlos y cómo serán presentados. El producto resultante de esta actividad es el Ini-004: Documento de plan de métricas. 3.4.3.5 Elaborar el plan de comunicaciones La comunicación entre el GGCA y los integrantes de los equipos de proyectos es clave para la implementación del modelo. Una comunicación adecuada permitirá involucrar y motivar a los
Manual de implementación del modelo “ele”
14
miembros del equipo de proyecto, exponer y explicar objetivos y actividades, capturar y discutir los aprendizajes obtenidos, generar las propuestas de mejora. Elaborar un plan de comunicaciones implica detallar las distintas estrategias de comunicación que se usarán en cada fase. Para realizar esta selección se debe tener en cuenta los objetivos, la naturaleza de las actividades y la importancia que la comunicación tendrá en esa fase. Familiarización, Actuación y Educción son las fases que tienen instancias de comunicación más relevantes. El producto resultante de esta actividad es el Ini-005: Documento de plan de comunicación. 3.5 Preparación 3.5.1 Propósito El propósito de la fase de Preparación es preparar a la organización para una nueva iteración en la ejecución del modelo. Durante esta fase se elaboran las preguntas críticas en base de los objetivos de aprendizaje definidos y se construyen la Guía de Reflexión con las preguntas elaboradas. La Guía de Reflexión tiene por objetivo capturar el aprendizaje surgido de la experiencia. Las preguntas contenidas en ella enfocan el proceso reflexivo hacia aquellos aspectos que se quieren mejorar. Los resultados de la reflexión se recogen en las respuestas dadas a las preguntas críticas. También en esta fase se identifican y evalúan las brechas de conocimientos de los miembros de los equipos de proyecto. La fase culmina con reuniones de preparación dirigidas a los miembros de la organización con el objetivo de involucrar a los mismos en el proceso que se realizará. 3.5.2 Insumos y productos
Manual de implementación del modelo “ele”
15
3.5.3 Actividades
Manual de implementación del modelo “ele”
16
3.5.3.1 Definir plan de actividades El plan de actividades a elaborar es un listado de todas las actividades a realizarse durante la presente iteración. Se presenta en forma detalla las actividades a ejecutarse en las fases de Preparación, Familiarización, Actuación, Educción, Integración y Revisión. Las actividades se presentan en orden cronológico, y agrupadas por fase del modelo. El plan puede incluir fecha de inicio y fin, tiempos de duración, recursos, costos, prioridades de cada actividad u otras consideraciones que estime relevantes y sean útiles para realizar la administración y el control de las actividades a desarrollar. Para la realización de esta actividad se necesita el documento Ini-003: Documento de Plan General de Actividades. El producto resultante de la actividad es el Pre-001: Plan de actividades para la presente iteración. 3.5.3.2 Elaborar o actualizar la lista de preguntas críticas Las preguntas críticas tienen por objetivo promover el análisis y la reflexión de los profesionales sobre su quehacer diario. Las mismas estarán contenidas en las Guías de Reflexión que serán elaboradas y posteriormente asignadas a los miembros de los equipos de proyectos. Cada objetivo de aprendizaje deberá tener asociadas una o más preguntas críticas. ¿Por qué se construyen preguntas para estimular la reflexión? A menudo no se puede expresar lo que se sabe, este conocimiento es tácito. Está implícito en las acciones, en las actividades que se realizan a diario. Las preguntas intentan ser el mecanismo que facilite la transformación del conocimiento tácito a conocimiento explícito, el cual puede ser compartido y transmitido. (Schon, 1998) Según Schon (1998), la reflexión en la acción y la reflexión sobre la acción son los mecanismos que utilizan los profesionales para poder desarrollarse de forma continua y aprender de sus propias experiencias. Por tanto, la reflexión se puede ver desde dos marcos temporales diferentes, puede darse antes y después de la acción. Mientras realizan el proceso reflexivo pasan por las etapas de apreciación, acción y reapreciación. Ellos interpretan y aprecian sus experiencias a través de los sistemas apreciativos, es decir, por medio de un
Manual de implementación del modelo “ele”
17
conjunto de valores, conocimientos, teoría y prácticas que ya han adquirido. Schon afirma que los profesionales reflexionan sobre su saber desde la práctica. Ante un problema a resolver, recuerdan una situación que han vivido y exploran la comprensión que han aportado en la resolución del caso. Las actividades repetitivas de una experiencia especializada hacen emerger las comprensiones que van madurando a través de la experiencia. Según Clifford y Thorpe (2007) muchos profesionales consideran las prácticas reflexivas como parte del proceso continuo de desarrollo profesional. Este autor propone el diario reflexivo como técnica para tomar los resultados de la reflexión sobre experiencias y situaciones. A través de esta herramienta se realiza la recopilación de información variada con el propósito de ayudar a la formulación de un juicio, para tomar decisiones correctas, para el rumbo o para realizar inferencias válidas. El modelo propone las preguntas críticas como herramienta para estimular la reflexión de los profesionales, y lograr capturar a través de las respuestas los aprendizajes surgidos de la reflexión sobre su experiencia diaria. 3.5.3.2.1 Conocimiento de las áreas de IS Antes de abordar la elaboración de las preguntas críticas, el GGCA necesita conocer en profundidad las áreas de IS involucradas en la presente iteración. Los plazos para concretar esta actividad dependerán de los recursos como ser: el conocimiento de sus miembros, la posibilidad de contratar asesores, los cursos disponibles, el acceso a bibliografía. También de las decisiones que tomen durante esta fase, la incorporación de un experto en el área a trabajar permitiría optimizar los tiempos. Se sugiere que el GGCA complete su capacitación en IS con la revisión de la Guía del Cuerpo de Conocimientos de la IS (Guide to the Software Engineering Body of Knowledge). Ésta pretende ser una referencia conceptual de IS para la comunidad informática. Define un cuerpo unificado de conocimiento de la disciplina, clarifica el lugar que ocupa y establece los límites con respecto a otras disciplinas. En la versión 2004 presenta una estructura conformada por diez áreas del conocimiento donde se integran aspectos teóricos y prácticos 3.5.3.2.2 Taxonomía de Bloom Por todo lo expuesto es clave elaborar preguntas que estimulen el pensamiento crítico y la reflexión. Para lograrlo se tomará como base el marco teórico dado por la taxonomía de Bloom1 (1956), la cual considera que las personas aprenden a partir de tres dominios: cognitivo, afectivo y psicomotor. Para este trabajo se centrará la atención en el dominio cognitivo por ser éste el que categoriza el desempeño intelectual. A su vez el dominio cognitivo se subdivide en los siguientes seis niveles: conocimiento, comprensión, aplicación, análisis, síntesis y evaluación. Estos niveles son de complejidad creciente, jerarquizando el conocimiento adquirido. Esto significa que para alcanzar un nivel se requiere las habilidades desarrolladas en los niveles anteriores o precedentes. El cuadro siguiente presenta las características de cada nivel de la taxonomía. 1 Bloom creó esta taxonomía en 1956, con el objetivo de establecer un marco de referencia común para facilitar la comunicación entre los profesionales del área educativa y a la vez estimular la investigación del proceso de adquisición de conocimiento.
Manual de implementación del modelo “ele”
18
CONOCIMIENTO El principal proceso psicológico que se requiere en este nivel es recordar información.Recordar: terminología, hechos específicos (acontecimientos, personas, lugares, fechas, etc.), modos de organizar, convenciones, tendencias, secuencias, clasificaciones, categorías, criterios, metodología, teorías, estructuras, etc. COMPRENSIÓN La capacidad que se espera en este nivel es entender la información recibida. Comprender algo requiere previamente conocer la información. Tres tipos de comportamiento de comprensión:
• La traducción: poner en otro lenguaje la comunicación recibida. Ejemplos de este tipo de comportamiento son: planteo de un problema con tus propias palabras, expresar una abstracción a través de una ilustración, diagrama u otro elemento gráfico, capacidad de comprender mapas, diagramas, tablas, etc.
• La interpretación: comprender la relación entre las partes, reordenarlas, distinguir lo esencial de lo secundario.
• La extrapolación: implica la capacidad de ampliar la información encontrando
implicaciones, consecuencias, corolarios, efectos, etc. Requiere la capacidad de predecir, estimar, extraer conclusiones, distinguir consecuencias.
Las habilidades que se describen en este nivel tienen un nivel de abstracción menor a las que se describirán en los siguientes niveles. APLICACIÓN Es la capacidad de aplicar correctamente una abstracción para resolver un problema. La aplicación requiere un poder de abstracción mayor a la comprensión. En la comprensión la persona puede usar la abstracción, en la aplicación puede aplicarla para resolver una situación. Requiere la capacidad de aplicar conceptos, teorías, principios, generalizaciones, leyes, etc. ANÁLISIS El análisis implica el fraccionamiento del todo en sus partes constitutivas, conocer la relación entre las partes y comprender cómo están organizadas. Análisis y comprensión pueden confundirse. La comprensión implica el contenido, la capacidad de análisis implica contenido y forma. Tres tipos de niveles de análisis: Fraccionar el material en sus partes constitutivas, Hacer implícitas las relaciones entre las partes, Reconocimiento de la estructura.
Manual de implementación del modelo “ele”
19
SÍNTESIS En la síntesis se reúnen los elementos para formar un todo. Requiere la capacidad de combinar partes de fuentes diversas capaces de crear un todo creativo, distinto al inicial. Se obtiene un todo que es más que las sumas de las partes con el que se comienza a trabajar. EVALUACIÓN Capacidad de hacer juicios cualitativos o cuantitativos en base a criterios dados. Este nivel está relacionado con el dominio afectivo, puesto que en la evaluación se deben tener en cuenta valoraciones (gustos-disgustos, goce-rechazo, etc.). Es necesario distinguir opinión de evaluación. La evaluación requiere el aporte de todos los niveles anteriores de la taxonomía. 3.5.3.2.3 Tipos de preguntas & Operaciones Cognitivas Cecil (1995) expresa que es necesario conocer los distintos tipos de preguntas que se puede elaborar. Esta autora clasifica las preguntas de acuerdo con los niveles de aprendizaje de la taxonomía de Bloom, asociando en cada nivel las operaciones cognitivas que se realizan para dar respuesta a las preguntas. Durante los procesos de aprendizaje, las personas en sus actividades efectúan múltiples operaciones cognitivas que contribuyen a lograr el desarrollo de sus estructuras mentales y de sus esquemas de conocimiento. La siguiente es una breve lista de operaciones cognitivas:
- Receptivas:
- Percibir / Observar - Leer / Identificar
- Retentivas:
- Memorizar / Recordar (recuperar, evocar)
- Reflexivas:
- Analizar / Sintetizar - Comparar / Relacionar - Ordenar / Clasificar - Calcular / Aplicar procedimientos - Comprender / Conceptualizar - Interpretar / Inferir - Planificar - Elaborar hipótesis / Resolver problemas - Criticar / Evaluar
El siguiente cuadro presenta las preguntas que se pueden formular para cada nivel de la taxonomía de Bloom. La columna de “palabras claves” identifica las operaciones cognitivas que se requieren para dar respuesta a los distintos tipos de preguntas.
Manual de implementación del modelo “ele”
20
NIVELES PALABRAS CLAVES PREGUNTAS
Conocimiento Escoger, encontrar, definir, rotular, mostrar, deletrear, listar, parear, nombrar, relatar, contar, recordar, seleccionar.
¿Cómo explicaría usted? ¿Cómo lo describiría usted...? ¿Cómo lo demostraría usted…?
Comprensión Comparar, contrastar, demostrar, interpretar, explicar, extender, ilustrar, inferir, extractar, relatar, refrasear, traducir, resumir, demostrar, clasificar.
¿Cómo clasificaría usted...? ¿Cómo compararía usted...? ¿Cómo contrastaría usted...? ¿Cómo expondría o compararía usted en sus propias palabras....? ¿Cómo refrasearía usted el sentido, el significado.. ¿Qué ejemplos podría usted encontrar para...? ¿Cómo resolvería usted _______ utilizando lo que ha aprendido sobre...?
Aplicación Aplicar, construir, escoger, realizar, desarrollar, entrevistar, hacer uso de, organizar, experimentar con, planear, seleccionar, resolver, utilizar, modelar, identificar.
¿Cómo organizaría usted ______ para demostrar...? ¿Cómo demostraría usted su entendimiento de...? ¿Qué aproximación o punto de vista, utilizaría para...? ¿Cómo aplicaría usted lo que ha aprendido para desarrollar...? ¿De qué otra manera planearía usted...? ¿Qué pasaría si...? ¿Podría usted utilizar algunos hechos para...? ¿Cuáles elementos cambiaría usted...? ¿Qué hechos seleccionaría para demostrar...?
Análisis Analizar, categorizar, clasificar, comparar, contrastar, descubrir, disecar, dividir, examinar, inspeccionar, simplificar, tomar parte en, examinar para, encuestar, distinguir, listar, relacionar, funcionar, motivar, diferenciar, inferir, asumir, concluir, componer.
¿Cómo es ______ en relación a...? ¿Por qué cree usted...? ¿Qué razones, motivos, existen para...? ¿Qué inferencias puede hacer usted...? ¿A qué conclusiones puede llegar...? ¿Cómo clasificaría usted...? ¿Qué evidencia encuentra usted...? ¿Puede usted diferenciar entre...?
Síntesis Construir, escoger, combinar, compilar, componer, crear, fabricar, diseñar, desarrollar, estimar, formular, imaginar, inventar, originar, planear, predecir, decidir, proponer, resolver, solucionar, suponer, discutir, modificar, cambiar, originar, implementar, adaptar, minimizar, maximizar, teorizar, elaborar, examinar, eliminar, implementar, suceder, cambiar.
¿Qué cambios haría usted para resolver....? ¿Cómo mejoraría usted...? ¿Qué pasaría si...? ¿Puede proponer una alternativa...? ¿Puede usted inventar...? ¿Cómo adaptaría usted _____ para crear una situación o cosa diferente...? ¿Cómo cambiaría, modificaría, el terreno, plano...? ¿Qué haría usted para minimizar (o maximizar)...? ¿Qué diseñaría usted...? ¿Qué combinaciones se podrían hacer para mejorar o cambiar...? ¿Suponga que usted puede ______ qué haría...? ¿Cómo examinaría, evaluaría, usted...? ¿Podría usted
Manual de implementación del modelo “ele”
21
formular una teoría para...? ¿Podría predecir usted el resultado de...? ¿Cómo estimaría usted los resultados de...? ¿Qué hechos puede usted compilar...? ¿Podría usted construir un modelo que cambiara...? ¿Podría pensar usted en una forma original para...?
Evaluación Premiar, escoger, concluir, criticar, decidir, defender, determinar, disputar, evaluar, juzgar, justificar, medir, comparar, marcar, categorizar, recomendar, reglamentar, seleccionar, aceptar, interpretar, explicar, avaluar, priorizar, opinar, dar importancia, establecer criterios, aprobar, reprobar, valorar, influenciar, percibir, significar, estimar, influenciar, deducir.
¿Está usted de acuerdo con las acciones o procedimientos...? ¿con los resultados....? ¿Cuál es su opinión de...? ¿Cómo aprobaría (desaprobaría) usted...? ¿Puede usted establecer el valor o importancia de...? ¿Sería mejor si...? ¿Por qué cree usted que (tal persona) escogió...? ¿Qué recomendaría usted...? ¿Qué argumentaría usted para defender tales acciones...? ¿Cómo daría usted prioridad...? ¿Qué juicio haría usted sobre...? ¿En base a lo que usted sabe, cómo explicaría...? ¿Qué información usaría usted para justificar tal punto de vista...?
Tabla 2: La taxonomía de Bloom y el pensamiento crítico (Álvarez, 2003)
3.5.3.2.4 Proceso para la elaboración de preguntas Se estará pronto para comenzar el proceso de elaboración de preguntas una vez que se haya comprendido cómo se formulan las preguntas para cada nivel de la taxonomía y qué operaciones cognitivas tiene asociada cada pregunta. Las operaciones cognitivas del tipo reflexivas son las más relevantes para el propósito de nuestras preguntas. Resulta siempre complejo poner ejemplos inequívocos de preguntas que incluyan una operación cognitiva concreta, ya que, entre otras cosas, resulta difícil establecer fronteras absolutamente nítidas entre las operaciones cognitivas y porque muchas preguntas tienen asociadas más de una operación. Aún así, se proponen algunos ejemplos, con el propósito de esclarecer los conceptos expresados. Ejemplo 1: ¿Qué hace usted para motivar al usuario durante el proceso de recolección de requerimientos?
Pregunta dirigida al área de Ingeniería de Requerimientos, sub-área Educción, según SWEBOK. Pertenece al tercer nivel de Bloom: Aplicación. Las operaciones cognitivas asociadas son: utilizar métodos, aplicar.
Manual de implementación del modelo “ele”
22
Ejemplo 2: De acuerdo a su experiencia, ¿cuáles son los elementos esenciales para realizar una entrevista productiva? Se elaboran preguntas dirigidas a los objetivos de aprendizaje planteados y a las áreas y sub-áreas de IS asociados con estos objetivos. Se construirá un conjunto de preguntas para las áreas involucradas en función de los objetivos planteados. Para la clasificación por área y sub-área se usará la categorización planteada por SWEBOK. A la vez que se construyen las preguntas, se las asocia con el nivel de Bloom y el área y sub-área de IS a la cual está dirigida. Se recomienda construir preguntas de todos los niveles de la taxonomía pero a medida que avanza en su tarea deberá concentrarse en los niveles más avanzados de la taxonomía (Aplicación, Análisis, Síntesis y Evaluación) por ser éstos lo que requieren operaciones cognitivas de tipo reflexivas. Para realizar todo este proceso de elaboración y clasificación se propone el uso de la plantilla denominada Catálogo de Preguntas (ver apartado Plantillas). Las preguntas están agrupadas por áreas y sub-áreas de ingeniería de software involucradas. Y clasificadas según la taxonomía de Benjamín Bloom. Se identifica cada pregunta con un código compuesto que ilustra la clasificación realizada: Para la realización de esta actividad se necesita el documento Ext-001: Documento de especificación del proceso software. El producto resultante de la actividad es el Pre-002: Catálogo de preguntas. 3.5.3.2.5 Algunas sugerencias El éxito del trabajo dependerá en gran medida de la cantidad y calidad de la información que obtengamos a partir de las preguntas. Por tanto es clave que las mismas estén adecuadamente elaboradas. A continuación se presentan algunas sugerencias que pueden ayudar a cumplir este propósito.
Req. Edu. An. 03
área sub-áreanivel de Bloom
número de pregunta
Pregunta dirigida al área de Ingeniería de Requerimientos, sub-área Educción, según SWEBOK. Pertenece al sexto nivel de Bloom: Evaluación. Las operaciones cognitivas asociadas son: seleccionar, evaluar, inferir, priorizar, valorar.
Manual de implementación del modelo “ele”
23
Para estimular la reflexión, plantear situaciones problemáticas en las preguntas, ya que las situaciones problemáticas invitan a la reflexión.
Algunas de las preguntas planteadas en la guía deberían apuntar a que la persona describa los problemas que tuvo en determinadas situaciones y cómo logró resolverlos. Esta es la forma adecuada de lograr que la persona transmita su experiencia a la vez que reflexiona sobre la misma. Permitir que la persona pueda realizar sugerencias. Las sugerencias son una fuente muy importante de información. Por ello se recomienda agregar a la guía un espacio destinado para tal fin, el cual apunta a que la persona tenga un lugar en el que pueda expresar aspectos no considerados, opiniones personales, observaciones, recomendaciones, etc. No utilizar muchas preguntas cerradas, ya que las mismas tienden a guiar la respuesta de la persona. Se recomienda hacer uso de preguntas abiertas para los objetivos. Solicitar a la persona que realice una narración de no menos de tres o cuatro líneas, relatando una experiencia positiva o negativa que haya tenido. 3.5.3.3 Elaborar o actualizar las Guías de Reflexión La Guía de Reflexión permite dirigir las actividades de creación de conocimiento y aprendizaje experimental. Contiene preguntas críticas elaboradas para generar instancias de reflexión y análisis sobre las actividades que desarrollan los miembros del equipo de proyecto. Cada Guía de Reflexión estará dirigida a un área de IS, por lo tanto se elaboraran tantas guías como áreas de ingeniería de software surjan del conjunto de objetivos de aprendizajes definidos en la fase de Iniciación. Para armar las guías se seleccionan, del conjunto de preguntas críticas elaboradas, aquellas que puedan dar mayor información para el cumplimiento de los objetivos. Además de las preguntas se incluirá en la guía información sobre la misma, como son: objetivos, instrucciones de uso, líneas de comunicación y otros datos que considere de utilidad. En el apartado Plantillas se incluyó una plantilla para elaborar las Guías de Reflexión. En los anexos se encontrará un ejemplo de Guía de Reflexión relativa al área de ingeniería de requerimientos. Para la realización de esta actividad se necesita como insumo el documento Pre-002: Catálogo de preguntas. El producto resultante de la actividad es el documento Pre-003: Guía de Reflexión.
Manual de implementación del modelo “ele”
24
3.5.3.4 Asignar las Guías de Reflexión Los miembros de los equipos de proyectos deben recibir, junto con las asignaciones de tareas propias del proyecto, la Guía de Reflexión elaborada para dicha actividad. Ésta guiará su reflexión y análisis durante la ejecución de dichas tareas. Para la realización de esta actividad se necesitan los documentos Ext-003: Documento de asignación y de especificación de actividades de proyectos y el Pre-003: Guía de Reflexión. El producto resultante de la actividad es el documento Pre-004: Documento de asignación de Guías de Reflexión. 3.5.3.5 Elaborar o actualizar inventario de conocimientos El inventario de conocimientos es un mapa de los conocimientos y de la experiencia que cada miembro de los equipos de proyectos tiene en relación con los roles y las actividades de proyecto que le corresponderá desempeñar durante el desarrollo del mismo. Para la realización de esta actividad se necesitan los documentos Ext-003: Documento de asignación y de especificación de actividades de proyectos. El producto resultante de la actividad es el documento Pre-005: Inventario de conocimientos y de experiencia. 3.5.3.6 Identificar brechas de conocimiento Una vez asignadas la Guía de Reflexión a cada miembro de los equipos de proyecto, corresponde identificar y evaluar las necesidades de conocimientos particulares que cada persona tenga en relación con las actividades de proyecto asignadas y los roles que deberá desempeñar. Para la realización de esta actividad se necesitan los documentos Ext-003: Documento de asignación y de especificación de actividades de proyectos. El producto resultante de la actividad es el documento Pre-005: Inventario de conocimientos y de experiencia. 3.5.3.7 Definir plan de adquisición inicial de conocimientos Para eliminar, o al menos reducir, las brechas de conocimientos identificadas en el paso anterior, pueden definirse una variedad de mecanismos, tales como el estudio individual o grupal de material bibliográfico, impartir cursos específicos y la realización de talleres, entre otros. Para la realización de esta actividad se necesitan los documentos Pre-004: Documento de asignación de guías de reflexión. El producto resultante de la actividad es el documento Pre-006: Plan de adquisición inicial de conocimientos. 3.5.3.8 Preparar cuestionario para Guía de Reflexión El cuestionario es una herramienta utilizada para recabar información útil a muy bajo costo de tiempo y dinero. Debe estar bien elaborado para que los datos recolectados sean significativos. Para lograr esto es necesario saber con precisión qué información se debe recolectar y adaptar el lenguaje del cuestionario a la población a la que va dirigido. (García y Martínez, 2000) El cuestionario a elaborar tiene por objetivo evaluar las Guías de Reflexión como herramienta que permite dirigir las actividades de creación de conocimiento y aprendizaje experiencial. La
Manual de implementación del modelo “ele”
25
información recabada permitirá evaluar la eficacia de las guías para el logro de los objetivos propuestos, se busca detectar qué elementos de las guías fueron adecuados y cuáles es necesario cambiar, corregir o adaptar. Los destinatarios del cuestionario son los miembros de los equipos de proyecto a los cuales se les asignaron guías durante el desarrollo de los proyectos de software. El mismo es entregado una vez que el profesional haya completado la guía que le fue asignada. Esta actividad de evaluación resultante de la aplicación del cuestionario, está enmarcada en lo García y Martínez (2000) llama evaluación “acompañante”. Este tipo de evaluación tiene por propósito evaluar durante el proceso de un proyecto de trabajo, si un componente aporta o no a los objetivos del mismo. En el modelo la evaluación “acompañante” se utilizará para evaluar las Guías de Reflexión respondidas en la fase de Actuación y el taller que se efectúa en la fase de Educción. En este marco de trabajo la evaluación se realiza durante el proceso de implementación del modelo y no sólo al final del mismo. Este tipo de evaluación que se da durante el proceso de implementación busca innovar y mejorar las Guías de Reflexión sobre la base del conocimiento que se genera al usar y reflexionar sobre los resultados de las mismas. Las preguntas que conformarán el cuestionario podrán estar orientados a evaluar aspectos tales como:
A) Eficacia de las preguntas como instrumento para promover la reflexión sobre las prácticas de trabajo.
B) Vínculo entre experiencia personal y las preguntas formuladas. C) Valoración de los miembros de los equipos de desarrollo al trabajo con las guías. D) Claridad de las preguntas. E) Claridad de las instrucciones de uso de la Guía de Reflexión. F) Tiempos destinados para dar respuesta a la guía. G) Estructura general de la guía.
El producto resultante de la actividad es el documento Pre-007: Cuestionario. Se presenta un ejemplo de cuestionario de evaluación de Guías de Reflexión en los anexos. 3.5.3.9 Reuniones de preparación Las reuniones de preparación son la vía para involucrar y comprometer a los miembros de la organización en el proceso de implementación del modelo. Estas reuniones tienen por objetivo informar sobre el proceso a realizarse y planificar acciones en común. En ellas, los miembros del GGCA presentarán y explicarán:
A) Los objetivos y las características generales del modelo. B) El fundamento teórico sobre el cual se apoya. C) Los objetivos que se persiguen en esta iteración. D) Las actividades fundamentales del modelo.
Manual de implementación del modelo “ele”
26
3.6 Familiarización 3.6.1 Propósitos En la fase de Familiarización los miembros de los equipos del proyecto de desarrollo de software conocen y comprender los objetivos de aprendizaje y las actividades del modelo en las cuales participarán para el logro de los mismos. 3.6.2 Insumos y productos
3.6.3 Actividades
Manual de implementación del modelo “ele”
27
3.6.3.1 Analizar y comprender las Guías de Reflexión La participación activa de los miembros de los equipos de proyecto es clave para el éxito del modelo. Para ello es necesario que comprendan los objetivos de aprendizaje que se persiguen y las actividades que deberán realizar para lograrlo. En esta actividad del modelo el GGCA realiza reuniones para informar, explicar e involucrar a miembros de los equipos de proyecto, estas reuniones se denominarán Reuniones de Familiarización. Durante las Reuniones de Familiarización el GGCA presentará y explicará:
A) Los objetivos de aprendizaje de la presente iteración. B) Las actividades que los miembros de los equipos de proyecto realizarán: responder
Guías de Reflexión, participar en talleres, cursos, completar cuestionarios, formular posibles propuestas de mejora, etc.
C) El propósito y contenido de las Guías de Reflexión. D) Las instrucciones para completar las Guías de Reflexión.
3.6.3.2 Adquirir conocimientos básicos En base a las brechas de conocimientos identificadas en la fase anterior, corresponde aquí instrumentar los mecanismos adecuados para que los miembros de los equipos de proyectos adquieran los conocimientos necesarios para eliminar, o al menos reducir, esas brechas de conocimientos. Los mecanismos referidos pueden consistir, por ejemplo, en asignación de lecturas de material teórico o la realización de cursos o talleres enfocados específicamente a los temas en los que se han detectados esas carencias de conocimientos. 3.7 Actuación 3.7.1 Propósitos Las Guías de Reflexión han sido asignadas a los miembros de los equipos de proyecto en función de las actividades que desempeñan en el proyecto. Éstos, a la vez que desarrollan sus actividades, van analizando su quehacer en función de los criterios provistos en las Guías de Reflexión y respondiendo a las preguntas contenidas en ella. A partir de este proceso de reflexión y aprendizaje comienzan a delinearse las propuestas de mejora de las prácticas.
Manual de implementación del modelo “ele”
28
3.7.2 Insumos y productos
3.7.3 Actividades
Manual de implementación del modelo “ele”
29
3.7.3.1 Responder Guías de Reflexión Los miembros de los equipos de proyecto van respondiendo las preguntas críticas contenidas en la Guía de Reflexión a medida que van realizando las tareas del proyecto. Estas respuestas estarán basadas en la experiencia práctica de estar realizando o haber realizado las actividades del proyecto. En el transcurso de esta fase, se estimula a los profesionales a realizar un proceso reflexivo que pasa por las etapas de apreciación, acción y reapreciación. A este tipo de reflexión, Schon lo llama reflexión en la acción y desde la acción, la explicación de estos conceptos se encuentra en el apartado 4.5.3.1 de este manual y el marco teórico presentado en los anexos. 3.7.3.2 Formular propuestas preliminares de mejora A partir del proceso reflexivo que los miembros del equipo de proyecto realicen sobre sus prácticas, comienzan a formularse propuesta de mejora de estas prácticas. Esta actividad puede realizarse en forma individual o colectiva por aquellos miembros de equipo de proyecto que tengan asignadas tareas iguales o similares. 3.7.3.3 Revisar completud de respuestas de las Guía de Reflexión Es necesario que los miembros del equipo de proyecto completen todas las preguntas críticas contenidas la Guía de Reflexión que les fue asignada. 3.7.3.4 Responder cuestionario para Guía de Reflexión El cuestionario de evaluación de las Guías de Reflexión es entregado a los miembros de los equipos de desarrollo de software una vez que éstos hayan completado las preguntas críticas contenidas en la guía. Es de esperar que las respuestas al cuestionario aportadas por los miembros de los equipos de proyectos sean muy valiosas para realizar una posterior evaluación de las Guías de Reflexión que permita mejorar esta herramienta.
Manual de implementación del modelo “ele”
30
3.8 Educción 3.8.1 Propósitos El GGCA analiza las respuestas dadas a las preguntas contenidas en las Guías de Reflexión. El resultado de esta tarea es volcado en instancias grupales de taller a realizarse entre el GGCA y los miembros del proyecto. Los talleres tienen por objetivo consolidar los nuevos conocimientos y las propuestas de mejora del proceso de desarrollo de software. 3.8.2 Insumos y productos
Manual de implementación del modelo “ele”
31
3.8.3 Actividades
Edu-001
Edu-002
Edu-003
Edu-004
Edu-001
Edu-005Edu-004
Edu-001
Edu-001
Edu-001Edu-002
Edu-003Edu-004Edu-005
2. Educir Nuevos Conocimientos y
3.8.3.1 Consolidar respuestas de las Guías de Reflexión El GGCA analiza las respuestas dadas por los miembros de los equipos de proyectos a las preguntas críticas contenidas en las Guías de Reflexión. El propósito de esta actividad es:
Manual de implementación del modelo “ele”
32
A) Extraer los aspectos más relevantes de cada respuesta. B) Relacionar las respuestas dadas a la misma pregunta por distintos equipos de proyecto. C) Hallar coincidencias y discrepancias sobre los distintos aspectos tratados. D) Delinear posibles propuestas de mejora de las prácticas existentes en la organización.
Este análisis se continúa con una instancia de análisis colectivo a través de la realización de un taller. Durante el mismo el GGCA y los miembros de los equipos de proyecto comenzarán a delinear recomendaciones y propuestas de mejores prácticas. 3.8.3.2 Planificar el taller Según Ander-Egg (1999) el término taller sirve para indicar un lugar donde se trabaja, se elabora y se transforma algo para ser utilizado. Esta metodología de trabajo se caracteriza por:
A) Ser participativa, se aprende a partir de la experiencia compartida, todos tienen que aportar para llevar a cabo la tarea.
B) Activa: es un aprender haciendo, se aprende a partir de la participación activa. C) Grupal: es una forma de aprender en grupo donde se promueve y desarrolla la
capacidad de reflexionar del grupo. En un taller los conocimientos se producen fundamentalmente en respuesta a preguntas. Las actividades deben estar orientadas a solucionar un problema del mundo real y permitir establecer una relación entre lo pensado y lo realizado. Para lograr esto es necesario comprender el problema que se estudia. Comprender supone indagar, reflexionar, comparar, generalizar, dudar (Ander-Egg, 1999). Según García (1997) el taller tiene una intencionalidad operativa porque busca influir en las acciones de sus participantes. Durante el taller se dan tres momentos, el de la vivencia, la reflexión y la conceptualización. La vivencia es el primer paso, donde se realiza una técnica disparadora con el objetivo de romper el hielo y movilizar las estructuras cognitivas en relación al tema que se tratará. Durante la reflexión se intenta que se repiense sobre la experiencia de trabajo. Cada integrante va exponiendo lo aportado, lo pensado y lo trabajado. La conceptualización tiene por cometido producir una nueva hipótesis que llevará a la síntesis y conceptualización final. Para este autor, el taller se inicia con la presentación de un problema, esto permite ir desde la acción a la reflexión y a una nueva conceptualización (dinámica que se produce durante el taller). Para la planificación del taller se sigue la secuencia propuesta por García (1997):
1) Definir objetivos operacionales: si los objetivos están definidos con claridad y exactitud se podrán seleccionar las actividades, los recursos y el trabajo en equipo a desarrollarse durante el taller.
2) Actividad disparadora: esta actividad permite romper el hielo inicial para comenzar la actividad con un clima más distendido que de lugar a la comunicación en el grupo. Para la elección de esta actividad es necesario tener en cuenta las características de los miembros del grupo, la cantidad y el espacio físico donde se realizará el taller.
3) Momento de la reflexión: en esta fase comienzan a entretejerse las ideas, los pensamientos que constituyen la base de nuevos conocimientos.
Manual de implementación del modelo “ele”
33
4) Evaluación: en esta etapa los participantes realizan un recuento, explicación o síntesis final. Los coordinadores realizan una devolución de lo trabajado y logrado en la actividad. Es importante que el coordinador deje una impronta positiva que permita un reencuentro futuro.
3.8.3.3 Educir nuevos conocimientos y aprendizajes El taller constituye una instancia de análisis colectivo. Tiene por cometido arribar a conclusiones que permitan formular las propuestas y recomendaciones finales de mejora. Estas propuestas de mejores prácticas surgen del consenso logrado durante la instancia de taller entre los miembros de los equipos de proyecto y el GGCA. En las propuestas de mejora están contenidos los nuevos conocimientos y aprendizajes generados a partir de la experiencia. 3.8.3.4 Elaborar cuestionario sobre taller Evaluar las acciones realizadas durante el curso de acción resulta de gran valor para la mejorar de las mismas. En este contexto el cuestionario intenta evaluar el taller como herramienta para educir los nuevos conocimientos y aprendizajes logrados. Las preguntas que conformarán el cuestionario podrán estar orientados a evaluar aspectos tales como:
A) Proceso y resultados obtenidos del taller. B) Mecanismos de análisis y reflexión propuestos durante el taller. C) Objetivos, temas, actividades y tiempos propuestos durante el taller.
3.8.3.5 Responder el cuestionario sobre el taller El cuestionario de evaluación del taller es entregado a los miembros de los equipos de desarrollo de software inmediatamente después de su realización. La franca opinión de todos los participantes de esta instancia es clave para mejorar esta actividad en la próxima iteración del modelo. 3.9 Integración 3.9.1 Propósitos El propósito de esta fase es integrar las propuestas de mejores prácticas obtenidas durante la fase anterior al repositorio de la organización de forma de preservar y diseminar el conocimiento generado.
Manual de implementación del modelo “ele”
34
3.9.2 Insumos y productos
3.9.3 Actividades
3.9.3.1 Seleccionar propuestas de mejores prácticas Se entiende por mejores prácticas a un conjunto coherente de acciones que explican cómo llevar a cabo una o más actividades de forma de obtener mejores resultados durante su ejecución. El objetivo de esta actividad es seleccionar del conjunto de mejores prácticas
Manual de implementación del modelo “ele”
35
propuestas en la fase anterior aquellas que serán integradas a las prácticas de trabajo de la organización. 3.9.3.2 Integrar las propuestas de mejores prácticas al repositorio El objetivo de la última actividad de esta fase es incorporar el conocimiento generado al repositorio de la organización para su reutilización. El repositorio de conocimiento es el lugar donde se almacena el conocimiento disponible para su posterior reutilización (Markus, 2001). Ackerman (1994) prefiere llamar “memoria organizacional” al almacén de conocimientos de la organización. El repositorio es una pieza clave para compartir el conocimiento y, de esta forma, convertirlo en conocimiento de toda la organización. Puede ser organizado de diversas formas: software, documentos, base de datos, portal de conocimientos, entre otros (Markus, 2001). 3.10 Revisión 3.10.1 Propósitos En esta fase se realiza la evaluación del modelo y de los resultados obtenidos hasta el momento. Se analizan aquí los posibles errores, variables no controladas o desvíos que pueden haberse cometido en función de los objetivos de la presente iteración y se determina si es necesario otra iteración para el logro de los mismos. 3.10.2 Insumos y productos
Manual de implementación del modelo “ele”
36
3.10.3 Actividades
Manual de implementación del modelo “ele”
37
3.10.3.1 Análisis de los cuestionarios La información obtenida de los cuestionarios permitirá evaluar las Guías de Reflexión y el taller desde la perspectiva de los participantes de estas actividades. Esta evaluación es útil en la medida que la misma sea formativa, es decir, que se extraen enseñanzas (García y Martínez, 2000). El análisis de los cuestionarios tiene por cometido descubrir los aspectos positivos y negativos de las herramientas utilizadas en la implementación del modelo, para hacer modificaciones en los mismas para adaptarlas a nuestros objetivos. 3.10.3.2 Evaluar el proceso seguido Se evalúa el proceso realizado con el objetivo de introducir mejoras en próximas implementaciones del modelo. Para realizar esta evaluación es necesario apoyarse en las opiniones de los miembros de los proyectos de desarrollo (a través de los cuestionarios), en los resultados obtenidos en cada fase del modelo y en los datos de las métricas definidas en la fase de Iniciación del modelo. 3.10.3.3 Evaluar los productos generados Se evalúan los productos generados durante la implementación del modelo. Esto implica analizar: estructura, contenido, objetivos, utilidad. 3.10.3.4 Formular recomendaciones La evaluación de productos y procesos generará posibles aspectos a mejorar que se traducirán en recomendaciones. Las recomendaciones son útiles en la medida que sean tenidas en cuenta en las próximas iteraciones del modelo. 3.10.3.5 Identificar desvíos con respecto a los objetivos de aprendizaje Corresponde en esta actividad evaluar si se han cumplido los objetivos definidos para esta iteración. Un objetivo estará cumplido si se lograron mejores prácticas a partir de las experiencias y aprendizajes capturados durante el proceso de implementación del modelo.
Manual de implementación del modelo “ele”
38
3.10.3.6 Decidir si es necesario una nueva iteración Para determinar si es necesario iterar nuevamente se deben comparar los objetivos de aprendizaje propuestos al comienzo del modelo con los objetivos de aprendizaje logrados durante esta iteración. Es necesaria una nueva iteración si no se han cumplido todos los objetivos de aprendizaje propuestos. 3.11 Conclusión 3.11.1 Propósitos El objetivo de esta actividad es cerrar el conjunto de iteraciones efectuadas para cumplir los objetivos de aprendizaje definidos al inicio de la implementación. Las actividades de cierre incluyen recabar las lecciones aprendidas y analizar la aplicación del modelo a través de todas sus iteraciones. 3.11.2 Insumos y productos
Manual de implementación del modelo “ele”
39
3.11.3 Actividades
3.11.3.1 Analizar la aplicación general del modelo y recabar lecciones aprendidas Las lecciones aprendidas surgen de las conclusiones obtenidas del análisis de la aplicación del modelo. La evaluación de la labor realizada, los resultados obtenidos según los objetivos definidos, los aciertos y errores generan conclusiones. De las lecciones aprendidas se extraen buenas prácticas. Según el Departamento de Operaciones de Mantenimiento de la Paz de Naciones Unidas una buena práctica es “una forma de hacer que ha probado su efectividad en una situación y puede ser aplicable en otra” (Agencia Española de la Cooperación Internacional, 2000).
Manual de implementación del modelo “ele”
40
4 Plantillas 4.1 Plantilla de Catálogo de preguntas
Catálogo de preguntas Área: Escriba aquí el área de IS
Sub-área: Escriba aquí sub-área de IS
Identificación: Escriba aquí código del área
1. Conocimiento (Cn) código compuesto ...ingrese aquí la pregunta...
Palabras claves ...ingrese procesos cognitivos...
2. Comprensión (Cm) código compuesto ...ingrese aquí la pregunta...
Palabras claves ...ingrese procesos cognitivos...
3. Aplicación (Ap) código compuesto ...ingrese aquí la pregunta...
Palabras claves ...ingrese procesos cognitivos...
4. Análisis (An) código compuesto ...ingrese aquí la pregunta...
Palabras claves ...ingrese procesos cognitivos...
5. Síntesis (Si) código compuesto ...ingrese aquí la pregunta...
Palabras claves ...ingrese procesos cognitivos...
6. Evaluación (Ev) código compuesto ...ingrese aquí la pregunta...
Palabras claves ...ingrese procesos cognitivos...
Manual de implementación del modelo “ele”
41
4.2 Plantilla de Guía de Reflexión
Guía de Reflexión Ingrese área de trabajo
Estimado, Haga clic aquí y escriba el objetivo de la guía ¿Cómo completar esta guía? Haga clic aquí y escriba las instrucciones ¿A dónde recurrir en caso de necesitar asistencia? Estaremos a su disposición para responder cualquier duda. Usted puede optar por cualquiera de las siguientes formas de comunicación: Correo electrónico: Ingrese aquí dirección de correo electrónico Teléfonos: Ingrese aquí números telefónicos Ingrese aquí el saludo final y agradecimientos
Manual de implementación del modelo “ele”
42
Preguntas Pregunta 1 código compuesto
...ingrese aquí la pregunta...
Respuesta … incluir aquí los comentarios y reflexiones …
Pregunta 2 código compuesto
...ingrese aquí la pregunta...
Respuesta … incluir aquí los comentarios y reflexiones …
Pregunta 3 código compuesto
...ingrese aquí la pregunta...
Respuesta … incluir aquí los comentarios y reflexiones …
Pregunta 4 código compuesto
...ingrese aquí la pregunta...
Respuesta … incluir aquí los comentarios y reflexiones …
Espacio Libre
Manual de implementación del modelo “ele”
43
5 Bibliografía Ackerman, M., 2004 Ackerman, M: Definitional and contextual issues in
organization and group memories. Disponible en Internet: <www.ics.uci.edu/~ackerman>, 2004
AECI, 2000 Agencia Española de la Cooperación Internacional. Lecciones aprendidas y buenas prácticas. Una aproximación. Madrid, AECI, 2000
Alvarez, N., 2005 Alvarez, N.: Estrategias para mejorar la participación y moderación de foros de discusión, en: Revista E-formadores. Nº 8, agosto 2005
Ander-Egg, E., 1999 Ander-Egg, E.: El taller-Una alternativa de renovación pedagógica. Buenos Aires, Del Río de la Plata, 3ed., 1999
Basili, V. et al., 1994 Basili, V., Caldeira, G., Rombach., H.: Goal-Question-Metric Approach, en Encyclopedia of Software Engineering, pp. 528-532, 1994
Bloom, B. et al., 1956 Bloom, B.: Taxonomía de los objetivos de la educación. Buenos Aires, Ciudad de Edición, 7ed., 1956
Cecil, N., 1995 Cecil, N.: The Art of inquiry. Toronto, Peguis, 1995 Clifford, J. et al., 2007 Clifford, J., Thorpe, S. Workplace Learning & Development.
London, Kogan Page, 2007 García, D., 1997 García, D.: El grupo. Métodos y técnicas participativas.
Buenos Aires, Espacio, 1997 García, J. et al., 2000 García J., Martínez, R.: Concepto y metodología de la
evaluación en el programa Equal-Andalucía, Laboratorio de Estudios Interculturales, Universidad de Granada, 2000
IEEE, 2004 IEEE Computer Society: Guide to the Software Engineering Body of Knowledge, Los Alamitos, 2004
McFeeley, B., 1996 McFeeley, B.: IDEAL: A user’s guide for software process improvement, Pittsburgh, Carnegie-Mellon University, 1996
Markus, M., 2001 Markus, M.: Toward a theory of knowledge reuse: Types of knowledge reuse situations and factors in reuse success. En: Management Information Systems. 2001
Sommerville, I., 2005 Sommerville, I.: Ingeniería del Software. Madrid, Addison Wesley 7ed. 2005
Schon, D., 1998 Schon, D.: El profesional reflexivo. Buenos Aires, Piados, 1998
Manual de implementación del modelo “ele”
44
6 Glosario Aprendizaje experimental
Teoría del aprendizaje que centro el proceso del aprendizaje en la experiencia.
Experiencia Forma de conocimiento o habilidad derivados de la observación, de la vivencia de un evento o proveniente de las cosas que suceden en la vida.
GGCA Grupo de Gestión del Conocimiento y Aprendizaje. Guías de Reflexión Herramienta que tiene por objetivo capturar el aprendizaje surgido
de la experiencia. Insumos Artefactos necesarios para realizar las actividades de la fase.
Mejores prácticas Conjunto coherente de acciones que explican cómo llevar a cabo una o más actividades de forma de obtener mejores resultados durante su ejecución.
Objetivo de aprendizaje
Meta deseable a alcanzar en la que se formula lo que se pretende que se aprenda al realizar una actividad.
Operaciones cognitivas Actividad mental que procesa la información de los datos sensorialesPreguntas críticas Preguntas destinadas a promover el análisis y la reflexión.
Productos Resultados obtenidos como consecuencia de las tareas realizadas en la fase.
SPI
Mejora del proceso de Software: método sistemática y continua de mejora de una organización productora de software, con el objetivo de producir y entregar software de calidad, en los tiempos y el presupuesto establecidos
