Página 1

UNIVERSIDAD DE CHILE FACULTAD DE CIENCIAS FISICAS Y MATEMATICAS DEPARTAMENTO DE CIENCIAS DE LA COMPUTACION

UN MODELO EMPÍRICO DE ENSEÑANZA DE LAS METODOLOGÍAS ÁGILES: EL CASO DEL CURSO CC62V ­ TALLER DE METODOLOGÍAS ÁGILES DE DESARROLLO DE SOFTWARE TESIS PARA OPTAR AL GRADO DE MAGISTER EN CIENCIAS MENCION COMPUTACION

AGUSTÍN ANTONIO VILLENA MOYA

PROFESORA GUÍA: MARIA CECILIA BASTARRICA PIÑEYRO MIEMBROS DE LA COMISIÓN: LUIS A. GUERRERO BLANCO SERGIO OCHOA DELORENZI YADRAN ETEROVIC SOLANO

SANTIAGO DE CHILE MARZO 2008



Página 2

RESUMEN
Las metodologías ágiles de desarrollo de software, y en particular Extreme Programming (XP), constituyen una de las tendencias de mayor impacto en la industria del desarrollo de software en la última década, gracias a su enfoque centrado en la generación temprana de valor y en su acento en el aspecto humano del desarrollo de software. Su adopción sin embargo ha demostrado ser bastante compleja debido a los cambios de paradigma que ellas plantean. Desde los inicios de estas metodologías surgió el interés de incorporar esta nueva mirada como una forma de enriquecer la formación de los futuros ingenieros de software. En este trabajo se plantea que un buen aprendizaje de las metodologías ágiles de desarrollo de software puede ser logrado por los alumnos a través de una experiencia educativa teóricopráctica basada en la aplicación de dichas metodologías en proyectos reales. Este enfoque ha sido aplicado desde el año 2002 en el curso CC62V "Taller de metodologías ágiles de desarrollo de software" del Departamento de Ciencias de la Computación de la Universidad de Chile, y en esta investigación se pone a prueba esta hipótesis, a partir del análisis de una de las instancias del curso realizada entre los meses de agosto y noviembre del año 2005. Para realizar este análisis se construyó un modelo evaluativo de aprendizaje basado en cómo las metodologías ágiles, y en particular Extreme Programming (XP), organizan el entorno de un proyecto de desarrollo de software para mantener la sincronía entre los cambiantes elementos que allí están en juego. Dichos elementos son el problema de negocios, la tecnología, la experiencia y destrezas del equipo de desarrollo, y el producto en desarrollo. El modelo de evaluación fue aplicado sobre los trabajos generados por los alumnos de la versión del curso usado como experimento de esta investigación, complementados con las observaciones realizadas por el profesor en la sala de clases, y otras evidencias tales como las opiniones de los clientes y una encuesta de evaluación de impacto hecha a los alumnos aproximadamente 6 meses después de finalizado el curso. Con respecto al impacto en el aprendizaje de los alumnos, se observó una comprensión y aplicación generalizada del marco de prácticas de XP, aunque el nivel de logro estuvo muy relacionado al entorno de trabajo logrado por cada uno de los proyectos realizados. En particular se encontró que algunos elementos no considerados en la hipótesis original, tales como la complejidad del problema a resolver y la relación con el cliente, tenían también un impacto relevante sobre el éxito de los proyectos, y no sólo los aspectos pedagógicos. Se comprobó la eficacia de este modelo pedagógico que promueve el equilibro entre teoría y práctica, el ambiente humano de equipo y de colaboración con el cliente y las destrezas entrenadas. Por su parte, la práctica de XP más destacada por los alumnos es la "programación en parejas", que presenta la mejor evaluación durante el curso y es la más aplicada a posteriori. Otra práctica que causa mucho interés es el "desarrollo guiado por test", pero se indican problemas de tiempo y experiencia para poder aplicarla después del curso. En lo que se refiere al modelo pedagógico aplicado para que los alumnos conozcan e internalicen las prácticas de XP, se determina que las claves de su éxito se encuentran en: x x reproducir de manera fiel el ambiente de aprendizaje colaborativo acelerado que se genera en la práctica profesional de las metodologías ágiles, y complementar dicho ambiente con una leve capa de acciones docentes orientadas a reflexionar y retroalimentar el dominio de la metodología. 2



Página 3

AGRADECIMIENTOS
Este trabajo está motivado por el cariño y consejos pedagógicos de mi esposa Pamela y el cariño de mis hijos Gerard y Rafael, y por el amor a la educación de mi familia de origen, en particular de mis padres, a quienes dedico todo el esfuerzo involucrado en esta investigación. No quisiera dejar de mencionar a toda aquella gente que aportó con su grano de arena a esta labor: Sergio Ochoa con sus consejos para encauzar el tema dentro de las ciencias de la ingeniería, el apoyo y la confianza de Cecilia Bastarrica, los consejos de Jesús María Redondo, actual director de la Escuela de Psicología de la Universidad de Chile, quién á través de sus consejos permitió darle solidez a esta investigación desde la perspectiva educacional, y por supuesto a todos los alumnos del curso CC62V, en especial a la generación del 2005 gracias a los cuales fue posible no sólo realizar el curso sino que también extender el contacto y la reflexión mucho más allá en el tiempo y así poder efectivamente obtener un resultado acerca de la experiencia educativa vivida. Una mención especial merece el apoyo desinteresado y fiel de mi gran amigo Carlos Henríquez, sin el cual el finalizar este trabajo no habría sido posible.

3



Página 4

TABLA DE CONTENIDOS
RESUMEN ...................................................................................................................................................................... 2 TABLA DE CONTENIDOS ............................................................................................................................................... 4 ÍNDICE DE ILUSTRACIONES ......................................................................................................................................... 6 ÍNDICE DE TABLAS ....................................................................................................................................................... 8 1. 2. INTRODUCCIÓN................................................................................................................................................. 9 PLAN DE TRABAJO ........................................................................................................................................ 12 2.1 2.2 3. HIPÓTESIS DE LA INVESTIGACIÓN ................................................................................................................................. 12 METODOLOGÍA ................................................................................................................................................................. 12

ANTECEDENTES ............................................................................................................................................. 13 3.1 EL PROBLEMA DE LA PRODUCTIVIDAD DE LA INDUSTRIA DE SOFTWARE ................................................................ 13 3.1.1 Aproximaciones de solución surgidas en la industria ............................................................................... 14 METODOLOGÍAS ÁGILES (MA) Y EXTREME PROGRAMMING (XP) ......................................................................... 16 3.2 3.2.1 Bases conceptuales de las MA ............................................................................................................................... 17 3.2.2 La propuesta de Extreme Programming (XP) ............................................................................................... 22 3.2.3 El problema de la adopción de XP en la industria ....................................................................................... 28 EL ESTADO DEL ARTE DE LA CIENCIA DEL APRENDIZAJE .......................................................................................... 33 3.3 3.3.1 Los antecedentes de la ciencia del aprendizaje ............................................................................................ 33 3.3.2 La ciencia del aprendizaje: aprender con entendimiento ........................................................................ 33 EDUCACIÓN DE LA INGENIERÍA DE SOFTWARE .......................................................................................................... 39 3.4 3.4.1 Objetivos y Contenidos de la Educación en Ingeniería de Software .................................................... 40 3.4.2 Modelos pedagógicos para la formación ingenieros de software......................................................... 42 3.4.3 Desafíos en la educación de ingeniería de software ................................................................................... 44 3.4.4 Desafíos de la incorporación de XP en la formación de los ingenieros de software ..................... 46 3.4.5 Caracterización de las aplicaciones de XP en la formación académica de los ingenieros de software ........................................................................................................................................................................................... 47 3.4.6 Un caso destacable: Role Model Software y su Software Studio .......................................................... 49

4.

PROPUESTAS .................................................................................................................................................. 52 4.1 EL CURSO CC62V "TALLER DE METODOLOGÍAS ÁGILES DE DESARROLLO DE SOFTWARE" Y SU DISEÑO INSTRUCCIONAL ................................................................................................................................................................................ 53 4.1.1 Orígenes del Curso CC62V ....................................................................................................................................... 54 4.1.2 Contexto del curso ...................................................................................................................................................... 55 4.1.3 Diseño Instruccional del curso CC62V .............................................................................................................. 57 XP COMO ORGANIZADOR DE UN AMBIENTE DE DESARROLLO DE SOFTWARE ......................................................... 66 4.2 4.2.1 Mecanismos de sincronización/armonización en un proyecto de software organizado según 68 XP UN MODELO DE EVALUACIÓN SOBRE APRENDIZAJE DE XP CENTRADO EN EL INDIVIDUO .................................... 73 4.3 4.3.1 Razones para un nuevo modelo evaluativo .................................................................................................... 73 4.3.2 Modelo de evaluación de la experiencia ........................................................................................................... 74 4.3.3 Medios de recopilación de evidencias para evaluar la experiencia ..................................................... 74 4.3.4 Variables a medir en la experiencia ................................................................................................................... 77

5.

EXPERIENCIA REALIZADA: SEMESTRE PRIMAVERA 2005 DEL CURSO CC62V .......................... 79 5.1 DESCRIPCIÓN DE LA EXPERIENCIA ................................................................................................................................ 79 5.1.1 Innovaciones aplicadas al diseño instruccional............................................................................................ 79 5.1.2 Calendario de Actividades ...................................................................................................................................... 79 5.1.3 Tamaño del curso ....................................................................................................................................................... 80 5.1.4 Proyectos desarrollados .......................................................................................................................................... 80

4



Página 5

5.2 ANÁLISIS DE RESULTADOS DE LA EXPERIENCIA .......................................................................................................... 82 5.2.1 Conocimientos previos .............................................................................................................................................. 82 5.2.2 Aprendizajes logrados durante el curso ........................................................................................................... 82 5.2.3 Calidad en la reproducción del ambiente XP durante el curso .............................................................. 85 5.2.4 Percepciones de los clientes ................................................................................................................................... 87 5.2.5 Encuesta de impacto post curso ........................................................................................................................... 89 6. RESULTADOS ADICIONALES ...................................................................................................................... 96 6.1 MEJORAS PARA FORTALECER EL DISEÑO INSTRUCCIONAL DEL CURSO .................................................................... 96 6.1.1 Explicar XP a partir del nuevo modelo planteado en esta investigación. ......................................... 96 6.1.2 Estrategias para evitar malos entendidos de las prácticas de XP ........................................................ 96 6.1.3 Pre-selección de los proyectos a trabajar ........................................................................................................ 97 6.1.4 Involucramiento temprano de los alumnos en la plataforma tecnológica y en el problema ... 97 6.1.5 Implementar un sistema emergente de organización en los equipos ................................................. 97 6.1.6 Establecer una base temprana de código funcional ................................................................................... 98 6.1.7 Fortalecer la aplicación del modelo de aprendizaje cognitivo .............................................................. 98 ENUNCIACIÓN DE CLAVES DEL MODELO PEDAGÓGICO APLICADO............................................................................. 98 6.2 6.2.1 Propuesta de prácticas pedagógicas ágiles ................................................................................................. 101 7. CONCLUSIONES ............................................................................................................................................ 103 7.1 HIPÓTESIS 1: ES POSIBLE LA REPRODUCCIÓN EFECTIVA DE UN AMBIENTE DE DESARROLLO ÁGIL (XP) EN UN CURSO UNIVERSITARIO ................................................................................................................................................................. 103 HIPÓTESIS 2: LA EXPOSICIÓN DE LOS ALUMNOS A UN DESARROLLO AUTÉNTICO EN UN AMBIENTE ÁGIL GENERA 7.2 BUENOS APRENDIZAJES SOBRE LAS METODOLOGÍAS ÁGILES .................................................................................................. 104 TRABAJO FUTURO ....................................................................................................................................... 106 8.1 8.2 8.3 8.4 9. 10. APLICACIÓN DEL DISEÑO INSTRUCCIONAL (O ELEMENTOS DE ÉSTE) EN MÁS CURSOS DE LA CARRERA ......... 106 LÍNEAS DE DESARROLLO PARA EL MODELO EXPLICATIVO DE XP Y SU MODELO EVALUATIVO DERIVADO. ..... 106 APLICAR ESTE MODELO PEDAGÓGICO A LA CAPACITACIÓN DE PROFESIONALES ................................................. 106 VALIDAR LA RELACIÓN ENTRE CONTRUCTIVISMO Y MÉTODOS ÁGILES, Y COMO ESTA RELACIÓN POTENCIARÍA LOS APRENDIZAJES ........................................................................................................................................................................ 107 REFERENCIAS Y BIBLIOGRAFÍA .............................................................................................................. 108 ANEXOS ...................................................................................................................................................... 111

8.

10.1 DESCRIPCIÓN DETALLADA DE LA EXPERIENCIA ...................................................................................................... 111 Fase teórica........................................................................................................................................................... 111 10.1.1 Fase práctica ........................................................................................................................................................ 113 10.1.2 10.2 HERRAMIENTAS DE EVALUACIÓN UTILIZADAS ......................................................................................................... 155 Encuesta de co-evaluación ............................................................................................................................. 155 10.2.1 Encuesta al cliente ............................................................................................................................................. 156 10.2.2 Pauta de Evaluación de Ensayo de XP y Opinión del Primer Ciclo............................................... 157 10.2.3 Pauta de Evaluación del Proyecto y Proyección a la Vida Profesional ...................................... 159 10.2.4 10.3 RESUMEN DE ENSAYOS DE ALUMNOS ......................................................................................................................... 161 Proyecto Mapache ............................................................................................................................................. 161 10.3.1 Proyecto XMLSync.............................................................................................................................................. 167 10.3.2

5



Página 6

ÍNDICE DE ILUSTRACIONES
Ilustración 1: Funciones desarrolladas en un software y su nivel de uso efectivo por parte de los usuarios. [48] .......................................................................................................................................................................... 14 Ilustración 2: Complejidad de un NPD de acuerdo a sus niveles de incertidumbre .......................................... 17 Ilustración 3: Comparación entre el valor generado por un proyecto tradicional y lo que sería ideal ..... 18 Ilustración 4: Curva de costo de cambio tradicional versus la revisada ................................................................. 19 Ilustración 5: El ambiente del desarrollo de software .................................................................................................... 21 Ilustración 6: El desarrollo de un software a través de la metáfora del desarrollo de un columpio .......... 22 Ilustración 7: Flujo del trabajo en XP ...................................................................................................................................... 25 Ilustración 8: Ritmos de XP ....................................................................................................................................................... 26 Ilustración 9: La interrelación de prácticas de XP, según Kent Beck en la primera edición de "Extreme Programming Explained"[6] ............................................................................................................................................ 27 Ilustración 10: Flujo de pasos del modelo pedagógico de Aprendizaje Cognitivo.............................................. 38 Ilustración 11: Áreas curriculares de la computación propuestas por CC2001. ................................................. 39 Ilustración 12: Niveles de cursos y estrategias de implementación ......................................................................... 40 Ilustración 13: Ambiente de trabajo del Software Studio.............................................................................................. 50 Ilustración 14: Carrera de Ingeniería Civil en Computación y el contexto en donde se aplica el curso CC62V ......................................................................................................................................................................................... 55 Ilustración 15: Relación entre los diversos integrantes del curso ............................................................................. 60 Ilustración 16: Presentación de valores asociando los principios a cada uno de ellos .................................... 62 Ilustración 17: Organizador de prácticas de XP por afinidad ...................................................................................... 63 Ilustración 18: El complejo entorno de un proyecto de software desde la mirada de un ingeniero de software..................................................................................................................................................................................... 66 Ilustración 19: Ciclos de sincronización de un proyecto organizado en torno a XP .......................................... 68 Ilustración 20: Entorno de desarrollo de software organizado por las prácticas de XP .................................. 69 Ilustración 21: Flujo del Planning Game. ............................................................................................................................... 70 Ilustración 22: Contraste entre el modelo evaluativo usado en el curso y de la investigación..................... 73 Ilustración 23: Versión adaptada de la Taxonomía de Bloom por la American Psichology Association .... 77 Ilustración 24: Planificación inicial del curso ..................................................................................................................... 80 Ilustración 25: Mapa global de comprensión de prácticas ............................................................................................ 82 Ilustración 26: Mapa global de evaluación de aplicación de prácticas .................................................................... 85 Ilustración 27: Comparación entre plan inicial y lo sucedido en los proyectos realizados ........................... 86 Ilustración 28: Opinión del cliente del proyecto Mapache sobre los alumnos .................................................... 88 Ilustración 29: Opinión del cliente del proyecto XMLSync sobre los alumnos .................................................... 89 Ilustración 30: Gráfico de evaluación a posteriori de los alumnos............................................................................ 90 Ilustración 31: Aspectos destacados del curso según nº de menciones recibidas ............................................. 90 Ilustración 32: Rememoración de prácticas de XP ........................................................................................................... 92 Ilustración 33: Ilustración 36: Rememoración de prácticas de XP por proyecto................................................ 93 Ilustración 34: Aplicación de elementos de XP................................................................................................................... 94 Ilustración 35: Aplicación deseada por los alumnos pero no lograda ..................................................................... 95 Ilustración 36: Complementación natural entre XP y el modelo pedagógico del curso CC62V .................... 99 Ilustración 37: Cómo el modelo pedagógico de aprendizaje se realiza en el curso CC62V ......................... 100 Ilustración 38: Prácticas pedagógicas instaladas sobre XP........................................................................................ 101 Ilustración 39: "Cómo funciona XP" ..................................................................................................................................... 111 Ilustración 40: Reglas para clientes y desarrolladores ............................................................................................... 111 Ilustración 41: eXtreme Hour ­ "Equipo de desarrollo" frente a los "clientes"................................................. 111 Ilustración 42: eXtreme Hour ­ Los "clientes" inspeccionando el trabajo realizado ..................................... 111 Ilustración 43: eXtreme Hour ­ Tarjetas con las "Historias de usuario" que describen las características de la máquina ficticia........................................................................................................................................................ 112 Ilustración 44: eXtreme Hour ­ Máquina Ficticia: "Producto" generado en el taller ..................................... 112 Ilustración 45: Charla sobre Desarrollo Guiado por Tests dada por un alumno .............................................. 113

6



Página 7

Ilustración 46: Plan inicial del proyecto, construido con post-it's pegados en un papelógrafo, para su fácil remoción, almacenado y reinstalación en cada sesión ............................................................................ 115 Ilustración 47: Alumnos colaborando con el cliente (sentado frente al computador del medio) ............ 117 Ilustración 48: Plan de inicios de la segunda iteración ................................................................................................ 124 Ilustración 49: Plan al finalizar el proyecto ...................................................................................................................... 127 Ilustración 50: Plan inicial del proyecto, construido con post-it's pegados en un papelógrafo, para su fácil remoción, almacenado y reinstalación en cada sesión ............................................................................ 135 Ilustración 51: Coach (a la izquierda) liderando el análisis del problema ......................................................... 138 Ilustración 52: Equipo presentando algunos avances al cliente .............................................................................. 139 Ilustración 53: Papelógrafo con el plan obtenido al finalizar la primera iteración ......................................... 146 Ilustración 54: Plan final del proyecto ................................................................................................................................ 150

7



Página 8

ÍNDICE DE TABLAS
Tabla 1: Resultados comparados entre 1994 y 2004 [48] ............................................................................................ 13 Tabla 2: Sobretiempo y efectividad comparada entre 2000 y 2003 [48] .............................................................. 13 Tabla 3: Principios Ágiles ............................................................................................................................................................. 16 Tabla 4: Declaración de derechos de clientes y desarrolladores................................................................................ 20 Tabla 5: Buenas prácticas de la industria del software y su versión XP ................................................................. 23 Tabla 6: Principios de XP según Kent Beck en "Extreme Programming Explained".......................................... 25 Tabla 7: Comparación entre los conceptos tradicionales y los de XP....................................................................... 29 Tabla 8: Comparación entre prácticas de desarrollo tradicional y XP .................................................................... 29 Tabla 9: Contraste entre planificación según XP y su interpretación por un equipo de desarrollo ........... 30 Tabla 10: Comparación entre el aprendizaje de personas comunes y estudiantes ........................................... 36 Tabla 11: Desafíos derivados de llevar el modelo del taller de oficios a la sala de clases .............................. 37 Tabla 12: Propuestas para las hipótesis de esta investigación ................................................................................... 52 Tabla 13: Desafíos de la enseñanza de la Ingeniería de Software y cómo XP puede ayudar a abordarlos ....................................................................................................................................................................................................... 54 Tabla 14: Esquema estructurado de actividades del curso........................................................................................... 61 Tabla 15: Reglas de convivencia entre clientes y desarrolladores ............................................................................ 64 Tabla 16: Estructura de una sesión del curso ..................................................................................................................... 65 Tabla 17: Desafíos del Ingeniero de Software en un Proyecto de desarrollo ....................................................... 67 Tabla 18: Desafíos de un coach.................................................................................................................................................. 67 Tabla 19: Desafíos de un tracker............................................................................................................................................... 67 Tabla 20: Resumen de mecanismos de sincronización de un proyecto de software XP .................................. 72 Tabla 21: ítems de evaluación del cliente ............................................................................................................................. 75 Tabla 22: Rango de evaluación ocupada por el cliente ................................................................................................... 75 Tabla 23: Ítems de co-evaluación ............................................................................................................................................. 76 Tabla 24: Rango de evaluación utilizado en las co-evaluaciones ............................................................................... 76 Tabla 25: Variables que miden el aprendizaje logrado por los alumnos en el curso ........................................ 78 Tabla 26: Áreas en donde hubo problemas de aplicación de XP y la mejora propuesta.............................. 104 Tabla 27: pre-conceptos de los alumnos versus conceptos ágiles .......................................................................... 104 Tabla 28: Prácticas que deben ser mejor presentadas a los alumnos .................................................................. 105 Tabla 29: Comparación entre el plan original y lo realmente sucedido en el proyecto Mapache ............ 114 Tabla 30: Matriz del Plan Proyecto Mapache Ciclo 1 .................................................................................................... 116 Tabla 31: Plan de la segunda parte del proyecto. En gris se destaca lo no implementado .......................... 125 Tabla 32: Comparación entre el plan original y lo realmente sucedido en el proyecto XMLSync ............ 134

8



Página 9

1. INTRODUCCIÓN
Desde fines de la década pasada, las metodologías ágiles han propuesto un nuevo paradigma para el desarrollo de software, que establece la incertidumbre y el consecuente cambio como realidades intrínsecas a esta actividad, tanto en lo que se refiera a los problemas a resolver como en las formas de solucionarlos. El interés de la industria por este nuevo enfoque, liderado por la metodología ágil más difundida "Extreme Programming" (XP), también ha sido recogido por la academia, que la ha ido incorporando en la formación de los nuevos ingenieros de software. Sin embargo esta inserción no es simple debido a que las metodologías ágiles revisan e incluso contradicen paradigmas instalados fuertemente en la práctica pedagógica académica, tales como el modelo de ciclo de vida de cascada o la curva de costo exponencial del cambio a lo largo de un desarrollo de software En las experiencias académicas documentadas en los últimos años, se pueden observar dos aproximaciones para la introducción de las metodologías ágiles: una parcial, que incorpora prácticas ágiles de manera aislada como la "programación de a pares" o el "desarrollo guiado por pruebas", y otra más integral, a través de cursos especializados en la materia. Lo que llama la atención es que los proyectos abordados suelen no ser reales, es decir, se diseñan requerimientos ficticios y personas que actúan el rol de cliente, sin serlo en realidad, paradigma que incluso se repite en experiencias en donde se cuenta con el apoyo directo de empresas reales. Un modelo alternativo de formación de ingenieros de software lo representa el "Software Studio" de la empresa Role Model Software[53], en donde se reproduce un taller de oficios. En éste taller "maestros desarrolladores de software" van guiando y formando a los nuevos desarrolladores-aprendices a medida que éstos se van incorporando a la empresa a través del uso de metodologías ágiles. En la experiencia local tenemos que desde el año 2002 se lleva a cabo en el Departamento de Ciencias de la Computación de la Facultad de Ciencias Físicas y Matemáticas de la Universidad de Chile el curso CC62V: "Taller de metodologías ágiles de desarrollo de software", el cual, usando la aproximación pedagógica "aprender haciendo", es decir, trabajando en proyectos con necesidades y clientes auténticos, ha obtenido resultados bastante interesantes tanto desde la perspectiva de los alumnos como la de los clientes que han participado. Tanto los alumnos como clientes han destacado el buen ambiente humano vivido, los alumnos demuestran un dominio aceptable de los conceptos y prácticas ágiles y los productos de software generados en el curso han sido satisfactorios y entregados sin ocupar ni tiempo ni recursos adicionales a los predefinidos en el curso. Todo lo anterior no deja de llamar la atención, no sólo desde la perspectiva del éxito del enfoque ágil, sino que también desde el punto de vista pedagógico, dado que la estrategia educativa aplicada ocupa un modelo de enseñanza muy distinto al común de los cursos de la carrera. El objetivo de esta investigación por ende es comprobar mediante un análisis acucioso de un semestre del curso CC62V estos buenos resultados observados de manera informal, buscando además determinar las claves que explican los resultados del modelo pedagógico aplicado en el curso, y el real impacto logrado por éste en los aprendizajes de los alumnos que cursan dicho ramo. El experimento en cuestión fue realizado durante el curso realizado en el período agostonoviembre del año 2005. En ese curso se recopilaron un conjunto de evidencias sobre la experiencia educativa: 9



Página 10

x x x x

ensayos de opinión de los alumnos sobre XP, ensayos de evaluación del uso de XP en los proyectos de desarrollo abordados en el curso, las evaluaciones realizadas por los clientes de los proyectos, y una encuesta de evaluación de impacto realizada a los alumnos a partir de 6 meses después de finalizado el curso.

Se realizó un estudio acerca de la problemática de la adopción de las metodologías ágiles en la industria, el estado del arte de las ciencias de aprendizaje, el estado del arte de la educación en ingeniería de software y sobre las experiencias documentadas de incorporación de metodologías ágiles en la formación en dicha ingeniería. Se documentó el diseño instruccional que se aplica en el curso, explicando como éste busca reproducir de la manera más fiel posible un entorno de desarrollo ágil. Adicionalmente se elaboró un nuevo modelo evaluativo orientado a determinar el real grado de aprendizaje de los alumnos del curso desde la perspectiva ágil. Dicho modelo está basado en cómo las metodologías ágiles ­ y en particular XP ­ organizan el entorno de un desarrollo de software para mantener la sincronía entre los cambiantes componentes que allí están en juego, tales como el problema de negocios, la tecnología, la experiencia y destrezas del equipo de desarrollo, y el producto en desarrollo. Al aplicar el nuevo modelo evaluativo sobre las evidencias recopiladas, se pudo observar que los alumnos adquieren durante el curso una comprensión bastante completa del complejo marco de prácticas de XP, complementada con una aplicación de dichas prácticas en los proyectos abordados. Sin embargo se observa que el nivel de logro está muy relacionado al entorno de trabajo logrado por cada uno de los proyectos realizados. En particular se encontró que algunos elementos no considerados anteriormente, tales como la complejidad del problema y la relación con el cliente, tenían también un impacto relevante sobre el éxito de los proyectos, y no sólo los aspectos pedagógicos. Por otra parte, se comprobó la eficacia de este modelo pedagógico que promueve el equilibro entre teoría y práctica, el ambiente humano de equipo y de colaboración con el cliente y las destrezas entrenadas. En lo que se refiere a la adopción de prácticas de XP, la más destacada por los alumnos es la "programación de a pares", que presenta la mejor evaluación durante el curso y es la más aplicada a posteriori. Otra práctica que causa mucho interés es el "desarrollo guiado por test", pero se indican problemas de tiempo, y experiencia para poder aplicarla después del curso. En lo que se refiere al modelo pedagógico aplicado para que los alumnos conozcan e internalicen las prácticas de XP, se determinó que las claves de su éxito se encuentran en el reproducir de manera fiel el ambiente de aprendizaje colaborativo acelerado que generan las metodologías ágiles, y complementar dicho ambiente con una leve capa de acciones docentes orientadas a reflexionar y retroalimentar el dominio de la metodología. Como antecedentes de esta investigación se presentarán las bases de las metodologías ágiles, y la experiencia recopilada en la industria y la academia en torno a los desafíos que plantea su adopción y las formas de abordar este tema. También se presentan los últimos avances de las ciencias del aprendizaje y los lineamientos actuales para la formación de ingenieros de software. Los antecedentes de esta investigación son completados por una descripción del contexto de la carrera de Ingeniería civil en Computación de la Universidad de Chile, que es en donde se enmarca la experiencia analizada. Posteriormente se presenta el diseño del experimento realizado y del modelo evaluativo que se usó para analizar los resultados obtenidos. Luego se describe la experiencia realizada incorporando los análisis de 10



Página 11

aprendizajes logrados por los alumnos a lo largo de cada uno de los proyectos abordados durante el curso. Finalmente, se presentan las conclusiones de esta investigación, con una definición de cuáles son los logros del modelo pedagógico aplicado, las posibles mejoras que pueden aplicarse y la formulación de las claves de éxito de dicho modelo, enunciadas como prácticas complementarias a las tradicionales de las metodologías ágiles y en particular de XP.

11



Página 12

2. PLAN DE TRABAJO
2.1 Hipótesis de la Investigación
Las hipótesis que se busca poner a prueba en esta investigación son: 1. Es posible la reproducción efectiva de un ambiente de desarrollo ágil (XP) en un curso universitario: Se puede ofrecer a los alumnos de ingeniería de software una experiencia representativa de las metodologías ágiles - en particular Extreme Programming ­ dentro del marco, recursos y tiempo de un curso normal de la carrera. 2. La exposición de los alumnos a un desarrollo auténtico en un ambiente ágil genera buenos aprendizajes sobre las metodologías ágiles. Gracias a la naturaleza de los ambientes de desarrollo ágil, que están orientados a potenciar el aprendizaje continuo en sus integrantes para así lograr la mayor productividad, al reproducirlos fielmente en el contexto de un curso de Ingeniería de Software se obtienen buenos resultados en los aprendizajes de los alumnos.

2.2 Metodología
El plan de trabajo aplicado seguido en este trabajo comprendió las siguientes actividades: x x Definición de bases conceptuales, en lo que se refiere al origen de las metodologías ágiles, la ciencia del aprendizaje y su aplicación a la formación de ingenieros de software. Conceptualización del problema. Mediante un estudio del estado del arte de la adopción de XP tanto en la academia como en la industria, se definieron los desafíos a abordar en la adopción de buenas prácticas por parte de los desarrolladores. También se analizó el contexto de la carrera en la que se encuentra inmerso este curso. Documentación del diseño instruccional de enseñanza de metodologías ágiles aplicado en el curso CC62V "Taller de Metodologías Ágiles de Desarrollo de Software" que se imparte desde el 2002 en el Departamento de Ciencias de la Computación de Facultad de Ciencias Físicas y Matemáticas de la Universidad de Chile. Recopilación de evidencias sobre la experiencia de curso realizado en el período agosto-noviembre de 2005. Consistió en la captura de evidencias de aprendizaje desde el curso mencionado, las que fueron usadas en el posterior análisis usando el modelo evaluativo preparado. Elaboración de modelo evaluativo, se definió un modelo evaluativo que permitiese, medir el impacto en el aprendizaje de los alumnos sobre metodologías ágiles obtenido mediante la aplicación del diseño instruccional de CC62V. Evaluación de la efectividad del modelo de adopción. A partir de las evidencias recogidas en la experiencia, realizar un análisis de los aprendizajes logrados por los alumnos. Elaboración de proyecciones del trabajo, en particular definir mejoras al diseño instruccional del curso y enunciar las claves metodológicas que sustentan los buenos resultados percibidos.

x

x

x

x

x

12



Página 13

3. ANTECEDENTES
3.1 El problema de la productividad de la industria de software
Desde 1994 la consultora norteamericana "The Standish Group" realiza en EEUU un estudio bi-anual llamado "The Chaos Report" [27] cuyo objetivo es medir la efectividad lograda por los proyectos de software, en base a criterios tales como: x x cumplimiento y desviación con respecto a metas de tiempo y costos porcentaje de funcionalidad útil realmente lograda Año exitosos abortados con problemas 1994 16% 31% 53% 2003 34% 15% 51%

Tabla 1: Resultados comparados entre 1994 y 2004 [48]

Como es posible observar en la Tabla 1, ha existido un aumento en los proyectos exitosos (es decir, que son terminados dentro de los plazos y costos esperados, y que entregan el valor suficiente) pero la cantidad de proyectos en problemas se mantiene casi igual. El aumento promedio por año en la cantidad de proyectos exitosos es pequeño, apenas superior a un 1%, lo que, proyectado en el tiempo arrojaría que para lograr un 50% de proyectos exitosos tenemos que esperar por lo menos hasta el 2015. Sin embargo, existen otros antecedentes que ponen en peligro incluso esta predicción. Año sobretiempo promedio % de funcionalidades requeridas logradas 2000 63% 67% 2003 82% 52%

Tabla 2: Sobretiempo y efectividad comparada entre 2000 y 2003 [48]

Tal como es posible observar en la Tabla 2, el sobretiempo sufrido por los proyectos está en aumento, y, lamentablemente, cada vez se logra menos de las funcionalidades esperadas, lo que se refleja en la Ilustración 1, en donde se grafica la proporción de funcionalidades que los clientes declaran realmente usar en los software que reciben.

13



Página 14

Uso de Funcionalidades de Software
Frecuente mente 13% Siempre 7%

Algunas veces 16% Raramente 19%

Nunca 45%

Ilustración 1: Funciones desarrolladas en un software y su nivel de uso efectivo por parte de los usuarios. [48]

Esta realidad fue la que llevó a acuñar a Kent Beck la siguiente frase: "El Software falla en ser entregado... y falla en entregar valor" [6].

3.1.1 Aproximaciones de solución surgidas en la industria
Como una forma de paliar esta situación, ya desde los `70 se han planteado modelos de ciclo de vida que dan una estructura más ordenada a los proyectos de software, donde destaca por su penetración en la industria y la academia el conocido ciclo de vida de cascada [44]. Este define un conjunto de pasos secuenciales para el desarrollo de software, donde se hace énfasis en que el equipo de desarrollo debe obedecer un proceso pre-definido, generando diversos productos intermedios durante el desarrollo, tales como documentos de análisis, diseño, pruebas, etc. Surgió entonces, en la década de los '90, la tendencia a generar formalismos para facilitar la creación de estos artefactos intermedios, y de herramientas de software para apoyar su desarrollo - denominadas CASE 1 - cuya promesa consiste en generar software funcional a partir de modelos de alto nivel. Uno de los enfoques más destacados de esta tendencia surge a mediados de los '90 el "Rational Unified Process" (RUP) 2, basado en el formalismo UML que representa la ambición de abracar en un solo modelo de proceso cualquier desarrollo de software, sin importar su naturaleza o tamaño. El valor aportado por estas propuestas no es gratis: x x x requiere de una elevada curva de aprendizaje de los formalismos, un alto costo de licencias en las herramientas asociadas, un gran esfuerzo en horas hombre requerido para gestionar, y controlar el desarrollo,

RUP genera una cantidad no despreciable de productos intermedios requeridos por la metodología: diagramas y especificaciones de casos de uso, diagramas de clases, diagramas de componentes, etc., los que si bien tienen valor, no son el producto final que se busca lograr: software funcional. Debido a lo anterior, a este tipo de metodologías se les comenzó a denominar "metodologías pesadas", quedando abierta la discusión acerca de cómo ofrecer una respuesta directa al

1 Computer Assisted Software Engineering 2 http://www-306.ibm.com/software/awdtools/rup

14



Página 15

problema de generar productos de software de alta calidad en un ambiente de cambio acelerado, pero además mejorando la relación costo-eficiencia [54]. Otro enfoque con gran presencia en la industria es representado por el Capability Maturity Model [41] que consiste en un modelo de referencia de mejora en etapas propuesto para las organizaciones que desarrollan software, desde el nivel inicial denominado caótico hasta un nivel en el cual la organización pueda aprender y optimizar permanentemente su forma de trabajar. La versión más actualizada de CMM, denominada Capability Maturity Model Integration (CMMi) agrega un fuerte componente de la planificación detallada y de control centralizado a la gestión del desarrollo de software, lo que implica un giro hacia la mirada de la tradicional gestión Tayloriana en donde el foco del trabajo está en seguir estrictamente un plan predefinido, generándose así una fuerte resistencia al cambio e inflexibilidad. [43]

15



Página 16

3.2 Metodologías Ágiles (MA) y Extreme Programming (XP)
Eclipsadas por el imperante paradigma secuencial del desarrollo de software, ya desde los '60 se plantearon propuestas de ciclos de vida según el modelo iterativo e incremental de desarrollo de software, en donde el ciclo de vida espiral [11] - consistente en la descomposición de los proyectos en mini-cascadas sucesivas dirigidas cada una de ellas a abordar los riesgos - es quizás uno de los más conocidos. En estos modelos iterativos se reconoce la necesidad de la comunicación y el aprendizaje como herramientas cruciales para poder generar soluciones de calidad [29], enfocándose así en las necesidades de las personas que realizan los proyectos por sobre los pasos que ellos debieran seguir. De acuerdo a esta mirada centrada en el potenciamiento del recurso humano, a mediados de los '90 comenzó a surgir una alternativa a las metodologías pesadas. El hito seminal de una nueva mirada "liviana" al desarrollo de software tuvo lugar en el proyecto Chrysler Compensation Center en 1996, en donde comenzó a cristalizarse la metodología semi-formal "Extreme Programming" (XP), que recibe su nombre de la intención de llevar al máximo buenas prácticas de desarrollo de software. Esta propuesta se fue tejiendo en las páginas del primer wiki-wiki 3 desde 1996, hasta que en 1999 se publicó el libro "Extreme Programming Explained" [6], que constituye el punto de partida de la difusión de esta nueva mirada. Siguiendo el camino de XP, surgieron otras propuestas similares tales como la australiana "Feature Driven Development" 4, las norteamericanas "SCRUM" 5, "Crystal Clear" 6, y la europea "Dynamic Systems Development Model" 7. En el año 2001, los líderes de este movimiento se reunieron para acordar un piso común de discurso. Es así que acordaron la denominación "ágil" para este tipo de metodologías ­ en vez del equívoco término "livianas" - y redactaron el "Manifiesto Ágil", donde se definieron 4 principios que establecen los criterios del movimiento ágil, que se presentan en la Tabla 3.

Individuos e interacciones Software funcional Colaboración con el cliente Responder al cambio por sobre

Procesos y herramientas. Documentación exhaustiva Negociación de contratos Seguir un plan
Tabla 3: Principios Ágiles

A partir de entonces, la influencia de este tipo de metodologías ha sido notoria, ­ hay miradas incluso que han tratado de asimilar XP a una configuración específica de RUP - aunque no exenta de polémica [51], existiendo estudios que afirman el crecimiento sostenido de su adopción en la industria del software [40], incluyendo a corporaciones de la importancia de Microsoft 8, Yahoo 9 y Google 10.
3 http://c2.com/wiki 4 http://www.featuredrivendevelopment.com/ 5 http://jeffsutherland.com/scrum/ 6 http://alistair.cockburn.us/crystal/wiki 7 http://na.dsdm.org/ 8 Darryl K. Taft, "Microsoft Lauds 'Scrum' Method for Software Projects", eWeek.com, http://www.eweek.com/article2/0,1895,1885883,00.asp 9 Pete Deemer, "How and Why go Agile", http://www.agileadvice.com/archives/2005/05/scrum_gathering.html 10 Dentro de los requisitos para trabajar en algunos de los proyectos de Google, se plantea como deseable tener experiencia en metodologías ágiles. (http://www.google.com/support/jobs/bin/answer.py?answer=23712&query=agile&topic=0&type=agile)

16



Página 17

3.2.1 Bases conceptuales de las MA
Las metodologías ágiles basan su propuesta en una revisión de la naturaleza del desarrollo de software surgida a la luz de nuevas teorías económicas generadas a raíz de la innovación tecnológica de las últimas décadas. En 1986, surge el concepto "desarrollo de nuevo producto" (NPD por su sigla en inglés 11) para referirse a todo esfuerzo por llevar un nuevo producto al mercado [52]. A diferencia de la "manufactura predecible", en los NPD no es posible predecir con precisión los tiempos y plazos que se deberían invertir para implementar un producto terminado. Al contrario, mientras más se avance en la solución del problema (y por ende en su comprensión), mejor será la capacidad de estimar [31]. Esto se debe a que en los NPD existen dos dimensiones de incertidumbre: la (in)certeza acerca de la tecnología, y el nivel de acuerdo en los requerimientos con los clientes, tal como se observa en la Ilustración 2:

Bajo Acuerdo

Requerimientos

a uí q ar An
Complejo
Complicado

Alto Acuerdo

Simple
Alta Certeza

Complicado

Baja Certeza

Tecnología
Ilustración 2: Complejidad de un NPD de acuerdo a sus niveles de incertidumbre

Un ejemplo típico de un desarrollo con alta incertidumbre de requerimientos pero tecnológicamente cierto es el componente de un sistema que entrega datos a otros. Existen un sinnúmero de tecnologías para enfrentar esta labor, pero acordar qué datos exactos generar es lo realmente complejo. Un ejemplo contrario ­ simple en requerimientos pero complejo tecnológicamente ­ sería un sistema de transporte de pasajeros a la Luna. Existe muchísima experiencia de servicios similares ­ buses, trenes, etc. ­ pero lo realmente complejo es como implementar tecnológicamente el servicio. La estrategia propuesta para enfrentar el desafío de un NPD es comparada con la formación de jugadores del rugby llamada Scrum, en donde se forma un grupo cohesionado de profesionales que integra todas las competencias (comerciales, técnicas, operacionales) necesarias para poder definir e implementar el producto. En este esquema, la estrategia ágil
11 New Product Development

17



Página 18

consiste en una relación colaborativa entre clientes y desarrolladores, a través de la cual se van disminuyendo progresivamente los niveles de incertidumbre en un modelo denominado concurrente, en oposición al tradicional modelo de pasos secuenciales característicos de un modelo cascada. Al ir avanzando en el trabajo es natural entonces que surjan cambios que alteren el plan original de trabajo, siendo el "ajuste de planificación" la labor más cotidiana de gestión en el modelo ágil, en oposición al "control de ejecución del plan" de los modelos secuenciales.

Aumentando la curva de valor
Tal como fue visto en la sección 3.1, la producción de real valor para el cliente es uno de los mayores problemas de la industria y que, a pesar de todos los esfuerzos, se ha ido acentuando. Es característico de los proyectos de software que el cliente sólo pueda recibir valor - medida en funcionalidades efectivas del sistema - por su inversión al final del proyecto. Esto es debido, entre otras razones, a que los desarrolladores tienen una mirada tecno céntrica, priorizando desarrollos que les "faciliten el trabajo a futuro" (como por ejemplo implementar una infraestructura de Base de datos con mantenedores simples de información) antes de preocuparse de poner en producción funcionalidades que sean directamente útiles a su cliente. Esta situación, contrastada con la ideal, es reflejada en la Ilustración 3:

funcionalidades

tiempo
Valor entregado de un proyecto tradicional

funcionalidades

tiempo
Valor ideal que debiera entregar un proyecto

Ilustración 3: Comparación entre el valor generado por un proyecto tradicional y lo que sería ideal

¿Cómo es posible entonces generar este mayor valor promedio? El principio básico que las MA proponen es realizar un diseño simple, con la ingeniería justa para cumplir con los requerimientos inmediatos del cliente, e ir empaquetando estos en entregables funcionales de forma periódica. En la visión ágil, esto es facilitado por el concepto del Scrum generado entre clientes y desarrolladores, pero tiene una fuerte amenaza radicada en el tradicional concepto de que cambiar es algo costoso en un proyecto de software, y que lo es en mayor medida a medida que el proyecto avanza. Esta creencia es la gran generadora de "sobrediseño" (también llamada "sobreingeniería"), que consiste en generar diseños demasiado ambiciosos y tempranos, antes de que se haya alcanzado la madurez suficiente para saber qué es lo que realmente se necesita, con el consecuente riesgo de generar funcionalidades de software que finalmente no son utilizadas, lo que constituye en sí un desperdicio no sólo por el tiempo que se invirtió en definir y desarrollar dichas funcionalidades, sino por el que se tendrá que invertir en mantener el código fuente del sistema. 18



Página 19

La revisión a la curva del cambio y la estrategia del timeboxing con contratos de alcance variable
Para lograr la agilidad necesaria para producir real valor lo más pronto posible, las metodologías ágiles se basan en una revisión de la curva del costo del cambio para un proyecto de software, tal como se observa en la Ilustración 4.

Costo del Cambio

Requerimientos Análisis

Diseño

Implementación

Producción

Costo del Cambio
Requerimientos Análisis

Ilustración 4: Curva de costo de cambio tradicional versus la revisada

Ti

Diseño

Implementación

Producción

Ti

Es decir, se plantea un modelo en donde el cambio es económicamente aceptable, y por lo tanto es posible adaptarse rápidamente a cambios en los requerimientos. Para poder lograr la curva de la derecha es necesario revisar las variables de gestión usadas predominantemente en la industria: x x x Alcance : la funcionalidad esperada del sistema Recursos: que se deben invertirse en el proyecto Tiempo: que se estima necesario para lograr el alcance

Existe además una cuarta variable, muchas veces oculta: la Calidad (entendida como eficacia, eficiencia y resistencia a fallas). Usualmente en los contratos de software se fijan las tres primeras variables (por ej.: se deben realizar las funcionalidades X,Y,Z con R recursos dentro de un tiempo T). Debido a la incertidumbre, es muy probable que surjan cambios a medida que se vaya conociendo más del problema, tanto de requerimientos por parte del cliente como de las estimaciones por parte del desarrollador, pero ante la rigidez de las variables antes nombradas, la única que queda para ajustar es la calidad, implicando por ejemplo menos tiempo para pruebas, lo que redunda necesariamente en un conflicto dado que ningún cliente quiere realmente algo de poca calidad y ningún desarrollador se sentirá satisfecho con un entorno que lo fuerce a realizar un mal trabajo. La segunda variable más elástica es el tiempo, dado que en caso de que un proyecto no cumpla con el alcance (aun con una calidad mínima) el plazo tiende a extenderse, es decir, el proyecto se "atrasa". Es por esto que se propone una nueva mirada, en la que Tiempo, Recursos y Calidad quedan fijos (dado que en realidad, todas estas variables no tienen mucha elasticidad), dejando el Alcance como la variable a gestionar. Lo anterior implica que la relación entre clientes y desarrolladores se debe realizar en un nuevo contexto, expresado en un conjunto de "deberes y derechos" [7]tal como se presenta en la Tabla 4: 19



Página 20

Derechos del cliente x x x

Derechos del desarrollador Conocer qué se necesita, con prioridades declaradas claramente Producir trabajo de calidad en todo momento. Pedir y entregar ayuda compañeros, superiores y clientes por

Tener un plan global, y conocer qué x puede ser logrado, cuándo y a qué costo Obtener el mayor valor de cada semana x de desarrollo Observar el progreso en un sistema x funcional, cuyo funcionamiento puede ser probado por ejecuciones exitosas de x pruebas repetibles que él puede especificar x Cambiar de opinión, canjear funcionalidades y cambiar prioridades sin pagar costos exorbitantes Ser informado de cambios de planificación, a tiempo para poder definir cómo ajustar el alcance para poder alcanzar la fecha original Cancelar en cualquier momento y tener en sus manos un sistema funcional que refleje lo invertido hasta ese entonces

Actualizar las estimaciones ante nuevos descubrimientos técnicos Aceptar responsabilidades en vez de que le sean asignadas.

x

x

x

Tabla 4: Declaración de derechos de clientes y desarrolladores

Estos deberes y derechos se ejecutan en un modelo gestión de tiempo denominado "timeboxing", consistente en que clientes y desarrolladores acuerdan una fechas de entrega, al final del cual, y luego de un trabajo orientado a la mayor calidad con los recursos disponibles, se obtiene un producto que aporte real valor al cliente, y cuyos detalles se irán acordando a medida que avance el desarrollo. Esto contrasta con el modelo tradicional en donde la fecha de término es incierta y está determinada por la "finalización" del producto pre-definido (hito que, dada la naturaleza incierta del producto que se desea, es bastante subjetiva). El modelo de tiempo fijo tiene varias ventajas: x El equipo de trabajo (que incluye al cliente) sabe a priori cuanto tiempo va a tener que dedicar al proyecto, tanto diariamente como semanalmente, lo que desde el punto de vista humano permite bajar la tensión provocada al miedo a equivocarse, que en los modelos tradicionales implican sobretiempos, atrasos en la generación de productos y horas extras. De hecho, el concepto de "atraso" desaparece. Existe un incentivo directo a ocupar de manera más productiva el tiempo que se tiene disponible para lograr resultados Se previene el uso indiscriminado de las nocivas horas extras, que como ya fue demostrado por Ford a comienzos del siglo 20 sólo provocan caídas sostenidas en la productividad. Y por último, en la industria existen testimonios que indican mejoras sustanciales de productividad cuando se ha aplicado este principio, tal como es mostrado por James Martin en su libro "Rapid Application Development" ya en 1991 [34]. 20

x x

x



Página 21

El ambiente de desarrollo de software y el aprendizaje

Avance de Proyecto: - ¿Cuánto hemos avanzado realmente (en generar real valor)? - ¿Cuáles y cuántas funcionalidades queda por hacer? - ¿Cuánto tiempo se requerirá para dichas funcionalidades? - ¿Qué defectos puede tener el producto? Método de Trabajo - ¿Qué prácticas y estándares se debe seguir? - ¿Qué errores no se debe repetir? - ¿Qué debemos mejorar?

?
Tecnología: - ¿Cuál tecnología usar? r? ? - ¿Qué sabemos hacer con la tecnología utilizada? - ¿Cuáles es posible hacer ( (limites) con la t tecnología?

?
Problema en resolución: - ¿Cuáles son la necesidades actuales? - ¿Cuáles son prioritarias?

Cliente

Desarrollador
¿Concuerdan?
¿Concuerdan?

Trabajo en Equipo: - ¿Cómo mantener la motivación? - ¿Cómo comunicarse efectivamente? - ¿Hay áreas del proyecto que sólo puedan ser mantenidas por uno?

?

Equipo de Desarrollo

Ilustración 5: El ambiente del desarrollo de software

En la Ilustración 5 podemos observar el ambiente de desarrollo de software, y lo complejo que es para las personas involucradas en él. Ellos deben entender tres aspectos: el problema de negocio a resolver, las herramientas tecnológicas que se están utilizando, y el estado del proyecto de desarrollo, y todos son blancos móviles. Además, la comprensión de cada uno difiere: el cliente domina en mayor medida el problema de negocio, mientras que los desarrolladores lo hacen con la tecnología, y a su vez cada miembro del equipo tiene un dominio distinto de las herramientas. Y estas comprensiones también van variando a lo largo del tiempo. Con respecto al estado del proyecto, usualmente son los desarrolladores los que tienen mayor comprensión de lo realizado. Sin embargo, una práctica común como es la estricta división de roles lleva a problemas tales cómo que se repita trabajo previamente realizado por otros, o que el esfuerzo requerido por la integración de los módulos desarrollados sea excesiva. Asimismo, la también común práctica de mantener una comunicación con el cliente restringida a hitos de entrega y basada en intercambio de documentación permite que lo programado por los desarrolladores diverja de las necesidades actuales del negocio. El resultado que se puede esperar sin una sincronización continua entre todos los involucrados es mejor reflejado por una clásica viñeta humorística acerca del desarrollo de un columpio que vemos en la Ilustración 6.

21



Página 22

Ilustración 6: El desarrollo de un software a través de la metáfora del desarrollo de un columpio

Como una solución a esta problemática, en el libro "Lean Software Development" [43]., los autores plantean que ante la naturaleza inherentemente variable de los proyectos de software, una herramienta fundamental es la "amplificación del aprendizaje", la cual se obtiene mediante la retroalimentación continua entre clientes y desarrolladores a través la integración de ambos en un sólo equipo y la generación y validación continua de entregables (software funcional) incrementales Por su parte, Ivar Jacobson, uno de los creadores de RUP, ha afirmado que una de las características fundamentales de un buen proceso de desarrollo de software es que este facilite el aprendizaje: "un buen proceso te permite aprender a medida que se avanza, sin frenar el avance del proyecto", e identifica esta propiedad con las metodologías ágiles [25]. Esto es apoyado por otras investigaciones que han analizado las metodologías ágiles desde el punto de vista de las ciencias del aprendizaje, y ha destacado el beneficio de las actividades de retroalimentación rápida propias a las metodologías ágiles como una manera reducir la complejidad cognitiva inherente en los desarrollos de software haciendo el ambiente de desarrollo más comprensible para los desarrolladores [8].

3.2.2 La propuesta de Extreme Programming (XP)
Extreme Programming (XP), la propuesta ágil más importante en la actualidad, recoge desde la industria diversas prácticas reconocidas por su aporte al éxito de los proyectos, y propone llevarlas al extremo (de ahí el nombre "Extreme Programming"). Algunos ejemplos son presentados en la Tabla 5. 22



Página 23

Práctica u Objetivo Revisiones de código Sistema de pruebas estructurado del sistema Software funcionando

Conocimiento compartido del dominio del problema a resolver, y de la estrategias de solución Conocimiento compartido de la estrategia de solución

Versión "extrema" "Programación de a pares", donde hay siempre a lo menos dos personas revisando el código concurrentemente "Desarrollo guiado por pruebas", en donde cada segmento del código ha sido construido a partir de una prueba que define su comportamiento correcto "Integración continua", en donde periódicamente se ensamblan los módulos del sistema, y "Entregables pequeños" que implica ir entregando incrementos de valor al cliente a través de entregables pequeños lo antes posible "Cliente in situ", en donde el cliente es integrado 100% al quehacer del grupo como un experto en el dominio a resolver "Metáfora" que indica qué se debe construir, un lenguaje común entre clientes y desarrolladores usando una comparación metafórica que facilite el entendimiento del sistema a desarrollar "Planning Game", que consiste en un juego colaborativo, en donde clientes y desarrolladores definen el alcance de cada iteración del desarrollo "40 horas a la semana", que indica que el trabajo debe hacerse normalmente dentro de la jornada laboral normal, dejando el esfuerzo de trabajar horas extras relegado sólo a situaciones extraordinarias, todo esto con el afán de mantener el equipo descansado y con capacidad máxima de producir Se complementa con "Planning Game", en el sentido de que esta última busca dar confianza a todos en el proyecto de que éste es realizable "Estándares de código", en donde el equipo norma un conjunto de reglas de formateo y nombrado de entidades en el código fuente "Refactorización", que indica que ninguna funcionalidad debe estar implementada más de una vez en el sistema, y que en caso de encontrarse alguna duplicidad, debe ser eliminada factorizando el código repetido. Esto evita que defectos arreglados en una parte del código persistan en otras partes "Diseño simple", que indica que lo que se diseña es sólo lo que realmente se va a utilizar. De esta manera se eliminan "áreas grises", con código que nunca se usa y que sin embargo engorda el código del sistema, y también se ahorra tiempo de los desarrolladores al no desperdiciar esfuerzos en funcionalidades que puede que nunca sean utilizadas "Propiedad colectiva de código", todos los desarrolladores son responsables y dueños de todo el código del sistema. Esto se refuerza por "Programación de a pares" y "Mantener el equipo rotando"

Equipo motivado

Código fuente comunicable

legible

y

Conocimiento compartido del sistema, como una forma de evitar dependencias excesivas en un desarrollador específico

Tabla 5: Buenas prácticas de la industria del software y su versión XP

Estas prácticas se definen como un conjunto de valiosas herramientas, cuya aplicación debe estar condicionada a la realidad de cada proyecto. Para facilitar este trabajo de aplicación, se propone un conjunto de criterios que se deben seguir, denominados "Principios de XP"[6], que se presentan en la Tabla 6:

23



Página 24

Principio Comunicación abierta y honesta

Explicación Debe darse a todo nivel, entre desarrolladores y con el cliente. Se entiende como la única forma de generar real confianza y un trabajo efectivo en equipo, evitar malos entendidos y poder prevenir a tiempo problemas Es aprovechar las características distintivas de cada persona a favor del proyecto, en vez de reprimirlas. Por ejemplo, si alguien se expresa mejor a partir de gráficos, motivarlos a su uso, entendiendo eso sí que la verdad definitiva del software está en lo realmente programado

Trabajar con los instintos de las personas

Responsabilidad aceptada En un equipo XP no se imponen tareas, sino que se exponen necesidades y (antes que asumida) cada cual se ofrece para aquella para la cual se considere mejor preparado. Relacionada con el coraje; implica abordar los mayores riesgos o problemas Atacar problema urgente, con decisión, definiendo alternativas para resolverlos, y evaluando cada uno dejando la mayor cantidad con experimentos pequeños que permitan tomar una decisión informada de opciones acerca del camino a seguir. Evitar la dependencia de herramientas costosas, sino contar con un kit mínimo de herramientas simples y valiosas. Esto da origen a los wikis para la Viajar con equipaje: poco, documentación, o a los frameworks para realizar pruebas de unidad como simple y valioso JUnit, pero evita la dependenciar de grandes y costosas suites de desarrollo para poder gestionar un proyecto de software. Adaptación local Cada proyecto tiene su propia realidad por lo que cada equipo deberá seleccionar aquellas prácticas de XP que mejor le sirvan, complementándolas con otras originadas en otras metodologías si es necesario Cada equipo debe mantener un fuerte compromiso con el aprendizaje rápido y continuo de todos, tanto del proceso de desarrollo, como del problema de negocio o de las tecnologías ocupadas Mantener una actitud positiva y optimista orientada a lograr el éxito del proyecto Cada producto desarrollado debe tener la mayor calidad posible. Esto no es negociable Debe privilegiarse siempre la solución más simple que pueda funcionar. Representada por la sigla YAGNI 12 El trabajo es siempre realizado en incrementos pequeños, lo que permite tener que validar cada vez cosas pequeñas, y si se ha fallado, perder poco

Enseñar a aprender

Jugar a ganar Trabajo de Calidad Asumir siempre simplicidad "Hacer lo más simple que posiblemente funcione" Cambios paso a paso

Mientras antes sepamos algo, antes se puede reaccionar. Esta retroalimentación puede venir del cliente, del propio sistema o de la forma Retroalimentación rápida en que está trabajando. Representado por la frase "Fail fast" (si algo va a fallar, que falle antes y con el menor costo posible) Experimentos concretos Hay que validar cada decisión abstracta o duda que se tenga con experimentos pequeños. Es decir, no hay que adivinar, sino actuar a partir de la realidad

12

De "You aren't gonna need it" ("No vas a necesitarlo"), es decir, antes de definir una solución validar fuertemente si realmente se va a necesitar o no. Ver http://c2.com/xp/YouArentGonnaNeedIt.html

24



Página 25

Principio Medir Honestamente

Explicación Medir el avance del proyecto de una manera que refleje realmente su estado, considerando sus particularidades y con datos reales.

Tabla 6: Principios de XP según Kent Beck en "Extreme Programming Explained"

Estos principios son englobados por cuatro valores sobre los que deben basarse los equipos XP: Coraje, Comunicación, Retroalimentación y Simplicidad. Como podemos observar, existe un fuerte énfasis en definir valores y principios que inspiren a las personas que practiquen XP. Esto no es de extrañar, dado el enfoque centrado en potenciar el recurso humano de las metodologías ágiles, que busca en definitiva hacer que cada persona del equipo pueda aportar el mayor valor posible a través de una mejor capacidad para tomar decisiones.

Cómo funciona XP
El funcionamiento de XP puede ser resumido según el esquema presentado en la Ilustración 7:

Ilustración 7: Flujo del trabajo en XP 13

El punto de partida consiste en el "Planning Game", en donde el usuario, en su lenguaje define "historias de usuario", las que son documentadas en tarjetas indexadas (como las usadas en las bibliotecas) y donde el cliente expresa alguna funcionalidad que espera del sistema. Cada tarjeta es analizada por los desarrolladores para lograr una estimación de esfuerzo, y en el caso de no poder lograrla debido a incertidumbre sin resolver, se le pide al cliente que especifique aún más la historia en una o más nuevas tarjetas. Si la incertidumbre es de tipo técnico, los desarrolladores pueden hacer mini-experimentos para tener una mejor idea del esfuerzo implicado por un requerimiento. Una vez que se logra un conjunto de historias de usuario estimadas, el cliente procede a definir aquellas que son más urgentes y que en su conjunto definan un sistema de software funcional, calculando un esfuerzo tal que calce con una fecha de entrega de la iteración. Con este conjunto de tarjetas, los desarrolladores pasan a
13

Fuente: www.borland.com

25



Página 26

planificar en detalle la iteración, definiendo tareas específicas surgidas a partir de las historias, y permitiendo que el desarrollador que asuma una tarea sea el encargado de estimarla. Luego, se pasa a la construcción del software, en donde cada funcionalidad es construida a partir de un test que especifica el funcionamiento esperado del módulo, para luego generar el código más simple que pase ese test. Si durante esta implementación se detecta que se está generando alguna redundancia con alguna otra parte del sistema, se factoriza la funcionalidad en un módulo común. Para que una historia de usuario sea aceptada, el cliente debe definir para los desarrolladores un conjunto de "pruebas de aceptación", es decir, una especificación de condiciones que defina con claridad los criterios que se usarán para determinar que una historia de usuario está completa, y que objetivice para los desarrolladores el funcionamiento macro de la historia. En caso de que alguna historia no pase sus pruebas de aceptación, se pasa a corregir los defectos hasta que se logre el objetivo. Una vez que todas las historias de una iteración estén aprobadas, se empaquetará un "entregable pequeño" para el cliente, quien procederá, si corresponde, a escoger un nuevo conjunto de historias para su implementación en una nueva iteración. La posibilidad de ajustarse al cambio se expresa en el derecho otorgado al cliente de definir nuevas funcionalidades en cualquier momento, las que pueden ser incorporadas a la carga de trabajo del equipo reemplazando historias de usuario aún no implementadas que impliquen un esfuerzo equivalente a la nueva. De manera similar, si el desarrollador encuentra nueva información que indique un cambio en las estimaciones iniciales, debe comunicarla al cliente y realizar los ajustes necesarios en la carga de trabajo de la iteración, sacando o simplificando historias si es necesario para cumplir con la fecha de entrega definida. Lo antes explicado puede resumirse en los "ritmos de XP", graficados en la Ilustración 8.
entregable pequeñoo pequeñ peque entregablepequeño g pq ñ pequeño
plan entrega lan plan entrega completar ompletar completar iteraciones eracio eraciones iteraciones entregar ntregar entregar oftware tw software software

planning game lanning g e planning game escribir scribir bir escribir historias istoria istorias ti historias estimar estimar historias de historias de usuario usua o usuario priorizar riorizar priorizar istoria istorias historias historias planificar lanificar planificar iteración teració teración e eraci iteración iteración

iteración te teración iteració iteración iteración completar ompletar completar a areas tareas tareas escribir scribir bir escribir tests de ests de t tests de aceptación ceptació ceptación t aceptación p aceptación

planificar iteración lanificar iteración iteració planificar iteración p ón iteración seleccionar eleccionar eccio seleccionar hi t i istoria istorias historias historias dividir dividir historias en historias en tareas tareas ta eas estimar stimar m estimar tareas tareas a tareas asumir asumir tareas tareas escoger escoger par par

tarea a area a tarea listar ítemes sta emes star í e ítemes listar ítemes por h or hacer por hacer completar ompletar completar ítemes por emes e ítemes ítemes por hacer a acer hace hacer h

código de colores digo g es có código código de colores equipo equipo completo completo

ítem por hacer te em ítem por hacer ít ítem escribir scribir bir escribir test test et test Escribir Escribir código que código que cumple test cu p e t cumple test refactorizar refactorizar sin piedad sin piedad integrar integrar código código

cliente cliente

desarrollo desarrollo

Ilustración 8: Ritmos de XP 14

14

Fuente: www.diamond-sky.com

26



Página 27

En resumen, XP propone pasar de diseñar-programar-probar-depurar-armar-entregar, a diseñar continuamente, probar continuamente, armar continuamente, revisar continuamente y entregar temprana y frecuentemente.

Interdependencia entre las prácticas
Como ya pudo observarse en la Tabla 5, las prácticas de XP funcionan mejor si están apoyadas por otras. Esto ya fue indicado por Kent Beck, tal como se muestra en la Ilustración 9.
On Site Customer Planning Game 40 Hours Week Metaphor

Refactoring

Simple Design

Short Releases Testing Pair Programming

Coding Standards Collective Ownership Continuous Integration

Ilustración 9: La interrelación de prácticas de XP, según Kent Beck en la primera edición de "Extreme Programming Explained"[6]

Por ejemplo, la refactorización es la herramienta fundamental para mantener el diseño del sistema en su estado más simple posible. De manera similar, el Desarrollo Guiado por Pruebas servirá para detectar cualquier problema que una refactorización del código del sistema pueda causar a la funcionalidad ya implementada. El diseño simple es también apoyado por la programación de a pares, por el efecto conocido de que "dos cabezas piensan mejor que una", lo que conlleva a obtener diseños mejor pensados y más simples. Podrían indicarse otros ejemplos, pero como es posible observar, existe un delicado equilibrio que debe lograrse al implementar este conjunto de prácticas propuesto por XP.

Roles dentro de un equipo XP
En XP se plantean dos roles especiales, que pueden ser compartidos por una persona: el coach y el tracker. El primero es el líder del equipo, quien en base a su experiencia y dominio de XP tiene como labor principal formar a sus compañeros en la mejor toma de decisiones, potenciándolos para que "hagan un trabajo aún mejor". El tracker por su parte, es el encargado de ir recogiendo la información de avance del proyecto (tareas logradas, historias aceptadas por el cliente, esperado versus logrado, etc.). Esta información será publicada en un lugar visible por todo el equipo, como medio de retroalimentar el avance y dar al equipo una perspectiva de la sanidad del avance.

27



Página 28

3.2.3 El problema de la adopción de XP en la industria
Al momento de plantear una eventual adopción de alguna metodología ágil, y en particular XP es importante el analizar cuáles son los escollos que es posible esperar, algunos de los cuáles ya fueron planteados por el propio Kent Beck en "Extreme Programming Explained" [6]. Una primera afirmación que es posible realizar, es que la adopción de XP presenta problemas extrínsecos e intrínsecos. Los primeros son los debidos a que XP plantea una mirada revisionista a la ingeniería de software actual, y por ende plantea un cambio calificado incluso de cultural [56]. Los segundos son aquellos planteados por la rica pero compleja gama de herramientas conceptuales que conforman XP (4 valores, 16 principios y 12 prácticas interrelacionadas entre sí). A continuación se presentarán dichos desafíos en más detalle.

Desafíos extrínsecos: XP versus el establishment
XP plantea un número no despreciable de nuevos paradigmas en el desarrollo de software, lo que claramente implica un esfuerzo no menor de evangelización y cambio cultural, lo que ha sido refrendado por diversos reportes de experiencias [35]. Además debe considerarse que si bien XP plantea como principio trabajar con los instintos de las personas y no en contra de ellos, hay que saber muy bien diferenciar un instinto de un paradigma que la persona puede tener muy internalizado en sí. Por ejemplo, la visión tradicional de la gestión de desarrollos de software contrasta con la visión que XP tiene de la misma, tal como se puede apreciar en la Tabla 7:
Aspectos Relación clientedesarrollador Ciclo de vida Rol de la planificación Costo del cambio Actitud frente al cambio de requerimientos Tipos de Contratos Esfuerzo de diseño Priorización del esfuerzo Herramienta para mejorar el éxito de los proyectos Tradicional Defensiva, con cláusulas de castigo en caso de no cumplimiento Cascada Guía de debe cumplirse estrictamente Exponencial a medida que avanza el proyecto Enojo, miedo, a la defensiva De precio, tiempo y alcance fijos Principalmente el comienzo del proyecto, y del sistema completo 15 Según la perspectiva técnica Proceso bien definido, que debe seguirse y controlarse XP Colaborativa en pro del éxito del proyecto Iterativo Guía que debe ajustarse continuamente a la realidad Puede lograrse un costo constante Positiva, empática con la necesidad que origina el cambio De alcance variable Emergente a media que se conoce con certeza cada incremento del sistema a construir. "Lo más simple que pueda funcionar" Según la perspectiva del cliente Personas bien formadas que comparten un conjunto de valores, principios y prácticas comunes

15

Denominado "BDUF", por la sigla en inglés de "Big Design Upfront" ("Gran Diseño Anticipado"). Ver http://c2.com/xp/BigDesignUpFront.html

28



Página 29

Aspectos Herramientas de comunicación

Indicador de compromiso con la empresa Liderazgo del equipo

Tradicional Documentación exhaustiva y abstracta de requisitos y diseño, principal medio de comunicación entre clientes y desarrolladores Dedicar muchas horas extra a la jornada laboral para completar las tareas Vertical, la responsabilidad está centrada en el jefe de proyecto Saber siempre

XP Documentación somera, pero útil para constituir una base de conversación de "banda ancha" entre clientes y desarrolladores Dedicar las horas de una jornada normal a producir al ritmo más elevado de calidad Horizontal, el coach tiene un rol de guía y de formador hacia la toma de buenas decisiones por parte de todos. Saber expresar claramente lo que domina, saber pedir apoyo frente a temas que desconozca, y mantener una actitud siempre abierta al aprendizaje

Indicador de capacidad del desarrollador

Tabla 7: Comparación entre los conceptos tradicionales y los de XP

Asimismo, en la praxis de los ingenieros de software prevalecen prácticas que también son revisadas por XP, como vemos en la Tabla 8.
Aspectos Ciclo programación Costo de pruebas de hacer Tradicional Programar, probar, depurar, probar, depurar, etc. Más que simplemente programar la solución Complejo, previendo muchos casos que "podrían alguna vez necesitarse", (también llamado "sobrediseño") XP Definir la prueba, programar el código más simple que pase la prueba (Desarrollo Guiado por Pruebas) Menos, debido a que se evitan ciclos eternos de depuración Simple, lo justo y necesario para lo que estamos seguros de necesitar ahora. Para mantener la simpleza, se refactoriza "sin piedad" para evitar cualquier duplicación de funcionalidad en el código. Nunca permanece en el sistema código que no tenga aplicabilidad directa al problema a resolver Dos personas en un mismo esfuerzo implica mejores soluciones, menos defectos y en definitiva, un desarrollado de calidad más acelerado El que estima es la persona que asume la responsabilidad de ejecutar la tarea La propiedad del código es de todo el equipo, que rota, de a pares constantemente en la implementación de funcionalidades

Diseño

Trabajo en solitario versus de a pares Responsabilidad sobre estimaciones

Dos personas trabajando en una sola tarea es un desperdicio, es mejor paralelizar esfuerzos. El que estima es un experto, usualmente el jefe de proyecto Cada desarrollador está a cargo de una parte del código. Suele generarse dependencia de un desarrollador específico debido a que es el único que conoce cómo está hecha una parte del sistema

las

Propiedad del código

Tabla 8: Comparación entre prácticas de desarrollo tradicional y XP

29



Página 30

Desafío intrínseco: Apropiación del marco conceptual y transferencia de prácticas de XP
En un mundo ideal, en donde no existiese una cultura alterna a la propuesta de XP, aún su adopción sería un desafío. A continuación veremos por qué. XP plantea un conjunto interrelacionado e interdependiente de prácticas que definen la relación entre cliente-desarrollador, el desarrollo de software en equipo y la forma de programar software. Es decir, no sólo basta con conocer cada práctica, sino que hay que aplicarlas apoyándose en otras que las complementan y fortalecen, buscando generar un balance entre ellas [6]. Se entregan un conjunto de principios orientadores que debieran facilitar este proceso, pero su cantidad tampoco es menor. Así que las preguntas que naturalmente surgen son: x x ¿Por dónde partir? ¿Cómo continuar a partir de allí?

Meta-desafíos
Al unirse los tipos de desafíos extrínsecos e intrínsecos antes descritos, surgen dos muy particulares que son indicados por Kent Beck[6]: x x "Pequeños malos entendidos pueden ser desastrosos". "Al ser sometidos a stress, la gente vuelve a sus antiguas costumbres"

Analizaremos cada uno más en detalle. "Pequeños malentendidos pueden ser desastrosos". El correcto entendimiento del complejo marco de XP está sometido a un fuerte stress debido a las concepciones imperantes en la industria. Un ejemplo expuesto por el propio Beck [6], plantea que un equipo de desarrollo que estaba adoptando XP estaba teniendo problemas para lograr sus objetivos de desarrollo. Luego de analizar el problema, se encontró lo descrito en la Tabla 9:
Proceso de planificación de tareas propuesto por XP 1. Inscribirse en una tarea 2. Estimar las tareas propias 3. Re-balancear si alguien está sobrecargado Entendido por el equipo 1. Estimar tareas colectivamente 2. Inscribirse en las tareas

Tabla 9: Contraste entre planificación según XP y su interpretación por un equipo de desarrollo

El ligero cambio de orden en el proceso, y la eliminación del último paso provocaban que mucha gente asumiese tareas con una estimación que no calzaba con su propia idea del esfuerzo implicado. Esto generaba un grave desorden en la planificación y seguimiento del proyecto debido a que se perdía inmediatamente contacto con la realidad del avance. "Al ser sometidos a stress, la gente vuelve a sus antiguas costumbres" El buen entendimiento de XP es sólo el comienzo. Si bien es posible hacer el cambio de paradigma, bajo stress, la gente vuelve a actuar de la forma en que estaba acostumbrada originalmente [20], por lo cual cualquier cambio logrado debe ser sostenido y gestionado en el tiempo [6]. Este efecto ha sido documentado en diversos reportes de campo, en donde

30



Página 31

prácticas como "Desarrollo Guiado por Pruebas" suelen abandonarse en los momentos en que más sería necesario sostenerla [28]. La rápida evolución y reformulación de XP Muchas prácticas del marco conceptual de XP han sido refinadas intensamente en el tiempo. Es así como "40 horas a la semana" se ha replanteado como "productividad sostenida", o que "cliente in-situ" ahora se llame "un solo equipo (conformado por clientes y desarrolladores)". Inclusive acaba de salir una segunda versión de "Extreme Programming Explained" que redefine y reorganiza mucho de lo planteado en el libro original, y que, debido al impacto de estos cambios, escapa al alcance de esta investigación. Todo lo anterior nos lleva al punto siguiente: ¿qué estrategias se han propuesto para la adopción exitosa de XP?

Buscando un punto de partida para aplicar XP
En "Extreme Programming Explained", Beck ya proponía la siguiente estrategia de adopción: 1. Escoger el peor problema. 2. Resolverlo al estilo XP. 3. Cuando ya no sea el peor problema, escoger otro y repetir. Esta estrategia deja una pregunta abierta: para resolver un problema "al estilo XP", primero debo saber aplicarla. Es así que Beck basa la aplicación de XP en la destreza de un coach experto, que sirve de mentor y guía a su equipo. Pero igual queda la duda de cual es el punto inicial por donde dicho coach deberá partir su trabajo. En el 2001, en "Extreme Programming Applied ­ Playing to win" [4], dos adoptadores tempranos de XP a partir de su experiencia en la empresa Role Model Software plantean un modelo en el que se priorizan aquellas prácticas que son consideradas fundamentales: x x x x x x Planificación y estimación (Planning Game) Entregables pequeños (e iteraciones) Desarrollo Guiado por Pruebas Programación de a pares Refactorización Integración continua

El resto de las prácticas se consideran "suplementarias". Posteriormente en el 2003, en el libro "Lean Software Development" [43] se plantea que el punto de partida inicial (y el pivote a partir del cual puede comenzar el cambio hacia un modelo ágil) está en el planificar el desarrollo en iteraciones de tamaño fijo que entreguen cada una incrementos de valor para el cliente, lo que tiene mucho sentido pues si observamos las otras prácticas antes nombradas, están todas dirigidas por este principio.

31



Página 32

Herramientas para difundir y adoptar XP
La primera herramienta que se usó para difundir XP y sus principios fue el primer Wiki-Wiki creado por Ward Cunnigham 16, en donde se fueron escribiendo y depurando a modo de una lluvia colaborativa de ideas los conceptos fundacionales de XP. Posteriormente se abrieron otros sitios de difusión, entre los que podemos destacar: x xprogramming.com: sitio de Ron Jeffries, el coach del primer proyecto XP (C3), con diversos artículos donde se presentan aplicaciones de prácticas XP como el desarrollo guiado por pruebas, la programación de a pares, y se reflexiona sobre fundamentos de XP extremeprogramming.org: sitio de Don Wells, otro de los primeros proponentes de XP, donde se presenta mediante diagramas el funcionamiento interno de XP www.martinfowler.com: sitio de Martin Fowler, con información sobre XP aplicado en sistemas de bases de datos relacionales, y algunas reflexiones teóricas sobre XP

x x

Otra instancia de difusión de importancia son las conferencias anuales sobre XP (XP2000, XP2001, etc.) que se realizan todos los años desde el 2000, y las que se realizan sobre metodologías ágiles en general. Herramientas de entrenamiento La comunidad de desarrolladores que ha adoptado XP también ha diseñado técnicas que hacen más simple el explicar sus prácticas. Por ejemplo, Peter Merel inventó y documentó en el wiki de XP la llamada "Extreme Hour" 17 como una forma de explicar de manera simple y significativa el Planning Game. En este taller desarrolladores y clientes se reúnen por una hora, para simular el desarrollo de un invento cuyas funcionalidades serán solicitadas mediante tarjetas, y cuya construcción es realizado en iteraciones de pocos minutos a través de dibujos en una pizarra. Siguiendo esta línea, han surgido otras herramientas similares, entre las que podemos destacar: x x Games for Programmers 18: donde se listan una serie de talleres en donde se proponen juegos para entrenar al equipo en las prácticas de XP. XP Simulation & Games 19: aquí la empresa Industrial Logic presenta un kit de tarjetas con las que se pueden realizar diversos juegos para aprender XP. También se proponen talleres para explicar prácticas específicas.

http://www.c2.com/cgi/wiki?ExtremeProgrammingRoadmap http://c2.com/cgi/wiki?ExtremeHour 18 http://www.xp123.com/g4p 19 http://industriallogic.com/games/
16 17

32



Página 33

3.3 El estado del arte de la Ciencia del Aprendizaje
Tal como se presentó en el punto 3.2.1, la incertidumbre es parte de la naturaleza del desarrollo de software, lo cual ciertamente impacta tanto la formación cómo la labor diaria de quienes realizan esta labor: los ingenieros de software. Para poder profundizar en este tema, se introducirán algunos descubrimientos realizados en el área de las ciencias de la educación, que servirán a su vez como base para analizar el problema de la incertidumbre como parte natural del desarrollo de software.

3.3.1 Los antecedentes de la ciencia del aprendizaje
El estudio de la mente humana mediante métodos científicos surge a fines del siglo 19, tomando el lugar que anteriormente había sido ocupado por la teología y la filosofía[19]. Uno de los pioneros en esta nueva ciencia denominada "psicología" fue el estudioso alemán Wilhelm Wundt quien, junto a su equipo, trató de poner la conciencia humana bajo análisis principalmente mediante pedir a sus sujetos de estudio que reflexionasen acerca de sus propios proceso de pensamiento mediante la introspección [18]. Al comienzo del siglo XX surge una respuesta denominada conductismo que critica al modelo anterior debido a la subjetividad inherente de la introspección, y abogando por un estudio restringido a observar conductas observables y los estímulos que la provocan. De esta manera los conductistas concibieron el aprendizaje como un proceso interno de formación de relaciones entre estímulos y respuestas. En esta mirada, el aprendizaje aparenta estar motivado por necesidades internas como el hambre, o por fuerzas externas como recompensas o castigos, tal como planteaba Edward L. Thorndike en 1913[19].. Fruto de esta mirada es la enseñanza orientada al aprendizaje memorístico, en el que el aprendiz orienta su labor al estudio, memorización y repetición de conceptos, siendo esta última una evidencia observable de aprendizaje considerada como suficiente por el conductismo. De más está decir que este modelo pedagógico todavía influencia mucha de la práctica educativa actual. Una limitación del conductismo es que el foco en la conducta observable hace difícil estudiar fenómenos de importancia fundamental para el aprendizaje tales como el entendimiento, el razonamiento y el pensamiento. Es así que surge el denominado neo-conductismo, que se permite formular hipótesis acerca de los "estados mentales" que explican las conductas observadas, como el planteado por Clark Hull en 1943[19]. A fines de los 1950, se hizo evidente la complejidad del entendimiento humano, lo que dio origen a un nuevo campo de estudio, la ciencia del aprendizaje (también denominada ciencia cognitiva), que enfrenta de manera multidisciplinaria el aprendizaje incorporando elementos antropológicos, filosóficos, y sociológicos, entre otros. El desarrollo de nuevas herramientas experimentales, como el análisis cualitativo riguroso, ha permitido que el estudio del funcionamiento de la mente humana pueda ser efectivamente estudiado más allá de las conjeturas hipotéticas.

3.3.2 La ciencia del aprendizaje: aprender con entendimiento
El principal énfasis de la ciencia del aprendizaje es el aprender con entendimiento, Por esto, veremos cómo entender el proceso de aprendizaje mediante una teoría de la cognición, y cómo aprovechar este nuevo conocimiento al enseñar para lograr una efectiva mejora en los aprendizajes obtenidos. De esta manera se estará atacando una reconocida falencia de los 33



Página 34

ambientes de educación formal, que históricamente han sido mejores para seleccionar alumnos que para formarlos [8].

La visión constructivista del proceso de aprendizaje
La ciencia cognitiva no niega la importancia que el conocimiento de hechos tiene para lograr el entendimiento. Sin embargo hay una gran diferencia entre conocer una gran cantidad de hechos desconectados, y el denominado "conocimiento útil", que servirá de base a para discriminar cuando el conocimiento es aplicable o no a ciertos contextos, y transferir lo conocido a nuevos contextos [46][18]. Es así que el conocimiento de un experto suele estar organizado y conectado en torno a principios importantes, a diferencia del novicio que suele organizar su conocimiento en base a conceptos superficiales. Por ejemplo, y contextualizando en el tema de esta tesis, donde un novicio entenderá superficialmente la práctica de XP "40 horas de trabajo a la semana" como algo solamente aplicable a proyectos con dedicación de jornada completa, y por ende, no podrán transferir este concepto por ejemplo, a un curso sobre XP; en cambio un experto la entenderá dicha práctica como "planificar un tiempo de dedicación al proyecto, y respetarlo, gestionando la carga de trabajo de tal manera que este tiempo sea respetado, y sólo excepcionalmente, excedido. Todo esto buscando generar una productividad sostenida en el equipo". Pero, ¿cómo sucede el aprendizaje? De los estudios de Jean Piaget y Lev Vigotsky[19][62], entre otros, se ha conceptualizado a las personas como agentes orientados a objetivos que activamente buscan información, trayendo con ellas un conjunto de conocimientos previos (creencias, habilidades, recuerdos, etc.), los que influencian significativamente qué y cómo captarán y organizarán la nueva información a obtener [18]. Es decir, las personas usarán sus conocimientos previos como base para construir los nuevos, y a su vez re-organizar lo anteriormente aprendido (re-construir). Esta mirada ha dado origen a la teoría del aprendizaje denominada constructivismo. Es importante, eso sí, hacer notar que los nuevos aprendizajes desarrollados pueden o no ser ciertos. Por ejemplo, un estudio de Vosniadou y Brewer de 1989[19]. mostró cómo niños pequeños que creían que la tierra era plana, al comentárseles que era redonda, asumían entonces que la forma era de tortilla, y no una esfera, dado que según su modelo mental previo, que les permitía entender cómo era posible que ellos pudiesen caminar sobre la superficie de la tierra, lo más asimilable era a una forma de tortilla, pero no a una forma esférica como las que ellos conocen (una pelota, por ejemplo[55]. Un elemento adicional fue aportado por Vigotsky, al conceptualizar la llamada "Zona Proximal de Desarrollo" (ZPD)[62] de los aprendices, que indica que existe un conjunto de aprendizajes que es posible que un aprendiz pueda lograr a partir de sus conocimientos previos. Por ejemplo, un niño que no tenga noción de que vive en un planeta "Tierra", no estará preparado para apropiarse del conocimiento de que ésta es redonda, ni siquiera con el error de entendimiento antes presentado. De lo anterior se desprende que uno de los roles fundamentales de un formador es poner atención a los conocimientos previos de sus aprendices, definir qué aprendizajes están en la ZPD de ellos, y luego de la actividad educativa revisar comprensiones incompletas y creencias falsas. El no realizar lo anterior puede implicar que los aprendices no aprendan, o, si lo hacen, vuelvan a sus concepciones anteriores al poco tiempo. Un error de interpretación común del constructivismo es que los formadores nunca deben indicar a sus alumnos qué aprender, sino que los aprendices siempre deben construir sus aprendizajes ellos mismos. Esta tendencia, llamada por algunos "aprendizaje natural", confunde una teoría de aprendizaje con una teoría pedagógica, debido a que los aprendices 34



Página 35

siempre construirán sus aprendizajes sin importar si estos son motivados por un formador o por el medio.

Hacia un aprendizaje activo mediante la metacognición y el soporte instruccional
Dado que el entendimiento es tan importante para el aprendizaje, la ciencia cognitiva plantea la importancia de que las personas adquieran la habilidad de reconocer cuándo están realmente entendiendo, y cuando necesitan más información, es decir, tomar control activo de su propio aprendizaje. La herramienta para lograr esta habilidad es denominada metacognición[17] (literalmente, el entendimiento sobre el mismo entendimiento) que ha sido definida como la habilidad de una persona de predecir su rendimiento en una tarea, poder monitorear sus niveles actuales de maestría y entendimiento, y seguir estrategias para mejorarlos, mediante planificación, predicción, retroalimentación , reflexión y validación constantes[13]. El formador actúa en este contexto frente a sus aprendices a través del denominado soporte instruccional 20, siguiendo esta ruta: x x A partir de los conocimientos previos de sus aprendices, Provee un soporte, si bien no necesariamente muy amplio, que sirva como una base sólida de explicación y práctica de conceptos y destrezas fundamentales al aprendizaje esperado (el soporte instruccional), el que está compuesto de recursos, desafíos motivadores, guías y plantillas y apoyo para la metacognición. El soporte es retirado gradualmente por el formador a medida que sus aprendices van adquiriendo autonomía en sus estrategias de aprendizaje a través de la práctica y del uso de herramientas metacognitivas.

x

El constructivismo social, la teoría del aprendizaje situado y el modelo pedagógico de aprendizaje cognitivo 21
El constructivismo ha tenido dos enfoques, uno liderado por los planteamientos de Jean Piaget, denominado constructivismo psicológico, el que está centrado en el aprendiz individual y su relación con un formador siguiendo los esquemas de interacción planteados en los puntos anteriores, y el inspirado por los planteamientos de Lev Vigotsky, llamado constructivismo social, en donde el aprendizaje se entiende como inherentemente situado, es decir, está ligado fuertemente al entorno sociocultural. El aprendizaje se produce entonces a través de la relación con una comunidad de aprendices, donde es relevante el contexto físico del aprendizaje y la interacción con los pares. Ambas visiones no son contrapuestas, sino dos partes de un mismo sistema, tal como expresa lo resume Driscoll[61]: "El conocimiento es construido por los aprendices a medida que intentar generar significado de su experiencias". Basado en el constructivismo social, la antropóloga Jean Lave propuso una teoría pedagógica denominada aprendizaje situado, la cual plantea que el aprendizaje está naturalmente ligado a actividades auténticas, contexto y cultura [32]. Es decir, el "saber qué" no puede ni debe separarse del "saber cómo". Como ejemplo de lo anterior, es más difícil aprender un idioma desde actividades antinaturales como leer un diccionario, que sumergiéndose en una comunidad de personas que ya hablen dicho idioma. Esta mirada critica a la educación formal imperante indicando que ésta tiende a abstraer el aprendizaje, segregando los conceptos de
20 21

Traducción del inglés "instructional scaffolding", literalmente "andamio instruccional". Del inglés "Cognitive apprenticeship". La traducción literal de "apprenticeship" es "aprendizaje", pero hay que notar que la acepción común del término castellano falla en recoger la relación maestro-aprendiz subyacente en el vocablo inglés

35



Página 36

los contextos naturales de aplicación. Sin embargo, durante la mayor parte de la historia de la humanidad, este no ha sido el caso. Las personas suelen adquirir mucho de su aprendizaje en un modelo similar al de "maestro-aprendiz", común en los talleres de oficios, y mediante los cuales, entre otras cosas, un niño aprende a hablar, un artista aprende su oficio, o los profesionales aprenden los detalles de su oficio una vez que han salido de la universidad. Brown, Collins, y Duguid plantean una comparación entre el aprendizaje de personas comunes, estudiantes y practicantes [14]tal como se aprecia en la Tabla 10:

Personas comunes Razonan con: actúan en: solucionan: producen: Historias casuales Situaciones Problemas emergentes y dilemas

Estudiantes Leyes Símbolos (conceptos) Problemas definidos bien

Practicantes (Aprendices) Modelos casuales Situaciones conceptuales Problemas vagamente definidos

Significado negociado, y entendimiento construido socialmente

Significados fijos, y conceptos inmutables

Significado negociado, y entendimiento construido socialmente

Tabla 10: Comparación entre el aprendizaje de personas comunes y estudiantes

Como es posible observar, existe una gran similitud entre las actividades de un practicante y una persona común. Ambas tienen actividades auténticas situadas en las culturas en la que trabajan, dentro de las cuáles negocian significados y construyen entendimiento. Por su parte, los estudiantes son conminados a razonar sobre reglas y conceptos definidos por otros, actuar sobre sistemas y símbolos aceptados y resolver problemas bien definidos. En el contexto de un taller de oficios tradicional, el maestro presenta a sus aprendices cómo realizar una tarea desafiante, muchas veces verbalizando y demostrando cada uno de los pasos involucrados en ella, observa cómo el aprendiz realiza partes de la tarea, y luego va paulatinamente entregando más responsabilidad hasta que el aprendiz es suficientemente autónomo para realizar el solo la tarea, lo que rememora el modelo de soporte instruccional presentado anteriormente. Sin embargo, hay que notar que mucho del aprendizaje se produce mientras los aprendices se observan y dialogan entre sí mientras realizan sus labores. Este modelo se produce en un entorno denominado por Jean Lave cultura de práctica, la cual está compuesta además por valores y creencias comunes. Si se desea llevar este modelo a una sala de clases, nos encontraremos con desafíos particulares los cuales presentamos en la Tabla 11:

36



Página 37

Contexto del Taller de Oficios Visibilidad aprendizaje Surgimiento tareas del Simple, debido a que la tarea es observable en la construcción del producto Naturalmente, por requerimientos de construcción de productos tangibles

Contexto de la Sala de Clases El profesor debe hacer visible su razonamiento. El profesor debe enseñar materias del currículum (matemáticas, ciencias, lenguaje, etc.), muchas veces divorciadas de los que los niños y adultos hacen en sus vidas. El desafío es contextualizar el conocimiento en contextos significativos (auténticos) para los alumnos. Los alumnos deben transferir sus aprendizajes a otros contextos. El profesor debe presentar un conjunto de tareas en contextos distintos, y luego apoyar la reflexión acerca de los elementos comunes entre ellos.

de

Habilidades practicar

a

Inherentes y restringidas al oficio. (Ejemplo: un aprendiz de sastre debe aprender a medir y cortar tela, y no a cortar piezas de roca o madera, como lo hace un escultor)

Tabla 11: Desafíos derivados de llevar el modelo del taller de oficios a la sala de clases

Estos desafíos dan pie a un modelo pedagógico denominado aprendizaje cognitivo[14], cuyos pasos son explicados en la Ilustración 10:

37



Página 38

APRENDIZAJE COGNITIVO APRENDIZAJE COGNITIVO
Flujo del modelo pedagógico Flujo del modelo pedagógico

Profesor Profesor
Recopilación Estrategias Expertas
Considerar las estrategias que un experto aplicaría en una tarea.

Aprendices Aprendices

Diseño soportes instruccionales i
Diseñar desafíos que, actuando como soportes instruccionales, motivarán a los aprendices a aplicar las estrategias. Estas actividades estarán situadas u orientadas a resultados relevantes.

Modelado de estra o estrategias
Modelar las estrategias a sus alumnos a través de la resolución del desafío

Práctica Guiada ( (Coaching) g)
ofrecer retroalimentación y consejo experto practicar habilidad resolviendo el desafío

Metacognición Motivación
Motivar en sus alumnos la metacognición

Articulación
Verbalizar los razonamientos y métodos usados para resolver el desafío, (metacognición)

Reflexión
Reflexionar y aprender de las estrategias usadas por sus pares y por el profesor.

Exploración lorac
Retirar paulatinamente el apoyo Aplicar estrategias a nuevos problemas.

Ilustración 10: Flujo de pasos del modelo pedagógico de Aprendizaje Cognitivo

38



Página 39

3.4 Educación de la Ingeniería de Software
En el 2001 la Computer Society of the Institute for Electrical and Electronic Engineers (IEEE-CS) y la Association for Computing Machinery (ACM) formaron un grupo de trabajo denominado Joint Task Force on Computing Curricula 2001 (CC2201) 22, con el objetivo de realizar una revisión detallada de los lineamientos curriculares para programas de pre-grado en computación. El currículum planteado 10 años antes integraba en un solo documento recomendaciones para Ciencias de la Computación e Ingeniería de Software. En esta nueva revisión se reconoce la necesidad de abarcar más disciplinas. De este trabajo, y a partir de la revisión de las experiencias educacionales en varios países surge una subdivisión de la Computación en 5 áreas, de acuerdo a tres criterios: orientación hacia Ciencias de la Ingeniería, grado de énfasis en el hardware y grado de énfasis en aplicaciones. Los nombres de las áreas fueron tomados de programas comunes en los EEUU.

Computing Curricula 2001 Structure
Overview Joint Task Force on Computing Curricula ACM IEEE Computer Society Other societies ?? Information Systems ACM Association for Information Systems (AIS) Association of Information Technology Professionals (AITP) IEEE Computer Society

Computer Science Computing Curriculum 2001 Steering Committee ACM IEEE Computer Society

Computer Engineering Computing Curriculum Computer Engineering Steering Committee ACM IEEE Computer Society

Software Engineering Computing Curriculum Software Engineering Steering Committee ACM IEEE Computer Society Several other societies

Information Technology Computing Curriculum Information Technology Steering Committee ACM IEEE Computer Society

Ilustración 11: Áreas curriculares de la computación propuestas por CC2001 23.

A continuación se presentaremos una breve descripción de cada área: x Ciencias de la Computación: El foco de esta área está en la ciencia y la tecnología de la computación. Existen diversas aproximaciones al currículo de estos programas, tal como se ve en la Ilustración 12.

22 23

Ver http://www.sigcse.org/cc2001/ y http://www.acm.org/education/curricula.html http://www-static.cc.gatech.edu/~rich/21st.ppt

39



Página 40

Ilustración 12: Niveles de cursos y estrategias de implementación

En el enfoque basado en tópicos, los alumnos reciben una instrucción en diversas áreas técnicas, como algoritmos, sistemas operativos, bases de datos. El enfoque comprimido selecciona sólo alguno de esos tópicos, el enfoque basado en sistemas pone su énfasis en arquitecturas computacionales y el enfoque basado en web se especializa en el desarrollo de software web x Sistemas de Información: Está orientado al manejo de la información en el contexto de una organización, por lo cual el currículum parte con una perspectiva centrada en la organización y no en la tecnología Ingeniería de Computadores: Está orientada en la construcción de sistemas de hardware y software con énfasis ingenieril. Posee una fuerte influencia de tópicos de hardware a través de la carrera. Tecnologías de la Información: Es la más nueva de las áreas, y aquí el énfasis es la aplicación de la tecnología computacional en múltiples contextos. Ingeniería de Software: Está orientada a la construcción de sistemas de software para resolver necesidades de un cliente, con una mirada ingenieril. Como esta área es el contexto de esta investigación, en el próximo punto detallaremos sus objetivos y contenidos.

x

x x

3.4.1 Objetivos y Contenidos de la Educación en Ingeniería de Software
La ACM y la IEEE-CS han propuesto en conjunto un documento denominado Software Engineering 2004 (SE2004), el cual provee recomendaciones para la educación de pre-grado en ingeniería de software. Este documento, el Software Engineering Education Knowledge (SEEK)[49], incluye una lista de tópicos que todos los graduados deben conocer, así como una serie de lineamientos para implementar currículos y un conjunto de cursos propuestos. Los conocimientos y habilidades que un ingeniero de software debería tener al graduarse pueden resumirse en el siguiente listado: 1. Demostrar dominio de un conjunto necesario de conocimientos y habilidades para comenzar su práctica profesional como ingeniero de software 2. Trabajar tanto individualmente como en equipo para desarrollar y generar software ejecutable 3. Reconciliar objetivos en conflicto, encontrar compromisos aceptables dentro de limitaciones de costo, tiempo, conocimiento, sistemas pre-existentes y organizaciones

40



Página 41

4. Diseñar soluciones apropiadas en uno o más dominios de aplicación, usando enfoques de ingeniería que integren aspectos éticos, sociales, legales y económicos 5. Demostrar entendimiento y poder aplicar teorías, modelos y técnicas actuales que provean una base para identificación de problemas y análisis, diseño de software, desarrollo, implementación y verificación 6. Negociar, trabajar efectivamente, asumir liderazgo cuando sea necesario, y comunicarse bien con los distintos interesados en un ambiente de desarrollo de software típico 7. Aprender nuevos modelos, técnicas y tecnologías a medida que ellas aparecen y apreciar la necesidad de un desarrollo profesional continuo Las áreas de contenido que un ingeniero de software debería recibir durante su formación son: x Conceptos Esenciales de Computación: Incluye los fundamentos que soportan el diseño y construcción de productos de software, como teoría de autómatas, programación, orientación a objetos, etc. También incluye conocimiento acerca de la transformación de diseños en implementaciones, las herramientas usadas durante el proceso y métodos formales de construcción de software Fundamentos Matemáticos y de Ingeniería: Estos fundamentos son los que permiten describir un software de manera precisa, modelar matemáticamente y facilitar el razonamiento acerca de los productos y sus interrelaciones. Un tema central es el diseño ingenieril como un proceso de toma de decisiones de naturaleza iterativa en donde la computación, la matemática y la ingeniería son aplicados para disponer los recursos eficientemente hacia el logro del objetivo buscado. Práctica profesional: se relaciona con el conocimiento, habilidades y actitudes que los ingenieros de software deben poseer para practicar su profesión de una manera responsable y ética. Se incluyen acá las áreas de comunicación interpersonal, dinámicas de trabajo en equipo y psicología, y responsabilidad profesional y social. Análisis y Modelamiento de Software: Consideradas como conceptos claves en cualquier disciplina de la ingeniería, el modelamiento y el análisis son primero aplicados en la especificación y validación de requerimientos. Estos representan las necesidades reales de usuarios, clientes y demás contrapartes interesadas y afectadas por el sistema. la construcción de requerimientos incluye un análisis de la factibilidad de un sistema deseado, análisis y ponderación de las necesidades de las distintas contrapartes, la creación de una descripción precisa de lo que un sistema debe y no debe hacer junto con las restricciones en su operación e implementación, y la validación de esta descripción por parte de las contrapartes. Diseño de Software: Este tópico trata de técnicas, estrategias, representaciones y patrones usados para determinar cómo implementar un componente o un sistema. Este diseño debe estar de acuerdo a requerimientos funcionales dentro de las restricciones impuestas por otros requerimientos tales como recursos, rendimiento, confiabilidad y seguridad. Esta área también incluye la especificación de interfaces internas entre componentes de software, diseño de arquitecturas, diseño de datos, diseño de interfaces de usuario, herramientas de diseño y la evaluación del diseño. Verificación y Validación de Software: Esta área implica el uso de técnicas dinámicas y estáticas de revisión de sistemas para asegurar que el programa 41

x

x

x

x

x