Project PlanGestión de Proyectos 2015

Título: Desarrollo de la capa de compatibilidad del firmwareEdu­CIAA para el hardware Edu­CIAA Xilinx.

Alumno: Gerardo L. PugaFecha: 31/05/2015Modificado: 31/05/2015

Revisión:  Rev.A

Historial de modificaciones:

31/05/2015  Primera versión del documento.01/06/2015 Corrección de errores de escritura. Emisión de la

Rev.A del documento. 

1

Project Charter

Con el fin de llevar a cabo el proyecto “Desarrollo de lacapa de compatibilidad del firmware  Edu­CIAA para el el hardwareEdu­CIAA Xilinx” como requisito de aprobación de la Carrera deEspecialización   en   Sistemas   Embebidos,   se   designa   al   IngenieroGerardo L. Puga para llevar adelante la gestión y ejecución delproyecto en todas sus etapas. 

Se establece la duración máxima del proyecto en ocho meses,desarrollarse entre la segunda quincena de abril de 2015 y laprimera quincena de diciembre de 2015.

La   disponibilidad   del   equipamiento   necesario   para   llevaradelante   la   ejecución   del   proyecto   (computadoras,   kits   dedesarrollo   FPGA,   cables,   etc.),   tanto   en   la   Universidad   de   LaPlata como en la Universidad de Buenos Aires, permite asumir lanulidad   de   los   costos   materiales   y   operativos   necesarios.   Loscostos de transporte y personal necesarios para llevar adelante elproyecto se calculan en un total de $29.232. La totalidad de laserogaciones necesarias corren por cuenta del Ing. Puga.

El   Ing.   Pedro   I.   Martos,   en   su   calidad   de   tutor   yrepresentante del proyecto que se encuentra llevando adelante eldesarrollo   del   hardware   de   la  Edu­CIAA   Xilinx  se   compromete   abrindar la asistencia que sea necesaria en términos de experienciade   desarrollo,   información   sobre   el   hardware   objetivo,   ycaracterísticas   necesarias   para   el   desarrollo   los   modelos   dedesarrollo.

Ing. Pedro I. MartosDocente Carrera de Especialización

en Sistemas Embebidos,Facultad de Ingeniería, UBA

Propósito

El presente proyecto tiene por fin el desarrollo de  una capade compatibilidad que permita ejecutar el firmware del proyectoCIAA   sobre   el   hardware   de   Edu­CIAA   Xilinx   que   se   encuentraactualmente en desarrollo.

Objetivos

Los objetivos del proyectos son, por orden de importancia, lossiguientes:

1. Realización   del   trabajo   de   finalización   de   carrera   encumplimiento de los requisitos de aprobación de la Carrera deEspecialización en Sistemas Embebidos, cursada del año 2015.

2. Extensión de la base de hardware que es posible utilizar en

2

los proyectos CIAA y Edu­CIAA.3. Ampliación de la base de procesadores que soporta la versión

del sistema operativo de tiempo real OSEK utilizado por elproyecto   CIAA,   potencialmente   facilitando   su   adopción   enotros   proyectos   nacionales   de   desarrollo   de   sistemas   detiempo real para aplicaciones críticas.

Stakeholders

Client Ing.   Pedro   Martos,   en   su   calidad   deresponsable del proyecto Edu­CIAA Xilinx.

End­User Conjunto   de   los   usuarios   de   losdispositivos   Edu­CIAA   Xilinx   con   fineseducativos, académicos o comerciales.

Sponsors Ing. Gerardo Puga

Champion Ing. Pedro Martos

Drivers Ing. Pedro MartosIng. Mariano Cerdeiro

Supporters Laboratorio de Sistemas Embebidos, UBA.Laboratorio LEICI, UNLP

Project Manager Ing. Gerardo Puga

Team members Ing. Gerardo Puga

Alcance

El alcance del proyecto se encuentra definido por las siguientes metas clave:

• Partiendo   del   último   release   estable   al   día   de   la   fecha(Firmware_0.4.1), efectuar el desarrollo del código necesariopara habilitar la ejecución del firmware de la CIAA en elsoft­core utilizado en le Edu­CIAA Xilinx de acuerdo con laguías de estilo propias de firmware del Proyecto CIAA.

• Modificación de la configuración del sistema de compilacióndel firmware para incorporar la nueva plataforma a las yaexistentes.

• Documentación   del   sistema   de   desarrollo   necesario   paracompilar y ejecutar el firmware para la plataforma elegida. 

• Documentación de las características mínimas requeridas de laplataforma por parte del firmware modificado.

3

• Hacer disponible el código y la documentación generada parasu   evaluación   y   eventual   reintegración   al   firmware   delProyecto CIAA. 

Requerimientos

R.01 Debe   portarse   el   código   de   la   versión   dereferencia   del   firmware   de   la   CIAA   para   quefuncione   sobre   el   procesador   seleccionado   paraser sintetizado en la FPGA del proyecto Edu­CIAA.Fuente: Justificación del proyecto.

R.02 La   versión   a   tomar   como   referencia   para   eldesarrollo es el último release estable al día dela fecha: Firmware_0.4.1.Fuente: Necesidad de fijar la versión de trabajo.

R.03 El   código   a   portar   incluye   la   capa   decompatibilidad   del   sistema   operativo   OSEKencargada de la gestión multitarea del firmware,y   los   drivers   de   dispositivos   de   la   capa   deabstracción de hardware del firmware CIAA.Fuente:   Análisis   del   código   de   la   versión   dereferencia.

R.04 Los   drivers   portados   debe   incluir   los   cuatrodrivers definidos en la capa de abstracción de laversión   de   referencia:  ciaaDriverFlash,ciaaDriverUart,  ciaaDriverAio  y  ciaaDriverDio.Los drivers que no sean pertinentes al hardwareobjetivo deben estar implementado como dummies deprueba.Fuente:   Análisis   del   código   de   la   versión   dereferencia.

R.05 El   código   implementado   debe   respetar   las  CIAAFirmware Coding Guidelines.Fuente: Web Proyecto CIAA ( http://www.proyecto­ciaa.com.ar )

R.06 El   código   implementado   debe   respetar   laestructura de directorios adoptada por el equipode desarrollo del firmware.Fuente: Web Proyecto CIAA ( http://www.proyecto­ciaa.com.ar )

R.07 El   código   implementado   debe   contenerdocumentación interna en el formato aceptado por

4

el   generador   automático   de   documentaciónutilizado por el proyecto (Doxygen).Fuente: Web Proyecto CIAA ( http://www.proyecto­ciaa.com.ar )

R.08 (Anulado. Mantener para conservar la numeración).

R.09 El   firmware   modificado   debe   poder   superar   labatería   de   tests   unitarios  presentes   en   elfirmware en la misma medida en la que lo hace elfirmware de referencia. Fuente: Web Proyecto CIAA ( http://www.proyecto­ciaa.com.ar ), intercambio por correo con MarianoCerceiro.

R.10 Al   finalizar   el   proyecto   debe   existirdocumentación que explicite las característicasde   los   recursos   de   hardware   asumidos   en   laimplementación   del   firmware   modificado,incluyendo mapa de memoria esperado, ocupación dememoria, bloques IP utilizados, asignaciones defuncionalidad a los pines de puertos de propósitogeneral, tasa por defecto de la UART. Fuente: Experiencia personal.

R.11 Al   finalizar   el   proyecto   debe   existirdocumentación que indique la configuración básicadel entorno de desarrollo utilizado para compilarel firmware portado, incluyendo versión de loscompiladores   y   demás   software   utilizado   paragenerar la imagen binaria del firmware.Fuente: Experiencia personal.

R.12 Al finalizar el proyecto el firmware modificadodebe   ser   capaz   de   ejecutar   correctamente   elejemplo  blinking  (provisto   con   la   versión   dereferencia del firmware) en una versión de pruebadel hardware.Fuente: Necesario para cumplir los criterios deaceptación.

R.13 El proyecto debe alcanzar su conclusión antes definalizada la primera quincena de diciembre de2015.Fuente: Necesario para cumplimentar la exigenciasde aprobación del trabajo final de la Carrera deEspecialización en Sistemas Embebidos.

5

Análisis de Factibilidad Técnica

Se cuenta con la información, los equipos y los recursos humanosformados necesarios para la ejecución del proyecto. Además, elfirmware   del   proyecto   CIAA   ha   sido   portado   a   múltiplesarquitecturas   de   hardware   y   cuenta   por   lo   tanto   con   unainfraestructura adecuada para este tipo de modificaciones.

Análisis de Factibilidad Financiera­Económica

El   desarrollo   del   proyecto   no   requiere   de   fuentes   definanciamiento   externas,   ni   de   presupuesto   para   la   compra   deequipo. Los costos de personal y transporte serán cubiertos en sutotalidad por el ejecutor. 

Work Breakdown Structure (WBS)

 1  Iniciación de proyecto 1.1  Realización TPs Gestión de Proyectos

 2  Puesta en marcha 2.1  Recopilación de información

2.1.1 Lectura Firmware Coding Guidelines 2.1.2  Estructura del repositorio de proyecto 2.1.3  Sistema de compilación proyecto CIAA 2.1.4  Sistema de tests de regresión CIAA 2.1.5  Sistema de control de versiones Git

 2.2  Instalación herramientas de desarrollo del hardware 2.3  Generación modelo de desarrollo del hardware

 2.3.1  Definición   de   características   de   modelo   dedesarrollo

 2.3.2  Implementación del modelo de desarrollo 3  Ejecución

 3.1  Desarrollo 3.1.1  Port OSEK LEON 3 3.1.2  Drivers LEON 3 3.1.3  Actualización del sistema de compilación

 3.2  Verificación 3.2.1  Verificar corrida de tests de regresión de OSEK 3.2.2  Verificar   funcionamiento   programa   "blinking"   en

modelo de desarrollo 3.3  Documentación

 3.3.1  Documentación externa 3.3.1.1  Documentación hardware modelo de desarrollo 3.3.1.2  Documentación entorno desarrollo

 3.3.2  Documentación interna 3.3.2.1  Documentacion doxygen

 4  Cierre de proyecto

6

 4.1.1  Escritura borrador tesis 4.1.2  Revisión borrador tesis 4.1.3  Versión final tesis

Diagrama Activity­on­Node

Utilizando una aproximación de división del proyecto en fases parareducir la complejidad se establecieron hitos intermedios a cadauna de las fases del WBS que son luego utilizados como dependenciapara las actividades posteriores. 

El diagrama de actividades resultante se ve en las figuras de laspáginas siguientes. 

Los caminos críticos del proyecto son tres debido a la igualdad enlas duraciones de todas as actividades dentro de 3.3:

1.1   2.1.5   2.3.1   2.3.2   3.2.2   3.3.1.1   4.1.1→ → → → → → 4.1.2   4.1.3→ →

1.1   2.1.5   2.3.1   2.3.2   3.2.2   3.3.1.2   4.1.1→ → → → → → 4.1.2   4.1.3→ →

1.1   2.1.5   2.3.1   2.3.2   3.2.2   3.3.2.1   4.1.1→ → → → → → 4.1.2   4.1.3→ →

Un camino semi­crítico posible es el que en lugar de pasar por2.1.5 pasa por 2.1.4 o 2.1.3, como en 

1.1   2.1.3   2.3.1   2.3.2   3.2.2   3.3.1.1   4.1.1→ → → → → → 4.1.2   4.1.3→ →

ya que si la actividad se atrasa más que 0.5 días adicionales,este camino se convierte en el determinante de la duración delproyecto.

El   análisis   anterior   no   considera   la   limitación   de   recursoshumanos para llevar a cabo el proyecto (asume que todas las tareasno dependientes pueden realizarse en paralelo).

7

8

9

Diagrama de Gantt

Para la realización del diagrama de Gantt se asumió un una únicapersona   a   cargo   de   todas   las   tareas   del   proyecto,   con   unadedicación de dos días por semana.

10

11

12

Matriz de Recursos Materiales y Presupuesto

Plan de Gestión de Riesgos

Descripción de riesgos:

Riesgo 1Descripción: Imposibilidad de acceder a un kit de desarrollo de

FPGA   para   realizar   el   modelo   de   desarrollo   dehardware   de   la   Edu­CIAA   Xilinx   a   tiempo   paracomenzar el desarrollo.

Probabilidad: Muy baja. Existen múltiples kits de desarrollo deFPGA disponibles en la UNLP. 

Impacto: Menor.   Aunque   no   es   recomendable,   la   etapa   decodificación   puede   comenzar   antes   de   tener   elmodelo de desarrollo para hacer las pruebas sobreéste.

Detección: Muy probable. Se puede anticipar la disponibilidadde   los   equipos   con   tiempo   y   planificar   suutilización.

13

Actividad Tiempo total Computadora

1.1 Trabajos prácticos gestión de proyectos 4 días 4 días2.1.1 Lectura firmware Coding Guidelines 0.25 días 0.25 días2.1.2 Estructura del repositorio de proyecto 0.25 días 0.25 días2.1.3 Sistema de compilación proyecto CIAA 0.5 días 0.5 días2.1.4 Sistema de tests de regresión CIAA 0.5 días 0.5 días2.1.5 Sistema de control de versiones Git 1 día 1 día2.2 Instalación herramientas de desarrrollo del hardware 1 día 1 día2.3.1 Definición de características de modelo de desarrollo 2 días2.3.2 Implementación del modelo de desarrollo 3 días 3 días 3 días3.1.1 Port OSEK LEON 3 4 días 4 días 4 días3.1.2 Drivers LEON 3 5 días 5 días 5 días3.1.3 Actualización del sistema de compilación 1 días 1 día3.2.1 Verificar corrida de tests de regresión de OSEK 1 día 1 día3.2.2 Verificar funcionamiento programa "blinking" en modelo de desarrollo 3 días 3 días 3 días3.3.1.1 Documentación hardware modelo de desarrrollo 1 día 1 día3.3.1.2 Documentacion entorno desarrollo 1 día 1 día3.3.2.1 Documentacion doxygen 1 día 1 día4.1 Escritura borrador tesis 4 días 4 días4.2 Revisión borrador tesis 10 días4.3 Versión final tesis 2 días 2 días

Kit desarrollo FPGA

Categoría Detalle CostoTrabajo directo Desarrollador (284 hs x $100/hs) 28400

Total Costos Directos 28400Costos Indirectos Transporte LP-BSAS 832

Total Costos Indirectos 832

Total 29232

Riesgo 2Descripción: Pérdida de prioridad del proyecto frente a otros

compromisos laborales.Probabilidad: Alta.Impacto: Crítico. No se  cumplen con los hitos de avance, la

duración   del   proyecto   se   alarga   y   se   corre   elriesgo   de   no   cumplir   con   la   fecha   de   entregapactada.

Detección: Muy probable. En general es posible anticipar loscompromisos y determinar que la disponibilidad detiempo se va a volver un problema.

Riesgo 3Descripción: Imposibilidad de completar las tareas de desarrollo

(port de sistema operativo, drivers y modificacióndel sistema de compilación) en el plazo establecido(10 días dedicados).

Probabilidad: Baja.Impacto: Significativo. De acuerdo con el plan de gestión de

tiempos es posible el atraso del trabajo en hasta10 días dedicados (aproximadamente un mes lineal)antes de que el atraso impacte sobre la fecha decierre.

Detección: Imposible. No se puede anticipar este riesgo antesde que se manifieste.

Riesgo 4Descripción: La   implementación   del   modelo   de   desarrollo   del

hardware utilizando un kit de desarrollo de FPGA esuna actividad novedosa,   y puede tomar más tiempodel previsto (3 días dedicados).

Probabilidad: Baja.Impacto: Significativo. Detección: Muy probable. Ya en las etapas de recolección de

información previas se puede anticipar el nivel dedificultad que va a significar la actividad.

Riesgo 5Descripción: Que la revisión de la primera versión de la tesis

del trabajo final se demore más tiempo del previsto(10 días dedicados) por falta de tiempo de partedel tutor. 

Probabilidad: Baja.Impacto: Significativo. De acuerdo con el plan de gestión de

tiempos es posible el atraso del trabajo en hasta10 días dedicados (aproximadamente un mes lineal)antes de que el atraso impacte sobre la fecha decierre.

14

Detección: Imposible. No se puede anticipar este riesgo.

Estrategia de gestión de riesgos

A partir de un análisis de los riesgos anteriores se concluyó quees conveniente delinear una estrategia para lidiar con los riesgos2, 3 y 5, de forma tal de minimizar la probabilidad de que afectenal desarrollo del proyecto. 

Riesgo 2Estrategia: Mitigar los efectos con una estrategia de avance

defensiva,   adelantando   hitos   respecto   de   loestipulado de forma oportunista cada vez que existala posibilidad, para de esa forma hacer lugar afuturos potenciales atrasos.

Modificación: Esto   puede   reducir   el   impacto   de   Crítico   aSignificativo.

Riesgo 3Estrategia: Idem Riesgo 2.Modificación: Se   puede   reducir   el   impacto   de   Significativo   a

Menor.

Riesgo 5Estrategia: Mantener   la   extensión   de   la   tesis   breve,   y   el

contenido   sintético  para   minimizar   el   tiempo   quetoma la corrección. Realizar un proceso intenso derevisión del texto antes de enviárselo al tutor,para minimizar la cantidad de correcciones. 

Modificación: Se   puede   reducir   la   probabilidad   de   que   semanifieste el riesgo de Baja a Muy Baja.

Risk Priority Number (RPN) usando estrategia de gestión de riesgos

15

RiesgoProbabilidad Impacto Detección

RPNCualitativo Cuantitativo Cualitativo Cuantitativo Cualitativo Cuantitativo

Riesgo 1 Muy Baja 0.1 Menor 1 Muy Probable 0.33 0.033Riesgo 2 Alta 0.7 Significativo 10 Muy Probable 0.33 2.31Riesgo 3 Baja 0.3 Menor 1 Imposible 0.9 0.27Riesgo 4 Baja 0.3 Significativo 10 Muy Probable 0.33 0.99Riesgo 5 Muy Baja 0.1 Significativo 10 Imposible 0.9 0.9

Muy Baja Baja Media Alta Muy AltaProbabilidad 0.1 0.3 0.5 0.7 0.9

Menor Significativo Crítico CatastróficoImpacto 1 10 100 1000

Imposible Improbable Muy probable SeguraDetección 0.9 0.66 0.33 0.1

Nota:  Detección   está   cuantificado   como   la   probabilidad   de  NOdetección. 

Plan de Gestión de Calidad

Los Costos de Conformidad del proyecto se encuentran asociadosfundamentalmente a la inversión de tiempo y esfuerzo necesariapara garantizar el cumplimiento de los requerimientos con un nivelde calidad adecuado, ya que en su formato actual el proyecto nodepende de ningún tipo de erogación económica para poder cumplirlos requerimientos (compra de equipos, entrenamiento de personal,etc.).

Los Costos de No Conformidad, por otro lado, se pagarán en laforma de tiempo invertido para realizar mantenimiento del códigoen   el   futuro   en   caso   de   que   se   encuentren   errores,   futurasiteraciones   de   la   documentación   para   completar   o   aclarar   lospasajes que puedan considerarse inadecuados, etc. 

Plan de Verificación y Validación

La verificación se lleva a cabo durante el desarrollo del códigodel  port,  para   comprobar   la   correcta   implementación   de   losfragmentos   de   código,   algoritmos   y   configuraciones   auxiliares(sistema de compilación) que sean necesarios. El análisis estáticode código es la primera instancia de defensa frente a problemas enla programación, seguido de la verificación manual mediante casosde ensayo. El firmware CIAA cuenta con su propio set de tests quepermiten   verificar   de   forma   automatizada   grandes   secciones   delcódigo de mismo para detectar que las modificaciones realizadas nointroduzcan problemas en el código preexistente. 

La   validación,   por   otro   lado,   se   lleva   a   cabo   verificando   elcumplimiento de cada uno de los requerimientos enunciados para elproducto del proyecto, así como verificando la conformidad de loscriterios de aceptación del mismo. 

Plan de Comunicación

La naturaleza prácticamente unipersonal del proyecto descripto poreste documento hace innecesaria la utilización de una gestión de comunicación muy compleja. 

La   comunicación   es   principalmente   de   tipo   externo,   pudiéndoseseñalar los siguientes tipos de comunicación necesarios para eldesarrollo del proyecto:

1. De seguimiento de avances, entre el ejecutor y el tutor delproyecto. 

16

2. De coordinación y consulta, entre el ejecutor y los miembrosdel grupo de trabajo que lleva adelante el desarrollo delfirmware CIAA y del hardware de la Edu­CIAA Xilinx. 

En   el   primer   caso   el   seguimiento   de   avances   puede   realizarsemediante informes mensuales donde se detalle el estado de avancedel proyecto, demoras, problemas pendientes, actividades futuras,etc. 

Estas comunicaciones serían iniciadas por el ejecutor, pudiendo ono recibir una devolución de parte del tutor en función de lostemas tratados en cada entrega. Por su formato y contenido estas comunicaciones de seguimiento deavances pueden realizarse mayormente mediante correo electrónico,o bien en caso de ser necesaria para una discusión más interactivasobre   un   tópico   en   particular   es   posible   coordinar   reunionespersonales entre el ejecutor del proyecto y el tutor. 

En el segundo tipo de comunicación externa, el canal es aún másinformal que el primero y no tiene una periodicidad establecida.Su ejecución es en función de las necesidades de avance, paraobtener   información   adicional   sobre   elementos   del   software   ohardware de trabajo. El canal de comunicación en este caso seráintercambios directos con los miembros de los equipos del firmwareo   hardware   Edu­CIAA   Xilinx,   o   bien   preguntas   abiertas   en   laslistas de correo de dichos proyectos. 

Gestión de Recursos Humanos

Matriz de Asignación de Responsabilidades

17

P = Responsabilidad Primaria S = Responsabilidad Secundaria A = Aprobación 

Gestión de Compras

Selección de proveedores

Este trabajo no tiene proveedores. 

En caso de que los tuviera, y teniendo más de uno en condicionesde cumplir con los requisitos de tiempo y costo de un producto oservicio dado, puedo elegir entre ellos planteando un  árbol dedecisión.

En este árbol se enumeran para cada uno de los proveedores todoslos posibles resultados de realizar la compra a través de ellos(atrasos, adelantos, problemas de calidad), cuantificados por elcosto   final   de   cada   opción   individual   (costo   del   producto   másdiferencial debido a ganancia/pérdida adicional por entrega fuerade término, perjuicio por calidad defectuosa, etc.) y asignando acada alternativa una probabilidad de ocurrencia

Finalmente para cada proveedor se calcula la esperanza del costofinal   de   contratarlo   como   la   suma   de   los   productos   entre   loscostos finales de cada alternativa y su probabilidad de ocurrenciaasociada. 

18

Actividad

1.1 Trabajos prácticos gestión de proyectos P A2.1.1 Lectura firmware Coding Guidelines P2.1.2 Estructura del repositorio de proyecto P2.1.3 Sistema de compilación proyecto CIAA P2.1.4 Sistema de tests de regresión CIAA P2.1.5 Sistema de control de versiones Git P2.2 Instalación herramientas de desarrrollo del hardware P2.3.1 Definición de características de modelo de desarrollo P S2.3.2 Implementación del modelo de desarrollo P3.1.1 Port OSEK LEON 3 P3.1.2 Drivers LEON 3 P3.1.3 Actualización del sistema de compilación P3.2.1 Verificar corrida de tests de regresión de OSEK P3.2.2 Verificar funcionamiento programa "blinking" en modelo de desarrollo P3.3.1.1 Documentación hardware modelo de desarrrollo P A3.3.1.2 Documentacion entorno desarrollo P3.3.2.1 Documentacion doxygen P4.1 Escritura borrador tesis P4.2 Revisión borrador tesis P4.3 Versión final tesis P A

Gerardo Puga

Ariel Lutemberg

Pedro Martos

El proveedor que tenga la esperanza de costo final más baja es lamejor opción.

Statement of Work

Este trabajo no tiene proveedores. 

Suponiendo que tercerizara la creación del modelo de desarrollodel hardware que se utilizará para trabajar, un Statement of Workposible podría ser la siguiente.

25 de Mayo de 2015

Por la presente se encarga el trabajo de desarrollo de un modelode  ingeniería del hardware de la Edu­CIAA Xilinx con el fin deser utilizado para el desarrollo de un firmware compatible con elmodelo de hardware definitivo de la misma. 

Entregables: Hardware del modelo. Diseño del hardware realizado.Guía de usuario. 

Prop. intelectual:Todos   los   derechos   de   propiedad   intelectualsobre el diseño pertenecen al adquiriente.

Plazo de entrega: 30 días a partir de la fecha. 

Forma de Pago: Efectivo.   40%   por   adelantado   a   fecha   decontrato,   y   lo   restante   sobre   entrega   delproducto final. 

Garantía:  Seis   meses   de   garantía   desde   la   entrega.   Lagarantía   cubre   tanto   vicios   en   el   hardwareentregado, como también defectos en el  diseñobase   del   mismo   y   en   la   documentación   queacompaña.

Firma del Proveedor Firma del Responsable

Procesos de Control y Seguimiento

Para llevar a cabo un seguimiento del grado de avance del proyecto

19

se evaluará periódicamente la cantidad y tipo de actividades quehan sido completadas satisfactoriamente, así como el estado deavance   de   las   que   hayan   sido   comenzadas.   Este   registro   secomparará con el cronograma estimado presente en el diagrama deGantt, analizando el impacto de cualquier divergencia entre elestado   real   y   el   previsto   del   proyecto   en   el   momento   deevaluación.

Procesos de Cierre

Una vez completadas todas las actividades previstas como parte dela   ejecución   del   proyecto,   es   necesario   realizar   un   cierreordenado del mismo que incluya las siguientes actividades finales:

• Análisis del desarrollo del proyecto, evaluando el nivel deaproximación entre el plan original contra los registros deejecución efectiva del proyecto, así como las razones de lasdiferencias.

• Devolución de todo el material que haya sido adquirido enpréstamo   para   la   ejecución   del   proyecto   (documentos,hardware, etc).

• Archivo de toda la información relativa al proyecto. • Archivo de la tesis de proyecto.

20