Source: http://docplayer.es/8456449-Titulo-del-proyecto-de-desarrollo-de-sw.html
Timestamp: 2018-08-20 02:37:20+00:00

Document:
<TITULO DEL PROYECTO DE DESARROLLO DE SW > - PDF
Download "<TITULO DEL PROYECTO DE DESARROLLO DE SW >"
Rosa María Camacho Rojo
1 Diana Milena Pérez Riveros <TITULO DEL PROYECTO DE DESARROLLO DE SW > <Fecha Edición del Documento> <Identificador Único> <Responsable (quien hizo el documento)> 1
2 Diana Milena Pérez Riveros Pagina de Firmas El presente documento es aprobado por las personas referenciadas a continuación: Firma Cliente: <nombre> Firma Administrador de Proyecto: <nombre> Firma Arquitecto <nombre> 2
3 Diana Milena Pérez Riveros Historial de Cambios Versión Fecha Sección del documento modificada Descripción de Cambios(corta) Responsable 3
4 Diana Milena Pérez Riveros 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. 4
5 Diana Milena Pérez Riveros Tabla de Contenido 1. VISIÓN GENERAL DEL PROYECTO 1.1. Resumen del Proyecto Propósito, Alcance y Objetivos Suposiciones y Restricciones Entregables del Proyecto Resumen de calendarización y presupuesto 1.2. Evolución del Plan 2. REFERENCIAS 3. DEFINICIONES Y ACRÓNIMOS 4. ORGANIZACIÓN DEL PROYECTO 4.1. Interfaces Externas 4.2. Estructura Interna 4.3. Roles y Responsabilidades 5. PLAN DE PROCESOS DE GESTIÓN 5.1. Plan de Arranque Plan de Estimación Plan de Personal Plan de adquisición de recursos Plan de Entrenamiento y Capacitación para el personal del proyecto 5.2. Plan de Trabajo Actividades de trabajo Detalle de la calendarización Detalle de los recursos Detalle del presupuesto 5.3. Plan de Control Plan de control de requerimientos Plan de control de calendarización Plan de control de presupuesto Plan de control de calidad Plan de Reporte Plan de recolección de métricas 5.4. Plan de Administración de Riesgos 5.5. Plan de Cierre 6. PLAN DE PROCESOS TÉCNICOS 6.1. Modelo de Ciclo de Vida del Proceso 6.2. Métodos, herramientas y técnicas 6.3. Plan de Infraestructura 6.4. Plan de aceptación del producto 7. PLAN DE PROCESOS DE SOPORTE 7.1. Plan de Administración de la Configuración Pág. 5
6 Diana Milena Pérez Riveros 7.2. Plan de verificación y validación 7.3. Plan de Documentación 7.4. Plan de aseguramiento de la calidad 7.5. Revisiones y Auditorias 7.6. Plan de resolución de problemas 7.7. Plan de administración de subcontratos 7.8. Plan de mejoras del proceso Anexos 6
7 Lista de Figuras Pág. Figura 1. <Título> Figura 2. <Título>.... 7
8 Lista de Tablas Pág. Tabla 1. <Título> Tabla 2. <Título>.... 8
9 1. VISIÓN GENERAL DEL PROYECTO 1.1 Resumen del proyecto 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 Suposiciones y restricciones 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 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 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. 1.2 Evolución del Plan 9
10 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. 2. REFERENCIAS Las referencias debería proveer una completa lista de todos los documentos y otras fuentes de información a las que se hace referencia en el SPMP. Cada documento debe ser identificado por su título, número de reporte, fecha, autor, dirección o nombre para su acceso de ser un documento electrónico, imprenta u organización encargada de su publicación. Otras fuentes de información, como archivos electrónicos, deben identificarse usando identificadores como la fecha y número de versión. Fuentes no referenciadas por este estándar y sus políticas deben ser identificadas y una justificación debe ser dada. Se debe seguir el estándar de la IEEE. IEEE Standard for Software Project Management Plans (SPMP). IEEE Std The Institute of Electrical and Electronics Engineers, Inc. Aprobado en Diciembre 8 de 1998., SPMP utilizado con fines académicos. Realizado por Daniel Valencia. Anamaria Ortiz, Diego González, Ana Maria Obando y Ángela María Muñoz. Documento SPMP, 2006-I, Pontifica Universidad Javeriana, Material de Curso Ingeniería de Software. 3. DEFINICIONES Y ACRONIMOS Debe proveer referencia a documentos con definiciones de todos los términos y acrónimos requeridos para el óptimo entendimiento del SPMP; tanto técnicos como del ámbito del proyecto. 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. 4. ORGANIZACIÓN DEL PROYECTO 4.1 Interfaces externas Relación con otras entidades (proveedores, contratistas). Aquí se debe describir los 10
11 límites organizacionales entre el proyecto y entidades externas. Debe incluir las siguientes (que no son las únicas): la 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. Representaciones como organigramas o diagramas pueden ser usados para mostrar interfaces externas del proyecto. La idea es describir a los agentes externos y la relación que se va a manejar con ellos. 4.2 Estructura interna Gestión interna, organigrama. En este ítem se describirá la estructura interna de la organización encargada del proyecto. Artefactos gráficos como organigramas o diagramas deben ser usados para dirigir las líneas de autoridad, responsabilidad y comunicación dentro del proyecto. Se debe especificar que estructura o modelo tiene el equipo u organización (bazar, catedral, por equipos ), y además describir como se gestionará internamente el equipo, formas de comunicación, toma de decisiones, organización 4.3 Roles y responsabilidades Funciones y actividades principales. Matriz de funciones/actividades contra responsables. Debe identificar y declarar la naturaleza de cada actividad relevante y proceso de soporte e identificar las unidades de la organización que son responsables para esos procesos y actividades. Una matriz con actividades de trabajo y procesos de soporte vs. Unidades organizacionales puede ser usada para ilustrar los roles y responsabilidades del proyecto. 5. PLAN DE PROCESOS ADMINISTRATIVOS 5.1 Plan de arranque Plan de estimación 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 Plan de contratación de personal Se especifica el número del personal por el nivel de habilidad o por el rol. De igual manera se debe en cada fase del proyecto detallar el numero requerido de personas, las 11
12 habilidades de ésta y el tiempo estimado que se éste personal se necesita. Es importante aclarar si el personal es interno o si este es de contratación externa. Esto se puede hacer mediante un cuadro en donde se indiquen los roles y las habilidades que requiere ese rol. Y luego para cada actividad planeada establecer el rol o roles necesarios para poderla desarrollar Plan de adquisición de recursos Debe especificar el plan para adquisición de recursos en necesarios para cumplir con el proyecto satisfactoriamente. El plan debería incluir, aunque no únicamente, planes de adquisición de equipos, hardware y software, entrenamiento, contratos de servicio, transporte, instalaciones, y servicios administrativos y de limpieza. El plan debería especificar en que actividades del cronograma se requerirá adquisición de recursos Plan de entrenamiento para el personal del proyecto Debería 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. El cronograma de entrenamiento debería incluir los tipos de entrenamiento a ser impartido, números de personal a entrenar, criterios de ingreso y salida de entrenamiento y métodos de entrenamiento. Debería incluir entrenamiento tanto en habilidades técnicas como de administrativas. 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. 5.2 Plan de trabajo Actividades de trabajo Se debe especificar todas las actividades que se realizarán en el proyecto y las relaciones o jerarquías que existan entre éstas. 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 Cronograma Es conveniente utilizar un método como GANTT, redes de actividad, PERT o camino crítico, para describir claramente las actividades que se pueden realizar concurrentes y las restricciones de secuencia que tenga unas con las otras. Cualquier restricción en el cronograma de trabajo causada por factores externos al proyecto debería ser indicada en éste. 12
13 5.2.3 Asignación de recursos Por cada actividad definida en el numeral de este documento, se debe especificar todos los recursos que ésta necesita para poder desarrollarse (recursos de personal, de operación, de administración...) Asignación de presupuesto. Para cada actividad que ya ha sido definida, debe definirse el costo estimado para la realización de ésta (costos para reuniones, recursos computacionales, herramientas de software, pruebas, costos administrativos, de personal ) 5.3 Plan de control 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. Los mecanismos más usados en esta fase son: Realizar prototipos, trazabilidad, hacer análisis de impacto y llevar siempre acabo revisiones Plan de control de cronograma Debe especificar los mecanismos de control que se deben usar para medir el progreso del trabajo, evaluando el cronograma planeado con el que se está realizando. En el planeamiento se debe especificar como, cuando se realizará esta actividad y quién esta encargado de realizarla. Es importante que si el cronograma no se esta llevando al día, aquí se debe tomar medidas de control e implementar acciones correctivas para corregir éste problema Plan de control de presupuesto Se debe especificar los mecanismos de control que se utilizan para medir el costo total del proyecto y el costo presupuestado. Si el presupuestado no esta siendo acorde se debe tomar medidas correctivas. En esta parte se debería realizar pausas o intervalos y así ir midiendo el presupuesto que se tenía sobre una tarea actual y evaluar si se cumplió lo especificado. El plan de control de presupuesto debería especificar los métodos y herramientas que serán usadas para manejar el presupuesto. 13
14 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 Plan de control de calidad Debería especificar los mecanismos a usar para medir y controlar la calidad de los procesos de trabajo y los productos de trabajo resultantes. Mecanismos de control de calidad deberían incluir aseguramiento de calidad de los procesos de trabajo, verificación y validación, revisión en conjunto y auditoria. Se debe especificar como se realizará el control de calidad, quién lo realizará y en que consistirá Plan de reportes Se incluyen todos los mecanismos de reporte, los formatos y la información que va en cada tipo de reporte, es importante que se realicen reportes en los requerimientos, en el cronograma, en la calidad, en el presupuesto, en las métricas, entre otras. 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 Plan colección de métricas Debería especificar los métodos, herramientas y técnicas a ser usadas en la recolección y retención de métricas de proyecto. El plan de recolección de métricas debería especificar las métricas a ser recolectadas, la frecuencia de recolección, y los métodos a ser usados en la validación, el análisis y el reporte de métricas. 5.4 Plan de administración de riesgos Se debe realizar un planeamiento para establecer como se van a identificar, como se van a analizar y como se le de va a asignar una prioridad a cada riesgo que llegue a existir en el proyecto. También debería describirse como se van a manejar los planes de contingencia y mitigación, los métodos que serán usados en el seguimiento de los riesgos y el planeamiento para dar respuestas a dichos riesgos en el caso de que éstos se lleguen a presentar. Debería especificar también quien se va a encargar de administrar los riesgos, en que momento, como. 5.5 Plan de clausura Se deben especificar todos los planes necesarios para asegurar ordenadamente la clausura del proyecto de software. Entre estos están: la reasignación del personal de trabajo, realizar el archivo de los materiales y documentos que dejo el proyecto, las actividades que se realizarán después de terminar el proyecto con los roles de las 14
15 personas que las deben realizar y los reportes de lecciones aprendidas y logros obtenidos con la realización de este proyecto. 6. PLAN DE PROCESOS TÉCNICOS 6.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. Se especifican los entregables y las modificaciones en los requerimientos si las hubo. 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 6.2 Métodos, herramientas y técnicas En este punto se debe dar a conocer la metodología que se usara para el desarrollo del proyecto. Se deben especificar el lenguaje de programación, las herramientas y los recursos técnicos que serán usados a lo largo del proyecto. Por ejemplo, es importante definir las pruebas que se realizarán al software para su buen funcionamiento y logro de los objetivos planteados inicialmente. Otro aspecto, es describir cuales productos de trabajo serán entregables y cuales no. Finalmente es necesario que el gerente del proyecto y el líder del equipo determinen las políticas de comunicación y las reglas de trabajo. 6.3 Plan de infraestructura En este campo, se describe detalladamente el ambiente de trabajo para la realización del proyecto. Aquí se ubican las instalaciones, 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. Es importante aclarar las normas y leyes establecidas para dirigir el proyecto de software. 6.4 Plan de aceptación del producto Aquí hacemos 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. Además, se han de definir los criterios de aceptación y el modo de formalizar de manera escrita el compromiso por parte del cliente en la cuál se especifique que el cliente está satisfecho con dichos entregables. Hay que tener en cuenta que los aspectos relativos a la descripción de lo que puede y lo que no puede hacer el software. Estos aspectos se aclaran con el resultado del análisis, las pruebas, inspecciones del software. 15
16 7. PLAN DE PROCESOS DE APOYO 7.1 Plan de administración de configuración 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. 7.2 Plan de verificación y validación En este punto deben definirse las actividades y tareas con las cuales se quiere comprobar el funcionamiento y los logros alcanzados del proyecto. Para esto, se debe especificar el alcance del proyecto y las técnicas de comprobación respectivas. 7.3 Plan de documentación Es necesario definir desde un comienzo, los entregables o la documentación que debe ser presentada como resultado de los avances logrados en el proyecto. 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. 7.4 Plan de aseguramiento de calidad 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. 7.5 Revisiones y auditorias Es necesario definir desde un comienzo, los entregables o la documentación que debe ser presentada como resultado de los avances logrados en el proyecto. 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. 7.6 Plan de resolución de problemas El 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. Este debe tener indicadores de control de cambios, administración de configuración, verificación y 16
17 validación en actividades de resolución de problemas. 7.7 Plan de manejo de contratistas En este ámbito, se debe especificar cualquier subcontratista que contribuya en el desarrollo del software, 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. 7.8 Plan de mejoramiento de procesos Aquí se realiza el plan para mejorar los procesos que necesiten este tratamiento, se debe realizar evaluaciones periódicas de las actividades y de ahí mirar los procesos a mejorar. Este plan va ligado con el plan de resolución de problemas. En esta área de sebe incluir los procesos que potencialmente se pueden mejorar. Esto se puede lograr haciendo evaluaciones periódicas de las actividades del proyecto. Este procedimiento debe estar estrechamente relacionado con el plan de resolución de problemas. 17

References: resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución