Compartir a través de


Actividades de proyecto

Para usar MSF for CMMI Process Improvement v5.0 con la máxima eficacia, debe organizar el proyecto en una serie de iteraciones, normalmente entre cuatro y ocho semanas. Esto ayuda a reducir los riesgos para el proyecto derivados de un cambio en los requisitos y los costos de implementación. La estructura iterativa del proyecto es una contribución importante para satisfacer los requisitos de administración de riesgos de CMMI.

Para obtener más información sobre CMMI, vea Información general de CMMI.

Al principio del proyecto

Principio del proyecto

En el principio se incluye la definición de la visión del proyecto, que establece lo que los usuarios podrán realizar cuando el proyecto lance su producto.

También se incluye la configuración del equipo, de la infraestructura y de los demás recursos, así como la determinación del proceso de desarrollo.

Para obtener más información, vea Principio del proyecto.

Planeación inicial del proyecto

La planeación del proyecto incluye las actividades siguientes:

  • Analizar los requisitos con el detalle suficiente para permitir formar un plan. Este análisis puede incluir el uso de modelos de requisitos, guiones gráficos y otras herramientas que ayudan a prever el sistema de trabajo.

  • Crear un diseño o arquitectura totales para el sistema. Si esto implica trabajar en una plataforma nueva para los miembros del equipo, se debe asignar un tiempo para experimentar con ella. El desarrollo será lento en las iteraciones anteriores.

  • Presentar los requisitos como un conjunto de requisitos de producto incrementales cuyo desarrollo se puede estimar de forma aproximada. La diferencia entre los requisitos generales y los requisitos de producto es un punto importante y se trata de una actividad significativa. Para obtener más información, vea Implementar requisitos.

  • Realizar una asignación inicial de requisitos del producto a las iteraciones.

  • Establecer fechas para los lanzamientos.

Se volverá sobre los modelos del plan y de los requisitos para perfeccionarlos a lo largo del proyecto. Una parte del objetivo del desarrollo iterativo es permitir las mejoras en los requisitos provenientes de la demostración de software que funciona en una fase inicial.

La planeación inicial del proyecto se realiza en la Iteración 0.

Para obtener más información, vea Planear el proyecto (CMMI).

Explorar un producto existente

El objetivo del proyecto podría ser actualizar un producto que ya existe. En este caso, si el equipo no está familiarizado con el producto, la exploración del código es una actividad de la Iteración 0. Cada tarea de desarrollo en las iteraciones subsiguientes también implicará la comprensión del código en una situación determinada y la traza de las consecuencias de cambiarlo.

Para obtener más información, vea Visualizar código.

Durante el proyecto

El plan se revisa y está sujeto a cambios a lo largo del proyecto.

Varias actividades relacionadas con el plan del proyecto se realizan de forma regular a lo largo del proyecto, normalmente hacia el final de una iteración.

Validación

Muestre a los clientes o a las partes interesadas del negocio el software desarrollado durante la iteración. Cuando sea factible, entrégueselo para que puedan experimentar con él o utilizarlo hasta un determinado punto en un contexto práctico.

Después de un intervalo suficiente, acuerde una reunión para revisar los comentarios del usuario. Los comentarios se deben utilizar para generar solicitudes de cambio.

Para obtener más información, vea Validating Customer Requirements.

Administración de riesgos

Revise la probabilidad y el impacto de posibles eventos adversos y dé los pasos necesarios para reducir los riesgos. Para obtener más información, vea Administrar riesgos.

Administración de cambios

Puede utilizar los elementos de trabajo de solicitudes de cambio para registrar los cambios en los requisitos establecidos por las partes interesadas del negocio. Pueden provenir de cambios en el contexto del negocio pero también de la demostración y pruebas de versiones tempranas del producto. Estos cambios deben ser bien recibidos porque mejoran la aptitud del producto al objetivo comercial. Este efecto forma parte del objetivo de desarrollo incremental.

Algunos equipos de proyecto ajustan los elementos de trabajo de requisitos de producto cuando se solicitan cambios, sin utilizar un elemento de trabajo independiente. Pero la ventaja del elemento de trabajo de solicitud de cambio es que, en la parte última del proyecto, se pueden revisar el número y la naturaleza de los cambios realizados. Se puede utilizar esa información para mejorar el proceso o la arquitectura con vistas al futuro.

Las solicitudes de cambio se deben utilizar como entrada a la revisión del plan del producto.

Para obtener más información, vea Administrar cambios (CMMI).

Revisión del plan del producto

Mantenga una revisión del plan del producto antes de planear cada iteración. El plan del proyecto asigna requisitos del producto a las iteraciones.

El plan cambiará por dos razones principales:

  • Cambios en los requisitos.

  • Cambios en las estimaciones realizadas por los desarrolladores. Según progresa el proyecto, el equipo de desarrollo puede realizar estimaciones más confiables del trabajo necesario para implementar características futuras. En algunos casos, podrían haberse pospuesto algunas funciones a partir de una iteración anterior, que agrega una característica al plan.

Ambos tipos de cambio son menos frecuentes en iteraciones posteriores.

Revise los modelos de requisitos de los que se derivan los requisitos del producto.

Revise la asignación de requisitos a las iteraciones. Al igual que en la actividad de planeación inicial, las partes interesadas del negocio proporcionan las prioridades, el equipo de desarrollo proporciona las estimaciones y la reunión permite reorganizar las características entre iteraciones.

Para obtener más información, vea Planear el proyecto (CMMI).

Antes de las versiones principales del producto

Las actividades implicadas en la implementación de un producto varían de acuerdo con su tipo y no se tratan aquí.

Tenga en cuenta los puntos siguientes en lo que respeta a las iteraciones posteriores de desarrollo de software:

  • Excluya la realización de cambios principales en el diseño para evitar que se planteen problemas imprevistos.

  • Eleve el listón de cambios y errores en las reuniones de evaluación de errores. Deben rechazarse los cambios propuestos y las correcciones de errores a menos que tengan efectos significativos en la facilidad de uso y la aptitud para la finalidad del producto.

  • Dedique recursos al aumento de la cobertura de pruebas y a la realización de pruebas manuales.