Experiencias en la formación de ingenieros informáticos. Desempeño de roles y trabajo en equipo

Experiencias en la formación de ingenieros informáticos. Desempeño de roles y trabajo en equipo Yucely López Trujillo, Margarita André Ampuero, Katerine Escalera Fariñas, Sandra Verona Marcos Resumen En el desempeño de los ingenieros informáticos resulta vital poseer los conocimientos y habilidades que permitan trabajar en equipo. La universidad es la responsable de formar a los profesionales informáticos que ingresan en la industria; por tanto, tiene el deber de impartir los conocimientos y acrecentar las habilidades necesarias que les posibiliten ser miembros efectivos de equipos de desarrollo. Para el logro de dicho objetivo es preciso perfeccionar continuamente el proceso de formación de roles y hábitos de trabajo en equipo. En esta presentación, se hace referencia específicamente a la experiencia en la asignatura Ingeniería de Software III de la carrera de Ingeniería Informática que se imparte en la Facultad de Informática del Instituto Superior Politécnico José Antonio Echevarría (CUJAE), La Habana, Cuba. En opinión de las autoras, la problemática identificada, su posible solución, así como las experiencias que se exponen son aplicables también a otros contextos. Palabras clave: formación, roles, ingeniería informática, proceso software en equipo. Abstract It is vital for computer engineers to have both knowledge and skills that enable the development of a team based work. The university is responsible for training IT professionals entering the industry; therefore, it has a duty to impart knowledge and promote the necessary abilities for them to become effective members of development teams. To achieve this objective it is necessary to continuously improve the process of formation of roles and habits of teamwork in the career of computer engineering. This paper refers specifically to the teaching experience of Software Engineering 3, a subject included in the curriculum of the Computer Engineering degree taught at the Computing College of the Polytechnic Institute Jose Antonio Echevarria (CUJAE), Havana Cuba. The authors consider that the identified problem, its possible solutions as well as the exposed experiences may also be applied to other contexts. Keywords: training, roles, software engineering, team software process. Introducción La industria de software tiene gran impacto en prácticamente todas las ramas del desarrollo de la sociedad. Sin embargo, a pesar de sus reconocidos resultados, aún resulta significativo el número de proyectos de software que no culminan con éxito (Chaos, 2013). Entre los principales problemas se identifican: insuficiente calidad de los productos finales, estimaciones inexactas de la duración de los proyectos, retrasos en la entrega de los productos, Autoras: Y. López Trujillo es Ingeniera Informática y Máster en Informática Aplicada. M. André Ampuero es Ingeniera de Sistemas Automatizados de Dirección, Máster en Informática Aplicada y Doctor en Ciencias Técnicas. K. Escalera Fariñas y S. Verona Marcos son Ingenieras Informáticas. Son todas docentes de la carrera de Ingeniería Informática de la Facultad de Ingeniería Informática. Instituto Superior Politécnico José Antonio Echeverría (CUJAE). Dirección de contacto: ylopez@ceis.cujae.edu.cu. Revista Argentina de Enseñanza de la Ingeniería / Año 4 / Nº 9 / Septiembre 2015 25

descontrol de los costos de desarrollo y mantenimiento de los productos, pobre definición de los requisitos y descontrol de los requerimientos de cambios (Chaos, op. cit.). Las principales dificultades apuntan a la inexistencia de procesos de desarrollo de software bien definidos que garanticen un buen uso de los talentos y recursos con que cuentan las organizaciones y que estos procesos mejoren de forma continua. No obstante, para lograr las mejoras deseadas resulta vital entrenar al personal de forma tal que sea capaz de desempeñar los roles que le correspondan de manera disciplinada, ya sea trabajando individualmente o en equipo. La universidad debe jugar un papel protagónico en la formación del ingeniero informático en consonancia con las exigencias que demanda la industria. Por su parte, la industria se siente presionada por mejorar su desempeño y elaborar software de calidad, sobre todo teniendo en cuenta que en la actualidad se experimenta un crecimiento del volumen y complejidad de los productos de software que, indudablemente, ha convertido el desarrollo de sistemas en una actividad de equipo. El personal es un factor poco formalizado en los modelos de procesos y en las metodologías de desarrollo de software, las cuales se centran más en aspectos técnicos que en los aspectos humanos (Wastell, 1999) (Acuña, 2002) (Acuña, 2006). Asimismo, existen modelos líderes en el tópico de la mejora de procesos que sí se centran en los recursos humanos: el Proceso de Software Personal (PSP) y el Proceso de Software en Equipo (TSP) (Humphrey,1994, 1995 y 2000; Hayes, 1997; Couprie, 2000). Ambos procesos fueron desarrollados en el Software Engineering Institute (SEI) de la Universidad de Carnegie Mellon por Watts S. Humphrey, científico e investigador del SEI. El objetivo de PSP es proveer a los individuos de mecanismos de trabajo para convertirse en miembros efectivos de equipos, partiendo de que la base para alcanzar una disciplina a nivel de equipo es la disciplina personal. TSP, en tanto, pretende formar y desarrollar equipos exitosos. En cuanto a los cursos que se imparten en la carrera de Ingeniería Informática y de manera general en carreras afines, se puede afirmar que se centran en cuestiones técnicas y en el desempeño individual del estudiante (Andre, 2005 y 2007). La disciplina personal y de trabajo en equipo, la formación de roles, la comunicación y el liderazgo son temas que se abordan, en muchas ocasiones, de manera teórica o no logran implementarse a plenitud en la ejecución de proyectos reales (André, 2007; López, 2011). Las insuficiencias en la formación académica entran en contradicción con las exigencias que impone la industria en función de las dificultades que enfrenta. Esta situación indica que es preciso trabajar desde el proceso de formación con el propósito de eliminar la brecha existente entre la academia y la industria. En Cuba, la carrera de Ingeniería Informática ha transitado por diferentes planes de estudio, todos estructurados en cinco años académicos (diez semestres). Cada uno de ellos ha exigido que la totalidad de los estudiantes, a partir del tercer año, se incorporen a la ejecución de proyectos reales, los cuales en la mayoría de los casos se llevan a cabo en empresas o centros de investigación. Como parte del proceso de elaboración del plan de estudio vigente (denominado Plan D ) y en respuesta a los retos que enfrenta el proceso de formación de los profesionales de software, se elaboró una estrategia para la formación de los roles y las competencias que precisa la industria en cuanto a trabajo disciplinado y en equipo. Esta estrategias incorpora, entre otros aspectos, la introducción de las prácticas de PSP y TSP de forma incremental (Andre, 2007; López, 2011). Precisamente, una de las asignaturas surgidas con el Plan D, que tributan directamente a la formación de roles y al trabajo en equipo, es Ingeniería de Software III (IS3), asignatura del currículo propio que se imparte en el segundo semestre del cuarto año de la carrera. Desde la puesta en marcha del Plan D han transcurrido ocho cursos académicos, y en la ejecución de la asignatura IS3 se tiene experiencia en cinco cursos. Así, el objetivo de este material es exponer las experiencias en la impartición de la asignatura IS3, que las autoras del trabajo consideramos válidas 26 Revista Argentina de Enseñanza de la Ingeniería / Año 4 / Nº 9 / Septiembre 2015

para ser aplicadas en otros contextos con problemáticas similares. El trabajo se ha estructurado de la siguiente forma: en un primer acápite se hace referencia al proceso de formación de roles que se aplica en el plan de estudios vigente, en los acápites siguientes se describen las experiencias en la impartición de la asignatura IS3. 1. Proceso de formación de roles. Antecedentes El Plan de estudios vigente, Plan D, que se aplica en la Facultad de Informática de la CUJAE, tuvo sus antecedentes en los análisis críticos realizados a su predecesor, el denominado Plan C. Andre (2007) estudia el proceso de formación del ingeniero informático con el Plan C y concluye que los temas de planificación, asignación de recursos, estimación de costos, tamaños y tiempos, definición y trabajo con estándares, calidad, entre otros, no eran abordados de forma profunda. Andre (op. cit.) advierte que el Plan C estaba concebido de forma tal que en los primeros años se impartía un ciclo de programación en el que apenas se introducían algunos aspectos relacionados con la Ingeniería de Software y solo se ejercitaba con fuerza el rol de programador. Es a partir del segundo semestre de 3er año que se comenzaba a enseñar las prácticas de la ingeniería de software, por lo que resultaba muy difícil tratar de cambiar la visión y los hábitos adquiridos por los estudiantes en los años previos. Con el objetivo de mejorar el proceso de formación concebido en el Plan C se propuso una estrategia, incluida en el Plan D, para lograr que los estudiantes adquirieran una disciplina personal y aprendiesen a desempeñar los roles a lo largo de toda la carrera de forma incremental, consciente y disciplinada con vistas a ser miembros efectivos de un equipo de proyecto. En la estrategia se identifican doce roles a formar durante la carrera (Andre, 2007): analista (negocio y sistema), diseñador, programador, arquitecto, planificador, especialista en calidad, especialista en seguridad, jefe de proyecto, implantador, probador, especialista en soporte y gestor de configuración y cambios. De ellos son secundarios: el especialista en seguridad, el implantador y el especialista en soporte, mientras que los restantes son primarios en al menos un año académico. El proceso de formación para la totalidad de los roles es iterativo y gradual; en el último año de la carrera se alcanza el 100% de la formación requerida en cada uno de los casos. Es válido señalar que en Andre (2007) se encuentra un análisis más detallado de cómo aporta cada asignatura a la formación de los roles en cada año académico, las tareas definidas para cada rol y la forma de evaluación. 2. Aspectos generales de la organización de la asignatura IS3 A partir del curso académico 2007-2008 se comenzó a aplicar el Plan D, en la Facultad de Ingeniería Informática del Instituto Superior Politécnico José Antonio Echeverría. El plan de estudio D tiene una organización docente compuesta por un currículo base, un currículo propio y un conjunto de asignaturas optativas. Dentro de las asignaturas de la disciplina Ingeniería y Gestión de Software que tributan directamente a la formación de roles y al trabajo en equipo se encuentra Ingeniería de Software III (IS3), materia del currículo propio que se imparte en el segundo semestre del cuarto año de la carrera. Los objetivos instructivos declarados en el Plan D para dicha asignatura son los siguientes: -Ejercitar habilidades en el desempeño de roles desarrollando un proyecto informático, incluyendo el rol de Jefe de proyecto. -Ejercitar habilidades de trabajo en equipo. -Evaluar las competencias de los estudiantes en la ejecución de determinados roles dentro del equipo. En el curso 2010-2011 se imparte la asignatura IS3 por primera vez a los estudiantes iniciadores del Plan D. En estos momentos se cuenta con una experiencia en su ejecución de cinco cursos académicos. En la preparación de la asignatura y en el estudio individual orientado a los estudiantes se consultó bibliografía básica en Revista Argentina de Enseñanza de la Ingeniería / Año 4 / Nº 9 / Septiembre 2015 27

el tema de la gestión de proyectos, tal el caso del Cuerpo de conocimientos para la Gestión de Proyectos, conocido por sus siglas en inglés como PMBoK (PMI, 2013); y en lo que respecta a la mejora de procesos de desarrollo de software, el estudio del Modelo de Madurez, conocido como CMMi (CHRISSIS, 2009). La asignatura dispone de un fondo de tiempo de 42 hs. En la secuencia de actividades se encuentran definidas 6 conferencias relativas a los temas de roles, planificación, gestión de recursos humanos y comunicaciones; y tres conferencias sobre el método de mejora de proceso PSP. El resto del tiempo se distribuye en actividades prácticas, fundamentalmente cortes evaluativos del proyecto de curso, teniendo en cuenta que el desarrollo en equipo de un proyecto informático y el desempeño de diferentes roles, es el objetivo esencial de la asignatura. La ejercitación y la evaluación de las habilidades de trabajo en equipo en la ejecución de un proyecto informático constituyen un gran reto a la hora de organizar la asignatura. Para el logro de estos objetivos se conforman equipos de entre 4 y 6 miembros, y a cada equipo se le asigna un proyecto, en la medida de lo posible, real. Se utilizan los proyectos reales que se desarrollan en la facultad en los que participan profesores y estudiantes desde el tercer año de la carrera. A medida que han transcurrido los cursos académicos se ha tornado más difícil la conformación de estos equipos, pues, no todos los estudiantes están vinculados a proyectos reales. El reto mayor del colectivo de profesores de la asignatura está en lograr una adecuada composición de los equipos y que el tema que desplieguen sea para un cliente o usuario real. En este sentido, una solución ha sido designar como jefe de proyecto al estudiante que está vinculado realmente a un proyecto e incorporar al equipo a otros miembros con tareas concretas que contribuyan al desarrollo del proyecto y les permitan ejercitar los roles. En un inicio, los profesores valoraban esta situación como un problema. Hoy se analiza como una oportunidad tener que insertar estudiantes que no pertenecen en realidad a un proyecto. Lo verdaderamente importante es asignar una tarea al equipo y definir una meta u objetivo común. Los estudiantes deben realizar la planificación de las tareas y trabajar como equipo en función de los entregables de la asignatura, de la nota de todos y de los resultados que deben ofrecer al cliente o usuario real. En estos casos, en la planificación se reflejan actividades de capacitación dirigidas a los estudiantes que se insertan en estos proyectos. El colectivo de la asignatura apuesta fuertemente en todo momento por el desarrollo de proyectos reales que respondan a demandas de clientes reales, tratando de insertar la mayor cantidad de estudiantes. Se concibe como último recurso asignarles proyectos que son casos de estudio. 3. Roles a desempeñar en los equipos de proyectos. Proceso de asignación. Para la asignación de roles se aplican diferentes instrumentos que ayudan a: evaluar competencias requeridas en el desempeño de los diferentes roles que participan en el desarrollo del proyecto. identificar características de la personalidad con vistas a valorar cómo contribuyen al desempeño de los roles. Para evaluar las habilidades de comunicación oral y escrita y las de trabajo en equipo, se utiliza el Modelo de evaluación de competencia comunicación interpersonal y el Test de trabajo en equipo desarrollados por la doctora María J. Becerra. (Becerra, 2003). Para analizar preferencias y características de la personalidad que apoyan el trabajo en equipo y el desempeño de roles, se utilizan los instrumentos siguientes: 1. Roles de equipos: Test de Belbin (Belbin, 2004; Basri, 2008). 2. Rasgos de la personalidad que expresan las preferencias de las personas en cómo hacer las cosas, cómo captar la información y cómo tomar decisiones: Test de Myers-Briggs (Briggs, 2004; Capretz, 2003). Los roles que se ejercitan son: jefe de proyecto, arquitecto, analista, programa- 28 Revista Argentina de Enseñanza de la Ingeniería / Año 4 / Nº 9 / Septiembre 2015

dor, planificador, gestor de configuración, y especialista de calidad. Es de señalar que la asignatura no aporta conocimientos nuevos para la formación de los roles arquitecto, analista y programador, solo evalúa el desempeño de los estudiantes. Para los cuatro restantes roles sí se aportan conocimientos nuevos y se logra su ejercitación en la práctica. A partir del curso 2011-2012 se incorpora la ejercitación del rol probador. Se considera que los roles de jefe de proyecto, planificador, gestor de configuración y especialista de calidad son los que más influyen en el trabajo por la calidad en un proceso de desarrollo de software. Sin embargo, son los que tradicionalmente solo se forman de manera teórica. En el caso del rol de Jefe de proyecto, en esta asignatura es la primera vez que los estudiantes tienen la oportunidad de desempeñarlo y, en sentido general, de experimentar el trabajo en equipo dirigidos y controlados por un jefe y con responsabilidades bien delimitadas. Teniendo en cuenta la novedad que representa la formación en la práctica de los roles de jefe de proyecto, planificador, gestor de configuración y especialista de calidad, a continuación se describen las responsabilidades asignadas a los estudiantes en el marco de esta experiencia docente. Responsabilidades del rol jefe de proyecto: 1. conformar el equipo, lo que implica asignar los roles y responsabilidades. 2. dar seguimiento al plan de proyecto con vistas a que se cumplan todas las tareas y se obtengan los entregables en las fechas programadas. 3. garantizar que se realice de forma objetiva la evaluación y autoevaluación del desempeño del rol y del aporte al equipo de todos los miembros. 4. garantizar la adecuada comunicación y control del trabajo en el equipo. Responsabilidades del rol planificador: 1. estudiar el área de proceso de planificación de proyecto de CMMi. 2. estudiar en el libro PMBoK los procesos de dirección de proyecto y en especial, estudiar el grupo de procesos de planificación. 3. asimilar la herramienta Microsoft Project. 4. ejecutar el plan de proyecto utilizando la herramienta Project, incluyendo todas las tareas que indican tanto CMMi como PMBoK, debe contener un proyecto. 5. entregar el plan de proyecto utilizando la herramienta Microsoft Project. Responsabilidades del rol gestor de configuración: 1. estudiar el área de proceso de gestión de configuración de CMMi. 2. definir la herramienta a utilizar en el proyecto para garantizar la gestión de configuración, velando porque cumpla con lo establecido en las prácticas específicas para el área de gestión de configuración de CMMi. 3. capacitar al equipo para el uso de la herramienta de gestión de configuración. Responsabilidades del rol epecialista de calidad: 1. proponer listas de chequeo para la revisión de los principales artefactos de cada rol. 2. ejecutar la revisión, registrar y dar seguimiento a los defectos. 3. realizar análisis de la distribución del tiempo de manera individual y colectiva, y de las principales dificultades y lecciones aprendidas tomando en cuenta el seguimiento dado al registro de tiempo de todos los miembros del equipo a lo largo del desarrollo del proyecto. 4. responsable de la calidad del entregable final y del producto desarrollado. 4. Evaluación de la asignatura Las autoras de este trabajo consideran esencial prestar atención a la evaluación como categoría didáctica, teniendo en cuenta que una correcta evaluación permite valorar el éxito o fracaso del proceso de enseñanza-aprendizaje y redefinir elementos en función de las finalidades de formación (Rizo, 2004; González, 2001). Así, en el curso 2014-2015 se perfeccionó el sistema y la asignatura se evalúa de la siguiente forma. Revista Argentina de Enseñanza de la Ingeniería / Año 4 / Nº 9 / Septiembre 2015 29

Existen evaluaciones intermedias acerca del desarrollo del proyecto, denominadas cortes de proyecto. A lo largo del semestre hay 5 cortes, en los que el miembro del equipo que desempeñe el rol a evaluar es el máximo responsable de la entrega en tiempo de la documentación, de la calidad del entregable y de la exposición en el aula de los principales resultados. Adicionalmente, se realiza un examen teórico sobre el contenido del método de mejora de proceso PSP. El objetivo del examen es evaluar los conocimientos teóricos acerca de las principales métricas propuestas en el método y su interpretación para la mejora del proceso de desarrollo. Al finalizar el semestre se realiza la evaluación integral del proyecto de curso. Para este fin, se constituye un tribunal de profesores de la disciplina. Lo integran tres docentes, siempre participa el docente que ha seguido el proyecto a lo largo del semestre y ha revisado los cortes parciales. Esta evaluación es la de mayor consideración y es aquí donde se incorporaron algunas modificaciones en el presente curso. Para la evaluación final del proyecto los estudiantes deben entregar: documento Word que contiene el informe final con los requisitos que se explican en una guía definida a tal efecto, máximo de 40 páginas. software con la implementación de, al menos, 2 casos de uso definidos en el informe. fichero que genera la herramienta de gestión de proyectos seleccionada, con la planificación del proyecto. estándar de codificación utilizado en el proyecto. presentación elaborada para la exposición oral. En los cuatro cursos anteriores en que se impartió la asignatura, cada tribunal evaluaba siguiendo los criterios generales que entendía por lógica y la evaluación podía no ser precisa o justa, dependía de los criterios de cada tribunal evaluador. En el presente curso la evaluación se realizó siguiendo una lista de chequeo, con el objetivo de homogenizar los criterios de todos los tribunales. Así, se logró que no dejaran de evaluarse aspectos y que todos los tribunales actuaran con el mismo rigor. La evaluación final tuvo en cuenta la importancia dada a los siguientes elementos: aspectos generales del documento, software con la implementación de al menos 2 casos de uso, presentación oral del proyecto, evaluación del desempeño de cada rol expresada en la calidad de los artefactos presentados. La lista de chequeo general constituida para tal efecto es la suma de varias asociadas a los diferentes objetos de evaluación. Cada lista de chequeo a su vez se desglosa en diferentes elementos objeto de evaluación y para cada uno se realizan preguntas de chequeo que deben ser evaluadas cualitativamente como Muy Bien (MB), Bien (B), Regular (R) o Mal (M). A continuación, las listas de chequeo definidas: Lista de chequeo para evaluar aspectos generales del documento. Elementos objeto de evaluación contenidos en la lista: entrega en tiempo del documento, sobre el título, sobre el resumen, sobre la introducción, sobre la redacción en general, sobre las conclusiones, sobre las recomendaciones, sobre las referencias bibliográficas. Lista de chequeo para evaluar desempeño del rol jefe de proyecto. Elementos objeto de evaluación contenidos en la lista: sobre el trabajo en equipo, sobre el análisis de riesgos. Lista de chequeo para evaluar desempeño del rol planificador. Elementos objeto de evaluación contenidos en la lista: Sobre el Plan del proyecto. Lista de chequeo para evaluar desempeño del rol analista. Elementos objeto de evaluación contenidos en la lista: sobre el modelo del negocio, sobre el Diagrama de CU del Negocio (representación gráfica), sobre el Modelo de Objetos, sobre el Modelo de Dominio, sobre Reglas del Negocio, sobre Modelo de casos de uso del Sistema (Rep. Gráfica), sobre los Casos de Prueba. Lista de chequeo para evaluar desempeño del rol arquitecto. Elementos objeto de evaluación contenidos en la lista: sobre la arquitectura candidata, sobre el modelo de despliegue, sobre el modelo lógico, sobre el modelo físico, sobre el estándar de 30 Revista Argentina de Enseñanza de la Ingeniería / Año 4 / Nº 9 / Septiembre 2015

codificación. Lista de chequeo para evaluar desempeño del rol Gestor de la Configuración. Elementos objeto de evaluación contenidos en la lista: sobre gestión de la configuración. Lista de chequeo para evaluar desempeño del rol Especialista de la Calidad. Elementos objeto de evaluación contenidos en la lista: sobre la definición de las listas de chequeo, sobre análisis de métricas de tiempo, sobre registro de defectos. Lista de chequeo para evaluar desempeño del rol Probador. Elementos objeto de evaluación contenidos en la lista: sobre el resultado de las pruebas. Lista de chequeo para evaluar el Sofware. Elementos objeto de evaluación contenidos en la lista: sobre el software desarrollado, sobre principios generales para el diseño de la interfaz de usuario. Lista de chequeo para evaluar Exposición Oral del equipo. Elementos objeto de evaluación contenidos en la lista: sobre la presentación, sobre la exposición oral. En la figura 1 se muestra un ejemplo de la lista de chequeo empleada para revisar el artefacto Plan de Proyecto. Coincidentemente, la evaluación de este artefacto permite evaluar el desempeño del rol planificador pues no hay otro artefacto asociado. La lista de chequeo se encuentra definida en Excel. Figura 1. Lista de chequeo para evaluar el artefacto Plan de Proyecto. La nota final de la asignatura tiene en cuenta la nota recibida en el examen teórico, la nota dada en los cortes parciales del proyecto y la nota final dada al proyecto. 5 Conclusiones Las conclusiones acerca de las experiencias en la ejecución de la asignatura IS3 se centran fundamentalmente en los resultados obtenidos a lo largo de estos cinco cursos académicos. En sentido general, se evidencia que: el equipo asigna los roles en función de las competencias reales de cada miembro. se realizan actividades de capacitación a fin de preparar a los miembros del equipo en las temáticas necesarias para el desarrollo de cada proyecto en particular. Sobre todo, capacitar a aquellos que no pertenecen al proyecto realmente. el rigor, la exigencia y el control sistemático de las tareas asignadas propician elevar el nivel de responsabilidad y laboriosidad por parte de los estudiantes, porque del correcto desempeño de los roles depende la nota del equipo. se logra que sientan el espíritu del trabajo en equipo, todos bregando por un objetivo en común. en el desempeño de los roles que forman las asignaturas precedentes (analista, arquitecto, programador, probador), se evidencia dominio de los aspectos técnicos. Por otra parte, es la primera vez que los estudiantes tienen la oportunidad de Revista Argentina de Enseñanza de la Ingeniería / Año 4 / Nº 9 / Septiembre 2015 31

desempeñar los roles de manera consciente y aportar al desarrollo de un proyecto en equipo. el uso de listas de chequeo permite que todos los tribunales involucrados en el proceso de evaluación evalúen los mismos elementos. con las listas de chequeo se logra en alguna medida que los tribunales evalúen con el mismo rigor. Aún falta trabajar en la cuestión del otorgamiento de peso a cada elemento dentro de la lista para lograr que la nota final que se emita responda a los mismos criterios. 6. Trabajo futuro El trabajo futuro se encuentra encaminado al perfeccionamiento continuo del proceso de enseñanza y aprendizaje. En este sentido, estará dirigido a: 1- perfeccionar las orientaciones del proyecto final, específicamente en el tema del seguimiento de defectos, y cómo mostrar las evidencias producto del seguimiento al plan de proyecto. 2- realizar encuestas a evaluadores expertos, solicitando que emitan su criterio acerca de qué peso se debe otorgar a cada elemento dentro de la lista de chequeo de Evaluación. 3- obtener criterio final a partir de las encuestas sobre el peso a otorgar a cada elemento de la lista de chequeo, buscando obtener una evaluación parcial de cada elemento. 4- proponer mecanismos concretos de evaluación del desempeño de cada rol en cada una de las asignaturas del plan de estudios. Para lograr esta acción es preciso tener sesiones de trabajo con los colectivos de asignaturas involucrados donde se definan las listas de chequeo específicas, que sean utilizadas por todos los miembros del colectivo y se logre una evaluación uniforme. Referencias ACUÑA, S. (2002) Capabilities-Oriented Integral Software Process Model. Ph.D. Thesis, Universidad Politécnica de Madrid. ACUÑA, S. y JURISTO, N. y MORENO, A. M. (2006), Emphasizing Human Capabilities in Software Development. IEEE Software, Vol. 23 N0 2. pp. 94-101. ANDRE, M. (2007). Estrategia para la formación de roles en la carrera de Ingeniería Informática basado en la gestión por competencias, Parte 1, en Reporte de Investigaciones del Centro de Estudio de Ingeniería y Sistemas, Instituto Superior Politécnico José Antonio Echevarría: La Habana. ANDRE, M. (2005). El proceso de software en equipo: de la disciplina personal a la disciplina organizacional. XI Convención Informática 2005. ANDRE, M. y MARTINEZ, J. (2007). Transformaciones en el plan de Estudio de Ingeniería Informática en busca de una mayor calidad en el proceso de formación. XII Convención Internacional Informática. La Habana. 2007. BASRI, H. (2008). An Evaluation on Belbin s Team Roles Theory. World Applied Sciences Journal, 4(3): 460-469. BECERRA, Ma. J. (2003). Una Estrategia Pedagógica para el desarrollo de la Competencia para la Comunicación Interpersonal en el desempeño profesional de los ingenieros, Tesis de doctorado, C. Habana, CUJAE. BELBIN, M. (2004). Management Teams: Why they Succeed or Fail. 2nd ed., Butterworth Heinemann. BRIGGS, K y MYERS, I. (2004). Introducción al Type (MBTI). Una guía para entender los resultados de su evaluación Myers-Briggs Type Indicador. Sexta ed., Consulting Psychologists Press, California. CAPRETZ, L. F. (2003). Personality types in software engineering. International Journal of Human Computer Studies, 58(2): 207 214, 2003. CHAOS Manifesto (2013). The Standish Group. Fecha de consulta: abril 2015. Disponible en: URL: http://www.standishgroup.com. COUPRIE, D. (2000). The Personal Software Process. A Good Start for the New Software Engineer. University of Calgary. 32 Revista Argentina de Enseñanza de la Ingeniería / Año 4 / Nº 9 / Septiembre 2015

GONZALEZ, M. (2001) La evaluación del Aprendizaje: tendencias y reflexión crítica. Rev Cubana Educ Med Super; 15(1):85-96 HAYES, W. y OVER, J. W. (1997) The Personal Software Process: An Empirical Study of the Impact of PSP on Individual Engineers. Technical Report CMU/SEI- 97-TR-001 ESC-TR-97-001. CHRISSIS, M. B. (2009) CMMi. Guía para la integración de procesos y la mejora de productos. Pearson Educación. Segunda edición. 2009. HUMPHREY, W.S. (2000). The Personal Software Process. Technical Report CMU/SEI-2000-TR-022. November 2000. HUMPHREY, W.S. (1994) The Personal Process in Software Engineering. III International Conference on the Software Process IEEE. HUMPHREY, W.S (1995). A discipline for software engineering. SEI Series in Software Engineering. Addison-Wesley 2000. LOPEZ, Y., ANDRE, M. e INFANTE, A. L. (2011). Formación de roles y buenas prácticas en el trabajo por la calidad de un ingeniero informático Ingeniare. Revista Chilena de Ingeniería, vol. 19 Nº 3, pp. 382-395. PMI,(2013). Project Management Institute, A Guide to the Project Management Body of Knowledge (PMBOK Guide), 5th edition. Pennsylvania: Newtown Square, PMI Publications. RIZO, H. (2004). Evaluación del aprendizaje: Una propuesta de evaluación basada en productos académicos. Revista Electrónica Iberoamericana sobre Calidad, Eficacia y Cambio en Educación, 2(2). Disponible en: http://www.ice.deusto.es/ rinace/reice/vol2n2/rizo.pdf. Fecha de consulta (abril 2015). WASTELL, D. (1999). The Human Dimension of the Software Process, in Software Process: Principles, Methodology and Technology. Springer-Verlag, pp. 165-199. Revista Argentina de Enseñanza de la Ingeniería / Año 4 / Nº 9 / Septiembre 2015 33