Project Charter

ESCUELA DE INGENIERÍA DE SISTEMAS CURSO: PROYECTO DE INVESTIGACION III TEMA: PRESENTADO POR:  GAMARRA PEÑALVA, RELY OMAR SEMESTRE: IX DOCENTE:  ING. VICTOR MANUEL CORNEJO APARICIO AREQUIPA – PERÚ 2013

1

INDICE GENERAL 1.

PROJECT CHARTER....................................................................................... 3

2.

DOCUMENTAR REQUISITOS.............................................................................. 7

3.

PLAN DE GESTION DE REQUISITOS..................................................................11

4.

MATRIZ DE TRAZABILIDAD DE REQUISITOS DE PROYECTO.....................................13

5.

PLAN DE GESTIÓN DE ALCANCE......................................................................14

6.

WBS DEL PROYECTO.................................................................................... 16

7.

DICCIONARIO WBS (completo)..........................................................................21

8.

RED DEL PROYECTO.................................................................................... 45

9.

CRONOGRAMA DEL PROYECTO.......................................................................50

10. GESTIÓN DE COSTOS................................................................................... 54 11. PLAN DE GESTIÓN DE LA CALIDAD...................................................................58 12. PLAN DE GESTIÓN DE RIESGOS......................................................................63 13. PLAN DE RESPUESTA A LOS RIESGOS...............................................................68 14. PLAN DE GESTIÓN DE CAMBIOS......................................................................72 15. PLAN DE GESTIÓN DE LA CONFIGURACIÓN.........................................................75 16. PLAN DE GESTIÓN DE COMUNICACIONES..........................................................78 17. MÉTRICAS DE CALIDAD DEL PRODUCTO............................................................82 18. LÍNEA BASE DE LA CALIDAD............................................................................83 19. PLAN DE GETSION DE ADQUISICIONES..............................................................84 20. CIERRE DE PROYECTO................................................................................. 88 I

2

NDICE DE GRAFICAS GRAFICA 1 WBS............................................................................................................................................17 GRAFICA 2 FASE DE INICIO...........................................................................................................................18 GRAFICA 3 FASE DE PLANEAMIENTO...........................................................................................................18 GRAFICA 4 FASE DE ANALISIS Y DISEÑO.....................................................................................................19 GRAFICA 5 FASE DE CONSTRUCCION.........................................................................................................20 GRAFICA 6 FASE DE CIERRE.......................................................................................................................21 GRAFICA 7 RED Nº1 (PRIMERA PARTE).........................................................................................................46 GRAFICA 8 RED Nº2 (SEGUNDA PARTE)........................................................................................................47 GRAFICA 9 RED Nº3 (TERCERA PARTE)........................................................................................................47 GRAFICA 10 RED Nº4 (CUARTA PARTE).........................................................................................................47 GRAFICA 11 RED Nº5 (QUINTA PARTE)..........................................................................................................48 GRAFICA 12 RED Nº6 (SEXTA PARTE)...........................................................................................................48 GRAFICA 13 RED Nº7 (SEPTIMA PARTE).......................................................................................................49 GRAFICA 14 RED Nº8 (OCTAVA PARTE).........................................................................................................49 GRAFICA 15 RED Nº9 (NOVENA PARTE)........................................................................................................50 GRAFICA 16 RED Nº10 (DECIMA PARTE).......................................................................................................50 GRAFICA 17 DISEÑO DEL CIRCUITO ELECTRONICO CON LOS COMPONENTES CORRESPONDIENTES......92 GRAFICA 18 DISEÑO DE LAS PISTAS DEL CIRCUITO ELECTRONICO............................................................93 GRAFICA 19 DIAGRAMA DE CASO DE USO...................................................................................................94 GRAFICA 20 DIAGRAMA DE CLASES.............................................................................................................94 GRAFICA 21 DIAGRAMA DE SECUENCIA CONTROL DE LA SILLA..................................................................95 GRAFICA 22 DIAGRAMA DE SECUENCIA DEFINIR COMANDOS.....................................................................96 GRAFICA 23 FORMULARIO PRINCIPAL........................................................................................................102 GRAFICA 24 FORMULARIO PRINCIPAL MOSTRANDO EL MENU COMANDOS..............................................102 GRAFICA 25 FORMULARIO PRINCIPAL MOSTRANDO EL MENU CONTROL.................................................103 GRAFICA 26 FORMULARIO DE COMANDOS................................................................................................105 GRAFICA 27 FORMULARIO DE CONTROL...................................................................................................109

INDICE DEL CODIGO CODIGO 1 CÓDIGO DEL PIC..........................................................................................................................97 CODIGO 2 SCRIPT DE LA BASE DE DATOS.................................................................................................101 CODIGO 3 PRINCIPAL.CS............................................................................................................................104 CODIGO 4 COMANDOS.CS..........................................................................................................................106 CODIGO 5 CONTROL.CS.............................................................................................................................110

3

1. PROJECT CHARTER NOMBRE DEL PROYECTO SIGLAS DEL PROYECTO PROTOTIPO DE UN SISTEMA DE MANEJO PSVOZ PARA UNA SILLA DE RUEDAS UTILIZANDO UN MODULO DE PROCESAMIENTO DE VOZ DESCRIPCIÓN DEL PROYECTO: ¿QUÉ, QUIÉN, CÓMO, CUÁNDO Y DÓNDE? El proyecto “PROTOTIPO DE UN SISTEMA DE MANEJO PARA UNA SILLA DE RUEDAS UTILIZANDO UN MODULO DE PROCESAMIENTO DE VOZ”, ayudara a personas con discapacidades motrices o que no cuentan con los miembros superiores para su desplazamiento debido a que las personas con este tipo de discapacidades no pueden utilizar sus miembros superiores para poder maniobrar una silla de ruedas convencional y por ende la manipulación y control clásico de estos implementos. Este proyecto está orientado a mejorar la calidad de vida ofreciendo un amplio rango de aplicaciones como la ayuda a la manipulación o la movilidad para personas con problemas motrices. El proyecto comprende el diseño y construcción de un prototipo de una silla de ruedas hasta la construcción de un software que realice el control autónomo guiado por voz, basada en la identificación de comandos por parte del usuario donde el resultado será el movimiento de la silla de ruedas. Los comandos de voz ayudaran a que se realicen los siguientes movimientos : -

Adelante. Atrás. Izquierda. Derecha. Alto.

El proyecto será realizado desde el 22 de abril de 2013 hasta 21 de octubre de 2013, la gestión del proyecto se realizará en las instalaciones de la Universidad Alas Peruanas por el equipo de proyecto. DEFINICIÓN DEL PRODUCTO DEL PROYECTO: DESCRIPCIÓN DEL PRODUCTO, SERVICIO O CAPACIDAD AGENERAR. El producto es una silla de ruedas que pueda desplazarse utilizando comandos de voz. El producto constará de dos partes principales. A esta primera construcción se le denominara: Modulo de procesamiento de voz que consiste en la construcción del software el cual utilizara los comandos de voz que pueden ser una letra o una palabra identificando para si los siguientes movimientos: “adelante”, “atrás”, “izquierda”, “derecha”, “alto”. Utilizando para tal fin una interfaz de usuario que permita el ingreso de los respectivos comandos desarrollado en una plataforma .NET. El módulo de procesamiento de voz debe utilizar un micrófono para poder ingresar el comando de voz convirtiendo de esta manera la señal de voz en información reconocible por la red neuronal. La segunda parte será el diseño y construcción de un prototipo de silla de ruedas. Los bloques utilizados en esta parte son los siguientes: a) Circuito de control. b) Circuito de potencia. El circuito de control debe controlar los motores de acuerdo a la técnica de control de velocidad por PWM 4

(Modulación por anchura de pulso) acción ejecutada por un microcontrolador PIC el cual genera una señal PWM que exista a los dispositivos de potencia y controla la velocidad y sentido de giro de los motores. El circuito de potencia deberá cumplir las funciones de protección y aislamiento entre los circuitos de control y potencia usando los optoacopladores 4n33. DEFINICIÓN DE REQUISITOS DEL PROYECTO: DESCRIPCIÓN DE REQUERIMIENTOS FUNCIONALES, NOFUNCIONALES, DE CALIDAD, ETC., DEL PROYECTO/PRODUCTO.

REQUISITOS FUNCIONALES: 

Utilización de la interfaz de usuario para el entrenamiento de los patrones manejando solo la voz desarrollado en una plataforma .NET.



Presentación de informes mensuales sobre los avances del proyecto para la gestión de proyectos.



Presentación de un documento final que incluya una memoria de las actividades realizadas, resultados alcanzados y todo el material elaborado durante el desarrollo del proyecto.

REQUISITOS NO FUNCIONALES: 

Se usa Framework 4.5



El sistema deberá contar con Sistema operativo Windows 7 o superior.



Disponibilidad: Estar disponible 100% o muy cercano a esta disponibilidad durante el horario hábil laboral a nivel nacional (Lunes a viernes de 8:00 a.m. a 5:00 p.m., con excepción de los días festivos).



Escalabilidad: El producto debe ser construido sobre la base de un desarrollo evolutivo e incremental, de manera tal que nuevas funcionalidades y requerimientos relacionados puedan ser incorporados.

REQUISISTOS DE CALIDAD  

Interfaces simples de entender al momento de entrenar al sistema. Consistencia y robustez de los equipos y software que conformen el producto

OBJETIVOS DEL PROYECTO: METAS HACIA LAS CUALES SE DEBE DIRIGIR EL TRABAJO DEL PROYECTO EN TÉRMINOS DELA TRIPLE RESTRICCIÓN.

CONCEPTO 1. Alcance

2. Tiempo

OBJETIVO Desarrollar un sistema autónomo capaz de movilizar a personas discapacitadas sobre una silla de ruedas, utilizando un simple comando o instrucción de voz. Concluir el proyecto en el plazo determinado.

CRITERIO DE EXITO Artefacto que facilite la movilidad de personas discapacitadas. El proyecto debe ser realizado

5

desde el 22 de abril de 2013 hasta 21 de octubre de 2013. No exceder el presupuesto del proyecto.

3. Costo

Cumplir con el presupuesto del proyecto de S/. 1680.00 FINALIDAD DEL PROYECTO: FIN ÚLTIMO, PROPÓSITO GENERAL, U OBJETIVO DE NIVEL SUPERIOR POR EL CUAL SE EJECUTA EL PROYECTO. ENLACE CON PROGRAMAS, PORTAFOLIOS, O ESTRATEGIAS DE LA ORGANIZACIÓN.



La finalidad del proyecto es ser una alternativa de solución para las personas discapacitadas que no cuenten con los recursos suficientes para adquirir una silla de ruedas elaborada por empresas extranjeras.

JUSTIFICACIÓN DEL PROYECTO: MOTIVOS, RAZONES, O ARGUMENTOS QUE JUSTIFICAN LA EJECUCIÓN DELPROYECTO. JUSTIFICACIÓN CUALITATIVA Una gran sección de la robótica e inteligencia artificial aplicada a la ayuda a los discapacitados está orientada al desarrollo de las sillas de ruedas inteligentes. Estos equipos están orientados a mejorar la calidad de vida ofreciendo un amplio rango de aplicaciones como la ayuda a la manipulación o a la movilidad para personas con problemas motrices. Esta comunicación se centra en la ayuda a movilidad por medio de sillas robóticas inteligentes, las cuales dan un valor añadido a las sillas comerciales motorizadas convencionales. Hay al menos dos factores claves del desarrollo de estos equipos:  

El prototipo de la silla a desarrollar con recursos locales Control del movimiento de la silla mediante instrucciones de voz.

CRONOGRAMA DE HITOS DEL PROYECTO. HITO O EVENTO SIGNIFICATIVO FASE DE INICIO FASE DE PLANEACIÓN FASE DE ANALISIS Y DISEÑO FASE DE CONSTRUCCION FASE DE CIERRE

HITO N°1 INICIANDO PROYECTO HITO N°2 PLANEANDO PROYECTO HITO N°3 DISEÑO HITO Nº4 EJECUCION DEL PROYECTO HITO N°5 CIERRE DEL PROYECTO

FECHA PROGRAMADA 22/04/2013 23/04/2013 16/05/2013 12/06/2013 18/10/2013

ENTREGABLES ( RESULTADOS DEL PROYECTOS)               

Acta de compromiso para el desarrollo de los paquetes firmado por el integrante del equipo de proyecto. Documento con las fechas establecidas para la presentación de los avances realizados en el proyecto aceptado por el sponsor y el jefe de proyectos. Informe con las especificaciones del proyecto. Cronograma de recursos El diagrama de Gantt de actividades El documento donde figuren los responsables para cada uno de los paquetes de trabajo. El documento con los roles de cada uno de las personas del equipo de trabajo. Documentación detallada con la metodología de gestión de riesgos, herramientas. Documentación con el plan de gestión de riesgos del proyecto. Un informe con la lista de riesgos del proyecto ordenado por prioridad y mostrando su probabilidad de ocurrencia e impacto. Un informe con la lista de riesgos del proyecto ordenado por prioridad y mostrando su probabilidad de ocurrencia e impacto. Informe de roles y privilegios. Version acceptable del producto. Documento con las pruebas realizadas y sus resultados. Manual de usuario. 6

OBJETIVOS DEL PROYECTO OBJETIVOS

CRITERIOS DE ÉXITO

El objetivo principal del presente proyecto es desarrollar un sistema autónomo capaz de movilizar a personas discapacitadas sobre una silla de ruedas, utilizando un simple comando o instrucción de voz.

Solución integrada para personas discapacitadas.

las

RECURSOS DEL PROYECTO 

La inversión necesaria para el desarrollo del proyecto debe ser de S/. 1680 (Incluye costo de equipos, salarios) En el anexo 01 se encuentra el presupuesto del proyecto.



El recurso Humano es el siguiente: - GAMARRA PEÑALVA, RELY OMAR SUPUESTOS Y LIMITACIONES



El proyecto se desarrollara entre el 22 de abril y el 21 de noviembre del 2013

 

El proyecto no debe exceder los S/ 20000.00 Acceso al espacio dispuesto para el montaje de los equipos que garanticen el buen funcionamiento de los mismos. RIESGOS PRINCIPALES AMENAZAS DEL PROYECTO (RIESGOS NEGATIVOS)  Falta de conocimientos para el desarrollo del prototipo de silla de ruedas.  Incumplimiento del cronograma de trabajo. PRINCIPALES OPORTUNIDADES DEL PROYECTO (RIESGOS POSITIVOS)  Financiamiento externo por personas interesadas.

7

2. DOCUMENTAR REQUISITOS NOMBRE DEL PROYECTO PROTOTIPO DE UN SISTEMA DE MANEJO PARA UNA SILLA DE RUEDAS UTILIZANDO UN MODULO DE PROCESAMIENTO DE VOZ NECESIDAD DEL NEGOCIO U OPORTUNIDAD A APROVECHAR:

SIGLAS DEL PROYECTO PSVOZ

DESCRIBIR LAS LIMITACIONES DE LASITUACIÓN

ACTUAL Y LAS RAZONES POR LAS CUÁLES SE EMPRENDE EL PROYECTO.

Existen personas con discapacidad o capacidades limitadas de movimiento debido a problemas de salud congénito o adquirido, lo cual les impide desplazarse de forma independiente por sus propios medios, casos como la cuadriplejia y/o personas de la tercera edad, que les impide cualquier movimiento y por ende la manipulación y control clásico de instrumentos de apoyo como las sillas de ruedas, estos implementos como uno de los tantos problemas a los que se enfrentan las personas discapacitadas; y considerando que estando en el siglo XXI donde la tecnología se ha adelantado a la imaginación y ha convertido lo que era producto de la imaginación; en herramientas al alcance de la gente, luego de la invención del computador y las maquinas, el hombre ha imaginado como comunicarse con ellas de forma natural, como con cualquier otra persona para poder ayudar a mejorar la calidad de vida de las personas con los problemas referidos. Actualmente esa brecha se está cerrando y encontramos teléfonos celulares, sistemas de seguridad y software que obedecen nuestra voz y que parecerían que nos entendieran. Precisamente este trabajo quiere contribuir a ese acercamiento hombre-máquina con el diseño de una silla de ruedas controlada por comandos de voz, esto es que con una simple frase como adelante, atrás, derecha, izquierda o alto pueda gobernar el movimiento de la silla sin necesidad de utilizar nuestras extremidades. Al implementar este sistema se quiere dar una mejor calidad de vida a la sociedad con problemas de motricidad, en este caso personas que no pudieran mover ninguna de las extremidades pero que a través de su voz se le pudiera facilitar alguna de las capacidades perdidas. OBJETIVOS DEL NEGOCIO Y DEL PROYECTO: DEFINIR CON CLARIDAD LOS OBJETIVOS DEL NEGOCIO Y DEL PROYECTO PARA PERMITIR LAS TRAZABILIDAD DE ÉSTOS.



EL objetivo principal del presente proyecto es desarrollar un prototipo de silla de ruedas capaz de movilizar a personas discapacitadas, utilizando un simple comando o instrucción de voz.



El sistema de control del navegador está basado en un microcontrolador tipo PIC para la ejecución del reconocimiento de voz y manejo.



Reducir los costos al poder brindar una alternativa de solución al problema de la motricidad de las personas.



Las palabras que reconocerá el sistema pueden ser cualquiera que el usuario entrene las cuales obedecerá a las siguientes acciones: “adelante”, “atrás”, “izquierda”, “derecha”, “alto”.

REQUISITOS FUNCIONALES:

DESCRIBIR PROCESOS DEL NEGOCIO, INFORMACIÓN, INTERACCIÓN CON EL

PRODUCTO,ETC.

8

STAKEHOLDER

PRIORIDAD OTORGADA POR EL STAKEHOLDER ALTA

CLIENTES ( PERSONAS CON DISCAPACIDAD)

REQUISITOS FUNCIONALES:

CÓDIGO

R001

REQUISITOS DESCRIPCIÓN

Utilización de la interfaz de usuario para el entrenamiento de los comandos de voz, por medio de patrones de audio para el manejo por medio de la voz.

DESCRIBIR PROCESOS DEL NEGOCIO, INFORMACIÓN, INTERACCIÓN CON EL

PRODUCTO,ETC.

STAKEHOLDER

PRIORIDAD OTORGADA POR EL STAKEHOLDER BAJA

CLIENTES ( PERSONAS CON DISCAPACIDAD)

REQUISITOS

NO

CÓDIGO

REQUISITOS DESCRIPCIÓN

R002

Emplear la plataforma de desarrollo Visual Studio 2010, con el lenguaje de programación C#.

MEDIA

R003

Presentación de informes mensuales sobre los avances del proyecto para la gestión de proyectos.

MEDIA

R004

Presentación de un documento final que incluya una memoria de las actividades realizadas, resultados alcanzados y todo el material elaborado durante el desarrollo del proyecto.

MEDIA

R005

Presentación de un documento final que incluya una memoria de las actividades realizadas, resultados alcanzados y todo el material elaborado durante el desarrollo del proyecto.

FUNCIONALES:

DESCRIBIR

REQUISITOS

TALES

CÓMO

NIVEL

DE

SERVICIO,

PERFOMANCE,SEGURIDAD, ADECUACIÓN, ETC.

STAKEHOLDER

GRUPO DE TRABAJO

PRIORIDAD OTORGADA POR EL STAKEHOLDER MEDIA

CÓDIGO

REQUISITOS DESCRIPCIÓN

R006

Se usa framework 4.5

ALTA

R007

ALTA

R008

El sistema usa un sistema operativo Windows 7 o superior. Disponibilidad del horario para la ejecución del proyecto.

9

MEDIA

R009

Escalabilidad: El producto debe ser construido sobre la base de un desarrollo evolutivo e incremental, de manera tal que nuevas funcionalidades y requerimientos relacionados puedan ser incorporados.

10

REQUISITOS DE CALIDAD:

DESCRIBIR REQUISITOS RELATIVOS A NORMAS O ESTÁNDARES DE CALIDAD, O LA SATISFACCIÓN Y CUMPLIMIENTO DE FACTORES RELEVANTES DE CALIDAD.

STAKEHOLDER

CLIENTES ( PERSONAS CON DISCAPACIDAD)

PRIORIDAD OTORGADA POR EL STAKEHOLDER MUY ALTA MEDIA

CÓDIGO

REQUISITOS DESCRIPCIÓN

R010

Interfaces simples de entender al momento de entrenar al sistema.

R011

Consistencia y robustez de los equipos y software que conformen el producto

CRITERIOS DE ACEPTACIÓN: ESPECIFICACIONES O REQUISITOS DE RENDIMIENTO, FUNCIONALIDAD, ETC., QUE DEBEN CUMPLIRSE ANTES DE ACEPTAR EL PROYECTO.

CONCEPTOS 1. TÉCNICOS

2. DE CALIDAD

3. ADMINISTRATIVOS

4. COMERCIALES

CRITERIOS DE ACEPTACION Entregar los modelos necesarios que cumplan con los estándares de análisis y diseño de producto. Contar con las herramientas necesarias para su desarrollo como: 

Sistema operativo Windows 7.



El framework 4.5



Visual estudio 2010, C#



SQL server estándar 2005 express

01 laptop con 4GB Memoria RAM, 500GB disco duro, procesador core 2 Duo. Lograr un entendimiento claro durante el proceso de los entregables del proyecto. El proyecto será desarrollado con estándares de calidad, definidos al iniciar el proyecto. Que además se detallarán en el documento de gestión de calidad. La aprobación de los entregables del proyecto está determinada por los integrantes del proyecto. El desarrollo del proyecto será ejecutado con recursos propios del desarrollador. Cumplir con las especificaciones del diseño del proyecto con todos sus entregables

REGLAS DEL NEGOCIO: REGLAS PRINCIPALES QUE FIJAN LOS PRINCIPIOS GUÍAS DE LA ORGANIZACIÓN.  Comunicación constante entre el equipo de proyecto, respecto a la ejecución del proyecto. 

La gestión del proyecto se realiza de acuerdo a la Metodología de Gestión de Proyectos de PMBOOK.



Estar evaluando el avance y rendimiento del proyecto, y tomar acciones correctivas de ser el caso.

11

IMPACTOS EN OTRAS ENTIDADES: DENTRO O FUERA DE LA ORGANIZACIÓN EJECUTANTE. Se espera que como resultado del proyecto las organizaciones obtengan el conocimiento y la capacidad de desarrollar sus proyectos de acuerdo a las buenas prácticas de Gestión de Proyectos de la Guía de los Fundamentos para la Dirección de Proyectos (Guía del PMBOK). REQUERIMIENTOS DE SOPORTE Y ENTRENAMIENTO 

El realizar, desarrollar y entender los formatos basados en la PMI de Dharma Consulting.

 

Los integrantes del desarrollo deben tener el lineamento para la ejecución del proyecto Se trabajara como guía los formatos de Dharma Consulting pero se elaboran en Word con unas especificaciones ya mencionadas.

SUPUESTOS RELATIVOS A REQUISITOS Los integrantes del grupo no cambiaran los formatos ya establecidos, ni la forma en que se trabajaran los formatos RESTRICCIONES RELATIVAS A REQUISITOS  La entrega de los formatos se hará en el sitio Web creado, para este fin.  La entrega de los formatos será aceptados previa aprobación de los integrantes del grupo y/o gerente del proyecto.  Se determinara la entrega mínima según cronograma y cualquier entrega anticipada tendrá el mismo procedimiento.

12

3. PLAN DE GESTION DE REQUISITOS NOMBRE DEL PROYECTO PROTOTIPO DE UN SISTEMA DE MANEJO PARA UNA SILLA DE RUEDAS UTILIZANDO UN MODULO DE PROCESAMIENTO DE VOZ

SIGLAS DEL PROYECTO PSVOZ

ACTIVIDADES DE REQUISITOS: DESCRIBIR CÓMO SE PLANIFICARÁN, SEGUIRÁN Y REPORTARÁN ESTAS ACTIVIDADES. Para dicho propósito se cuenta con todos los requerimientos expuestos por el jefe de proyectos (descritos en el Project Charter) , que servirán como ayuda y permitirán identificar las actividades que son requeridas para el proyecto planteado marcando así un inicio y por supuesto su planificación. Dicha planificación está estructurada y amparada por las buenas prácticas PMI. Se incluyen entonces el manejo de la documentación de manera que permita hacer seguimiento controlado al proyecto sin dejar de lado el apoyo tecnológico con Project 2010 para los informes necesarios. ACTIVIDADES DE GESTIÓN DE CONFIGURACIÓN:

DESCRIPCIÓN DE CÓMO SE INICIARÁN LAS ACTIVIDADES DE CAMBIOS AL PRODUCTO, SERVICIO O REQUERIMIENTO; CÓMO SE ANALIZARÁN LOS IMPACTOS; CÓMO SE RASTREARÁN, MONITOREARÁN, Y REPORTARÁN, Y CUÁLES SON LOS NIVELES DE AUTORIZACIÓN REQUERIDOS PARA APROBAR DICHOS CAMBIOS.

Para las actividades de cambio al producto, servicio o requerimiento se realizará lo siguiente: 

Para dicho propósito entonces cualquier integrante del equipo que considere un cambio debe presentar la solicitud del cambio con el correspondiente formato establecido donde se detalla y establece el cambio deseado.



En los comités de control de cambios que se realizan semanalmente se revisan los cambios que estén planteados identificando su impacto en la parte de costo, tiempo, recurso y obviamente el alcance que plantea. Allí se determina si son o no aprobados.



Cuando se aprueban se deben realizar los correspondientes ajustes en los cronogramas y formatos que impacten.

PROCESO DE PRIORIZACIÓN DE REQUISITOS: DESCRIBIR COMO SE PRIORIZARÁN LOS REQUISITOS 

Para el proceso de priorización de requisitos se tiene como base la matriz de trazabilidad de requisitos donde se clasifican de acuerdo a la complejidad, prioridad y a su nivel de estabilización.



Este proceso será realizado por el equipo del proyecto durante la planificación del mismo, y será aprobado por el jefe de proyectos.

MÉTRICAS DEL PRODUCTO: DESCRIBIR LAS MÉTRICAS QUE SE USARÁN Y SUSTENTAR PORQUÉ SE USARÁN. 13

Para poder cumplir con las expectativas de los usuarios se deberá cumplir con pruebas al finalizar cada paquete de trabajo descritos en el diccionario WBS. En caso de no cumplir se debe tomar acciones correctivas.

ESTRUCTURA DE TRAZABILIDAD: DESCRIBIR LOS ATRIBUTOS DE REQUISITOS QUE SE CAPTURARÁN EN LA MATRIZ DE TRAZABILIDAD Y ESPECIFICAR CONTRA QUE OTROS DOCUMENTOS DE REQUISITOS DEL PROYECTO SE HARÁ LA TRAZABILIDAD.

En la Matriz de Trazabilidad se documentará la siguiente información: 

Atributos de Requisitos, que incluye: código, descripción, sustento de inclusión, propietario, fuente, prioridad, versión, estado actual, fecha de cumplimiento, nivel de estabilidad, grado de complejidad y criterio de aceptación.

Trazabilidad hacia: 

Necesidades, oportunidades, metas y objetivos del negocio.



Objetivos del proyecto.



Alcance del proyecto, entregables del WBS.



Diseño del producto.



Desarrollo del producto.



Estrategia de prueba.



Escenario de prueba.



Requerimiento de alto nivel.

14

4. MATRIZ DE TRAZABILIDAD DE REQUISITOS DE PROYECTO

ID

NOMBRE

1

Sobrevaloración

2

Tiempo

3

Consistencia

4

Recursos

5

Desarrollo

6

Reglamento

7

Diseño

DESCRIPCION

RESPONSABL E

El proyecto cumple con el rango del límite de costo establecido para el desarrollo del proyecto. El proyecto cumple con el límite de tiempo establecido para el desarrollo. Mantener una buena comunicación, con habilidades verbales y escritas entre los participantes del proyecto, para evitar la inconsistencia de sus argumentos que da lugar a la réplica de información. Incrementar el uso de los recursos de la empresa en un 10% con la implementación del sistema. Desarrollar un sistema 100% automático

Director del proyecto Director del proyecto

Cumplir con las normas y reglamentos de la empresa Que cumpla con el 100% con las bases de diseño.

Establecer horarios de capacitación al personal. Maximizando la disponibilidad y tiempo con los participantes del proyecto. Elaborar el 100% de formatos de documentación de 9 Documentación los procesos desarrollados El personal debe completar 48 horas a la semana de 10 Horarios horarios de trabajo 5. PLAN DE GESTIÓN DE ALCANCE 8

Capacitación

NOMBRE DEL PROYECTO PROTOTIPO DE UN SISTEMA DE MANEJO PARA UNA SILLA DE RUEDAS UTILIZANDO UN MODULO DE PROCESAMIENTO DE VOZ

Director del proyecto Equipo de proyecto. Equipo de proyecto Equipo de proyecto Equipo de proyecto Equipo de proyecto Equipo de proyectos Equipo de proyectos

PRIORIDAD

VERSION

EST ACT

Alta

1

Ac

Alta

1

Ac

Alta

1

Ac

Media

1

Ac

Bajo

1

Ac

Medio

1

Ac

Alta

1

Ac

Media

1

Ac

Media

1

Ac

Media

1

Ac

SIGLAS DEL PROYECTO PSVOZ

PROCESO DE DEFINICIÓN DE ALCANCE:

DESCRIPCIÓN DETALLADA DEL PROCESO PARA ELABORAR ELSCOPE STATEMENT DEFINITIVO A PARTIR DEL SCOPE STATEMENT PRELIMINAR. DEFINICIÓN DE QUÉ, QUIÉN, CÓMO, CUÁNDO, DÓNDE, Y CON QUÉ.

La definición del Alcance del proyecto PSVOZ se desarrollará de la siguiente manera: 

En reunión de equipo de proyecto, tanto el equipo de proyecto como el sponsor revisarán el WBS y el diccionario WBS preliminar, el cual servirá como base

PROCESO PARA ELABORACIÓN DE WBS:

DESCRIPCIÓN DETALLADA DEL PROCESO PARA CREAR, APROBAR, Y MANTENER EL WBS. DEFINICIÓN DE QUÉ, QUIÉN, CÓMO, CUÁNDO, DÓNDE, Y CON QUÉ.

15

Los pasos que se realizaron para la elaboración del WBS son los siguientes: 

El EDT del proyecto será estructurado de acuerdo a la herramienta de descomposición, identificándose primeramente los principales entregables, que en el proyecto actúan como fases. En el proyecto se identificó 5 fases.



Identificado los principales entregables, se procede con la descomposición del entregable en paquetes de trabajo, los cuales nos permiten conocer al mínimo detalle el costo, trabajo y calidad incurrido en la elaboración del entregable.

PROCESO PARA ELABORACIÓN DEL DICCIONARIO WBS: DESCRIPCIÓN DETALLADA DEL PROCESO PARA CREAR, APROBAR, Y MANTENER EL DICCIONARIO WBS. DEFINICIÓN DE QUÉ, QUIÉN, CÓMO, CUÁNDO, DÓNDE, Y CON QUÉ.

Previo a este proceso, el WBS del proyecto debe haber sido elaborado, revisado y aprobado. Es en base a la información del WBS que se elaborará el Diccionario WBS, para lo cual se realizarán los siguientes pasos:        

La elaboración del Diccionario WBS se hace mediante una plantilla diseñada por Dharma Consulting. Se identifica las siguientes características de cada paquete de trabajo del WBS. Se detalla el objetivo del paquete de trabajo. Se hace una descripción breve del paquete de trabajo. Se describe el trabajo a realizar para la elaboración del entregable, como son la lógica o enfoque de elaboración y las actividades para elaborar cada entregable. Se establece la asignación de responsabilidad, donde por cada paquete de trabajo se detalla quién hace qué: responsable, participa, apoya, revisa, aprueba y da información del paquete de trabajo. De ser posible se establece las posibles fechas de inicio y fin del paquete de trabajo, o un hito importante. Se describe cuáles son los criterios de aceptación

PROCESO PARA VERIFICACIÓN DE ALCANCE: DESCRIPCIÓN DETALLADA DEL PROCESO PARA LA VERIFICACIÓN FORMAL DE LOS ENTREGABLES Y SU ACEPTACIÓN POR PARTE DEL CLIENTE (INTERNO O EXTERNO). DEFINICIÓN DE QUÉ, QUIÉN, CÓMO, CUÁNDO, DÓNDE, Y CON QUÉ.

Al término de elaboración de cada entregable, éste debe ser presentado al Sponsor del Proyecto, el cual se encargará de aprobar o presentar las observaciones del caso. Si el entregable es aprobado, es enviado al cliente PROCESO PARA CONTROL DE ALCANCE:

DESCRIPCIÓN DETALLADA DEL PROCESO PARA IDENTIFICAR, REGISTRAR, Y PROCESAR CAMBIOS DE ALCANCE, ASÍ COMO SU ENLACE CON EL CONTROL INTEGRADO DE CAMBIOS. DEFINICIÓN DE QUÉ, QUIÉN, CÓMO, CUÁNDO, DÓNDE Y CON QUÉ.

En este caso se presentan dos variaciones: 

Primero, el Project Manager se encarga de verificar que el entregable cumpla con lo acordado en la Línea Base del Alcance. Si el entregable es aprobado es enviado al Cliente, pero si el

16

entregable no es aprobado, el entregable es devuelto a su responsable junto con una Hoja de Correcciones, donde se señala cuáles son las correcciones o mejoras que se deben hacer. 

Segundo, a pesar que el Project Manager se encarga de verificar la aceptación del entregable del proyecto, el Cliente también puede presentar sus observaciones respecto al entregable, para lo cual requerirá reunirse con el Project Manager, y presentar sus requerimientos de cambio o ajuste. De lograrse la aceptación del Cliente y de tratarse de un entregable muy importante, se requerirá la firma de un acta de aceptación del entregable.

6. WBS DEL PROYECTO NOMBRE DEL PROYECTO PROTOTIPO DE UN SISTEMA DE MANEJO PARA UNA SILLA DE RUEDAS UTILIZANDO UN MODULO DE PROCESAMIENTO DE VOZ

SIGLAS DEL PROYECTO PSVOZ

GRAFICA 1 WBS

FUENTE: ELABORACION PROPIA GRAFICA 2 FASE DE INICIO

17

FUENTE: ELABORACION PROPIA

GRAFICA 3 FASE DE PLANEAMIENTO

FUENTE: ELABORACION PROPIA

18

GRAFICA 4 FASE DE ANALISIS Y DISEÑO

FUENTE: ELABORACION PROPIA

19

GRAFICA 5 FASE DE CONSTRUCCION

FUENTE: ELABORACION PROPIA

20

GRAFICA 6 FASE DE CIERRE

FUENTE: ELABORACION PROPIA

21

7. DICCIONARIO WBS (completo) NOMBRE DEL PROYECTO PROTOTIPO DE UN SISTEMA DE MANEJO PARA UNA SILLA DE RUEDAS UTILIZANDO UN MODULO DE PROCESAMIENTO DE VOZ CÓDIGO DEL PAQUETE DE TRABAJO (PDT): SEGÚN EL WBS 1.1 OBJETIVO DEL PAQUETE DE TRABAJO: DESCRIPCIÓN DEL PAQUETE DE TRABAJO: DESCRIPCIÓN DEL TRABAJO A REALIZAR (ACTIVIDADES):

ASIGNACIÓN RESPONSABILIDADES: FECHAS PROGRAMADAS: CRITERIOS DE ACEPTACIÓN:

RECURSOS ASIGNADOS

SIGLAS DEL PROYECTO PSVOZ

NOMBRE DEL PAQUETE DE TRABAJO (PDT):SEGÚN EL WBS REUNIONES Iniciar el proyecto Aquí se lleva a cabo la primera reunión para la presentación del equipo de trabajo especificado en el Project Charter para dar a conocer sus cargos, especialidades y responsabilidades en este proyecto, Presentación del proyecto al equipo. ACTIVIDADES A REALIZAR:    

DE

Reunión con el equipo de trabajo. Revisar el Project Charter. Firma del compromiso para la realización del proyecto. Reunión entre el sponsor y el jefe de proyectos para determinar fechas de reuniones para presentar el informe de avances del proyecto aceptado por el sponsor y el jefe de proyectos. RESPONSABLE: Jefe de proyectos PARTICIPA: Equipo de trabajo INICIO: 22-04-2013 FIN: 22-04-2013 HITOS IMPORTANTES: Fase de Inicio STAKEHOLDER QUE Clientes (personas con ACEPTA: discapacidades) REQUISITOS QUE DEBEN El equipo de trabajo deberá CUMPLIRSE: recibir una copia del Project Charter. FORMA EN QUE SE Reunión del equipo de ACEPTARÁ: proyecto PERSONAL: Jefe de proyectos y equipo de trabajo MATERIALES O Papeles. CONSUMIBLES: EQUIPOS O MÁQUINAS: Computadoras. ANTES DEL PDT: Ninguno DESPUÉS DEL PDT: 1.2

22

CÓDIGO DEL PAQUETE DE TRABAJO (PDT): SEGÚN EL WBS 1.2

NOMBRE DEL PAQUETE DE TRABAJO (PDT):SEGÚN EL WBS EVALUACION Y TOMA DE DECICIONES PARA EL TIEMPO DE DESARROLLO DEL PROYECTO

OBJETIVO DEL PAQUETE DE TRABAJO: DESCRIPCIÓN DEL PAQUETE DE TRABAJO: DESCRIPCIÓN DEL TRABAJO A REALIZAR (ACTIVIDADES):

Este paquete tiene la finalidad de determinar cuáles son los requerimientos que debe tener el prototipo de la silla de ruedas. En este paquete de trabajo se evaluara y determinara cuáles serán los tiempos para el desarrollo del proyecto. ACTIVIDADES A REALIZAR:

ASIGNACIÓN RESPONSABILIDADES: FECHAS PROGRAMADAS: CRITERIOS DE ACEPTACIÓN:

RECURSOS ASIGNADOS

DE



Se realiza el documento para especificar que el prototipo de silla de ruedas se basará en el Project Charter.  Tomamos la decisión sobre los elementos que usaremos en el proyecto decidiendo que usaremos una red neuronal para el reconocimiento de voz y todos aquellos requerimientos vistos en el Project Charter. RESPONSABLE: Jefe de proyectos PARTICIPA: Equipo de trabajo INICIO: 22-04-2013 FIN: 22-04-2013 HITOS IMPORTANTES: Fase de inicio STAKEHOLDER QUE Clientes (personas con ACEPTA: discapacidades) REQUISITOS QUE DEBEN Cumplir con las CUMPLIRSE: especificaciones del Project Charter para la elaboración de los requerimientos que serán entregados a el equipo de trabajo PERSONAL: Jefe de proyectos y equipo de trabajo MATERIALES O Papeles CONSUMIBLES: EQUIPOS O MÁQUINAS: Computadoras ANTES DEL PDT: 1.1 DESPUÉS DEL PDT: 2.1

23

CÓDIGO DEL PAQUETE DE TRABAJO (PDT): SEGÚN EL WBS 2.1

NOMBRE DEL PAQUETE DE TRABAJO (PDT):SEGÚN EL WBS CRONOGRAMA DE RECURSOS

OBJETIVO DEL PAQUETE DE TRABAJO:

Determinar el personal a utilizar y el momento en que intervienen así como que utilizaran.

DESCRIPCIÓN DEL PAQUETE DE TRABAJO:

Aquí se especifican las Fechas en que intervendrá cada persona para la realización del proyecto.

DESCRIPCIÓN DEL TRABAJO A REALIZAR (ACTIVIDADES):C ASIGNACIÓN DE RESPONSABILIDADES: FECHAS PROGRAMADAS:

ACTIVIDADES A REALIZAR: Reunión del jefe de proyectos y el equipo de proyectos RESPONSABLE: Jefe de proyectos PARTICIPA: Equipo de trabajo INICIO: 23-04-2013 FIN: 26-04-2013 HITOS IMPORTANTES: Fase de planeamiento STAKEHOLDER QUE Jefe de proyectos ACEPTA: REQUISITOS QUE DEBEN Determinación del recurso que CUMPLIRSE: interviene en cada paquete de trabajo. FORMA EN QUE SE Documento firmado de la ACEPTARÁ: elaboración del cronograma de recursos. PERSONAL: Equipo de trabajo MATERIALES O Papeles CONSUMIBLES: EQUIPOS O MÁQUINAS: Computadoras ANTES DEL PDT: 1.2 DESPUÉS DEL PDT: 2.2

CRITERIOS DE ACEPTACIÓN:

RECURSOS ASIGNADOS

24

CÓDIGO DEL PAQUETE DE TRABAJO (PDT): SEGÚN EL WBS 2.2 OBJETIVO DEL PAQUETE DE TRABAJO: DESCRIPCIÓN DEL PAQUETE DE TRABAJO: DESCRIPCIÓN DEL TRABAJO A REALIZAR (ACTIVIDADES): ASIGNACIÓN DE RESPONSABILIDADES: FECHAS PROGRAMADAS: CRITERIOS DE ACEPTACIÓN:

RECURSOS ASIGNADOS

NOMBRE DEL PAQUETE DE TRABAJO (PDT):SEGÚN EL WBS DIAGRAMA DE GANTT Determinar el tiempo de duración del proyecto. Aquí se especifican las fechas y la duración de cada una de las actividades que intervienen en la realización del proyecto. Ponen los hitos del proyecto. ACTIVIDADES A REALIZAR: Reunión del jefe de proyectos y el equipo de proyectos. RESPONSABLE: Jefe de proyectos PARTICIPA: Equipo de trabajo INICIO: 29-04-2013 FIN: 03-05-2013 HITOS IMPORTANTES: Fase de planeamiento STAKEHOLDER QUE Jefe de proyectos ACEPTA: Personas discapacitadas REQUISITOS QUE DEBEN Aprobación del cronograma de CUMPLIRSE: recursos. FORMA EN QUE SE Documentación del ACEPTARÁ: cronograma de recursos con la firma del equipo de trabajo PERSONAL: Jefe de proyectos MATERIALES O Papeles CONSUMIBLES: EQUIPOS O MÁQUINAS: Computadoras ANTES DEL PDT: 2.1 DESPUÉS DEL PDT: 2.3

25

CÓDIGO DEL PAQUETE DE TRABAJO (PDT): SEGÚN EL WBS 2.3

NOMBRE DEL PAQUETE DE TRABAJO (PDT):SEGÚN EL WBS ASIGNACIÓN DE ROLES Y RESPONSABILIDADES.

OBJETIVO DEL PAQUETE DE TRABAJO:

Planeamiento de los roles (funciones) de cada una de las personas que conforman el equipo de trabajo en la realización del proyecto Determinar un responsable para cada paquete de trabajo y hacerle firmar un documento donde especifique de que paquete de trabajo es responsable. ACTIVIDADES A REALIZAR: Reunión del jefe de proyectos con el equipo de trabajo RESPONSABLE: 1 Jefe de proyectos PARTICIPA: Equipo de trabajo INICIO: 06-05-2013 FIN: 06-05-2013 HITOS IMPORTANTES: Fase de planeamiento STAKEHOLDER QUE Jefe de proyectos ACEPTA: REQUISITOS QUE DEBEN Que no tenga como CUMPLIRSE: responsabilidad más de tres paquetes.

DESCRIPCIÓN DEL PAQUETE DE TRABAJO: DESCRIPCIÓN DEL TRABAJO A REALIZAR (ACTIVIDADES): ASIGNACIÓN DE RESPONSABILIDADES: FECHAS PROGRAMADAS: CRITERIOS DE ACEPTACIÓN:

FORMA EN ACEPTARÁ: RECURSOS ASIGNADOS

QUE

PERSONAL: MATERIALES CONSUMIBLES: EQUIPOS O MÁQUINAS: ANTES DEL PDT: DESPUÉS DEL PDT:

SE

O

Que tenga habilidades necesarias para tomar decisiones sobre el paquete Documentación donde se especifique los roles y responsabilidades del equipo de trabajo Equipo de trabajo Papeles Computadoras 2.2 2.4

26

CÓDIGO DEL PAQUETE DE TRABAJO (PDT): SEGÚN EL WBS 2.4 OBJETIVO DEL PAQUETE DE TRABAJO: DESCRIPCIÓN DEL PAQUETE DE TRABAJO: DESCRIPCIÓN DEL TRABAJO A REALIZAR (ACTIVIDADES):

ASIGNACIÓN RESPONSABILIDADES: FECHAS PROGRAMADAS:

DE

CRITERIOS DE ACEPTACIÓN:

RECURSOS ASIGNADOS: RECURSOS ASIGNADOS Y COSTOS: QUÉ RECURSOS SE NECESITAN PARA ELABORAR EL PDT, DE QUE TIPO, EN QUE CANTIDADES, Y CON QUE COSTOS.

NOMBRE DEL PAQUETE DE TRABAJO (PDT):SEGÚN EL WBS PLAN DE RIESGOS Se define el plan de gestión de riesgos del proyecto. Descripción detallada de la metodología de gestión de riesgos (procesos, sus respectivas descripciones, las herramientas a utilizar y las fuentes de información). ACTIVIDADES A REALIZAR: 1. Asignar los roles y responsabilidades de la gestión de riesgos del proyecto. 2. Asignar el presupuesto de la gestión de riesgos del proyecto. 3. Realizar el plan de gestión de riesgos del proyecto. RESPONSABLE: Jefe de proyectos PARTICIPA: Equipo de trabajo INICIO: 07-05-2013 FIN: 14-05-2013 HITOS IMPORTANTES: Fase de planificación STAKEHOLDER QUE Jefe de proyectos ACEPTA: REQUISITOS QUE DEBEN La lista de requerimiento CUMPLIRSE: deberá atribuirle atributos como: confiabilidad, seguridad y tiempo de respuesta inmediata, facilidad de uso, eliminar mensaje de error. FORMA EN QUE SE Documento del plan de riesgos ACEPTARÁ: Personal: Equipo de trabajo Materiales o Consumibles: Papeles Equipos o Máquinas: Computadoras Antes del pdt: 2.3 Después del pdt: 2.5 Otros tipos de dependencia: Ninguno

27

CÓDIGO DEL PAQUETE DE TRABAJO (PDT): SEGÚN EL WBS 2.5

NOMBRE DEL PAQUETE DE TRABAJO (PDT):SEGÚN EL WBS MONITOREO Y CONTROL

OBJETIVO DEL PAQUETE DE TRABAJO: DESCRIPCIÓN DEL PAQUETE DE TRABAJO:

Definir las guías para el registro y control ordenado de las versiones de los documentos del proyecto Se realizar el plan de gestión de monitoreo y control del proyecto y definir el procedimiento para revisar el plan. Tiene que contener la inspección de los paquetes de trabajo. Tiene que contener el informe de la inspección de los paquetes de trabajo. ACTIVIDADES A REALIZAR: Elaboración del entregable para el monitoreo y control RESPONSABLE: Jefe de proyectos PARTICIPA: Equipo de trabajo INICIO: 15-05-2013 FIN: 15-05-2013 HITOS IMPORTANTES: Fase de planificación STAKEHOLDER QUE Jefe de proyectos ACEPTA: REQUISITOS QUE DEBEN Monitorear cada paquete de CUMPLIRSE: trabajo teniendo como principal indicador el cronograma de recursos y el diagrama de Gantt FORMA EN QUE SE Documentación del plan para ACEPTARÁ: el monitoreo y control Personal: Jefe de proyectos Equipo de trabajo Materiales o Consumibles: Papeles Equipos o Máquinas: Computadoras Antes del pdt: 2.4 Después del pdt: 3.1.1º

DESCRIPCIÓN DEL TRABAJO A REALIZAR (ACTIVIDADES): ASIGNACIÓN DE RESPONSABILIDADES: FECHAS PROGRAMADAS: CRITERIOS DE ACEPTACIÓN:

RECURSOS ASIGNADOS :

28

CÓDIGO DEL PAQUETE DE TRABAJO (PDT): SEGÚN EL WBS 3.1.1

NOMBRE DEL PAQUETE DE TRABAJO (PDT):SEGÚN EL WBS MODELO DE CASO DE USO

OBJETIVO DEL PAQUETE DE TRABAJO:

El modelo de caso de uso describe la funcionalidad propuesta del proyecto.

DESCRIPCIÓN DEL PAQUETE DE TRABAJO:

1. Identificara los actores. 2. Secuencia de transacciones que son desarrolladas por el sistema en respuesta a un evento que inicia un actor. 3. Relaciones de Inclusión y Extensión entre Casos de Uso. 4. Se realizará el modelo UML de casos de uso. ACTIVIDADES A REALIZAR: Elaboración de los modelos de caso de uso RESPONSABLE: Analista de sistemas PARTICIPA: Analista de sistemas INICIO: 16-05-2013 FIN: 16-05-2013 HITOS IMPORTANTES: Fase de análisis y diseño STAKEHOLDER QUE Jefe de proyectos ACEPTA: REQUISITOS QUE DEBEN Cumplir con los requerimientos CUMPLIRSE: y/o funcionalidades descritas en el Project Charter FORMA EN QUE SE Documento del modelo de ACEPTARÁ: caso de uso PERSONAL: Analista de sistemas MATERIALES O Papeles CONSUMIBLES: EQUIPOS O MÁQUINAS: Computadora ANTES DEL PDT: 2.5 DESPUÉS DEL PDT: 3.2

DESCRIPCIÓN DEL TRABAJO A REALIZAR (ACTIVIDADES): ASIGNACIÓN DE RESPONSABILIDADES: FECHAS PROGRAMADAS: CRITERIOS DE ACEPTACIÓN:

RECURSOS ASIGNADOS:

29

CÓDIGO DEL PAQUETE DE TRABAJO (PDT): SEGÚN EL WBS 3.1.2

NOMBRE DEL PAQUETE DE TRABAJO (PDT):SEGÚN EL WBS MODELADO DE CLASES

OBJETIVO DEL PAQUETE DE TRABAJO:

Representa las clases que serán utilizadas dentro del proyecto y las relaciones que existen entre ellas. Nos sirve para visualizar las relaciones entre las clases que se involucran, utilizando los datos recabados en la fase de Análisis de Project Charter. 1. Identificar las Clases que interviene. 2. Identificar los atributos y métodos de cada clase. 3. Se realizara en modelo de clases en UML. ACTIVIDADES A REALIZAR: Reunión del jefe de proyectos y el analista de sistemas. RESPONSABLE: Analista de sistemas PARTICIPA: Analista de sistemas INICIO: 17-05-2013 FIN: 17-05-2013 HITOS IMPORTANTES: Fase de análisis y diseño STAKEHOLDER QUE Jefe de proyectos ACEPTA: REQUISITOS QUE DEBEN Cumplir con los requerimientos CUMPLIRSE: y/o funcionalidades establecidas por el jefe de proyectos para describir las relaciones entre las clases utilizadas para la realización del software FORMA EN QUE SE Documento del modelo de ACEPTARÁ: clases PERSONAL: Analista de sistemas MATERIALES O Papeles CONSUMIBLES: EQUIPOS O MÁQUINAS: Computadora ANTES DEL PDT: Ninguno DESPUÉS DEL PDT: 3.3

DESCRIPCIÓN DEL PAQUETE DE TRABAJO: DESCRIPCIÓN DEL TRABAJO A REALIZAR (ACTIVIDADES): ASIGNACIÓN DE RESPONSABILIDADES: FECHAS PROGRAMADAS: CRITERIOS DE ACEPTACIÓN:

RECURSOS ASIGNADOS:

30

CÓDIGO DEL PAQUETE DE TRABAJO (PDT): SEGÚN EL WBS 3.1.3

NOMBRE DEL PAQUETE DE TRABAJO (PDT):SEGÚN EL WBS MODELADO DE SECUENCIA

OBJETIVO DEL PAQUETE DE TRABAJO: DESCRIPCIÓN DEL PAQUETE DE TRABAJO:

Modelo de secuencia provee un medio gráfico para representar la interacción entre los objetos a lo largo del tiempo. Elaborar el diagrama donde muestran a un actor, los objetos y componentes con los que interactúen durante la ejecución de un Caso de Uso. ACTIVIDADES A REALIZAR: 1. Revisar el documento de caso de uso. 2. Identificar los objetos y componentes que interactúan con el actor. 3. Identificar el tiempo en que interactúa con cada objeto y componente del sistema. 4. Realizar el modelo de secuencia UML RESPONSABLE: Analista de sistemas PARTICIPA: Analista de sistemas INICIO: 20-05-2013 FIN: 21-05-2013 HITOS IMPORTANTES: Fase de análisis y diseño STAKEHOLDER QUE Jefe de proyectos ACEPTA: REQUISITOS QUE DEBEN Cumplir con los tiempos en los CUMPLIRSE: que interactuara cada objeto y componente del sistema FORMA EN QUE SE Impresa y la firma del analista ACEPTARÁ: de sistemas PERSONAL: Analista de sistemas MATERIALES O Papeles CONSUMIBLES: EQUIPOS O MÁQUINAS: Computadora ANTES DEL PDT: 3.1.2 DESPUÉS DEL PDT: 3.3 OTROS TIPOS DE Ninguno DEPENDENCIA:

DESCRIPCIÓN DEL TRABAJO A REALIZAR (ACTIVIDADES):

ASIGNACIÓN RESPONSABILIDADES: FECHAS PROGRAMADAS: CRITERIOS DE ACEPTACIÓN:

RECURSOS ASIGNADOS:

DE

31

CÓDIGO DEL PAQUETE DE TRABAJO (PDT): SEGÚN EL WBS 3.2.1 OBJETIVO DEL PAQUETE DE TRABAJO: DESCRIPCIÓN DEL PAQUETE DE TRABAJO: DESCRIPCIÓN DEL TRABAJO A REALIZAR (ACTIVIDADES): ASIGNACIÓN DE RESPONSABILIDADES: FECHAS PROGRAMADAS: CRITERIOS DE ACEPTACIÓN:

RECURSOS ASIGNADOS:

NOMBRE DEL PAQUETE DE TRABAJO (PDT):SEGÚN EL WBS DISEÑO DE LA ESTRUCTURA DE LA SILLA DE RUEDAS Elaborar el diseño de la estructura de la silla de ruedas. Diseñar el prototipo de la silla de ruedas a implementar tomando las características descritas en el Project Charter. ACTIVIDADES A REALIZAR: Diseñar la silla de ruedas. RESPONSABLE: Jefe de proyectos PARTICIPA: Equipo de trabajo INICIO: 24-05-2013 FIN: 28-05-2013 HITOS IMPORTANTES: Fase de análisis y diseño STAKEHOLDER QUE Jefe de proyectos ACEPTA: REQUISITOS QUE DEBEN Debe cumplir con las CUMPLIRSE: especificadas en el Project Charter, para la distribución de todos los componentes electrónicos. FORMA EN QUE SE Impresa y en CD ACEPTARÁ: PERSONAL: Equipo de trabajo MATERIALES O Papeles CONSUMIBLES: CD’s EQUIPOS O MÁQUINAS: Computadoras ANTES DEL PDT: 3.1.3 DESPUÉS DEL PDT: 3.2.2

32

CÓDIGO DEL PAQUETE DE TRABAJO (PDT): SEGÚN EL WBS 3.2.2

NOMBRE DEL PAQUETE DE TRABAJO (PDT):SEGÚN EL WBS DISEÑO DE LA DISTRIBUCION

OBJETIVO DEL PAQUETE DE TRABAJO: DESCRIPCIÓN DEL PAQUETE DE TRABAJO: DESCRIPCIÓN DEL TRABAJO A REALIZAR (ACTIVIDADES): ASIGNACIÓN DE RESPONSABILIDADES: FECHAS PROGRAMADAS:

Diseñar como estarán distribuidos los diferentes componentes del proyecto. Diseñar como está distribuida las diferentes partes que conforman la implementación del proyecto. ACTIVIDADES A REALIZAR: Elaboración del diseño de distribución. RESPONSABLE: Jefe de proyectos PARTICIPA: Equipo de trabajo INICIO: 29-05-2013 FIN: 30-05-2013 HITOS IMPORTANTES: Fase de análisis y diseño STAKEHOLDER QUE Jefe de proyectos ACEPTA: REQUISITOS QUE DEBEN Tener en consideración las CUMPLIRSE: especificaciones denotadas en el diseño de la silla de ruedas FORMA EN QUE SE Documento del diseño de ACEPTARÁ: distribución. PERSONAL: Equipo de trabajo MATERIALES O Papeles CONSUMIBLES: EQUIPOS O MÁQUINAS: Computadora ANTES DEL PDT: 3.2.1 DESPUÉS DEL PDT: 3.3 OTROS TIPOS DE DEPENDENCIA:

CRITERIOS DE ACEPTACIÓN:

RECURSOS ASIGNADOS:

33

CÓDIGO DEL PAQUETE DE TRABAJO (PDT): SEGÚN EL WBS 3.3.1 OBJETIVO DEL PAQUETE DE TRABAJO: DESCRIPCIÓN DEL PAQUETE DE TRABAJO: DESCRIPCIÓN DEL TRABAJO A REALIZAR (ACTIVIDADES): ASIGNACIÓN RESPONSABILIDADES: FECHAS PROGRAMADAS: CRITERIOS DE ACEPTACIÓN:

RECURSOS ASIGNADOS :

DE

NOMBRE DEL PAQUETE DE TRABAJO (PDT): SEGÚN EL WBS DISEÑO Y SIMULACION DE LOS CIRCUITOS DE CONTROL. Diseñar y simular el funcionamiento de los circuitos de control. Simular el movimiento de los motores que indiquen el cambio de sentido. ACTIVIDADES A REALIZAR: Diseñar y simular como los motores son controlados por PWM (modulación por ancho de pulso) a través del microcontrolador PIC 16F877 RESPONSABLE: Jefe de proyectos PARTICIPA: Equipo de trabajo INICIO: 31-05-2013 FIN: 04-06-2013 HITOS IMPORTANTES: Fase de análisis y diseño STAKEHOLDER QUE Jefe de proyectos ACEPTA: REQUISITOS QUE DEBEN Utilizar un Proteus para la CUMPLIRSE: simulación de los circuitos de control. FORMA EN QUE SE Documento de la simulación ACEPTARÁ: ( grafica) PERSONAL: Equipo de trabajo MATERIALES O Papeles CONSUMIBLES: EQUIPOS O MÁQUINAS: Computadoras ANTES DEL PDT: 3.2.2 DESPUÉS DEL PDT: 3.3.2

34

CÓDIGO DEL PAQUETE DE TRABAJO (PDT): SEGÚN EL WBS 4.1.1

NOMBRE DEL PAQUETE DE TRABAJO (PDT): SEGÚN EL WBS ENTRENAMIENTO DE PATRONES

OBJETIVO DEL PAQUETE DE TRABAJO: DESCRIPCIÓN DEL PAQUETE DE TRABAJO:

Entrenar los patrones para el reconocimiento de las acciones a realizar En esta actividad se construye un patrón de referencia asociado a cada palabra (o subunidad de palabra) que se quiere reconocer, basándose en los vectores característicos de todas las palabras usadas para el entrenamiento ACTIVIDADES A REALIZAR: Comenzar con la programación del software RESPONSABLE: Analista de sistemas PARTICIPA: Analista de sistemas INICIO: 17-07-2013 FIN: 24-07-2013 HITOS IMPORTANTES: Fase de construcción STAKEHOLDER QUE Jefe de proyectos ACEPTA: REQUISITOS QUE DEBEN Utilizar un Visual Studio para CUMPLIRSE: la el desarrollo del software FORMA EN QUE SE Documento con las pantallas y ACEPTARÁ: código desarrollado en físico y en CD PERSONAL: Analista de sistemas MATERIALES O Papeles CONSUMIBLES: EQUIPOS O MÁQUINAS: Computadoras ANTES DEL PDT: 3.2.3 DESPUÉS DEL PDT: 4.1.2

DESCRIPCIÓN DEL TRABAJO A REALIZAR (ACTIVIDADES): ASIGNACIÓN DE RESPONSABILIDADES: FECHAS PROGRAMADAS: CRITERIOS DE ACEPTACIÓN:

RECURSOS ASIGNADOS :

35

CÓDIGO DEL PAQUETE DE TRABAJO (PDT): SEGÚN EL WBS 4.1.2 OBJETIVO DEL PAQUETE DE TRABAJO: DESCRIPCIÓN DEL PAQUETE DE TRABAJO:

DESCRIPCIÓN DEL TRABAJO A REALIZAR (ACTIVIDADES): ASIGNACIÓN DE RESPONSABILIDADES: FECHAS PROGRAMADAS: CRITERIOS DE ACEPTACIÓN:

RECURSOS ASIGNADOS :

NOMBRE DEL PAQUETE DE TRABAJO (PDT): SEGÚN EL WBS COMPARACION DE PATRONES Realizar la comparación de los patrones a utilizar En la etapa de comparación de patrones se realiza una comparación directa entre el vector característico asociado a la señal de voz desconocida (a reconocer) y todos los posibles patrones aprendidos en la etapa de entrenamiento, de manera de determinar el mejor ajuste de acuerdo a algún criterio ACTIVIDADES A REALIZAR: Comenzar con la programación del software RESPONSABLE: Analista de sistemas PARTICIPA: Analista de sistemas INICIO: 25-07-2013 FIN: 31-07-2013 HITOS IMPORTANTES: Fase de construcción STAKEHOLDER QUE Jefe de proyectos ACEPTA: REQUISITOS QUE DEBEN Utilizar un Visual Studio para CUMPLIRSE: la el desarrollo del software FORMA EN QUE SE Documento con las pantallas y ACEPTARÁ: código desarrollado en físico y en CD PERSONAL: Analista de sistemas MATERIALES O Papeles CONSUMIBLES: EQUIPOS O MÁQUINAS: Computadoras ANTES DEL PDT: 3.1.2 DESPUÉS DEL PDT: 4.1.3

36

CÓDIGO DEL PAQUETE DE TRABAJO (PDT): SEGÚN EL WBS 4.1.3

NOMBRE DEL PAQUETE DE TRABAJO (PDT): SEGÚN EL WBS PRUEBAS DEL MÓDULO DE RECONOCIMIENTO DE VOZ

OBJETIVO DEL PAQUETE DE TRABAJO: DESCRIPCIÓN DEL PAQUETE DE TRABAJO:

Probar si todos los pasos referentes al procesamiento de voz funcionen correctamente Se lleva a cabo las pruebas para determinar si el entrenamiento y comparación de patrones son correctos de modo que el reconocimiento de voz basado en comparación de patrones sea el adecuado ACTIVIDADES A REALIZAR: Pruebas del software RESPONSABLE: Analista de sistemas PARTICIPA: Analista de sistemas INICIO: 01-08-2013 FIN: 25-09-2013 HITOS IMPORTANTES: Fase de construcción STAKEHOLDER QUE Jefe de proyectos ACEPTA: REQUISITOS QUE DEBEN Cumplir con los diagramas CUMPLIRSE: UML elaborados en la fase de análisis y diseño FORMA EN QUE SE Informe con los resultados ACEPTARÁ: obtenidos PERSONAL: Analista de sistemas MATERIALES O Papeles CONSUMIBLES: EQUIPOS O MÁQUINAS: Computadoras ANTES DEL PDT: 4.1.2 DESPUÉS DEL PDT: 4.2.1

DESCRIPCIÓN DEL TRABAJO A REALIZAR (ACTIVIDADES): ASIGNACIÓN DE RESPONSABILIDADES: FECHAS PROGRAMADAS: CRITERIOS DE ACEPTACIÓN:

RECURSOS ASIGNADOS :

37

CÓDIGO DEL PAQUETE DE TRABAJO (PDT): SEGÚN EL WBS 4.2.1 OBJETIVO DEL PAQUETE DE TRABAJO: DESCRIPCIÓN DEL PAQUETE DE TRABAJO: DESCRIPCIÓN DEL TRABAJO A REALIZAR (ACTIVIDADES): ASIGNACIÓN DE RESPONSABILIDADES: FECHAS PROGRAMADAS: CRITERIOS DE ACEPTACIÓN:

RECURSOS ASIGNADOS :

NOMBRE DEL PAQUETE DE TRABAJO (PDT): SEGÚN EL WBS CONSTRUCCION DE LA ESTRUCTURA DE LA SILLA DE RUEDAS Se realizarán la construcción de la silla de ruedas usando el diseño del prototipo Se lleva a cabo construcción de la silla de rueda basándonos en los diseños y la distribución. ACTIVIDADES A REALIZAR: Construcción de la estructura de la silla de ruedas RESPONSABLE: Jefe de proyectos PARTICIPA: Equipo de proyectos INICIO: 26-09-2013 FIN: 09-10-2013 HITOS IMPORTANTES: Fase de construcción STAKEHOLDER QUE Jefe de proyectos ACEPTA: REQUISITOS QUE DEBEN Cumplir con las características CUMPLIRSE: definidas en el diseño del prototipo de silla de ruedas en la fase de análisis y diseño FORMA EN QUE SE Informe con los resultados ACEPTARÁ: obtenidos PERSONAL: Analista de sistemas MATERIALES O Papeles CONSUMIBLES: EQUIPOS O MÁQUINAS: Computadoras ANTES DEL PDT: 4.1.3 DESPUÉS DEL PDT: 4.3.1

38

CÓDIGO DEL PAQUETE DE TRABAJO (PDT): SEGÚN EL WBS 4.3.1

NOMBRE DEL PAQUETE DE TRABAJO (PDT): SEGÚN EL WBS FABRICACION DE LA PLACA DEL CIRCUITO

OBJETIVO DEL PAQUETE DE TRABAJO:

Se realizara la fabricación de la placa tomando como datos los diseños y simulaciones realizadas en la fase de análisis y diseño. Se elabora la placa del circuito

DESCRIPCIÓN DEL PAQUETE DE TRABAJO: DESCRIPCIÓN DEL TRABAJO A REALIZAR (ACTIVIDADES): ASIGNACIÓN DE RESPONSABILIDADES: FECHAS PROGRAMADAS: CRITERIOS DE ACEPTACIÓN:

RECURSOS ASIGNADOS :

ACTIVIDADES A REALIZAR: Elaboración de la placa del circuito electrónico RESPONSABLE: Ingeniero Electrónico PARTICIPA: Ingeniero Electrónico INICIO: 10-10-2013 FIN: 10-10-2013 HITOS IMPORTANTES: Fase de construcción STAKEHOLDER QUE Jefe de proyectos ACEPTA: REQUISITOS QUE DEBEN Utilizar los diseños elaborados CUMPLIRSE: en el la simulación de los componentes electrónicos. FORMA EN QUE SE Informe con los resultados ACEPTARÁ: obtenidos PERSONAL: Ingeniero Electrónico MATERIALES O Papeles CONSUMIBLES: Vaquelita Acido EQUIPOS O MÁQUINAS: Computadoras Planca ANTES DEL PDT: 4.2.1 DESPUÉS DEL PDT: 4.3.2

39

CÓDIGO DEL PAQUETE DE TRABAJO (PDT): SEGÚN EL WBS 4.3.2

NOMBRE DEL PAQUETE DE TRABAJO (PDT): SEGÚN EL WBS IMPLEMENTACION DE LOS COMPONENTES ELECTRONICOS EN PROTOBOARD

OBJETIVO DEL PAQUETE DE TRABAJO:

Se realizara el armado de los circuitos elaborados en la fase de análisis y diseño en protoboard para ver su correcto funcionamiento. Armado de el circuito en el protoboard

DESCRIPCIÓN DEL PAQUETE DE TRABAJO: DESCRIPCIÓN DEL TRABAJO A REALIZAR (ACTIVIDADES): ASIGNACIÓN DE RESPONSABILIDADES: FECHAS PROGRAMADAS: CRITERIOS DE ACEPTACIÓN:

RECURSOS ASIGNADOS :

ACTIVIDADES A REALIZAR: Armado del circuito electrónico RESPONSABLE: PARTICIPA: INICIO: FIN: HITOS IMPORTANTES: STAKEHOLDER QUE ACEPTA: REQUISITOS QUE DEBEN CUMPLIRSE: FORMA EN QUE SE ACEPTARÁ: PERSONAL: MATERIALES O CONSUMIBLES: EQUIPOS O MÁQUINAS: ANTES DEL PDT: DESPUÉS DEL PDT:

Ingeniero Electrónico Ingeniero Electrónico 10-10-2013 10-10-2013 Fase de construcción Jefe de proyectos Utilizar los diseños elaborados en el la simulación de los componentes electrónicos. Informe con los resultados obtenidos Ingeniero Electrónico Dispositivos electrónicos Computadora. Protoboard 4.3.1 4.3.3

40

CÓDIGO DEL PAQUETE DE TRABAJO (PDT): SEGÚN EL WBS 4.3.3 OBJETIVO DEL PAQUETE DE TRABAJO: DESCRIPCIÓN DEL PAQUETE DE TRABAJO: DESCRIPCIÓN DEL TRABAJO A REALIZAR (ACTIVIDADES):

ASIGNACIÓN RESPONSABILIDADES: FECHAS PROGRAMADAS: CRITERIOS DE ACEPTACIÓN:

RECURSOS ASIGNADOS:

DE

NOMBRE DEL PAQUETE DE TRABAJO (PDT):SEGÚN EL WBS PRUEBA DE LOS CIRCUITOS Se realizarán pruebas de los componentes electrónicos. Se probaran los circuitos electrónicos en el funcionamiento con la silla de ruedas ACTIVIDADES A REALIZAR: 1. Pruebas de corriente, voltaje. 2. Pruebas a los visualizadores. 3. Pruebas a los circuitos de control. 4. Pruebas a los circuitos de potencia. 5. Pruebas del uso de las protecciones contra corto circuitos. RESPONSABLE: Ingeniero. Electrónico PARTICIPA: Ingeniero. Electrónico INICIO: 01-08-2013 FIN: 25-09-2013 HITOS IMPORTANTES: Fase de construcción STAKEHOLDER QUE Jefe de proyectos ACEPTA: REQUISITOS QUE DEBEN Cumplir con las CUMPLIRSE: especificaciones de seguridad FORMA EN QUE SE Informe ACEPTARÁ: PERSONAL: Ingeniero. Electrónico MATERIALES O Materiales empleados en el CONSUMIBLES: paquete de trabajo 4.3.1 y 4.3.2 EQUIPOS O MÁQUINAS: Computadora ANTES DEL PDT: 3.3 -3.4 DESPUÉS DEL PDT: 4.3.3

41

CÓDIGO DEL PAQUETE DE TRABAJO (PDT): SEGÚN EL WBS 4.3.4

NOMBRE DEL PAQUETE DE TRABAJO (PDT):SEGÚN EL WBS INTEGRACION Y SOLDADO DE LOS COMPONENTES ELECTRONICOS

OBJETIVO DEL PAQUETE DE TRABAJO: DESCRIPCIÓN DEL PAQUETE DE TRABAJO: DESCRIPCIÓN DEL TRABAJO AREALIZAR (ACTIVIDADES): ASIGNACIÓN DE RESPONSABILIDADES: FECHAS PROGRAMADAS:

Se realizara el soldado de los componentes electrónicos en las placas correspondientes. Soldado de los componentes electrónicos

CRITERIOS DE ACEPTACIÓN:

RECURSOS ASIGNADOS:

ACTIVIDADES A REALIZAR: Soldado de los componentes electrónicos. RESPONSABLE: Ingeniero Electrónico PARTICIPA: Ingeniero Electrónico INICIO: 01-08-2013 FIN: 25-09-2013 HITOS IMPORTANTES: Fase de construcción STAKEHOLDER QUE Jefe de proyectos ACEPTA: REQUISITOS QUE DEBEN Integración y soldado de los CUMPLIRSE: componentes electrónicos utilizando los paquetes 3.3.13.3.2-4.3.1 FORMA EN QUE SE Informe de los resultados ACEPTARÁ: obtenidos PERSONAL: Ingeniero Electrónico MATERIALES O Soldadura CONSUMIBLES: Pasta EQUIPOS O MÁQUINAS: Pistola ANTES DEL PDT: 4.3.1 DESPUÉS DEL PDT: 4.4

42

CÓDIGO DEL PAQUETE DE TRABAJO (PDT): SEGÚN EL WBS 4.4.1

NOMBRE DEL PAQUETE DE TRABAJO (PDT):SEGÚN EL WBS INTEGRACION Y DETECCION DE FALLAS

OBJETIVO DEL PAQUETE DE TRABAJO:

Se integrara los módulos de desarrollo de reconocimiento de voz, desarrollo de prototipo de la silla de ruedas y los circuitos armados para determinar el correcto funcionamiento. Armado de todo el proyecto

DESCRIPCIÓN DEL PAQUETE DE TRABAJO: DESCRIPCIÓN DEL TRABAJO A REALIZAR (ACTIVIDADES): ASIGNACIÓN DE RESPONSABILIDADES: FECHAS PROGRAMADAS: CRITERIOS DE ACEPTACIÓN:

RECURSOS ASIGNADOS:

ACTIVIDADES A REALIZAR: Armar el proyecto. Juntando todos los procesos desarrollados RESPONSABLE: Jefe de proyectos PARTICIPA: Equipo de trabajo INICIO: 01-08-2013 FIN: 25-09-2013 HITOS IMPORTANTES: Fase de construcción STAKEHOLDER QUE Jefe de proyectos ACEPTA: REQUISITOS QUE DEBEN Cumplir con el tiempo de CUMPLIRSE: entrega de cada actividad para el armado del mismo FORMA EN QUE SE Informe de los resultados ACEPTARÁ: obtenidos PERSONAL: Equipo de tranajo MATERIALES O Componentes previamente CONSUMIBLES: desarrollados EQUIPOS O MÁQUINAS: Computadoras ANTES DEL PDT: 4.3.1 DESPUÉS DEL PDT: 4.4

43

CÓDIGO DEL PAQUETE DE TRABAJO (PDT): SEGÚN EL WBS 4.5

NOMBRE DEL PAQUETE DE TRABAJO (PDT):SEGÚN EL WBS PRUEBAS FINALES

OBJETIVO DEL PAQUETE DE TRABAJO: DESCRIPCIÓN DEL PAQUETE DE TRABAJO: DESCRIPCIÓN DEL TRABAJO A REALIZAR (ACTIVIDADES):

Realizar la pruebas finales que cumplan con los requisitos del proyecto Se realizar las pruebas finales en conjunto.

ASIGNACIÓN RESPONSABILIDADES: FECHAS PROGRAMADAS: CRITERIOS DE ACEPTACIÓN:

RECURSOS ASIGNADOS:

DE

ACTIVIDADES A REALIZAR: 1. Pruebas del módulo de procesamiento de voz. 2. Pruebas de campo para determinar algún problema en el proyecto. RESPONSABLE: Jefe de proyectos PARTICIPA: Equipo de trabajo INICIO: 01-08-2013 FIN: 25-09-2013 HITOS IMPORTANTES: Fase de cierre STAKEHOLDER QUE Jefe de proyectos ACEPTA: REQUISITOS QUE DEBEN Cumplir con el control de CUMPLIRSE: calidad y la verificación de los requerimientos FORMA EN QUE SE Documento de informe ACEPTARÁ: PERSONAL: Equipo de proyectos MATERIALES O Papeles CONSUMIBLES: EQUIPOS O MÁQUINAS: Computadora ANTES DEL PDT: 4.3.1 DESPUÉS DEL PDT: 4.4

44

CÓDIGO DEL PAQUETE DE TRABAJO (PDT): SEGÚN EL WBS 5.1

NOMBRE DEL PAQUETE DE TRABAJO (PDT):SEGÚN EL WBS MANUALES

OBJETIVO DEL PAQUETE DE TRABAJO:

Tienen como propósito orientar al usuario con el uso del módulo, responderle preguntas comunes y toda la información adicional que pueda serle útil al usuario.

DESCRIPCIÓN DEL PAQUETE DE TRABAJO: DESCRIPCIÓN DEL TRABAJO AREALIZAR (ACTIVIDADES):

Elaboración de los manuales de usuario.

ASIGNACIÓN RESPONSABILIDADES: FECHAS PROGRAMADAS: CRITERIOS DE ACEPTACIÓN:

RECURSOS ASIGNADOS:

DE

ACTIVIDADES A REALIZAR: 1. Elaboración del manual de usuario 2. Revisión del manual de usuario. 3. Correcciones al manual de usuario. 4. Aprobación del manual de usuario firmado por todo el equipo de trabajo RESPONSABLE: Jefe de proyectos PARTICIPA: Equipo de trabajo INICIO: 01-08-2013 FIN: 25-09-2013 HITOS IMPORTANTES: Fase de cierre STAKEHOLDER QUE Jefe de proyectos ACEPTA: REQUISITOS QUE DEBEN Tener coherencia con los CUMPLIRSE: requerimientos y/o funcionalidades descritas en el desarrollo del proyecto FORMA EN QUE SE Impresa y CD’s ACEPTARÁ: PERSONAL: Equipo de trabajo MATERIALES O Papeles CONSUMIBLES: EQUIPOS O MÁQUINAS: Computadora ANTES DEL PDT: 4.3.1 DESPUÉS DEL PDT: 4.4

45

UNIVERSIDAD ALAS PERUANAS – FILIAL AREQUIPA

8. RED DEL PROYECTO NOMBRE DEL PROYECTO PROTOTIPO DE UN SISTEMA DE MANEJO PARA UNA SILLA DE RUEDAS UTILIZANDO UN MODULO DE PROCESAMIENTO DE VOZ

SIGLAS DEL PROYECTO PSVOZ

GRAFICA 7 RED Nº1 (PRIMERA PARTE)

FUENTE: ELABORACION PROPIA

46

UNIVERSIDAD ALAS PERUANAS – FILIAL AREQUIPA

GRAFICA 8 RED Nº2 (SEGUNDA PARTE)

FUENTE: ELABORACION PROPIA GRAFICA 9 RED Nº3 (TERCERA PARTE)

FUENTE: ELABORACION PROPIA GRAFICA 10 RED Nº4 (CUARTA PARTE)

47

UNIVERSIDAD ALAS PERUANAS – FILIAL AREQUIPA

FUENTE: ELABORACION PROPIA

48

UNIVERSIDAD ALAS PERUANAS – FILIAL AREQUIPA

GRAFICA 11 RED Nº5 (QUINTA PARTE)

FUENTE: ELABORACION PROPIA

GRAFICA 12 RED Nº6 (SEXTA PARTE)

49

UNIVERSIDAD ALAS PERUANAS – FILIAL AREQUIPA

FUENTE: ELABORACION PROPIA GRAFICA 13 RED Nº7 (SEPTIMA PARTE)

FUENTE: ELABORACION PROPIA GRAFICA 14 RED Nº8 (OCTAVA PARTE)

50

UNIVERSIDAD ALAS PERUANAS – FILIAL AREQUIPA

FUENTE: ELABORACION PROPIA

51

UNIVERSIDAD ALAS PERUANAS – FILIAL AREQUIPA

GRAFICA 15 RED Nº9 (NOVENA PARTE)

FUENTE: ELABORACION PROPIA GRAFICA 16 RED Nº10 (DECIMA PARTE)

FUENTE: ELABORACION PROPIA

52

UNIVERSIDAD ALAS PERUANAS – FILIAL AREQUIPA

9. CRONOGRAMA DEL PROYECTO NOMBRE DEL PROYECTO PROTOTIPO DE UN SISTEMA DE MANEJO PARA UNA SILLA DE RUEDAS UTILIZANDO UN MODULO DE PROCESAMIENTO DE VOZ

SIGLAS DEL PROYECTO PSVOZ

53

UNIVERSIDAD ALAS PERUANAS – FILIAL AREQUIPA

54

UNIVERSIDAD ALAS PERUANAS – FILIAL AREQUIPA

55

UNIVERSIDAD ALAS PERUANAS – FILIAL AREQUIPA

56

UNIVERSIDAD ALAS PERUANAS – FILIAL AREQUIPA

57

UNIVERSIDAD ALAS PERUANAS – FILIAL AREQUIPA

10. GESTIÓN DE COSTOS NOMBRE DEL PROYECTO PROTOTIPO DE UN SISTEMA DE MANEJO PARA UNA SILLA DE RUEDAS UTILIZANDO UN MODULO DE PROCESAMIENTO DE VOZ REQUERIMIENTOS DE HARDWARE DESCRIPCIÓN HARDWARE CANTIDAD LAPTOP 1  Memoria RAM: 4GB  Disco Duro: 500GB  Procesador core2Duo IMPRESORA 1  Multifuncional. REQUERIMIENTOS DE SOFTWARE DESCRIPCIÓN SOFTWARE CANTIDAD Visual studio C# 2010. 1 SQL server estándar 2005 1 express. Microsoft Office home and 1 student. Star UML 1 RECURSOS HUMANOS CARGOS Jefe de proyecto Analista de sistemas Ingeniero Electrónico.

Nº MESES 6 6 3

SUMINISTROS DE ESCRITORIO DESCRIPCION Memoria USB de 4GB Folders / Sobre manilla Útiles de escritorio Recarga de tinta Hojas Bond

CANTIDAD 1 1 1 2 ½ millar

SIGLAS DEL PROYECTO PSVOZ

PRECIO/UNIDAD S/. 1300.00

TOTAL COSTO S/. 1300.00

S/. 300.00

S/. 300.00

TOTAL

S/. 1600.00

PRECIO/UNIDAD S/. 265.00 S/. 00.00

TOTAL COSTO S/. 265.00 S/. 00.00

S/. 00.00

S/. 00.00

S/. 00.00 TOTAL

S/. 00.00 S/. 265.00

PRECIO/MES S/. 1 300.00 S/. 1 000.00 S/. 900.00 TOTAL

TOTAL COSTO S/. 7 800.00 S/. 6 000.00 S/. 1 800.00 S/. 16500.00

PRECIO/UNIDAD S/.30.00 S/. 10.00 S/. 30.00 S/. 10.00 S/. 14.00 TOTAL

TOTAL COSTO S/.30.00 S/.10.000 S/.30.00 S/.20.00 S/.14.00 S/.104.00

58

UNIVERSIDAD ALAS PERUANAS – FILIAL AREQUIPA

SERVICIOS DESCRIPCION Servicios de internet y teléfono Suministro eléctrico Recurso hídrico Movilidad

CANTIDAD 4 4 4 4

RESUMEN DEL PRESUPUESTO DESCRIPCION  Requerimiento de hardware  Requerimientos de software  Recursos Humanos  Suministros de escritorio  Servicios TOTAL

PRECIO/UNIDAD S/. 139.00 S/. 35.00 S/. 15.00 S/. 20.00 TOTAL

TOTAL COSTO S/. 556.00 S/. 140.00 S/. 60.00 S/. 80.00 S/. 836.00 TOTAL COSTO S/.1600.00 S/.265.00 S/.16500.00 S/.104.00 S/. 836.00 S/. 19305.00

59

UNIVERSIDAD ALAS PERUANAS – FILIAL AREQUIPA

N VALORIZADA DEL PROYECTO

E

OS

Director de proyecto Analista de sistemas Ingeniero electrónico una laptop Impresora multifuncional Microsoft office Home and student SQL server estándar2005 express Visual Studio C# 2010 Star UML Memoria USB de 4GB Folders / Sobre manilla Útiles de escritorio Recarga de tinta Hojas Bond Servicios de internet y teléfono Suministro eléctrico Recurso hídrico Movilidad TOTAL

MAYO S/. 1 300.00 S/. 1 000.00

JUNIO S/. 1 300.00 S/. 1 000.00

JULIO S/. 1 300.00 S/. 1 000.00 S/. 900.00

AGOSTO S/. 1 300.00 S/. 1 000.00 S/. 900.00

SETIEMBRE S/. 1 300.00 S/. 1 000.00 S/. 900.00

OCT S/. 1 S/. 1

S/. 139.00 S/. 35.00 S/. 15.00 S/. 20.00

S/. 139.00 S/. 35.00 S/. 15.00 S/. 20.00

S/. 1 S/. 3 S/. 1 S/. 2

S/. 1 300.00 S/. 300.00 S/. 0.00 S/. 0.00 S/. 265.00 S/. 0.00 S/. 30.00 S/. 10.00 S/. 20.00 S/. 10.00 S/. 14.00 S/. 139.00 S/. 35.00 S/. 15.00 S/. 20.00 S/. 14 055.00

S/. 10.00 S/. 10.00 S/. 139.00 S/. 35.00 S/. 15.00 S/. 20.00

S/. 139.00 S/. 35.00 S/. 15.00 S/. 20.00

60

UNIVERSIDAD ALAS PERUANAS – FILIAL AREQUIPA

ESTIMACIÓN VALORIZADA ACUMULADA DEL PROYECTO alorizada acumulada del proyecto se puede analizar los gastos que se ha estado realizando por cada mes de desarrollo del proyecto. MAYO

JUNIO

JULIO

AGOSTO

SETIEMBRE

OCTUBRE

Director de proyecto

S/. 1 300.00

S/. 1 300.00

S/. 1 300.00

S/. 1 300.00

S/. 1 300.00

S/. 1 300.00

Analista de sistemas

S/. 1 000.00

S/. 1 000.00

S/. 1 000.00

S/. 1 000.00

S/. 1 000.00

S/. 1 000.00

S/. 900.00

Ingeniero electrónico

S/. 900.00

S/. 900.00

una laptop

S/. 1 300.00

S/. 1 300.00

S/. 1 300.00

Impresora multifuncional

S/. 300.00

S/. 300.00

S/. 300.00

Microsoft office Home and student

S/. 0.00

S/. 0.00

S/. 0.00

SQL server estándar2005 express

S/. 0.00

S/. 0.00

S/. 0.00

Visual Studio C# 2010

S/. 265.00

S/. 265.00

S/. 265.00

S/. 0.00

S/. 0.00

S/. 0.00

S/. 30.00

S/. 30.00

S/. 10.00

S/. 10.00

S/. 30.00

S/. 30.00

S/. 20.00

S/. 20.00

S/. 14.00

S/. 14.00

Star UML Memoria USB de 4GB

S/. 30.00

Folders / Sobre manilla

S/. 10.00

Útiles de escritorio

S/. 20.00

Recarga de tinta

S/. 10.00

Hojas Bond

S/. 14.00

Servicios de internet y teléfono

S/. 139.00

S/. 139.00

S/. 139.00

S/. 139.00

S/. 556.00

S/. 556.00

Suministro eléctrico

S/. 35.00

S/. 35.00

S/. 35.00

S/. 35.00

S/. 140.00

S/. 140.00

Recurso hídrico

S/. 15.00

S/. 15.00

S/. 15.00

S/. 15.00

S/. 60.00

S/. 60.00

Movilidad

S/. 20.00

S/. 20.00

S/. 20.00

S/. 20.00

S/. 80.00

S/. 80.00

TOTAL

S/. 19305.00

S/. 10.00 S/. 10.00

11. PLAN DE GESTIÓN DE LA CALIDAD NOMBRE DEL PROYECTO PROTOTIPO DE UN SISTEMA DE MANEJO PARA UNA SILLA DE RUEDAS UTILIZANDO UN MODULO DE PROCESAMIENTO DE VOZ

SIGLAS DEL PROYECTO PSVOZ

DESCRIPCIÓN DEL PRODUCTO: El siguiente proyecto se propone para brindar una ayuda a las personas con discapacidades que no pueden movilizarse por sí solas. Razón por la cual este proyecto va enfocada en aquello que es de mucha utilidad al momento de movilizarse de un lugar hacia otro. El eje principal de este proyecto va enfocado al reconocimiento de patrones o comandos de voz que ejecuten una acción determinada. POLÍTICA DE CALIDAD DEL PROYECTO: Este proyecto debe cumplir con los requisitos de calidad, es decir acabar dentro del tiempo y el presupuesto planificados, y también debe cumplir con los requisitos de calidad. LÍNEA BASE DE CALIDAD DEL PROYECTO: FACTOR DE OBJETIVO DE CALIDAD CALIDAD RELEVANTE PERFOMANCE DEL CPI>= 0.95

METRICA A UTILIZAR CPI= COST

FRECUENCIA Y MOMENTO DE MEDICION FRECUENCIA,

FRECUENCIA Y MOMENTO DE REPORTE FRECUENCIA 61

UNIVERSIDAD ALAS PERUANAS – FILIAL AREQUIPA

PROYECTO

PERFOMANCE DEL PROYECTO

PERFOMANCE INDEX ACUMULADO SPI >= 0.95

SPI= SCHEDULE PERFOMANCE INDEX ACUMULADO

SEMANAL

SEMANAL

MEDICIÓN, VIERNES

REPORTE, VIERNES

EN LA MAÑANA FRECUENCIA,

FRECUENCIA

SEMANAL

SEMANAL

MEDICIÓN, VIERNES

REPORTE, VIERNES

SATISFACCIÓN DE

NIVEL DE

NIVEL DE

EN LA MAÑANA FRECUENCIA, UNA

LOS DISTRIBUIDORES

SATISFACCIÓN >= 4.0

SATISFACCIÓN=

ENCUESTA

PROMEDIO ENTRE 1 A 5 DE 14 FACTORES SOBRE MANUAL Y CAPACITACIÓN.

SEMANAL.

MEDICIÓN, AL DÍA SIGUIENTE DE LA ENCUESTA

EN LA TARDE

EN LA TARDE

FRECUENCIA, UNA VEZ POR SEMANA. REPORTE, AL DÍA SIGUIENTE DE LA MEDICIÓN

PLAN DE MEJORA DE PROCESOS: Cada vez que se deba mejorar un proceso se seguirán los siguientes pasos: 1. Delimitar el proceso 2. Determinar la oportunidad de mejora 3. Tomar información sobre el proceso 4. Analizar la información levantada 5. Definir las acciones correctivas para mejorar el proceso 6. Aplicar las acciones correctivas 7. Verificar si las acciones correctivas han sido efectivas 8. Estandarizar las mejoras logradas para hacerlas parte del proceso MATRIZ DE ACTIVIDADES DE CALIDAD:. ENTREGABLE ESTÁNDAR DE CALIDAD APLICABLE Project Charter Metodología de Gestión de Proyectos de Dharma Consulting Scope Statement Metodología de Gestión de Proyectos de Dharma Consulting Plan de Proyecto Metodología de Gestión de Proyectos de Dharma Consulting Informe de Estado Metodología de Gestión de Proyectos de Dharma Consulting Reunión de Metodología de Gestión coordinación Semanal de Proyectos de Dharma Consulting Cierre de Proyecto Metodología de Gestión de Proyectos de Dharma Consulting Listado de Necesidades

ACTIVIDADES DE PREVENCIÓN

ACTIVIDADES DE CONTROL Aprobación por Sponsor Aprobación por Sponsor Aprobación por Sponsor Aprobación por Sponsor Aprobación por Sponsor Aprobación por Sponsor Revisión/Aprobación por Sponsor 62

UNIVERSIDAD ALAS PERUANAS – FILIAL AREQUIPA

Orden de compra

Estándar de Orden de compra

Orden de compra equipos y suministros

Estándar de Orden de compra

Equipos y suministros

Negociación detallada

Reporte Implementación

Formato exigido por LA EMPRESA

Revisión de modelos de formatos

Informe mes 1

Formato exigido por LA EMPRESA

Revisión de modelos de formatos

Informe mes 2

Formato exigido por LA EMPRESA

Revisión de modelos de formatos

Informe mes 3

Formato exigido por LA EMPRESA

Revisión de modelos de formatos

Informe Final

Formato exigido por LA EMPRESA

Revisión de modelos de formatos

Revisión por Project Manager y Aprobación del Sponsor Revisión por Project Manager y Aprobación del Sponsor Revisión por Project Manager Aprobación por OFICINA TECNICA DE LA EMPRESA Aprobación por OFICINA TECNICA DE LA EMPRESA Aprobación por OFICINA TECNICA DE LA EMPRESA Aprobación por OFICINA TECNICA DE LA EMPRESA Aprobación por OFICINA TECNICA DE LA EMPRESA

63

UNIVERSIDAD ALAS PERUANAS – FILIAL AREQUIPA

ROLES PARA LA GESTIÓN DE LA CALIDAD: Objetivos del rol: ROL NO 1 : Responsable ejecutivo y final por la calidad del proyecto Funciones del rol: SPONSOR Revisar, aprobar, y tomar acciones correctivas para mejorar la calidad Niveles de autoridad: Aplicar a discreción los recursos de Dharma Consulting para el proyecto, renegociar contratos Reporta a: Directorio Supervisa a: Project Manager Requisitos de conocimientos: Project Management y Gestión en General Requisitos de habilidades: Liderazgo, Comunicación, Negociación, Motivación, y Solución de Conflictos Requisitos de experiencia: más de 20 años de experiencia en el ramo Objetivos del rol: ROL NO 2 : Gestionar operativamente la calidad PROJECT MANAGER Funciones del rol: Revisar estándares, revisar entregables, aceptar entregables o disponer su reproceso, deliberar para generar acciones correctivas, aplicar acciones correctivas Niveles de autoridad : Exigir cumplimiento de entregables al equipo de proyecto Reporta a: Sponsor Supervisa a: Equipo de Proyecto Requisitos de conocimientos: Gestión de Proyectos Requisitos de habilidades: Liderazgo, Comunicación, Negociación, Motivación, y Solución de Conflictos Requisitos de experiencia: 3 años de experiencia en el cargo Objetivos del rol: ROL NO 3 : Elaborar los entregables con la calidad requerida y según estándares Funciones del rol : MIEMBROS DEL Elaborar los entregables EQUIPO DE Niveles de autoridad: PROYECTO Aplicar los recursos que se le han asignado Reporta a: Project Manager Supervisa a: Requisitos de conocimientos: Gestión de Proyectos y las especialidades que le tocan según sus entregables asignados

64

UNIVERSIDAD ALAS PERUANAS – FILIAL AREQUIPA

Requisitos de habilidades: Específicas según los entregables Requisitos de experiencia: Específicas según los entregables

65

UNIVERSIDAD ALAS PERUANAS – FILIAL AREQUIPA

ORGANIZACIÓN PARA LA CALIDAD DEL PROYECTO:

SPONSOR Comité de Control de Cambios

PROJECT

MANAGER

EQUIPO DE PROYECTO DOCUMENTOS NORMATIVOS PARA LA CALIDAD: 1 .Para Mejora de Procesos 2. Para Auditorias de Procesos 3. Para Reuniones de Aseguramiento de Calidad PROCEDIMIENTOS 4. Para Resolución de Problemas 1. Métricas PLANTILLAS 2. Plan de Gestión de Calidad 1. Métricas FORMATOS 2. Línea Base de Calidad 3. Plan de Gestión de Calidad 1. De Métricas CHECKLISTS 2. De Auditorias 3. De Acciones Correctivas PROCESOS DE GESTIÓN DE LA CALIDAD: El aseguramiento de calidad se hará monitoreando continuamente la perfomance del trabajo, los resultados del control de calidad, y sobre todo las métricas De esta manera se descubrirá tempranamente cualquier necesidad de auditoria ENFOQUE DE ASEGURAMIENTO DE de procesos, o de mejora de procesos Los resultados se formalizarán como solicitudes de cambio y/o acciones LA CALIDAD correctivas/preventivas Asimismo se verificará que dichas solicitudes de cambio, y/o acciones correctivas/preventivas se hayan ejecutado y hayan sido efectivas El control de calidad se ejecutara revisando los entregables para ver si están conformes o no Los resultados de estas mediciones se consolidarán y se enviarán al proceso de aseguramiento de calidad ENFOQUE DE Asimismo en este proceso se hará la medición de las métricas y se informarán al CONTROL DE LA proceso de aseguramiento de calidad CALIDAD Los entregables que han sido reprocesados se volverán a revisar para verificar si ya se han vuelto conformes Para los defectos detectados se tratará de detectar las causas raíces de los defectos para eliminar las fuentes del error, los resultados y conclusiones se formalizarán como solicitudes de cambio y/o acciones correctivas/preventivas

66

UNIVERSIDAD ALAS PERUANAS – FILIAL AREQUIPA

Cada vez que se requiera mejorar un proceso se seguirá lo siguiente: 1. Delimitar el proceso 2. Determinar la oportunidad de mejora 3. Tomar información sobre el proceso ENFOQUE DE MEJORA 4. Analizar la información levantada DE PROCESOS 5. Definir las acciones correctivas para mejorar el proceso 6. Aplicar las acciones correctivas 7. Verificar si las acciones correctivas han sido efectivas 8. Estandarizar las mejoras logradas para hacerlas parte del proceso

67

UNIVERSIDAD ALAS PERUANAS – FILIAL AREQUIPA

12. PLAN DE GESTIÓN DE RIESGOS NOMBRE DEL PROYECTO PROTOTIPO DE UN SISTEMA DE MANEJO PARA UNA SILLA DE RUEDAS UTILIZANDO UN MODULO DE PROCESAMIENTO DE VOZ METODOLOGÍA DE GESTIÓN DE RIESGOS PROCESO DESCRIPCION Planificación de Gestión de los Riesgos Identificación de Riesgos

SIGLAS DEL PROYECTO PSVOZ

HERRAMIENTAS

FUENTES DE INFORMACION Sponsor y usuarios. PM y equipo de proyecto Sponsor y usuarios. PM y equipo de proyecto Archivos históricos de proyectos

Elaborar Plan de Guia del PMBOK® Gestión de los Riesgos Compendio PMI® Identificar que riesgos Checklists de riesgos pueden afectar el proyecto y documentar sus características Planificación de Definir respuesta a Plan de respuesta a Sponsor y usuarios. Respuesta a los riesgos Planificar riesgos PM y equipo de proyecto Riesgos ejecución de Archivos históricos de respuestas proyectos Seguimiento y Control Verificar la ocurrencia Plan de monitoreo y Sponsor y usuarios. del Riesgos de riesgos. Supervisar y control PM y equipo de proyecto verificar la ejecución de respuestas. Verificar aparición de nuevos riesgos ROLES Y RESPONSABILIDADES DE GETSION DE RIESGOS PROCESO ROLES RESPONSABILIDADES Planificación de Equipo de G. Riesgos Dirigir actividad, responsable Gestión de los Líder directo Riesgos Apoyo Proveer definiciones Miembros Ejecutar Actividad Identificación de Equipo de G. Riesgos Dirigir actividad, responsable Riesgos Líder directo Apoyo Proveer definiciones Miembros Ejecutar Actividad Análisis Cuantitativo Equipo de G. Riesgos No aplica de Riesgos Líder Apoyo Miembros Planificación de Equipo de G. Riesgos Dirigir actividad, responsable Respuesta a los Líder directo Riesgos Apoyo Proveer definiciones Miembros Ejecutar Actividad Seguimiento y Equipo de G. Riesgos Dirigir actividad, responsable Control del Riesgos Líder directo Apoyo Proveer definiciones Miembros Ejecutar Actividad

68

UNIVERSIDAD ALAS PERUANAS – FILIAL AREQUIPA

PERIOCIDAD DE LA GESTION DE RIESGOS PROCESO MOMENTO DE EJECUCION Planificación de Al inicio del proyecto Gestión de los Riesgos Identificación de Riesgos Análisis Cualitativo de Riesgos Planificación de Respuesta a los Riesgos Seguimiento y Control del Riesgos

Al inicio del proyecto En cada reunión del equipo del proyecto Al inicio del proyecto En cada reunión del equipo del proyecto Al inicio del proyecto En cada reunión del equipo del proyecto En cada fase del proyecto

ENTREGABLES WBS 1.1 Reuniones 2.1 Cronograma recursos 1.1 Reuniones 4.3 Desarrollo aplicación 1.1 Reuniones 4.3 Desarrollo aplicación 1.1 Reuniones 4.3 Desarrollo aplicación 1.1 Reuniones 4.3 Desarrollo aplicación

PERIOCIDAD DE EJECUCION Una vez

de

de la

Una vez Semanal

de la

Una vez Semanal

de la

Una vez Semanal Semanal

de la

TIPOS DE RIESGOS  Riesgos del proyecto: afectan a la calendarización o recursos del proyecto 

Riesgos del producto: afectan la calidad o desempeño del software que se está desarrollando.

 Riesgo de negocio: afectan a la organización que desarrolla el software. RIESGOS TÉCNICOS  Que se genere un mal diseño en la base de datos, que no cubre los requisitos de software.  Que se genere problemas en el diseño de interfaz. PRESUPUESTOS  Que el presupuesto se recorte en pleno desarrollo del sistema.  Que el presupuesto no haya sido calculado de manera correcta. Pudiendo faltar o sobrar de una manera considerable.  Que haya demoras en la entrega del dinero pactado. PERSONAL  El personal proporciona capacidad inaceptable para el desarrollo del proyecto. Por lo que hay que añadir un tiempo extra para dar capacitación.  Personal abandona el proyecto antes de su finalización.  Poca habilidad del desarrollador para comunicarse con el cliente  Que el personal no esté capacitado para el uso de tecnología de punta. PLANIFICACION  La planificación realizada no incluye tareas necesarias.  No se puede construir el producto planificado en el tiempo asignado. RECURSOS  La herramienta de desarrollo no están listos en el momento deseado.  Los recursos de infraestructura no están disponibles en el momento necesario.

69

UNIVERSIDAD ALAS PERUANAS – FILIAL AREQUIPA

CLIENTES  El cliente insiste en nuevos requisitos, después de la etapa de levantamiento de requerimientos.  El cliente no participa en la presentación de los avances del prototipo, resultando alargar el tiempo de respuesta.  Tiempo de respuesta, más lento de lo esperado a las preguntas para aclarar los requisitos.  Los componentes suministrados por el cliente no son adecuados para el funcionamiento del software, por lo que se tiene que hacer trabajo extra de diseño e integración.  El cliente no acepta el software entregado, incluso aunque cumpla con todas sus especificaciones.  El cliente piensa en una velocidad de desarrollo que el personal de desarrollo no puede alcanzar. REQUISITOS  Los requisitos se han adaptado pero, continúan cambiando.  Los requisitos no se han definido correctamente. Y su redefinición genera problemas.  Se añade requisitos extras, a mitad de desarrollo.  Requisitos diseñados no concuerdan con los deseados por el cliente. ANALISIS CUALITATIVOS DE RIESGOS CALIFICACION DE RIESGOS PROBABILIDA D Insignificante E A: Muy probable Medio B: Probable Menor C: Posible Menor D: Poco Probable Menor E: Raro Menor F: Muy Raro Menor

CONSECUENCIA - IMPACTO Menor D Medio Medio Medio Menor Menor Menor

Moderado C Mayor Mayor Medio Medio Medio Menor

Mayor B Extremo Mayor Mayor Medio Medio Medio

Catastrófico A Extremo Extremo Mayor Mayor Medio Medio

70

UNIVERSIDAD ALAS PERUANAS – FILIAL AREQUIPA

ANÁLISIS DE LOS RIESGOS DEL PROYECTO ANÁLISIS CUALITATIVOS Y CUANTITATIVOS DE LOS RIESGOS RIESGOS ACTUAL Probabilidad TECNICOS Diseño de la base de datos, no cubre los C B requisitos. Que se genere problemas en el diseño B C de interfaz. PRESUPUESTO Que el presupuesto se recorte en pleno D desarrollo del sistema. Que el presupuesto no haya sido calculado de manera correcta. Pudiendo C faltar o sobrar de una manera considerable. Que haya demoras en la entrega del B dinero pactado. PERSONAL El personal proporciona capacidad inaceptable para el desarrollo del D proyecto Personal abandona el proyecto antes de D su finalización. Poca habilidad del desarrollador para D comunicarse con el cliente Que el personal no esté capacitado para C el uso de tecnología de punta. PLANIFICACIÓN La planificación realizada no incluye E tareas necesarias No se puede construir el producto D planificado en el tiempo asignado. RECURSOS La herramienta de desarrollo no está E lista en el momento deseado. Los recursos de infraestructura no están E disponibles en el momento necesario. CLIENTES El cliente insiste en nuevos requisitos A El cliente no participa en la presentación A de los avances del prototipo Tiempo de respuesta, más lento de lo esperado a las preguntas para aclarar A los requisitos Los componentes suministrados por el cliente no son adecuados para el C funcionamiento del software El cliente no acepta el software entregado, incluso aunque cumpla con E todas sus especificaciones. El cliente piensa en una velocidad de B desarrollo que el personal de desarrollo

Impacto

Prioridad MAYOR MAYOR

A

MAYOR

B

MAYOR

C

MAYOR

C

MEDIO

B

MEDIO

D

MENOR

C

MEDIO

B

MEDIO

B

MEDIO

B

MEDIO

B

MEDIO

B

EXTREMO

C

MAYOR

C

MAYOR

B

MAYOR

B

MEDIO

E

MENOR

71

UNIVERSIDAD ALAS PERUANAS – FILIAL AREQUIPA

no puede alcanzar. REQUISITOS Los requisitos se han adaptado pero, continúan cambiando. Los requisitos no se han definido correctamente. Y su redefinición genera problemas. Se añade requisitos extras, a mitad de desarrollo. Requisitos diseñados no concuerdan con los deseados por el cliente.

A

B

EXTREMO

C

B

MAYOR

B

B

MAYOR

C

B

MAYOR

13. PLAN DE RESPUESTA A LOS RIESGOS

RESPUESTAS AL RIESGO

ACTUAL

RIESGOS PROBABILIDAD

IMPACTO

ACCIÓN A TOMAR

PRIORIDAD

TÉCNICOS Diseño de la base de datos, no cubre los requisitos.

C

B

Mayor

Que se genere problemas en el diseño de interfaz.

B

C

Mayor

El analista se debe volver a tomar en forma rápida y modificar el diseño de la base de datos El analista debe ver localizar el problema del interfaz y dar una solución

El analista debe verificar alcance del diseño de la bas de datos.

El analista debe verificar alcance del diseño de interfa

PRESUPUESTO Que el presupuesto se recorte en pleno desarrollo del sistema. Que el presupuesto no haya sido calculado de manera correcta. Pudiendo faltar o sobrar de una manera considerable. Que haya demoras en la entrega del dinero pactado.

D

A

Mayor

Tener un plan de contingencia para recortes del presupuesto.

Dar un seguimiento d presupuesto conforme vay avanzando el proyecto.

Definir correctamente lo recursos que se van a utiliz en el proyecto.

Definir bien las fechas d pago en el contrato.

C

B

Mayor

Dar un informe con el presupuesto consumido en el proyecto

B

C

Mayor

Tener una reunión de emergencia con el Sponsor

PERSONAL El personal proporciona capacidad inaceptable para el desarrollo del proyecto Personal proyecto

abandona antes de

el su

D

C

Medio

D

B

Medio

Contratar personal alternativo para casos de retirar de alguno de ellos. contratar personal alternativo para

Capacitar al personal informar continuamente cronograma del proyecto

Tener personal alternativ para casos de abandono d 72

UNIVERSIDAD ALAS PERUANAS – FILIAL AREQUIPA RESPUESTAS AL RIESGO

ACTUAL

RIESGOS PROBABILIDAD

IMPACTO

PRIORIDAD

finalización. Poca habilidad del desarrollador para comunicarse con el cliente Que el personal no esté capacitado para el uso de tecnología de punta.

D

C

D

C

ACCIÓN A TOMAR

Menor

Medio

casos de abandono de alguno de ellos El director del proyecto se comunicaría con el cliente Contratar personal alternativo para casos de falta de capacitación de alguno de ellos.

alguno de ellos.

Capacitar al person planteando estrategias d comunicación fluida y direc con el cliente.

Seleccionar al personal qu cumpla con los requisitos en uso de las tecnologías utilizar en el proyecto.

PLANIFICACIÓN La planificación realizada no incluye tareas necesarias No se puede construir el producto planificado en el tiempo asignado.

E

B

Medio

Hacer una planificación con todos los objetivos necesarios

D

B

Medio

Pedir más tiempo para la construcción

La planificación deberá est muy bien sustentada, ante un reunión de interesados.

Al momento de la adquisició de herramienta, firmar u contrato con penalidades an el no cumplimiento.

Realizar una planificación co todos sus objetivos demostrados ante un superio

RECURSOS La herramienta de desarrollo no está lista en el momento deseado. Los recursos infraestructura no disponibles. CLIENTES

de están

El cliente insiste en nuevos requisitos

E

B

Medio

Tener una reunión Urgente con el Sponsor

E

B

Medio

Tener una reunión Urgente con el Sponsor

Verificar la correcta instalació del ambiente de trabajo.

Extremo

Estipular en el contrato, donde especifique la fecha de inicio y fin del levantamiento de los requisitos.

Estipular en el contrato, dond especifique la fecha de inicio fin del levantamiento de lo requisitos.

A

B

El cliente no participa en la presentación de los avances del prototipo

A

C

Mayor

Tiempo de respuesta, más lento de lo esperado a las preguntas para aclarar los requisitos

A

C

Mayor

Los componentes suministrados por el cliente no son adecuados para el funcionamiento del software

C

B

Mayor

E

B

Medio

El cliente no acepta el software entregado, incluso

Estipular en el contrato, dond del se da la cancelación d por mismo si no cumple co alguna de las clausulas Fijar fechas de respuesta pa Tener una reunión aclarar requisito Urgente con el Recordándole continuamen Sponsor la reunión pactada. Tener una reunión Urgente con el Sponsor y presentar Verificar bien los suministro la lista de adecuados, antes de iniciar componentes proyecto. necesarios para el trabajo Mostrar el contrato Los objetivos definidos debe donde se ve que se estar claros en el acta d Cancelación contrato incumplimiento.

73

UNIVERSIDAD ALAS PERUANAS – FILIAL AREQUIPA

PROBABILIDAD

aunque cumpla con todas sus especificaciones. El cliente piensa en una velocidad de desarrollo que el personal de desarrollo no puede alcanzar. REQUISITOS Los requisitos se han adaptado pero, continúan cambiando. Los requisitos no se han definido correctamente. Y su redefinición genera problemas.

RESPUESTAS AL RIESGO

ACTUAL

RIESGOS

B

A

C

IMPACTO

E

B

B

ACCIÓN A TOMAR

PRIORIDAD

Menor

ha cumplido todos los puntos Explicar el al cliente como es el desarrollo de una manera más clara

Extremo

Se replanteara el contrato si hay muchos cambios

Mayor

Asignar personal especialista y con gran experiencia en el levantamiento de requisitos

Se añade requisitos extras, a mitad de desarrollo.

B

B

Mayor

Requisitos diseñados no concuerdan con los deseados por el cliente.

C

B

Mayor

Si el requisito genera problemas con otros módulos. Entonces se pacta un nuevo contrato con un costo adicional o una posible cancelación del contrato. El diseño de software deberá ser analizado con el cliente

constitución

Aclarar bien las fechas d inicio y fin del proyecto.

Si los cambios so insignificantes, se hace u cobro adicional. Asignar personal especialis y con gran experiencia en levantamiento de requisito para evitar problemas má adelante

Si el requisito no gene problemas con otros módulo Entonces se pacta un nuev contrato con un cos adicional.

El diseño de software debe ser llevado de la mano con cliente.

74

14. PLAN DE GESTIÓN DE CAMBIOS

NOMBRE DEL PROYECTO PROTOTIPO DE UN SISTEMA DE MANEJO PARA UNA SILLA DE RUEDAS UTILIZANDO UN MODULO DE PROCESAMIENTO DE VOZ

SIGLAS DEL PROYECTO PSVOZ

ROLES DE LA GESTIÓN DE CAMBIOS: ROLES QUE SE NECESITAN PARA OPERAR LA GESTIÓN DE CAMBIOS NOMBRE PERSONA RESPONSABILIDADES NIVELES DE AUTORIDAD DEL ROL ASIGNADA Sponsor Gamarra  Dirimir en decisiones empatadas en el Total sobre el proyecto Peñalva Comité de Control de Cambios. Rely Comité de Gamarra  Decidir qué cambios se aprueban, Autorizar, rechazar, o diferir Control de Peñalva solicitudes de cambio. rechazan, o difieren. Cambios Rely Project Gamarra  Evaluar impactos de las Solicitudes de Hacer recomendaciones Manager Peñalva Cambio y hacer recomendaciones. sobre los cambios. Rely Aprobar Solicitudes de Cambio. Asistente de Gamarra  Captar las iniciativas de cambio de los Emitir solicitudes de cambio Gestión de Peñalva stakeholders y formalizarlas en Proyectos Rely solicitudes de cambio. Stakeholders Gamarra  Solicitar cambios cuando lo crea Solicitar cambios Peñalva conveniente y oportuno. Rely TIPOS DE CAMBIOS: DESCRIBIR LOS TIPOS DE CAMBIOS Y LAS DIFERENCIAS PARA TRATAR CADA UNO DE ELLOS. 1. ACCIÓN CORRECTIVA: Este tipo de cambio no pasa por el Proceso General de Gestión de Cambios, en su lugar el Project Manager tiene la autoridad para aprobarlo y coordinar su ejecución. 2. ACCIÓN PREVENTIVA: Este tipo de cambio no pasa por el Proceso General de Gestión de Cambios, en su lugar el Project Manager tiene la autoridad para aprobarlo y coordinar su ejecución. 3. REPARACION DE DEFECTO: Este tipo de cambio no pasa por el Proceso General de Gestión de Cambios, en su lugar el Inspector de Calidad tiene la autoridad para aprobarlo y coordinar su ejecución. 4. CAMBIO AL PLAN DE PROYECTO: Este tipo de cambio pasa obligatoriamente por el Proceso General de Gestión de Cambios, el cual se describe en la sección siguiente. PROCESO GENERAL DE GESTIÓN DE CAMBIOS: DESCRIBIR EN DETALLE LOS PROCESOS DE 75

LA GESTIÓN DECAMBIOS, ESPECIFICANDO QUÉ, QUIÉN, CÓMO, CUÁNDO Y DÓNDE. SOLICITUD DE CAMBIOS: Captar  El Asistente de Gestión de Proyectos se contacta con el las solicitudes y preparar el Stakeholder cada vez que capta una iniciativa de cambio. documento en forma adecuada y  Entrevista al Stakeholder y levanta información detallada sobre lo precisa. que desea.  Formaliza la iniciativa de cambio elaborando la Solicitud de Cambio respectiva  Presenta la Solicitud de Cambio al Project Manager. VERIFICAR SOLICITUD DE  El Project Manager analiza a profundidad la Solicitud de cambio CAMBIOS: con el fin de entender lo que se solicita y las razones por las Asegurar que se ha provisto toda la cuales se originó la iniciativa de cambio. información necesaria para hacer la  Verifica que en la Solicitud de Cambios aparezca toda la evaluación. información que se necesita para hacer una evaluación de impacto integral y exhaustivo.  Completa la Solicitud de Cambio si es necesario.  Registra la solicitud en el Log de Control de Solicitudes de Cambio. EVALUAR IMPACTOS: Evalúa los  El Project Manager evalúa los impactos integrales del cambio en impactos integrales de los cambios. todas las líneas base del proyecto, en las áreas de conocimiento subsidiarias, en otros proyectos y áreas de la empresa, y en entidades externas a la empresa.  Describe en la Solicitud de Cambio los resultados de los impactos que ha calculado.  Efectúa su recomendación con respecto a la Solicitud de Cambio que ha analizado.  Registra el estado de la solicitud en el Log de Control de Solicitudes de Cambio. TOMAR DECISIÓN Y  El Comité de Control de Cambios evalúa los impactos calculados REPLANIFICAR: Se toma la decisión por el Project Manager y toma una decisión sobre la Solicitud a la luz de los impactos, de Cambio: aprobarla, rechazarla, o diferirla, total o (dependiendo de los niveles de parcialmente. autoridad), se replanifica según sea  En caso de no poder llegar a un acuerdo el Sponsor tiene el voto necesario. dirimente.  Comunica su decisión al Project Manager, quién actualiza el estado de la solicitud en el Log de Control de Solicitudes de Cambio. IMPLANTAR EL CAMBIO: Se realiza  El Project Manager replanifica el proyecto para implantar el el cambio, se monitorea el progreso, cambio aprobado. y se reporta el estado del cambio.  Comunica los resultados de la replanificación a los stakeholders involucrados.  Coordina con el Equipo de Proyecto la ejecución de la nueva versión de Plan de Proyecto.  Actualiza el estado de la solicitud en el Log de Control de Solicitudes de Cambio.  Monitorea el progreso de las acciones de cambio.  Reporta al Comité de Control de Cambios el estado de las acciones y resultados de cambio.

76

CONCLUIR EL PROCESO DE  El Project Manager verifica que todo el proceso de cambio se CAMBIO: Asegura que todo el haya seguido correctamente. proceso haya sido seguido  Actualiza todos los documentos, registros, y archivos históricos correctamente, se actualizan los correspondientes. registros.  Genera las Lecciones Aprendidas que sean adecuadas.  Genera los Activos de Procesos de la Organización que sean convenientes.  Actualiza el estado de la solicitud en el Log de Control de Solicitudes de Cambio. PLAN DE CONTINGENCIA ANTE SOLICITUDES DE CAMBIO URGENTES: DESCRIBIR EL PLAN DECONTINGENCIA PARA ATENDER SOLICITUDES DE CAMBIO SUMAMENTE URGENTES QUE NO PUEDEN ESPERAR A QUE SE REÚNA ELCOMITÉ DE CONTROL DE CAMBIOS. El único autorizado para utilizar y ejecutar personalmente este Plan de Contingencia es el Project Manager: 1. 2. 3. 4. 5. 6. 7. 8.

Registrar la Solicitud de Cambio: Project Manager registra personalmente la solicitud. Verificar la Solicitud de Cambio: Project Manager verifica la solicitud. Evaluar Impactos: Project Manager evalúa impactos. Tomar Decisión: Project Manager toma la decisión consultando telefónicamente al Sponsor, o en su defecto consultando a por lo menos dos miembros del Comité de Control de Cambios. Implantar el Cambio: Project Manager implanta el cambio. Formalizar el Cambio: Project Manager convoca al Comité de Control de Cambios y sustenta la necesidad de haber utilizado este procedimiento de urgencia. Comité de Control de Cambios formaliza la aprobación o reconsidera la decisión del Project Manager. Ejecutar Decisión del Comité: Project Manager ejecuta decisión del Comité. Concluir el Cambio: Project Manager concluye el proceso de cambio.

77

15. PLAN DE GESTIÓN DE LA CONFIGURACIÓN NOMBRE DEL PROYECTO PROTOTIPO DE UN SISTEMA DE MANEJO PARA UNA SILLA DE RUEDAS UTILIZANDO UN MODULO DE PROCESAMIENTO DE VOZ

ROLES DE LA GESTIÓN DE CAMBIOS: NOMBRE DEL ROL PERSONA ASIGNADA Project Manager Gamarra Peñalva Rely Gestor de Gamarra Peñalva Rely Configuración Inspector de Gamarra Peñalva Rely Aseguramiento de Calidad Miembros del Equipo Gamarra Peñalva Rely de Proyecto

SIGLAS DEL PROYECTO PSVOZ

RESPONSABILIDADES Supervisar el funcionamiento dela Gestión de la Configuración. Ejecutar todas las tareas de Gestión de la Configuración. Auditar la Gestión de la Configuración.

NIVELES DE AUTORIDAD Toda autoridad sobre el proyecto y sus funciones. Autoridad para operar las funciones de Gestión de la Configuración. Auditar la Gestión de la configuración según indique el Project Manager.

Consultar la información de Gestión de la Configuración según sus niveles de autoridad.

Depende de cada miembro, se especifica para cada artefacto y cada CI (Item de Configuración).

PLAN DE DOCUMENTACIÓN: DOCUMENTOS Ó ARTEFACTOS

FORMATO (E=ELECTRÓNICO H=HARD

ACCESORÁPID O NECESARIO

Project Charter

E

Disponible line

Plan deProyecto

E

Disponible line

DISPONIBILIDAD AMPLIA NECESARIA

SEGURIDAD DE ACCESO

on-

A todos Stakeholders

los

on-

A todos Stakeholders

los

Lectura general Modificación Restringida Lectura general Modificación Restringida

RECUPERACIÓN DE INFORMACIÓN

Backup primario almacenamiento secundario Backup primario almacenamiento secundario

RETENCIÓN DE INFORMACIÓN

y

Durante todo el proyecto

y

Durante todo el proyecto

78

DOCUMENTOS Ó ARTEFACTOS

FORMATO (E=ELECTRÓNICO H=HARD

ACCESORÁPID O NECESARIO

DISPONIBILIDAD AMPLIA NECESARIA

SEGURIDAD DE ACCESO

Informe de Perfomance del proyecto Solicitud de Cambio

E

Disponible line

on-

A todos Stakeholders

los

Disponible line

on-

A todos Stakeholders

los

Log de Control E Disponible de Solicitudes line deCambio Informe de E Disponible Cierre de line Proyecto ITEMS DE CONFIGURACIÓN (CI): CÓDIGO DEL ITEM NOMBRE DEL ITEM DE DE CONFIGURACIÓN CONFIGURACIÓN

on-

A todos Stakeholders

los

on-

A todos Stakeholders

los

Lectura general Modificación Restringida Lectura general Modificación Restringida Lectura general Modificación Restringida Lectura general Modificación restringida

E

RECUPERACIÓN DE INFORMACIÓN

Backup primario almacenamiento secundario Backup primario almacenamiento secundario Backup primario almacenamiento secundario Backup primario almacenamiento secundario

CATEGORÍA FUENTE FORMATO 1=FÍSICO P=PROYECTO (SOFTWARE + 2=DOCUMENTO C=CONTRATISTA VERSIÓN + 3=FORMATO V=PROVEEDOR PLATAFORMA) 4=REGISTRO E=EMPRESA 1 Contrato de los servicios 1 V Original Impreso 2 Materiales 2 P Original Impreso 3 Informe de las sesiones 3 P PDF 4 Informe mensual 2 P PDF 5 Informe final 2 P PDF CONTABILIDAD DE ESTADO Y MÉTRICAS DE CONFIGURACIÓN:  El Repositorio de Información de los documentos del proyecto será una carpeta con la estructura del WBS para la organización interna de sus sub-carpetas. 

El Repositorio de Información para los CI’s (Configuration Items) será el Diccionario WBS que residirá en la carpeta antes mencionada.



En cualquier momento se podrá mostrar una cabecera con la historia de versiones de los

RETENCIÓN DE INFORMACIÓN

y

Durante todo el proyecto

y

Durante todo el proyecto

y

Durante todo el proyecto

y

Durante todo el proyecto OBSERVACIONES

Firmado Firmado Firmado Firmado y aprobado Firmado y aprobado

79

documentos y artefactos del proyecto, así como se podrá consultar todas las versiones de los CI’s. 

No se llevarán métricas del movimiento y la historia de los documentos, artefactos, y CI’s para este proyecto.

VERIFICACIÓN Y AUDITORÍAS DE CONFIGURACIÓN: Las verificaciones y auditorías de la integridad de la configuración serán rutinarias y bisemanales, realizadas por el Inspector de Aseguramiento de Calidad y donde se comprobará: 

Integridad de la información de los CI’s.



Exactitud y reproducibilidad de la historia de los CI’s.

80

16. PLAN DE GESTIÓN DE COMUNICACIONES NOMBRE DEL PROYECTO PROTOTIPO DE UN SISTEMA DE MANEJO PARA UNA SILLA DE RUEDAS UTILIZANDO UN MODULO DE PROCESAMIENTO DE VOZ

SIGLAS DEL PROYECTO PSVOZ

COMUNICACIONES DEL PROYECTO: JEFE DE PROYECTOS

INGENIERO DE SISTEMAS

ANALISTA

INGENIERO ELECTRONICO

PROCEDIMIENTO PARA TRATAR POLÉMICAS: 1. Se captan las polémicas a través de la observación y conversación, o de alguna persona o grupo que los exprese formalmente. 2. Se codifican y registran las polémicas en el Log de Control de Polémicas: LOG DE CONTROL DE POLEMICAS CODIGO DE

DESCRIPC ION

INVOLUCRA DOS

ENFOQ UE DE

ACCION ES DE

RESPONSA BLE

FEC HA

RESULTA DO

81

POLÉMI CA

SOLUCI ÓN

SOLUCI ÓN

OBTENID O

3. Se revisa el Log de Control de Polémicas en la reunión semanal de coordinación con el fin de: a) Determinar las soluciones a aplicar a las polémicas pendientes por analizar, designar un responsable por su solución, un plazo de solución, y registrar la programación de estas soluciones en el Log de Control. b) Revisar si las soluciones programadas se están aplicando, de no ser así se tomarán acciones correctivas al respecto. c) Revisar si las soluciones aplicadas han sido efectivas y si la polémica ha sido resuelta, de no ser así se diseñarán nuevas soluciones (continuar en el paso ‘a’). 4. En caso que una polémica no pueda ser resuelta o en caso que haya evolucionado hasta convertirse en un problema, deberá ser abordada con el siguiente método de escalamiento: a) En primera instancia será tratada de resolver por el Project Manager y el Equipo de Gestión de Proyecto, utilizando el método estándar de resolución de problemas. b) En segunda instancia será tratada de resolver por el Project Manager, el Equipo de Gestión de Proyecto, y los miembros pertinentes del Equipo de Proyecto, utilizando el método estándar de resolución de problemas. c) En tercera instancia será tratada de resolver por el Sponsor, el Project Manager, y los miembros pertinentes del proyecto, utilizando la negociación y/o la solución de conflictos. d) En última instancia será resuelta por el Sponsor o por el Sponsor y el Comité de Control de Cambios si el primero lo cree conveniente y necesario. PROCEDIMIENTO PARA ACTUALIZAR EL PLAN DE GESTIÓN DE COMUNICACIONES:

82

El Plan de Gestión de las Comunicaciones deberá ser revisado y/o actualizado cada vez que: 1. Hay una solicitud de cambio aprobada que impacte el Plan de Proyecto. 2. Hay una acción correctiva que impacte los requerimientos o necesidades de información de los stakeholders. 3. Hay personas que ingresan o salen del proyecto. 4. Hay cambios en las asignaciones de personas a roles del proyecto. 5. Hay cambios en la matriz autoridad versus influencia de los stakeholders. 6. Hay solicitudes inusuales de informes o reportes adicionales. 7. Hay quejas, sugerencias, comentarios o evidencias de requerimientos de información no satisfechos. 8. Hay evidencias de resistencia al cambio. 9. Hay evidencias de deficiencias de comunicación dentro del proyecto y fuera del mismo. La actualización del Plan de Gestión de las Comunicaciones deberá seguir los siguientes pasos: 1. Identificación y clasificación de stakeholders. 2. Determinación de requerimientos de información. 3. Elaboración de la Matriz de Comunicaciones del Proyecto. 4. Actualización del Plan de Gestión de las Comunicaciones. 5. Aprobación del Plan de Gestión de las Comunicaciones. 6. Difusión del nuevo Plan de Gestión de las Comunicaciones. GUÍAS PARA EVENTOS DE COMUNICACIÓN: Guías para Reuniones .- Todas las reuniones deberán seguir las siguientes pautas: 1. 2. 3. 4.

Debe fijarse la agenda con anterioridad. Debe coordinarse e informarse fecha, hora, y lugar con los participantes. Se debe empezar puntual. Se deben fijar los objetivos de la reunión, los roles (por lo menos el facilitador y el anotador), los procesos grupales de trabajo, y los métodos de solución de controversias.

83

5. Se debe cumplir a cabalidad los roles de facilitador (dirige el proceso grupal de trabajo) y de anotador (toma nota de los resultados formales de la reunión). 6. Se debe terminar puntual. 7. Se debe emitir un Acta de Reunión (ver formato adjunto), la cual se debe repartir a los participantes (previa revisión por parte de ellos). Guías para Correo Electrónico.- Todos los correos electrónicos deberán seguir las siguientes pautas: 1. Los correos electrónicos entre el Equipo de Proyecto y el Cliente deberán ser enviados por el Project Manager con copia al Sponsor, para establecer una sola vía formal de comunicación con el Cliente. 2. Los enviados por el Cliente y recibidos por cualquier persona del Equipo de Proyecto deberán ser copiados al Project Manager y el Sponsor (si es que éstos no han sido considerados en el reparto), para que todas las comunicaciones con el Cliente estén en conocimiento de los responsables de la parte contractual. 3. Los correos internos entre miembros del Equipo de Proyecto, deberán ser copiados a la lista Equipo Proyecto que contiene las direcciones de los miembros, para que todos estén permanentemente informados de lo que sucede en el proyecto. GUÍAS PARA DOCUMENTACIÓN DEL PROYECTO: Guías para Codificación de Documentos.- La codificación de los documentos del proyecto será la siguiente: AAAA_BBB_CCC.DDD Donde:  AAAA = Código del Proyecto= ‘PROD’  BBB = Abreviatura del Tipo de Documento= pch, sst, wbs, dwbs, org, ram, etc.  CCC = Versión del Documento=’v1_0’, ‘v2_0’, etc.  DDD = Formato del Archivo=doc, exe, pdf, mpp, etc. Guías para Almacenamiento de Documentos.- El almacenamiento de los documentos del proyecto deberá seguir las siguientes pautas: 1. Durante la ejecución del proyecto cada miembro del equipo mantendrá en su máquina una carpeta con la misma estructura que el WBS del proyecto, donde guardará en las sub-carpetas correspondientes las versiones de los documentos que vaya generando. 2. Al cierre de una fase o al cierre del proyecto cada miembro del equipo deberá eliminar los archivos

84

temporales de trabajo de los documentos y se quedará con las versiones controladas y numeradas (ver guías para el control de versiones), las cuales se enviarán al Project Manager. 3. El Project Manager consolidará todas las versiones controladas y numeradas de los documentos, en un archivo final del proyecto, el cual será una carpeta con la misma estructura del WBS, donde se almacenarán en el lugar correspondiente los documentos finales del proyecto. Esta carpeta se archivará en la Biblioteca de Proyectos, y se guardará protegida contra escritura. 4. Se publicará una Relación de Documentos del Proyecto y la ruta de acceso para consulta. 5. Los miembros de equipo borrarán sus carpetas de trabajo para eliminar redundancias de información y multiplicidad de versiones. Guías para Recuperación y Reparto de Documentos.1. La recuperación de documentos a partir de la Biblioteca de Proyectos es libre para todos los integrantes del Equipo de Proyecto. 2. La recuperación de documentos a partir de la Biblioteca de Proyectos para otros miembros que no sean del Proyecto requiere autorización del Project Manager. 3. El acceso a la información del proyecto por parte de personas que no son del equipo de proyecto requiere autorización, pues esta información se considera confidencial. 4. El reparto de documentos digitales e impresos es responsabilidad del Project Manager. 5. El reparto de documentos impresos no contempla el control de copias numeradas.

85

GUÍAS PARA EL CONTROL DE VERSIONES: 1. Todos los documentos de Gestión de Proyectos están sujetos al control de versiones, el cual se hace insertando una cabecera estándar con el siguiente diseño: CONTROL DE VERSIONES Codigo de versión

Hecha por

Revisada por

Aprobada por

Fecha

Motivo

2. Cada vez que se emite una versión del documento se llena una fila en la cabecera, anotando la versión, quien emitió el documento, quién lo revisó, quién lo aprobó, a que fecha corresponde la versión, y por qué motivo se emitió dicha versión. 3. Debe haber correspondencia entre el código de versión del documento que figura en esta cabecera de Control de Versiones y el código de versión del documento que figura en el nombre del archivo (ver Guía para Codificación de Documentos), según: AAAA_BBB_CCC.DDD Donde:  AAAA= Código del Proyecto= ‘PROD’  BBB= Abreviatura del Tipo de Documento= pch, sst, wbs, dwbs,org,ram,etc.  CCC= Versión del Documento=’v1_0’, ‘v2_0’, etc.  DDD= Formato del Archivo=doc, exe, pdf,mpp,etc.

86

17. MÉTRICAS DE CALIDAD DEL PRODUCTO

CÓDIG O

R01

REQUISITOS DE CALIDAD

Funcionalidad

R02

Fiabilidad

R03

Usabilidad

R04

Eficiencia

CRITERIOS DE ACEPTACIÓN

MÉTRICAS A UTILIZAR

FRECUENC IA DE MEDICIÓN

RESPONSABLE



El sistema deberá cumplir con los requisitos funcionales y no funcionales de software.



El sistema no deberá sobrepasar el costo planificado. Y aceptado por sus responsables.



El sistema no deberá sobrepasar el tiempo planificado y aceptado por sus responsables.



El software deberá mantener un nivel aceptable de un 99% de rendimiento.

Modularidad

99%

Gamarra Peñalva Rely



El software deberá ser aceptado por el usuario, por su fácil uso y manejabilidad, presumiendo así de ser atractivo para el usuario.

Modularidad

95%

Gamarra Peñalva Rely

Pruebas

98%

Gamarra Peñalva Rely



El software deberá ofrecer tiempo de respuesta aceptable, es decir que el usuario se sienta

87

satisfecho en la velocidad de respuesta.

R04

Mantenibilidad

R05

Portabilidad



El software deberá estar pensado a futuro. Siendo capaz de soportar modificaciones y mejoras.

Mantenimiento

97%

Gamarra Peñalva Rely



El software deberá ser fácilmente transportado a otros entornos de ejecución.

Pruebas

99%

. Gamarra Peñalva Rely

88

18. LÍNEA BASE DE LA CALIDAD NOMBRE DEL PROYECTO PROTOTIPO DE UN SISTEMA DE MANEJO PARA UNA SILLA DE RUEDAS UTILIZANDO UN MODULO DE PROCESAMIENTO DE VOZ

SIGLAS DEL PROYECTO PSVOZ

LINEA BASE DE CALIDAD

FACTOR DE CALIDAD RELEVANTE Performance Proyecto

Performance Proyecto

del

del

Satisfacción de la inmobiliaria

OBJETIVO DE CALIDAD

CPI>= 0.95

SPI >= 0.95

NCR (No conformidad)=0

MÉTRICA A USAR

CPI= Cost Perfomance Index Acumulado SPI= Schedule Perfomance Index Acumulado Seguimiento al dossier de calidad

FRECUENCIA Y MOMENTO DE MEDICIÓN Frecuencia, semanal

FRECUENCIA Y MOMENTO DE REPORTE Frecuencia Semanal

Medición, lunes en la mañana Frecuencia, semanal

Reporte, lunes en la tarde Frecuencia semanal

Medición, lunes en la mañana Frecuencia, en cada reporte semanal

Reporte, lunes en la tarde Frecuencia, una vez por semana

Medición, al día siguiente de la entrega del reporte semanal

Reporte, al día siguiente de la medición

89

19. PLAN DE GETSION DE ADQUISICIONES NOMBRE DEL PROYECTO PROTOTIPO DE UN SISTEMA DE MANEJO PARA UNA SILLA DE RUEDAS UTILIZANDO UN MODULO DE PROCESAMIENTO DE VOZ

SIGLAS DEL PROYECTO PSVOZ

RECURSOS TÉCNICOS Hardware con sus respectivas características: CANTIDAD

PRODUCTO

1

Laptop

1

Impresora

HARDWARE

CANTIDAD LICENCIA 1 SOFTWARE

1 1 1

        

CARACTERÍSTICAS 01 laptop 4GB Memoria RAM 500GB disco duro Procesador core 2 Duo. Impresión, copia, escaneado. Modelo D1000 jet Tinta negro y colores Compatibilidad Windows 7 y XP. hojas A4, A5, A6 DESCRIPCIÓN Microsoft office Home and student SQL server estándar2005 express Visual Studio C# 2010 Star UML.

Recursos de comunicaciones :Contrato de Servicio de internet y teléfono, durante el periodo de 4 meses. Suministro Eléctrico: Contrato de suministro eléctrico por el periodo de 4 meses. Suministro Eléctrico :Contrato de suministro eléctrico por el periodo de 4 meses. Recurso Hídrico: Contrato de recurso hídrico por el periodo 4 meses. Servicio de movilidad: Se considera a la movilidad de transporte. Servicio de movilidad :Se considera a la movilidad de transporte. Suministro de escritorio: Compra de útiles de escritorio

90

RECURSOS PARA LA ADQUISICION El director del proyecto estará encargado de las adquisiciones para obtener los recursos de hardware y software. Entre las acciones que se deberán tomar es ponerse en contacto directo con los proveedores para incorporar un precio base (incluido en el presupuesto) y contrastar las características técnicas del producto solicitado. Una vez que se haya seleccionado al proveedor que cumpla con los requisitos, se procede a hacer el seguimiento de los tiempos de entrega con el proveedor. Luego de ello se procederá el siguiente paso que es el ingreso de la mercadería y su respectiva revisión y evaluación desde el punto de vista técnico. En cuanto a la adquisición de los siguientes recursos, también estará a cargo del director del proyecto.     

Recursos de comunicaciones (Internet y teléfono) Suministro Eléctrico (Luz) Suministro Hídrico (Agua) Servicio de movilidad (pasajes) Suministros de escritorio(Útiles de escritorio)

Estas adquisiciones serán respaldadas a través de la firma de un contrato. En la que incluirán cláusulas de cumplimiento y penalidades en el caso de no cumplimiento. TIPOS DE CONTRATO A SER USADOS  El contrato de los recursos técnicos y suministros de escritorio serán precios fijos. Que serán pagados de forma efectiva, una vez que se haya realizado la adquisición. 

En el caso de los recursos de suministro eléctrico e hídrico serán precios variados, ya que el pago será según el consumo mensual realizado.

El recurso de comunicaciones y el servicio de movilidad serán precios fijos mensuales, ya que en el momento del contrato se fijan los montos a pagar ENUNCIADO DEL RECURSO A CONTRATAR

91

IDENTIFICADOR DE ENTREGABLE Nombre del entregable Alcance

DESCRIPCIÓN Adquisición de recursos técnicos

del Hardware y software para el desarrollo del proyecto.

entregable Duración

2 días

estimada Fecha de término

30/03/2013 El proveedor con mejor propuesta será el encargado de proporcionar el hardware y software. Se validará los siguientes factores:

Criterio

de

aceptación



Calidad



Precio



Tiempo de entrega



Garantía que ofrece.

IDENTIFICADOR DE ENTREGABLE Nombre del entregable Alcance

DESCRIPCIÓN Adquisición de suministros de escritorio

del Suministros de escritorios que se van a utilizar durante el periodo

entregable Duración

de desarrollo. 2 días

estimada Fecha de término

30/03/2013 El proveedor con mejores propuestas será el encargado de proporcionar el suministros de escritorio

Criterio

de

Se validará los siguientes factores:  Precio

aceptación

 Calidad que ofrece  Tiempo de entrega IDENTIFICADOR DE ENTREGABLE Nombre del entregable Alcance entregable

DESCRIPCIÓN Adquisición de recursos de comunicación, suministro eléctrico,

suministro hídrico. del Estos Suministros serán utilizados

durante el periodo de

desarrollo. 92

Duración

2 días

estimada Fecha de término

30/03/2013 Servicio que ofrecerá:  Precio

Criterio

de

 Calidad

aceptación

 Tiempo de entrega  Garantía

IDENTIFICADOR DE ENTREGABLE Nombre del entregable Alcance

del sistema. Todos los días que se va a trabajar

estimada Fecha de término

aceptación

Servicio de Movilidad

del Este servicio será utilizado por el periodo que dura el desarrollo

entregable Duración

Criterio

DESCRIPCIÓN

de

28/06/2013 El proveedor con mejores propuestas será el encargado de proporcionar el servicio. Se validara los siguientes factores: 

Precio



Calidad

93

20. CIERRE DE PROYECTO NOMBRE DEL PROYECTO PROTOTIPO DE UN SISTEMA DE MANEJO PARA UNA SILLA DE RUEDAS UTILIZANDO UN MODULO DE PROCESAMIENTO DE VOZ

SIGLAS DEL PROYECTO PSVOZ

SE HAN ACEPTADO LOS RESULTADOS DEL PROYECTO OBJETIVOS

ENTREGABLES

1. Obtener aceptación final

2. Satisfacer todos requerimientos contractuales

los

Aprobación documentada de los resultados del proyecto Documentación de entregables terminados y no terminados. Aceptación documentada de que los términos del contrato han sido satisfechos.

3. Trasladar todos los Aceptación documentada entregables a por parte de operaciones. operaciones. ¿SE HAN LIBERADO LOS RECURSOS DEL PROYECTO? OBJETIVOS

ENTREGABLES

1. Ejecutar los Procedimientos Cronogramas de liberación Organizacionales para De recursos, Ejecutados Liberar los recursos del proyecto. Resultados de la 2. Proporcionar Retroalimentación de la retroalimentación de Performance del equipo de performance a los Proyecto, archivados en los Miembros del equipo. Files personales. 3. Proporcionar Evaluaciones de retroalimentación a la performance Revisadas con Organización relativa a los gerentes Funcionales y La performance de los archivadas Miembros del equipo. Apropiadamente.

REALIZADO A SATISFACCION (S/N)

OBSERVACIONES

SI

Ninguna

SI

Ninguna

SI

Ninguna

REALIZADO A SATISFACCION (S/N)

OBSERVACIONES

SI

Ninguna

No

No se ha generado

SI

Ninguna

94

¿SE HAN MEDIDO Y ANALIZADO LAS PERCEPCIONES DE LOS STAKEHOLDERS DEL PROYECTO? OBJETIVOS

ENTREGABLES

REALIZADO A SATISFACCION (S/N)

1. Entrevistar a los Stakeholders del proyecto.

Representación de los Stakeholders, documentada.

SI

2. Analizar los resultados de Análisis documentado Si la Retroalimentación. ¿SE HA CERRADO FORMALMENTE EL PROYECTO?

OBSERVA-CIONES

Ninguna Ninguna

OBJETIVOS

ENTREGABLES

REALIZADO A SATISFACCION (S/N)

1. Ejecutar las actividades de Cierre para el Proyecto.

Reconocimiento firmado de la entrega de los productos y servicios del proyecto. Documentación de las actividades de cierre.

SI

Ninguna

2. Informar a gerencia sobre todos los problemas importantes.

Documentación de los Problemas importantes.

Si

En conocimiento Gerencia

Si

Actividad Conforme.

Si

Stakeholders tomaron conocimiento

3. cerrar todas las actividades financieras asociadas con el proyecto. 4. Notificar formalmente a los Stakeholders del cierre del proyecto. 5. cerrar todos los contratos del proyecto. 6. documentar y publicar el aprendizaje del proyecto. 7. actualizar los activos de los procesos de la organización.

Retroalimentación documentada del departamento Financiero sobre el cierre del Proyecto. Documento que comunica el cierre del proyecto, almacenado en el file del proyecto. Contratos cerrados apropiadamente. Documentación de lecciones aprendidas. Documentación del proyecto, archivada. Cambios/actualizaciones delos activos de los procesos de la organización, documentados.

Si Si

Si

OBSERVA-CIONES

Confirmaron aceptación. Ninguna observación

Ninguna observación

95

ANEXOS

96

GRAFICA 17 DISEÑO DEL CIRCUITO ELECTRONICO CON LOS COMPONENTES CORRESPONDIENTES

FUENTE: ELABORACION PROPIA

97

GRAFICA 18 DISEÑO DE LAS PISTAS DEL CIRCUITO ELECTRONICO

FUENTE: ELABORACION PROPIA

98

GRAFICA 19 DIAGRAMA DE CASO DE USO

System

Definir Comandos de Voz

Administrador

Usuario Controlar Silla de Ruedas

FUENTE: ELABORACION PROPIA

GRAFICA 20 DIAGRAMA DE CLASES

Sistema -ComandoAvanzar -ComandoRetroceder -ComandoDerecha -ComandoIzquierda -ComandoDetener Usuario -TipoUsuario +ActivarSistema() +Hablar()

+ReconocerVoz() +EjecutarComando() +DefinirComando()

Silla de Ruedas +ConectarSilla() +Avanzar() +Retroceder() +Derecha() +Izquierda() +Detener() +RealizarMovimiento(Comando)

FUENTE: ELABORACION PROPIA

99

GRAFICA 21 DIAGRAMA DE SECUENCIA CONTROL DE LA SILLA

: Silla de Ruedas

: Sistema

: Usuario

2 : EjecutarComando() 1 : ReconocerVoz()

3 : ConectarSilla() 4 : Conexion

5 : RealizarMovimiento()

FUENTE: ELABORACION PROPIA

100

GRAFICA 22 DIAGRAMA DE SECUENCIA DEFINIR COMANDOS

: Sistema : Administrador

1 : DefinirComando() 2 : ReconocerVoz()

FUENTE: ELABORACION PROPIA

101

CODIGO 1 CÓDIGO DEL PIC #include //llamo a la libreria del pic #fuses XT, NOWDT, NOPROTECT, BROWNOUT, NOPUT //ordenes para el programador #device ADC = 8 //declaro la cantidad de bits para la resolucion #use delay(clock=4000000) //el reloj que voy a usar #use rs232(baud=9600, xmit=PIN_C6, rcv=PIN_C7,BITS=8,STOP=2) #use standard_io(B) //inicializo los puertos #use standard_io(A) #include //libreria manejo lcd //**************************************************************************** #define BIT_TEST_ON output_high(PIN_C1) #define BIT_TEST_OFF output_low(PIN_C1) //VARIABLES char codigo; //variable en la que recojere lo que entre por el puerto serial float V1; //para el valor analogico del puerto AN0 int conectar=0; //bandera para el sentido del radar char val; //variable para la lectura de sensores

//**********************FUNCIONES DEL ROBOT************************************* void motor_adelante(); //funcion para avanzar void motor_atraz(); //funcion para retroceder void motor_derecha(); //funcion para que gire a la derecha void motor_izquierda(); //funcion para que gire a la izquierda void freno(); //funcion para que se detengan los dos motores void freno_cambio(); //funcion para que cambio de sentido void Leer_Timon(); #INT_rda void serie() { codigo = getc (); //leo lo que entre por el puerto serial if(codigo!='G' && codigo!='H'&& codigo!='g' && codigo!='h') { printf ("%c", codigo); }

102

SWITCH (codigo) { //Byte para movimiento hacia adelante CASE 'A' : motor_adelante (); //delay_ms (10); BREAK; //Byte para movimiento hacia atraz CASE 'B' : motor_atraz (); //delay_ms (10); BREAK; //Byte para detener el robot CASE 'C' : motor_derecha (); //delay_ms (10); BREAK; CASE 'D' : motor_izquierda (); BREAK; CASE 'E' : Leer_Timon (); //Mover_Timon (Leer_Timon ()); BREAK; CASE 'Q': freno (); delay_ms (10); BREAK; CASE 'W': printf (lcd_putc, "\nConectado "); conectar = 1; BREAK; CASE 'Y': printf (lcd_putc, "\nActivado "); freno(); BREAK; CASE 'X': printf (lcd_putc, "\nDesconectado "); freno(); conectar = 0; BREAK; } } 103

void main() //funcion principal { enable_interrupts (INT_rda); enable_interrupts (GLOBAL); lcd_init (); //inicializa lcd printf (lcd_putc, "RELY"); //imprime en el LCD delay_ms (1000); WHILE (true) //bucle infinito de trabajo { if(conectar==0) printf ("W"); delay_ms (100); } } void freno() { printf (lcd_putc, "\n DETENIDO "); //imprime en el LCD output_low (PIN_C0); output_low (PIN_C1); output_low (PIN_C2); output_low (PIN_C3); delay_ms (20); } void freno_cambio() { printf (lcd_putc, "\n DETENIDO "); //imprime en el LCD output_low (PIN_C0); output_low (PIN_C1); output_low (PIN_C2); output_low (PIN_C3); delay_ms (20); } void motor_adelante() { freno_cambio (); printf (lcd_putc, "\n AVANZA ") ; //imprime en el LCD output_high (PIN_C0); output_low (PIN_C1); output_high (PIN_C2); output_low (PIN_C3); } void motor_atraz() 104

{ freno_cambio (); printf (lcd_putc, "\n RETROCEDE ") ; //imprime en el LCD output_low (PIN_C0); output_high (PIN_C1); output_low (PIN_C2); output_high (PIN_C3); } void motor_derecha() { printf (lcd_putc, "\n DERECHA "); //imprime en el LCD output_high (PIN_C0); output_low (PIN_C1); output_low (PIN_C2); output_high (PIN_C3); } void motor_izquierda() { printf (lcd_putc, "\n IZQUIERDA ") ; //imprime en el LCD output_low (PIN_C0); output_high (PIN_C1); output_high (PIN_C2); output_low (PIN_C3); } void Leer_Timon() //funcion para leer el puerto AN0 { setup_port_a (ALL_ANALOG); //inicializo todos los puertos analogicos setup_adc (ADC_CLOCK_INTERNAL); //el periodo de muestreo set_adc_channel (0); //escojo el puerto AN0 delay_ms (20); V1 = read_adc (); //paso el valor del puerto AN0 a V1 delay_ms (20); //tiempo de espera setup_adc (adc_off); //apago todos los puertos analogicos IF(V1115 && V1=140) { printf ("s"); } }

105

CODIGO 2 SCRIPT DE LA BASE DE DATOS USE [DB_Rely] GO /****** Object: Table [dbo].[tbl_Comandos] Script Date: 11/14/2013 12:49:28 ******/ SET ANSI_NULLS ON GO SET QUOTED_IDENTIFIER ON GO SET ANSI_PADDING ON GO CREATE TABLE [dbo].[tbl_Comandos]( [id_comandos] [int] IDENTITY(1,1) NOT NULL, [avanzar] [varchar](50) NULL, [retroceder] [varchar](50) NULL, [girar_derecha] [varchar](50) NULL, [girar_izquierda] [varchar](50) NULL, [parar] [varchar](50) NULL, CONSTRAINT [PK_tbl_Comandos] PRIMARY KEY CLUSTERED ( [id_comandos] ASC )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY] ) ON [PRIMARY] GO SET ANSI_PADDING OFF GO SET IDENTITY_INSERT [dbo].[tbl_Comandos] ON INSERT [dbo].[tbl_Comandos] ([id_comandos], [avanzar], [retroceder], [girar_derecha], [girar_izquierda], [parar]) VALUES (1, N'perro', N'gato', N'toro', N'vaca', N'parar') SET IDENTITY_INSERT [dbo].[tbl_Comandos] OFF

106

GRAFICA 23 FORMULARIO PRINCIPAL

FUENTE: ELABORACION PROPIA

GRAFICA 24 FORMULARIO PRINCIPAL MOSTRANDO EL MENU COMANDOS

FUENTE: ELABORACION PROPIA 107

GRAFICA 25 FORMULARIO PRINCIPAL MOSTRANDO EL MENU CONTROL

FUENTE: ELABORACION PROPIA

108

CODIGO 3 PRINCIPAL.CS using System; using System.Collections.Generic; using System.ComponentModel; using System.Data; using System.Drawing; using System.Linq; using System.Text; using System.Windows.Forms; namespace ProyectoRely { public partial class Principal : Form { public Principal() { InitializeComponent(); } private void Principal_Load(object sender, EventArgs e) { } private void comandosToolStripMenuItem1_Click(object sender, EventArgs e) { frmComandos objcomandos = new frmComandos(); objcomandos.MdiParent = this; objcomandos.Show(); } private void controlToolStripMenuItem1_Click(object sender, EventArgs e) { frmControl objcontrol = new frmControl(); objcontrol.MdiParent = this; objcontrol.Show(); } } }

109

GRAFICA 26 FORMULARIO DE COMANDOS

FUENTE: ELABORACION PROPIA

110

CODIGO 4 COMANDOS.CS using System; using System.Collections.Generic; using System.ComponentModel; using System.Data; using System.Drawing; using System.Linq; using System.Text; using System.Windows.Forms; using ProyectoRely.DAL; using System.Threading; using SpeechLib; using System.Speech.Recognition; using System.Speech.Synthesis; using System.Speech.AudioFormat; namespace ProyectoRely { public partial class frmComandos : Form { dsRely.tbl_ComandosDataTable ComandosDT = new dsRely.tbl_ComandosDataTable(); DAL.dsRelyTableAdapters.tbl_ComandosTableAdapter ComandosTA = new DAL.dsRelyTableAdapters.tbl_ComandosTableAdapter(); private SpeechSynthesizer synthesizer = null; private string selectedVoice = string.Empty; private SpeechRecognitionEngine recognizer = null; private DictationGrammar dictationGrammar = null; static SpeechRecognitionEngine speechReconocedor = null; static ManualResetEvent manualResetEvent = null; string avanzar = ""; string retroceder = ""; string derecha = ""; string izquierda = ""; string parar = ""; public frmComandos() { InitializeComponent(); } private void frmComandos_Load(object sender, EventArgs e) { ComandosDT = ComandosTA.GetData(); foreach (var item in ComandosDT) { 111

avanzar = item.avanzar; retroceder = item.retroceder; derecha = item.girar_derecha; izquierda = item.girar_izquierda; parar = item.parar; } txtAvanzar.Text = avanzar; txtRetroceder.Text = retroceder; txtDerecha.Text = derecha; txtIzquierda.Text = izquierda; txtParar.Text = parar; synthesizer = new SpeechSynthesizer(); recognizer = new SpeechRecognitionEngine(); dictationGrammar = new DictationGrammar(); InitializeSpeechRecognitionEngine(); } private void InitializeSpeechRecognitionEngine() { recognizer.SetInputToDefaultAudioDevice(); Grammar customGrammar = CreateCustomGrammar(); recognizer.UnloadAllGrammars(); recognizer.LoadGrammar(customGrammar); recognizer.RecognizeAsync(RecognizeMode.Multiple); recognizer.SpeechHypothesized += new EventHandler(recognizer_SpeechHypothesized); } private Grammar CreateCustomGrammar() { GrammarBuilder grammarBuilder = new GrammarBuilder(); grammarBuilder.Append(new Choices("configuracion", "avanzar", "retroceder", "derecha", "izquierda", "parar", avanzar, retroceder, derecha, izquierda, parar)); return new Grammar(grammarBuilder); } private void recognizer_SpeechHypothesized(object sender, SpeechHypothesizedEventArgs e) { if (e.Result.Text == "salir") { } } private void tbnAceptar_Click(object sender, EventArgs e) { try {

112

ComandosTA.UpdateQueryComandos(txtAvanzar.Text, txtRetroceder.Text, txtDerecha.Text, txtIzquierda.Text, txtParar.Text); MessageBox.Show("Los comandos fueron insertados correctamente","Mensaje",MessageBoxButtons.OK,MessageBoxIcon.Asterisk); } catch (Exception) { MessageBox.Show("Ocurrio un error al insertar los comandos", "Mensaje"); } } private void btnCancelar_Click(object sender, EventArgs e) { this.Close(); } } }

113

GRAFICA 27 FORMULARIO DE CONTROL

FUENTE: ELABORACION PROPIA

114

CODIGO 5 CONTROL.CS using System; using System.Collections.Generic; using System.ComponentModel; using System.Data; using System.Drawing; using System.Linq; using System.Text; using System.Windows.Forms; using System.Threading; using SpeechLib; using System.Speech.Recognition; using System.Speech.Synthesis; using System.Speech.AudioFormat; using ProyectoRely.DAL; namespace ProyectoRely { public partial class frmControl : Form { dsRely.tbl_ComandosDataTable comandosDT = new dsRely.tbl_ComandosDataTable(); DAL.dsRelyTableAdapters.tbl_ComandosTableAdapter comandosTA = new DAL.dsRelyTableAdapters.tbl_ComandosTableAdapter(); private SpeechSynthesizer synthesizer = null; private string selectedVoice = string.Empty; private SpeechRecognitionEngine recognizer = null; private DictationGrammar dictationGrammar = null; static SpeechRecognitionEngine speechReconocedor = null; static ManualResetEvent manualResetEvent = null; string avanzar = ""; string retroceder = ""; string derecha = ""; string izquierda = ""; string parar = ""; public frmControl() { CheckForIllegalCrossThreadCalls = false; InitializeComponent(); } private void frmControl_Load(object sender, EventArgs e) { // TODO: esta línea de código carga datos en la tabla 'dsRely.tbl_Comandos' Puede moverla o quitarla según sea necesario. 115

this.tbl_ComandosTableAdapter.Fill(this.dsRely.tbl_Comandos); comandosDT = comandosTA.GetData(); foreach (var item in comandosDT) { avanzar = item.avanzar; retroceder = item.retroceder; derecha = item.girar_derecha; izquierda = item.girar_izquierda; parar = item.parar; } synthesizer = new SpeechSynthesizer(); recognizer = new SpeechRecognitionEngine(); dictationGrammar = new DictationGrammar(); InitializeSpeechRecognitionEngine(); serialPort1.Open(); } private void InitializeSpeechRecognitionEngine() { recognizer.SetInputToDefaultAudioDevice(); Grammar customGrammar = CreateCustomGrammar(); recognizer.UnloadAllGrammars(); recognizer.LoadGrammar(customGrammar); recognizer.RecognizeAsync(RecognizeMode.Multiple); recognizer.SpeechHypothesized += new EventHandler(recognizer_SpeechHypothesized); } private Grammar CreateCustomGrammar() { GrammarBuilder grammarBuilder = new GrammarBuilder(); grammarBuilder.Append(new Choices(avanzar, retroceder,derecha, izquierda, parar)); return new Grammar(grammarBuilder); } private void recognizer_SpeechHypothesized(object sender, SpeechHypothesizedEventArgs e) { txtPalabra.Text = e.Result.Text; if (e.Result.Text == avanzar) { //MessageBox.Show("avanzando"); txtDireccion.Text = "avanzando"; escribir("A"); } else if (e.Result.Text == retroceder) { //MessageBox.Show("retrocediendo"); txtDireccion.Text = "retrocediendo"; escribir("B"); } 116

else if (e.Result.Text == derecha) { //MessageBox.Show("derecha"); txtDireccion.Text = "derecha"; escribir("C"); Thread.Sleep(1000); escribir("Q"); } else if (e.Result.Text == izquierda) { //MessageBox.Show("izquierda"); txtDireccion.Text = "izquierda"; escribir("D"); Thread.Sleep(1000); escribir("Q"); } else if (e.Result.Text == parar) { //MessageBox.Show("parando"); txtDireccion.Text = "parando"; escribir("Q"); } } public void escribir(string orden) { if (serialPort1.IsOpen) { serialPort1.Write(orden); } else { serialPort1.Open(); } } private void serialPort1_DataReceived(object sender, System.IO.Ports.SerialDataReceivedEventArgs e) { string dato_recibido = null; //una variable para almacenar lo que llege dato_recibido = serialPort1.ReadExisting(); if (dato_recibido == "W") { escribir("W"); lblEstado.Text = "Sistema conectado"; } if (dato_recibido == "Y") { lblEstado.Text = "Sistema Activado"; 117

} if (dato_recibido == "X") { lblEstado.Text = "Sistema Desconectado"; } } } }

118