Upload
others
View
7
Download
0
Embed Size (px)
Citation preview
Universidad Tecnológica de Tecámac
“Diseño de objetos de aprendizaje de M-Learning para la
materia Metodología de la Programación”
Integrantes del equipo:
CRUZ MAGADAN SARAI
FLORES LÓPEZ JESÚS EDUARDO
RANGEL SUÁREZ LORENZO
ROBLES LÓPEZ EDUARDO
Asignatura: Administración de Proyectos
Grupo: 8ITI1
Profesor: Alejandro Buendia
Introducción
En las Universidades Tecnológicas, se ha observado que un gran número de
alumnos pertenecientes a la carrera Técnico Superior Universitario en Tecnologías
de la Información y Comunicación; Área Sistemas Informáticos, principalmente en
los primeros tres cuatrimestres de la carrera, no han fortalecido su aprendizaje con
los principios básicos de las materias inherentes a la programación, esto se ve
reflejado principalmente en la reprobación y deserción, un estudio realizado entre
los alumnos además de los profesores pertenecientes a la División de Informática
de la Universidad Tecnológica de Tecámac, arrojó que es imperioso facilitar el
aprendizaje por lo que respecta a las unidades temáticas de la materia
Metodología de la Programación, que es el eje principal del resto de las materias
del área de especialidad, la cual se imparte durante el primer cuatrimestre de la
carrera.
Por tal motivo, el Cuerpo Académico: Servicios Tecnológicos, decidió iniciar un
proyecto denominado M-learning el cual dio inicio con la gestión que se hizo a
principios de año para contar con un laboratorio de Tecnología Móvil mismo que
ya se ha aprobado por medio de fondos FACUT y que será implementado a finales
de este año. Este laboratorio será utilizado para implementar diversos proyectos
iniciando con la generación de objetos de aprendizaje para la materia de
Metodología de la Programación, debido a que como se mencionó es una de las
materias de mayor impacto en la carrera, también requiere mucha práctica extra
clase por parte de los estudiantes y asesoría por parte de los profesores.
Es por esto que se planteó como objetivo general: “Proporcionar actividades de
apoyo con sus respectivos contenidos a los alumnos que cursen la materia de
Metodología de la Programación, que cuente con las características de los objetos
de aprendizaje y el M-Learning”.
1. Acta constitutiva
Nombre del
proyecto
Diseño de objetos de aprendizaje de M-Learning para la materia
Metodología de la Programación
Director de
proyecto
T.S.U Lorenzo Rangel Suárez
Patrocinador
del proyecto
M. en c. Moramay Ramírez Hernández
Propósito Servir de ayuda a los estudiantes de la Universidad Tecnológica
de Tecámac que cursan la carrera de Tecnologías de la
Información y Comunicación, permitiendo disminuir la deserción
de los alumnos, retroalimentando los temas impartidos en clase.
Producto Se entregarán 9 aplicaciones móviles para los alumnos de esta
institución y un sitio Web para consultar contenidos de la materia
y poder descargar las aplicaciones móviles.
Comunicación con el cliente
La información necesaria para la creación de este sistema se
recolectará mediante entrevistas y encuestas aplicadas a los
usuarios.
Informes Los avances del sistema se presentarán cada mes con el
patrocinador del proyecto.
FIRMAS
________________________ _______________________
T.S.U Lorenzo Rangel Suárez M. en c. Moramay Ramírez
Hernández
Director del proyecto Patrocinador
2. Alcance de proyecto
Problemática
Hoy en día en las Universidades Tecnológicas (UTs) la materia de Metodología de
la Programación en la carrera de Tecnologías de la Información y Comunicación
es un eje fundamental para la formación técnica, sin embargo es una de las que
tienen mayor índice de reprobación ya que aproximadamente el 40% de los
estudiantes desertan debido a que se requiere un pensamiento lógico, además de
habilidades matemáticas, cosa que a la gran mayoría se les dificulta y esto se ve
reflejado principalmente en la deserción de los alumnos.
La Universidad Tecnológica de Tecámac no es la excepción, puesto que los
profesores que imparten las materias inherentes a la programación en un estudio
efectuado para este proyecto, confirman la falta de habilidad en el manejo de los
conceptos básicos de la programación por parte de los alumnos de hasta cuarto
cuatrimestre de la carrera Técnico Superior Universitario en Tecnologías de la
Información y Comunicación área Sistemas Informáticos.
Objetivo General del proyecto
El principio fundamental de este proyecto se centra básicamente en desarrollar
ciertos objetos de aprendizaje con las características del M-Learning. Para ello se
plantea el acceso extra muros a los contenidos temáticos, proporcionar el acceso
a ciertas actividades de apoyo (aplicaciones para dispositivos móviles) a los
alumnos que cursen la materia de Metodología de la Programación.
Objetivos específicos
Profundizar el análisis de la tecnología JME y JSE para el desarrollo de
aplicaciones móviles.
Desarrollar aplicaciones móviles en JME que cuenten con interfaces
gráficas atractivas, de fácil uso e intuitivas para los usuarios.
Diseñar aplicaciones que proporcionen una retroalimentación al usuario.
Permitir a los Profesores de la materia de Metodología de la Programación
apoyarse en estas aplicaciones móviles para reforzar el aprendizaje en los
alumnos.
Proporcionar material de apoyo que abarque todas las unidades temáticas.
Desarrollar la plataforma de contenidos temáticos y la distribución de las
aplicaciones.
Alcance
Crear aplicaciones móviles que realicen una transición de los objetos de
aprendizaje con los que cuenta el Responsable del Cuerpo Académico Servicios
Tecnológicos de la Universidad Tecnológica de Tecámac en la materia de
Metodología de la Programación en el programa del 2012.
Se establecerán las condiciones de distribución de aplicaciones móviles
educativas mediante un sitio Web, con sus respectivos contenidos a los alumnos
que cursen esta materia, las cuales los apoyen en la comprensión de las unidades
temáticas.
Requisitos funcionales
Un requisito funcional define el comportamiento interno del software: cálculos,
detalles técnicos, manipulación de datos y otras funcionalidades específicas que
muestran cómo los casos de uso serán llevados a la práctica. Son
complementados por los requisitos no funcionales, que se enfocan en cambio en
el diseño o la implementación.
Como se define en la ingeniería de requisitos, los requisitos funcionales
establecen los comportamientos del sistema.
Los requisitos funcionales del sistema son:
Creación de 9 aplicaciones móviles
Utilizar contenidos temáticos basados en el programa de estudios del 2012
Crear un sitio Web para descargar aplicaciones y consultar los contenidos
El sitio Web permitirá modificar los contenidos y/o aplicaciones
Las aplicaciones tendrán como contenido un cuestionario
Preguntas aleatorias en las aplicaciones
Las aplicaciones realizarán una evaluación del cuestionario
La aplicación deberá tener instrucciones de uso
Requisitos no funcionales
Un requisito no funcional o atributo de calidad es, en la ingeniería de sistemas y
la ingeniería de software, un requisito que especifica criterios que pueden usarse
para juzgar la operación de un sistema en lugar de sus comportamientos
específicos, ya que éstos corresponden a los requisitos funcionales.
Los requisitos no funcionales del sistema son:
Seguridad en las aplicaciones
Diseño de interfaces (en aplicaciones y sitio Web)
3. Estándares de calidad
La gerencia de Calidad
La gerencia de la calidad es el proceso que asegura que todas las actividades necesarias para diseñar, planificar e implementar un proyecto sean efectivas y eficientes con respecto al propósito del objetivo y su misión.
La gerencia de la calidad es un proceso continuo que empieza y termina con el proyecto.
Auditorias de Calidad
Las auditorias de calidad son revisiones estructuradas de las actividades de la gerencia de calidad que ayudan a identificar las lecciones aprendidas que pueden mejorar ejecución de las actividades actuales o futuras del proyecto. Las auditorias son ejecutadas por el personal del proyecto o consultores con experiencia en áreas específicas.
El ciclo PHRA (Planificar, Hacer, Revisar, Actuar,)
La herramienta más popular utilizada para determinar el aseguramiento de la calidad es el ciclo de Shewhart. Este ciclo consiste en cuatro pasos: Planificar, hacer, revisar, y Actuar. Estos pasos son comúnmente abreviados PHRA.
Los cuatro pasos del aseguramiento de la calidad son:
Planificar: Establecer los objetivos y procesos requeridos para entregar los resultados deseados.
Hacer: Implementar el proceso.
Revisar: Monitorear y evaluar el proceso implementado evaluando los resultados versus los objetivos predeterminados.
Actuar: Aplicar las acciones necesarias para mejorar si los resultados requirieran cambios.
El método planificar, hacer, revisar y actuar es un método efectivo para monitorear la calidad, ya que analiza las condiciones existentes y procedimientos utilizados para proveer el bien o servicio a los beneficiarios.
Modelos de Madurez
Otro enfoque para mejorar la calidad es el uso de modelos de madurez, los cuales son una guía para ayudar a las organizaciones y proyectos a mejorar sus procesos.
El modelo incluye un método para establecer los niveles de madurez del proyecto como un primer paso para determinar las mejoras requeridas para aumentar la capacidad del proyecto para entregar los resultados como se prometió.
La madurez de la calidad del proyecto usualmente consiste de cinco niveles:
Nivel 1. Nivel informal, no existen procesos definidos para las prácticas o estándares de calidad. La organización puede estar en las etapas iniciales de consideración de cómo los proyecto deben definir la calidad, pero la mayoría de esfuerzos son informales.
Nivel 2. Nivel definido, la organización ha definido algunos estándares básicos de calidad y políticas de calidad del proyecto que están siendo adoptadas. Pero no todos los proyectos las están usando de manera constante.
Nivel 3. Nivel repetible, el proceso de calidad está bien documentado y es un estándar organizacional. Todos los proyectos están usándolo y produciendo resultados consistentes.
Nivel 4. Nivel controlado, todos los proyectos se les requiere usar procesos estándares de planificación de la calidad. La organización tiene una unidad o roles que coordinan los estándares de calidad y aseguramiento, y las auditorias de calidad se realizan regularmente.
Nivel 5. Nivel optimizado, el proceso de calidad incluye lineamientos para la retroalimentación de las mejoras al proceso. Se utilizan medidas como criterios claves para las decisiones de calidad y los resultados de calidad son altamente predecibles.
4. Esquema del ciclo de vida
El sistema funciona en el momento en que el Administrador sube aplicaciones
al servidor y modifica los contenidos en el sitio Web, para que los alumnos
puedan consultar esos contenidos y descargar las aplicaciones, para así
instalarlas en sus dispositivos móviles y poder hacer uso de estas.
A continuación se muestra un diagrama con el objetivo de mostrar mejor el
comportamiento del sistema.
Figura 7.2 Estructura del sistema.
5. Script
Investigación sobre los objetos de aprendizaje y M-Learning
En esta etapa del proyecto se realizó una investigación sobre que son los objetos
de aprendizaje y también se investigó sobre la metodología M-Learning.
Investigación preliminar
Aquí se realizó una investigación sobre todo lo que se realizará en el transcurso
del proyecto, las metodologías que se utilizaran en el desarrollo del proyecto,
como se realizara el sitio Web, las aplicaciones móviles, etc.
Análisis de la tecnología Java Micro Edition
Se investigó sobre la plataforma Java micro Edition la cual es una especificación
de un subconjunto de la plataforma Java orientada a proveer una colección
certificada de APIs de desarrollo de software para dispositivos con recursos
restringidos. Está orientado a productos de consumo como PDAs, teléfonos
móviles o electrodomésticos.
Análisis del ciclo de vida clásico de Pressman
Se hizo un análisis para ver que metodología era la indicada para la realización del
proyecto y se llegó a la conclusión de que la metodología de Pressman o de
cascada es la más indicada para la realización de este proyecto.
Análisis
En esta etapa se comenzó a recopilar la información necesaria para la elaboración
del proyecto, tal como los requisitos funcionales y no funcionales, se elaboraron
los diagramas UML, la EDT y todo lo necesario para que el desarrollo del proyecto
sea lo mejor posible.
Diseño
En esta etapa del proyecto se realizaron las aplicaciones móviles que son objetos
de aprendizaje que ayudaran a los alumnos de primer cuatrimestre de la carrera
Tecnologías de la Información y Comunicación lo cual será de gran ayuda para
ellos y para la Universidad porque con este proyecto se busca reducir el
porcentaje de deserción en la carrera.
También en esta etapa se comenzara con el desarrollo del sitio de Web de
contenidos, que también será un servidor que almacenara la aplicación móvil para
poder facilitar su distribución a los alumnos.
Implantación
Aquí en esta etapa se hará la implementación de las aplicaciones móviles para
que puedan ser utilizadas por los alumnos.
Pruebas
En la etapa de pruebas se comprueba el adecuado funcionamiento de las
aplicaciones mediante algunas pruebas sencillas que nos servirán para ver si la
aplicación no tiene algún error en los procedimientos o métodos que se hicieron.
Instalación (puesta en operación)
En esta etapa se hará un seguimiento a lo realizado en el proyecto para verificar que las aplicaciones funcionan de una manera correcta.
6. Elementos clave para su planeación, monitoreo y control
En el desarrollo de nuestro proyecto, hay 3 elementos claves los cuales serán los entregables que se harán conforme se va desarrollando el proyecto.
El primer entregable que se realizó es la Documentación, la cual es una parte fundamental en la elaboración del proyecto, ya que es la base de todo lo que se necesita, los diagramas UML, costos, cronograma, organigrama, todo esto para tener un orden de lo que se va a elaborar, ya sean las aplicaciones móviles y el sitio Web de contenidos.
La segunda entrega serán las Aplicaciones móviles las cuales son la parte medular del proyecto, ya que este proyecto está basado en la creación de las aplicaciones para dispositivos móviles, las cuales ayudaran a los profesores de la materia Metodología de la programación porque estas aplicaciones serán objetos de aprendizaje, estos servirán para que los alumnos aprendan algunas cosas de una manera interactiva y no tan tediosa como luego suele ser andar memorizando tipos de datos y los rangos que comprenden.
El último entregable será el Sitio Web de contenidos el cual será de gran ayuda porque será la forma de distribución de las aplicaciones móviles y también será un sitio Web que servirá para que los alumnos puedan repasar los temas vistos en clase.
7. EDT del Proyecto
A continuación se presenta la Estructura de Desglose de Trabajo basada en la metodología RAD (Diseño Rápido de
Aplicaciones) la cual fue elegida por el equipo de trabajo para el desarrollo del sitio web de este proyecto. Esta
metodología fue elegida por aspectos como la reducción de costos, aseguramiento de la calidad y porque está más
enfocada a proyectos pequeños o medianos con logros a corto plazo.
Sitio Web M -
Learning
Planificación de
Requisitos
Planteamiento de
la Problematica
Propuesta de
Solución
Definir
Alcance
Definir
Objetivos
Definir objetivo general
Definir objetivos
especificos
Definir Requisitos
del sistema
Diseño
Creación del
Prototipo
Análisis de
Procesos
Creación del
Mapa
Navegacional
Definir el
Contenido
Construcción
Confirmación de
Requisitos Codificación
Creacion de
módulos
Realización
de pruebas
Construcción del Servidor
Web
Implementación
Alojar Sitio Web en el Servidor
Adiestramiento de los usuarios
Realizar Manual de Usuario
Diccionario de la EDT
Paquetes de trabajo
Fase 1: Planificación de Requisitos Fase 2: Diseño Fase 3: Construcción Fase 4: Implementación Descripción de los Paquetes de Trabajo
Planificación de Requisitos: En esta fase se planteará la problemática por la cual se generó el proyecto, se dará la propuesta de solución y se definirán los objetivos, el alcance del proyecto y los requisitos del sistema.
Diseño: Se analizará la información obtenida en la fase anterior y se definirá el contenido y los apartados para posteriormente realizar diseño del prototipo del sitio web.
Construcción: Se lleva a cabo la codificación de los apartados y se realizan las pruebas necesarias para el aseguramiento de la funcionalidad del sitio web.
Implementación: Al término de la fase 3 se alojará el sitio web en un servidor, así mismo se realizará el manual técnico y el manual de usuario.
Planificación de Requisitos ID: DefReq -1
Responsable: Líder de Proyecto
Analista
ID Entregable Actividad Descripción
DefReq -1.1
Planteamiento de la problemática
Se realizará una reunión del equipo de trabajo para definir exactamente cuál es la problemática que se presenta.
DefReq -1.2 Propuesta de solución
El equipo de trabajo planteará la solución para la problemática presentada.
o DefReq -1.2.1 Definir Requisitos del sistema
En base a la propuesta de solución se definirán los requisitos del sistema mediante la identificación de las necesidades de los usuarios.
o DefReq -1.2.2 Definir Alcance Se definirá el alcance del proyecto en donde se especificarán los logros
esperados para el final del proyecto.
o DefReq -1.2.3 Definir Objetivos Se documentarán los objetivos del proyecto.
DefReq -1.2.3.1
Objetivo general
Se planteará el objetivo general del proyecto, se describirá que es lo que se pretende conseguir al término del proyecto.
DefReq -1.2.3.2
Objetivos específicos
El objetivo general será desglosado en objetivos específicos en donde se precisa lo que se desea conseguir.
Diseño ID: Dis -2
Responsable: Analista
Diseñador
ID Entregable Actividad Descripción
Dis -2.1 Creación del prototipo
Al término de la fase 1 se realizará la creación del prototipo del sitio web.
Dis -2.1.1 Análisis de procesos
Se realizará un análisis de los procesos que se necesitan llevar a cabo antes de ser codificados y así mismo se analiza la información recabada en la fase anterior.
Dis -2.1.2
Creación del mapa navegacional
Se realizará un diagrama donde se represente cada una de las partes que constituyen de la estructura del sitio web.
Dis -2.1.2.1
Definir el contenido
En base al mapa navegacional se realizará la definición del contenido para cada apartado especificado en el diagrama antes mencionado.
Construcción ID: Cons -3
Responsable: Diseñador
Programador
ID Entregable Actividad Descripción
Cons -3.1 Confirmación de requisitos
Los requisitos documentados en la primera fase serán confirmados mediante los responsables de esta fase.
Cons -3.2 Codificación
Se realizará la programación del sitio web utilizando el entorno de desarrollo Netbeans y el lenguaje de programación AJAX.
Cons -3.2.1 Creación de módulos
Se especificarán los módulos o apartados que tendrá el sitio web basándose en el mapa navegacional realizado en la fase anterior.
Cons -3.2.1.1
Realización de pruebas
Al término de la codificación se realizarán pruebas de caja negra y caja blanca al sitio web.
Cons -3.3 Creación del servidor web
Se configurará un servidor web utilizando el Sistema Operativo Debian.
Implementación ID: Imp -4
Responsable:
Líder de Proyecto
Analista
Diseñador
Programador
ID Entregable Actividad Descripción
Imp -4.1 Alojar sitio web en el servidor
Cuando la programación del sitio web se concluya se procederá a cargar todos los elementos que integran en el servidor creado en la fase anterior.
Imp -4.2 Adiestramiento de los usuarios
Para que los usuarios puedan utilizar el sitio web de manera óptima se documentará un manual.
o Imp -4.2.1 Realizar manual de usuario
Se documentará cada una de las acciones del sitio web y se darán instrucciones concisas acerca del funcionamiento de cada una de ellas.
8. Diagrama de Gantt
El diagrama de Gantt puede apreciarse de manera detallada en la siguiente liga:
Diseño de objetos de aprendizaje de la materia Metodología de la
Programación.pod
9. Diagrama de ruta crítica
Es una herramienta que se utiliza para organizar programas, se representa por
una red de nodos y flechas para determinar cuáles son las actividades críticas y
para revisar el avance del proyecto una vez que se ha iniciado.
A continuación se presentará la ruta crítica de nuestro sistema:
ACTIVIDAD PREDECESOR DURACIÓN
1. Planificación de Requisitos
1.1 Planteamiento de la problemática
-- 5 días
1.2 Propuesta de solución 1.1 5 días
1.2.1 Definir Requisitos del sistema
1.2 10 días
1.2.2 Definir Alcance 1.2 1 días
1.2.3 Objetivo general 1.2 1 días
1.2.4 Objetivos específicos 1.2.3 2 días
2. Diseño
2.1 Creación del prototipo 1.2,1.2.1 7 días
2.1.1 Análisis de procesos -- 3 días
2.1.2 Creación del mapa navegacional
2.1 2 días
2.1.3 Definir el contenido 2.1.2 2 días
3. Construcción
3.1 Confirmación de requisitos 1.2.1 2 días
3.2 Codificación 2.1 40 días
3.2.1 Realización de pruebas 3.2 5 días
3.3 Creación del servidor web -- 3 días
4. Implementación
4.1 Alojar sitio web en el servidor 3.2,3.3 2 días
4.2 Realizar manual de usuario 3.2 5 días
10. Informe de presupuesto y evaluación de alternativas de
inversión
Aquí se hace un desglose de los recursos que se utilizaran a lo largo de la realización del proyecto, este desglose se divide en 3 partes, recursos humanos, materiales y técnicos, en la tabla de recursos humanos se especifica la cantidad de personas que se necesitan en cada puesto, las funciones que debe realizar y el sueldo que va a percibir por mes.
También se muestra un subtotal que está realizado en un tiempo de 4 meses y el total que es la suma del subtotal y un análisis de reserva que se decidió sea un 10% del subtotal.
CANT PUESTO FUNCIONES SUELDO
1 Líder de
proyecto
Asignar los recursos humanos y de otro tipo
Definir las prioridades de las tareas
Planificar las iteraciones
Planificar y asignar las tareas
Motivar y organizar al equipo de trabajo para lograr
un objetivo definido
Informar sobre el estado actual del proyecto
Mantener el plan del proyecto
$3,000 mensuales
1 Diseñador
Diseñar la solución del problema de acuerdo al
análisis previo
Diseñar la interfaz del sistema
Realizar el diseño de la BD
$3,000 mensuales
1 Programador
Implementar el prototipo de solución mediante un
lenguaje de programación
Realizar pruebas del sistema
Depurar los errores de codificación
Participar en la etapa del diseño
$3,000 mensuales
1 Analista
Analizar el problema
Describir la posible solución
Controlar el trabajo del equipo de diseño para
garantizar el cumplimiento de los planes elaborados.
$3,000 mensuales
Representación de los algoritmos de los procesos de
cada tarea
Documentación técnica y de utilización del sistema
Subtotal $48,000
Total $52,800
En la tabla de recursos materiales se especifica de forma detallada las cosas que son necesarias para poder realizar el proyecto de una forma adecuada, al igual que en la tabla de recursos humanos hay un subtotal y un total al que se le agrega el 10% del análisis de reserva.
CANT. NOMBRE DESCRIPCIÓN C. UNITARIO C. TOTAL
4 Escritorio ejecutivo Escritorio de madera con 4 cajones $1,500 $6,000
4 Sillas secretariales Silla giratoria con apoya brazos
ergonómica
$650 $2,600
1 Paquete de hojas Paquete de 500 hojas blancas tamaño
carta
$50 $50
1 Caja de lápices Caja de 48 lápices del # 2 $90 $90
1 Caja de bolígrafos Caja de 12 bolígrafos tinta negra $55 $55
4 Laptop Laptop Compaq Presario CQ43,
procesador AMD Vision, memoria
RAM de 2 GB, 500 GB en disco duro y
Sistema Operativo Windows 7.
$6,500 $26,000
1 Teléfono Celular LG T310 $1,400 $1,400
1 Tablet SO Android 4.0 4gb 512 mb multitouch $1,500 $1,500
Subtotal $37,695
Total $38,995
En esta tabla se muestran los recursos técnicos que se utilizaran, en este caso no tienen ningún costo pero igual se cuentan.
CANT. NOMBRE DESCRIPCIÓN C. UNITARIO C. TOTAL
Netbeans IDE 7.1 Entorno de desarrollo Netbeans IDE
7.1 Java Micro Edition
Software Libre --
JBED Emulador de archivos .jar en IOS
Android
Software Libre --
S.O. Debian Sistema operativo de Linux para la
implementación del servidor web
Software Libre --
Subtotal $ 0.00
Total $ 0.00
En esta última tabla se muestras los valores totales de las tablas mencionadas anteriormente y se realiza una suma y esta es el total del costo del proyecto.
Recurso Costo
Recursos Humanos $ 52,800
Recursos Materiales $ 38,995
Recursos Técnicos $ 0.00
Total del Proyecto $ 91,795
11. Recursos humanos
Perfil de los participantes y del administrador
Descripción de Roles
CONTROL DE VERSIONES
VERSIÓN HECHA POR
REVISADO POR
APROBADO POR
FECHA MOTIVO
1.0 Sarai Cruz Magadan
Jesús E. Flores López
Lorenzo Rangel Suárez
12/04/2013 Identificación y
definición de roles
NOMBRE DEL PROYECTO SIGLAS DEL PROYECTO
Diseño de Objetos de Aprendizaje de M-Learning para la Materia Metodología de la
Programación DOAMMP
Nombre del rol
Patrocinador
Objetivo del rol
Será el responsable principal del éxito del proyecto.
Requisitos del rol
Excelencia en el manejo de relaciones personales
Conocer las funciones principales de los puestos subordinados
Toma de decisiones
Liderazgo
Comunicación
Negociación
Niveles de autoridad
Toma decisiones acerca de:
Tiempo
Recursos
Supervisa a:
Líder de proyecto
Analista
Diseñador
Programador
Nombre del rol
Líder de Proyecto
Objetivo del rol
Es la persona que gestiona el proyecto, es el principal responsable para el éxito del proyecto, y por tanto la persona que asume el liderazgo y la administración de los recursos del proyecto para lograr los objetivos fijados.
Requisitos del rol
Excelencia en el manejo de relaciones personales
Adaptación rápida al cambio
Eficacia personal
Creatividad e innovación
Conciencia social
Conocer las funciones principales de los puestos subordinados
Manejo adecuado del tiempo
Toma de decisiones
Liderazgo
Comunicación
Negociación
Solución de Conflictos
Motivación
Niveles de autoridad
Toma decisiones acerca de:
La programación detallada de los recursos asignados al proyecto.
La información y los entregables del proyecto.
Los proveedores y contratos del proyecto.
Supervisa a:
Analista
Diseñador
Programador
Reporta a:
Patrocinador
Nombre del rol
Analista
Objetivo del rol
Es la persona que investigará la viabilidad del proyecto y definirá fechas para cada actividad.
Requisitos del rol
Fácil comprensión
Habilidad de comunicación
Conocimientos sobre computación
Capacidad de abstracción
Capacidad de análisis
Conocimientos sobre el paradigma de la Ingeniería de Software
Conocimiento sobre documentación técnica
Niveles de autoridad
Toma decisiones acerca de:
Las fechas de cada entregable del proyecto
Viabilidad del proyecto
Supervisa a:
Diseñador
Programador
Reporta a:
Líder de proyecto
Nombre del rol
Diseñador
Objetivo del rol
Es el encargado de realizar la solución de la problemática de acuerdo al análisis previo, realizará el diseño de la interfaz del producto.
Requisitos del rol
Saber elegir las técnicas adecuadas
Creatividad e innovación
Amplio conocimiento de las tecnologías de información
Conocimiento de bases de datos y lenguajes de programación
Capacidad de trabajar bajo presión
Niveles de autoridad
Toma decisiones acerca de:
Enfoque de base de datos a utilizar
Información requerida a mostrar en el producto final
Distribución de la información dentro de la aplicación
Supervisa a:
Programador
Reporta a:
Analista
Líder de proyecto
Nombre del rol
Programador
Objetivo del rol
Es el encargado de la codificación en base a la solución propuesta por el diseñador y realizará también las pruebas al producto final.
Requisitos del rol
Capacidad de análisis y pensamiento lógico
Creatividad e innovación
Conocimiento de bases de datos y lenguajes de programación
Conocimiento de Ingeniería de Software
Capacidad de trabajar bajo presión
Niveles de autoridad
Toma decisiones acerca de:
El lenguaje de programación a utilizar
Metodología de programación a utilizar
Supervisa a:
Reporta a:
Líder de proyecto
Diseñador
Matriz de responsabilidades
CONTROL DE VERSIONES
VERSIÓN HECHA POR REVISADO POR
APROBADO POR
FECHA MOTIVO
1.0 Sarai Cruz Magadan
Jesús E. Flores López
Lorenzo Rangel Suárez
12/04/2013 Matriz de asignación de
responsabilidades
NOMBRE DEL PROYECTO SIGLAS DEL PROYECTO
Diseño de Objetos de Aprendizaje de M-Learning para la Materia Metodología de la Programación
DOAMMP
Lorenzo Rangel Suárez - Líder de Proyecto
Sarai Cruz Magadan -
Analista
Eduardo Robles López -
Diseñador
Jesús Eduardo Flores López - Programador
Planteamiento de la
problemática F R P P
Definir alcance F R P P Definir objetivos F R P P Propuesta de solución F R P P Definir requisitos del sistema F R P P Definir el contenido de la
página web R P P
Análisis de procesos de la
página web R P P
Creación del mapa
navegacional P R P
Creación del prototipo F P R P Creación de módulos P R P Codificación P P R Realización de pruebas F P P R Construcción del servidor Web P R Alojar sitio Web en el servidor P R Realizar manual de usuario F R P P
F: Firma requerida R: Responsable P: Participante
Lista de factores clave de desempeño
CONTROL DE VERSIONES
VERSIÓN HECHA POR
REVISADO POR
APROBADO POR
FECHA MOTIVO
1.0 Sarai Cruz Magadan
Jesús E. Flores López
Lorenzo Rangel Suárez
12/04/2013 Factores clave de
desempeño
NOMBRE DEL PROYECTO SIGLAS DEL PROYECTO
Diseño de Objetos de Aprendizaje de M-Learning para la Materia Metodología de la
Programación DOAMMP
EVALUACIÓN DEL DESEMPEÑO
Apellido y Nombre:
Puesto:
Fecha:
Evaluador:
Evalúe del 1 al 5 las siguientes métricas:
1.- Malo. 2.-Regular. 3.-Bueno. 4.-Muy Bueno. 5.-Excelente
Desempeño Laboral
1 Responsabilidad
2 Exactitud y calidad de trabajo
3 Cumplimiento de fechas estimadas / pautadas
4 Productividad – volumen y cantidad de trabajo
5 Orden y claridad del trabajo
6 Planificación del trabajo
7 Documentación que genera
8 Reporta avances de tarea
9 Capacidad de delegar tareas
10 Capacidad de realización
11 Comprensión de situaciones
12 Sentido común
13 Cumplimiento de los procedimientos existentes
14 Grado de conocimiento funcional
15 Grado de conocimiento técnico
Factor Humano/Actitudinal
16 Actitud hacia la empresa
17 Actitud hacia superior/es
18 Actitud hacia los compañeros
19 Actitud hacia el cliente
20 Cooperación con el equipo
21 Cooperación con pares
22 Capacidad de aceptar críticas
23 Capacidad de generar sugerencias constructivas
24 Presentación personal
25 Predisposición
26 Puntualidad
Habilidades
27 Iniciativa
28 Creatividad
29 Adaptabilidad (temas, grupos, funciones)
30 Respuesta bajo presión
31 Capacidad de manejar múltiples tareas
32 Coordinación y liderazgo
33 Potencialidad – capacidad de aprendizaje
34 Carisma
35 Compromiso hacia el grupo
36 Manejo de conflictos
37 Manejo y optimización del grupo
38 Relación con el cliente
39 Planificación – coordinación
40 Toma de decisiones
41 Comercial
Comentarios
12. Comunicación
Registro de Stakeholders.
CONTROL DE VERSIONES
VERSIÓN HECHA POR
REVISADO POR
APROBADO POR
FECHA MOTIVO
1.0 Sarai Cruz Magadan
Jesús E. Flores López
Lorenzo Rangel Suárez
28/01/2013 Registro de stakeholders
NOMBRE DEL PROYECTO SIGLAS DEL PROYECTO
Diseño de Objetos de Aprendizaje de M-Learning para la Materia Metodología de la Programación DOAMMP
IDENTIFICACIÓN EVALUACIÓN
NOMBRE EMPRESA Y PUESTO
ROL EN EL PROYECTO
REQUERIMIENTOS PRIMORDIALES
EXPECTATIVAS PRINCIPALES
INFLUENCIA POTENCIAL
FASE DE MAYOR INTERÉS
M. en C. Moramay Ramirez Hernandez
UT Tecámac Jefe del Cuerpo Académico Servicios Tecno-lógicos
Cliente (Usuario, recomendador, decisor de satisfacción)
Aplicaciones para dispositivos móviles para la materia Metodología de la Programación
Que las aplicaciones sirvan como objetos de aprendizaje para los alumnos del primer cuatrimestre
Fuerte
Pruebas
Lorenzo Rangel Suárez
3 Soft - Gerente
Líder de Proyecto (Asignar tareas, resolver problemas y toma de decisiones)
Cumplir con el plan del proyecto
Implementación exitosa de la solución
Fuerte
Todo el proyecto
Sarai Cruz Magadan
3 Soft Analista Administrativo
Analista
Cumplir con la delimitación análisis de la solución informática (descripción del problema), para ver lo que se requiere inicialmente
Descripción correcta de la problemática para implementar la mejor de las soluciones informáticas
Mediana
Análisis de requisitos
Eduardo Robles López
3 Soft Administrativo
Diseñador Correcta traducción de las necesidades del cliente en instrucciones y la creación del modelo informático.
Descripción eficaz de la solución
Fuerte
Etapa de Diseño y arquitectura
Jesús Eduardo Flores López
3 Soft Desarrollador
Programador Amplio conocimiento en lenguajes de programación y la correcta elaboración de instrucciones de programación
implementación de prototipos del sistema
Mediana Etapa de Codificación
ESTRATEGIA DE GESTIÓN DE STAKEHOLDERS
CONTROL DE VERSIONES
VERSIÓN HECHA POR REVISADO POR APROBADO POR FECHA MOTIVO
1.0 Sarai Cruz Magadan
Jesús E. Flores López
Lorenzo Rangel Suárez
28/01/2013 Registro de stakeholders
Nombre del proyecto Siglas del proyecto
Diseño de Objetos de Aprendizaje de M-Learning para la Materia Metodología de la Programación
DOAMMP
STAKEHOLDERS (Personas o Grupos)
INTERES EN EL PROYECTO
EVALUACION DEL IMPACTO
ESTRATEGIA POTENCIAL PARA GANAR SOPORTE O REDUCIR OBSTACULOS
OBSERVACIONES Y COMENTARIOS
Gerente. Lorenzo Rangel Suárez
Que el proyecto sea terminado exitosamente para poder satisfacer al cliente y currículo académico
Muy alto
Estar en contacto continuo con el cliente y los miembros del equipo para eficientar el desarrollo del proyecto e involucrarse directamente en el mismo
N i n g u n o.
Analista. Sarai Cruz Magadan
Que el análisis de la problemática sea efectuado de manera correcta para asegurar el éxito de
alto
Establecer amplios canales de comunicación con el cliente para determinar
N i n g u n o.
las fases siguientes del proyecto
correctamente la especificación del sistema
Administrativo. Eduardo Robles López
Plasmar todo su talento creativo en cada una de las soluciones presentadas y así éstas sean potencialmente funcionales
Alto
evaluar posibles soluciones y escoger las más apropiadas de acuerdo a la satisfacción que muestre el cliente
N i n g u n o.
Desarrollador. Jesús Eduardo Flores López
Participación en la definición del producto diseñando y mejorando prototipos y/o demos para validar los requerimientos
Medio
Testeo de las aplicaciones y supervisión del proceso de arranque de la aplicación y Mantenimiento.
Se planea que el perfil sea más acercado al de un desarrollador que simplemente limitarse al ser programador.
MATRIZ DE COMUNICACIÓN DEL PROYECTO
CONTROL DE VERSIONES
VERSIÓN HECHA POR REVISADO POR APROBADO POR FECHA MOTIVO
1.0 Sarai Cruz Magadan
Jesús E. Flores López
Lorenzo Rangel Suárez
28/01/2013 Registro de stakeholders
Nombre del proyecto Siglas del proyecto
Diseño de Objetos de Aprendizaje de M-Learning para la Materia Metodología de la Programación DOAMMP
INFORMACIÓN CONTENIDO FORMATO NIVEL DE DETALLE
RESPONSABLE DE COMUNICAR
GRUPO RECEPTOR
METODOLOGÍA O TECNOLOGÍA
FRECUENCIA DE COMUNICACIÓN
Plan del proyecto
Informar el plan del proyecto a todos los interesados
Project Charter
Muy alto
Líder de proyecto
Equipo del proyecto
Documento digital (pdf)via correo electronico
Fin de la planificación
Informe mensual del proyecto
Informar el avance del proyecto, actividades, riesgos y problemas críticos, hitos, compromisos
Informes alto Líder del proyecto
Comité del proyecto
Documento por escrito con firmas
Mensual
Bitácora del proyecto
# registro
Descripción Prioridad
Estrategia Fecha de apertura
Status Fecha de cierre
responsable
Tarea Elaboración del estudio de factibilidad del proyecto
Alta Realizar una analogía
20 diciembre de 2012
Terminado
25 de diciembre de 2012
Lider de proyecto y analista
Decisión
Se informa a los interesados sobre la iniciación del proyecto
Alta Reunión general 01 enero 2013
Terminado 01 enero 2013
Líder de proyecto
Decisión
Se definen a las partes interesadas en el proyecto
Alta Reunión general 01 enero 2013
Terminado 01 enero 2013
Líder de proyecto y cliente
Decisión
Elaboración y suscripción del acta constitutiva
Alta Reunión general 5 de enero de 2013
Terminado
5 de enero de 2013
Líder de proyecto y cliente
Decisión
Se entregan las responsabilidades a los interesados en el proyecto
Alta Envío por estafeta 15 enero 2013
Terminado 17 enero 2013
Líder de proyecto
Decisión
Se definen las fechas de los entregables
Media Entregadas en la reunión general de la actividad 3
15 enero 2013
Terminado 17 enero 2013
Analista
Tarea
Elaboración del análisis de riesgos del proyecto
Media Analogía 20 enero 2012
Terminado 25 enero 2013
Analista
Riesgo
Los empleados consideran un paro laboral por falta de un aumento de sueldo
Alta Reunión con los empleados inconformes
15 febrero de 2013
Terminado
15 febrero de 2013
Líder de proyecto y líder sindical
Cambio
Modificación del presupuesto (Se requieren más recursos)
Media Reunión con el cliente
01 febrero de 2013
Pendiente de autorizar
2 febrero de 2013
Líder de proyecto y cliente
Tarea Culminación y entrega de los entregables
Alta Reunión con el cliente
01 marzo 2013
Terminado 02 marzo 2013
Líder de proyecto y cliente
Tarea Finiquito y acta de terminación del proyecto
Alta Reunión con el cliente
20 marzo 2013
Terminado 20 marzo 2013
Líder de proyecto y cliente
Información clave para cada actor involucrado
ANALISIS DE CAMBIOS
Cve: 001 Nombre: Implementación de la base de datos
Fase: Análisis Fecha de solicitud: 23/01/13
# Cambio: 001
Impacto del cambio
La funcionalidad será la misma solo que el sistema mejorará con este tipo de modificación.
Productos
No Producto Actividad Duración
1 Gestor de Base de datos Implementar la base de datos
2 semanas
Impacto del cambio
ESFUERZO: CALENDARIO:
Hrs. Por aplicar: 5 hrs al día
ALCANCE: RIESGOS:
Requerimientos adicionales
Análisis de la base de datos
Fecha de fin de proyecto autorizado:
Fecha de fin de proyecto estimado (nuevo):
Valor de riesgo anterior:
30%
Valor de riesgo estimado (nuevo):
20%
Técnico
Funcional
Mejora
SOLICITUD DE CAMBIOS
Cve: 001 Nombre: Implementación de la base de datos
Fase: Análisis Fecha de solicitud: 23/01/13
# Cambio: 001
Datos del solicitante
Nombre del solicitante: Moramay Ramírez Hernández
Área: Sistemas.
Teléfono: 554 567 56 56 e-mail: [email protected]
Datos del cambio
Descripción:
Las aplicaciones móviles no utilizaban base de datos, pero debido a las observaciones para mejorar el sistema se implementará la base de datos.
Tipo de cambio Prioridad
Técnico
Funcional
Mejora
Tiempo
Costo
Justificación:
Es necesario cubrir los aspectos importantes para la mejora de nuestro sistema y pueda satisfacer las necesidades del cliente.
Solicito: Administración de Proyectos
Alta
Media
Baja
Control de productos proporcionados por el cliente
Productos proporcionados por el cliente
Aquí se enlistan los productos que el cliente haya proporcionado y que, conforme a lo acordado, le tendrán que ser
devueltos al terminar el proyecto o en el transcurso del mismo, o bien que el equipo de trabajo deberá responder por los
mismos.
Producto / descripción Número de
Serie
Fecha de
Recibido
Responsable Fecha de
Recepción
Observaciones
Lap top Compaq Presario 1234567890 01 enero
2013
Lorenzo Rangel
Suárez
Equipo nuevo para
desarrollo
Lap top Compaq Presario 1234567891 01 enero
2013
Sarai Cruz
Magadan
Equipo semi nuevo
para desarrollo
Lap top Compaq Presario 1234567892 01 enero
2013
Eduardo Robles
López
Equipo nuevo para
desarrollo
Lap top Compaq Presario 12345678923 01 enero
2013
Jesús Flores
López
Equipo nuevo para
desarrollo
Table Viewsonic
0987654
01 enero
2013
Lorenzo Rangel
Suarez
Equipo nuevo para
pruebas
Objetos de aprendizaje en 08098787r8 12 enero Lorenzo Rangel En buen estado de
papel
2013 Suárez uso
Libro “Desarrollo Android”
s/n
15 enero
2013
Sarai Cruz
Magadan
En buen estado de
uso
Impresora laser Lexmarx 798709089
16 enero
2013
Lorenzo Rangel
Suárez
En buen estado de
uso
CONTROL DE CAMBIOS
Cve: 001 Nombre: Cruz Magadan Sarai
# Descripción
corta del cambio
Solicitante F. de
solicitud Estado
Esfuerzo (Hrs)
Fin prog.
# recursos
Fecha de resolución
001 Implementación de la base de
datos Cliente 23/01/13
En proceso
5 hrs al día
19/03/13 Gestor
de base de datos
4/02/13
Métodos de comunicación, justificación y formato.
Agenda de la reunión
Fecha de la reunión: 01 enero de 2013
Asunto: Definición de entregables
Proyecto: Diseño de Objetos de Aprendizaje de M-Learning para la
materia Metodología de la Programación.
Participante Puesto
M. en C. MORAMAY RAMIREZ HERNANDEZ Cliente
TSU LORENZO RANGEL SUAREZ Líder de proyecto
TSU SARAI CRUZ MAGADAN Analista
Punto Tema Estatus
1 Las interfaces de las aplicaciones Terminado y
acordado
2 Definición de la temática del sitio web Terminado y
acordado
3 Definición de la temática de las aplicaciones móviles Terminado y
acordado
4 Definición de las fechas de revisión y entrega de las
aplicaciones
Terminado y
acordado
5 La documentación de las aplicaciones (web y
móviles)
Terminado y
acordado
6 Piloteo de las aplicaciones en los usuarios Terminado y
acordado
Minuta
Fecha: 15/02/2013
Duración: 11:00 - 13:30
Lugar: Universidad Tecnológica de Tecámac
Fase: Análisis y Diseño
Elaboró: TSU Eduardo Robles López
Asistentes
Nombre Empresa/Área y puesto/Rol
TSU. Lorenzo Rangel Suarez 3-soft, Líder de proyecto
TSU. Sarai Cruz Magadan 3-soft, Analista
TSU. Jesús Eduardo Flores López 3-soft, Diseñador
TSU. Eduardo Robles López 3-soft, Programador
M. en C. Moramay Ramírez Hernández UTTEC, Jefe del cuerpo académico
servicios tecnológicos de la división de
informática
Objetivo Estatus
Desarrollar las aplicaciones móviles sobre los temas de la materia
Metodología de la programación
Terminado
Realizar el análisis para la creación del sitio web de contenidos Terminado
Actividades realizadas Estatus
Presentación de los asistentes Realizado
Introducción del proyecto que se está realizando Realizado
Revisar el llenado de los formatos faltantes Realizado
Compromisos
Pendiente Responsable Fecha
Compromiso
Terminar el sitio web de contenidos
TSU. Jesús Eduardo
Flores López
TSU. Eduardo Robles
López
11-Nov-13
Realizar el Manual de Usuario TSU. Sarai Cruz
Magadan
25-Nov-13
Realizar el Manual Técnico TSU. Sarai Cruz
Magadan
25-Nov-13
Acuerdos y aclaraciones
Se acordó que la próxima reunión se realizara en 2 meses, específicamente
el 18 de Abril de 2013.
M. en c. Moramay Ramírez Hernández T.S.U Lorenzo Rangel Suárez
Representante facultado por el cliente Representante facultado por el
proveedor
LOG DE POLÉMICAS
CONTROL DE VERSIONES
VERSIÓN HECHA POR REVISADO POR APROBADO POR FECHA MOTIVO
1.0 Sarai Cruz Magadan
Jesús E. Flores López
Lorenzo Rangel Suárez
11/02/2013 Polémicas del Proyecto
CÓDIGO DE
POLÉMICA DESCRIPCIÓN INVOLUCRADOS
ENFOQUE DE
SOLUCIÓN
ACCIONES DE SOLUCIÓN
RESPONSABLE FECHA RESULTADO OBTENIDO
PO-01
Las aplicaciones móviles no son compatibles en todos los dispositivos móviles.
Diseñador, Programador
Programar aplicaciones en diferentes lenguajes para que sean compatibles con la mayoría de dispositivos.
Organizar una reunión donde participe el equipo de trabajo para discutir la viabilidad de manejar diferentes lenguajes de programación.
Programador 06-02-
13
Se aprobó la utilización otro lenguaje aparte de Java ME que es Android ya que son los más comunes en los dispositivos móviles.
NOMBRE DEL PROYECTO SIGLAS DEL PROYECTO
Diseño de Objetos de Aprendizaje de M-Learning para la Materia Metodología de la Programación
DOAMMP
PO-02
Se comenta sobre el desarrollo de aplicaciones móviles que abarquen también los contenidos temáticos de la materia Estructura de Datos.
Líder de Proyecto, Analista,
Diseñador, Programador
Realizar encuestas a los posibles usuarios para ver si les interesa que se añadan objetivos de aprendizaje enfocados en la materia Estructura de Datos.
Preguntar a los alumnos del 4º cuatrimestre de TSU en TIC’s si usarían las nuevas aplicaciones móviles.
Realizar una reunión del equipo de trabajo para discutir la viabilidad en cuanto a tiempo para la entrega del proyecto.
Líder de Proyecto, Analista
11-02-12
Se llegó a la conclusión de que el tiempo no será suficiente para el desarrollo de las aplicaciones móviles para la materia de Estructura de Datos.
Esquema de comunicación con los interesados
Proyecto: Diseño de Objetos de Aprendizaje de M-Learning para la Materia Metodología de la Programación
Versión: 1.0
Cliente: M. en C. Moramay Ramírez Hernández Fecha: 18/02/13
En este documento se debe indicar cómo, cuándo y con quién se maneja la información.
Actividad Responsable por el
cliente
Responsable por
el proyecto Frecuencia Medio / Mecanismos
A quién informar del status del proyecto
M. en C. Moramay
Ramírez Hernández
T.S.U. Lorenzo
Rangel Suárez
Dos veces por
semana
Por mail con formato
de reporte de status
Responsable de validar los
avances
M. en C. Moramay
Ramírez Hernández
T.S.U. Lorenzo
Rangel Suárez
Una vez cada dos
semana
El cliente tiene que
firmar la carta de
aceptación de
avances
Responsable de la
validación y aceptación de
la especificación de
M. en C. Moramay
Ramírez Hernández
T.S.U. Lorenzo
Rangel Suárez
Al término de
cada fase del
proyecto
El cliente debe firmar
el documento de
especificación de
Actividad Responsable por el
cliente
Responsable por
el proyecto Frecuencia Medio / Mecanismos
requisitos requisitos y la carta de
aceptación de
requisitos
Proporcionará información
para la especificación de
requisitos
M. en C. Moramay
Ramírez Hernández
Alumnos de 1er
cuatrimestre de
T.S.U. en TIC’s
T.S.U. Lorenzo
Rangel Suárez
T.S.U. Sarai Cruz
Magadan
Solo cuando sea
necesario
Realizar cuestionarios
a los posibles
usuarios
Medio presencial con
el representante del
cliente
Personal de apoyo
informático
Profesores de la
División de
Informática de la
Universidad
Tecnológica de
Tecámac
T.S.U. Lorenzo
Rangel Suárez
Cuando sea
necesario
Medio presencial
Responsable aprobar la
liberación del producto del
proyecto
M. en C. Moramay
Ramírez Hernández
T.S.U. Lorenzo
Rangel Suárez
Al quedar
satisfecho el
cliente con los
productos y
entregables
El cliente debe firmar
una carta de
aceptación
Actividad Responsable por el
cliente
Responsable por
el proyecto Frecuencia Medio / Mecanismos
Responsable de autorizar
modificaciones (solo una
persona)
M. en C. Moramay
Ramírez Hernández
T.S.U. Lorenzo
Rangel Suárez
Cuando sea
necesario
El cliente debe firmar
una carta de
aceptación de las
modificaciones
realizadas
Responsable de autorizar
Pagos
M. en C. Moramay
Ramírez Hernández
T.S.U. Lorenzo
Rangel Suárez
Periodos de 15
días
Responsable de dar el pago M. en C. Moramay
Ramírez Hernández
Periodos de 15
días
Responsable de validar
arquitectura base
M. en C. Moramay
Ramírez Hernández
T.S.U. Lorenzo
Rangel Suárez
Al término de la
fase de Diseño
El cliente debe firmar
la carta de aceptación
de la arquitectura
base del proyecto
Responsable de validar el
diseño
M. en C. Moramay
Ramírez Hernández
T.S.U. Lorenzo
Rangel Suárez
Antes de
comenzar la fase
de Codificación
El cliente debe firmar
la carta de aceptación
del diseño del
producto
Responsable de las
pruebas de aceptación
M. en C. Moramay
Ramírez Hernández
T.S.U. Lorenzo
Rangel Suárez
Al termino del
proyecto
El cliente debe firmar
la carta de liberación
del proyecto cuando
Actividad Responsable por el
cliente
Responsable por
el proyecto Frecuencia Medio / Mecanismos
éste quede conforme
con el entregable final.
M. en C. Moramay Ramírez Hernández T.S.U. Lorenzo Rangel Suárez
Carta de aceptación de compromisos
Proyecto: Diseño de Objetos de Aprendizaje de M-Learning
para la Materia Metodología de la Programación
Cliente: División de Informática de la Universidad
Tecnológica de Tecámac
Representante del cliente: M. en C. Moramay Ramírez Hernández
Responsable del proyecto: T.S.U. Lorenzo Rangel Suárez
Fecha: 09-01-13
Clave del plan de trabajo : CAC-01
Hitos de referencia
Compromiso Responsable Fecha Implicaciones
(si no se cumple)
Programar 9 aplicaciones móviles con el contenido temático de la materia Metodología de la Programación
Diseñador Programador
17-04-13 Si no se cumple ya sea con el número de aplicaciones requeridas o con la fecha de entrega, el sueldo de los responsables reducirá proporcionalmente según los días de retraso o el número de aplicaciones faltantes.
Realizar un sitio web para alojar los objetos de aprendizaje
Analista
Diseñador
07-08-13 Si no se entrega en la fecha especificada el costo total del
Programador proyecto acordado disminuirá por incumplimiento.
El sitio web deberá estar alojado en un servidor para la utilización del mismo.
Programador 14-08-13
Se deberá proporcionar un manual técnico al momento de la entrega del proyecto
Analista 14-08-13 Se dará un plazo máximo de 5 días hábiles después de la fecha acordada para la entrega del manual, por cada día se descontará un 2% al costo total del proyecto
Se deberá proporcionar un manual de usuario al momento de la entrega del proyecto
Analista 14-08-13 Se dará un plazo máximo de 5 días hábiles después de la fecha acordada para la entrega del manual, por cada día se descontará un 2% al costo total del proyecto
Observaciones del cliente
M. en C. Moramay Ramírez Hernández T.S.U. Lorenzo Rangel Suárez
Cliente Gerente de proyecto
Calendario de reuniones programadas de verificación del estado del
proyecto
Nombre del proyecto: Diseño de objetos de aprendizaje de M-Learning para la materia Metodología de la Programación
Preparado por: TSU Eduardo Robles López
Fecha: 15/Feb/13
Gerente del proyecto: TSU Lorenzo Rangel Suarez
Líder de comunicación del proyecto: TSU Lorenzo Rangel Suarez
Grupo interesado(stakeholder)
Fechas propuestas o programadas de reuniones
Tópicos a revisar en la agenda del día
M. en C. Moramay Ramírez Hernández
TSU Lorenzo Rangel Suarez
10/DICIEMBRE/12
1. Tratar asuntos del proyecto que se está realizando.
2. Llenar formatos faltantes.
3. Corroborar que la elaboración de las aplicaciones móviles vaya en tiempo y forma.
M. en C. Moramay Ramírez Hernández
TSU Lorenzo Rangel Suarez
TSU Sarai Cruz Magadan
TSU Eduardo Robles López
15/FEBRERO/13
1. Tratar asuntos del proyecto que se está realizando.
2. Mostrar el primer entregable (aplicaciones móviles) al cliente.
3. Empezar a planear la creación del sitio web de contenidos.
M. en C. Moramay Ramírez Hernández
TSU Jesús Eduardo Flores López
TSU Eduardo Robles López
25/ABRIL/13
1. Mostar avance del sitio web al cliente para ver si todo va como él lo requiere.
2. Especificar por escrito los cambios(si hay) que se realizaran
M. en C. Moramay Ramírez Hernández
TSU Jesús Eduardo Flores López
3/JUNIO/13
1. Entregar segunda versión del sitio web al cliente.
2. Realizar la documentación necesaria.
M. en C. Moramay
Ramírez Hernández
TSU Eduardo Robles López
13/AGOSTO/13 1. Entrega del sitio web
M. en C. Moramay Ramírez Hernández
TSU Lorenzo Rangel Suarez
TSU Sarai Cruz Magadan
TSU Jesús Eduardo Flores López
TSU Eduardo Robles López
22/NOVIEMBRE/13
1. Entrega final del proyecto la cual contiene:
Aplicaciones móviles
Sitio web de contenidos
Manual técnico
Manual de usuario
Carta de aceptación de capacitación
Proyecto: Diseño de objetos de aprendizaje de M-Learning para la
materia Metodología de la Programación
Cliente: Universidad Tecnológica de Tecamac
Representante del cliente: M. en c. Moramay Ramírez Hernández
Representante del equipo: T.S.U. Lorenzo Rangel Suárez
Fecha: 15/02/13
Por medio de la presente confirmo que se impartió la capacitación del sistema
“Desarrollo de Android” en la Universidad Tecnológica de Tecamac.
La persona que tomo la capacitación fue:
Lorenzo Rangel Suárez (Líder de proyecto)
Las fechas y horarios del curso fueron:
Fecha de Inicio 7 de Enero de 2013
Fecha de termino 15 de Febrero de 2013
Horario De 9:00 am a 1:00 pm
El instructor del curso fue, M en C. Andrés Ramírez Santos
Los cursos que se impartieron fueron:
Curso de programación orientado a las aplicaciones móviles sobre el sistema operativo
Android.
M. en c. Moramay Ramírez Hernández T.S.U Lorenzo Rangel
Suárez
Cliente Representante del Equipo
13. Riesgos
Posibles problemas que se pueden presentar en el proyecto y el
impacto que tendrán en el mismo.
La siguiente tabla muestra los riesgos identificados en el desarrollo del sistema.
ID Riesgo
Ri-1 No se tienen todos los requisitos del proyecto.
Ri-2 El cliente no está conforme con el alcance del proyecto.
Ri-3 No se tienen toda la documentación necesaria para realizar el análisis de información.
Ri-4 El equipo de cómputo falla o no funciona.
Ri-5 Se daña el archivo de la documentación que se había recabado.
Ri-6 Falla la electricidad mientras se realizar alguna actividad.
Ri-7 El diseño realizado no es del agrado del cliente.
Ri-8 Se extravía el diseño realizado.
Ri-9 Los avances presentados no satisfacen las necesidades del cliente.
Ri-10 El equipo de trabajo carece de conocimientos.
Ri-11 El líder carece de autoridad ante el equipo.
Ri-12 El gestor de base de datos falla.
Ri-13 El programador se enferma durante el proceso de la actividad.
Ri-14 Retraso de tiempo en el proyecto.
Ri-15 No se cuenta con el software o hardware necesario para realizar las pruebas.
Ri-16 Crisis económica.
Análisis cualitativo
CONTROL DE VERSIONES
VERSIÓN HECHA POR REVISADO POR
APROBADO POR
FECHA MOTIVO
1.0 Sarai Cruz Magadan
Jesús E. Flores López
Lorenzo Rangel Suárez
01/03/2013 Análisis cualitativo de
riesgos
NOMBRE DEL PROYECTO SIGLAS DEL PROYECTO
Diseño de Objetos de Aprendizaje de M-Learning para la Materia Metodología de la
Programación DOAMMP
Probabilidad de ocurrencia
ID Riesgo 1 2 3 4 5 Impacto
Ri-1 No se tienen todos los requisitos del proyecto.
4
Ri-2 El cliente no está conforme con el alcance del proyecto.
5
Ri-3 No se tienen toda la documentación necesaria para realizar el análisis de información.
4
Ri-4 El equipo de cómputo falla o no funciona. 2
Ri-5 Se daña el archivo de la documentación que se había recabado.
5
Ri-6 Falla la electricidad mientras se realizar alguna actividad. 3
Ri-7 El diseño realizado no es del agrado del cliente.
4
Ri-8 Se extravía el diseño realizado. 3
Ri-9 Los avances presentados no satisfacen las necesidades del cliente.
5
Ri-10 El equipo de trabajo carece de conocimientos. 4
Ri-11 El líder carece de autoridad ante el equipo. 3
Ri-12 El gestor de base de datos falla. 3
Ri-13 El programador se enferma durante el proceso de la actividad. 1
Ri-14 Retraso de tiempo en el proyecto. 5
Ri-15 No se cuenta con el software o hardware necesario para realizar las pruebas.
2
Ri-16 Crisis económica. 4
Impacto Valor
Numérico
Muy bajo 1
Bajo 2
Moderado 3
Alto 4
Muy alto 5
Probabilidad Valor
Numérico
Muy improbable 1
Relativamente probable
2
Probable 3
Muy probable 4
Casi certeza 5
MATRIZ DE RIESGOS
CONTROL DE VERSIONES
VERSIÓN HECHA POR REVISADO POR
APROBADO POR
FECHA MOTIVO
1.0 Sarai Cruz Magadan
Jesús E. Flores López
Lorenzo Rangel Suárez
04/03/2013 Matriz de riesgos
NOMBRE DEL PROYECTO SIGLAS DEL PROYECTO
Diseño de Objetos de Aprendizaje de M-Learning para la Materia Metodología de la Programación
DOAMMP
PR
OB
AB
ILID
AD
5 10 15 20 25
4 8 12 16 20
3 6 9 12 15
2 4 6 8 10
1 2 3 4 5
IMPACTO
Impacto Valor
Numérico
Muy bajo 1
Bajo 2
Moderado 3
Alto 4
Muy alto 5
Probabilidad Valor
Numérico
Muy improbable 1
Relativamente probable
2
Probable 3
Muy probable 4
Casi certeza 5
Análisis cuantitativo
CONTROL DE VERSIONES
VERSIÓN HECHA POR REVISADO POR
APROBADO POR
FECHA MOTIVO
1.0 Sarai Cruz Magadan
Jesús E. Flores López
Lorenzo Rangel Suárez
11/02/2013 Riesgos del proyecto
LISTA DE RIESGOS
Id Riesgo Contingencia Presupuesto
Ri-1 No se tienen todos los requisitos del proyecto.
Se convoca a una reunión con todos los involucrados en la actividad para realizarla.
Ri-3 El cliente no está conforme con el alcance del proyecto.
Se convoca a una reunión entre el cliente y el equipo de trabajo para poder llegar a un acuerdo.
Ri-4 No se tienen toda la documentación necesaria para realizar el análisis de información.
Se pide al responsable que complete la información necesaria para realizar el análisis.
Ri-5 El equipo de cómputo falla o no funciona.
Se tendrá un equipo de cómputo de reserva.
$ 5,000
Ri-6 Se daña el archivo de la documentación que se había recabado.
Respaldar el archivo cada que se realicen cambios en el mismo.
Ri-8 Falla la electricidad mientras se realizar alguna actividad.
Se contara con un No Break de 30 min para guardar o seguir realizando la actividad.
$ 1,000
Ri-9 El diseño realizado no es del agrado del cliente.
Se realizaran las modificaciones requeridas.
Ri-10
Se extravía el diseño realizado. Se contara con un respaldo del diseño en todas las computadoras utilizadas para el desarrollo del proyecto.
Ri-11
Los avances presentados no satisfacen las necesidades del cliente.
Se convoca a una reunión con todos los involucrados en la actividad para modificaciones.
Ri-12
El equipo de trabajo carece de conocimientos.
Se capacitará de inmediato. $ 10, 000
NOMBRE DEL PROYECTO SIGLAS DEL PROYECTO
Diseño de Objetos de Aprendizaje de M-Learning para la Materia Metodología de la
Programación DOAMMP
Ri-13
El líder carece de autoridad ante el equipo.
Se capacitará o se revocará del cargo asignando a otro miembro del equipo de trabajo que cumpla con el perfil requerido.
$ 3, 000
Ri-14
El gestor de base de datos falla. Se contara con otra máquina con el gestor listo para su utilización.
Ri-15
El programador se enferma durante el proceso de la actividad.
El miembro del equipo que esté capacitado tomará el rol de programador.
Ri-16
Retraso de tiempo en el proyecto. Realizar una buena planeación para no poner en riesgo la entrega del proyecto.
Ri-17
No se cuenta con el software o hardware necesario para realizar las pruebas.
Especificar todos los recursos que se necesitan para llevar a cabo las pruebas tanto en el manual de usuario, así como en el manual técnico.
Total $ 19, 000
Plan de respuesta del problema
Plan de Manejo de Riesgos
Introducción
Propósito
Este documento tiene como objetivo controlar los riesgos que se puedan presentar
en el desarrollo del sistema para poder contrarrestar cada una de estas situaciones y
prevenir algún retraso en la entrega del sistema.
Alcance
En este, se identificarán los riesgos y la solución para cada uno de ellos clasificando
los riesgos dependiendo del nivel que cada uno presente en el desarrollo de este
proyecto.
Definiciones, acrónimos y abreviaciones.
BD: Base de Datos
Referencias
Título Fecha Organización
Registro de Riesgos 04/03/2013
Diseño de objetos de aprendizaje de M-Learning para la materia Metodología de la Programación
Análisis Cualitativo 11/03/2013
Diseño de objetos de aprendizaje de M-Learning para la materia Metodología de la Programación
Análisis del riesgo
La siguiente tabla muestra el nivel de probabilidad de los riesgos y la descripción de
cada valor para facilitar la identificación de cada uno de los riesgos.
A continuación la tabla presentada muestra la descripción del valor del impacto que podrá tener cada uno de los riesgos del sistema.
Impacto Valor Numérico
Descripción
Muy bajo 1 Impacto insignificante para el proyecto, no es posible determinar la magnitud del mismo en el este por lo pequeño que este resulta.
Bajo 2 El Impacto que tendrá en el proyecto no es mucho, es decir, será como un 7% más de los recursos de lo ya planeado en el área que se encontró el riesgo.
Moderado 3 El impacto que tiene en el proyecto es notable, puede ocupar un 20% más de los recursos de lo ya planeado en el área que se encontró el riesgo.
Alto 4 El impacto en el proyecto es alto, puede ocupar el 30% o 40% más de los recursos ya planeados para el área donde se encontró el riesgo.
Muy alto 5 El impacto en el proyecto ya es más de la mitad de los recursos ya planeados para el área donde se encontró el riesgo.
Determinación del nivel del riesgo
La siguiente tabla muestra el identificador de cada uno de los riesgos relacionados con
su probabilidad y el impacto que cada uno tiene en este proyecto.
Probabilidad Valor Numérico
Descripción
Muy improbable 1 Riesgo altamente probable para ocurrir. Tiene la posibilidad más alta de ocurrir, entre 80% y 100%.
Relativamente probable
2 Riesgo altamente probable para ocurrir. Tiene una posibilidad más antes de ocurrir, entre 60% y 80%.
Probable 3 Riesgo medianamente probable para ocurrir. Tiene una posibilidad mediana de ocurrir, entre 40 % y 60%.
Muy probable 4 Riesgo poco probable para ocurrir. Tiene una posibilidad baja de que ocurra el Riesgo, entre 10% y 40%.
Casi certeza 5 Riesgo muy poco probable para ocurrir. La posibilidad de que ocurra este Riesgo y el impacto en el proyecto es casi o totalmente nula.
Plan de Contención del Riesgo
A continuación se muestra las actividades que se deben realizar para evitar los riesgos
del sistema.
Probabilidad de ocurrencia
ID 1 2 3 4 5 Impacto
Ri-1 4
Ri-2 5
Ri-3 4
Ri-4 2
Ri-5 5
Ri-6 3
Ri-7 4
Ri-8 3
Ri-9 5
Ri-10 4
Ri-11 3
Ri-12 3
Ri-13 1
Ri-14 5
Ri-15 2
Ri-16 4
ID Riesgo Contención
Ri-1 No se tienen todos los requisitos del proyecto.
Realizar un Juicio de expertos
Ri-2 El cliente no está conforme con el alcance del proyecto.
Realizar un contrato
Ri-3 No se tienen toda la documentación necesaria para realizar el análisis de información.
Realizar un Juicio de expertos
Ri-4 El equipo de cómputo falla o no funciona.
Tener equipos de respaldo
Ri-5 Se daña el archivo de la documentación que se había recabado.
Realizar respaldo de información
Ri-6 Falla la electricidad mientras se realiza alguna actividad.
Tener una planta de luz
Ri-7 El diseño realizado no es del agrado del cliente.
Realizar un contrato
Ri-8 Se extravía el diseño realizado. Realizar respaldo de información
Ri-9 Los avances presentados no satisfacen las necesidades del cliente.
Realizar un contrato
Ri-10 El equipo de trabajo carece de conocimientos.
Capacitar al personal
Ri-11 El líder carece de autoridad ante el equipo.
Capacitar al personal
Ri-12 El gestor de base de datos falla. Realizar respaldo de información
Tener otro equipo de cómputo listo para trabajar sobre el proyecto
Ri-13 El programador se enferma durante el proceso de la actividad.
Capacitar al personal
Estar en contacto con algún otro desarrollador
Ri-14 Retraso de tiempo en el proyecto.
Hacer una ruta crítica para administrar que se hará cada día.
Realizar revisiones del cumplimiento de la ruta critica
Ri-15 No se cuenta con el software o hardware necesario para realizar las pruebas.
Tener equipos de respaldo
Hacer un plan de requisitos para realizar el sistema.
Ri-16 Crisis económica. Realizar un análisis financiero.
Plan de Contingencia del Riesgo
En la tabla siguiente se muestran las acciones a realizar si ocurre el riesgo identificado.
ID Riesgo Contención
Ri-1 No se tienen todos los requisitos del proyecto.
Realizar entrevistas o encuestas para recabar la información
Ri-2 El cliente no está conforme con el alcance del proyecto.
Mostrar el cumplimiento de los requisitos mostrados en el contrato.
Llegar a un nuevo acuerdo
Ri-3 No se tienen toda la documentación necesaria para realizar el análisis de información.
Realizar entrevistas o encuestas para recabar la información
Ri-4 El equipo de cómputo falla o no funciona.
Utilizar un equipo de cómputo que funcione correctamente.
Ri-5 Se daña el archivo de la documentación que se había recabado.
Se busca el último respaldo realizado para poder continuar con la documentación del proyecto.
Ri-6 Falla la electricidad mientras se realiza alguna actividad.
Se utiliza la planta de luz para poder continuar con la actividad.
Ri-7 El diseño realizado no es del agrado del cliente.
Mostrar el cumplimiento de los requisitos mostrados en el contrato.
Llegar a un nuevo acuerdo
Ri-8 Se extravía el diseño realizado. Utilizar el último respaldo que se utilizó
para continuar con el diseño del proyecto.
Ri-9 Los avances presentados no satisfacen las necesidades del cliente.
Mostrar el cumplimiento de los requisitos mostrados en el contrato.
Llegar a un nuevo acuerdo
Ri-10 El equipo de trabajo carece de conocimientos.
Se tomarán cursos de capacitación en el área que el equipo de trabajo lo requiera.
Ri-11 El líder carece de autoridad ante el equipo.
El líder de proyecto tomará cursos para aprender o reforzar sus habilidades de liderazgo.
Ri-12 El gestor de base de datos falla. Importar la BD a otro equipo de
cómputo.
Ri-13 El programador se enferma durante el proceso de la actividad.
Asignar las actividades a otro integrante del equipo de trabajo.
Ri-14 Retraso de tiempo en el proyecto.
Se modificará el cronograma del proyecto de tal forma en que se pueda recuperar el mayor tiempo posible y evitar más demora.
Ri-15 No se cuenta con el software o hardware necesario para realizar las pruebas.
Se comprarán o descargarán las herramientas necesarias para poder realizar esta actividad.
Ri-16 Crisis económica. Utilizar el capital asignado como análisis
de reserva si es que se requiere.
Riesgo Descripción del riesgo Fecha Posibles
Consecuencias
Probabilida
d Impacto Responsable
1
No se tienen todos los
requisitos del proyecto. 03/12/12 Retraso en la
entrega del proyecto 2 4
Sarai Cruz Magadan
2
El cliente no está conforme
con el alcance del proyecto. 20/11/12 Conflictos con el
contrato 3 5
Lorenzo Rangel Suárez
3
No se tienen toda la
documentación necesaria para
realizar el análisis de
información.
01/10/12 Retraso en la
entrega del proyecto 2 4
Sarai Cruz Magadan
4
El equipo de cómputo falla o
no funciona. 22/11/12 Retraso en la
entrega del proyecto 1 2
Lorenzo Rangel Suárez
5
Se daña el archivo de la
documentación que se había
recabado. 30/11/12
Retraso en la entrega del proyecto
1 5 Sarai Cruz Magadan
6
Falla la electricidad mientras
se realizar alguna actividad. 06/12/12 Retraso en la
entrega del proyecto 1 3
Lorenzo Rangel Suárez
7
El diseño realizado no es del
agrado del cliente. 10/01/13 Conflictos con el
contrato 3 4
Eduardo Robles López
8
Se extravía el diseño
realizado. 17/01/13 Conflictos con el
contrato 1 3
Eduardo Robles López
9
Los avances presentados no
satisfacen las necesidades del
cliente. 04/02/13
Conflictos con el contrato
1 5 Jesús Flores
López
10
El equipo de trabajo carece de
conocimientos. 27/09/12 Retraso en la
entrega del proyecto 1 4
Lorenzo Rangel Suárez
11
El líder carece de autoridad
ante el equipo. 20/09/12 Retraso en la
entrega del proyecto 1 3
Jesús Flores López
12
El gestor de base de datos
falla. 01/03/13 Retraso en la
entrega del proyecto 2 3
Eduardo Robles López
13
El programador se enferma
durante el proceso de la
actividad. 01/01/13
Retraso en la entrega del proyecto
1 1 Lorenzo Rangel
Suárez
14
Retraso de tiempo en el
proyecto. 15/03/13 Conflictos con el
contrato 3 5
Jesús Flores López
15
No se cuenta con el software o
hardware necesario para
realizar las pruebas. 15/03/13
Retraso en la entrega del proyecto
1 2 Jesús Flores
López
16 Crisis económica.
01/03/13 Retraso en la
entrega del proyecto 3 4
Lorenzo Rangel Suárez
14. Procuramiento
Requerimientos del proyecto a ser solicitados a
proveedores, los tiempos y formas en que estos deben ser
entregados.
CONTROL DE VERSIONES
VERSIÓN HECHA POR
REVISADO POR
APROBADO POR
FECHA MOTIVO
1.0 Sarai Cruz Magadan
Jesús E. Flores López
Lorenzo Rangel Suárez
12/04/2013 Requerimientos del
proyecto
NOMBRE DEL PROYECTO SIGLAS DEL PROYECTO
Diseño de Objetos de Aprendizaje de M-Learning para la Materia Metodología de la
Programación DOAMMP
Adquisiciones del proyecto
Matriz de las adquisiciones del proyecto
Procedimientos estándar a seguir
Para los contratos de adquisición del materiales se realiza el siguiente proceso:
Se comunica al patrocinador sobre los materiales requeridos
Se realiza una lista de posibles proveedores
Al ser atendidos por los proveedores, se revisan las cotizaciones de éstos
Se realiza la negociación con el mejor proveedor
Se firma el contrato
Fecha de firma de contrato
Contrato de material de oficina que contiene los siguientes artículos:
4 Escritorios ejecutivos
4 Sillas secretariales
1 Paquete de hojas
1 Caja de lápices
1 Caja de bolígrafos Será firmado el día 18 de abril del 2013 Contrato para material tecnológico que contiene los siguientes artículos:
4 Laptop
1 Tableta electrónica Será firmado el día 25 de abril del 2013
Fecha de recepción de los materiales
Para la recepción del material requerido en los contratos se especificarán 3 días hábiles, es
decir, para el contrato de materiales de oficina la fecha de recepción es el 23 de abril del
2013.
Para los materiales tecnológicos la fecha es el 30 de abril del 2013.
Se especifica que en el caso del primer contrato los materiales se recibirán en una dirección
especificada en dicho contrato. En el caso del segundo contrato nosotros, la empresa cliente
iremos por los artículos solicitados.
Propuestas de cotización y/o licitación
SOLICITUD DE COTIZACIÓN
Diseño de Objetos de Aprendizaje de M-Learning para la Materia Metodología de la
Programación
Para: Office Depot de México, S.A. de
C.V.
Av. Revolución, S/N, San Cristóbal
Centro, EDO. De México
Fecha: 12 de abril de 2013
Item
N°
Breve descripción Cantidad
1 Escritorio ejecutivo, madera, cuatro cajones 4
2 Sillas secretariales, ergonómica con apoya brazos 4
3 Paquete de 500 hojas blancas tamaño carta 1
4 Caja de lápices # 2 1
5 Caja de bolígrafos tinta negra punto fino 1
Validez mínima de la oferta: 5 días 10 días 15 días
Términos de adquisición: Tienda Otro ________
Lugar de entrega de los bienes: UTTEC Carretera México - Pachuca Km37.5, Sierra
Hermosa, 55740 Tecámac, Estado de México
Forma de pago: El 100% del precio será cubierto 2 días después de
recibir a entera satisfacción la totalidad de los bienes.
Facturas emitidas a nombre de: T.S.U Lorenzo
Rangel Suárez
Plazo de la entrega de los bienes: 3 días hábiles
Lugar para presentación de ofertas: UTTEC Carretera México - Pachuca Km37.5, Sierra
Hermosa, 55740 Tecámac, Estado de México
Fecha para presentación de ofertas: Martes 16 de abril de 2013, 13:00 horas.
SOLICITUD DE COTIZACIÓN
Diseño de Objetos de Aprendizaje de M-Learning para la Materia Metodología de la
Programación
Para: OfficeMax®
Carretera Fed. México-Pachuca
Km.36.5, Col. Hueyotenco,
CP.55740
Fecha: 12 de abril de 2013
Item
N°
Breve descripción Cantidad
1 Escritorio ejecutivo, madera, cuatro cajones 4
2 Sillas secretariales, ergonómica con apoya brazos 4
3 Paquete de 500 hojas blancas tamaño carta 1
4 Caja de lápices # 2 1
5 Caja de bolígrafos tinta negra punto fino 1
Validez mínima de la oferta: 5 días 10 días 15 días
Términos de adquisición: Tienda Otro ________
Lugar de entrega de los bienes: UTTEC Carretera México - Pachuca Km37.5, Sierra
Hermosa, 55740 Tecámac, Estado de México
Forma de pago: El 100% del precio será cubierto 2 días después de
recibir a entera satisfacción la totalidad de los bienes.
Facturas emitidas a nombre de: T.S.U Lorenzo
Rangel Suárez
Plazo de la entrega de los bienes: 3 días hábiles
Lugar para presentación de ofertas: UTTEC Carretera México - Pachuca Km37.5, Sierra
Hermosa, 55740 Tecámac, Estado de México
Fecha para presentación de ofertas: Miércoles 17 de abril de 2013, 12:00 horas.
SOLICITUD DE COTIZACIÓN
Diseño de Objetos de Aprendizaje de M-Learning para la Materia Metodología de la
Programación
Para: OfficeMax®
Carretera Fed. México-Pachuca
Km.36.5, Col. Hueyotenco,
CP.55740
Fecha: 12 de abril de 2013
Item
N°
Breve descripción Cantidad
1 Laptop Compaq Presario CQ43 4
2 Tablet con SO Android 4.0 1
Validez mínima de la oferta: 5 días 10 días 15 días
Términos de adquisición: Tienda Otro ________
Lugar de entrega de los bienes: UTTEC Carretera México - Pachuca Km37.5, Sierra
Hermosa, 55740 Tecámac, Estado de México
Forma de pago: El 100% del precio será cubierto 2 días después de
recibir a entera satisfacción la totalidad de los bienes.
Facturas emitidas a nombre de: T.S.U Lorenzo
Rangel Suárez
Plazo de la entrega de los bienes: 3 días hábiles
Lugar para presentación de ofertas: UTTEC Carretera México - Pachuca Km37.5, Sierra
Hermosa, 55740 Tecámac, Estado de México
Fecha para presentación de ofertas: Martes 16 de abril de 2013, 15:00 horas.
SOLICITUD DE COTIZACIÓN
Diseño de Objetos de Aprendizaje de M-Learning para la Materia Metodología de la
Programación
Para: Office Depot de México, S.A. de
C.V.
Av. Revolución, S/N, San Cristóbal
Centro, EDO. De México
Fecha: 12 de abril de 2013
Item
N°
Breve descripción Cantidad
1 Laptop Compaq Presario CQ43 4
2 Tablet con SO Android 4.0 1
Validez mínima de la oferta: 5 días 10 días 15 días
Términos de adquisición: Tienda Otro ________
Lugar de entrega de los bienes: UTTEC Carretera México - Pachuca Km37.5, Sierra
Hermosa, 55740 Tecámac, Estado de México
Forma de pago: El 100% del precio será cubierto 2 días después de
recibir a entera satisfacción la totalidad de los bienes.
Facturas emitidas a nombre de: T.S.U Lorenzo
Rangel Suárez
Plazo de la entrega de los bienes: 3 días hábiles
Lugar para presentación de ofertas: UTTEC Carretera México - Pachuca Km37.5, Sierra
Hermosa, 55740 Tecámac, Estado de México
Fecha para presentación de ofertas: Miércoles 17 de abril de 2013, 15:00 horas.
15. Control y seguimiento del proyecto
Este es realizado con el fin de asegurar que el equipo de desarrollo cumple
satisfactoriamente con las metas del plan de proyecto. A continuación se muestran
las actividades a realizar en esta fase.
Tareas
o Seguir y revisar los resultados y logros del proyecto
o Revisar el plan de proyecto para reflejar los resultados obtenidos y ajustar
las tareas restantes
o Analizar el progreso en el ejecución del plan
o Tomar acciones correctivas en caso de desvíos
o Fijar nuevas metas
Entregables
o Reportes de avance o estado actual
o Actualizar las listas de tareas, riesgos y problemas
o Actualizar el plan y el cronograma, a fin de reflejar los avances
o Auditoria y reporte de los ítems en desarrollo
Formas de control
o Control de performance: recolectar y distribuir información de
performance incluyendo estado del proyecto, reportes de avance,
presupuestos de estado y avance.
o Control de tiempo: definición, secuencia, estimación, programación y
control de calendario.
o Control de costos: planificación de recursos y estimación de costos.
16. Documentación técnica del proyecto
Modelos del sistema
Estructura del sistema
Un caso de uso es una descripción de los pasos o las actividades que deberán
realizarse para llevar a cabo algún proceso. Los diagramas de casos de uso sirven
para especificar la comunicación y el comportamiento de un sistema mediante su
interacción con los usuarios y/u otros sistemas.
El caso de uso resultante del sistema es:
Figura 16.1 Caso de uso general.
Diagrama de Clases
En este proyecto no se cuenta con una base de datos por lo cual no se puede
realizar un diagrama de clases.
Alumno
AdministradorInstalar aplicación
Ejecutar aplicación
Contestar test
Consultar resultados
Salir de la aplicación
Descargar Aplicaciónes
Subir aplicaciones
Gestionar contenidos
Consultar contenidos
Repetir test
Diagrama de actividades
Representa los flujos de trabajo paso a paso de negocio y operacionales de los
componentes en un sistema. Un Diagrama de Actividades muestra el flujo de
control general. El siguiente diagrama contiene las actividades que se realizan
durante todo el proceso.
Figura 16.2 Diagrama de actividades.
Gestionar contenidos
Subir aplicaciones
[Administrador] [Alumno]
Consultar contenidos
Descargar aplicaciones
Utilizar las aplicaciones
Diagrama de estados
Los diagramas de estado muestran el conjunto de estados por los cuales pasa un
objeto durante su vida en una aplicación en respuesta a eventos (por ejemplo,
mensajes recibidos, tiempo rebasado o errores), junto con sus respuestas y
acciones. También ilustran qué eventos pueden cambiar el estado de los objetos
de la clase. El diagrama siguiente corresponde a las aplicaciones:
Figura 16.3 Diagrama de estados.
Diagrama de secuencia
Un diagrama de secuencia muestra la interacción de un conjunto de objetos en
una aplicación a través del tiempo y se modela para cada caso de uso. A
continuación se muestran los diagramas de secuencia del sistema:
a) Sitio Web
Subir aplicaciones
Ingresando
Resolviendo
entry/Leer instruccionesdo/Contestar preguntasexit/Resultado
Cancelada
Evaluando
Aplicaciones
Anulada
Figura 16.4 Subir aplicaciones
Gestionar contenidos
Figura 16.5 Gestionar contenidos.
Sitio ServidorXML
: Administrador
1 : Ingresar al sitio()
2 : Mostrar pantalla login()
3 : Insertar datos()4 : Confirmar datos()
5 : Mostrar index()
6 : Subir aplicaciones()
: Administrador
Sitio XLML
1 : Ingresar al sitio()
2 : Mostrar pantalla login()
3 : Introducir datos() 4 : Confirmar datos()
5 : Mostrar index()
6 : Gestionar contenidos()
b) Aplicaciones móviles
Consultar contenidos, descarga e instalación de aplicaciones
Figura 16.6 Aplicaciones móviles.
Implementación del sistema
Diagrama de componentes
Representan todos los tipos de elementos de software que entran en la fabricación
del sistema.
Dentro de estos diagramas existen diferentes tipos, pero el que se implementa en
este sistema es el diagrama de despliegue.
: Alumno
SitioMovilServidor
1 : Ingresar al sitio()
2 : Muestra el menu()
3 : Consulta contenidos()
4 : Descarga aplicaciones()
5 : Muestra los ejecutables()
6 : Copia ejecutables()
7 : Instala aplicación()
8 : Utiliza aplicación()
Figura 16.7 Diagrama de componentes (despliegue).
Diagrama de paquetes
Dentro de nuestro sistema no se manejan diagramas de paquetes debido a la falta
de base de datos en este.
17. Documento de cierre
Checklist
La siguiente tabla muestra las actividades que se realizaron en el
desarrollo del sistema, marcando el estado en el que se encuentran
por lo que las actividades se han terminado satisfactoriamente.
Actividad Estado
Investigación sobre los objetos de aprendizaje y M-
Learning TERMINADA
Investigación preliminar TERMINADA
Análisis de la tecnología Java Micro Edition TERMINADA
Análisis del ciclo de vida clásico de Pressman TERMINADA
Formulación TERMINADA
EDT TERMINADA
Diagrama de Gantt TERMINADA
Ruta critica TERMINADA
Informe de presupuesto y evaluación de alternativas TERMINADA
Recursos humanos TERMINADA
Descripción de la problemática TERMINADA
Objetivos TERMINADA
Alcance del sistema TERMINADA
Requisitos funcionales y no funcionales TERMINADA
Comunicación con el cliente TERMINADA
Diseño TERMINADA
Esquema del ciclo de vida TERMINADA
Diagramas del sistema TERMINADA
Implantación TERMINADA
Procuramiento TERMINADA
Pruebas TERMINADA
Riesgos TERMINADA
Análisis cualitativo TERMINADA
Análisis cuantitativo TERMINADA
Plan de respuesta de los riesgos TERMINADA
Estándares de calidad TERMINADA
Control de Calidad TERMINADA
Elementos clave para su planeación, monitoreo y
control. TERMINADA
Instalación (puesta en operación) TERMINADA
Control y seguimiento del proyecto TERMINADA
Documentación técnica del proyecto TERMINADA
Documento de cierre. TERMINADA
Carta de cierre.
Carta de liberación
Proyecto Diseño de objetos de aprendizaje de M-Learning para
la materia Metodología de la Programación
Cliente Universidad Tecnológica de Tecámac
Representante del Cliente M. en C. Moramay Ramírez Hernández
Representante de Sistemas TSU Lorenzo Rangel Suarez
Fecha 13/DIC/13
Por medio de la presente le informo que el día de hoy liberamos de manera
definitiva [Nombre del producto]. Esta entrega se hace conforme las
especificaciones establecidas en la especificación de requerimientos, las
especificaciones de casos de uso y las modificaciones negociadas a lo largo del
desarrollo.
La fase de transición/liberación se ha llevado a cabo. Los usuarios ya se
capacitaron, y la aplicación ya está instalada y en producción. El período de
pruebas con el usuario se llevó a cabo de [fecha inicio] a [fecha final], se nos
reportaron errores los cuales ya han sido corregidos y vueltos a probar. Adjunto a
esta carta, entregamos un CD que contiene el código fuente y documentación del
sistema.
A continuación se listan todos los entregables comprometidos en el contrato (o
propuesta) junto con una descripción.
Manual de Usuario: En este documento se explica el modo de utilizar el sistema. La última versión se encuentra en el CD titulado " Diseño de objetos de aprendizaje de M-Learning para la materia Metodología de la Programación v1.0" en el directorio \documentación\manuales\M-Learning.doc
Capacitación a los usuarios: Esta se llevó a cabo en las instalaciones de Universidad Tecnológica de Tecámac. Esta capacitación se impartió en la semana del 25 al 30 de agosto de 2013.
Las facturas que quedan pendientes de pago son las siguientes:
Número de
factura
Concepto Monto Fecha de pago
1 Pago del sistema concluido $47,200.00 16-DIC-13
Le recordamos que a partir de hoy cuentan con una garantía de seis meses contra
toda falla de programación que se detecte en el sistema siempre y cuando se
hayan cubierto todos los pagos pendientes y en caso de que algún tercero
modifique los archivos fuentes, se perderá dicha garantía.
El proceso para hacer efectiva la garantía es el siguiente:
El cliente notificará a Sistemas el error o bug detectado, avalado con una
impresión de la pantalla donde especifique lo ocurrido, proporcionando los detalles
del mismo, localizando el último mensaje de error enviado por el sistema.
Sistemas hará la corrección sobre la última versión de las fuentes que se
encuentren el CD entregado al cliente.
Sistemas entregará el o los archivos corregidos al cliente. El Cliente validará la
corrección del bug. Y firmará carta de aceptación. Sistemas agregará las nuevas
fuentes al CD del Cliente para llevar un control de versiones sobre los cuales se
harán las nuevas correcciones.
En caso de que el bug no sea reproducible de acuerdo a los archivos fuentes
entregados, se cobrará el número de horas empleadas para detectar y corregir el
bug, de acuerdo a la tarifa vigente para un Consultor Externo. Le agradeceríamos
llenara la encuesta de “satisfacción del cliente” que se anexa a este documento
para evaluar nuestro desempeño y poder servirle cada día mejor.
Les agradecemos su preferencia y esperamos servirle pronto en futuros sistemas.
M. en c. Moramay Ramírez Hernández TSU Lorenzo Rangel
Suarez
Cliente Representante del Proyecto
Lecciones aprendidas.
Elaborado por: Sarai Cruz Magadan Fecha: 15/04/13 Nombre del proyecto: Diseño de objetos de aprendizaje de M-Learning para la materia Metodología de la Programación Líder de Proyecto: Lorenzo Rangel Suárez o Se alcanzaron las metas de tiempo y se cumplieron los requerimientos del
alcance del sistema.
o Dentro el desarrollo de la parte documental del sistema se aprendió a
organizar las actividades y realizar trabajo en equipo
o El equipo aprendió a realizar documentos para la comunicación con el
cliente.
o Se obtuvo mayor conocimiento sobre en el desarrollo de aplicaciones
móviles.
o Se aprendió a respetar los tiempos que cada actividad tenia planificada para
poder concluir las actividades a tiempo.
o Se realizó el proyecto con mayor tiempo y en un concepto real.
________________________ Líder del Proyecto
Lorenzo Rangel Suárez