Metodología para la Administración de Proyectos de Desarrollo de Sistemas de Información Lic. Leticia Almaguer Flores, MAI Departamento de Sistemas de Información Edificio DACS 135 Introducción El estudiante del área de sistemas de información (ISC, ISI y LSCA) debe desarrollar la habilidad de administrar proyectos de desarrollo de sistemas porque es una de las actividades más importantes en su área. [Schwalbe] Como una contribución a la estrategia 1 de nuestra misión: Reingeniería del proceso enseñanzaaprendizaje, presento esta metodología para la administración de proyectos de desarrollo de sistemas de información aplicada en algunos de los Proyectos de Apoyo al Desarrollo Sostenible bajo mi coordinación. Esta metodología está relacionada con el Desarrollo Curricular para coadyuvar en la adquisión de conocimientos y en el desarrollo de habilidades, valores y actitudes deseables en el administrador de proyectos del área de sistemas de información. Objetivo de la Metodología La metodología para la administración de proyectos de desarrollo de sistemas de información bajo el esquema PADS (CADS) tiene como objetivo: Dirigir al equipo de trabajo durante el proceso de desarrollo de sistemas de manera sistemática para cumplir con las expectativas del cliente (empresa) y, al mismo tiempo, fortalecer los conocimientos, habilidades, actitudes y valores necesarios en los profesionistas del área. A diferencia de los proyectos de desarrollo de sistemas de información en un ambiente profesional, los proyectos PADS de desarrollo deben ofrecer resultados aceptables en un período de tiempo limitado y sin poder realizar la selección del equipo de trabajo, pues son los alumnos quienes inscriben una materia cuyo objetivo es la vinculación de la academia con la empresa. Estas limitantes presentan grandes retos para el administrador del proyecto (profesor) quien debe desarrollar un cuidadoso plan, mantener una coordinación rítmica y cuidar la motivación de su equipo de trabajo para lograr los resultados esperados. La metodología de administración de proyectos fue desarrollada tomando como base el ciclo de vida de desarrollo de sistemas [Kendall] e implantada en tres PADS de análisis, diseño y desarrollo de sistemas de información: Alestra ITESM 1 (Verano 1997); Ciudad de los Niños ITESM 2 (Enero mayo 1999); DIEX 3 (Enero mayo 2000). 1 El apéndice A muestra los participantes del proyecto Alestra 2 El apéndice B muestra los participantes del proyecto Ciudad de los Niños 3 El apéndice C muestra los participantes del proyecto: DIEX
2
Antecedentes Profesionalmente he participado en algunos proyectos de desarrollo de sistemas de información para empresas, fungiendo como coordinadora general en algunos de ellos y obteniendo resultados diversos. Inicialmente apliqué la metodología típica de análisis-diseño-desarrollo-implantación para el desarrollo de sistemas [Wilson]. Sin embargo, esta herramienta no fue suficiente para coordinar un proyecto con tiempos y costos establecidos. Los problemas típicos presentados fueron: Falta de capacitación de los participantes Errores en la estimación de costos y tiempos Falta de descripción detallada y secuencial de actividades Ignorancia de los imponderables o problemas no previstos. Cuando coordiné el primer proyecto con un grupo de estudiantes, los problemas se incrementaron: Tiempos limitados a un semestre académico La participación de los estudiantes estaba motivada por una nota final, que en ocasiones no era suficiente para cumplir con el proyecto. Estos problemas me llevaron a comprender la necesidad de ajustar las metodologías aplicadas en el ámbito profesional a la realidad de la academia. Metodología La metodología consta de 14 etapas cuyas actividades pueden variar segun la naturaleza del proyecto. 1. Entrevista inicial Como primer paso, se debe realizar una entrevista a los directivos que apoyan el desarrollo del proyecto y a los responsables directos en la empresa. Esta entrevista inicial la realiza el coordinador del proyecto (profesor) y tiene como objetivos: Definir el alcance del proyecto Establecer las expectativas de la empresa Conocer los recursos tecnológicos con los que se cuenta Es recomendable que la primera entrevista se realice en las instalaciones del cliente para conocer a los empleados involucrados en el proyecto y las instalaciones. Cuando no se realiza esta entrevista se corre el riesgo de no comprometer a la dirección para apoyar el cumplimiento del proyecto dentro de la empresa. 2. Elaboración del plan de trabajo (Grafica de Gantt). Con la información obtenida, el coordinador desarrolla el plan definiendo primero la cantidad de grupos de trabajo y luego las actividades que realizarán cada uno de ellos. Los grupos de trabajo se deben establecer de acuerdo al proyecto y su alcance. Por lo general, se divide el proyecto en módulos manejables independientemente para simplificarlo. Después de definir los grupos y sus actividades, es importante que se establezca claramente las habilidades necesarias en los participantes de acuerdo a las responsabilidades de cada grupo. Si no se hiciera esta consideración, se corre el riesgo de atrasar la terminación del proyecto por falta de capacitación de los participantes. 3
Como herramienta para el desarrollo del plan de trabajo se recomienda el uso de MsProject 4 pues permite la definición de las actividades, duración y requisitos presentando una gráfica Gantt clara y completa. 3. Presentación del proyecto y del plan a los integrantes del proyecto. La primera reunión con los integrantes (alumnos) del equipo de desarrollo para presentarles el objetivo del proyecto, su alcance y sus limitaciones es el momento donde se crean las expectativas en los alumnos, por esto es importante que el coordinador presente el proyecto como un experiencia retadora y de gran valor para su formación profesional. Si se planteara como algo que se tiene que hacer para lograr aprobar el curso, el alumno se sentirá poco motivado, la diferencia en la percepción de esta presentación es determinante en el desarrollo del proyecto. 4. Descripción de habilidades de los miembros del equipo. Cuando los integrantes del equipo conocen el proyecto, cada uno de ellos debe describir de manera realista sus habilidades personales útiles para el desarrollo del sistema. En este punto, es importante aclarar que el profesor no escoge a los alumnos, por lo que generalmente los participantes del proyecto no cumplen con las habilidades requeridas para la realización del mismo. El coordinador, al conocer las habilidades requeridas para el desarrollo del proyecto y las habilidades que presentan los integrantes debe determinar las diferencias para decidir si es necesario realizar una capacitación específica para su grupo de trabajo. En ocasiones la capacitación es por cuenta de la empresa, como sucedió con Alestra al comprometerse a capacitar formalmente a todo el equipo de desarrollo en el manejo de la herramienta Lotus Notes. Pero no siempre se puede contar con ello, y es responsabilidad del coordinador proporcionar la capacitación necesaria a su equipo. En el caso del proyecto desarrollado para Cd. De los Niños, un miembro experimentado del equipo ofreció la capacitación a sus compañeros. Si no se proporciona capacitación a los alumnos se incrementaría el riesgo del fracaso del proyecto, pues demandaría más esfuerzo por parte de los participantes y no se terminaría a tiempo. 5. Elección del líder general del proyecto. De acuerdo al perfil observado de los alumnos participantes, el coordinador elige un líder de proyecto que asume las siguientes responsabilidades: Respresentar al equipo de trabajo ante los usuarios. Coordinar e integrar las actividades del proyecto Mantener la comunicación entre los miembros del equipo El líder de proyecto no sustituye las labores del coordinador sino que las imita. Esta persona tendrá la oportunidad de desarrollar sus habilidades de liderazgo, administración y coordinación de su equipo de trabajo siendo apoyado por la experiencia del coordinador (profesor) del proyecto. En este momento el coordinador cambia su rol para convertirse en un observador del proceso interviniendo solo para guiar al líder. 4 MsProject es marca registrada de Microsoft Company 4
Esta etapa no existe en ninguna metodología, pues éstas se definen bajo el principio que hay un solo coordinador de proyecto. Para este caso, si el profesor fuese el coordinador general entonces no habría oportunidad para los estudiantes, en su proceso de formación, de experimentar el rol de administrador de proyecto. 6. Formación de los equipos de trabajo segun sus habilidades. En seguida se definen los equipos de trabajo y se asignan los módulos del proyecto. El equipo se debe formar de acuerdo a las habilidades propias de cada integrante en función del objetivo de su módulo o parte del proyecto. La subdivisión modular del proyecto aclara las funciones de los participantes desde un principio eliminando sustancialmente la incertidumbre y elevando su motivación, pues saben que van a participar en el proyecto de acuerdo a sus habilidades específicas. 7. Elección de los líderes de cada equipo de trabajo. Asignados los equipos a cada módulo del proyecto, se nombra al líder del equipo. El líder es responsable del cumplimiento de las tareas asignadas al equipo y de la comunicación con el(los) usuario(s) y con el líder de proyecto. Estos niveles de liderazgo simulan la situación real en las empresas que desarrollan sistemas de información donde generalmente se labora con equipos de trabajo numerosos. 5 8-10. Análisis, Diseño/Prototipo 6 y Desarrollo 7 de Sistemas Una vez que se han establecido todos los detalles referentes a la organización y coordinación del proyecto, se procede a realizar el proyecto de acuerdo al método de ciclo de vida usada para el desarrollo de sistemas de información y representadas en esta metodología en las etapas 8 a 13. Generalmente, los alumnos ya conocen esta metodología tanto como sus herramientas pues forma parte del plan de estudios de las carreras del área de sistemas (ISC, ISI y LSCA). Solo deben definir las herramientas que se usarán como estándar en el proyecto. 11. Elaboración de los documentos y respaldos del sistema. La documentación es un aspecto que no se debe descuidar durante el desarrollo del proyecto. Fomentar la elaboración de una buena documentación en el equipo de trabajo y resaltar su utilidad cuando se tiene completa, es una labor propia del coordinador del proyecto. 12. Presentación a usuarios. Otro aspecto relevante durante el proceso es la presentación formal del proyecto a los usuarios. Se recomienda que participen en la presentación todas las personas involucradas en el proyecto por parte de la empresa, así como profesores del área. 5 Los proyectos PADS referidos en este escrito han tenido entre 8 y 12 alumnos, agrupados en tres o cuatro equipos de trabajo 6 Se describe el ciclo en el Apéndice D 7 Se describe el ciclo en el Apéndice E 5
13. Instalación y entrega de la documentación. Después de la presentación del proyecto, y de acuerdo con las negociaciones previas con la empresa, se debe hacer la instalación del software y la entrega de la documentación y discos al responsable del proyecto en la empresa. En este momento, el responsable del proyecto en la empresa debe firmar una carta de aceptación de producto terminado donde se deslinde de cualquier responsabilidad al equipo de desarrollo, al profesor y a la Institución, por problemas posteriores a la instalación. 14. Sesión de cierre del proyecto. Cuando se ha terminado el proyecto, se recomienda una última reunión de retroalimentación con los alumnos donde tengan la oportunidad de expresar sus opiniones como participantes del proyecto. La riqueza que ofrece al coordinador este último momento de reflexión es de gran utilidad en el desarrollo de sus siguientes proyectos. Venciendo obstáculos Es obvio que durante el desarrollo de los proyectos se presentan problemas técnicos y humanos que el administrador de proyectos debe solucionar. Cuando se presentan problemas técnicos la lluvia de ideas entre los integrantes del equipo de trabajo es una herramienta muy útil y práctica. No solo sirve para resolver el problema mismo, sino también para fomentar en los participantes la confianza en sí mismos, en sus conocimientos y en sus habilidades. Esto presenta resultados muy favorables en comparación a que sea el profesor quien dé las soluciones. Cuando se presentan problemas humanos se debe analizar la participación del líder y su influencia en el resto del equipo, generalmente aquí se encuentra la causa del problema y con algunos detalles de orientación y motivación se puede sacar adelante el proyecto. Aunque el coordinador (profesor) del proyecto es un observador, nunca debe estar alejado del equipo de trabajo, esto disminuye los retrasos del proyecto por cualquier problema que se presente pues el coordinador estará ahí para intervenir de manera rápida y oportuna. Resultados Los resultados obtenidos en la implantación de esta metodología han sido, por un lado, que los usuarios quedan satisfechos con el producto terminado; y, por otro, los alumnos viven una experiencia real de desarrollo de sistemas donde: Reconocen e incrementan sus habilidades de liderazgo y trabajo en equipo. Enriquecen sus conocimientos en el área y sus habilidades para la administración de proyectos. Fortalecen la confianza en sí mismos, en sus conocimientos y en sus habilidades. Desarrollan la necesidad de aprender por sí mismos para dar soluciones a problemas. Valoran la participación de los usuarios en los proyectos. Conclusiones 6
Esta metodología ofrece una referencia a los profesores que desean participar en proyectos de desarrollo de sistemas con alumnos del área bajo el esquema PADS. Si bien es cierto que cualquier desarrollo de software presenta sus propios retos, se debe reconocer que trabajar con el esquema estudiantil implica cumplir adicionalmente con objetivos de formación académica. De ahí la importancia de: Cumplir con las expectativas de los clientes, y Formar personas en su área de especialidad con conocimientos, actitudes y valores para que fomenten el desarrollo de sus comunidades. Capitalización Los beneficios que encuentro en la aplicación de esta metodología están orientados tanto al cumplimiento del proyecto como a la formación de los alumnos: La aplicación de esta metodología, principalmente en sus fases iniciales (1 a 7) y finales (13 14) pueden evitar problemas de conformidad con los usuarios y con los alumnos. Esta metodología esta diseñada principalmente para la administración de proyectos de desarrollo de sistemas; sin embargo, puede utilizarse en otro tipo de proyectos, por ejemplo en el área de ingeniería industrial. Para los alumnos es mejor ser parte de un proyecto que mano de obra barata en el desarrollo de sistemas. Bibliografía [Kendall] Análisis y Diseño de Sistemas de Información Kendall & Kendall Tercera edición Prentice Hall 1997 [Yourdon] Análisis Estructurado Moderno Edward Yourdon Prentice Hall 1994 [Schwalbe] Information Technology Project Management Kathy Schwalbe Course Technology 1999 [Wilson] Systems: Concepts, methodologies and applications Brian Wilson Wiley 1984 7
Apéndice A Participantes del proyecto ITESM Alestra Verano 1997 José Antonio Rivera Blasco ISI 172131 Jorge Andrés Salinas Girodengo ISI 173150 Mónica Zamudio Pérez LSCA 173591 Gabriela Ilich Valero Pámanes ISI 175427 Guadalupe Monserrat Pozoz Guerrero ISI 177660 Ana Maribel Ramos Fajardo ISI 177662 Magdalena Margarita Sánchez García ISI 262286 Dora Esthela Izaguirre González LSCA 283688 Geidy Sandoval Alcántara LSCA 446139 8
Apéndice B Participantes del proyecto ITESM Ciudad de los Niños Enero Mayo 1999 Juan Luis García ISC 766645 Ulises Ochoa ISC 172682 Jorge Pérez ISC 449951 Gerardo Rodríguez ISC 174262 Oscar Aguilar ISC 764600 Hilda Beas LSCA 763986 Gabriela Saldívar ISE 178523 Apéndice C Participantes del proyecto DIEX Enero Mayo 2000 Noel Antonio Vázquez ISI 174091 Juan Pablo Anaya V LSCA 177647 Francisco Javier Flores R ISI 251524 Luis Carlos Espinoza H LSCA 338178 Roberto Díaz LSCA 450949 José Ramón Hernández Macías LSCA 583668 Enriqueta Vega ISE 586686 Luis Fernando Ramírez LSCA 716623 Eduardo Zavala LSCA 765935 Carlos E. Barclay LSCA 766141 Miguel Angel Velázquez LSCA 766160 Mauricio H Contreras LSCA 766648 9
Apéndice D Proceso de elaboración de prototipos Definición de requisitos Construcción del prototipo Evaluación del prototipo Prototipo Final Apéndice E Ciclo de Vida de Desarrollo de Sistemas 10