10-7-2015
Profesor: Dr. Ariel Lutenberg Alumno:
Ricardo Pafundi DNI: 17.833.525
SOFTWARE EDUCATIVO
EDU-CIAA-NXP
Tabla de contenidos
Índice de contenido
:
-Project Charter
…...2
-Propósito del proyecto
...2
-Objetivos del proyecto
...2
- General
………..……..….……...2
- Especifico
……….………..…..………...3
-Análisis de los interesados (stakeholders)
...3
-Requerimientos
...3
-Alcance del proyecto
...4
-Justificación
………...…..……….4
-Estructura de desglose del trabajo
...5
-Planificación
………..….…...6
-Gestión de Costos
………...6
-Gestión de Riesgos
...6
Riesgos
...8
Consecuencias
………...8
Rpn asociado a cada riesgo
………..…...…9
Plan para mitigar riesgos
………..…………...9
-Gestión de calidad
…...9
Costos de Conformidad
……….………..…10
Costos de no conformidad
...10
-Gestión de compras
………...11
-Plan de control y segumiento
...11
1.- Project Charter.
CABA, 20 de Abril de 2015.-
De mi consideración:
Con el fin de comenzar los trabajos necesarios para el proyecto de análisis de la factibilidad del diseño, desarrollo e implementación de un software, de interface entre la EDU-CIAA y la comunidad educativa, que facilite la utilización de la placa, se asigna este proyecto al Ing. Ricardo Pafundi, quien actuara como gerente del proyecto y de quien se espera que a la fecha de finalización del trabajo, entregue la documentación técnica en la cual se expliciten los tiempos y costos necesarios de la fabricación de dicho sistema. La fecha de finalización para el estudio de factibilidad está estipulada para el 22 de mayo del corriente año.
Sin más, lo saluda atte.
Roberto González
Director de Inversiones estratégicas
2.- Propósito del proyecto
Con el desarrollo de este software se lograra el refuerzo del aprendizaje, siendo necesario para la implementación y uso de esta herramienta, poseer un mínimo de
conocimientos prácticos en microcontroladores y programación por parte del docente, ya que será el, en la mayoría de los casos, quien motive y promueva la utilización del
software, así mismo sobre su orientación en la situación en que alguna duda pueda presentarse.
3.- Objetivos del Proyecto.
General
:Desarrollar un software didáctico para la EDU-CIAA, aplicable a alumnos secundarios / terciarios y público en general.
Específicos
:i. Conocer otros software didácticos similares. ii. Definir los requerimientos del Software. iii. Realizar las pruebas necesarias.
iv. Implantar el software.
4.-Analisis de los interesados
Client:
- Instituciones educativas, con orientación electrónica, mecánica o industrial. Sponsor:
-Ricardo Pafundi. End-User:
- Alumnos secundarios.
- Alumnos de Formación Profesional.
- Docentes de Escuelas Secundarias y Formación Profesional. - Hobbista o entusiastas de la electrónica.
Champion: - Ricardo Pafundi Drivers: - Ariel Lutenberg. Project manager: - Ricardo Pafundi. Team members: -Ricardo Pafundi.
5.-
Requerimientos
Del Producto: - Técnicos. - Funcionales. - Seguridad. - Performance. - De mantenimiento y entrenamiento.Del Proyecto:
- De Gestión del proyecto. - De entregas.
- Criterios de aceptación.
6.-
Alcance del Proyecto
Con el desarrollo de este software se lograra el refuerzo del aprendizaje, siendo necesario para la implementación y uso de esta herramienta, poseer un mínimo de
conocimientos prácticos en microcontroladores y programación por parte del docente, ya que será el, en la mayoría de los casos, quien motive y promueva la utilización del
software, así mismo sobre su orientación en la situación en que alguna duda pueda presentarse.
7.- Justificación
Incrementar el rendimiento estudiantil en sistemas embebidos, en los futuros periodos de aprendizaje y refuerzo del conocimiento. La idea de implementar el uso de las TICs, (Tecnologías de información y comunicación) va de acuerdo a los procesos de cambios dados en el ámbito educativo, los cuales nos obligan estar al pendiente en el ámbito de las nuevas tecnologías (NT) o de las tecnologías de la información aplicadas a la educación, lo que con lleva a la utilización de nuevos medios para la enseñanza y los profesionales involucrados en el sector educativo, quienes necesitan herramientas adecuadas para enfrentar y reforzar el aprendizaje.
8.- Restricciones
Cabe destacar, que esta herramienta será un complemento a la comprensión de la materia y que en ningún momento pretenderá ser sustituto en el aprendizaje guiado por parte del docente, es por ello que desea convertirse en un refuerzo y recurso libre y abierto a nuevos cambios y opiniones de las partes por las cuales será utilizado.
9.- Estructura de desglose del trabajo.
2.0 Desarrollo del Producto
2.1 Preparación
2.1.1 Recepcion del Hardware
2.1.2 Recepcion del Software
2.1.3 Instalación y configuración
2.1.4. Pruebas Técnicas
2.2 Diseño de Arquitectura de Software
2.2.1 Capas de Software
2.2.2 Definición de interface
2.2.3. Programación de funciones
2.2.4 Programación de APIs
2.2.5. Integración
2.3 Implementación software en EDU-CIAA-NXP
2.3.1 Estudio de formatos de entrada
2.3.2 Implementación cargar datos
2.3.3 Desarrollo de interfaz grafica
10.- Planificación
11.- Gestión de Costos
WBS – NOMBRE DE LA TAREA Hs. Hombre Costo
1.1 Definición de Requerimientos y Alcances. 10 1.500
1.2 Elaboración y aprobación del acta. 5 750
1.3 Secuencia de Actividades. 15 2.250
1.4 Establecer Cronograma. 10 1.500
1.5 Calculo de Actividades. 10 1.500
1.6 Calculo de Costos. 10 1.500
1.8 Adquisición del Software SCRATCH. 10 1.500
1.9 Reunión de Seguimiento. 30 4.500
2.1.1 Recepcion del Hardware. 25 3.750
2.1.2 Recepcion del Software. 25 3.750
2.1.3 Instalación y Configuración. 50 15.000 2.1.4 Pruebas Técnicas. 50 15.000 2.2.1 Capas de Software. 25 7.500 2.2.2 Definición de Interface. 25 7.500 2.2.3 Programación de Funciones. 50 15.000 2.2.4 Programación de APIS. 75 22.500 2.2.5 Integración. 50 15.000
2.3.1 Estudio de formato de datos de entrada. 25 7.500
2.3.2 Implementación de carga de datos. 25 7.500
2.3.3 Desarrollo interfaz gráfica. 25 7.500
2.3.4 Estudio y prueba de algoritmos. 25 7.500
2.4.1 Prueba unitaria. 25 7.500
2.4.2 Puesta a punto. 30 9.000
2.4.3 Testeo en Sistema Windows. 30 9.000
3.1 Verificación de estabilidad y Software . 10 3.000
3.2 Prueba de integración de software final. 10 3.000
3.3 Documentación del sistema. 5 750
3.4 Entrega manual del usuario de programa. 5 750
Se tomó como valor de $ 150.- la hora de trabajo no relacionada con la programación, y $ 300.- la hora de programación.
Costo de mano de obra. $ 24.750.-
Costo de mano de programación $ 159.000.-
TOTAL $ 183.750.-
12.- Gestión de Riesgos
1) Problemas con la interfaz. 2) Congelamiento del sistema. 3) Respuesta negativa del usuario.
4) Error en la estimación de la duración de las tareas. 5) Mal funcionamiento del hardware-software.
Estimación de consecuencias:
Rpn asociado a cada riesgo.
Plan para mitigar riesgos.
Evento de riesgo
Respuesta
Plan de contingencia
Problemas con la interfaz Reducir Darle la vuelta hasta que
pueda encontrarse otra opinión
Congelamiento del sistema Reducir Reinstalar el SO
Respuesta negativa del usuario Reducir Aumentar el soporte,
demostrar capacidades, beneficios, utilidades.
Mal funcionamiento del equipo Transferir Probar con otra placa
Error en el tiempo de tareas Reducir Restructuración de los
tiempos
13.- Gestión de Calidad
Calidad: Definición de la norma ISO 9000: “Calidad: grado en el que un conjunto de características inherentes cumple con los requisitos”.[
1.9 Reunión de Seguimiento.
3.1 Verificación de estabilidad y Software 3.2 Prueba de integración de software final
Las reuniones de seguimiento tienen como función no solo, validar el cumplimiento de los tiempos, sino también verificar que se cumple con los requisitos inherentes al producto, que se está desarrollando, estas reuniones son en un total de 6 (seis) que se intercalan en la vida total del proyecto. Cerrando con la calidad de conformidad y de uso, reflejado en la Verificación de estabilidad y Prueba de integración final del software.
Grado de Calidad: El grado de calidadindica las diferencias entre productos o servicios con el mismo uso funcional.
2.1.4 Pruebas Técnicas. 2.4.2 Puesta a punto
2.4.3 Testeo en Sistema Windows
Para determinar el grado de calidad siempre es necesario comparar con otros servicios que cumpla con las mismas condiciones. Algo parecido es lo que se hace con Arduino, y en su momento Nxp, con el LPC812, pero no hay nada de estas
características (en relación al hardware utilizado) que cumpla no solo con la faz educativa apta para todos los niveles sino adaptado también a la industria.
-Costos de conformidad:
- Entrenamiento (prevención) Se minimizo, buscando mano de obra calificada, por eso se fijó la hora de desarrollo de software en $ 300.-, para evitar demoras y costos extras relacionadas con la capacitación.
- Documentación de procesos (prevención). Se tiene en cuenta cuando se realizan las reuniones de seguimiento.
- Equipamiento (prevención). Se adquirió la placa sobre la cual se va a trabajar, en cuanto al software se realizara con aquellos que son open source
“Tiempo y recursos para hacer las cosas bien”.
- Realización de ensayos (evaluación). Previstas que se realicen durante toda la vida del proyecto.
- Inspecciones (evaluación). Contempladas en la realización de ensayos.
Costos de no conformidad
Estos costos no se tienen en cuenta, puesto de manifiesto en los diversos puntos de control incluidos durante todo el proyecto, verificación de estabilidad, pruebas de integración, puesta a punto, testeo sobre el sistema operativo Windows.
14.- Gestión de Compras
En este proyecto no se aplica la gestión de compras, no hay nada que comprar.
15.- Plan de control y seguimiento
La duración de las tareas está programada en horas/hombre pero siempre en cantidades que quepan en una o varias semanas laborables. Por lo tanto, al final de cada semana se cotejará el estado de avance contra la planificación.
Dado que la mayoría de las tareas está en el camino crítico de la planificación, es importante detectar lo más pronto posible cualquier retraso en la ejecución de modo de poder tomar acciones correctivas.
16.- Proceso de Cierre.
El principal proceso de cierre consiste en determinar en qué medida se cumplió con la planificación inicial. Por lo tanto se cotejará el tiempo de concreción de cada tarea contra su estimación inicial, en busca de fallas en dichas estimaciones.
Se verificará si se materializaron los riesgos contemplados en el plan de gestión, si fue eficaz su plan de mitigación y si se presentaron riesgos no contemplados.
Se verificará si fue adecuada la cantidad de horas invertidas en planificación del proyecto y su impacto respecto a las horas invertidas en ejecución del mismo.
Con estos tres análisis se espera obtener una metodología probada de selección y planificación de proyectos
