INTRODUCCIN A LOS CONCEPTOS DE GESTIN DE PROYECTOS DE SOFTWARE Vismar G. Flores T. y Roberto C. Cueva S. vgflores@utpl.edu.ec - rccueva@utpl.edu.

ec Escuela de Ciencias de la Computacin Universidad Tcnica Particular de Loja

1. Resumen Este artculo tiene como finalidad estudiar los conceptos bsicos orientados a la Gestin de Proyectos de Software enfocado principalmente a las cuatro P (Personal, Producto, Proceso y Proyecto). Lo que pretendemos es mostrar las principales ventajas que obtenemos al utilizar la gestin de proyectos en el desarrollo de software tanto en el aspecto de la conformacin de equipos tomando en cuenta las caractersticas sobresalientes que el equipo debe tener, para llevar una ejecucin exitosa del proyecto; as como los diferentes procesos que pueden existir en el mismo, facilitando la deteccin de posibles errores en la elaboracin y consejos para prevenirlos alcanzando un ndice de alta calidad del producto a presentar. 2. Introduccin Planteo del problema de la gestin La gestin de proyectos de software persigue la misma finalidad que todas las gestiones de proyectos de ingeniera: Estimar que suceder con un proyecto nuevo Analizar qu sucedi con un proyecto ya finalizado En todos los casos se tratar de dar respuestas cuantitativas a preguntas precisas tales como: Cul ser el plazo de entrega? Cuntas personas necesito? Cunto costar el proyecto? La gestin de proyectos de software es una rama especializada de la Ing. de software.[1] Gestin de proyectos de Software

No debe perderse de vista nunca que lo que intentamos hacer no es una rama de la brujera sino una rama de la Ing. del Software. No se busca preparar gurs sino ingenieros, no se apela a oscuros mecanismos sino a datos numricos en informacin medible. No debe confundirse una ecuacin emprica, obtenida del anlisis de muchos casos y sometida reiteradas veces al contraste con la experiencia prctica con una forma de brujera. Por esta razn, estamos hablando de una rama de la ingeniera que: Emplea metodologas bien definidas. Realiza medidas repetibles y confiables. Estima costos y tiempos. Da elementos para la gestin de los proyectos. Replantea resultados para ajustar la informacin disponible.

Diferentes tipos de proyectos Debemos diferenciar tres tipos de proyectos desde el punto de vista de su gestin: Proyectos nuevos: se busca analizar costos, tiempos y cantidad de personas. Es el caso ms difcil de todos. Replanteo de proyectos viejos: se busca afinar la metodologas de estimacin. Es la principal fuente de informacin Extensiones: o ampliaciones de un proyecto existente: Es un caso intermedio donde se desea tener buena precisin en plazos y costos.

El tamao de los proyectos Los proyectos de software son diferentes por la sola razn de su tamao. Proyectos pequeos: consisten solamente en implementacin. No tienen costos indirectos importantes Proyectos medianos: es un caso intermedio entre los dos. Proyectos grandes: poseen implementacin, pero hay ms cosas. Poseen gerencia de proyecto, control de calidad, capacitacin de personal, hay un plan de mantenimiento, hay

documentacin importante para uso interno y externo. Se genera informacin para mercadeo. Un error clsico en la historia de la gestin de proyectos fue no advertir la existencia de stas tres categoras y es un error pensar que la experiencia adquirida en proyectos pequeos nos pueda servir en proyectos medianos o grandes. La constitucin del equipo de trabajo es uno de los mejores indicadores del caso que se considera. Pequeos: - Menos de un ao de tiempo de desarrollo - Menos de 25 meses-persona de esfuerzo total - Menos de 3 personas en el equipo de trabajo Grandes: - Mas de 3 aos de tiempo de desarrollo - Mas de 100 meses persona - Mas de 10 personas en el equipo de trabajo Un equipo de trabajo de menos de 3 personas puede trabajar con una documentacin informal, un equipo de mas de 10 personas, durante varios aos, no puede confiar en los contactos personales ni en la memoria de la gente. Es ms, puede ocurrir que muchos de los que comienzan en el proyecto sean reemplazados por otros, en plazos tan largos.[3]

3. Desarrollo El trabajo desarrollado se basa en el enfoque de las 4 P (Personal, Producto, Proceso y Proyecto). Personal Sin duda alguna en todas las empresas el elemento ms importante es el recurso humano o personal. El SEI, desarrollo ha desarrollado el MMCGP con el fin de: Aumentar la rapidez con la cual las organizaciones de sw acometen las aplicaciones cada vez ms complejas al ayudar a atraer, aumentar, motivar, desplegar y retener el talento necesario para mejorar su capacidad de desarrollo de sw [4]

 El equipo de direccin del proyecto debe identificar a los interesados, determinar sus requisitos y expectativas y, gestionar su influencia en relacin con los requisitos para asegurar un proyecto exitoso. Qu tomar en cuenta? Reclutamiento, seleccin, entrenamiento, diseo de la organizacin, el trabajo y desarrollo de la cultura de equipo. Participantes: Se proponen las siguientes categoras: Gestores Ejecutivos.- definen aspectos del negocio Gestores del proyecto.- planifican, motivan, organizan y controlan a los profesionales que realizan el trabajo de sw. Profesionales.- dan habilidades para la ingeniera de una aplicacin. Clientes.-especifican requisitos y necesidades Usuarios Finales.- quienes interactan con el sistema.

Interesados: Director del proyecto. Dirige el proyecto. Cliente/usuario. Persona u organizacin que utilizar el producto del proyecto. Organizacin ejecutante. Empresa cuyos empleados participan ms directamente en el trabajo del proyecto. Miembros del equipo del proyecto. El grupo que realiza el trabajo del proyecto. Equipo de direccin del proyecto. Miembros del equipo del proyecto que participan directamente en las actividades de direccin del proyecto. Patrocinador. Persona o grupo que proporciona los recursos financieros, monetarios o en especie, para el proyecto. Influyentes. Personas o grupos que no estn directamente relacionados con la adquisicin o el uso del producto del proyecto, pero que, debido a su posicin en la organizacin del cliente u organizacin ejecutante, pueden ejercer una influencia positiva o negativa sobre el

curso del proyecto. Oficina de Gestin de Proyectos (PMO). Puede ser un interesado si tiene responsabilidad directa o indirecta sobre el resultado del proyecto.

Cmo estructurar un equipo? Se debe tener en cuenta las siguientes consideraciones: La dificultad del problema que se resolver. El tamao del programa resultante en lneas de cdigo. Vida del equipo (trabajo en conjunto) El grado en el que el problema puede separarse en mdulos. La calidad y confiabilidad requeridas del sistema que se construir. La rigidez de la fecha de entrega. El grado de comunicacin que requiere el proyecto

Paradigmas Organizacionales

Tipos

Caractersticas

- Jerarqua tradicional de autoridad Cerrado - Aconsejable para proyectos similares a anteriores. - Dbil para proyectos innovadores

- Equipo libremente y depende de la iniciativa individual. Aleatorio - Fuerte en proyectos innovadores - Puede haber problemas cuando hay desempeo ordenado.

Abierto

-Usa controles del cerrado e innovacin del aleatorio - Slida comunicacin y toma de decisiones basadas en el consenso.

-Organiza a los miembros para trabajar en partes del problema Sincrnico -Poca comunicacin entre los miembros

CUIDADO Factores que inciden negativamente en un ambiente de trabajo en equipo: 1. Una atmsfera de trabajo frentica 2. Alta frustracin que provoca friccin entre los miembros del equipo 3. Proceso de software pobremente coordinado 4. Una definicin poco clara de los papeles del equipo de sw. 5. Continuas y repetidas exposiciones al fracaso.

EQUIPOS GILES La filosofa gil alienta la satisfaccin del cliente y la temprana entrega incremental del software. - Pequeos equipos de trabajo enormemente motivados - Mtodos informales - Mnimos productos de trabajo de ingeniera del sw. - Simplicidad global de desarrollo

Producto Un proyecto crea productos entregables nicos. Productos entregables son productos,

servicios o resultados. Los proyectos pueden crear: Un producto o artculo producido, que es cuantificable, y que puede ser un elemento terminado o un componente La capacidad de prestar un servicio como, por ejemplo, las funciones del negocio que respaldan la produccin o la distribucin Un resultado como, por ejemplo, salidas o documentos. Por ejemplo, de un proyecto de investigacin se obtienen conocimientos que pueden usarse para determinar si existe o no una tendencia o si un nuevo proceso beneficiar a la sociedad La conclusin y la aprobacin de uno o ms productos entregables caracterizan a una fase del proyecto. Un producto entregable es un producto de trabajo que se puede medir y verificar, tal como una especificacin, un informe del estudio de viabilidad, un documento de diseo detallado o un prototipo de trabajo. Algunos productos entregables pueden corresponder al mismo proceso de direccin de proyectos, mientras que otros son los productos finales o componentes de los productos finales para los cuales se cre el proyecto. Los productos entregables, y en consecuencia las fases, son parte de un proceso generalmente secuencial, diseado para asegurar el adecuado control del proyecto y para obtener el producto o servicio deseado, que es el objetivo del proyecto. En cualquier proyecto especfico, las fases se pueden subdividir en subfases en funcin del tamao, complejidad, nivel de riesgo y restricciones del flujo de caja. Cada subfase se alinea con uno o ms productos entregables especficos para el seguimiento y control. La mayora de estos productos entregables de las subfases estn relacionados con el producto entregable de la fase principal, y las fases normalmente toman el nombre de estos productos entregables de las subfases: requisitos, diseo, construccin, prueba, puesta en marcha, rotacin, entre otros, segn corresponda. Por lo general, una fase del proyecto concluye con una revisin del trabajo logrado y los productos entregables, a fin de determinar la aceptacin, tanto si an se requiere trabajo adicional como si se debe considerar cerrada la fase. Con frecuencia, la direccin lleva a cabo una revisin para tomar una decisin a fin de comenzar las actividades de la siguiente fase sin cerrar la fase actual, por ejemplo, cuando el director del proyecto elige la ejecucin rpida como curso de accin. Otro ejemplo es cuando una compaa de tecnologa de la informacin elige un ciclo de vida iterativo donde ms de una fase del proyecto puede avanzar de forma simultnea. Los requisitos de un mdulo se pueden recopilar y analizar antes de que el mdulo sea diseado y construido. Mientras se lleva a cabo el anlisis de un mdulo, se puede comenzar a recopilar los requisitos de otro mdulo de forma paralela. [5]

Proceso Un proceso de software proporciona el marco de trabajo desde el cual se puede establecer un plan detallado para el desarrollo del software. Un pequeo nmero de actividades del

marco de trabajo es aplicable a todos los proyectos de software, sin importar su tamao o complejidad. Algunos conjuntos de tareas diferentes (tareas, hitos, productos de trabajo y puntos de control de calidad) permiten que las actividades del marco de trabajo se adapten a las caractersticas del proyecto de software, as como a los requisitos del equipo del proyecto. Finalmente, las actividades protectoras como control de calidad, la gestin de configuracin y la medicin cubren el modelo del proceso. Las actividades protectoras son independientes de cualquier actividad del marco de trabajo y ocurren durante todo el proceso Elegir el modelo que mejor se adapte Para cumplir con: 1. Los clientes que han solicitado el producto y el personal que har el trabajo. 2. Las caractersticas del producto 3. El ambiente del proyecto en que trabaja el equipo de

Descomposicin del proceso: Esta descomposicin depende mucho del tipo de proyecto que se realizar, as por ejemplo: Proyecto pequeo enfoque secuencial Restricciones de tiempo desarrollo rpido de aplicaciones (DRA) Funcionalidad no se alcanza por fecha muy ceida estrategia incremental

Proyecto La gestin de un proyecto de software exitoso requiere entender qu puede salir mal. A continuacin se indican 10 seales de que un proyecto est en peligro. 1. El personal de software no entiende las necesidades de sus clientes. 2. El mbito del producto est mas definido 3. Los cambios se gestionan mal 4. La tecnologa elegida cambia 5. Las necesidades comerciales cambian

6. Los plazos de entrega no son realistas 7. Los usuarios se resisten 8. Se pierde el patrocinio 9. El equipo de proyecto carece de personal con las habilidades apropiadas 10. Los gestores evitan las mejores practicas y las lecciones aprendidas

Qu hacer frente a lo anterior? 1. Comience con el pie derecho entendiendo bien el proyecto , definir los objetivos dar al equipo autonoma, autoridad, y tecnologa. 2. Mantenga el mpetu proporcionar incentivos los gestores deben estar fuera del camino del equipo de desarrollo. 3. Rastree el proyecto mediante revisiones tcnicas formales (QA) establecer medidas que muestren el progreso. 4. Tome decisiones inteligentes mantenerlo simple consejo utilice sw o componentes ya desarrollados, no se complique la vida 5. Realice un anlisis de resultados mtricas del proyecto de sw realimentacin de los miembros y clientes registre los hallazgos

4. Resultados En todos los proyectos de ingeniera la buena calidad se adquiere mediante un buen diseo, pero en el caso del software, la etapa de construccin incide pobremente en su calidad, no as en la construccin de hardware o de una obra civil. As, no se puede gestionar un proyecto de desarrollo de software como si se tratara de un proyecto de fabricacin. Es por eso que en el desarrollo de software donde no existe una gestin adecuada podemos encontrar varios problemas tales como:

Requerimientos incorrectos e incompletos, muchas especificaciones de requerimientos son inestables y sujetas a cambios mayores, la planificacin no se lleva a cabo por la creencia errnea de que es una prdida de tiempo y los planes cambiarn de todos modos, es difcil estimar el tamao y complejidad del proyecto de software de modo de realizar una estimacin de costos y plazos realista, no se manejan factores de riesgo, la mayora de las organizaciones de desarrollo de software no recolectan datos de proyectos pasados, las compaas no establecen polticas o procesos de desarrollo de software. La gestin del proyecto de software es el primer nivel del proceso de ingeniera de software, que nos permite hacer frente a los problemas anteriormente mencionados, porque cubre todo el proceso de desarrollo. Para conseguir un proyecto de software fructfero se debe comprender el mbito del trabajo a realizar, los riesgos en los que se puede incurrir, los recursos requeridos, las tareas a llevar a cabo, el esfuerzo (costo) a consumir y el plan a seguir. En el presente artculo se detalla los elementos ms importantes y relevantes de la gestin de proyectos de software, de modo de proveer las bases conceptuales necesarias para llevar a cabo un proyecto exitoso.

Con respecto a la manera en cmo se llevo la clase impartida a nuestros compaeros obtuvimos los siguientes resultados: La compresin de forma clara acerca de los pilares de la gestin de proyectos (Personal, Producto, Proceso y Proyecto). Los estudiantes estn la capacidad de prever en forma general los aspectos importantes al conformar un equipo de trabajo. Determinar en forma clara las diferencias y similitudes entre los paradigmas organizacionales. Estudiamos los sntomas de cuando un proyecto se encuentra en problemas para poder evitarlos en un futuro. Aporte por parte de los compaeros al surgir nuevos criterios valederos de los conceptos tratados.

 En el transcurso de la clase realizamos el estudio con ejemplos prcticos de las diferentes culturas organizacionales a nivel local como internaciones especficamente con el ejemplo de cmo se trabaja en google. 5. Conclusiones Cualquier proyecto que se desarrolle debe ser gestionado sin importar su tamao o dificultad. La eleccin de la metodologa de desarrollo sin lugar a duda debe estar acorde a las necesidades a resolver. La correcta aplicabilidad de los conceptos estudiados influyen en el xito o fracaso del proyecto. Todos los proyectos de software que se desarrollan corren sobre una base fundamental que es el PMI.

6. Bibliografa PRESSMAN ROGER. Ingeniera de software, (VI edicin) Gua de los Fundamentos de la Direccin de Proyectos. (2004) (en digital). Tercera Edicin. Newtown Square. Pennsylvania 19073-3299 EE.UU. SOMMERVILLE IAM(2005) Ingeniera de Software. (VII edicin) Madrid:Ed.Pearson The American Heritage Dictionary of the English Language, 3rd ed. Boston: Houghton Mifflin Company, 1992. International Organization for Standardization/International Electrotechnical Commission (ISO/IEC) Guide 2. Geneva: ISO Press, 1996. Turner, J. Rodney. The Handbook of Project-Based Management. New York: McGrawHill,1992. PALACIO, J. Gestin de Proyecto gil y valor de producto. (en video) Disponible en
www.qualitatis.org

GROMPONE, J. (1996) Gestin de Proyectos de Software. Montevideo, Uruguay: Ed. La Flor del Itapeb
[1]

GROMPONE, J. (1996) Gestin de Proyectos de Software. Montevideo, Uruguay: Ed. La Flor del Itapeb.
[2] [3]

GROMPONE, J. (1996) Gestin de Proyectos de Software. Montevideo, Uruguay:

Ed. La Flor del Itapeb. CURTIS, B. et al., People Management Capability Maturity Model, Software Engineering Institute, 1994
[4]

Gua de los Fundamentos de la Direccin de Proyectos. (2004) (en digital). Tercera Edicin. Newtown Square. Pennsylvania 19073-3299 EE.UU.
[5]