Modelo para la gestión del conocimiento y la experiencia integrada
Anuncio
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 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. i 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. ii 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 iii iv 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 v 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 vi 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 vii 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 viii 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 ix 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 x 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 xi 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 xii 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 xiii 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 xv 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 xvi 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 1 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. 2 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 3 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 4 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 5 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 6 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. 7 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. 9 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: De Tácito De Explícito A Tácito A Explícito Socialización Externalización 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 10 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. 11 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) 12 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í. 13 En base a estas dos dimensiones, Boisot [Boisot, M., 1998] propone cuatro tipos de conocimientos, según la tabla 2.3: Codificable No codificable Difundido Conocimiento público Conocimiento de sentido común No difundido Conocimiento registrado propio 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. 14 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, 15 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. 16 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 17 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 Alineación con Estrategia Organizacional Definición de objetivos Identificación Identificación Bhatt Abou-Zeid Davenport y Prusak Identificación Adquisición Generación Creación Incorporación Desarrollo 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 Aplicación Utilización Tabla 2.4: Procesos de gestión del conocimiento 18 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”. 19 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. 20 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. 21 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. 22 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 23 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 24 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 25 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. 26 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. 27 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 28 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. 29 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 Proveer un miembros; construir producto o un servicio e intercambiar conocimientos 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 30 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. 31 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 32 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. 33 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. 34 Experiencia Concreta Observación Reflexiva Experimentación Activa 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 35 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. 36 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 37 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. 38 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. 39 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óncambio. 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. 40 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, 41 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. 42 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. 43 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. 44 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. 45 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. 46 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, 47 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. 48 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. 49 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. x x x x x x x x x x x x x x x x x x x x x x Nivel de Madurez Apoyo Ingeniería Gestión de proyecto Area de proceso Analisis de causas y resolucion Gestión de la configuración Análisis de decisiones y resolucion Gestion integrada de proyectos Medición y análisis Innovación y despliegue organizacionales Definición de procesos organizacionales Enfoque organizacional en procesos Rendimiento de procesos organizacionales Formación organizacional Integración de producto Monitorización y control de proyecto Planificación de proyecto Aseguramiento de calidad de procesos y productos Gestión cuantitativa de proyectos Gestión de requisitos Desarrollo de requisitos Gestión de riesgos Gestión de acuerdos con proveedores Solucion técnica Validación Verificación Gestión de proceso Categoría 5 2 3 3 2 5 3 3 4 3 3 2 2 2 4 3 2 3 2 3 3 3 Tabla 2.6: Areas de proceso y sus categorías y niveles de madurez asociados 50 Nivel 0 1 2 3 4 5 Niveles de Capacidad Incompleto Ejecutado Administrado Definido Quantitativamente administrado Optimizado Niveles de Madurez No aplicable Inicial Administrado Definido Quantitativamente administrado 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. 51 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]. 52 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 53 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. 54 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. 55 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. 56 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. 57 Grupo II Grupo I Socialización Externalización Internalización Combinación 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. 58 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 4 Grupo II Socialización 1 Grupo I Externalización 2 Grupo I Combinación 3 Grupo II Internalización Tabla 2.8: Perspectiva integrada 59 Paso del modelo de Kolb Experiencia Concreta Observación Reflexiva Conceptualización Abstracta Experimentación Activa 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: 60 Nivel Ignorant Beginner Advanced beginner Competent performer Proficient performer Expert Master Grand Master Explicación Sin conocimientos ni entendimiento de la disciplina Vagamente consiente de la disciplina; sin experiencia real Consiente e informado, pero relativamente incompetente en amplias áreas Comienza a tener un entendimiento más profundo Competente y ampliamente habilidoso; entendido en áreas específicas Altamente competente en un área particular Altamente experto en diversas áreas y ampliamente entendido 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 Aware Basic Competent Distinguished Expert Descripción Puede hablar el lenguaje de la disciplina Tiene un conocimiento rudimentario de la disciplina Es capaz de discutir y de trabajar en forma competente Es alguien a quien sus colegas de trabajo se dirigen en busca de consejos 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 61 evaluación de información. Cada nivel de la taxonomía tiene asociados una serie de verbos que denotan las operaciones cognitivas correspondientes. Nivel Conocimiento Comprensión Aplicación Análisis Síntesis Evaluación Descripción Habilidad para recordar material previamente aprendido Habilidad para captar el significado de un material, traducir de una forma a otra, explicar dando ejemplos, estimar tendencias futuras Habilidad para usar un material aprendido en situaciones nuevas o concretas aplicando reglas, métodos, conceptos, principios, leyes y teorías 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 Habilidad para reunir partes para formar un todo nuevo, creatividad para formular algo nuevo Habilidad para juzgar el valor de un material basado en criterios definidos Verbos asociados Conocer, recordar, repetir, definir, listar, describir, identificar, nombrar Clasificar, convertir, explicar, ilustrar, generalizar, ejemplificar, resumir, parafrasear, discutir, relatar, traducir Articular, calcular, construir, determinar, extender, resolver, mostrar, predecir, desarrollar, usar, aplicar, proporcionar, descubrir Descomponer, inferir, diferenciar, diagramar, distinguir, reconocer, separar, comparar, contrastar, inspeccionar, examinar, relacionar, discriminar Adaptar, combinar, compilar, generar, integrar, modelar, planear, organizar, ensamblar, formular, diseñar, crear, individualizar, categorizar, componer, proponer 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. 62 Proceso Recordar Entender Aplicar Analizar Evaluar Crear Descripción 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. 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. Implica utilizar procedimientos para realizar ejercicios o resolver problemas. Aplicar está íntimamente ligado al conocimiento procedimental. 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). 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. 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. 63 Conocimiento Factual Conceptual Procedimental Metacognitivo Descripción 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. 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. 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. 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. 64 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 65 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 Introductory Competency Leadership Mastery Descripción 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. 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. 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. 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. 66 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 67 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 semiestructuradas. 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 68 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 metamodelo 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, 69 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]. 70 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 71 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 72 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 retroalimentación recibida de los proyectos. 73 software estándar a partir de la 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 74 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 75 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, 76 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. 77 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 78 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 79 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 KMCORE (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 80 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. 81 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. 82 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 83 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. 84 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 85 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. 86 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 87 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? 88 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. 89 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 90 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" 91 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. 92 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. 93 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: 94 • 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. 95 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 96 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. 97 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. 98 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. 99 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. 100 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 101 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. 102 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. 103 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. 104 Act-01 Edu-01 Edu-01 1. Educir nuevos conocimientos y aprendizajes 2. Sintetizar lecciones aprendidas 3. Elaborar propuestas de mejores prácticas Edu-01 Edu-02 Edu-03 Insumo Producto 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. 105 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 106 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. 107 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. Ini-02 Act-01 1. Evaluar el proceso seguido y los productos generados Rev-01 2. Identificar desvíos respecto a los objetivos de aprendizaje Rev-02 3. Decidir si es necesaria una nueva iteración Rev-03 Pre-01 Ini-02 Pre-02 Act-01 Ini-02 Rev-02 Insumo Producto 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. 108 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. 109 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. 110 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. 111 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]. 112 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. 113 Area de Conocimiento: Requisitos Software + Fundamentos + Proceso Educción + Concepto o definición + Fuentes de requisitos Técnicas de educción Entrevistas Elección del entrevistado Planificación de la entrevista Interacció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 requisitos Funcionales y no funcionales Del producto y del proceso Priorizació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 114 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 Conocimiento Comprensión Aplicación Análisis Descripción La persona (conoce, recuerda, puede describir, …) las lecciones aprendidas y las propuestas de mejores prácticas relativas a <elemento de conocimientos y experiencia> 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> 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> 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. 115 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 116 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 Nivel personal Cn Cp Ap An Referencia Cn Cp Ap An + Fundamentos + Proceso Educción + Concepto o definición + Fuentes de requisitos Técnicas de educción x x Entrevistas Elección del entrevistado Planificación de la entrevista Interacción con el entrevistado : x x x + Escenarios + Prototipos + Reuniones de facilitación + Observación + Joint Application Development + Viewpoints : x x x x x x Análisis de requisitos + Concepto o definición Clasificación de requisitos x Funcionales y no funcionales Del producto y del proceso Priorización : x x x + Modelado conceptual + Diseño arquitectónico + Negociación de requisitos + Especificación de requisitos + Validación de requisitos + Consideraciones prácticas 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. 117 Dif. Área de conocimientos Sub-área de conocimiento Técnica Elementos de conocimientos y experiencia Preguntas Ingeniería de requisitos Educción de requisitos Entrevista Elección del entrevistado, planificación de la entrevista, interacción con el entrevistado, … 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. 118 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. 119 Catálogo de conocimientos y experiencia Objetivos de aprendizaje y de creación de conocimientos Taxonomía de objetivos educacionales Elementos de conocimientos y experiencia Objetivos de aprendizaje y de nuevos conocimientos Elaborar preguntas de reflexión Preguntas de reflexión Guía de reflexión Niveles de la taxonomía de Bloom 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 Sub-área de conocimiento Técnica Conceptos asociados Ingeniería de requisitos Educción de requisitos Entrevista 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 120 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. 121 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. 122 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 123 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. 124 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: 125 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. 126 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. 127 128 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 exploratoriodescriptivo 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 129 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. 130 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: 131 La organización (ORTsf) GGCA Investigador Implementación del Modelo “ele” GIP GPs GGCA: Grupo de Gestión del Conocimiento y del Aprendizaje GIP: Grupo de Ingeniería de Procesos GPs: Grupos de proyectos software 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. 132 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 133 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. 134 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 Proceso de implementación del modelo Guías de reflexión Taller de educción de conocimientos y experiencia Proposiciones 1 2, 3, 4 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. 135 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 Requisitos Software Diseño del software Construcción del software Prueba del software Gestión de Ingenieria Software Proceso de Ingeniería Software Mantenimiento del Software Gestión de Configuración Herramientas y Métodos Calidad del software Total 13 2 ‐‐‐ 3 16 4 ‐‐‐ 3 ‐‐‐ 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. 136 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. GP 1 GP 2 GP 3 Nombre del proyecto Código Sistema de gestión de acreditaciones GESA Software de gestión para COODESOR COODESOR Seguimiento y control de proyectos de SCPI inversión GP 4 Portal de inversiones InvPortal Integrantes 3 4 5 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. 137 Proposición 1 2 3 4 5 6 Fuentes de datos e instrumentos de recolección Documentos elaborados por el GGCA. Observación participante en el GGCA Guías de reflexión completadas por los miembros de los grupos de proyectos Documentos propios de los grupos de proyectos Guías de reflexión completadas por los miembros de los grupos de proyectos Cuestionario a los miembros de los grupos de proyecto Documento de resultados del Taller de educción de conocimientos y experiencia Observación participante en el GGCA 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. 138 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. 139 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. 140 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: 141 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). 142 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. Abr. Mayo Junio Julio Iniciación Seleccionar prácticas Definir objetivos de aprendizaje Seleccionar proyectos Preparación Capacitació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ón Preparar sesiones de familiarización Realizar reuniones de familiarización Actuación Responder guías de reflexión para Ing. Req. Responder guías de reflexión para Métricas Analizar respuestas Elicitación Preparar taller Realizar taller Identificar L.A. y M.P. Integración Definir estructura del repositorio Integrar L.A. y M.P. al repositorio Revisión Revisión del proceso y de los productos Conclusión Figura 5.2: Cronograma de actividades 143 Agosto Setiembre Octubre 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. 144 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. 145 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. 146 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 implementaciones del modelo, que se describen en el apartado 5.4.1. 147 en futuras 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. 148 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. 149 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. 150 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. 151 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 152 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. 153 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. 154 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. 155 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 156 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 SCPI InvPortal 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. El respondiente no hizo uso de este espacio. El respondiente no hizo uso de este espacio. 157 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. 158 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 SCPI … 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 ... 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 … 159 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. Guía para ingeniería de requisitos Guía para métricas de gestión de proyecto Totales en minutos COODESOR 80 90 170 GESA SCPI 76 49 125 46 70 116 InvPortal 67 0 67 Tabla 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. Guía para ingeniería de requisitos Guía para métricas de gestión de proyecto Totales en horas COODESOR 1,33 1,50 2,83 GESA 1,27 0,82 2,09 SCPI 0,77 1,17 1,94 InvPortal 1,17 0 1,17 Tabla 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. 160 Actividades de ingeniería de requisitos Actividades de gestión del proyecto Tiempo total del proyecto COODESOR 372h 95h 1.371h GESA 232,8h 204,3h 1.261,7h SCPI 262,1h 116,5h 2912,0h InvPortal 27h ----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: Actividades de ingeniería de requisitos Actividades de gestión del proyecto Tiempo total del proyecto COODESOR 0,36% 1,58% 0,21% GESA 0,55% 0,40% 0,17% SCPI 0,29% 1,00% 0,07% InvPortal 4,33% ----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. 161 Muy de acuerdo 38 17 8 12 1 76 Indiferente 5 21 33 20 28 6 3 16 46 113 En desacuerdo De acuerdo Muy en desacuerdo Pregunta 1 2 3 4 5 6 Totales 2 1 10 13 19 3 3 14 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 Favorable Indiferente Desfavorable Respuestas consideradas Muy de acuerdo, De acuerdo Indiferente En desacuerdo, Muy en desacuerdo Cantidad 189 46 19 254 % 74,41% 18,11% 7,48% 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 Favorable Indiferente Desfavorable Respuestas consideradas Muy de acuerdo, De acuerdo Indiferente En desacuerdo, Muy en desacuerdo Cantidad 5 2 0 7 Tabla 5.11: Respuestas a la pregunta 1 del cuestionario 162 % 71,43% 28,57% 0,00% 100,00% 2. La respuesta dada a cada pregunta estuvo directamente vinculada a mi experiencia personal adquirida en el proyecto (tabla 5.12). Actitud Favorable Indiferente Desfavorable Respuestas consideradas Muy de acuerdo, De acuerdo Indiferente En desacuerdo, Muy en desacuerdo Cantidad 59 1 0 60 % 98,33% 1,67% 0,00% 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 Favorable Indiferente Desfavorable Respuestas consideradas Muy de acuerdo, De acuerdo Indiferente En desacuerdo, Muy en desacuerdo Cantidad 50 10 0 60 % 83,33% 16,67% 0,00% 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 Favorable Indiferente Desfavorable Respuestas consideradas Muy de acuerdo, De acuerdo Indiferente En desacuerdo, Muy en desacuerdo Cantidad 28 19 13 60 % 46,67% 31,67% 21,67% 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 Favorable Indiferente Desfavorable Respuestas consideradas Muy de acuerdo, De acuerdo Indiferente En desacuerdo, Muy en desacuerdo Cantidad 40 14 6 60 % 66,67% 23,33% 10,00% 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). 163 Actitud Favorable Indiferente Desfavorable Respuestas consideradas Muy de acuerdo, De acuerdo Indiferente En desacuerdo, Muy en desacuerdo Cantidad 7 0 0 7 % 100,00% 0,00% 0,00% 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. 164 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. 165 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. 1 2 1 1 2 1 2 2 Muy de acuerdo De acuerdo Pregunta 1 2 3 4 5 6 7 8 9 Totales Indiferente En desacuerdo Muy en desacuerdo Las respuestas obtenidas se resumen en la tabla 5.17: 1 2 2 2 1 1 3 7 5 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 Favorable Indiferente Desfavorable Respuestas consideradas Muy de acuerdo, De acuerdo Indiferente En desacuerdo, Muy en desacuerdo Cantidad 35 1 0 36 Tabla 5.18: Agrupación de respuestas por actitud 166 % 97,22% 2,78% 0,00% 100,00% 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 Favorable Indiferente Desfavorable Respuestas consideradas Muy de acuerdo, De acuerdo Indiferente En desacuerdo, Muy en desacuerdo Cantidad 11 1 0 12 % 91,67% 8,33% 0,00% 100,00% Tabla 5.19: Sobre la organización del taller (preguntas 1 a 4) Actitud Favorable Indiferente Desfavorable Respuestas consideradas Muy de acuerdo, De acuerdo Indiferente En desacuerdo, Muy en desacuerdo Cantidad 12 0 0 12 % 100,00% 0,00% 0,00% 100,00% Tabla 5.20: Sobre la participación personal en el taller (preguntas 5 a 8) Actitud Favorable Indiferente Desfavorable Respuestas consideradas Muy de acuerdo, De acuerdo Indiferente En desacuerdo, Muy en desacuerdo Cantidad 12 0 0 12 % 100,00% 0,00% 0,00% 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. 167 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 168 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. 169 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…”. 170 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. 171 Conclusiones del taller 1.1 1.2 Respuesta en la guía de reflexión COODESOR.IR.3, GESA.IR.2, InvPortal,IR.3 COODESOR.IR.1, GESA.IR.1, SCPI.IR.1 Objetivos iniciales de aprendizaje y de creación de conocimientos Planificación de entrevistas para educción de requisitos Planificación de entrevistas para educción de requisitos Planificación de entrevistas para educción de requisitos Planificación de entrevistas para educción de requisitos 1.3 InvPortal.IR.1 1.5 GESA.IR.1 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 4.1 SCPI.IR.7 4.2 COODESOR.IR.7, SCPI.IR.7, InvPortal.IR.7 Habilidades personales del ingeniero de requisitos Entrenamiento inicial para ingenieros de requisitos 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 1.4 Objetivos iniciales de aprendizaje y de creación de conocimientos 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 172 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. 173 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. 174 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. 175 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. 176 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. 177 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). 178 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). 179 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. 181 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? 182 8. BIBLIOGRAFÍA 1. Abou-Zeid, 2001 Abou-Zeid, E.: A knowledge management reference model, Journal of Knowledge Management, 5 (5), 2001, pp. 486499. 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., Alagarsamy, K., Justus S., Iyakutti, K.: The knowledge 2008 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., PriesHeje, J., y Ngwenyama, O. (eds.): Improving software organizations. From principles to practice, Upper Saddle River, Addison-Wesley, 2001, pp. 235-253. 183 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. 184 25. Bierly, 2002 P., Dale, P., 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. 277296. 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, 2001 A., et al., 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., Borjesson, A., Mathiassen, L.: Successful process 2004 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. 185 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, al., 2007 P. et 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 metaabilities in tacit knowledge externalization and th organizational learning, Proceedings of the 39 Hawaii International Conference on System Sciences, 2006, p. 149 45. Clifford, J. et al., 2007 Cliford, J., Thorpe, S.: Workplace 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. 186 learning and 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., Davenport, T., Prusak, L.: Working knowledge. How 1998 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.: Selforganized 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., del Moral, A., Pazos, J., Rodríguez Fernández, E., 2007 Rodríguez-Patón, A., Suárez, S.: Gestión del conocimiento, Madrid, Paraninfo, 2007 59. Deming, E., 1986 60. Desouza, 2005 K. et Deming, E.: Out of the crisis, Cambridge, MIT Press, 1986 al., Desouza, K., Dingsoyr, T., Awazu Y.: Experiences with conducting project postmortems, Proceedings of the 38th Hawaii International Conference on System Sciences, 2005, p. 233 187 61. Desouza, 2006 K. et al., 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, 2003a T. et al., 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, 2003b T. et al., 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., Easterbrook, S., Singer, J., Storey, M., Damian, D.: 2008 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. 532550 188 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 multiagent 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., Farenhorst, R., Lago, P., van Vliet, H.: Prerequisites for 2007 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 189 84. Gottschalk, P., 2004 Gottschalk, P.: Strategic knowledge technology, Harshey, Idea Group, 2004 management 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., Hernández, R., Fernández, C., Baptista, P.: Metodología de 2003 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., Humphrey, W., Konrad, M., Over, J., Peterson, W.: Future 2007 directions in process improvement, CrossTalk, 20 (2), 2007, pp. 17-22. 190 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., Jedlitschka, A., Althoff, K., Decker, B., Harrtkopf, S., Nick, 2001 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., Johansson C., Hall, P., Coquard, M.: Talk to Paula and 1999 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. 3750. 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., Kitchenham, B., Pickard, L., Pfleeger, S.: Case studies for 1995 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. 191 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., Komi-Sirvio, S., Mantyniemi, A., Seppanen, V.: Toward a 2002 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 192 121. Mathiassen, L. et al., Mathiassen, L., Pries-Heje, J., y Ngwenyama, O. (eds.): 2001 Improving software organizations. From principles to practice, Upper Saddle River, Addison-Wesley, 2001 122. Mathiassen, L. et al., Mathiassen, L., Nielsen, P.,Pries-Heje, J.: Learning SPI in 2001 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., Mathiassen, L., Pourkomeylian, P., Managing knowledge in 2003 a software organization, Journal of Knowledge Management, Nº 7, 2003, pp. 63-80 124. Mathiassen, L. et al., Mathiassen, L., Pedersen, K.: The dynamics of knowledge 2005 in systems development practice, Proceedings of the 38th Hawaii International Conference on System Sciences, 2005 125. Matturro, G., Silva, A., Matturro, G., Silva, A.: A knowledge-based perspective for 2005 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., Muhammed, S., Doll, W., Deng, X.: Exploring the 2008 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., Mutafelija, B., Stromberg, H.: Systematic process 2003 improvement using ISO 9001:2000 and CMMI, Norwood, Artech House, 2003 193 133. Mutafelija, B. et al., Mutafelija, B., Stromberg, H.: Process improvement with 2009 CMMI v1.2 and ISO standards, Boca Ratón, Auerbach, 2009 134. Myllyaho, 2004 M. et al., 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 1998 Serrano, G., 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 194 148. Pourkomeylian, 2000 P., 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., Ramasubramanian, S., Jagadeesan, G.: Knowledge et al., 2003 management at Infosys, IEEE Software, 20 (3) May/June 2003, pp. 53-55 155. Ravichandran, T. et al., Ravichandran, T., Rai, A.: Software process management: 2000 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.): 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. 2638 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 195 Learning software 163. Sánchez, 1997 R. et al., 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 userfriendly semantic wiki, 3rd European Semantic Web Conference (ESWC’06), 2006 169. Schneider, K. et al., Schneider, K., von Hunnius, J., Basili, V., Experience in 2002 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 196 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., Swieringa, J., Wierdsma, A.: La organización que aprende, 1995 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, Ventura, J., Ordoñez, P.: Análisis de estrategias de P., 2007 conocimiento en la industria manufacturera española, Tribuna de economía, Nro. 836, Mayo-Junio 2007, pp. 141161 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. 197 188. Wake, W., 2001 Wake, W.: Extreme 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 198 programming explored, Boston, 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. 199 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. 201 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 202 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. 203 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 204 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. 205 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. 206 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. 207 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. 208 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. 209 Actividad privada Análisis y desarrollo de sistemas Desarrollo software Ingeniería de requisitos Asistencia técnica a usuarios Gerenciamiento de proyectos Responsable de IT Actividades no relacionadas Nombres Alicia Pino, Alicia Pereira, Rodrigo Robaina Mario Romero, Ricardo Leite, Matías Núñez, Federico Fontes, Felipe Herrera Carlos Geribón Alejandra Pera Yairo Vettorello Federico Gordillo Daniel Nicolich, Andrés Lapachián, Sergio Gambini Tabla A2.1: Actividades privadas de los estudiantes 210 Cant. 3 5 1 1 1 1 3 Apéndice 2. INSTRUMENTOS DE RECOLECCIÓN DE DATOS Item. Documento A2.1 A2.2 A2.3 Guías de reflexión para Ingeniería de Requisitos Guías de reflexión para Métricas de gestión de proyectos Cuestionario de evaluación de las Guías de reflexión para ingeniería de requisitos Cuestionario de evaluación de las Guías de reflexión para métricas de gestión de proyectos Plantilla para el documento de Resumen de respuestas de las Guías de reflexión para ingeniería de requisitos Plantilla para el documento de Resumen de respuestas de las Guías de reflexión para métricas de gestión de proyectos Cuestionario de evaluación del Taller de educción de conocimientos y experiencia Guía para la realización del Taller de educción de conocimientos y experiencia Plantilla para el documento de Resultados del taller de educción de conocimientos y experiencia A2.4 A2.5 A2.6 A2.7 A2.8 A2.9 211 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 Respuesta ¿Qué aspectos considera usted que es importante que se tomen en cuenta a la hora de planificar una entrevista? 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 212 Pregunta 3 Req.Eli.Ev.01 Respuesta ¿Qué recomendaría usted a un ingeniero de requerimiento que se enfrenta a un usuario con necesidades poco claras? Tiempo Dedicado Pregunta 4 Req.Eli.Si.01 Respuesta 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. Tiempo Dedicado Pregunta 5 Req.An.An.01 Respuesta En base a su experiencia, ¿qué dificultades encontró para distinguir los requerimientos funcionales de los no funcionales? Tiempo Dedicado Pregunta 6 Req.An.Ev.01 Respuesta ¿Cómo logro superar las dificultades anteriormente expresadas? Tiempo Dedicado Pregunta 7 Req.Prep.Si.01 Respuesta 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? Tiempo Dedicado Pegunta 8 Req.Prep.Ev.01 Respuesta A su juicio, ¿qué habilidades personales facilitarían las tareas del ingeniero de requerimientos? Tiempo Dedicado Pegunta 9 Req..Ev.01 Respuesta 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? Tiempo Dedicado Espacio libre: 213 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 Respuesta ¿Qué métricas planificó recolectar para su proyecto? ¿Por qué considera que estas métricas son adecuadas para su proyecto en particular? Tiempo Dedicado Pregunta 2 Ge.Me.Ap.01 Respuesta ¿Cómo llevó a cabo el análisis de los datos obtenidos a partir de la recolección de las métricas? Tiempo Dedicado 214 Pregunta 3 Ge.Me.An.01 Respuesta En base a su experiencia, ¿qué dificultades encontró para identificar las métricas que son útiles para su proyecto en particular? Tiempo Dedicado Pregunta 4 Ge.Me.Ev.02 Respuesta ¿Cómo logró superar las dificultades anteriormente expresadas? Tiempo Dedicado Pregunta 5 Ge.Me.Ev.03 Respuesta ¿Qué aconsejaría usted hacer para asegurar que las métricas seleccionadas son las adecuadas para un proyecto en particular? Tiempo Dedicado Pregunta 6 Ge.Me.Si.01 Respuesta Relate, en no menos de cuatro o cinco líneas, las lecciones aprendidas durante el proceso de planificación de métricas. Tiempo Dedicado Pregunta 7 Ge.Me.Si.02 Respuesta 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? Tiempo Dedicado Pegunta 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? Ge.Me.Ev.04 Respuesta Tiempo Dedicado Espacio Libre 215 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: ____________________________ Propósito: Recabar opinión acerca de las Guías de Reflexión como herramienta para facilitar la reflexión. 1. Nombre: _________________________________ 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 1 2 3 4 5 6 7 8 9 Muy de acuerdo De acuerdo Indiferente Pregunta Req.Eli.An.01 Req.Eli.Ap.01 Req.Eli.Ev.01 Req.Eli.Si.01 Req.An.An.01 Req.An.Ev.01 Req.Prep.Si.01 Req.Prep.Ev.01 Req.-.Ev.01 1 2 3 4 5 6 7 8 9 Muy de acuerdo De acuerdo Indiferente En desacuerdo La pregunta me instó a reflexionar detenidamente acerca de la respuesta a dar a la misma. Muy en descuerdo 3. En desacuerdo La respuesta dada a cada pregunta estuvo directamente vinculada a mi experiencia personal adquirida en el proyecto. Muy en descuerdo 2. Pregunta Req.Eli.An.01 Req.Eli.Ap.01 Req.Eli.Ev.01 Req.Eli.Si.01 Req.An.An.01 Req.An.Ev.01 Req.Prep.Si.01 Req.Prep.Ev.01 Req.-.Ev.01 216 1 2 3 4 5 6 7 8 9 De acuerdo Muy de acuerdo Muy de acuerdo De acuerdo Indiferente En desacuerdo 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. 1 2 3 4 5 6 7 8 9 6. Indiferente Pregunta Req.Eli.An.01 Req.Eli.Ap.01 Req.Eli.Ev.01 Req.Eli.Si.01 Req.An.An.01 Req.An.Ev.01 Req.Prep.Si.01 Req.Prep.Ev.01 Req.-.Ev.01 Muy en descuerdo 5. En desacuerdo Haber reflexionado y respondido a la pregunta me permitió identificar “brechas” en mis conocimientos relativos a los temas abordados en las mismas. Muy en descuerdo 4. Pregunta Req.Eli.An.01 Req.Eli.Ap.01 Req.Eli.Ev.01 Req.Eli.Si.01 Req.An.An.01 Req.An.Ev.01 Req.Prep.Si.01 Req.Prep.Ev.01 Req.-.Ev.01 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 217 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: ____________________________ Propósito: Recabar opinión acerca de las Guías de Reflexión como herramienta para facilitar la reflexión. 1. Nombre: _________________________________ 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 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 218 Muy de acuerdo De acuerdo Indiferente En desacuerdo La respuesta dada a cada pregunta estuvo directamente vinculada a mi experiencia personal adquirida en el proyecto. Muy en descuerdo 2. Muy de acuerdo De acuerdo Indiferente En desacuerdo La pregunta me instó a reflexionar detenidamente acerca de la respuesta a dar a la misma. Muy en descuerdo 3. Pregunta 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 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 Muy de acuerdo De acuerdo Indiferente En desacuerdo Haber reflexionado y respondido a la pregunta me permitió identificar “brechas” en mis conocimientos relativos a los temas abordados en las mismas. Muy en descuerdo 4. 1 Muy de acuerdo De acuerdo Indiferente En desacuerdo 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 descuerdo 5. Pregunta 6. 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 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 220 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 221 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 222 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 223 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 224 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 225 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 226 A2.7 Cuestionario de evaluación de Taller de Educción de Conocimientos y Experiencia Cuestionario de Evaluación del Taller Proyecto: ___________________________ Propósito: Recabar la opinión del participante sobre los siguientes tres aspectos del Taller de Educción de Conocimientos: • • • 1. Nombre: _________________________________ Organización (preguntas 1 a 4) Participación (preguntas 5 a 8) Contenido (pregunta 9) 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 227 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 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 228 Muy de acuerdo De acuerdo Indiferente En desacuerdo De los cuatro temas tratados en el taller, el o los más interesantes fueron: Muy en descuerdo 9. 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: Fecha: Lugar: Hora inicio: Hora fin: Analizar en forma colectiva las respuestas dadas a las preguntas de las Guías de Reflexión. __ / __ / 2007 Sala de reuniones (Salón ___) __ : __ __ : __ 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 229 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 230 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 A3.2 A3.3 Informes de Revisión de proyectos anteriores desarrollados en ORTsf Planilla de análisis de los reportes de revisión 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 Documento de Resumen de Respuestas de las guías de reflexión para Ingeniería de Requisitos 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.5 A3.6 A3.7 A3.8 A3.9 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 Documento de Resumen de Respuestas de las guías de reflexión para Métricas de Gestión de Proyecto 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) 231 A3.1 Informes de Revisión de proyectos anteriores desarrollados en ORTsf GRUPO: FECHA: EVALUADORES: Desarrollo para la Cooperativa Bancaria 22/06/2004 [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: FECHA: EVALUADORES: Lotario – Data View Generator 28/07/2004 [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) 232 GRUPO: FECHA: EVALUADORES: GDSTool 23/06/2005 [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: FECHA: EVALUADORES: ArqNet 10/06/2004 [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. 233 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: FECHA: EVALUADORES: ArqNet 05/08/2004 [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: FECHA: EVALUADORES: Métricas 16/06/2004 [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. 234 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: FECHA: EVALUADORES: Métricas 16/06/2004 [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 235 proyecto y definir el alcance. 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. 7. GRUPO: FECHA: EVALUADORES: Framework PPC 17/06/2004 [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: FECHA: EVALUADORES: MAIS 14/06/2004 [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. 236 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: FECHA: EVALUADORES: MAIS 30/08/2004 [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: FECHA: EVALUADORES: Acuario 06/09/2005 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 237 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: FECHA: EVALUADORES: Swing Improver 07/09/2005 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. 238 GRUPO: FECHA: EVALUADORES: Conquest 13/12/2005 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: FECHA: EVALUADORES: NetDealer 12/12/2005 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 239 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 240 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. 241 A3.2 Planilla de análisis de los reportes de revisión Areas de conocimiento del SWBOK Requisitos Software 1. Fundamentos 2. Proceso 3. Educción 4. Análisis 5. Especificación 6. Validación 7. Consideraciones prácticas Diseño del software 1. Fundamentos 2. Aspectos clave 3. Arquitectura y estructura software 4. Análisis y evaluación de la calidad 5. Notaciones de diseño 6. Métodos y estrategias de diseño Construcción del software Prueba del software 1. Fundamentos 2. Niveles de prueba 3. Técnicas de prueba 4. Mediciones relativas a las pruebas 5. Proceso de pruebas Gestión de Ingenieria Software 1. Iniciación y definición de alcance 2. Planificación del proyecto 3. Ejecución del proyecto 4. Revisión y evaluación 5. Cierre 6. Mediciones Proceso de Ingeniería Software 1. Implementación y cambio del proceso 2. Definición del proceso 3. Evaluación 4. Medición de productos y del proceso Mantenimiento del Software Gestión de Configuración 1. Gestión del proceso de SCM 2. Identificación de la configuración 3. Control de la configuración 4. Status de la configuración 5. Auditoría de la configuración 6. Gestión y entrega de "releases" Herramientas y Métodos Calidad del software 1. Fundamentos 2. Proceso de gestión de la calidad 3. Consideraciones prácticas Spacewars NetDealer Conquest SwingImprover Acuario Mais FrameworkPPC Parix Métricas ArqNet GDSTool Lotario ‐ DVG Análisis de frecuencia de "oportunidades de mejora" y de "sugerencias" a partir de los Informes de Revisión Coop Bancaria 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. Totales 13 x x x x x x x x x x 1 2 7 3 x x x 2 x x 2 ‐‐‐ 3 x x 2 x 1 16 x x x x x x x x x 1 9 1 1 x x x x x x x 4 4 x x 2 x x 2 ‐‐‐ 3 x x 2 x 1 ‐‐‐ 6 x x x x x Tabla A3.1: Planilla de análisis de reportes de revisión 242 x 2 4 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 243 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. 244 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. 245 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. 246 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 Respuesta ¿Qué aspectos considera usted que es importante que se tomen en cuenta a la hora de planificar una entrevista? 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 Pregunta 2 Req.Eli.Ap.01 Respuesta 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. 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 Pregunta 3 Req.Eli.Ev.01 Respuesta 15 minutos ¿Qué recomendaría usted a un ingeniero de requerimiento que se enfrenta a un usuario con necesidades poco claras? 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 Pregunta 4 Req.Eli.Si.01 Respuesta 10 minutos 10 minutos 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. 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 247 10 minutos Pregunta 5 Req.An.An.01 Respuesta En base a su experiencia, ¿qué dificultades encontró para distinguir los requerimientos funcionales de los no funcionales? 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 Pregunta 6 Req.An.Ev.01 Respuesta ¿Cómo logró superar las dificultades anteriormente expresadas? 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 Pregunta 7 Req.Prep.Si.01 Respuesta Req..Ev.01 Respuesta 5 minutos A su juicio, ¿qué habilidades personales facilitarían las tareas del ingeniero de requerimientos? 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 Pegunta 9 5 minutos 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? 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 Pegunta 8 Req.Prep.Ev.01 Respuesta 5 minutos 5 minutos 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? 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 248 10 minutos. Proyecto GESA Preguntas Pregunta 1 Req.Eli.An.01 Respuesta ¿Qué aspectos considera usted que es importante que se tomen en cuenta a la hora de planificar una entrevista? 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 Pregunta 2 Req.Eli.Ap.01 Respuesta 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. 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 Pregunta 3 Req.Eli.Ev.01 Respuesta 20 minutos. 3 minutos ¿Qué recomendaría usted a un ingeniero de requerimiento que se enfrenta a un usuario con necesidades poco claras? 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 249 5 minutos. Pregunta 4 Req.Eli.Si.01 Respuesta 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. 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 Pregunta 5 Req.An.An.01 Respuesta En base a su experiencia, ¿qué dificultades encontró para distinguir los requerimientos funcionales de los no funcionales? 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 Pregunta 6 Req.An.Ev.01 Respuesta Req.Prep.Si.01 Respuesta Investigando acerca de los mismos, en Internet y en diapositivas de semestres anteriores. 2 minutos. 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? 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 Pegunta 8 Req.Prep.Ev.01 Respuesta 3 minutos. ¿Cómo logró superar las dificultades anteriormente expresadas? Tiempo Dedicado Pregunta 7 10 minutos. 10 minutos. A su juicio, ¿qué habilidades personales facilitarían las tareas del ingeniero de requerimientos? 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 250 3 minutos. Pegunta 9 Req..Ev.01 Respuesta 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? 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 Respuesta ¿Qué aspectos considera usted que es importante que se tomen en cuenta a la hora de planificar una entrevista? 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 Pregunta 2 Req.Eli.Ap.01 Respuesta 5 minutos 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. 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 251 5 minutos Pregunta 3 Req.Eli.Ev.01 Respuesta ¿Qué recomendaría usted a un ingeniero de requerimiento que se enfrenta a un usuario con necesidades poco claras? 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 Pregunta 4 Req.Eli.Si.01 Respuesta 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. 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 Pregunta 5 Req.An.An.01 Respuesta Req.Prep.Si.01 Respuesta 0 minutos 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? 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 Pegunta 8 Req.Prep.Ev.01 Respuesta 1 minuto ¿Cómo logró superar las dificultades anteriormente expresadas? Tiempo Dedicado Pregunta 7 5 minutos En base a su experiencia, ¿qué dificultades encontró para distinguir los requerimientos funcionales de los no funcionales? No se encontraron dificultades en este tema. Tiempo Dedicado Pregunta 6 Req.An.Ev.01 Respuesta 5 minutos 10 minutos A su juicio, ¿qué habilidades personales facilitarían las tareas del ingeniero de requerimientos? La organización, la comunicación con otros, la proactividad, conocer el dominio, ponerse del lado del cliente. Tiempo Dedicado 252 5 minutos Pegunta 9 Req..Ev.01 Respuesta 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? 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 Respuesta ¿Qué aspectos considera usted que es importante que se tomen en cuenta a la hora de planificar una entrevista? 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 Pregunta 2 Req.Eli.Ap.01 Respuesta 15 min 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. 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. 253 Tiempo Dedicado Pregunta 3 Req.Eli.Ev.01 Respuesta ¿Qué recomendaría usted a un ingeniero de requerimiento que se enfrenta a un usuario con necesidades poco claras? 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 Pregunta 4 Req.Eli.Si.01 Respuesta 10 min 5 min 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. 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 Pregunta 6 Req.An.Ev.01 Respuesta 5 min ¿Cómo logró superar las dificultades anteriormente expresadas? No hubo dificultades. Tiempo Dedicado 254 0 min Pregunta 7 Req.Prep.Si.01 Respuesta 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? 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 requerimientos? Respuesta Comunicación, entendimiento, comprensión, expresión, disponibilidad, detallista, analítico. Tiempo Dedicado Pegunta 9 Req..Ev.01 Respuesta de 2 min 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? 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 255 0 minutos. 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. 256 Proyecto 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. 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 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, 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. 257 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. 258 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 InvPortal No 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 InvPortal Comunicación, Entendimiento, Comprensión, Expresión, Disponibilidad, Detallista, Analítico. 259 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. 260 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: Nombre: Sistema Gestión COODESOR Daniel Nicolich Propósito: Recabar opinión acerca de las Guías de Reflexión como herramienta para facilitar la reflexión. 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. X Muy de acuerdo De acuerdo Indiferente La respuesta dada a cada pregunta estuvo directamente vinculada a mi experiencia personal adquirida en el proyecto. Muy en descuerdo 2. Muy en desacuerdo En desacuerdo Indiferente De acuerdo Muy de acuerdo En desacuerdo 1. Pregunta 1 Req.Eli.An.01 X 2 Req.Eli.Ap.01 X 3 Req.Eli.Ev.01 4 Req.Eli.Si.01 X X 5 Req.An.An.01 X 6 Req.An.Ev.01 7 Req.Prep.Si.01 X X 8 Req.Prep.Ev.01 X 9 Req.-.Ev.01 X 261 Muy de acuerdo De acuerdo Indiferente En desacuerdo La pregunta me instó a reflexionar detenidamente acerca de la respuesta a dar a la misma. Muy en descuerdo 3. Pregunta Req.Eli.An.01 X 2 Req.Eli.Ap.01 X 3 Req.Eli.Ev.01 4 Req.Eli.Si.01 5 Req.An.An.01 6 Req.An.Ev.01 X 7 Req.Prep.Si.01 X 8 Req.Prep.Ev.01 X 9 Req.-.Ev.01 X X X X Muy de acuerdo De acuerdo Indiferente En desacuerdo Haber reflexionado y respondido a la pregunta me permitió identificar “brechas” en mis conocimientos relativos a los temas abordados en las mismas. Muy en descuerdo 4. 1 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 X X X X X 6 Req.An.Ev.01 7 Req.Prep.Si.01 X X 8 Req.Prep.Ev.01 X 9 Req.-.Ev.01 X 262 Muy de acuerdo De acuerdo Indiferente En desacuerdo 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 descuerdo 5. Pregunta 6. 1 Req.Eli.An.01 X 2 Req.Eli.Ap.01 X 3 Req.Eli.Ev.01 X 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 X X X X X X 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 X Cuestionario de Evaluación de la Guía de Reflexión – Ingeniería de Requisitos Proyecto: Nombre: GESA 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 263 Muy de acuerdo De acuerdo Indiferente En desacuerdo La respuesta dada a cada pregunta estuvo directamente vinculada a mi experiencia personal adquirida en el proyecto. Muy en descuerdo 2. Pregunta 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 Muy de acuerdo De acuerdo Indiferente En desacuerdo La pregunta me instó a reflexionar detenidamente acerca de la respuesta a dar a la misma. Muy en descuerdo 3. 1 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 264 Muy de acuerdo De acuerdo Indiferente En desacuerdo Haber reflexionado y respondido a la pregunta me permitió identificar “brechas” en mis conocimientos relativos a los temas abordados en las mismas. Muy en descuerdo 4. Pregunta 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 Muy de acuerdo De acuerdo Indiferente En desacuerdo 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 descuerdo 5. 1 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 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: Nombre: SCPI (Seguimiento y Control de Proyectos de Inversión) Andrés Lapachian Propósito: Recabar opinión acerca de las Guías de Reflexión como herramienta para facilitar la reflexión. 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. X Muy de acuerdo De acuerdo Indiferente La respuesta dada a cada pregunta estuvo directamente vinculada a mi experiencia personal adquirida en el proyecto. Muy en descuerdo 2. Muy en desacuerdo En desacuerdo Indiferente De acuerdo Muy de acuerdo En desacuerdo 1. 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 266 Muy de acuerdo De acuerdo Indiferente En desacuerdo La pregunta me instó a reflexionar detenidamente acerca de la respuesta a dar a la misma. Muy en descuerdo 3. Pregunta 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 8 Req.Prep.Ev.01 9 Req.-.Ev.01 X X X Pregunta 1 Req.Eli.An.01 X 2 Req.Eli.Ap.01 X 3 Req.Eli.Ev.01 4 Req.Eli.Si.01 X 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 Muy de acuerdo De acuerdo Indiferente En desacuerdo Haber reflexionado y respondido a la pregunta me permitió identificar “brechas” en mis conocimientos relativos a los temas abordados en las mismas. Muy en descuerdo 4. 1 Muy de acuerdo De acuerdo Indiferente En desacuerdo 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 descuerdo 5. Pregunta 6. 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 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. X 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: Nombre: InvPortal (Sitio Web del Estado para la Inversión Privada) 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. X Muy en desacuerdo En desacuerdo Indiferente De acuerdo Muy de acuerdo 268 Muy de acuerdo De acuerdo Indiferente En desacuerdo La respuesta dada a cada pregunta estuvo directamente vinculada a mi experiencia personal adquirida en el proyecto. Muy en descuerdo 2. Pregunta Req.Eli.An.01 2 Req.Eli.Ap.01 X X 3 Req.Eli.Ev.01 X 4 Req.Eli.Si.01 X 5 Req.An.An.01 X 6 Req.An.Ev.01 7 Req.Prep.Si.01 X 8 Req.Prep.Ev.01 X 9 Req.-.Ev.01 X X Muy de acuerdo De acuerdo Indiferente En desacuerdo La pregunta me instó a reflexionar detenidamente acerca de la respuesta a dar a la misma. Muy en descuerdo 3. 1 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 7 Req.Prep.Si.01 X X 8 Req.Prep.Ev.01 X 9 Req.-.Ev.01 X 269 Muy de acuerdo De acuerdo Indiferente En desacuerdo Haber reflexionado y respondido a la pregunta me permitió identificar “brechas” en mis conocimientos relativos a los temas abordados en las mismas. Muy en descuerdo 4. Pregunta Req.Eli.An.01 2 Req.Eli.Ap.01 X 3 Req.Eli.Ev.01 X 4 Req.Eli.Si.01 X 5 Req.An.An.01 6 Req.An.Ev.01 X 7 Req.Prep.Si.01 X 8 Req.Prep.Ev.01 9 Req.-.Ev.01 X X X X Muy de acuerdo De acuerdo Indiferente En desacuerdo 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 descuerdo 5. 1 Pregunta 1 Req.Eli.An.01 X 2 Req.Eli.Ap.01 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 8 Req.Prep.Ev.01 X 9 Req.-.Ev.01 X X X 270 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. X Muy en desacuerdo En desacuerdo Indiferente De acuerdo Muy de acuerdo 271 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 Respuesta ¿Qué métricas planificó recolectar para su proyecto? ¿Por qué considera que estas métricas son adecuadas para su proyecto en particular? 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 Pregunta 2 Ge.Me.Ap.01 Respuesta ¿Cómo llevó a cabo el análisis de los datos obtenidos a partir de la recolección de las métricas? 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 Pregunta 3 Ge.Me.An.01 Respuesta 10 min En base a su experiencia, ¿qué dificultades encontró para identificar las métricas que son útiles para su proyecto en particular? 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 Pregunta 4 Ge.Me.Ev.02 Respuesta 5 min 5 min ¿Cómo logró superar las dificultades anteriormente expresadas? 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 272 15 min Pregunta 5 Ge.Me.Ev.03 Respuesta ¿Qué aconsejaría usted hacer para asegurar que las métricas seleccionadas son las adecuadas para un proyecto en particular? 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 Pregunta 6 Ge.Me.Si.01 Respuesta Relate, en no menos de cuatro o cinco líneas, las lecciones aprendidas durante el proceso de planificación de métricas. 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 Pregunta 7 Ge.Me.Si.02 Respuesta Ge.Me.Ev.04 Respuesta 10 min 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? 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 Pegunta 8 20 min 10 min 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? 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 Espacio Libre 273 15 min Proyecto GESA Preguntas Pregunta 1 Ge.Me.Ev.01 Respuesta ¿Qué métricas planificó recolectar para su proyecto? ¿Por qué considera que estas métricas son adecuadas para su proyecto en particular? 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 Pregunta 2 Ge.Me.Ap.01 Respuesta ¿Cómo llevó a cabo el análisis de los datos obtenidos a partir de la recolección de las métricas? 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 Pregunta 3 Ge.Me.An.01 Respuesta 5’ En base a su experiencia, ¿qué dificultades encontró para identificar las métricas que son útiles para su proyecto en particular? 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 Pregunta 4 Ge.Me.Ev.02 Respuesta 13 ‘ 10‘ ¿Cómo logró superar las dificultades anteriormente expresadas? 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 274 5’ Pregunta 5 Ge.Me.Ev.03 Respuesta ¿Qué aconsejaría usted hacer para asegurar que las métricas seleccionadas son las adecuadas para un proyecto en particular? 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 Pregunta 6 Ge.Me.Si.01 Respuesta Relate, en no menos de cuatro o cinco líneas, las lecciones prendidas durante el proceso de planificación de métricas. 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 Pregunta 7 Ge.Me.Si.02 Respuesta Ge.Me.Ev.04 Respuesta 5’ 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? 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 Pegunta 8 5’ 3’ 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? 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 Respuesta ¿Qué métricas planificó recolectar para su proyecto? ¿Por qué considera que estas métricas son adecuadas para su proyecto en particular? 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 275 15 min Pregunta 2 Ge.Me.Ap.01 Respuesta ¿Cómo llevó a cabo el análisis de los datos obtenidos a partir de la recolección de las métricas? 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 Pregunta 3 Ge.Me.An.01 Respuesta En base a su experiencia, ¿qué dificultades encontró para identificar las métricas que son útiles para su proyecto en particular? 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 Pregunta 4 Ge.Me.Ev.02 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). Ge.Me.Si.02 Respuesta 10 min Relate, en no menos de cuatro o cinco líneas, las lecciones aprendidas durante el proceso de planificación de métricas. 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 Pregunta 7 5 min ¿Qué aconsejaría usted hacer para asegurar que las métricas seleccionadas son las adecuadas para un proyecto en particular? 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 Pregunta 6 Ge.Me.Si.01 Respuesta 10 min ¿Cómo logró superar las dificultades anteriormente expresadas? Tiempo Dedicado Pregunta 5 Ge.Me.Ev.03 Respuesta 5 min 5 min 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? 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 276 10 min Pegunta 8 Ge.Me.Ev.04 Respuesta 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? 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 Espacio Libre 277 10 min 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. 278 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 279 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 … 280 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 281 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 Propósito: Recabar opinión acerca de las Guías de Reflexión como herramienta para facilitar la reflexión. 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. X 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 282 Muy de acuerdo De acuerdo Indiferente La respuesta dada a cada pregunta estuvo directamente vinculada a mi experiencia personal adquirida en el proyecto. Muy en descuerdo 2. Muy en desacuerdo En desacuerdo Indiferente De acuerdo Muy de acuerdo En desacuerdo 1. Nombre: Muy de acuerdo De acuerdo Indiferente En desacuerdo La pregunta me instó a reflexionar detenidamente acerca de la respuesta a dar a la misma. Muy en descuerdo 3. Pregunta 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 X X X X X X X X Pregunta 1 Ge.Me.Ev.01 2 Ge.Me.Ap.01 3 Ge.Me.An.01 4 Ge.Me.Ev.02 X 5 Ge.Me.Ev.03 X 6 Ge.Me.Si.01 7 Ge.Me.Si.02 8 Ge.Me.Ev.04 X X X X X X 283 Muy de acuerdo De acuerdo Indiferente En desacuerdo Haber reflexionado y respondido a la pregunta me permitió identificar “brechas” en mis conocimientos relativos a los temas abordados en las mismas. Muy en descuerdo 4. 1 Muy de acuerdo De acuerdo Indiferente En desacuerdo 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 descuerdo 5. Pregunta 6. 1 Ge.Me.Ev.01 2 Ge.Me.Ap.01 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 8 Ge.Me.Ev.04 X X X X 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. X Muy en desacuerdo En desacuerdo Indiferente De acuerdo Muy de acuerdo Cuestionario de Evaluación de las Guías de Reflexión – Métricas de Proyecto Proyecto: GESA Propósito: Recabar opinión acerca de las Guías de Reflexión como herramienta para facilitar la reflexión. 1. Nombre: 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. X Muy en desacuerdo En desacuerdo Indiferente De acuerdo Muy de acuerdo 284 Muy de acuerdo De acuerdo Indiferente En desacuerdo La respuesta dada a cada pregunta estuvo directamente vinculada a mi experiencia personal adquirida en el proyecto. Muy en descuerdo 2. Pregunta 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 Muy de acuerdo De acuerdo Indiferente En desacuerdo La pregunta me instó a reflexionar detenidamente acerca de la respuesta a dar a la misma. Muy en descuerdo 3. 1 Pregunta 1 Ge.Me.Ev.01 X 2 Ge.Me.Ap.01 X 3 Ge.Me.An.01 X 4 Ge.Me.Ev.02 5 Ge.Me.Ev.03 X X 6 Ge.Me.Si.01 X 7 Ge.Me.Si.02 X 8 Ge.Me.Ev.04 X 285 Muy de acuerdo De acuerdo Indiferente En desacuerdo Haber reflexionado y respondido a la pregunta me permitió identificar “brechas” en mis conocimientos relativos a los temas abordados en las mismas. Muy en descuerdo 4. Pregunta Ge.Me.Ev.01 2 Ge.Me.Ap.01 X 3 Ge.Me.An.01 4 Ge.Me.Ev.02 X 5 Ge.Me.Ev.03 X 6 Ge.Me.Si.01 X X X 7 Ge.Me.Si.02 X 8 Ge.Me.Ev.04 X Muy de acuerdo De acuerdo Indiferente En desacuerdo 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 descuerdo 5. 1 Pregunta 6. 1 Ge.Me.Ev.01 2 Ge.Me.Ap.01 3 Ge.Me.An.01 4 Ge.Me.Ev.02 X 5 Ge.Me.Ev.03 X 6 Ge.Me.Si.01 7 Ge.Me.Si.02 8 Ge.Me.Ev.04 X X X X X X 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. X Muy en desacuerdo En desacuerdo Indiferente De acuerdo Muy de acuerdo 286 Cuestionario de Evaluación de las Guías de Reflexión – Métricas de Proyecto Proyecto: SCPI Propósito: Recabar opinión acerca de las Guías de Reflexión como herramienta para facilitar la reflexión. 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. X Muy de acuerdo De acuerdo Indiferente La respuesta dada a cada pregunta estuvo directamente vinculada a mi experiencia personal adquirida en el proyecto. Muy en descuerdo 2. Muy en desacuerdo En desacuerdo Indiferente De acuerdo Muy de acuerdo En desacuerdo 1. Nombre: 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 287 Muy de acuerdo De acuerdo Indiferente En desacuerdo La pregunta me instó a reflexionar detenidamente acerca de la respuesta a dar a la misma. Muy en descuerdo 3. Pregunta Ge.Me.Ev.01 X 2 Ge.Me.Ap.01 X 3 Ge.Me.An.01 4 Ge.Me.Ev.02 5 Ge.Me.Ev.03 6 Ge.Me.Si.01 X 7 Ge.Me.Si.02 X 8 Ge.Me.Ev.04 X X X X Muy de acuerdo De acuerdo Indiferente En desacuerdo Haber reflexionado y respondido a la pregunta me permitió identificar “brechas” en mis conocimientos relativos a los temas abordados en las mismas. Muy en descuerdo 4. 1 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 6 Ge.Me.Si.01 7 Ge.Me.Si.02 8 Ge.Me.Ev.04 X X X X 288 Muy de acuerdo De acuerdo Indiferente En desacuerdo 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 descuerdo 5. Pregunta 6. 1 Ge.Me.Ev.01 X 2 Ge.Me.Ap.01 X 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 X X X X X X 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. X Muy en desacuerdo En desacuerdo Indiferente De acuerdo Muy de acuerdo 289 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: Lugar: Hora inicio: Hora fin: Asistentes: 27 / 08 / 2007 Sala de reuniones 2do piso 20:00 21:00 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. 290 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: Nombre: Sistema de Gestión COODESOR Daniel Nicolich Propósito: Recabar la opinión del participante sobre los siguientes tres aspectos del Taller de Educción de Conocimientos: • • • 1. Los objetivos del taller estuvieron claramente definidos. X 2. Muy en desacuerdo En desacuerdo Indiferente De acuerdo Muy de acuerdo El lugar físico elegido para realizar el taller fue adecuado. X 5. Muy en desacuerdo En desacuerdo Indiferente De acuerdo Muy de acuerdo El material recibido como insumo para la realización del taller fue satisfactorio en cuanto a su estructura y contenido. X 4. Muy en desacuerdo En desacuerdo Indiferente De acuerdo Muy de acuerdo La duración del taller fue adecuada. X 3. Organización (preguntas 1 a 4) Participación (preguntas 5 a 8) Contenido (pregunta 9) Muy en desacuerdo En desacuerdo Indiferente De acuerdo Muy de acuerdo Valoro como muy positivo el haber podido conocer y discutir, durante el taller, las experiencias de los otros participantes. X Muy en desacuerdo En desacuerdo Indiferente De acuerdo Muy de acuerdo 291 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 X 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 X En general, considero que el taller fue una experiencia positiva. Muy en desacuerdo En desacuerdo Indiferente De acuerdo Muy de acuerdo X Muy de acuerdo De los cuatro temas tratados en el taller, el o los más interesantes fueron: Muy en descuerdo 9. De acuerdo 8. Indiferente 7. En desacuerdo 6. 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: Nombre: GESA 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) 292 1. Los objetivos del taller estuvieron claramente definidos. 2. La duración del taller fue adecuada. 3. Muy en desacuerdo En desacuerdo Indiferente De acuerdo Muy de acuerdo Con la participación en el taller considero que he aumentado mis conocimientos sobre los temas tratados en el mismo. 7. Muy en desacuerdo En desacuerdo Indiferente De acuerdo Muy de acuerdo Valoro como muy positivo el haber podido conocer y discutir, durante el taller, las experiencias de los otros participantes. 6. Muy en desacuerdo En desacuerdo Indiferente De acuerdo Muy de acuerdo El lugar físico elegido para realizar el taller fue adecuado. 5. Muy en desacuerdo En desacuerdo Indiferente De acuerdo Muy de acuerdo El material recibido como insumo para la realización del taller fue satisfactorio en cuanto a su estructura y contenido. 4. Muy en desacuerdo En desacuerdo Indiferente De acuerdo Muy de acuerdo Muy en desacuerdo En desacuerdo Indiferente De acuerdo Muy de acuerdo 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 293 En general, considero que el taller fue una experiencia positiva. 1 2 Tema Planificación de entrevistas Interacción con el entrevistado x 3 Habilidades personales del Ing. de Req x 4 Entrenamiento inicial sobre Ing. de Req. Muy de acuerdo De acuerdo Indiferente De los cuatro temas tratados en el taller, el o los más interesantes fueron: Muy en descuerdo 9. Muy en desacuerdo En desacuerdo Indiferente De acuerdo Muy de acuerdo En desacuerdo 8. x x Cuestionario de Evaluación del Taller Proyecto: Nombre: SCPI (Seguimiento y Control de Proyectos de Inversión) Andrés Lapachian Propósito: Recabar la opinión del participante sobre los siguientes tres aspectos del Taller de Educción de Conocimientos: • • • 1. Los objetivos del taller estuvieron claramente definidos. X 2. Organización (preguntas 1 a 4) Participación (preguntas 5 a 8) Contenido (pregunta 9) Muy en desacuerdo En desacuerdo Indiferente De acuerdo Muy de acuerdo La duración del taller fue adecuada. X Muy en desacuerdo En desacuerdo Indiferente De acuerdo Muy de acuerdo 294 3. El material recibido como insumo para la realización del taller fue satisfactorio en cuanto a su estructura y contenido. X 4. El lugar físico elegido para realizar el taller fue adecuado. X 5. Muy en desacuerdo En desacuerdo Indiferente De acuerdo Muy de acuerdo Los conocimientos adquiridos en el taller me permitirán realizar un mejor desempeño en proyectos futuros. X 8. Muy en desacuerdo En desacuerdo Indiferente De acuerdo Muy de acuerdo Con la participación en el taller considero que he aumentado mis conocimientos sobre los temas tratados en el mismo. X 7. Muy en desacuerdo En desacuerdo Indiferente De acuerdo Muy de acuerdo Valoro como muy positivo el haber podido conocer y discutir, durante el taller, las experiencias de los otros participantes. X 6. Muy en desacuerdo En desacuerdo Indiferente De acuerdo Muy de acuerdo Muy en desacuerdo En desacuerdo Indiferente De acuerdo Muy de acuerdo En general, considero que el taller fue una experiencia positiva. X Muy en desacuerdo En desacuerdo Indiferente De acuerdo Muy de acuerdo 295 Muy de acuerdo De acuerdo Indiferente En desacuerdo De los cuatro temas tratados en el taller, el o los más interesantes fueron: Muy en descuerdo 9. Tema 1 Planificación de entrevistas X 2 Interacción con el entrevistado 3 Habilidades personales del Ing. de Req X 4 Entrenamiento inicial sobre Ing. de Req. 296 X X A3.12 Resumen de reuniones del GGCA Fecha 17/04 Inicio 18:00 Fin 19:30 24/04 18:00 19:00 30/4 18:00 19:30 4/5 18:30 20:15 11/5 10:00 12:30 16/5 18:30 20:30 25/5 18:30 20:30 30/5 19:00 20:15 4/6 19:00 20:00 11/6 19:00 20:00 15/6 18:30 19:15 24/6 Asuntos 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”. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 297 30/6 19:00 20:30 4/7 20:00 21:15 11/7 19:30 20:30 18/7 19:00 20:00 8/8 19:00 19:45 15/8 19:00 21:00 22/8 18:30 21:00 27/8 20:00 21:00 3/9 18:30 21:00 10/9 18:30 21:30 20/9 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. 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. 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. 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. 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. 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. 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. 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. 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. Se recibieron respondidos los cuestionarios de evaluación del taller y se confeccionaron las planillas para procesarlos. 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. 298 27/9 19:00 20:00 3/10 19:00 19:30 10/10 18:00 21: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. 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. 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. 299 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. 300 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 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. 3 Í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 1.2.2 1.2.3 Motivación .................................................................................................... 9 Propósito ...................................................................................................... 9 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 2.2.2 2.2.3 2.2.4 2.2.5 Alcance....................................................................................................... 12 Descripción del cliente................................................................................ 12 Usuarios ..................................................................................................... 13 Alcance del proyecto .................................................................................. 13 Resultados obtenidos ................................................................................. 14 2.3 DESCRIPCIÓN DEL GRUPO .....................................................................14 2.4 DESCRIPCIÓN DEL PROCESO UTILIZADO ............................................15 2.4.1 2.4.2 Narración del proceso ................................................................................ 15 Problemas y cambios ................................................................................. 16 CAPITULO 3 - INGENIERÍA DE REQUERIMIENTOS ..........................17 3.1 INTRODUCCIÓN ........................................................................................17 3.1.1 3.1.2 3.1.3 3.1.4 3.2 Estudio de Factibilidad ............................................................................... 17 Obtención y Análisis de Requerimientos.................................................... 18 Validación de Requerimientos.................................................................... 19 Administración de Requerimientos............................................................. 19 DESCRIPCIÓN DEL PROBLEMA..............................................................20 3.2.1 3.2.2 3.2.3 Descripción del Cliente............................................................................... 20 El problema planteado por el cliente .......................................................... 21 Factibilidad del proyecto............................................................................. 21 4 3.3 ESTRATEGIA DE RELEVAMIENTO..........................................................22 3.3.1 Obtención y Análisis de Requerimientos.................................................... 22 3.3.1.1 3.3.1.2 3.3.1.3 3.3.1.4 3.3.2 Lista de elementos a relevar ....................................................................22 Entrevista con usuarios del sistema.........................................................22 Encuestas a los odontólogos ...................................................................23 Relevamiento directo del sistema actual de COODESOR ......................23 Seguimiento y validación de los requerimientos ........................................ 24 3.3.2.1 3.3.2.2 Validación de documentos por parte del cliente ......................................24 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 3.5.1.2 3.5.1.3 3.5.1.4 3.5.1.5 3.5.2 3.5.3 Restricciones del sistema........................................................................... 28 Requerimientos del sistema ....................................................................... 28 3.5.3.1 3.5.3.2 3.5.4 3.5.5 Requerimientos funcionales.....................................................................28 Requerimientos no funcionales................................................................29 Casos de uso.............................................................................................. 29 Criterio de priorización de requerimientos.................................................. 29 3.5.5.1 3.5.5.2 3.5.5.3 3.5.5.4 3.5.5.5 3.6 Gestión de Afiliados .................................................................................27 Gestión Odontológica...............................................................................27 Gestión Contable......................................................................................27 Gestión de Stocks ....................................................................................27 Otras Gestiones .......................................................................................27 Importancia de los distintos procesos del cliente.....................................29 Elementos críticos del sistema actual ......................................................30 Precedencia de los casos de uso ............................................................30 Evaluación en base al cálculo de Puntos de Función..............................30 Dificultad aparente de los requerimientos................................................30 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 4.2.2 Descripción de las principales tecnologías a utilizar .................................. 33 Microsoft Visual Basic .NET (dot Net) ........................................................ 33 4.2.2.1 4.2.2.2 4.2.3 Microsoft SQL Server Desktop Engine (MSDE) ......................................... 34 4.2.3.1 4.2.3.2 4.2.4 4.3 Características de la herramienta ............................................................33 Esquema de Arquitectura de la herramienta ...........................................34 Características del MSDE 2000 ...............................................................34 Limitaciones del MSDE 2000 ...................................................................34 Diagramas de Clases del SGC................................................................... 36 SOLUCIÓN PARA LA MIGRACIÓN DE DATOS .......................................47 4.3.1 4.3.2 Proceso de Migración de Datos ................................................................. 47 Microsoft Visual Basic 6 (Migración de datos)............................................ 47 4.3.2.1 4.3.2.2 4.3.2.3 4.3.3 Características de la herramienta ............................................................47 Limitaciones de la herramienta ................................................................47 Archivos generados..................................................................................48 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 5 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 5.2.1.2 5.2.1.3 5.2.1.4 5.2.1.5 5.2.1.6 5.2.1.7 5.2.2 5.2.3 5.2.4 5.3 Ciclo de SQA .............................................................................................. 53 Criterio de aprobación de los documentos ................................................. 53 Estándares y Normativas establecidos ...................................................... 53 PRODUCTOS RESULTANTES DE LAS ACTIVIDADES DE SQA ............54 5.3.1 5.3.2 5.3.3 5.3.4 5.4 Actividades iniciales del proyecto ............................................................51 Actividades al inicio de cada nueva iteración ..........................................51 Actividades independientes de la fase.....................................................51 Fase 1: Relevamiento de Requerimientos y Análisis...............................51 Fase 2: Diseño .........................................................................................52 Fase 3: Construcción ...............................................................................52 Fase 4: Testing.........................................................................................52 Plan de Calidad .......................................................................................... 54 Reporte de Métricas ................................................................................... 66 Plan de Testing y casos de prueba ............................................................ 66 Estándares y encuestas al cliente .............................................................. 66 RESULTADOS DE LAS ACTIVIDADES DE SQA......................................67 5.4.1 5.4.2 5.4.3 Atributos de calidad del producto ESRE .................................................... 67 Ausencia de defectos ................................................................................. 72 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 6.2.2 6.2.3 6.3 Comunicación............................................................................................. 83 Criterios de versionado............................................................................... 83 Repositorio de componentes...................................................................... 84 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 7.3.2 Alcance del proyecto .................................................................................. 89 Accionistas ................................................................................................. 89 7.3.2.1 7.3.2.2 Cliente ......................................................................................................89 Equipo de desarrollo ................................................................................89 6 7.3.3 7.3.4 7.3.5 7.3.6 7.3.7 Requerimientos funcionales del producto .................................................. 90 Requerimientos del sistema ....................................................................... 90 Actores del sistema .................................................................................... 90 Medidas de éxito ........................................................................................ 90 Calendario .................................................................................................. 90 7.3.7.1 7.3.8 7.3.9 7.3.10 7.3.11 Ciclo de Vida ............................................................................................90 WBS de tareas ........................................................................................... 91 WBS de productos...................................................................................... 93 Cronograma................................................................................................ 94 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 7.5.2 7.6 Recursos Humanos .................................................................................... 98 Recursos Materiales................................................................................... 98 PRESUPUESTO .........................................................................................98 7.6.1 7.6.2 Costo x rol .................................................................................................. 98 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 7 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 8 7.6.2 Horas x rol Rol Horas Gerente 95 SQA 67 Arquitecto 82 Analista 372 Desarrollador, SCM. Tester 756 TOTAL 1371 Horas x Rol 1400 1200 1000 800 600 400 200 0 To t al s ar r An oll al i ad Ar s t a or, qu i tec SQ SC to M. A Horas De Ge re nt e Te ... El costo final del proyecto asciende a la suma de U$S 12.323 99 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 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. 2 Sistema de Gestión de Acreditaciones Índice 1. GLOSARIO........................................................................................................................... 5 2. INTRODUCCIÓN.................................................................................................................. 6 2.1. 2.2. 3. DESCRIPCIÓN DEL PROYECTO ....................................................................................... 7 3.1. 3.2. 3.3. 3.4. 3.5. 3.6. 4. INTRODUCCIÓN............................................................................................................. 50 DEFINICIÓN DEL PLAN DE TESTING ................................................................................ 50 ESTRATEGIA DE TESTING .............................................................................................. 50 MODALIDADES DE TESTING ........................................................................................... 53 CASOS DE PRUEBAS ..................................................................................................... 54 RESULTADOS DE LAS PRUEBAS ..................................................................................... 55 SQA .................................................................................................................................... 56 8.1. 8.2. 8.3. 8.4. 8.5. 8.6. 9. INTRODUCCIÓN............................................................................................................. 49 HERRAMIENTAS UTILIZADAS PARA EL DESARROLLO......................................................... 49 TESTING ............................................................................................................................ 50 7.1. 7.2. 7.3. 7.4. 7.5. 7.6. 8. INTRODUCCIÓN............................................................................................................. 31 DESCRIPCIÓN DE LA SOLUCIÓN...................................................................................... 31 ESTRATEGIA DE DESARROLLO ....................................................................................... 48 AMBIENTE DE DESARROLLO......................................................................................... 49 6.1. 6.2. 7. INTRODUCCIÓN............................................................................................................. 15 DESCRIPCIÓN DEL PROBLEMA ....................................................................................... 15 CLIENTES Y USUARIOS ................................................................................................. 19 DESCRIPCIÓN DEL SISTEMA DE SOFTWARE..................................................................... 21 ESTRATEGIA DE RELEVAMIENTO .................................................................................... 24 ANÁLISIS DE LAS DIFICULTADES DURANTE EL RELEVAMIENTO .......................................... 25 ESPECIFICACIÓN DE REQUERIMIENTOS .......................................................................... 26 REQUERIMIENTOS NO IMPLEMENTADOS ......................................................................... 27 DISEÑO ARQUITECTÓNICO ............................................................................................ 31 5.1. 5.2. 5.3. 6. INTRODUCCIÓN............................................................................................................... 7 DESCRIPCIÓN GENERAL DEL PROYECTO........................................................................... 8 ALCANCE DEL PROYECTO................................................................................................ 9 LIMITACIONES .............................................................................................................. 10 DESCRIPCIÓN DEL GRUPO ............................................................................................. 10 DESCRIPCIÓN DEL PROCESO UTILIZADO ......................................................................... 11 INGENIERÍA DE REQUERIMIENTOS............................................................................... 15 4.1. 4.2. 4.3. 4.4. 4.5. 4.6. 4.7. 4.8. 5. ENTORNO CONCEPTUAL DE SOFTWARE FACTORY Y SUS OBJETIVOS.................................. 6 INTRODUCCIÓN AL PROYECTO ......................................................................................... 6 INTRODUCCIÓN............................................................................................................. 56 ENFOQUE DE CALIDAD .................................................................................................. 56 CALIDAD DEL PRODUCTO .............................................................................................. 56 PRODUCTOS RESULTANTES DE LA ACTIVIDAD DE SQA.................................................... 64 CALIDAD DEL PROCESO DE DESARROLLO ....................................................................... 67 MÉTRICAS .................................................................................................................... 67 SCM .................................................................................................................................... 70 9.1. 9.2. 9.3. 9.4. 9.5. INTRODUCCIÓN............................................................................................................. 70 DESCRIPCIÓN Y JUSTIFICACIÓN DEL PROCESO DE SCM.................................................. 70 PRODUCTOS RESULTANTES DE LA ACTIVIDAD DE SCM ................................................... 71 SELECCIÓN DE LA HERRAMIENTA SVN........................................................................... 72 PROBLEMAS ENCONTRADOS Y ACCIONES TOMADAS DURANTE LA EJECUCIÓN DE LA ACTIVIDAD ................................................................................................................................. 72 3 Sistema de Gestión de Acreditaciones 10. GERENCIA......................................................................................................................... 74 10.1. 10.2. 10.3. 10.4. 10.5. INTRODUCCIÓN............................................................................................................. 74 PROCESO DE GERENCIA................................................................................................ 75 ACTIVIDADES................................................................................................................ 75 AVANCE DE FASES ...................................................................................................... 100 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. 14.2. 14.3. 14.4. 14.5. 14.6. 14.7. 14.8. 14.9. 14.10. 14.11. 14.12. 14.13. 14.14. 14.15. 14.16. 14.17. 14.18. 14.19. 14.20. 14.21. 14.22. 14.23. 14.24. 14.25. 14.26. 14.27. 14.28. ANEXO 1: ATRIBUTOS DE CALIDAD PARA EL ESRE ....................................................... 120 ANEXO 2: ATRIBUTOS DE CALIDAD PARA LA DOCUMENTACIÓN ....................................... 122 ANEXO 3: ATRIBUTOS DE CALIDAD PARA LA CODIFICACIÓN ............................................ 124 ANEXO 4: ATRIBUTOS DE CALIDAD PARA LA ARQUITECTURA .......................................... 125 ANEXO 5: PLAN DE V&V ............................................................................................. 126 ANEXO 6: PLAN DE TESTING ........................................................................................ 130 ANEXO 7: JUSTIFICACIÓN DEL PLAN DE CALIDAD .......................................................... 135 ANEXO 8: ESPECIFICACIÓN DE REQUERIMIENTOS ......................................................... 136 ANEXO 9: REQUERIMIENTOS FUNCIONALES DETALLADOS .............................................. 150 ANEXO 10: ELECCIÓN DEL CICLO DE VIDA .................................................................... 162 ANEXO 11: DIAGRAMA DE ACTIVIDAD ........................................................................... 165 ANEXO 12: GUÍA PARA ENTREVISTAS ........................................................................... 168 ANEXO 13: ACTA DE REUNIÓN CON CLIENTE................................................................. 171 ANEXO 14: EVALUACIÓN DEL MANEJADOR DE BASE DE DATOS ...................................... 173 ANEXO 15: PLANILLA DE DETECCIÓN Y SEGUIMIENTO DE ERRORES................................ 178 ANEXO 16: PLAN DE CALIDAD ...................................................................................... 179 ANEXO 17: ESTÁNDAR DE CODIFICACIÓN ..................................................................... 182 ANEXO 18: PLANILLA DE CONTACTO ............................................................................ 186 ANEXO 19: PLANILLA DE COSTOS HORA POR ROL ......................................................... 187 ANEXO 20: ANÁLISIS DE RIESGOS ............................................................................... 188 ANEXO 21: CRONOGRAMA INICIAL ............................................................................... 206 ANEXO 22: CRONOGRAMA REAL .................................................................................. 208 ANEXO 23: PLANILLA DE TAREAS ................................................................................. 210 ANEXO 24: PLANIFICACIÓN DESARROLLO - ESTIMADO ................................................... 211 ANEXO 25: PLANIFICACIÓN DESARROLLO - REAL .......................................................... 213 ANEXO 26: PLAN DE SCM .......................................................................................... 215 ANEXO 27: OPCIONES DE HOSTING ............................................................................. 220 ANEXO 28: PROTOTIPOS............................................................................................. 221 4 Sistema de Gestión de Acreditaciones 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 Gerente SQA IR SCM Arquitectura Tester Desarrollo Tutor Costo / Cantidad Hora de horas 15 204,3 10 70,5 8 232,8 8 28,5 15 111,5 8 106,5 8 461,6 30 46 TOTAL 3064,5 705 1862,4 228 1672,5 852 3692,8 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. 113 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 Alicia María Pino -137445 Alejandra Gabriela Pera -126530 Alicia Claudia Pereira -134021 Tutor: Mariana Lasarte 2007 Proyecto InvPortal Universidad ORT Uruguay – Software Factory 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. Entrega_InvPortal 3 Proyecto InvPortal Universidad ORT Uruguay – Software Factory 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. Entrega_InvPortal 4 Proyecto InvPortal Universidad ORT Uruguay – Software Factory Í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 Entrega_InvPortal 5 Proyecto InvPortal 4.2 La 4.2.1 4.2.2 4.2.3 4.2.4 Universidad ORT Uruguay – Software Factory investigación ........................................................................................... 28 Los comienzos… .................................................................................... 28 Planilla de Comparación de Sitios .......................................................... 28 Registro de sitios ................................................................................... 30 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 Entrega_InvPortal 6 Proyecto InvPortal Universidad ORT Uruguay – Software Factory 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 Entrega_InvPortal 7 Proyecto InvPortal Universidad ORT Uruguay – Software Factory 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 Entrega_InvPortal 8 Proyecto InvPortal Universidad ORT Uruguay – Software Factory 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 Gerencia SCM Arquitectura Ing. de Reqs. SQA Diseño - Desarrollo Responsable Alicia C. Pereira Alicia M. Pino Alejandra G. Pera 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. Entrega_InvPortal 93 Proyecto InvPortal Tareas Universidad ORT Uruguay – Software Factory Abril Mayo Capacitación Investigación Requerimientos Análisis Diseño Implementación Testing Documentación Reuniones 18 140 0 0 0 0 0 0 36 33 174 5 0 0 0 0 9 44 Total 194 265 Junio Julio Agosto Set (horas del equipo) 27 2 0 138 82 0 14 8 0 22 26 0 10 13 21 23 107 260 6 0 32 29 43 52 26 36 44 295 317 Totales 80 534 27 48 44 390 38 133 186 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 desarrolló el proyecto. tarea en los meses en los cuales se Esfuerzo acumulado por tarea 280 260 240 220 200 180 Capacitación Horas 160 Investigación 140 Requerimientos Análisis 120 Diseño 100 Implementación 80 Testing 60 Documentación Reuniones 40 20 0 Abril Mayo Junio Julio Agosto Meses 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. Entrega_InvPortal 94 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 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. 3 Índice 1 GLOSARIO ....................................................................................................................................................... 6 2 DESCRIPCIÓN GENERAL ............................................................................................................................ 7 2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.7.1 2.7.2 3 INGENIERÍA DE REQUERIMIENTOS...................................................................................................... 14 3.1 3.1.1 3.1.2 3.1.3 3.2 3.2.1 3.3 3.4 3.4.1 3.4.2 3.4.3 3.5 4 ESTRATEGIA DE RELEVAMIENTO .............................................................................................................. 14 Justificación de la estrategia de relevamiento utilizada ..................................................................... 14 Descripción de los prototipos realizados ............................................................................................ 16 Descripción de las validaciones realizadas al ESRE .......................................................................... 16 ENTORNO DE LA ORGANIZACIÓN............................................................................................................... 17 Casos de uso del negocio .................................................................................................................... 18 CLIENTES Y USUARIOS ............................................................................................................................. 21 DESCRIPCIÓN DEL SISTEMA DE SOFTWARE ................................................................................................ 22 Requerimientos funcionales ................................................................................................................ 22 Requerimientos no Funcionales .......................................................................................................... 23 Criterios priorización requerimientos................................................................................................. 23 PROBLEMAS ENCONTRADOS Y LECCIONES APRENDIDAS ........................................................................... 24 INVESTIGACIÓN DE HERRAMIENTAS .................................................................................................. 25 4.1 4.2 4.3 4.4 4.5 5 ENTORNO DEL PROYECTO ........................................................................................................................... 8 MOTIVACIÓN .............................................................................................................................................. 9 PRINCIPALES OBJETIVOS ............................................................................................................................ 9 COMPLEJIDAD DEL PROYECTO .................................................................................................................. 10 CLIENTES Y USUARIOS .............................................................................................................................. 11 INTEGRANTES DEL EQUIPO ........................................................................................................................ 11 PROCESO DE DESARROLLO ........................................................................................................................ 12 Descripción ......................................................................................................................................... 12 Principales dificultades....................................................................................................................... 13 MOTOR DE WORKFLOW ............................................................................................................................ 25 CAPA DE PRESENTACIÓN WEB .................................................................................................................. 27 PERSISTENCIA ........................................................................................................................................... 28 EVALUACIÓN DE FÓRMULAS ..................................................................................................................... 28 CONSULTAS OLAP ................................................................................................................................... 29 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 6.2.1.2 Organización ..............................................................................................................................................43 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 4 6.3.1.2 6.3.1.3 6.3.1.4 6.3.1.5 Fase de Ingeniería de requerimientos .........................................................................................................53 Fase de diseño ............................................................................................................................................54 Fase de Implementación.............................................................................................................................54 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 7.2 7.3 7.4 8 INTRODUCCIÓN ......................................................................................................................................... 64 PROCESO................................................................................................................................................... 64 PRODUCTOS RESULTANTES ....................................................................................................................... 66 PROBLEMAS Y ACCIONES TOMADAS.......................................................................................................... 67 GERENCIA ..................................................................................................................................................... 69 8.1 8.2 8.3 8.4 8.5 8.5.1 8.5.2 8.5.3 8.6 8.6.1 8.6.2 8.7 8.8 8.8.1 8.8.2 INTRODUCCIÓN ......................................................................................................................................... 69 ETAPAS DEL PROYECTO ............................................................................................................................ 69 TAMAÑO DEL PROYECTO .......................................................................................................................... 70 MEDIDAS DE ÉXITO ................................................................................................................................... 71 CALENDARIO ............................................................................................................................................ 72 Ciclo de vida ....................................................................................................................................... 72 Cronograma ........................................................................................................................................ 74 Desviaciones del cronograma ............................................................................................................. 76 ESFUERZO ................................................................................................................................................. 78 Esfuerzo planificado............................................................................................................................ 78 Esfuerzo real ....................................................................................................................................... 79 PRESUPUESTO ........................................................................................................................................... 83 ANÁLISIS DE RIESGOS ............................................................................................................................... 84 Identificación de Riesgos .................................................................................................................... 84 Evolución de Riesgos .......................................................................................................................... 85 9 CONCLUSIONES ........................................................................................................................................... 90 10 BIBLIOGRAFÍA ............................................................................................................................................. 92 11 ESTRUCTURA DE LA DOCUMENTACIÓN EN CD ............................................................................... 93 12 ANEXOS .......................................................................................................................................................... 94 5 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. 79 Se muestra en las siguientes gráficas los porcentajes de esfuerzo del proyecto por cada rol y por cada actividad: Esfuerzo por Rol Investigador, 5% Arquitecto, 6% Tester, 7% Lider SQA, 6% Lider SCM, 2% Ing Requerimientos, 10% Gerente, 6% Desarrollador, 58% Gráfica de Esfuerzo por Rol Esfuerzo por Actividad SQA, 6% Diseño, 5% Gestión, 4% Testing, 8% SCM, 2% Reunión, 3% Relevamiento, 9% Investigación, 5% Implementación, 58% Gráfica de Esfuerzo por Actividad 82 APENDICE 4. MANUAL DE IMPLEMENTACIÓN DEL MODELO 335 336 Modelo ele Manual de Implementación Manual de implementación del modelo “ele” 2 Manual de implementación del modelo “ele” 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 3 Manual de implementación del modelo “ele” 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 4 Manual de implementación del modelo “ele” 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. 5 Manual de implementación del modelo “ele” 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. 6 Manual de implementación del modelo “ele” 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. 7 Manual de implementación del modelo “ele” 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. 8 Manual de implementación del modelo “ele” 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 9 Manual de implementación del modelo “ele” 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. 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 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 10 Manual de implementación del modelo “ele” 3.4.3 Actividades 11 Manual de implementación del modelo “ele” 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. 12 Manual de implementación del modelo “ele” 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 13 Manual de implementación del modelo “ele” 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 14 Manual de implementación del modelo “ele” 3.5.3 Actividades 15 Manual de implementación del modelo “ele” 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 16 Manual de implementación del modelo “ele” 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. 17 Manual de implementación del modelo “ele” 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. 18 Manual de implementación del modelo “ele” 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. 19 Manual de implementación del modelo “ele” NIVELES Conocimiento Comprensión Aplicación Análisis Síntesis PALABRAS CLAVES Escoger, encontrar, definir, rotular, mostrar, deletrear, listar, parear, nombrar, relatar, contar, recordar, seleccionar. Comparar, contrastar, demostrar, interpretar, explicar, extender, ilustrar, inferir, extractar, relatar, refrasear, traducir, resumir, demostrar, clasificar. PREGUNTAS ¿Cómo explicaría usted? ¿Cómo lo describiría usted...? ¿Cómo lo demostraría usted…? ¿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...? Aplicar, construir, escoger, ¿Cómo organizaría usted ______ para realizar, desarrollar, demostrar...? ¿Cómo demostraría usted entrevistar, hacer uso de, su entendimiento de...? ¿Qué organizar, experimentar con, aproximación o punto de vista, utilizaría planear, seleccionar, resolver, para...? ¿Cómo aplicaría usted lo que ha utilizar, modelar, identificar. 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...? Analizar, categorizar, ¿Cómo es ______ en relación a...? ¿Por clasificar, comparar, qué cree usted...? ¿Qué razones, contrastar, descubrir, disecar, motivos, existen para...? ¿Qué dividir, examinar, inferencias puede hacer usted...? ¿A qué inspeccionar, simplificar, conclusiones puede llegar...? ¿Cómo tomar parte en, examinar para, clasificaría usted...? ¿Qué evidencia encuestar, distinguir, listar, encuentra usted...? ¿Puede usted relacionar, funcionar, motivar, diferenciar entre...? diferenciar, inferir, asumir, concluir, componer. Construir, escoger, combinar, ¿Qué cambios haría usted para compilar, componer, crear, resolver....? ¿Cómo mejoraría usted...? fabricar, diseñar, desarrollar, ¿Qué pasaría si...? ¿Puede proponer una estimar, formular, imaginar, alternativa...? ¿Puede usted inventar...? inventar, originar, planear, ¿Cómo adaptaría usted _____ para crear predecir, decidir, proponer, una situación o cosa diferente...? ¿Cómo resolver, solucionar, suponer, cambiaría, modificaría, el terreno, discutir, modificar, cambiar, plano...? ¿Qué haría usted para originar, implementar, adaptar, minimizar (o maximizar)...? ¿Qué minimizar, maximizar, diseñaría usted...? ¿Qué combinaciones teorizar, elaborar, examinar, se podrían hacer para mejorar o eliminar, implementar, cambiar...? ¿Suponga que usted puede suceder, cambiar. ______ qué haría...? ¿Cómo examinaría, evaluaría, usted...? ¿Podría usted 20 Manual de implementación del modelo “ele” 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...? Premiar, escoger, concluir, ¿Está usted de acuerdo con las acciones Evaluación criticar, decidir, defender, o procedimientos...? ¿con los determinar, disputar, evaluar, resultados....? ¿Cuál es su opinión de...? juzgar, justificar, medir, ¿Cómo aprobaría (desaprobaría) comparar, marcar, categorizar, usted...? ¿Puede usted establecer el valor recomendar, reglamentar, o importancia de...? ¿Sería mejor si...? seleccionar, aceptar, ¿Por qué cree usted que (tal persona) interpretar, explicar, avaluar, escogió...? ¿Qué recomendaría usted...? priorizar, opinar, dar ¿Qué argumentaría usted para defender importancia, establecer tales acciones...? ¿Cómo daría usted criterios, aprobar, reprobar, prioridad...? ¿Qué juicio haría usted valorar, influenciar, percibir, sobre...? ¿En base a lo que usted sabe, significar, estimar, influenciar, cómo explicaría...? ¿Qué información deducir. 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. 21 Manual de implementación del modelo “ele” Ejemplo 2: De acuerdo a su experiencia, ¿cuáles son los elementos esenciales para realizar una entrevista productiva? 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. 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: Req. Edu. An. 03 área sub-área nivel de Bloom número de pregunta 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. 22 Manual de implementación del modelo “ele” 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. 23 Manual de implementación del modelo “ele” 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 24 Manual de implementación del modelo “ele” 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. 25 Manual de implementación del modelo “ele” 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 26 Manual de implementación del modelo “ele” 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. 27 Manual de implementación del modelo “ele” 3.7.2 Insumos y productos 3.7.3 Actividades 28 Manual de implementación del modelo “ele” 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. 29 Manual de implementación del modelo “ele” 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 30 Manual de implementación del modelo “ele” 3.8.3 Actividades Edu-001 Edu-001 Edu-001 2. Educir Nuevos Conocimientos y Edu-002 Edu-003 Edu-001 Edu-004 Edu-004 Edu-005 Edu-001 Edu-002 Edu-003 Edu-004 Edu-005 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: 31 Manual de implementación del modelo “ele” A) B) C) D) Extraer los aspectos más relevantes de cada respuesta. Relacionar las respuestas dadas a la misma pregunta por distintos equipos de proyecto. Hallar coincidencias y discrepancias sobre los distintos aspectos tratados. 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. 32 Manual de implementación del modelo “ele” 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. 33 Manual de implementación del modelo “ele” 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 34 Manual de implementación del modelo “ele” 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 35 Manual de implementación del modelo “ele” 3.10.3 Actividades 36 Manual de implementación del modelo “ele” 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. 37 Manual de implementación del modelo “ele” 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 38 Manual de implementación del modelo “ele” 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). 39 Manual de implementación del modelo “ele” 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... 40 Manual de implementación del modelo “ele” 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 41 Manual de implementación del modelo “ele” Preguntas Pregunta 1 ...ingrese aquí la pregunta... código compuesto Respuesta … incluir aquí los comentarios y reflexiones … Pregunta 2 ...ingrese aquí la pregunta... código compuesto Respuesta … incluir aquí los comentarios y reflexiones … Pregunta 3 ...ingrese aquí la pregunta... código compuesto Respuesta … incluir aquí los comentarios y reflexiones … Pregunta 4 ...ingrese aquí la pregunta... código compuesto Respuesta … incluir aquí los comentarios y reflexiones … Espacio Libre 42 Manual de implementación del modelo “ele” 5 Bibliografía Ackerman, M., 2004 AECI, 2000 Alvarez, N., 2005 Ander-Egg, E., 1999 Basili, V. et al., 1994 Bloom, B. et al., 1956 Cecil, N., 1995 Clifford, J. et al., 2007 García, D., 1997 García, J. et al., 2000 IEEE, 2004 McFeeley, B., 1996 Markus, M., 2001 Sommerville, I., 2005 Schon, D., 1998 Ackerman, M: Definitional and contextual issues in organization and group memories. Disponible en Internet: <www.ics.uci.edu/~ackerman>, 2004 Agencia Española de la Cooperación Internacional. Lecciones aprendidas y buenas prácticas. Una aproximación. Madrid, AECI, 2000 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.: El taller-Una alternativa de renovación pedagógica. Buenos Aires, Del Río de la Plata, 3ed., 1999 Basili, V., Caldeira, G., Rombach., H.: Goal-Question-Metric Approach, en Encyclopedia of Software Engineering, pp. 528532, 1994 Bloom, B.: Taxonomía de los objetivos de la educación. Buenos Aires, Ciudad de Edición, 7ed., 1956 Cecil, N.: The Art of inquiry. Toronto, Peguis, 1995 Clifford, J., Thorpe, S. Workplace Learning & Development. London, Kogan Page, 2007 García, D.: El grupo. Métodos y técnicas participativas. Buenos Aires, Espacio, 1997 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 Computer Society: Guide to the Software Engineering Body of Knowledge, Los Alamitos, 2004 McFeeley, B.: IDEAL: A user’s guide for software process improvement, Pittsburgh, Carnegie-Mellon University, 1996 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.: Ingeniería del Software. Madrid, Addison Wesley 7ed. 2005 Schon, D.: El profesional reflexivo. Buenos Aires, Piados, 1998 43 Manual de implementación del modelo “ele” 6 Glosario Aprendizaje experimental Teoría del aprendizaje que centro el proceso del aprendizaje en la experiencia. Forma de conocimiento o habilidad derivados de la observación, de Experiencia la vivencia de un evento o proveniente de las cosas que suceden en la vida. GGCA Grupo de Gestión del Conocimiento y Aprendizaje. Herramienta que tiene por objetivo capturar el aprendizaje surgido Guías de Reflexión de la experiencia. Insumos Artefactos necesarios para realizar las actividades de la fase. Conjunto coherente de acciones que explican cómo llevar a cabo una Mejores prácticas o más actividades de forma de obtener mejores resultados durante su ejecución. Objetivo de Meta deseable a alcanzar en la que se formula lo que se pretende que se aprenda al realizar una actividad. aprendizaje Operaciones cognitivas Actividad mental que procesa la información de los datos sensoriales Preguntas críticas Preguntas destinadas a promover el análisis y la reflexión. Resultados obtenidos como consecuencia de las tareas realizadas en Productos la fase. Mejora del proceso de Software: método sistemática y continua de mejora de una organización productora de software, con el objetivo SPI de producir y entregar software de calidad, en los tiempos y el presupuesto establecidos 44
