Elementos Generales Del Plan De Trabajo Para Gestionar Un Desarrollo De Software Bajo El Estándar De La Norma IEEE 1058.1

Elementos Generales del Plan de Trabajo para Gestionar un Desarrollo de Software bajo el estándar de La norma IEEE 1058.1

1. Definiciones.

Las definiciones listadas a continuación establecen significados dentro del contexto de este estándar.

Activity (Actividad). Una unidad principal de trabajo que debe ser completada para lograr los objetivos de un proyecto software. Una actividad tiene una fecha determinada de inicio y otra de final, incorpora un conjunto de tareas a ser completadas, los recursos que consume y resultados en los productos de trabajo. Una actividad pueden contener otras actividades de forma jerárquica.

Baseline (Documento Base).1 Un producto de trabajo que ha sido formalmente desarrollado y acordado, y que puede ser cambiado sólo por medio de cambios en los procedimientos de control. Un producto de Trabajo del documento Base puede ser el origen de futuros desarrollos.

Customer (cliente). Cualquier persona u organización que especifica y acepta los entregables del proyecto. EL cliente puede ser interno o externo a la jerarquía del proyecto y puede o no ser el usuario final del producto software. No hay intrínsecamente ninguna relación económica entre el cliente y el desarrollador.

Project Agreement (Acuerdo de Proyecto). Un documento o conjunto de documentos acordados por las autoridades designadas para el proyecto y el cliente. Los documentos en un Acuerdo de Proyecto pueden incluir parte o todos de los siguientes documentos: un contrato, una sentencia de trabajo, especificaciones de ingeniería de sistema, especificaciones funcionales, el plan para la gestión de proyectos software, un plan de negocios, o un gráfico de proyecto.

Project deliverables ( Entregables del Proyecto). El(los) producto(s) del Trabajo que eran entregados al cliente. Las cantidades, fechas y lugares de entrega son especificados en los

acuerdos del proyecto.

Project Function (Funciones del Proyecto). Una actividad que abarca la duración entera de un proyecto software. Ejemplos de funciones de proyectos son gestión del proyecto, gestión de la configuración, aseguramiento de calidad y verificación y validación.

Review (Revisión). Una reunión en la cual un producto de trabajo o un conjunto de productos de trabajo se presenta al personal del proyecto, a los gestores, a los usuarios, a los clientes o a otros partes interesadas en comentarlo(s) o aprobarlo(s).

Software project (Proyecto Software). El conjunto de todas las funciones de proyectos, actividades y tareas ( técnicas y de gestión), requeridas para satisfacer los términos y las condiciones de los acuerdos del Proyecto. Un proyecto software puede estar auto contenido o puede ser parte de un proyecto mayor. Un proyecto software puede abarcar una porción del ciclo de vida de un producto software.

Software project management (Gestión de Proyecto Software). El proceso de planificar, organizar, gestionar la plantilla, controlar, gestionar y conducir un proyecto software.

Software project management plan (Plan para la Gestión de Proyectos Software).

El documento que dirige la gestión de un proyecto software. Un plan para la gestión de proyectos software define las funciones técnicas y de gestión de proyectos, actividades y tareas necesarias para satisfacer los requisitos de un proyecto software, tal como se define en los acuerdos de proyectos.

SPMP(PGPS). Plan para la gestión de proyectos software.

Task (Tarea). La unidad más pequeña de trabajo sometida a la responsabilidad del proyecto. Una tarea es una asignación de trabajo bien definida para uno o más miembros del proyecto. La especificación del trabajo que debe ser completado está descrito en un paquete de trabajo. Las tareas relacionadas son normalmente agrupadas para formar actividades.

Work Package (Paquete de Trabajo). Una especificación para el trabajo que debe ser completada para finalizar una actividad o una tarea. Un paquete de trabajo define el (los) producto(s) de trabajo, los requisitos de personal, la duración esperada, los recursos a ser usadas, los criterios de aceptación de los productos de trabajo, el nombre de las personas responsables y cualquier consideración especial para el trabajo.

Work Product (Producto de Trabajo). Cualquier elemento tangible que resulta de una función de proyecto, actividad o tarea. Ejemplos de producto de trabajo incluyen requisitos de los clientes, plan del proyecto, especificaciones funcionales, documentos de diseño, código fuente y objeto, manual de usuario, instrucciones de instalación, planes de pruebas, procedimientos de mantenimiento, tiempos para la reuniones, agendas, presupuestos, e informes de problemas. Algunos subconjuntos de productos de trabajo deberían formar el conjunto de entregables del proyecto.

Plan para la Gestión de Proyectos Software

Elementos deberían ser ordenados y descompuestos en secciones y subsecciones según la siguiente tabla:

Página de Título

Hoja de Revisión

Prefacio

Tabla de Contenidos

Lista de Figuras

Lista de Tablas

1. Introducción.

1.1.Visión General del proyecto.

1.2.Productos Finales.

1.3.Evolución del Plan de Proyecto.

1.4.Documentos de Referencia.

1.5.Definiciones y Acrónimos.

2. Organización del Proyecto.

2.1.Modelos de Procesos.

2.2.Estructura Organizativa.

2.3.Fronteras e interfaces organizativas.

2.4. Responsabilidades.

3. Procesos de Gestión.

3.1.Objetivos y prioridades de Gestión.

3.2.Suposiciones, dependencias y restricciones.

3.3.Gestión de Riesgos.

3.4.Mecanismos de supervisión y control.

3.5.Plan de Personal.

4. Proceso Técnico

4.1.Metodologías, Técnicas y Herramientas.

4.2.Documentación Software.

4.3.Funciones de Apoyo al proyecto.

5. Plan de Desarrollo.

5.1.Paquetes de Trabajo.

5.2. Dependencias.

5.3. Recursos.

5.4.Presupuesto y distribución de recursos.

5.5. Calendario.

Componentes adicionales

Índice

Apéndices.

Las Secciones y subsecciones se presentan a continuación. Cada versión del plan de Gestión de Proyecto Software basada en este estándar debería contener un título y una nota de la versión para identificar unívocamente al documento. La información de la revisión puede incluir el nombre del proyecto, número de versión del plan, fecha o versión, firmas de aprobación o aceptación, una lista de las páginas que han sido cambiadas en la versión actual del plan y una lista con las fechas de las revisiones de anteriores versiones del plan.

El prefacio de un PGPS basado en este estándar debería describir el propósito, indicando el alcance de las actividades, e identificar la intención y las personas a las que está dirigida este plan. También sería recomendable incluir una tabla de contenidos y una lista de figuras presentes en el documento para la mejor localización de cada uno de ellos.

1. Introducción

1.1.Visión General del Proyecto.

Esta subsección del PGPS debería ofrecer un resumen conciso de los objetivos del proyecto, los productos a ser desarrollados, actividades de trabajo principales, productos de trabajo principales, hitos principales, recursos requeridos, y una agenda principal del contenido y presupuesto. La visión general del proyecto debería también describir apropiadamente las relaciones entre éste y otros proyectos. Esta visión no debería ser construida como una sentencia oficial de los requerimientos del proyecto. Las referencias a las especificaciones de requisitos software deberían ser incluidas en la sección de referencia.

1.2.Entregables del Proyecto.

Esta subsección del PGPS debería listar todos los términos que deben ser desarrollados para el cliente, las fechas de entrega, lugares de entrega y cantidades requeridas para satisfacer los términos de los acuerdos del proyecto. La lista de productos entregables no debería ser construida como una lista de sentencias oficiales de los requerimientos del proyecto.

1.3.Evolución del PGPS.

Esta subsección del PGPS debería especificar los planes para llevar a cabo tanto las actualizaciones planificadas del plan, como las no planificadas del PGPS. Esta subsección debería especificar los mecanismos utilizados para localizar las versiones iniciales del plan bajo controles de carga y consecuentes controles del PGPS.

1.4.Material de Referencia.

Esta subsección del PGPS debería ofrecer una lista completa de todo los documentos y otras fuentes de información referenciadas en el PGPS. Cada documento debería ser identificado por un título, número de informe, autor y organización que lo publicó. Otras fuentes de información tales como ficheros electrónicos, deberían ser identificados de una manera no ambigua usando identificadores, tales como el número de versión y la fecha de su publicación. Cualquier desviación de los estándares referenciados o políticas debería ser identificado y aportado las correspondientes justificaciones.

1.5.Definiciones

...