Está en la página 1de 14

<Logo Universidad>

Universidad de Talca Facultad de Ingeniería Campus Los Niches Curicó.

<Logo del Proyecto>

<Nombre Proyecto >

Informe de Planificación

Profesor(es): <Nombre(es), de la forma: Nombre Apellido1 Apellido2 >

Fecha: <de la forma, día de mes del año> < Datos alineados hacia la izquierda, extremo inferior derecho, tamaño 12, Normal>

Verdana

<Planificación de proyecto considerando algunos puntos del estándar IEEE St.1058-1998 Software Project Management Plans>

Nota: El texto incluido en cursiva azul estilo InfoBlue se presenta con el propósito de entregar una guía de llenado del documento y debe eliminarse antes de que este sea publicado.

Descripción de este documento: este informe tiene por objetivo documentar la planificación y estimación del sistema, este describe todas las tareas que serán realizadas por los integrantes de los diferentes equipos del proyecto, los puntos importantes para realizar la estimación de costo y otros elementos necesarios para proporcionar una planificación completa y precisa del trabajo durante lo que dure el proyecto de software a desarrollar.

La configuración de las páginas es tamaño Carta, margen derecho e izquierdo de 2 cms, superior de 2,5 cms. e inferior de 3 cms.

La fuente a utilizar es Verdana en tamaño 10 para el texto normal. Para los títulos es Verdana en tamaño 16 y negrita, para los subtítulos se usa letra Verdana tamaño 14 en negrita. La alineación del texto es justificada en el texto general, y alineada a la izquierda en las tablas.

1

Introducción

1.1 Resumen del Proyecto

  • 1.1.1 Propósito, Alcance y Objetivos

<Resumir de manera global el proyecto de software a realizar, incluyendo enfoque, el desarrollo de este, asi como también la solución propuesta al problema encontrado. El propósito, objetivos etc. >

  • 1.1.2 Limitaciones

<Consecuencias en general que se pueden desprender durante el desarrollo del proyecto en términos Calendarización), recursos, reutilización de componentes de software, tecnología, interfaces.>

  • 1.1.3 Entrega Proyecto

<Identificar a usuario, fecha estimada y lugar de entrega del producto>

  • 1.1.4 Evolución del Plan

<Mencionar como evolucionara el proyecto de SW, por ejemplo las actualizaciones de este, el grupo de trabajo de manera muy general >

2

Glosario y Acrónimos

<Definir algunos términos complejos que permitan la comprensión del informe de planificación o plan de proyecto, que emergen durante el desarrollo del SW> <Realizar algo similar para los acrónimos que aparecen este plan > <Para ello deben rellenar las tablas que se muestran a continuación>

Termino

Definición <concisa>

<término>

<definición,<[Referencia], opcional>>

<término>

<definición,<[Referencia], opcional>>

 

Acrónimos

Significado

<Acrónimo, en mayúscula>

<Significado>

<Acrónimo>

<Significado>

<El formato de relleno de las tablas es Verdana, tamaño 10, Normal>

3

Organización del Proyecto

<Se debe describir las interfaces externas, estructura interna, roles y responsabilidades del proyecto>

  • 3.1 Interfaces externas

<Definir los límites organizacionales y medios de interacción y comunicación entre el proyecto y las entidades externas, es decir, el cliente, alguna organización externa (si ha de existir).Si es posible incluir un diagrama (grafico) que muestre este tipo de de comunicación>

  • 3.2 Estructura interna

<Aquí se describe la estructura de quienes organizan el proyecto incluyendo las interfaces (medio comunicación) entre las unidades del equipo de desarrollo SW, entidades que

prestan apoyo al proceso, tales como la administración(los diversos grupos).También si es posible mostrar un diagrama con os diferentes subgrupos, indicando líneas de autoridad, responsabilidad y la comunicación>

  • 3.3 Roles y responsabilidades

<Describir los diferentes grupos con sus respectivos jefes o líderes a cargo, considerando las responsabilidades >

Nombre

Nombre

Grupo

Id

encargado/Líder

Responsabilidad

 

< identificador del

<Nombre apellido1

<Describir la responsabilidad del

grupo, acrónimo>

apellido 2>

líder y/o grupo trabajo>

 
  • 4 Plan de procesos gerenciales

<Especificar la gestión para el proceso del proyecto, definiendo el plan de trabajo, gestión de riesgos, alcance del proyecto etc.>

  • 4.1 Plan inicial

    • 4.1.1 Estimación de proyecto

<Especificar los métodos, técnicas y herramientas de estimación a utilizar para determinar la complejidad, tamaño, tiempo y esfuerzo del producto. Documentar los resultados obtenidos. Incluir un resumen de la estimación del proyecto, como los datos mencionados anteriormente. También la inclusión de gráficos, donde se destaque el esfuerzo, tiempo durante las principales etapas del proyecto (planificación, análisis, diseño, implementación, testing y liberación del producto >

<El análisis completo se incluye en el informe como Anexo, ahí se detallan todos los cálculos realizados en forma extensa>

  • 4.1.2 Estimación del equipo de trabajo

<Especificar los métodos, técnicas y herramientas a utilizar para la estimación del personal necesario para el desarrollo del proyecto >

  • 4.1.3 Plan de recursos

<Detallar la cantidad del personal (RR.HH) para terminar con éxito el proyecto de SW, asi como la disponibilidad o adquisición de recursos para la implementación del producto, como lo es Hardware, Software, servicio de capacitación. Mencionar el lugar de desarrollo del producto.

Respecto a todo esto considerar algunas limitaciones o ciertas restricciones que surgen de lo mencionado. Pero no especificar en detalle ya que todo el aspecto técnico, el cual se vera en un plan que lleva su nombre >

  • 4.2 Plan de trabajo

<Especificación de actividades de trabajo, agenda respectiva, recursos, compuestos por los siguientes documentos>

4.2.1 Estructura de descomposición del trabajo, Work Breakdown Structure (WBS)

< En esta cláusula de debe definir las actividades generales que permitan el desarrollo del proyecto de software. > <Definir las actividades en términos de asignación de tiempo, es decir, la cantidad de días necesario para su completación, fecha de inicio y término. Cabe destacar que se debe definir el recurso humano requerido para cada actividad, junto a su responsable> <Restringirse de acuerdo a la tabla siguiente> <Cabe mencionar que aquí no se destacan las actividades específicas del SW, solo los hitos de las diferentes etapas, mas bien son las actividades de los lideres de los distintos grupos>

Etapa

Actividad

Días

Fecha Inicio

Fecha

Responsable

 

Id

Nombre

Dep.

Termino

<depe

ndenci

a>

<Etapa 1

<A

<actividad

 

<Cantidad

<dd/mm/aaaa>

<dd/mm/aaaa

<Id del grupo

>

1>

1>

de días

>

responsable>

para la

actividad

>

<A

<actividad

2>

etapa 2>

 

.

.

.

<Etapa 2

<actividad

>

1>

<actividad

etapa 2>

.

.

<actividad

n>

 

<Por ejemplo etapa1: Planificación, Actividad: Revisión semanal, Días: 1, Responsable: SQA>

<Definir mediante algún tipo de diagrama (por ej. grafo) las actividades, de manera de determinar la ruta critica, como información

4.2.2 Calendarización

<Con los datos obtenidos generar la Carta Gantt del proyecto de SW, asignando el personal especifico a cada actividad. Para ello se puede hacer uso de herramientas como Microsoft Project. >

  • 4.3 Plan de control

<Aquí se define el proceso de seguimiento y control de proyecto, en donde se ha de controlar el estado de avance del proyecto, cumplimiento de tareas criticas>

  • 4.3.1 Plan de control y reporte de requerimientos

<Se sabe que durante el desarrollo del producto de SW algunos requerimientos han de cambiar, por lo tanto aquí se debe especificar algún mecanismo a utilizar para hacer el monitoreo y control de los cambios en los requerimientos> <La secuencia de estados de un requerimiento son los siguientes:

  • 1. creado

  • 2. desarrollo

  • 3. evaluación

  • 4. terminado>

<Diagrama de estados que muestra lo anterior>

<Definir mediante algún tipo de diagrama (por ej. grafo) las actividades, de manera de determinar la

<Con esta información permite conocer el estado del proyecto y asi un determinado porcentaje de avance del mismo>

<Un formato de reporte puede ser el siguiente, se han de considerar como reporte internos>

 

Plan de reporte

Responsable: <Nombre líder o grupo>

Fecha emisión:<dd/mm/aaa>

Ámbito:

 

Destinatarios

Nombre: <Nombre apellido1 apellido2, no se restringe solo a un destinatario>

Cargo: <Cargo del destinatario>

 

Resultados

Estado según planificación:

<Una breve descripción que indique el porcentaje de avance del proyecto (requerimientos), en base a la planificación inicial. Si es posible referenciar algunos documentos que avalen lo mencionado>

Observaciones:

 

Fecha próximo reporte: <dd/mm/aaa>

  • 4.3.2 Plan de control de cronograma

<Aquí se debe especificar los hitos principales del proyecto, presentándolos en una línea de tiempo en relación con las tapas generales del proyecto> <Etapas principales como análisis, diseño, implementación, liberación del producto de SW, indicando las fechas en cada una de estas etapas, un ejemplo se muestra a continuación.>

<<Análisis>>
<<Análisis>>
<<Diseño>>
<<Diseño>>

<<Implementación>>

Carta Gantt
Carta Gantt
   
 
Hito 1: <<Análisis>> Hito 2: <<Diseño>> Hito 3: <<Liberación>> Fecha Entrega: dd/mm/aa Fecha Entrega: dd/mm/aa Fecha
Hito 1: <<Análisis>> Hito 2: <<Diseño>> Hito 3: <<Liberación>> Fecha Entrega: dd/mm/aa Fecha Entrega: dd/mm/aa Fecha
Hito 1: <<Análisis>> Hito 2: <<Diseño>> Hito 3: <<Liberación>> Fecha Entrega: dd/mm/aa Fecha Entrega: dd/mm/aa Fecha

Hito 1: <<Análisis>>

Hito 2: <<Diseño>>

 

Hito 3: <<Liberación>>

Fecha Entrega: dd/mm/aa

Fecha Entrega: dd/mm/aa

Fecha Entrega: dd/mm/aa

Fecha Inicio dd/mm/aa
Fecha Inicio
dd/mm/aa
  • 4.3.3 Plan de gestión de riesgos

<Consiste en tratar de identificar los riesgos y esbozar planes para minimizar sus efectos en el proyecto> <Es decir, se ha de realizar un analizar los posibles problemas que afecten el desarrollo normal de la planificación del proyecto> <Todo esto se debe regir en base a las diferentes tablas a continuación descritas>

  • 4.3.3.1 Identificación de riesgo

<Lista de ítem de riesgos que pueden comprometer el éxito del trabajo>

Tipo de riesgo

Riesgos posibles

<colocar el tipo de riesgo, los cuales pueden ser: tecnología, personal, organizacional, herramientas, requerimientos, estimación>

<indicar los riesgo según el tipo de estos>

  • 4.3.3.2 Análisis de riesgo

<Consiste en estimar la probabilidad y seriedad de cada riesgo. Asi como también los efectos de estos>

Riesgo

Probabilidad

Efectos

<Especificar el riesgo>

<colocar la probabilidad del riesgo en base a la siguiente escala: muy baja, baja, moderada,

<Especificar el tipo de efecto ya sea en proyecto, producto de acuerdo a lo siguiente: catastrófico, serios, tolerables o insignificantes. Si es necesario

alta, muy alta>

describir el porque de tal efecto>

  • 4.3.3.3 Planificación de riesgos

<Se ha de considerar cada riesgo y desarrollar una estrategia para administrarlo. Considerando en la descripción el impacto, si el riesgo surge, implementar un plan de contingencia >

Riesgo

Estrategia

<indicar de manera general el riesgo>

<Detallar alguna estrategia o plan de contingencia

para reducir su impacto>

  • 4.3.3.4 Monitorear el riesgo

<Estimar cada riesgo en forma regular para decidir si se esta haciendo mas o menos probable, asi como los efectos del riesgo, si han cambiado. Cada riesgo debe ser discutido en reuniones>

Tipo de riesgo

Indicadores potenciales

<Colocar el tipo de riesgo de acuerdo a los mencionados arriba, es decir, tecnológicos, personales etc.>

<Destacar los problemas percibidos>

5

Plan técnico

<En esta cláusula se debe especificar el modelo de desarrollo, los métodos técnicos, herramientas y técnicas a usar de los productos de trabajo del proyecto de SW. Todo esto se traduce en lo siguiente.>

  • 5.1 Modelo de proceso

<contiene una descripción detallada del modelo (desarrollo) de ciclo de vida a usar, definiendo las relaciones entre las actividades principales, flujo de información, productos de trabajo etc. Describir el proceso de manera grafica y textual, indicando desde la inicialización y finalización del proyecto>

  • 5.2 Métodos, herramientas y técnicas

<Par cada etapa del modelo de proceso se debe especificar los métodos, técnicas y herramientas que apoyaran el desarrollo del producto y la gestión del proyecto, es decir, lenguajes de programación, herramientas CASE (herramientas informáticas que ayudan a la productividad del software, por ejemplo, en el diseño, estimación etc.), técnicas de extracción de requerimientos ( modelado de metas (http://giro.infor.uva.es/Publications/2006/Gon06/metamodelo_v0.5.pdf) , técnicas de modelación, técnicas de comunicación, técnicas de aseguramiento de calidad, técnicas de control de cambio, estándares o procedimientos que faciliten la especificación, diseño, implementación, testing, entregables.>

<A continuación se muestra una tabla de apoyo para ingresar esa información>

Modelo de Procesos

<Nombre del modelo de procesos>

 

Etapa/Proceso

Actividad

Método

Técnica

Herramienta

<Nombre de

<actividad 1>

<metodo>

<tecnica>

<herramienta>

etapa>

<metodo>

<tecnica>

<herramienta>

<metodo>

<tecnica>

<herramienta>

 

<actividad 2>

<actividad n>

<Nombre de

etapa>

<En el caso de las herramientas a utilizar especificar con más detalle alguna descripción de ella>

5.2 Plan de infraestructura

<En esta sección se debe especificar los recursos usados durante el proceso de desarrollo (entorno de trabajo), es decir, destacar el hardware, sistema operativo, red, software durante análisis, diseño, implementación, prueba y gestión de proyectos, mesas de trabajo, espacios de oficinas etc.> <Para todas las herramientas indicar (si es posible), fecha de distribución y terminando respetando la disponibilidad. Todo esto tiene relación con la habilitación del laboratorio de desarrollo del proyecto> <A continuación una tabla que ayuda a la distribución de dicha información>

Recurso

Fecha disponibilidad

Fecha estimativa término

<nombre herramienta, técnica u otro>

<dd/mm/aaaa>

<dd/mm/aaaa>

 
  • 6 Plan de procesos de soporte

    • 6.1 Configuración del plan de gestión.

Esta sección debe contener una descripción detallada del cómo se realizará la administración de la configuración de los artefactos que se construyan en el proyecto, debe incluir los métodos que serán usados para proveer la configuración de identificación, control, estado de cuentas, evaluación y control de cambios o versiones. Además, se debe especificarlos procesos de administración que serán utilizados para los estándares iniciales, cuentas de usuario y análisis de solicitudes de cambio, procedimientos para tablas de control de cambios, control de los cambios en el proceso, y procedimientos para notificar los cambios en los estándares establecidos. Esto debe ser apoyado por uno o más herramientas de administración automáticas.

  • 6.2 Plan de Documentación.

Esta sección contiene el plan de documentación para el proyecto de software, incluyendo los planes para generar productos entregables y no entregables. Las entidades responsables de proveer la información, generando y revisando los variados documentos deben ser especificados en el plan. Los productos de trabajo no entregables incluyen ítems tales como especificación de requerimientos, documentación de diseño, planes de prueba, reuniones y informes de revisión. Los productos de trabajo entregables pueden incluir código fuente, manuales de usuario y una recopilación de las pruebas realizadas. El plan de documentación debe incluir una lista de documentos que serán preparados, los estándares de control o plantillas para cada documento, quién lo preparará, quién lo revisará, fechas tope para revisión de copias y versiones básicas, y una lista de distribución para revisar las copias y las versiones básicas.

6.3

Plan de aseguramiento de la calidad del proyecto.

En esta sección se estipulan los planes o pruebas que se utilizarán para asegurar que el proyecto de software cumpla plenamente con las características solicitadas del producto, los planes de soporte y cualquier estándar, procedimiento o guías a las cuales se debe adherir el proceso o producto. Los procedimientos de aseguramiento de calidad deben incluir análisis, inspecciones, revisiones y evaluaciones.

  • 7 Conclusión

  • 8 ANEXOS

    • 8.1 Anexo1: Estimación de esfuerzo por Casos de Uso

      • I. Cálculo de Puntos de Casos de Uso sin ajustar

I.I. Factor de Peso de los Actores sin ajustar (UAW)

I.II.

Factor de Peso de los Casos de Uso sin ajustar (UUCW)

II. Cálculo de Puntos de Casos de Uso ajustados

II.I.

Factor de complejidad técnica (TCF)

II.II.

Factor de ambiente (EF)

<Las Especificaciones de cada punto están descritas en el documento “Estimación del esfuerzo basada en casos de usos.pdf” adjunto a este estándar>

  • 8.1 Anexo2: Planificación de líderes del Proyecto

En esta sección se deben incluir las actividades para las diferentes etapas del proyecto, tales como Planificación, Requerimientos, Diseño, Prototipo Funcional, Revisión del Modelo, Codificación y Testing entre otros

Nombre

Responsable

Comienzo

Fin

<Nombre de la tarea>

<Nombre del grupo o grupos responsables>

<Fecha comienzo tarea en formato:

<Fecha finalización tarea en formato:

nombreDía dd-mm-

nombreDía dd-mm-

aaaa>

aaaa>

8.2

Anexo3: Planificación de Programadores por Equipos

En esta sección se deben incluir las actividades para las diferentes etapas del proyecto, tales como Planificación, Requerimientos, Diseño, Prototipo Funcional, Revisión del Modelo, Codificación y Testing entre otros

Nombre

Responsable

Comienzo

Fin

<Nombre de la tarea>

<Nombre del grupo o grupos responsables>

<Fecha comienzo tarea en formato:

<Fecha finalización tarea en formato:

nombreDía dd-mm-

nombreDía dd-mm-

aaaa>

aaaa>

  • 8.3 Anexo4: Planificación individual Expertos Base de Datos

En esta sección se deben incluir las actividades para las diferentes etapas del proyecto, tales como Planificación, Requerimientos, Diseño, Prototipo Funcional, Revisión del Modelo, Codificación y Testing entre otros

Nombre

Responsable

Comienzo

Fin

<Nombre de la tarea>

<Nombre del grupo o grupos responsables>

<Fecha comienzo tarea en formato:

<Fecha finalización tarea en formato:

nombreDía dd-mm-

nombreDía dd-mm-

aaaa>

aaaa>

  • 8.4 Anexo5: Planificación individual Expertos Testing

En esta sección se deben incluir las actividades para las diferentes etapas del proyecto, tales como Planificación, Requerimientos, Diseño, Prototipo Funcional, Revisión del Modelo, Codificación y Testing entre otros

Nombre

Responsable

Comienzo

Fin

<Nombre de la tarea>

<Nombre del grupo o grupos responsables>

<Fecha comienzo tarea en formato:

<Fecha finalización tarea en formato:

nombreDía dd-mm-

nombreDía dd-mm-

aaaa>

aaaa>

8.5

Anexo6: Planificación individual Expertos de Control de Calidad

En esta sección se deben incluir las actividades para las diferentes etapas del proyecto, tales como Planificación, Requerimientos, Diseño, Prototipo Funcional, Revisión del Modelo, Codificación y Testing entre otros

Nombre

Responsable

Comienzo

Fin

<Nombre de la tarea>

<Nombre del grupo o grupos responsables>

<Fecha comienzo tarea en formato:

<Fecha finalización tarea en formato:

nombreDía dd-mm-

nombreDía dd-mm-

aaaa>

aaaa>

  • 8.6 Anexo7: Planificación individual de Expertos Diseño de Interfaz

En esta sección se deben incluir las actividades para las diferentes etapas del proyecto, tales como Planificación, Requerimientos, Diseño, Prototipo Funcional, Revisión del Modelo, Codificación y Testing entre otros

Nombre

Responsable

Comienzo

Fin

<Nombre de la tarea>

<Nombre del grupo o grupos responsables>

<Fecha comienzo tarea en formato:

<Fecha finalización tarea en formato:

nombreDía dd-mm-

nombreDía dd-mm-

aaaa>

aaaa>

  • 8.7 Anexo8: Planificación general grupal.

En esta sección se deben incluir las actividades para las diferentes etapas del proyecto, tales como Planificación, Requerimientos, Diseño, Prototipo Funcional, Revisión del Modelo, Codificación y Testing entre otros.

El formato a utilizar es el estilo de Carta Gantt utilizando el software de planificación Microsoft Project.