norma ieee 1058

AUDITORIA INFORMATICA
NORMA IEEE 1058.1
COBOS LOMELI MANUEL ALEJANDRO
205305635
LÓPEZ RIVERA JOSÉ MIGUEL
204203042
HERNÁNDE HERNÁNDEZ AARON
204203000
PROF. MARGARITA MARÍA DE LOURDES SANCHEZ
GRUPOR CSI81
NORMA IEEE 1058.1
Propósito
Este estándar especifica el formato y contenidos de los planes para la gestión de proyectos
software. No especifica las técnicas exactas que pueden ser usadas en el desarrollo de los
planes de proyectos, ni ofrece ejemplos de los planes de gestión de proyectos. Cada
organización que usa este estándar debería desarrollar un conjunto de prácticas y
procedimientos para proporcionar una guía detallada para la preparación y actualización de los
planes de gestión de los proyectos software basada en este estándar. Estas prácticas
detalladas y procedimientos deberían tener en cuenta los factores del entorno,
organizacionales y políticos que pueden influenciar en la aplicación de este estándar.
No todos los proyectos de software se ocupan del desarrollo de código fuente para un nuevo
producto software. Algunos proyectos de software consisten en un estudio de viabilidad y
definición de requisitos del producto. Otros proyectos concluyen con la finalización del diseño
del producto software, y algunos proyectos se refieren a modificaciones importantes a los
productos software existente. Esta norma es aplicable a todo tipo de proyectos de software; la
aplicación no está limitada a los proyectos que desarrollan versiones operativas de nuevos
productos. La aplicación de esta norma no está limitada por el tamaño del proyecto. Los
proyectos pequeños pueden requerir menos formalidad que en la planificación de grandes
proyectos, pero todos los componentes de esta norma deben ser abordados por cada proyecto
de software.
Los proyectos de software son a veces partes componentes de los proyectos más grandes. En
estos casos, el Plan de Gestión de Proyecto de Software puede ser un componente separado
de un plan mayor o puede ser fusionado en el plan a nivel de sistema de gestión de proyectos.
A quién va dirigido
Este estándar está destinado a aquellos gestores de proyectos software y a otro personal que
prepare o actualice planes de proyectos y estén adheridos a esos planes.
Historia
La solicitud de autorización de proyectos para el desarrollo de esta norma fue aprobada por la
Junta de normas IEEE el 13 de diciembre de 1984. La modificación de la solicitud de
autorización fue aprobada en Septiembre de 1996. Se celebraron diez reuniones dentro de los
Estados Unidos entre Septiembre de 1984 y Septiembre de 1986.
Alcance
Este estándar prescribe el formato y contenido del Plan para la Gestión de Proyectos Software
-PGPS-. Un Plan para la Gestión de un Proyecto Software es el documento de control para
gestionar un proyecto software; define los procesos técnicos y de gestión necesarios para
satisfacer los requisitos del proyecto.
Este estándar puede ser aplicado a todos los tipos de proyectos software. El uso de este
estándar no está limitado por el tamaño, complejidad o criticidad del producto software. Este
estándar es aplicable a todas las clases de software, incluyendo firmware, código de sistemas
empotrados, matrices lógicas programables y software en Silicio. Este estándar puede ser
aplicado a cualquiera de los segmentos del ciclo de vida de un producto software.
Este estándar identifica el conjunto mínimo de elementos que debería aparecer en todos los
planes para la gestión de proyectos software. A fin de seguir el estándar los planes para la
gestión de proyectos software deben ajustarse al formato especificado en este estándar. De
todos modos, los usuarios de este estándar pueden incorporar otros elementos añadiendo
secciones o subsecciones adicionales a sus planes para la gestión de proyectos software. En
cualquier caso el esquema numerado de las secciones y subsecciones requeridas debe
ajustarse al formato especificado en este estándar. Varias secciones y subsecciones de un plan
para la gestión de proyectos software pueden ser incluidas en el plan bien por incorporación
directa o bien por referencia a otros planes y documentos.
Este estándar para planes para la gestión de proyectos software incorpora y abarca el plan
para el desarrollo software descrito en el Estándar ANSI/IEEE 729-1983[1] y en el ANSI/IEEE
730-1984 [2]
Plan para la Gestión de Proyectos Software
Las personas u organizaciones responsables de un proyecto software también deberían ser
responsables del Plan para la gestión de dicho proyecto. Esta sección del estándar describe
cada uno de los elementos esenciales para la planificación de la Gestión de un proyecto
Software. Estos 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.
Este es un orden propuesto, que no implica que haya que seguirlo literalmente. Las secciones y
subsecciones de un plan de gestión software deben ser incluidas aquí específicamente o bien
haciendo referencias a los documentos que sean necesarios.
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.
Visión General del Proyecto.
Esta subsección del PGPS incluirá un resumen conciso de los objetivos del proyecto, el
producto a entregar, las principales actividades de trabajo, los principales productos de
trabajo, los principales hitos, los recursos necesarios, y el calendario y el presupuesto maestro.
La descripción del proyecto incluirá asimismo la relación de este proyecto a otros proyectos,
según corresponda. Esta descripción, no se interpretará como una especificación oficial de los
requisitos del producto. La referencia a la especificación de los requisitos del software se
presentará en este tramo de la PGPS.
Entregables del Proyecto.
Esta subsección del PGPS incluirá en la lista todos los ítems que se entrega al cliente, las fechas
de entrega, los lugares de entrega, y las cantidades necesarias para satisfacer los términos del
acuerdo de proyecto. Esta lista de entregables del proyecto, no se interpretará como una
declaración oficial de los requisitos del proyecto.
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. Este apartado se
especificará también los mecanismos utilizados para colocar la versión inicial del PGPS bajo el
cambio de control y para controlar los cambios posteriores a la SPMP.
Material de Referencia.
Esta subsección del PGPS debería ofrecer una lista completa de todos 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 identificadas 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.
Definiciones y Acrónimos.
Esta subsección del PGPS debería definir o proveer referencias a los términos y acrónimos
necesarios para comprender adecuadamente el PGPS.
Organización del Proyecto
Modelo de Procesos.
Esta subsección del PGPS debería definir las relaciones entre las funciones principales del
proyecto y las actividades, especificando el calendario de los hitos principales, documentos
bases, revisiones, productos de trabajo, productos entregables, y el fin del proyecto. El modelo
de procesos puede ser descrito utilizando una combinación de notaciones textuales y gráficas.
El modelo de proceso puede incluir las actividades de iniciación y finalización del proyecto.
Estructura Organizativa
Esta subsección del PGPS debería describir la estructura para la gestión interna del proyecto.
Dispositivos gráficos tales como gráficos de organizaciones jerárquicas o diagramas de
matrices pueden ser usados para representar las líneas de autoridad, responsabilidad y
comunicación dentro del proyecto.
Límites e Interfaces organizativos
Esta subsección del PGPS debería describir los límites administrativos y de gestión entre el
proyecto y cada una de las siguientes entidades: organización que se encarga del proyecto, la
organización cliente, organizaciones subcontratadas o cualquier otra entidad organizativa que
interaccione con el proyecto. Además, las interfaces de administración y gestión de las
funciones de soporte del proyecto, tales como la gestión de configuración, control de calidad y
verificación y validación se especificarán en este apartado.
Responsabilidades
Esta subsección del PSMP deberá determinar y precisar la naturaleza de cada función
importante proyecto y actividad, e identificar a los individuos que son responsables de las
funciones y actividades. Una matriz de funciones y actividades versus las personas
responsables pueden ser utilizadas para representar las responsabilidades del proyecto.
Procesos de Gestión
Esta sección de la PGPS especificará objetivos y prioridades de gestión; suposiciones del
proyecto, las dependencias y las limitaciones, técnicas de gestión de riesgos, la supervisión y el
control de los mecanismos que se utilizarán, y el plan de personal.
Objetivos y Prioridades de gestión.
Esta subsección del PGPS dará cuenta de la filosofía, objetivos y prioridades para la gestión de
las actividades realizadas durante el proyecto. Los temas que se especifican pueden incluir,
pero no se limitan a, la frecuencia y los mecanismos para la generación de informes que se
utilizarán; la prioridad de los requisitos, el programa y presupuesto para este proyecto, los
procedimientos de gestión de riesgos que ha de seguirse, y una declaración de intenciones
para adquirir, modificar, o utilizar el software existente
Supuestos, dependencias y restricciones
Esta subsección del PGPS debería afirmar los supuestos en los que está basado el proyecto, los
acontecimientos externos de los que el proyecto depende y las restricciones que bajo las
cuales el proyecto va a ser guiado.
Gestión de Riesgos.
Esta subsección del PGPS debería identificar y valorar los factores de riesgos asociados al
proyecto. Esta subsección también debería prescribir mecanismos para el rastreo de varios
factores de riesgo e implementar planes de contingencia. Los factores de riesgos que deberían
ser considerados incluyen riesgos contractuales, tecnológicos, riesgos debidos al tamaño y
complejidad del proyecto, riesgos en la adquisición y retención del personal, y riesgos en lograr
que el cliente acepte el producto.
Mecanismos de supervisión y control
Esta subsección del PGPS debería definir los mecanismos para generar informes, los formatos
de los informes, flujos de información, mecanismos de auditoría y revisión, y otras
herramientas y técnicas que pueden ser usadas para controlar las adiciones al PGPS.
EL control del proyecto debería ocurrir en el nivel de paquetes de trabajo. La relación entre los
mecanismos para controlar el proyecto y las funciones de soporte deberían ser trazadas en
este nivel.
Plan del Personal
Esta sección del PGPS especificará el número y tipo de personal necesario para llevar a cabo el
proyecto. Los niveles de cualificación requeridos, los tiempos de comienzo, la duración de la
necesidad, y los métodos de obtención, la formación, retención y eliminación gradual del
personal se especificarán
Procesos Técnicos
Esta sección del PGPS deberá especificar los métodos técnicos, herramientas y técnicas
analíticas que se utilizarán en el proyecto. Además, el plan para la documentación de software
se especifica, y los planes para las funciones de soporte del proyecto, como garantía de la
calidad, gestión de configuración, la verificación y validación puede ser especificado
Métodos, herramientas y técnicas
Esta Subsección de la PGPSdeberá especificar el/los sistema informático(s), metodología/s de
desarrollo, la/s estructura del equipo, el/los lenguaje de programación, y otras anotaciones,
herramientas, técnicas y métodos que deben utilizarse para especificar, diseñar, construir,
probar, integrar, documentar, modificar o mantener o ambos (según corresponda) las
prestaciones del proyecto. Además, las normas técnicas, políticas y procedimientos que rigen
el desarrollo o la modificación o ambos de los productos de trabajo y las prestaciones del
proyecto se incluirán, ya sea directamente o por referencia a otros documentos.
Documentación del Software
Esta subsección del PGPS debería contener o referenciar el plan de documentación del
proyecto software. EL plan del documento debería especificar los requisitos de
documentación, los hitos, líneas base, revisiones y la finalización de la documentación del
software. El plan de documentación también puede contener una guía de estilo, convenciones
en la nomenclatura y formatos del documento. El plan de documentación podría incluir un
resumen de la agenda y los recursos necesarios para el esfuerzo de la documentación. El
Estándar ANSI/IEEE 829-1983 “Standard for Software Test Documentation” ofrece el estándar
para la documentación de pruebas del software.
Funciones de soporte a proyectos
Esta subsección del PGPS debería contener directamente o por referencia los planes para las
funciones de soporte para el proyecto software. Estas funciones pueden incluir, pero no están
limitadas a, gestión de la configuración, aseguramiento de la calidad del software, y
verificación y validación. Los planes para las funciones de soporte al proyecto deberán ser
desarrollados a un nivel de detalles consistente con las otras secciones del PGPS. En particular,
se deben especificar las responsabilidades, requerimientos de recursos, agendas y
herramientas para cada una de las funciones de soporte al proyecto. La naturaleza y tipo de las
funciones de soporte al proyecto variarán de un proyecto a otro; de todos modos, la ausencia
del aseguramiento de calidad software, gestión de la configuración o plan de verificación y
validación debe ser explícitamente justificado en los planes de los proyectos que no los
incluyan.
Paquetes de trabajo, Calendario y Presupuestos
Esta sección del PGPS debería especificar los paquetes de trabajo, identificar las relaciones de
dependencias entre ellos, declarar los requerimientos de recursos, facilitar la localización de
herramientas, y recursos para los paquetes de trabajo y establecer la agenda del proyecto.
Paquetes de trabajo
Esta subsección del PGPS debería especificar los paquetes de trabajo para las tareas y
actividades que deben completarse en orden para satisfacer los acuerdos del proyecto.
Cada paquete de trabajo debería ser unívocamente identificado; la identificación puede estar
basada en un esquema numerado y títulos descriptivos. Se puede usar un diagrama que
describa la división de las actividades en sub-actividades y tareas (estructura de desglose) para
describir las relaciones jerárquicas entre los distintos paquetes de trabajo.
Dependencias
Esta subsección del PGPS debería especificar las relaciones de orden entre los distintos
paquetes de trabajo para reflejar de alguna forma las interdependencias entre ellos y la
dependencia de acontecimientos externos al proyecto. Se pueden usar técnicas tales como las
listas de dependencia, redes de actividades, y método de camino crítico para describir las
dependencias entre los distintos paquetes de trabajo.
Requerimientos de recursos
Esta subsección del PGPS debería proporcionar, en función del tiempo, estimaciones del total
de los recursos necesarios para completar el PGPS. EL número y tipo del personal, tiempo de
computación, software de soporte, ordenadores, facilidades de laboratorios y oficinas, viajes, y
requerimientos de mantenimiento para los recursos de proyectos deberían ser especificados.
Presupuesto y distribución de recursos
Esta subsección del PGPS debería especificar la localización de las herramientas y recursos de
las distintas funciones del proyecto, actividades y tareas. Se puede usar un esquema de
ganancia de valores para localizar herramientas y recursos, y para llevar un control del gasto y
de la utilización de los recursos.
Calendario o Agenda
Esta subsección del PGPS debería ofrecer una agenda para que las distintas funciones,
actividades y tareas del proyecto fuesen desarrolladas en un determinado orden y se
consiguiesen los plazos previstos. Las agendas pueden ser expresadas bien en forma de
calendario relativo, bien en incrementos con respecto a fechas de hitos claves del proyecto.
Componentes Adicionales.
A veces se puede necesitar ciertos componentes adicionales. Estos pueden estar incluidos en
secciones adicionales o en subsecciones del PGPS. De todas formas el esquema numerado para
las secciones y subsecciones requeridas debería parecerse al formato especificado en este
documento. Ítems adicionales de importancia en cualquier proyecto pueden ser incluidos
como planes para la gestión de subcontratación, planes de seguridad, planes independientes
de verificación y validación, planes de entrenamiento, planes de adquisición de hardware,
planes de servicios, planes de instalación, planes de conversión de datos, planes de transición
de sistemas, o planes de mantenimiento. Si fuese necesario, se debería desarrollar
componentes adicionales en un formato y nivel de detalles de acuerdo con las secciones
requeridas en el PGPS
Índice
Es opcional incluir un índice con los términos y acrónimos utilizados en el proyecto pero es
bastante recomendable para mejorar la usabilidad del PGPS.
Apéndices
Se pueden incluir apéndices, bien directamente, o bien por referencias para proporcionar
soporte a los detalles que pudieran hacer falta.