Producto de trabajo: Proceso de desarrollo
Este producto de trabajo describe el proceso que un proyecto seguirá para producir los resultados deseados del proyecto. También se hace referencia a este producto de trabajo como proceso de desarrollo de software.
Objetivo
El objetivo del proceso de desarrollo es proporcionar orientación y soporte a los miembros del proyecto. "Información a su alcance" es una metáfora que se alinea bien con el objetivo de este producto de trabajo.
Relaciones
RolesResponsable: Modificado por:
Entrada aObligatoria:
  • Ninguno
Opcional: Externa:
  • Ninguno
Descripción principal

Cada proceso está formado por una estructura detallada de nivel-n. El contenido del método central proporciona explicaciones paso a paso, describiendo cómo se alcanzan objetivos de desarrollo muy específicos, independientemente de la ubicación de estos pasos dentro del ciclo vital de desarrollo. Los procesos toman estos elementos de método y los relacionan con secuencias semiordenadas que se personalizan con tipos de proyectos específicos. Por lo tanto, un proceso es un conjunto de descripciones de trabajo parcialmente ordenadas previstas para alcanzar un objetivo de desarrollo más elevado, como el release de un sistema de software específico. Un proceso se centra en el ciclo vital y las secuencias de trabajo en las estructuras de desglose.

Existen diferentes tipos de procesos: Proceso de entrega y Patrón de posibilidad.

Proceso de entrega

Un proceso de entrega describe un enfoque completo e integrado para realizar un tipo específico de proyecto de desarrollo. Un proceso de entrega es un proceso que cubre todo un ciclo vital de desarrollo desde el principio hasta el final. Un proceso de entrega se utiliza como plantilla para planificar y ejecutar un proyecto. Proporciona un modelo de ciclo vital completo con fases predefinidas, iteraciones y actividades que se han detallado secuenciando el contenido del método en estructuras de desglose. Se ha definido sobre la base de la experiencia con los proyectos o compromisos anteriores, y/o la utillización recomendada de un enfoque de desarrollo o de entrega. Define qué se produce, cómo se producen estos elementos, y el personal necesario en forma de trabajo integrado, producto de trabajo y estructuras de desglose del equipo. Por ejemplo, un ingeniero de proceso puede definir procesos de entrega alternativos para proyectos de desarrollo de software que difieren en la escala del compromiso y personal necesario, el tipo de aplicación de software que se va a desarrollar, los métodos de desarrollo y las tecnologías a utilizar, etc. Aunque el proceso de entrega pretende cubrir todo el proyecto, mantiene abiertas ciertas decisiones que son demasiado específicas del proyecto. Por ejemplo, la estructura detallada define qué elementos de desglose tienen varias apariciones o se pueden repetir a través de sus respectivos atributos, pero no indica cuantas apariciones y cuantas repeticiones/iteraciones tendrán. Estas decisiones debe tomarlas un gestor de proyectos al planificar el proyecto concreto, la fase del proyecto, o las iteraciones del proyecto.

Patrón de posibilidad

Un patrón de posibilidad describe un clúster reutilizable de actividades en áreas de proceso comunes. Los patrones de posibilidad expresan y comunican el conocimiento del proceso para un área clave de interés como la Disciplina y los puede utilizar directamente un practicante de proceso para orientar su trabajo. También se utilizan como bloques de construcción para ensamblar procesos de entrega o patrones de posibilidad más grandes que garanticen la reutilización óptima y la aplicación de las prácticas clave que expresan. Algunos ejemplos de patrón de posibilidad pueden ser 'utilizar la gestión de requisitos basada en guiones', 'utilizar el análisis de guiones' o 'prueba de unidades'. Habitualmente, aunque no es necesario, los patrones de posibilidad tienen el ámbito de una disciplina que proporciona un desglose de actividades complejas reutilizables, relaciones con los roles que efectúan tareas dentro de estas actividades, así como los productos de trabajo que se utilizan y producen. Un patrón de posibilidad no se relaciona con una fase específica o iteración de un ciclo vital de desarrollo, y no debe implicar ninguno. En otras palabras, un patrón debe diseñarse de modo que sea aplicable en cualquier parte del proceso de entrega. Esto permite que sus actividades se asignen con flexibilidad a cualquier fase en la que se esté aplicando el proceso de entrega.

Es una práctica recomendada diseñar un patrón de posibilidad para producir uno o más entregables genéricos. La configuración típica es que cada actividad del patrón de posibilidad produzca un entregable, y que el último descriptor de tareas de la actividad explícitamente extraiga sólo este entregable. Esto permite que el ingeniero de proceso seleccione patrones o sólo actividades decidiendo qué entregables son necesarios. También ofrece un enfoque de integración sencillo: una Actividad de un patrón de posibilidad se enlaza con la fase o iteración que es necesaria para producir el entregable de la actividad.

Propiedades
Opcional
PlaneadoYes
Factores clave
Puede decidir no capturar el proceso entero en el proceso de desarrollo. En algunos casos, parte de la responsabilidad y de las decisiones sobre el proceso, y los productos de trabajo en particular, se delegan a los miembros del proyecto de desarrollo de software. Por ejemplo, si cuenta con un buen gestor de proyectos con experiencia, puede delegar en esta persona las decisiones sobre qué planes producir y cómo hacerlo. De la misma manera, muchos gestores de proyectos no se preocupan sobre cómo cada miembro del equipo diseña su parte del sistema, siempre y cuando entreguen la funcionalidad esperada a tiempo y dentro de un nivel de calidad razonable.

Una razón para contar con una descripción del proceso es que varias personas puedan compartir la información. De no ser así, el coste del mantenimiento de la descripción del proceso puede ser muy alto. Por lo tanto, puede decidir no tener, o mantener, la descripción del proceso de una o varias disciplinas. Esto no significa que no se invierten esfuerzos en esa disciplina determinada, ni tampoco significa que no se considere importante. Por ejemplo, puede tener un gestor de pruebas excelente, proporcionar todo el soporte posible, pero delegar en el gestor de pruebas la decisión de cómo trabajar y qué productos de trabajo producir.

Más información