pautaplandeproyecto

DDDeeepppaaarrr ttt aaammmeeennnttt ooo dddeee III nnnfff ooorrr mmmttt iii cccaaaUUnniivveerrssiiddaadd TTccnniiccaa FFeeddeerriiccoo SSaannttaa MMaarraa

Profesor Dr. Marcello Visconti Z. 1

PPaauuttaa PPllaann ddee PPrrooyyeeccttoo

Ingeniera de Software

PPrrooffeessoorr:: Dr. Marcello Visconti [email protected]

0 PortadasEl documento que se est generando corresponde al plan de proyecto para eldesarrollo de un producto de software, dentro de las actividades de la asignaturaIngeniera de Software, por lo tanto, es de vital importancia que el grupo de proyectosepare e identifique dos tipos de portada que se deben incluir en el documento, en elorden que se seala a continuacin.

0.1 Portada de la asignatura Debe incluir los siguientes datos como mnimo: nombre del documento, nombre y

rol de los integrantes, nombre profesor, ayudante(s) y fecha.

0.2 Portada del proyecto Debe incluir la siguiente informacin como mnimo: nombre del documento,

nombre del proyecto, nombre y logotipo de la Empresa y producto, jefe deproyecto, equipo de desarrollo y fecha.

1 ndice o Tabla de Contenidos Presenta la secuencia lgica de ideas tratadas, facilitando la bsqueda de

informacin especfica contendida en el documento.

Observacin: el punto anterior (Portadas) NO debe ser incluido como parte de la tablade 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 Introduccin Resumen de la visin global del proyecto. Incluye:

Origen del tema tratado.

Pauta Plan de Proyecto Ingeniera de Software


Descripcin global del problema a resolver. Enfoque de desarrollo. Descripcin global de la solucin al problema.

3 Alcances y Propsitos 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 personasinvolucradas en el proyecto, como los clientes.

Es necesario destacar las consecuencias y compromisos que puedendesprenderse del informe.

4 Plan Tcnico

4.1 Especificacin del Sistema

El objetivo de este punto es definir los elementos de un sistema dentro de uncontexto global, con el fin de identificar necesidades de informacin y establecerlas bases para el proyecto.

Con lo anterior, se propondrn alternativas de solucin y se escoger una,apoyndose en un estudio de prefactibilidad.

4.1.1 Diagnstico de la situacin actual

4.1.1.1 Descripcin situacin actual

Descripcin de la forma en que actualmente se realizan los procesos y de suinteraccin con el entorno del sistema. Esta descripcin debe ser lo ms clara,completa y concisa, sin dar lugar a ambigedades.

A modo de apoyo, se recomienda usar esquemas y diagramas.

4.1.1.2 Identificacin de problemas y fallas

Listar las fallas y carencias que presenta el sistema / situacin actual. Implica clasificar y ordenar los problemas segn importancia e impacto.

4.1.2 Dimensin del cambio

4.1.2.1 Caractersticas y potencialidades deseadas

Se debe dar respuesta a los problemas y fallas antes descritos. Involucra rasgos funcionales, tecnolgicos, sociales, organizacionales, entre

otros. Estas caractersticas, a posterior, deben ser trazables con los requerimientos

funcionales y no funcionales.



4.1.2.2 Restricciones

Se debe realizar una descripcin de las restricciones econmicas, sociales,culturales, tecnolgicas, institucionales, polticas, legales, entre otras, que dealguna u otra forma afectan al proyecto.

4.1.3 Anlisis de las alternativas de solucin

Por cada una de las alternativas de solucin propuestas se debe explicar lostpicos que a continuacin se describen.

4.1.3.1 Alternativa X

Descripcin Por cada una de las alternativas de solucin propuestas, se debe realizar la

descripcin funcional y tecnolgica de stas.

Anlisis de prefactibilidad: Consiste en realizar una evaluacin cuantitativa y cualitativa de las alternativas

propuestas. Realizar un estudio de prefactibilidad tcnica, operacional, legal y econmica

de la alternativa antes descrita. No obstante, se pueden considerar aspectosrelevantes para el proyecto, como culturales, de normativa organizacional,entre otros.

La prefactibilidad econmica, en este punto, debe considerar aspectoscualitativos en vez de los cuantitativos.

4.1.4 Seleccin de la alternativa de solucin

Lo primero que se debe especificar son los criterios que se emplearn paraevaluar y seleccionar la mejor alternativa.

Luego, en base a estos criterios, determinar cul es la alternativa que mejorcumple con stos.

4.1.5 Estudio factibilidad econmica de la alternativa seleccionada

Una vez establecida la alternativa a desarrollar, debe hacerse un estudiobasado en indicadores econmicos, que al menos debe incluir PAYBACK, VANy TIR, de tal forma de justificar la inversin a realizar en el proyecto.

Adems, se deben cuantificar los beneficios y/o ganancias que generar eldesarrollo del proyecto.

4.2 Tcnicas y herramientas de desarrollo

4.2.1 Modelo de desarrollo

Elegir un paradigma de desarrollo, justificando esta eleccin en base a lascaractersticas propias del proyecto en desarrollo.



Se deben especificar productos de trabajo que se generarn en el desarrollodel proyecto, as como una breve descripcin del contenido de stos.

4.2.2 Herramientas y tcnicas de soporte para el desarrollo

Especificar las herramientas que se utilizarn en el desarrollo del proyecto, ascomo la(s) etapa(s) involucrada(s).

Definir las tcnicas a utilizar en el desarrollo del proyecto, as como el motivopor el cual fueron seleccionadas.

En este punto se hace mencin a cualquier herramienta o tcnica que apoye elproceso de desarrollo. Por ejemplo, lenguajes de programacin, herramientasCASE, tcnicas de comunicacin, tcnicas de aseguramiento de la calidad,tcnicas de control de cambio, entre otras.

4.2.3 Plan de medioambiente de desarrollo

Se debe entregar las caractersticas del ambiente de desarrollo que seutilizar, considerando aspectos tales como HW, SW, topologa de red, entreotros.

4.2.4 Plan de capacitacin del grupo de desarrollo

La capacitacin del personal incluye los siguientes puntos: Observacin del desarrollo cooperativo e individual. Anlisis de insuficiencias y mejoras. Elaboracin de programas de apoyo y optimizacin. Programa de incorporacin de nuevos funcionarios.

Se deben especificar las insuficiencias detectadas en cada participante deldesarrollo del proyecto, las acciones que se llevarn a cabo para remediarlas,y cundo se realizarn stas.

Este plan se debe reflejar en la calendarizacin del proyecto.

4.2.5 Gestin de riesgos

Anlisis y control de circunstancias probables que pudiesen obstaculizar elnormal transcurrir de la planificacin.

Las etapas que se desarrollan en el anlisis de riesgos, son las que acontinuacin se describen.

4.2.5.1 Anlisis de riesgos

Identificacin: lista de tems de riesgo que pueden comprometer el xito delproyecto.

Clasificacin de los riesgos: estos se pueden clasificar en distintas categoras.Las mnimas que se piden son:



Del proyecto: dificultades durante el desarrollo, relacionados con losrecursos humanos, la calendarizacin o la interaccin cliente-desarrollador.Ejemplo: Mal dimensionamiento del problema.

Tcnicos: potenciales problemas de diseo, implantacin del sistema,interfaz, verificacin y mantenimiento. Ejemplo: Prdidas de informacin porfallas de HW durante el desarrollo.

Del negocio: comprende posibles hechos que pueden hacer fracasar elsistema una vez terminado. Ejemplo: nuevas disposiciones legales,aparicin en el mercado de productos sustitutos.

Evaluacin: caracterizar cualitativamente la probabilidad de ocurrencia eimpacto de los riesgos.

Priorizacin de los riesgos, segn su probabilidad e impacto.

4.2.5.2 Control de riesgos

Se debe realizar el control de los 10 riesgos ms prioritarios, a travs de la hojade control de riesgos.

Esta hoja de control incluye: Planificacin de accin: plan de contingencia (acciones por realizar al

activarse el riesgo) y plan de mitigacin (acciones que permiten atenuar laprobabilidad de ocurrencia y/o el impacto del riesgo).

Resolucin: cierre del riesgo. Monitoreo: Seguimiento de los riesgos y actividades, con el objeto de

detectar nuevos, riesgos, reevaluar los existentes y ejecutar los planes encaso de ser necesario.

4.3 Implementacin

4.3.1 Plan de operacin del sistema

Se debe especificar el ambiente de operacin del sistema y los recursosrequeridos para ello.

4.3.2 Plan de implantacin

Especificacin de las tareas, responsabilidades y recursos ligados a laimplantacin del sistema, de forma secuencial.

4.3.3 Plan de mantencin

Definicin de recursos asociados a perodos de tiempo sobre la base de unaplanificacin.

Se debe especificar el tipo de garanta que se entregar.



5 Plan de Recursos

5.1 Dimensionamiento del problema

Estimacin de la complejidad funcional y del tamao del producto. Esto se realizautilizando la herramienta de Puntos de Funcin.

5.2 Calendarizacin

5.2.1 Estructura de descomposicin de tareas (WBS)

Determinacin de las principales fases, subfases, actividades, tareas ysubtareas que permitan cumplir con los compromisos adquiridos.

Definicin de hitos, los cuales se deben ver reflejados en el WBS. Asignacin de tiempo, responsable, recursos humanos, estado, costos

(opcional), productos de trabajo y actividades predecesoras a cada una de lastareas.

Definicin de mtodos de seguimiento y control de la planificacin.

5.2.2 Carta Gantt

Utilizar la herramienta Microsoft Project para generar la Carta Gantt, en base alo estipulado en el WBS.

Cabe notar que el WBS y Carta Gantt son parte del plan de proyecto, por loque 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, diseadores, programadores, ingenieros, entre otros).

Detallar, de forma tabular, las capacidades, habilidades, disponibilidad de tiempo yresponsabilidades (tareas asignadas) del recurso humano asignado al proyecto.

5.3.2 Hardware / Software

Especificar HW y SW requerido para el desarrollo del proyecto, describiendo suscaractersticas intrnsecas, potencialidades, funcionalidad y disponibilidad.

5.3.3 Otros

Recursos adicionales, no especificados en los puntos anteriores, requeridos parael desarrollo del sistema.



5.4 Estimacin de esfuerzo

Estimacin de esfuerzo (MM) y tiempo para el desarrollo e instalacin delsistema, basndose en la planificacin y asignacin de recursos.

Para esto, se utiliza la herramienta COCOMO.

5.5 Estimacin de costo

Estimacin del costo total de desarrollo del proyecto. Se debe especificar por fase e tem los costos, de la forma ms clara posible.

5.6 Organizacin del equipo de desarrollo

Cargos y funciones desarrolladas por cada uno de los integrantes del equipo detrabajo (a nivel organizacional) con la visin de desarrolladores, NO de empresa.



6 Plan del Aseguramiento de la Calidad del Software (SQA)

6.1 Introduccin

Se debe realizar una breve introduccin de la importancia de SQA en laorganizacin y los objetivos que se persiguen con el presente plan de calidad.

6.2 Organizacin y responsabilidad

Organizacin del grupo de SQA, especificando roles y responsabilidadesasociadas a cada rol.

Asignacin de personal a SQA, es decir, asociar a una persona particular uno delos roles antes definidos.

6.3 Prcticas de SQA

Descripcin de las tareas y actividades de SQA, dentro del contexto deldesarrollo de software, de forma clara y concisa.

6.4 Productos de Trabajo

Para cada uno de los productos de trabajo identificados en el plan tcnico (punto4.2.1), se deben definir los atributos de calidad exigibles, segn el modelo decalidad elegido.

Adems, es necesario establecer los mecanismos de aprobacin: quin oquines harn la revisin final?, cmo la harn?, cundo? (lo que se debereflejar en la planificacin) y con qu formularios o checklist?

6.5 Revisiones

Identificar las revisiones a realizar por el equipo de desarrollo del proyecto, elgrupo de SQA y el cliente, otorgando una visin global sobre los objetivos aalcanzar.

Se debe especificar los mecanismos de revisin: frecuencia, participantes, fechas,duracin, criterios para seleccionar el material a revisar y los formularios aemplear.

6.6 Formas o Checklist asociados

En este punto se deben mostrar todos los cheklist, templates o formulariosasociados al proceso de SQA. Incluye: Templates para el proceso de revisin. Templates para las pruebas. Checklist para la revisin final de cada etapa del proceso de desarrollo y

por producto de trabajo.



7 Plan de Gestin de Configuracin (SCM)

7.1 Introduccin

Se debe realizar una breve introduccin de la importancia de SCM en laorganizacin y los objetivos que se persiguen con el presente plan de gestin deconfiguracin.

7.2 Organizacin y responsabilidad

Organizacin del grupo de SCM, especificando los roles y las responsabilidadesasociadas a cada rol.

Asignacin de personal a SCM, es decir, asociar a una persona particular uno delos roles antes definidos.

7.3 Tareas de SCM

Descripcin de las tareas y actividades de SCM, dentro del contexto del procesode desarrollo de software.

7.3.1 Identificacin de tems de configuracin

Listar los tems de configuracin seleccionados, a su vez, indicar criterios deseleccin.

Determinar tipos de documentacin de configuracin requerida por cada tem. Establecer un mecanismo de asignacin de identificadores.

7.3.2 Identificacin de baselines

Identificar las baselines que se establecern durante el proyecto. Descripcin de cuando y como sern producidas y de su composicin.

7.3.3 Mecanismos de Control de cambio

Determinar la forma y los procedimientos para la preparacin y realizacin de loscambios. Como mnimo, deben definirse las etapas de solicitud de cambio,evaluacin del cambio e implementacin de las modificaciones aprobadas.

Tambin, deben especificarse los roles y responsabilidades asociadas a cadapaso. (por ejemplo, quin ser el(los) responsable(s) de aprobar el cambio?)

7.3.4 Contabilidad del estado de la configuracin

Lista de los reportes que se proveern en relacin al estado de la configuracin. Para cada reporte debe especificarse audiencia y frecuencia de distribucin.



7.3.5 Auditoras de configuracin

Descripcin de las auditoras de configuracin: participantes, fechas, duracin ylos 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 configuracin: reporte detallado de cada CI, histrico

de los cambios del proyecto, estado de cada CI, estado de las baselines,resultados de las auditoras.

Auditoras.

8 Conclusin

Por cada entrega parcial del plan de proyecto, se debe incluir una conclusin. 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 bibliogrfica, URL's, papers y otros. La informacin debe ser completa, es decir, especificar todos los datos de la

referencia.

pautaplandeproyecto

Documents