Compartir a través de


Administración de proyectos

Puede utilizar la sección Administración de proyectos de la guía de MSF for CMMI Process Improvement para entender mejor cómo administrar, planear y coordinar el desarrollo y el mantenimiento de los productos de software. Para obtener más información sobre CMMI, vea Información general de CMMI.

En Administración de proyectos, los grupos de áreas de proceso de CMMI incluye Planeación de proyectos, Supervisión y control de proyectos, Administración integrada de proyectos, Administración de riesgos y Administración cuantitativa de proyectos. Todas las áreas, salvo la de Administración cuantitativa de proyectos, forman parte de los niveles de modelo 2 o 3. La Administración cuantitativa de proyectos es una actividad de nivel 4 del modelo que refleja cómo las organizaciones de gran madurez utilizan datos cuantitativos objetivos basados en estadísticas para tomar decisiones de administración y dirigir los proyectos hacia una meta adecuada y predecible.

Las actividades de administración de proyectos representan costos económicos de actividades de ingeniería de valor añadido. Estas actividades son necesarias e importantes para administrar el riesgo, coordinar correctamente los esfuerzos de ingeniería y definir de manera adecuada las expectativas del cliente. Sin embargo, se debe minimizar el esfuerzo dedicado a estas actividades. " Poco y muchas veces" sería un buen lema. Los lotes de menor tamaño reducen la complejidad y los costos de coordinación. Al definir y elaborar una definición de proceso, se ha de tener en cuenta que las actividades de administración de proyectos deben reducirse al mínimo a la vez que deben ajustarse al perfil de riesgos del proyecto.

Desarrollo iterativo

Team Foundation junto con la plantilla de proceso MSF for CMMI admite el trabajo iterativo. El desarrollo iterativo administra el riesgo aportando software demostrable y probado a intervalos fijos a lo largo del proyecto.

Iteraciones sucesivas

La programación de un proyecto está organizada en una serie de iteraciones cuya duración suele ser de cuatro a seis semanas. Cada iteración finaliza con una demostración del software probado y utilizable. Para obtener más información, vea Crear y modificar áreas e iteraciones.

  • En el plan de proyecto se indican los requisitos en materia de características que se van a desarrollar en cada iteración. El plan de proyecto se desarrolla en la iteración 0 y se revisa al principio de cada iteración. El plan de proyecto se puede ver de diferentes maneras; por ejemplo, a través del Panel de proyecto. Para obtener más información, vea Requisito (CMMI) y Panel de proyecto (CMMI).

  • En cada plan de iteración se indican las tareas que se van a realizar durante esa iteración. La mayoría de las tareas son tareas de desarrollo y de prueba que son necesarias para cumplir los requisitos en materia de características que se han programado para esa iteración. El plan de iteración se puede ver a través del panel Progreso. Para obtener más información, vea Tarea (CMMI) y Progreso (Panel de CMMI).

El trabajo iterativo no administra automáticamente los riesgos. Para minimizar el riesgo, es preciso organizar el plan de proyecto en incrementos. Las iteraciones tempranas deben proporcionar un "fino segmento de extremo a extremo", es decir una versión mínima de los comportamientos más importantes del producto. Las iteraciones posteriores agregan más funcionalidad.

Por el contrario, sería mucho menos útil programar toda la parte comercial de un sitio web de compras en el primer tercio del proyecto, todo el sistema del almacén en el segundo tercio y todo el sistema de pagos en el último tercio. Esta programación correría el riesgo de crear un sitio web de ventas atractivo y con muchas características pero sin ningún medio para aceptar los pagos de sus clientes. El desarrollo es iterativo pero no es incremental.

El desarrollo incremental tiene las siguientes ventajas:

  • Permite cumplir los verdaderos requisitos. Las partes interesadas tienen la oportunidad de probar el producto, lo que siempre da lugar a mejoras en sus requisitos.

  • Permite ajustar la arquitectura. Permite al equipo de desarrollo detectar y solucionar las dificultades que se producen con la plataforma o realizar posibles mejoras en su diseño.

  • Permite asegurar resultados. Las partes interesadas saben que, incluso si se recortan parcialmente los recursos de un proyecto, los gastos incurridos hasta la fecha no habrán sido en vano. Lo mismo se aplica si resulta que las estimaciones de desarrollo han sido optimistas y se deben quitar las características menos importantes.

Para obtener más información sobre cómo expresar de manera apropiada los requisitos del desarrollo incremental, vea Implementar requisitos.

Ciclos más y menos reducidos

El proyecto y la iteración no son los únicos aspectos cíclicos del desarrollo de software. Por ejemplo, en una iteración, los miembros del equipo comienzan y completan las tareas y protegen el código. El sistema de compilación compila el producto de manera continua o por la noche. Todos los días, el equipo revisa brevemente el progreso de las tareas de iteración.

Proteger, compilación diaria, iteración, proyecto, programa

Proyectos grandes

Un proyecto en el que trabaja un equipo a través de una serie de iteraciones puede formar parte de un proyecto o programa más grande. Un proyecto grande tiene varios equipos que trabajan en paralelo. Cada equipo suele componerse de 16 personas.

Se debe abrir una bifurcación de control de versiones independiente para cada equipo. Cada equipo debe integrarse con la bifurcación principal al final de cada iteración. Para obtener más información, vea Bifurcar y combinar.

La bifurcación principal queda reservada para la integración y las pruebas. El equipo de compilación debe realizar un conjunto completo de pruebas después de una integración.

Se debe asignar un área a cada equipo para que sus elementos de trabajo puedan separarse con facilidad de los demás. Para obtener más información, vea Crear y modificar áreas e iteraciones.

Los equipos pueden compartir una serie de integraciones, pero esto no siempre es necesario. Si los equipos no sincronizan las integraciones, cada equipo debe tener un prefijo propio para sus nombres de iteración.

En esta sección

Ciclo de proyecto: se inicia el proyecto, se recopilan los requisitos, se crea un plan de proyecto, se divide dicho plan en iteraciones y se entregan las versiones. Se administran los riesgos y los cambios realizados en el plan.

Actividades de proyecto

Ciclo de iteración: se revisan y se actualizan los requisitos, se planean las tareas para implementar los requisitos y se administran los problemas cuando se producen.

Actividades de iteración

Vea también

Conceptos

MSF for CMMI Process Improvement v5.0