Departamento de Informática Universidad Técnica Federico Santa María Pauta Plan de Proyecto Profesor: Dr. Marcello Visconti Zamora visconti@inf.utfsm.cl 0 Portadas El documento que se está generando corresponde al plan de proyecto para el desarrollo de un producto de software, dentro de las actividades de la asignatura, por lo tanto, es de vital importancia que el grupo de proyecto separe e identifique dos tipos de portada que se deben incluir en el documento, en el orden que se señala a continuación. 0.1 Portada de la asignatura Debe incluir los siguientes datos como mínimo: nombre del documento, nombre y rol de los integrantes, nombre profesor, ayudante(s) y fecha. 0.2 Portada del proyecto Debe incluir la siguiente información como mínimo: nombre del documento, nombre del proyecto, nombre y logotipo de la Empresa y producto, jefe de proyecto, equipo de desarrollo y fecha. 1 Índice o Tabla de Contenidos Presenta la secuencia lógica de ideas tratadas, facilitando la búsqueda de información específica contendida en el documento. Observación: el punto anterior (Portadas) NO debe ser incluido como parte de la tabla de contenidos 1.1 Lista de figuras Índice de las figuras que se han incluido en el plan. 1.2 Lista de tablas Índice de las tablas que se han incluido en el plan. 2 Introducción Resumen de la visión global del proyecto. Incluye: Origen del tema tratado. Profesor Dr. Marcello Visconti Z. 1
Descripción global del problema a resolver. Enfoque de desarrollo. Descripción global de la solución al problema. 3 Alcances y Propósitos del Documento Establece los objetivos que cubre el documento y la forma en que se resuelven, junto con su importancia y trascendencia, tanto a nivel de las personas involucradas en el proyecto, como los clientes. Es necesario destacar las consecuencias y compromisos que pueden desprenderse del informe. 4 Plan Técnico 4.1 Especificación del Sistema El objetivo de este punto es definir los elementos de un sistema dentro de un contexto global, con el fin de identificar necesidades de información y establecer las bases para el proyecto. Con lo anterior, se propondrán alternativas de solución y se escogerá una, apoyándose en un estudio de prefactibilidad. 4.1.1 Diagnóstico de la situación actual 4.1.1.1 Descripción situación actual Descripción de la forma en que actualmente se realizan los procesos y de su interacción con el entorno del sistema. Esta descripción debe ser lo más clara, completa y concisa, sin dar lugar a ambigüedades. A modo de apoyo, se recomienda usar esquemas y diagramas. 4.1.1.2 Identificación de problemas y fallas Listar las fallas y carencias que presenta el sistema / situación actual. Implica clasificar y ordenar los problemas según importancia e impacto. 4.1.2 Dimensión del cambio 4.1.2.1 Características y potencialidades deseadas Se debe dar respuesta a los problemas y fallas antes descritos. Involucra rasgos funcionales, tecnológicos, sociales, organizacionales, entre otros. Estas características, a posterior, deben ser trazables con los requerimientos funcionales y no funcionales. Profesor Dr. Marcello Visconti Z. 2
4.1.2.2 Restricciones Se debe realizar una descripción de las restricciones económicas, sociales, culturales, tecnológicas, institucionales, políticas, legales, entre otras, que de alguna u otra forma afectan al proyecto. 4.1.3 Análisis de las alternativas de solución Por cada una de las alternativas de solución propuestas se debe explicar los tópicos que a continuación se describen. 4.1.3.1 Alternativa X Descripción Por cada una de las alternativas de solución propuestas, se debe realizar la descripción funcional y tecnológica de éstas. Análisis de prefactibilidad: Consiste en realizar una evaluación cuantitativa y cualitativa de las alternativas propuestas. Realizar un estudio de prefactibilidad técnica, operacional, legal y económica de la alternativa antes descrita. No obstante, se pueden considerar aspectos relevantes para el proyecto, como culturales, de normativa organizacional, entre otros. La prefactibilidad económica, en este punto, debe considerar aspectos cualitativos en vez de los cuantitativos. 4.1.4 Selección de la alternativa de solución Lo primero que se debe especificar son los criterios que se emplearán para evaluar y seleccionar la mejor alternativa. Luego, en base a estos criterios, determinar cuál es la alternativa que mejor cumple con éstos. 4.1.5 Estudio factibilidad económica de la alternativa seleccionada Una vez establecida la alternativa a desarrollar, debe hacerse un estudio basado en indicadores económicos, que al menos debe incluir PAYBACK, VAN y TIR, de tal forma de justificar la inversión a realizar en el proyecto. Además, se deben cuantificar los beneficios y/o ganancias que generará el desarrollo del proyecto. 4.2 Técnicas y herramientas de desarrollo 4.2.1 Modelo de desarrollo Elegir un paradigma de desarrollo, justificando esta elección en base a las características propias del proyecto en desarrollo. Profesor Dr. Marcello Visconti Z. 3
Se deben especificar productos de trabajo que se generarán en el desarrollo del proyecto, así como una breve descripción del contenido de éstos. 4.2.2 Herramientas y técnicas de soporte para el desarrollo Especificar las herramientas que se utilizarán en el desarrollo del proyecto, así como la(s) etapa(s) involucrada(s). Definir las técnicas a utilizar en el desarrollo del proyecto, así como el motivo por el cual fueron seleccionadas. En este punto se hace mención a cualquier herramienta o técnica que apoye el proceso de desarrollo. Por ejemplo, lenguajes de programación, herramientas CASE, técnicas de comunicación, técnicas de aseguramiento de la calidad, técnicas de control de cambio, entre otras. 4.2.3 Plan de medioambiente de desarrollo Se debe entregar las características del ambiente de desarrollo que se utilizará, considerando aspectos tales como HW, SW, topología de red, entre otros. 4.2.4 Plan de capacitación del grupo de desarrollo La capacitación del personal incluye los siguientes puntos: Observación del desarrollo cooperativo e individual. Análisis de insuficiencias y mejoras. Elaboración de programas de apoyo y optimización. Programa de incorporación de nuevos funcionarios. Se deben especificar las insuficiencias detectadas en cada participante del desarrollo del proyecto, las acciones que se llevarán a cabo para remediarlas, y cuándo se realizarán éstas. Este plan se debe reflejar en la calendarización del proyecto. 4.2.5 Gestión de riesgos Análisis y control de circunstancias probables que pudiesen obstaculizar el normal transcurrir de la planificación. Las etapas que se desarrollan en el análisis de riesgos, son las que a continuación se describen. 4.2.5.1 Análisis de riesgos Identificación: lista de ítems de riesgo que pueden comprometer el éxito del proyecto. Clasificación de los riesgos: estos se pueden clasificar en distintas categorías. Las mínimas que se piden son: Profesor Dr. Marcello Visconti Z. 4
Del proyecto: dificultades durante el desarrollo, relacionados con los recursos humanos, la calendarización o la interacción cliente-desarrollador. Ejemplo: Mal dimensionamiento del problema. Técnicos: potenciales problemas de diseño, implantación del sistema, interfaz, verificación y mantenimiento. Ejemplo: Pérdidas de información por fallas de HW durante el desarrollo. Del negocio: comprende posibles hechos que pueden hacer fracasar el sistema una vez terminado. Ejemplo: nuevas disposiciones legales, aparición en el mercado de productos sustitutos. Evaluación: caracterizar cualitativamente la probabilidad de ocurrencia e impacto de los riesgos. Priorización de los riesgos, según su probabilidad e impacto. 4.2.5.2 Control de riesgos Se debe realizar el control de los 10 riesgos más prioritarios, a través de la hoja de control de riesgos. Esta hoja de control incluye: Planificación de acción: plan de contingencia (acciones por realizar al activarse el riesgo) y plan de mitigación (acciones que permiten atenuar la probabilidad de ocurrencia y/o el impacto del riesgo). Resolución: cierre del riesgo. Monitoreo: Seguimiento de los riesgos y actividades, con el objeto de detectar nuevos, riesgos, reevaluar los existentes y ejecutar los planes en caso de ser necesario. 4.3 Implementación 4.3.1 Plan de operación del sistema Se debe especificar el ambiente de operación del sistema y los recursos requeridos para ello. 4.3.2 Plan de implantación Especificación de las tareas, responsabilidades y recursos ligados a la implantación del sistema, de forma secuencial. 4.3.3 Plan de mantención Definición de recursos asociados a períodos de tiempo sobre la base de una planificación. Se debe especificar el tipo de garantía que se entregará. Profesor Dr. Marcello Visconti Z. 5
5 Plan de Recursos 5.1 Dimensionamiento del problema Estimación de la complejidad funcional y del tamaño del producto. Esto se realiza utilizando la herramienta de Puntos de Función. 5.2 Calendarización 5.2.1 Estructura de descomposición de tareas (WBS) Determinación de las principales fases, subfases, actividades, tareas y subtareas que permitan cumplir con los compromisos adquiridos. Definición de hitos, los cuales se deben ver reflejados en el WBS. Asignación de tiempo, responsable, recursos humanos, estado, costos (opcional), productos de trabajo y actividades predecesoras a cada una de las tareas. Definición de métodos de seguimiento y control de la planificación. 5.2.2 Carta Gantt Utilizar la herramienta Microsoft Project para generar la Carta Gantt, en base a lo estipulado en el WBS. Cabe notar que el WBS y Carta Gantt son parte del plan de proyecto, por lo que NO van en los anexos. 5.3 Recursos del proyecto 5.3.1 Recursos Humanos Establecer y caracterizar el perfil del recurso humano requerido para el proyecto (analistas, diseñadores, programadores, ingenieros, entre otros). Detallar, de forma tabular, las capacidades, habilidades, disponibilidad de tiempo y responsabilidades (tareas asignadas) del recurso humano asignado al proyecto. 5.3.2 Hardware / Software Especificar HW y SW requerido para el desarrollo del proyecto, describiendo sus características intrínsecas, potencialidades, funcionalidad y disponibilidad. 5.3.3 Otros Recursos adicionales, no especificados en los puntos anteriores, requeridos para el desarrollo del sistema. Profesor Dr. Marcello Visconti Z. 6
5.4 Estimación de esfuerzo Estimación de esfuerzo (MM) y tiempo para el desarrollo e instalación del sistema, basándose en la planificación y asignación de recursos. Para esto, se utiliza la herramienta COCOMO. 5.5 Estimación de costo Estimación del costo total de desarrollo del proyecto. Se debe especificar por fase e ítem los costos, de la forma más clara posible. 5.6 Organización del equipo de desarrollo Cargos y funciones desarrolladas por cada uno de los integrantes del equipo de trabajo (a nivel organizacional) con la visión de desarrolladores, NO de empresa. Profesor Dr. Marcello Visconti Z. 7
6 Plan del Aseguramiento de la Calidad del Software (SQA) 6.1 Introducción Se debe realizar una breve introducción de la importancia de SQA en la organización y los objetivos que se persiguen con el presente plan de calidad. 6.2 Organización y responsabilidad Organización del grupo de SQA, especificando roles y responsabilidades asociadas a cada rol. Asignación de personal a SQA, es decir, asociar a una persona particular uno de los roles antes definidos. 6.3 Prácticas de SQA Descripción de las tareas y actividades de SQA, dentro del contexto del desarrollo de software, de forma clara y concisa. 6.4 Productos de Trabajo Para cada uno de los productos de trabajo identificados en el plan técnico (punto 4.2.1), se deben definir los atributos de calidad exigibles, según el modelo de calidad elegido. Además, es necesario establecer los mecanismos de aprobación: quién o quiénes harán la revisión final?, cómo la harán?, cuándo? (lo que se debe reflejar en la planificación) y con qué formularios o checklist? 6.5 Revisiones Identificar las revisiones a realizar por el equipo de desarrollo del proyecto, el grupo de SQA y el cliente, otorgando una visión global sobre los objetivos a alcanzar. Se debe especificar los mecanismos de revisión: frecuencia, participantes, fechas, duración, criterios para seleccionar el material a revisar y los formularios a emplear. 6.6 Formas o Checklist asociados En este punto se deben mostrar todos los cheklist, templates o formularios asociados al proceso de SQA. Incluye: Templates para el proceso de revisión. Templates para las pruebas. Checklist para la revisión final de cada etapa del proceso de desarrollo y por producto de trabajo. Profesor Dr. Marcello Visconti Z. 8
7 Plan de Gestión de Configuración (SCM) 7.1 Introducción Se debe realizar una breve introducción de la importancia de SCM en la organización y los objetivos que se persiguen con el presente plan de gestión de configuración. 7.2 Organización y responsabilidad Organización del grupo de SCM, especificando los roles y las responsabilidades asociadas a cada rol. Asignación de personal a SCM, es decir, asociar a una persona particular uno de los roles antes definidos. 7.3 Tareas de SCM Descripción de las tareas y actividades de SCM, dentro del contexto del proceso de desarrollo de software. 7.3.1 Identificación de ítems de configuración Listar los ítems de configuración seleccionados, a su vez, indicar criterios de selección. Determinar tipos de documentación de configuración requerida por cada ítem. Establecer un mecanismo de asignación de identificadores. 7.3.2 Identificación de baselines Identificar las baselines que se establecerán durante el proyecto. Descripción de cuando y como serán producidas y de su composición. 7.3.3 Mecanismos de Control de cambio Determinar la forma y los procedimientos para la preparación y realización de los cambios. Como mínimo, deben definirse las etapas de solicitud de cambio, evaluación del cambio e implementación de las modificaciones aprobadas. También, deben especificarse los roles y responsabilidades asociadas a cada paso. (por ejemplo, quién será el(los) responsable(s) de aprobar el cambio?) 7.3.4 Contabilidad del estado de la configuración Lista de los reportes que se proveerán en relación al estado de la configuración. Para cada reporte debe especificarse audiencia y frecuencia de distribución. Profesor Dr. Marcello Visconti Z. 9
7.3.5 Auditorías de configuración Descripción de las auditorías de configuración: participantes, fechas, duración y los formularios a emplear. 7.3.6 Formas o Checklist asociados Mecanismos de Control de cambio: Solicitud de cambio, versiones, revisiones, etc. Contabilidad del estado de la configuración: reporte detallado de cada CI, histórico de los cambios del proyecto, estado de cada CI, estado de las baselines, resultados de las auditorías. Auditorías. 8 Conclusión Por cada entrega parcial del plan de proyecto, se debe incluir una conclusión. Esta debe ser con respecto al proyecto desarrollado. Con respecto al proyecto, debe quedar claro el estado de avance y los compromisos que se desprenden del documento. 9 Referencias Esta se debe separar en bibliográfica, URL's, papers y otros. La información debe ser completa, es decir, especificar todos los datos de la referencia. Profesor Dr. Marcello Visconti Z. 10