1 Plan de Gestión del proyecto IEEE standard for software project management plansLuis Felipe Ramirez

2 Estándar Es una especificación que regula la realización de ciertos procesos o la fabricación de componentes para garantizar la interoperabilidad.

3 IEEE (The Institute of Electrical and Electronics Engineers )Es una organización profesional sin ánimo de lucro de más de miembros individuales en alrededor de 175 paises. Asociación técnico-profesional mundial dedicada a la estandarización, entre otras cosas. Fundada 1884

4

5 Pagina de Titulo Debe contener titulo del Proyecto FechaIdentificador único (versión, o numero del borrador) Identificación de la empresa que lo hace

6 Pagina de Firmas Las firmas (el espacio) para las personas responsables de aprobar el proyecto Position Name Signature Date Director, The Institute for Government Informantion Professionals Fram Engineer ROCIT Project Manager Martin Malo

7 Historial Nombre del Proyecto Numero versión del PlanFecha de realización Lista de las paginas que fueron modificadas para la versión actual Breve resumen de la naturaleza de los cambios en este proyecto Lista de versiones y fechas de versiones anteriores del plan

8 Prefacio Se presenta el documento. Alcance, contexto y audiencia del SPMP (no del proyecto). La audiencia del SPMP incluye tanto a la gerencia como a los desarrolladores. Debe explicarse para que se está haciendo este documento y que utilidad e importancia tiene.

9 Listas Tabla de Contenidos Lista de Figuras Lista de Tablas

10 1. Visión General Del Proyecto (Descripción)1.1 Resumen del proyecto 1.1.1 Propósito, Alcance y objetivos a) Propósito: Definir el por qué y para qué del proyecto. b) Alcance: Indica las posibilidades de aplicación real de los resultados del proyecto, que se va a hacer y que no. c) Objetivos: Son los fines que se buscan con el desarrollo del proyecto. Lo que se quiere hacer, lograr, conocer o analizar. Tambien una referencia a la declaración oficial de requisitos del producto

11 1. Visión General Del Proyecto (Descripción)1.1 Resumen del proyecto 1.1.2 Suposiciones y restricciones 1.1.3 Entregables del Proyecto Debe hacer una lista de los productos de trabajo que serán entregados al cliente, sus fechas de entrega, sitios de entrega y las cantidades requeridas para satisfacer los términos del acuerdo de proyecto. Debe especificarse el medio de entrega e instrucciones necesarias para su manejo. Suposiciones: • Lo que suponemos para poder llevar a cabo el proyecto, aquello que consideramos cierto o falso, Ejemplo: Los establecimientos donde la herramienta será instalada posee los recursos necesarios mínimos para el buen desempeño de la ésta. Restricciones: • En tiempo, presupuesto, recursos, reutilización de software, software del cliente que debe ser incorporado, tecnología a usar, e interfaces de conexión con otros productos, fechas de entrega...

12 1. Visión General Del Proyecto (Descripción)1.1 Resumen del proyecto 1.1.4 Resumen de presupuesto y cronograma. Enunciar las principales actividades que se deben llevar a cabo para el desarrollo del producto de software junto con el presupuesto que se ha planeado para cada actividad y el tiempo que se tiene estimado para su cumplimento. Es algo conciso, sin extenderse y detallar mucho puesto que las actividades se harán más explícitas en el Plan de Trabajo.

13 1. Visión General Del Proyecto (Descripción)1.2 Evolución del Plan Planificar el cómo se va a manejar los cambios al SPMP. Los cambios son planeados en cronograma y adiciones extraordinarias (que no están en el cronograma). Cada cambio debe especificar su responsable dentro del plan. Especificar cuál es el manejo para la versión inicial del SPMP y sus cambios subsecuentes.. No olvidar en la planificación especificar que, como, quien y cuando

14 2. Referencias Lista de documentos y otras fuentes de información referenciadas en el documento Cada documento debe ser identificado Cada documento debe ser identificado por títulos, numero de reporte, fecha, autor, link de ser necesario y organización que lo publica.

15 3. Definiciones Definir o proveer referencias a los documentos que contengan la definición de todos los términos y acrónimos requeridos para el apropiado entendimiento del SPMP Incluir definición de términos del negocio para que cualquier persona pueda entender el SPMP y el proyecto que se va a realizar, debe proveer todas las definiciones para que el documento sea entendible para el cliente y para todo el equipo de trabajo.

16 4. Organización Del Proyecto4.1 Interfaces externas Relación con otras entidades (proveedores, contratistas). Límites organizacionales entre el proyecto y entidades externas. Organizaciones Padres Organizaciones Adquiridas Organizaciones Subcontratadas Otras Representaciones: Caracteres organizacionales Diagramas organización padre (aquella a la que puede pertenecer la organización que actualmente trabaja en el proyecto), la organización cliente, organizaciones contratistas, y otras entidades que interactúen con el proyecto. Organigramas.. La idea es describir a los agentes externos y la relación que se va a manejar con ellos.

17 4. Organización Del Proyecto4.2 Estructura interna Describirá la estructura interna de la organización encargada del proyecto describir como se gestionará internamente el equipo, formas de comunicación, toma de decisiones, organización…

18 4. Organización Del Proyecto4.3 Roles y responsabilidades Funciones y actividades principales. Matriz de funciones/actividades contra responsables Identificar y declarar la naturaleza de cada actividad de trabajo y soporte de procesos. Identificar las unidades organizacionales que son responsables de esos procesos y actividades. Actividades del trabajo y soporte de procesos vs Unidades organizacionales.

19 5. Plan De Procesos Administrativos5.1 Plan de arranque 5.1.1 Plan de estimación Especifica el costo y calendario para conducir el proyecto 5.1.2 Plan de personal Especifica el equipo de trabajo para cada nivel del proyecto. Incluye que fases y tipos de habilidades debe tener cada persona, la necesidad en la cual se empleará, así como la duración de la misma. 5. especifica la administración 5.1.1 Se debe utilizar métodos, herramientas y técnicas, para poder estimar el cronograma, los costos del proyecto y requerimientos de recursos. Se debe escoger que método se va a utilizar para poder estimar el costo del SW, puede ser por líneas de código, puntos de función, puntos objeto, Cocomo, etc... , y utilizarlo para realizar la estimación; además se debe realizar la calendarización estimada, ésta se puede representar por medio de un diagrama GANNT o PERT. 5.1.2 Es importante aclarar si el personal es interno o si este es de contratación externa.

20 5. Plan De Procesos Administrativos5.1 Plan de arranque 5.1.3 Plan de adquisición de recursos Especifica el plan de adquisición de recursos para que el personal pueda realizar sus tareas. Incluye el proceso de adquisición, así como los diferentes responsables para llevar a cabo ésto. El plan debería especificar en que actividades del cronograma se requerirá adquisición de recursos. Los recursos pueden ser: Equipo, H.W y S.W, entrenamiento, contratos de prestación de servicios, transporte etc.

21 5. Plan De Procesos Administrativos5.1 Plan de arranque 5.1.4 Plan de entrenamiento al personal Especificar el entrenamiento necesario para asegurar que los niveles de habilidad requeridos sean alcanzados por las personas que desempeñan los diferentes roles en el proyecto, asegurando que éste cumpla su objetivo satisfactoriamente. Se debe especificar cuando se realizará el entrenamiento, quién lo realizará, quien lo recibirá, en que consistirá. Debe describirse clara y puntualmente como se manejaran los entrenamientos en el proyecto.

22 5. Plan De Procesos Administrativos5.2 Plan de trabajo 5.2.1 Actividades de trabajo Especificar todas las actividades que se realizarán en el proyecto Deben ser descompuestas a un nivel que expongan todos los factores de riesgo y que permita estimar la necesidad de recursos y duración de cada actividad. Por cada actividad se describe en que consiste, los riesgos que este llega a presentar, los recursos necesarios para que la actividad se realice, los entregables y el tiempo estimado de duración.

23 5. Plan De Procesos Administrativos5.2 Plan de trabajo 5.2.2 Cronograma Entre las actividades y un cronograma Cualquier restricción en el cronograma de trabajo causada por factores externos al proyecto debería ser indicada en éste. Son muy usados los diagramas de PERT y GANTT.

24 5. Plan De Procesos Administrativos5.2 Plan de trabajo 5.2.3 Asignación de recursos Por cada actividad definida en el numeral 2.5.1, se debe especificar todos los recursos que ésta necesita para poder desarrollarse (recursos de personal, de operación, de administración...)

25 5. Plan De Procesos Administrativos5.2 Plan de trabajo 5.2.4 Asignación de presupuesto. Resumen detallado sobre la partida presupuestal para cada una de las actividades más importantes para el desarrollo del proyecto. costo estimado para la realización de ésta (costos para reuniones, recursos computacionales, herramientas de software, pruebas, costos administrativos, de personal… )

26 5. Plan De Procesos Administrativos5.3 Plan de control 5.3.1 Plan de control de requerimientos Si existe una modificación en uno o en varios requerimientos se debe tener mecanismos para controlar, manejar, reportar y medir estos. Se debe tener especificados los planes que mitiguen los cambios en el cronograma, presupuesto, recursos y los factores de riesgo Existen cambios después del SRS Se discuten estos cambios si son (Factibles, Permisibles) Actualiza SRS Los mecanismos más usados en esta fase son: Realizar prototipos, trazabilidad, hacer análisis de impacto y llevar siempre acabo revisiones.

27 5. Plan De Procesos Administrativos5.3 Plan de control 5.3.2 Plan de control de cronograma Medir el progreso del trabajo completado Comparar el progreso de lo actual con lo completado Implementar acciones correctivas si hay retrasos Cuales acciones se deben tomar Políticas Criterios de aceptación Herramientas

28 5. Plan De Procesos Administrativos5.3 Plan de control 5.3.3 Plan de control de presupuesto Se maneja presupuesto en el proyecto Medir el costo del trabajo completado Comparar costos de lo planeado con lo actual Implantar acciones correctivas Al ser un proyecto académico este plan es algo irrelevante ya que no se manejan grandes sumas y en sí no existe un presupuesto como tal. Los pequeños gastos que se tienen pueden ser cubiertos fácilmente por los integrantes del grupo.

29 5. Plan De Procesos Administrativos5.3 Plan de control 5.3.4 Plan de control de calidad Calidad de los procesos de trabajo y en la calidad de los productos Verificación y validación Juntas de revisión Auditorias Evaluación de los procesos Se debe especificar como se realizará el control de calidad, quién lo realizará y en que consistirá.

30 5. Plan De Procesos Administrativos5.3 Plan de control 5.3.5 Plan control de reportes Se definen los formatos de los reportes Flujos de información que se van a usar en la comunicación del estado de los requerimientos, calendarización, presupuestos, calidad y otros Especificar técnicas y métodos de comunicación. Aquí se debe especificar el tipo de comunicación que los integrantes del grupo tienen entre ellos y con entidades externas. Lo mismo que la frecuencia con que las realizan.

31 5. Plan De Procesos Administrativos5.3 Plan de control 5.3.6 Plan de Control de Recolección de Métricas Recolección y almacenamiento de métricas Definir frecuencia de recolección Validación, análisis y reportes especificar los métodos, herramientas y técnicas a ser usadas en la recolección y retención de métricas de proyecto.

32 5. Plan De Procesos Administrativos5.4 Plan de administración de riesgos Identificar, analizar y priorizar los factores de riesgo del proyecto Describir los planes de contingencia Definir los métodos para el seguimiento, evaluación de cambios, responsables. Planes para medir los factores de riesgo iniciales, mitigación a través del ciclo de vida definido en el proyecto. Establecer los procedimientos para la comunicación del estado de los riesgos entre todos lo involucrados Factores de Riesgo Riegos en la relación de cliente - proveedor "nosotros" Riesgos contractuales Riesgos tecnológicos Riesgos a por causas en el tamaño y complejidad del producto Riesgos en el desarrollo y los ambientes donde se va instalar Riesgos con el personal contratado Niveles de habilidad y retención Riesgos en los en calendario por retrasos y sobre costos en los presupuestos Riesgos con respecto a las metas adquiridas con respecto a las logradas en el producto

33 5. Plan De Procesos Administrativos5.5 Plan de Terminación del Proyecto Plan de reasignación de empleados Plan de para archivar los materiales del proyecto Planes de informes postmortem  del personal involucrado en el proyecto Preparación de un reporte final que incluye las lecciones aprendidas y un análisis de los objetivos logrados. Determina los planes necesarios para asegurar ordenadamente la finalización del proyecto de software.

34 6. Plan De Procesos Técnicos6.1 Modelo de Procesos Se especifica todas las actividades para cada proceso de apoyo del proyecto para cada actividad se debe: incluir los flujos de información, los productos de trabajo, el tiempo estimado para la realización y la revisión, y cronograma Relación entre actividades Puede escogerse un modelo de ciclo de vida que se adapte al proyecto, y a partir de éste definir todas las actividades que se deben realizar, los entregables, productos…

35 6. Plan De Procesos Técnicos6.2 Métodos, herramientas y técnicas Especificar: Desarrollo de metodologías. Lenguajes de programación. Otras notaciones. Herramientas y técnicas. Diseño. Construcción. Pruebas. Integración. Documentos. Desarrollo. Modificación. Otras especificaciones. Estándares técnicos . Políticas. Procedimientos gobernados por el desarrollador. Modificación de productos de trabajo.

36 6. Plan De Procesos Técnicos6.3 Plan de infraestructura Especificar: Ensamble y mantenimiento del desarrollo del entorno. Hardware. Sistema Operativo. Red. Software. Políticas. Procedimientos. Estándares. Facilidades requeridas para conducir el software del proyecto. Los recursos pueden incluir: Estaciones de trabajo. LAN’s. Herramientas de software para: Análisis. Diseño. Implementación. Prueba. Escrituras. Espacios de oficina. Provisiones para seguridad física. Personal administrativo En este campo, se describe detalladamente el ambiente de trabajo para la realización del proyecto. se identifican los entornos de desarrollo y pruebas, el sistema operativo, las redes de comunicación, y en general los aspectos físicos y tangibles

37 6. Plan De Procesos Técnicos6.4 Plan de aceptación del producto Algunas especificaciones son: Procesos técnicos. Métodos. Herramientas requeridas para la aceptación del producto. Algunos métodos son: Prueba. Demostración. Análisis. Inspección. Especifica el plan para adquirir la aceptación de los productos desarrollables. referencia a las actividades, metodologías, herramientas y todo aquello que sea indispensable para lograr la aceptación de los entregables de este proyecto de software por parte del cliente.

38 7. Plan De Procesos De Apoyo7.1 El plan de la gerencia de la configuración Especifica los métodos que serán utilizados para proporcionar la identificación de la configuración, el control, la contabilidad del estado, la evaluación, y la gerencia del lanzamiento. Es un planeamiento de como se evaluará y se identificarán todas las versiones nuevas que resultaron del trabajo, se lleva un seguimiento claro de los cambios Vs. lo que se tenía planeado al comienzo del proyecto. Se debe aclarar quien lo realizará, como se hará y cuando.

39 7. Plan De Procesos De Apoyo7.2 Plan de verificación y validación Definir las actividades y tareas con las cuales se quiere comprobar el funcionamiento y los logros alcanzados del proyecto. Especificar el alcance del proyecto y las técnicas de comprobación respectivas. Especifica el alcance, las herramientas, las técnicas, y las responsabilidades de las actividades del trabajo de la verificación y de la validación.

40 7. Plan De Procesos De Apoyo7.3 Plan de documentación Especifica las directrices que rigen la documentación de los productos no entregables y entregables del trabajo. Algunos documentos pueden incluir código de la implementación del software, un manual de usuario u otros artículos específicos, además debe definirse la fecha de entrega, las revisiones realizadas y el responsable de cada entregable. Los productos no entregables del trabajo incluyen especificaciones de requisitos, documentación del diseño, matrices del traceability, planes de prueba, minutos de reunión e informes de revisión. Los productos entregables del trabajo incluyen código de fuente, código de objeto, un manual de usuario, un sistema de ayuda en línea, una habitación de la prueba de la regresión, una biblioteca de la configuración y una herramienta de gerencia de la configuración, teoría de operación, una guía del mantenimiento,

41 7. Plan De Procesos De Apoyo7.4 Plan de aseguramiento de calidad Especificar los planes para asegurar que el proyecto del software satisfaga las especificación contempladas al inicio del proyecto Se presentan todos los documentos que se tengan sobre los avances y sobre el plan de calidad que se tuvo durante la realización del proyecto. .

42 7. Plan De Procesos De Apoyo7.5 Revisiones y auditorias Especifica el horario, los recursos, y los métodos y los procedimientos que se utilizarán en revisiones e intervenciones del proyecto 7.6 Plan de resolución de problemas Debe contener los recursos, métodos, herramientas, técnicas y procedimientos, utilizados a la hora de hacer reportes, análisis, establecer prioridades y reportes de problemas en los procesos de software. 7.5 Los procedimientos de la garantía de calidad pueden incluir análisis, inspecciones, revisiones, intervenciones, y gravámenes. 7.6 como manejar los problemas

43 7. Plan De Procesos De Apoyo7.7 Plan de manejo de contratistas planes para seleccionar y manejar cualquier subcontratista que pueda contribuir productos del trabajo al proyecto del software. Los criterios para seleccionar subcontratistas y el plan de la gerencia para cada subcontrato. por consiguiente, este debe contener los criterios de selección, administración de riesgos, y todo aquello relevante a los nuevos contratos, que garanticen la mejor forma de llevar a feliz término el desarrollo del proyecto de software. Para ello, hay que llevar un estricto control de los requerimientos del subcontratista, el monitoreo de todas sus actividades, etc.

44 7. Plan De Procesos De Apoyo7.8 Plan de mejoramiento de procesos Se realiza el plan para mejorar los procesos que se puedan mejorar Revisiones periódicas Identificar áreas para mejorar Este plan va ligado con el plan de resolución de problemas.

45 8. Planes Adicionales Especifica los planes adicionales requeridos para satisfacer requisitos del producto y términos contractuales tales que rectifiquen la seguridad, aislamiento Planes de instalación Entrenamiento Integración Transición Mantenimiento Soporte

46 Anexos Los anexos pueden ser incluidos directamente o remitiéndolos a otros documentos para proveer detalles presentados en el SPMP

47 Índice Un índice de palabras o términos usados en el documentoEs opcional pero recomendado para un mayor aprovechamiento del SPMP

48

49 ¿Que es un Plan? 2. m. Intención, proyecto. (RAE)3. m. Modelo sistemático de una actuación pública o privada, que se elabora anticipadamente para dirigirla y encauzarla.(RAE) 4. m. Escrito en que sumariamente se precisan los detalles para realizar una obra. (RAE) Un modelo sistemático que detalla qué tareas se deben llevar a cabo para alcanzar un objetivo (Wikipedia) ¿Qué? ¿Quien? ¿Como? ¿Cuando? ¿Donde? ¿Porque? bitácora.1. m. Mar. Libro en que se apunta el rumbo, velocidad, maniobras y demás accidentes de la navegación. Es donde se va anotando las cosas q pasan, el plan es lo q se desea q pase

50 Errores Comunes No hay plan No planearon todoNo contemplaron bien los riesgos Usan el mismo plan para todos los proyectos Usan el plan que otro hizo El plan es muy alejado de la realidad Planear muchos detalles muy pronto Planear para después alcanzar No aprender de los errores de planeación pasados Copiar si mirar el titulo de donde estoy 7. Ejemplo del carro y las luces, uno sabe el mapa y planea, pero los detalles son las cosas q ve con las luces

51 Tips Un máximo de 20 paginas Mantener las versiones del documentoDefinir quién cambia cosas en el documento Copias de seguridad Lugares de trabajo

52 FAQ ¿Existen algunos puntos donde se hable específicamente del documento y no del proyecto en si? ¿Hay que seguir al pie de la letra el estándar al entregar los informes? ¿Que hay que hacer si uno se desfasa mucho y no cumple la calendarizaciòn que había planeado? ¿Que tipo de medidas de seguridad se debe tener en cuenta en cada una de las etapas de elaboración del proyecto? ¿De que manera se deben solucionar los problemas que surjan entre los integrantes del equipo? ¿Como evitar que el equipo llegue a desintegrarse por una discusión? ¿Que castigo o llamado de atención se debe aplicar a un integrante del equipo q no haya cumplido con la entrega de la parte que le correspondía hacer? ¿Todo el esquema de iniciación de proyectos (análisis, roles, tareas), depende de la magnitud del proyecto o es independiente de tal? ¿Qué es ingeniería de software? ¿Cuál es el punto de plan de administración de proyectos más difícil? Ejemplos de los métodos basal y catedral

53 Bibliografía IEEE standard for software project management plans. IEEE Std Tigris.org Open Source Software Engineering Tools Plantilla SPMP. Pontificia Universidad Javeriana. Ingeniería De Software. Diana Milena Pérez Riveros Mapa Mental SPMP. Ing Luis Carlos Díaz Software Project Management Plan (SPMP) for ROCIT Registration On-line for Canadian IT Professionals for the Institute Prepared by Nerds-R-US Trabajos de la materia Ingenieria de Software de la P.U.J de semestres anteriores. Diccionario de la Real Academia de la Lengua Española Wikipedia Editorial “The Nine Deadly Sins of Project Planning”. Steve McConnell. Revista IEEE SOFTWARE edición September/ O c t o b e r