Software HEY

HEY
FINANCIERA INDEPENDIENTE
JIREH
indice
DOCUMENTACIÓN POR
MATERIA
ADMINISTRACIÓN DE
PROYECTOS
INGENIERA EN
SOFTWARE II
INTEGRADORA II
Administración
de proyectos
<HEY>
COMMUNICATIONS MANAGEMENT PLAN
i
Document History
Document Version Control
Version Version Date Summary of Changes Author
Ingreso demedio por la cual se

registra avance de proyecto en
1.0 29/10/18 Cabrera Paulin Miriam
reuniones internas y externas
del proyecto.
ii
Table of Contents
1.0 INTRODUCTION ............................................................................................................. 1

1.1 PROJECT DESCRIPTION .................................................................................................................. 1
1.2 PROJECT BACKGROUND ................................................................................................................ 1
1.3 COMMUNICATION MANAGEMENT PLAN OVERVIEW .................................................................... 1
2.0 STAKEHOLDERS ........................................................................................................... 2
3.0 ROJECT INFORMATION COLLECTION, REPORTING, AND DISTRIBUTION ............. 3
4.0 BITÁCORA DE REGISTRO DE PROFESORES ............................................................. 4
4.1 ALUMNO ........................................................................................................................................ 4
4.2 MATERIA ....................................................................................................................................... 4
4.3 PROFESOR...................................................................................................................................... 4
4.4 GRUPO ........................................................................................................................................... 4
4.5 FECHA ........................................................................................................................................... 4
4.6 DATOS DE REUNIÓN ...................................................................................................................... 4
iii
1.0 INTRODUCTION
1.1 PROJECT DESCRIPTION
El proyecto consiste en la automatización el área de visitas en una Financiera Independiente,
esta lleva a cabo el registro de visitas que tiene agendadas un promotor. El gerente de la
financiera tendrá como rol el administrador el podrá dar de alta a los promotores, dar de alta
centros educativos e ingresar los registros de visitas que tendrá un promotor durante un
periodo. Al igual que el promotor que solo podrá consultar sus visitas realizadas.
1.2 PROJECT BACKGROUND

La necesidad de la financiera de tener un control exacto sobre sus visitas, fue la causa por la
cual se decidió crear el sistema “HEY”. Este estar sujeto a las necesidades que se han
detectado mediante entrevistas y el análisis de equipo de trabajo.
1.3 COMMUNICATION MANAGEMENT PLAN OVERVIEW

La forma de comunicación del desarrollo del sistema es fundamental tanto con los miembros
encargados del desarrollo como el cliente que solicito la creación del sistema.
El medio de comunicación que se utilizará serán reuniones tanto como internas y externas esto
con el fin de mostrar avances del proyecto y los entregables.
Cada reunión interna con los miembros del equipo será para la organización y hacer el reparto
de actividades que realizará cada uno.
Posteriormente se realizarán reuniones con los profesores encargados de revistar y evaluar
cada avance solicitado haciendo las respectivas correcciones y observaciones.
Todo esto se reportará en una minuta de trabajo con la cual se anotará el nombre de los
integrantes, los temas a tratar, registro de actividades entregadas y observaciones esto
acompañado con la firma del profesor como medio de aprobación.
Communications Management Plan <HEY> 1

2.0 STAKEHOLDERS
Stakeholders Necesidades Actividades
 Gerente Tener un control sobre las Registrar los promotores,
visitas que realiza cada
Registrar las visitas .
uno de sus promotores y
una lista sobre el estatus
de cada una de estas.
Registrar a los centros
educativos que se les
realizara las visitas .
 Promotor Realizar las vistas a los Consultar las visitas
centros educativos cambiar el estatus de la
asignados por el visita .
gerenete, cambiar el
estatus de la visita .
 Centro Educativo Podra consultar su visita Consultar su seguimiento
y checar el tiempo que de la visita .
esta tardara , que
promotor se le asigno .

3.0 ROJECT INFORMATION COLLECTION, REPORTING, AND
DISTRIBUTION
La minuta servirá como el medio de almacenamiento por la cual se registrarán las
actividades o tema a tratar en cada una de las reuniones que se tengan con los
profesores asignados para revisión de avance o asesorías.
Ejemplo del formato.

4.0 BITÁCORA DE REGISTRO DE PROFESORES
Romero Martinez Yessica Integradora
4.1 ALUMNO 4.2 MATERIA
Catalina Barbeyto Chalte IC51
4.3 PROFESOR 4.4 GRUPO
19/10/2018
4.5 FECHA
Motivo Acuerdo Asistente
Recordatorio de las Tareas Realización Diagramas de Gantt Equipo Jireh

Asignadas en la semana con el profesor Mexica
Realizar Dialogo Expresión Oral y
Escrita
4.6 DATOS DE REUNIÓN
Observaciones de Reunión
____________________________ ____________________________
Firma del Profesor Firma de Alumno

Control de Presupuesto
Proyecto HEY
Comprobante Descripción Importe Fecha Folio

1 Papelería (paquete de 500 hojas 126 23/10/2018 1336
vangogh,plumines,plumas)
2 Papelería(paquete de folders, 24/10/2018 100

tóner color B/N)
3 Papelería ( papel opalina ,marca 183.80 26/10/2018 1771

textos plumines)
4 papelería(hojas negras, 54.10 26/10/2018 1772

engrapadora)
Confidential ©JIREH, 2018 Page 1 of 4

Comprobantes
Notas de Remision

Planeación de Proyecto Financiera
Comienzo: lun 01/10/18 Identificador: 1
Fin: vie 23/11/18 Dur: 40 días
RE:
Determinar Problematica
Fin: lun 03/09/18 Dur: 1 día
RE:
Página 1
Asiganaacion de Roles
Fin: mar 30/10/18 Dur: 2 días
RE:
Página 2
Creacion de Bitacora de segumiento
Comienzo: mar 30/10/18 Identificador: 4
Fin: mié 31/10/18 Dur: 2 días
RE:
Página 3
Redactar Problem Statemenet
Comienzo: mié 31/10/18 Identificador: 5
Fin: jue 01/11/18 Dur: 2 días
RE:
Página 4
Levantar Requerimientos
Comienzo: jue 01/11/18 Identificador: 6
Fin: jue 01/11/18 Dur: 1 día
RE:
Página 5
Realizar Entrevista
Comienzo: vie 02/11/18 Identificador: 7
Fin: lun 05/11/18 Dur: 2 días
RE:
Página 6
Creacion del Software Document Plane
RE:
Página 7
Crear Diagrama de Casos de Us
RE:
Página 8
Elaboracion de SCU
RE:
Página 9
Elaboracion de logos y slogan
RE:
Página 10
Buscar Template
RE:
Página 11
Elaboracion de Guía de estilo
RE:
Página 12
Crear modelo entidad relacion de la BD
Fin: mar 13/11/18 Dur: 1 día
RE:
Página 13
Realizar Entrevista
RE:
Página 14
Elaboracion del SatkeHolderRequest
RE:
Página 15
Elaboracion del SOW
RE:
Página 16
Elaboracion de BC
RE:
Página 17
Elaboracion de ProjectCharter
RE:
Página 18
Elaboracion de diagrama deployment
RE:
Página 19
Elaboracion de diagramas de secuencia
RE:
Página 20
Diseño de interfaz
RE:
Página 21
Codificacion de interfaz
RE:
Página 22
Codificacion del ABC
RE:
Página 23
Creacion de manuales de usuario
RE:
Página 24
Realizacion de Pruebas
RE:
Página 25
Creacion de reportes
Fin: vie 30/11/18 Dur: 1 día
RE:
Página 26
Entrega del Producto
RE:
Página 27
Tareas críticas Tareas críticas y marcadas
Tareas no críticas Tareas marcadas
Hitos críticos Tareas externas críticas
Hito Externas
Proyecto: Diagrama_Gantt
Fecha: lun 29/10/18 Tareas de resumen críticas Resumen del proyecto
Tareas de resumen Tareas críticas resaltadas
Tareas críticas insertadas Tareas no críticas resaltadas
Tareas insertadas
Página 28
Fecha 28/Octubre/2018
CHECK LIST DE CALIDAD
Proyecto HEY
ITEMS Cumple Observaciones/notas

SI NO Regular
¿El software utilizado es X
el correcto?
¿el hardware utilizado es X
el correcto?
¿la planificación se X
adecua al proyecto?
¿se estimo la X
complejidad del
proyecto?
¿Se utiliza protocolo de X
seguridad?
¿Se estimo X Se lleva acabo el ajuste del
correctamente el tiempo cronograma para terminar a tiempo.
de desarrollo?
¿El presupuesto X
estimado es el correcto?
¿Se utiliza un lenguaje de X
programación adecuado?
¿Las interfaces son X
intuitivas?
¿el diseño es atractivo X
para el cliente?
¿la funcionalidad es la X Aun falta algunas funcionalidades
prevista? por implementar.
¿se realizan las pruebas X
suficientes para el
control?
¿Se lleva acabo la X
documentación del
proyecto?
¿cumple con la norma X Algunos estándares aun falta por
ISO 9126? cumplirlos.
¿el cliente esta satisfecho X Las funcionalides son satisfactorias
con el prototipo del de acuerdo a lo requerido
proyecto?
28/Octubre/2018
Firma Fecha
Plan de Deployment
Perfil Básico
Plan de Deployment Página 2 / 14
Versión 1.0
Historial de Versiones
Fecha Versión Descripción Autor

28/11/2018 1.0 Creación del documento Yessica Romero
Martinez
Abreviaciones/Acrónimos
Abrv./Acro. Definición
PD Plan de Deployment- conjunto de artefactos desarrollados para facilitar la
implementación de un conjunto de prácticas, de un marco de trabajo
seleccionado, en una Pequeña Organización.
UC Use Case técnica para la captura de requisitos potenciales de un
nuevo Sistema o una actualización de Software
Versión 1.0
Tabla de Contenidos
1. Descripción Técnica ............................................................................. 4
Propósito del documento ...................................................................................... 4
2. Definiciones......................................................................................... 5
Términos Genéricos ............................................................................................. 5
Términos Específicos ........................................................................................... 5
3. Descripción de Procesos, Actividades, Tareas, Pasos, Roles y
Productos ................................................................................................ 6
Proceso de Planificación de Proyecto ...................................................................... 7
Ejecución de Plan de Proyecto ............................................................................... 8
Evaluación y Control de Proyecto .......................................................................... 9
Cierre del Proyecto ............................................................................................. 10
Descripción de roles ........................................................................................... 12
Descripción de Artefactos .................................................................................... 13
4. Estructura de Descomposición ........................................................... 14
Versión 1.0
1. Descripción Técnica
Propósito del documento
Este Documento está realizado para facilitar la implementación de un conjunto de
prácticas en una Organización. Un PD no es un modelo de proceso de referencia. Los
elementos de un PD típico son: descripción de procesos, actividades, tareas, roles y
productos, plantillas, lista de verificación, ejemplo, referencia a estándares y modelos, y
herramientas.
Versión 1.0
2. Definiciones
En esta sección, el lector encontrará dos conjuntos de definiciones. El primer conjunto

define los términos utilizados en todos los Paquetes de Despliegue, esto es, términos
genéricos. El segundo conjunto de términos utilizados en este Paquete de Despliegue, es
decir, los términos específicos.
Términos Genéricos
Proceso: conjunto de actividades interrelacionadas o que interactúan entre ellas para
transformar entradas en salidas.
Actividad: un conjunto de tareas cohesivas de un proceso.
Tarea: acción requerida, recomendada o permisible que intenta contribuir al logro de uno
o más resultados de un proceso.
Paso: en un paquete de despliegue, una tarea es descompuesta en una serie de pasos.
Rol: una función definida para ser realizada por un miembro del equipo del proyecto,
como pruebas, archivamiento, inspección, codificación.
Producto: pieza de información o entregable que puede ser producida (no

obligatoriamente) por una o muchas tareas (por ejemplo, un documento de diseño,
código fuente).
Términos Específicos
EDT: Estructura de Descomposición de Trabajo (EDT): es una técnica fundamental
de la gestión de proyectos para definir y organizar el alcance total de un proyecto,
empleando una estructura de árbol jerárquica. Los primeros dos niveles del EDT (el nodo
raíz y el Nivel 2) definen un conjunto de resultados planificados que representan de
forma colectiva y exclusiva el 100% del alcance del proyecto. En cada nivel subsecuente,
los nodos hijos representan de forma colectiva y exclusiva el 100% del alcance del nodo
padre.
Proyecto: Un esfuerzo con fechas de inicio y fin definidas realizado para crear un
producto o servicio de acuerdo a los recursos y requerimientos especificados.
Recurso: Un elemento que es utilizado o consumido durante la ejecución de un proceso.
Versión 1.0
3. Descripción de Procesos, Actividades, Tareas,

Pasos, Roles y Productos
Planificación de
Proyecto
Ejecución de
Plan de Proyecto
Evaluación y
Control del
Proyecto
Cierre del
Proyecto
Figura 1 Prácticas de Gestión de Proyectos
Actividad: Planificación de Proyecto
Tareas Roles1
1.1 Revisar la definición de requerimientos LP, LT
1.2 Definir con el Cliente las tiempos de Entrega para cada uno de los LP, CL
entregables especificados en la definición de requerimientos
1.3 Identificar las tareas específicas a ejecutar para producir los LP, LT
entregables y sus componentes de software identificados en la
definición de requerimientos
1.4 Establecer la Duración Estimada para ejecutar cada tarea. LP, LT
1.5 Identificar y documentar los recursos: personal, materiales, LP, LT
equipos y herramientas, incluyendo la capacitación requerida para que
el Equipo de Trabajo ejecute el proyecto.
1.6 Establecer la Composición del Equipo de Trabajo asignando roles y LP, LT
responsabilidades de acuerdo a los Recursos.
1.7 Asignar fechas estimadas de inicio y fin para cada tarea a fin de LP, LT
crear el Cronograma de Tareas del Proyecto considerando los recursos
asignados, la secuencia y dependencia de las tareas.
1.8 Calcular y documentar el Esfuerzo y Costo Estimados del proyecto. LP
1.9 Identificar y documentar los riesgos que pueden afectar el LP, LT
proyecto.
1.10 Verificación del Plan de Proyecto. Verificar que todos los LP, LT
elementos del Plan de Proyecto son viables y consistentes.
1.11 Validación del Plan de Proyecto. Validar que la definición de los LP,FI
Versión 1.0
elementos del Plan de Proyecto corresponden con la definición de

requerimientos
Proceso de Planificación de Proyecto
Objetivos: Determina el alcance de la gestión del proyecto y las actividades

técnicas, identifica los resultados del proceso, las tareas y los
entregables del proyecto, establece cronogramas para conducir las
tareas del proyecto, incluyendo los criterios de éxito, y los recursos
requeridos para alcanzar las tareas del proyecto.
Roles: líder de Proyecto
Analista
Financiera
Artefactos: Plan de Proyecto
Descripción de Proyecto
Pasos: 1. Identificar productos y actividades
2. Estimar los recursos, esfuerzo y duración
4. Crear un cronograma
Descripción de Paso 1. Identificar productos y actividades:
Paso: Durante esta etapa el líder del proyecto designara las siguientes
tareas
• Definición de requerimientos
• Creación de UC
• Especificación de UC
• Programación del sistema
• Verificación de validaciones
• Estado de prueba
• Entrega de software funcional
Paso 2. Estimar los recursos, esfuerzo y duración:

Véase el diagrama de Gantt y control de presupuesto del apartado
de Seguimiento y control
Paso 3. Crear un cronograma:

Véase el diagrama de Gantt del apartado de Seguimiento y control
Comunicación:
A todo los integrantes del equipo se le designaron tareas mediante
minutas estableciendo las tareas a realizar al igual que en el
diagrama de Gantt se establecen sus tiempos de duración
Versión 1.0
Actividad: Ejecución de Plan de Proyecto
Tarea Roles
2.1 Revisar el Plan de Proyecto y registrar la información actual en el LT, ET
Reporte de Avance.
2.2 Analizar y evaluar la Solicitud de Cambio para el impacto en LT
costos, de tiempos y técnico, e incluir los cambios aceptados en el
Plan de Proyecto.
2.3 Conducir reuniones de revisión con el Equipo de Trabajo, revisar LT
estado de los riesgos, registrar acuerdos y monitorearlos hasta su
conclusión.
2.4 Conducir reuniones de revisión con el Cliente, registrar acuerdos y FI, LT,
monitorearlos hasta su conclusión. ET
Ejecución de Plan de Proyecto
Objetivos: Implementar el trabajo actual de las tareas del proyecto de acuerdo

al plan de proyecto.
Roles: Analista
Desarrollador
Cliente
Reporte de Avance
Solicitudes de cambio
Pasos: 1. Obtener el acuerdo del plan de proyecto
2. Registrar el estado
3. Tomar acciones correctivas
Descripción de Paso 1. Obtener el acuerdo del plan de proyecto:
Pasos: El equipo ya debe de tener sus tareas designadas y se muestran a
continuación :
• Realización de documentación
• Actualizaciones de los documentos de seguimiento y control
• Realización de programación del software
•
Paso 2. Registrar el estado:
El gestor de proyecto debe monitorear y registrar el progreso actual
del proyecto contra el progreso planificado. Para registrar el estado,
se puede utilizar un 'sistema de luces de tránsito'. El enfoque de las
luces Roja / Amarilla / Verde es usado comúnmente en la gestión
de proyectos debido a que todos están familiarizados con los
colores. Los colores son:
▪ Verde – la tarea está 'a tiempo'
▪ Amarillo – la tarea está 'fuera de tiempo pero recuperable'
▪ Rojo – la tarea está 'fuera de tiempo y recuperable con
dificultades'
Versión 1.0
El contenido característico de este reporte es:

• Estado de las tareas actuales contra las tareas planificadas
• Estado de los resultados actuales contra los objetivos y
alcances
• Estado de la asignación actual de recursos contra el
seguimiento y control
• Estado del costo actual contra el presupuesto estimado
• Estado del tiempo actual contra el tiempo programado
• Estado de los riesgos actuales contra los riesgos
identificados previamente
Paso 3. Tomar acciones correctivas:

Cuando se han identificado los desvíos entre el plan de proyecto y
el progreso actual del proyecto o la implementación de solicitudes
de cambio han sido aceptadas, se necesitarán tomar las acciones
correctivas para asegurar que el proyecto continúe de acuerdo con
el plan revisado.
Actividad: 4.3 Evaluación y control de proyecto

Tarea Roles
3.1 Evaluar el progreso del proyecto respecto al Plan de Proyecto. LT, ET
3.2 Establecer acciones para corregir desvíos o problemas e identificar LT, ET

riesgos relacionados al cumplimiento del plan, si son necesarios,
agregarlos en el apartado de seguimiento y control
3.3 Identificar cambios a los requerimientos y/o Plan de Proyecto para LT, ET
atender los desvíos graves, riesgos potenciales o problemas asociados
al cumplimiento del plan.
Evaluación y Control de Proyecto
Objetivos: determinar el estado del proyecto y asegurar que el proyecto se

ejecuta de acuerdo a los planes y cronogramas, dentro del
presupuesto estimado y satisface los objetivos técnicos.
Roles: Lider de Proyecto

Desarrollador
Reporte de Avance
Solicitudes de Cambio
Pasos: 1. Revisión del plan
2. Identificar desvíos en el plan
3. Procesar las solicitudes de cambio
Descripción de Paso 1. Revisión del plan:
Pasos: El plan de proyecto debería ser revisado periódicamente por el
gestor de proyecto contra el progreso actual registrado en el
Reporte de Avance. Los desvíos del progreso planificado pueden
Versión 1.0
requerir la ejecución de una Acción Correctiva, resultando en un

plan de proyecto actualizado. Se debería prestar atención a la
identificación y documentación de cualquier riesgo que puede
afectar el proyecto.
Paso 2. Identificar desvíos en el plan:

Basado en cualquier desvío encontrado durante la actividad de
Revisión del Plan, puede ser necesario identificar y evaluar los
desvíos de costos, cronogramas y rendimiento técnico significativos
y emprender Acciones Correctivas.
Paso 3. Procesar las solicitudes de cambio:

Las solicitudes de cambio de requerimientos (cualquier cambio que
ocurra luego que el proyecto ha iniciado) deben ser gestionadas y
controladas, como si fueran a impactar el plan de proyecto,
cronograma y costo. Típicamente, para una solicitud de cambio se
deben seguir los siguientes pasos:
• Realizar un análisis de impacto del cambio en el producto de
trabajo
• Estimar el esfuerzo para implementar el cambio
• Re-estimar el cronograma y costo del proyecto
• Obtener la aprobación del cliente sobre el cambio acordado
Actividad: 4.4 Cierre del proyecto

Tarea Roles
.4.1 Formalizar el término del proyecto de acuerdo a las FI
Instrucciones de Entrega establecidas en el Plan de Proyecto,
proporcionando el apoyo para su aceptación y obteniendo las firmas
correspondientes en el Acta de Aceptación.
Cierre del Proyecto
Objetivos: liberar los entregables finales al cliente, entregar la documentación

del proyecto al negocio, terminar los contratos con proveedores,
liberar los recursos del proyecto y comunicar el cierre del proyecto
a todos los stakeholders.
Roles: Lider de Proyecto
Financiera
Artefactos: Plan de proyecto
Software
Acta de aceptación
Pasos: 1. Entregar el software
2. Obtener la aceptación del cliente
Descripción de Paso 1. Entregar el software:
paso: Se entregan el sistema de software y la documentación asociada a
la financiera
Versión 1.0
Paso 2. Aceptación del cliente:

La firma de un Documento de Aceptación por la financiera donde
indica el cierre formal del proyecto y que el software ha sido
entregado de acuerdo a lo especificado en el contrato de
instrucciones de entrega.
Versión 1.0
Descripción de roles
Esta es una lista alfabética de los roles, abreviaciones y lista de competencias definidas
en la Parte 5.
Rol Abreviación Competencias
1. Financiera FI Organización que nos brindara la información
relacionada al la creación del software a realizar
2. Equipo de ET Conocimiento y experiencia de acuerdo a los roles
Trabajo en el proyecto: LiT, AN, DIS y/o PR.
Conocimiento de los estándares usados por la
finaciera
3. Líder de LP Conocimiento y experiencia en el dominio de
proyecto proceso del Software.
Versión 1.0
Descripción de Artefactos
Esta es una lista alfabética de los artefactos que pueden ser producidos para facilitar la
documentación de un proyecto.
Artefactos Definición
Una descripción de alto nivel del proyecto que incluye:
Descripción de Proyecto
alcance, objetivos y entregables principales.
Documento que establece la aceptación del cliente sobre
Documento de Aceptación
los entregables establecidos en el proyecto.
Reporte de cierre de Un documento que captura las lecciones aprendidas.
proyecto
Un conjunto consistente de productos de software que
incluye:
• Especificación de Requerimientos
• Diseño de Software
Software • Software (unidad, producto, elemento)
• Casos y Procedimientos de Pruebas y Reportes de
Incidencias
• Manual técnico
• Manual de Usuario
Un documento que describe un requerimiento nuevo o
Solicitud de Cambio
revisado por el cliente.
Versión 1.0
4. Estructura de Descomposición
Estructura de Descomposición de Trabajo (EDT)

Número Tipo de Descripción de la Tarea Estimación
de Tarea Tarea (personas días)
1 Tarea Principal Requerimientos 10
1.1 Sub-tarea Análisis de dominio 5
1.2 Sub-tarea Identificación de Requerimientos 2
1.3 Sub-tarea Verificación y Validación de 3
Requerimientos
2 Tarea Principal Diseño de Sistema 15
2.1 Sub-tarea Diseño de la Arquitectura 10
2.2 Sub-tarea Diseño Detallado 5
3 Tarea Principal Implementación de Sistema 30
3.1 Sub-tarea Codificación 25
3.2 Sub-tarea Pruebas 5
JIREH
HEY
Software Development Plan (Small Project)
Version 1.0
JIREH Version: 1.0
Software Development Plan Date: 29/10/2018
Revision History
Date Version Description Author
26/10/2018 1.0 Documento para el plan de desarrollo de Cabrera Paulin Miriam

Software, con los puntos importantes para
su elaboración y organización.
Coryringht JIREH, 2018 Page 2 of 8

JIREH Version: 1.0
Table of Contents
1. Introduction 4
1.1 Purpose 4
1.2 Scope 4
1.3 Definitions, Acronyms, and Abbreviations 4
1.4 References 4
1.5 Overview 4
2. Project Overview 5
2.1 Project Purpose, Scope, and Objectives 5

2.2 Assumptions and Constraints 5
2.3 Project Deliverables 5
2.4 Evolution of the Software Development Plan 5
3. Project Organization 5
3.1 Organizational Structure 5

3.2 External Interfaces 5
3.3 Roles and Responsibilities 6
4. Management Process 6
4.1 Project Estimates 6

4.2 Project Plan 6
4.2.1 Phase Plan 6
4.2.2 Iteration Objectives 6
4.2.3 Releases 7
4.2.4 Project Schedule 7
4.2.5 Project Resourcing 7
4.3 Project Monitoring and Control 7
5. Annexes 8

JIREH Version: 1.0
Software Development Plan (Small Project)
1. Introduction
Este Documento nos servirá con el planteamiento del plan de desarrollo de software, con el
propósito, alcance del documento, definiciones y acrónimos utilizados dentro de este documento,
para que sea entendible la información. Explicando de esta manera el cómo es desarrollar el
proyecto, como se pretende que se lleve a cabo, organizando los roles y responsabilidades que se
desempeñaran dentro de este, junto con las estimaciones y recursos que serán utilizados, de esta
manera tener una idea más clara de cómo se llevara a cabo el desarrollo del software, siguiendo una
serie de pasos, estableciendo una serie de puntos importantes.
1.1 Purpose
Recopilar un conjunto de información para saber el proceso que se realizaran para llevar acabo la
elaboración del proyecto y la manera en que este estará constituido.
De esta manera permite conocer la planificación que se realizar el software, explicando de manera
general lo que este conlleva lo que se está desarrollando. Permitiendo tener más organización con
ayuda de esta información.
1.2 Scope
Este plan de desarrollo permitirá conocer las ideas principales de cómo es que se llevara a cabo el
proyecto con los puntos importantes a considerar planeados. Saber lo que se realizara evitando tener
planes que no correspondientes a los que se realizar, teniendo en claro que se quiere y busca, como
lograr el desarrollo exitoso del proyecto buscando la mejor forma de realizarlo.
Los planes corresponderán para satisfacer las necesidades y requisitos que se deben cumplir para
que el proyecto para el cliente obtenga su producto como desea y espera.
1.3 Definitions, Acronyms, and Abbreviations
TESTEO: Realización de pruebas en el Software.
1.4 References
Los documentos que se utilizaran como referencia para la administración y planificación del
proyecto son:
1. Problem statement
2. SOW
3. BC
4. PrjCh
5. StkRq
6. WBS
7. Diagrama de Casos de Uso,
8. Especificaciones de Caso de Uso.
9. SAD
1.5 Overview
.

JIREH Version: 1.0
2. Project Overview
2.1 Project Purpose, Scope, and Objectives
Facilitar el manejo de información sobre las visitas que tiene un promotor que está asociado con
una Financiera Independiente. El sistema dará el alcance de solo llevar el manejo de registrar
visitas, registras promotores, consulta de visitas, etc.
El sistema no se verá involucrado en otros ámbitos dentro de la financiera. Se centrara solamente
en sistematizar el área de Visitas.
2.2 Assumptions and Constraints

Este Proyecto será desarrollado por los alumnos: Cabrera Paulin Miriam, Ceballos Cervantes
Viviana Elizabeth, Espinosa Dimas Jorge Enrique, Romero Matinés Yessica y Toxqui Jiménez
Alan con un presupuesto mínimo aproximado de $10,000, dependiendo las necesidades de los
desarrolladores, se realizará durante horas escolares de 7 de la mañana a 3 de la tarde y horario
externo de 7 de la noche en adelante. Incluyendo reuniones externas del horario escolar y marcado
después de esto llegando a ocupar fines de semana por las tardes.
2.3 Project Deliverables
Los entregables y avances se entregan para su revisión durante las fechas correspondiente para su
revisión con el profesor. A finales de cada parcial se entregarán avances o actividades finalizadas
correspondientes con el proyecto para la evaluación de esta manera teniendo cada vez más
actividades concluidas hasta que se finalice el proyecto.
2.4 Evolution of the Software Development Plan
El plan de desarrollo de Software será revisado al inicio de cada fase cada avance será revisado
durante el periodo correspondiente para dar correcciones, observaciones, acuerdos, así dar
formalmente entregar los avances cada mes, siendo de esta manera responsiva e incremental, para
obtener el logro de un proyecto terminado para su entrega total, con los requerimientos
correspondientes y solicitados por el cliente.
3. Project Organization
3.1 Organizational Structure
Romero Martínez Yessica : Líder de proyecto, Analista.
Ceballos Cervantes Viviana Elizabeth: Diseñador de base de Datos, Analista.
Cabrera Paulin Miriam: Diseñador de base de Front-End, Especializar en Seguridad, Tester.
Espinosa Dimas Jorge Enrique: Programador.
Toxqui Jimenez Alan: Programador.
Juan Mexica Rivera: Profesor a cargo de revisiones sobre documentación del desarrollo del
proyecto (Administración de Proyecto).
Esmeralda Contreras Trejo: Profesor encargada de revisiones sobre la arquitectura del software,
especificaciones de caso de uso e implementación del sistema.
Catalina Barbeitor : Profesora encargados de revisión de proyecto en general.
3.2 External Interfaces
Personas externas que se ven involucradas en el Proyecto son:

JIREH Version: 1.0
• Financiera Independiente, encargada de llevar a cabo prestamos financieros dentro de la

zona de Iztapalapa y anexas.
• Centros Educativos Registrados dentro de la financiera.
• Promotores y Gerentes.
3.3 Roles and Responsibilities
Person Rational Unified Process Role

Project Manager
Deployment Manager
Espinosa Dimas Jorge Enrique Requirements Reviewer
Toxqui Jiménez Alan Architecture Reviewer
Configuration Manager
Change Control Manager
System Analyst
Requirements Specifier
User Interface Designer
Software Architect
Romero Martínez Yessica Design Reviewer
Ceballos Cervantes Vivina Test Manager Test
Elizabeth Analyst
Cabrera Paulin Miriam Designer
Implementer
Code Reviewer
Integrator
Test Designer
Tester
4. Management Process
4.1 Project Estimates
El Proyecto debe dar inicio desde el 10 de Septiembre de 2018 hasta aproximadamente el 30 de
Noviembre de 2018 fecha de finalización y entrega de producto. Tomando el lapso de la duración
del cuatrimestre, con una inversión mínima estimada en $10,000 para gastos de papelería y servidor.
4.2 Project Plan
4.2.1 Phase Plan
4.2.2 Iteration Objectives

Dar la automatización al área de visitas en la Financiera Independiente, esto con el fin de que esta
tenga un mejor manejo con la información que se ingresa periódicamente.
Con el fin específico de ofrecer un seguimiento y control más accesible y fiable dentro de esta.

JIREH Version: 1.0
4.2.3 Releases
El Proyecto a realizar durante el periodo de los dos primeros meses cuatrimestre en formato de
forma Beta, dando solo entregas de interfaces para el cliente debido a que este esté sujeto a
modificaciones sugeridas o solicitadas en las revisiones marcadas en la planeación inicial. El resto
de tiempo marcado en el cronograma con base a las revisiones y correcciones detectadas al largo
del desarrollo e finalizara haciendo las pruebas pertinentes del funcionamiento general. Una vez el
sistema esté terminado y en funcionamiento se subirá el sistema en un servidor web para su
implementación, proporcionando el URL del sitió a los profesores para que estos puedan hacer la
evaluación final.
4.2.4 Project Schedule
Milestone Estimated Delivery Date

Tema y problematica 17-09-2018
Documentation 24-09-2018
Base de Datos 18-10-2018
Implementacion 05-11-2018
Pruebas 19-11-2018
Documentacion completa 26-11-2018
Proyecto final 03-12-2018
4.2.5 Project Resourcing

Se desarrollará el Proyecto en un equipo de cinco personas, estudiantes de Universidad en la carrera
de TSU, en TIC´s Area Sistemas Informáticos
• Cabrera Paulin Miriam
• Cevallos Cervantes Viviana Elizabeth
• Espinosa Dimas Jorge Enrique
• Romero Martínez Yessica
• Toxqui Jiménez Alan
Con conocimientos básicos en: Programación, Base de Datos, Análisis.

4.3 Project Monitoring and Control
Los requisitos para este Sistema serán capturados en la matriz de requerimientos, será modificado
si es necesario, para que este sea aprobado, además contaremos con una bitácora, para el control de
entregables, para la aprobación de dichos documentos y las observaciones correspondientes. Para
su posterior modificación y entrega del documento corregido.
El líder del proyecto mantiene el cronograma que muestra las fechas de entrega y estimaciones de
tiempo en las cuales se realizara el proyecto.
Además, se le asignara a cada empleado un paquete de trabajo proporcional, que debe ser cumplido
en un plazo de tiempo determinado.
Cualquier cambio del tiempo y entregables, será informado por el líder de proyecto o clientes,
modificado en el cronograma, respetando los tiempos de entrega y termino final del proyecto.

JIREH Version: 1.0
Todos los entregables deben pasar por un proceso de revisión apropiado, para su aprobación y
aceptación.
Se corregirá lo que corresponda referente a los entregables, y pueda ser liberado
Para evitar riesgos y mala funcionalidad del sistema, se realizarán testeos de seguridad y validación
de datos.
5. Annexes

STATEMENT OF WORK
(Financiera “independiente”)
Issued to Organization Name: JIREH
Street Address: Cto. Rey Nezahualcóyotl, Benito Juárez, 57000
Nezahualcóyotl, Méx.
Attn: JIREH, “independiente”

email address:
Cabrera Paulin Miriam :
nyunora7@gmail.com
Ceballos Cervantes Viviana Elizabeth:
viviseliza@hotmail.com
Espinosa Dimas Jorge Enrique:
Jurgen9790@gmail.com
Romero Martinez Yessica :
yessica.romero501@gmail.com
Toxqui Jiménez José Alan :
alantox10@hotmail.com
Issued By Your Name: Luis Toxqui Jimenez

Business Name: Financiera “independiente”
Street Address:San Felipe de Jesus 95a
CDMX 09360.
email address: no aplica
phone number: 5527172356
Contents
Introduction.................................................................................................................................................... 2
Background Information ................................................................................................................................ 2
Current Environment ................................................................................................................................. 2
Goals and Objectives................................................................................................................................. 3
Scope of Work ............................................................................................................................................... 3
Deliverables ............................................................................................................................................... 3
Period of Performance .................................................................................................................................. 4
Place of Performance.................................................................................................................................... 4
Applicable Standards .................................................................................................................................... 4
Specific Requirements .................................................................................................................................. 4
Resource Requirements ............................................................................................................................... 4
Vendor Responsibilities ................................................................................................................................. 4
Client Responsibilities ................................................................................................................................... 4
Project Risks ................................................................................................................................................. 5
Completion Criteria ....................................................................................................................................... 5
Change Control Procedure ........................................................................................................................... 5
Other Information and Supporting Documentation........................................................................................ 5
Points of Contact ........................................................................................................................................... 5
Acceptance.................................................................................................................................................... 6
1
Statement of Work Template
Initials
Insert Date
INTRODUCTION
Este documento que se presenta a continuación nos expone los alcances que se planean establecer en
la financiera “independiente” para facilitar su utilización
BACKGROUND INFORMATI ON
La planificación es fundamental para este proyecto ya que nos ayudara a establecer el control y
seguimiento necesario para su buena implementación y correcta utilización
CURRENT ENVIRONMENT
En la actualidad la financiera” independiente” se encuentra ubicada en la calle San Felipe de Jesus 95ª
cuenta con 2 Gerentes y 5 promotores
• Misión: En la financiera independiente se tiene como misión ser una mano amiga que ayude alas
diversas personas que necesiten de algún préstamo para su crecimiento o salir de la mala racha
que tenga cada persona o organización
• Servicio actual: Cuenta con el servicio de préstamos para personas física o escuelas que
necesiten de este préstamo económico
• Entrega: El equipo JIREH tiene como fecha limite de entrega el 15 de diciembre del 2018
• Usuario:
Customer: El gerente será el encargado de registrar a los promotores que se requieran al

igual la programación de visitas a los diversos clientes que se tengan
Cliente: podrá ver el estado del proceso de su visita
Promotor: será el encargado de estar constantemente actualizando el status de las visitas
programadas
2
Initials
GOALS AND OBJECTIVES
Que la planificación ayude a optimizar el seguimiento de la financiera “independiente” sobre lo
SCOPE OF WORK
JIREH se compromete a la entrega de este sistema con las funcionalidades explicitas en este
documento con un costo total de $12000
DELIVERABLES
Se incluirán
➢ Plan de desarrollo de software (Sow)

➢ Bussines Case Template (BS)
➢ Stakeholder Requests
➢ Project chárter (PRJCH)
3
Initials
PERIOD OF PERFORMANCE
Fecha de inicio: 03/09/2018 fecha de entrega: 15/12/2018 21 horas
PLACE OF PERFORMANCE
Lugar de desarrollo será en la universidad Tecnologica de Nezahualcoyotl para su posteriores revisiones

en la calle Felipe de Jesus 95ª
APPLICABLE STANDARDS
ISO – 9126
SPECIFIC REQUIREMENT S
No aplica
RESOURCE REQUIREMENT S
Word
SublimeText 3
VENDOR RESPONSIBILIT IES
No Aplica
CLIENT RESPONSIBILIT IES
La financiera “independiente” es responsable de ingresar los datos correctamente a la base de datos

que previamente se llego a un acuerdo con el equipo JIREH para no tener fallas en días posteriores
o confusión entre los promotores en la utilización de este sistema
4
Initials
PROJECT RISKS
1. Falla del sistema
2. Derrame de algún tipo de liquido a los equipos de trabajo.
3. Falla de conexión de luz.
4. Falla en la conexión a internet.
5. Robo imparcial o parcial de los equipos.
6. Falla de software de los equipos.
7. Asaltos.
8. Caducidad de licencias de software.
9. Falla de fabrica en los equipos
COMPLETION CRITERIA
La terminación del objetivo del proyecto ser cuando se cumplan los siguientes términos:
• Entrega de la documentación del proyecto

• Sistema funcional con las funcionalidades especificadas
CHANGE CONTROL PROCE DURE
No aplica
OTHER INFORMATION AND SUPPORTING DOCUMENTATION
No aplica
POINTS OF CONTACT
No aplica
5
Initials
ACCEPTANCE
Fecha: 29-Septiembre --2018
Yo Luis Toxqui Jimenez , en mi capacidad como dueño y administrador de la financiera

“independiente” acepta los términos establecidos en esta Declaración de trabajo. Por JIREH
Firma
6
Initials
JIREH
HEY
Stakeholder Requests
Version 1.2
Hey Version: 1.1
Stakeholder Requests Date: 30/09/2018
SR
Revision History
28/09/2018 1.0 Especificaciones de las actividades y los Espinosa Dimas
requerimientos de los Stakeholders.
Jorge Enrique.
30/09/2018 1.1 Requerimientos de los Stakeholders. Ceballos Cervantes
Viviana Elizabeth
12/10/2018 1.2 Correcciones de especificaciones Ceballos Cervantes
Viviana Elizabeth
Confidential ©JIREH, 2018 Page 2

Hey Version: 1.1
SR
Table of Contents
1. Introduction, 4
1.1 Purpose 4
1.2 Scope 4
1.3 References 4
1.4 Overview 4
2. Establish Stakeholder or User Profile 4
3. Assessing the Problem 5
4. Understanding the User Environment 5
5. Recap for Understanding 6
6. Analyst’s Inputs on Stakeholder’s Problem (validate or invalidate assumptions) 6
7. Assessing Your Solution (if applicable) 6
8. Assessing the Opportunity 6
9. Assessing Reliability, Performance, and Support Needs 6

• Un Sistema que no pueda acceder cualquiera a la parte del administrador solo personal
designado por la empresa. 6
• El servidor sea capaz de soportar toda la información que se agregue. 6
• La misma empresa le dará el mantenimiento necesario al sistema cada cierto tiempo. 6
Other Requirements 7
10. Wrap-Up 7
11. Analyst’s Summary 7

Hey Version: 1.1
SR
Stakeholder Requests
1. Introduction,
Definicion de personas u orgonizaciones que se involucren en el proyecto”HEY”, que reciban un beneficio
Apartir del proyecto.
1.1 Purpose
Se propone que para tanto el gerentecomo el promotor (Stakeholders) inicie Sesion y el sistema le habilite la
interfaz dependiendo de los privilegios de cada actor.
1.2 Scope
El gerenete poda registra las visitas de cada uno de los promotores
Los promotores podran Consultar la visita y Modificar el estatus de la visita
Los clients podran consultar la visita en el sistema con un folio .
1.3 References
Use case
Programar visita
Mantener Promotor
Mantener Centrro Educativo
Seguimiento visita
Iniciar Sesion
1.4 Overview
La documentacion de este Sistema esta organizado mediante una problematica , casos de uso descritos
anteriormente..
2. Establish Stakeholder or User Profile
• Name:Toxqui Jimenez Luis Company / Industry: Financiera
independiente
• Job Title: Gerente
• What are your key responsibilities? Financiar el proyecto dando el capital de inicio
• What deliverables do you produce? Dar el capital
• How is success measured? Cuando el proyecto sea finalizado y este a su vez funcional.
• What problems interfere with your success?La no funcionalidad del servicio.
• What, if any, trends make your job easier or harder?No contara con el capital inicial suficiente.
• Name:Promotor Company / Industry: Financiera

• Job Title: Gerente
• What are your key responsibilities? Dar a conocer las necesidades de su area entorno a su rol
• What deliverables do you produce? Necesidad a resolver

Hey Version: 1.1
SR
• What problems interfere with your success?La no funcionalidad del producto.
• Name: Servicio Educativo Company / Industry: Financiera

• Job Title: Clintes
• What are your key responsibilities? Dar aconocer sus neceisdades entorno al proyecto ,para que estas se
puedan cumplir de acuerdo a los alcanzes del proyecto.
• What deliverables do you produce? Problema que resolver
• What problems interfere with your success?La no funcionalidad del servicio.
3. Assessing the Problem
• El Sistema “Hey ” Tiene Como Finalidad Crear Un Registro De Seguimiento Entorno A La Visita Promotor-
Cliente • El Sistema Fue Creado Para Mantener Un Orden Sobre Las Visitas Ya Que Estas Peden Repetirse Por
Diferentes Promotores O La Visita No Se Realiza En El Horario A Cordado Sin Que El Cliente Pueda Ser
Informado . For Each Problem, Ask: • La Mayoría De La Financieras Hoy Een Dia No Cuentan Con Un Regitro De
Seguimiento De La Visita Digitaliado , El Sistema Ofrece Poder Subir Toda La Informacion De Las Visitas
Digitalizadas . • El Sistema Resolvera Problemas De Visitas Repetidas Por Uno O Mas Promotores , Los Horarios
De Estaya Que Muchos Clientes Cancelan La Visita Por No Contar Con Un Dia Y Hora Especificos
Ya Que Con Nuestro Sistema El Cliente Podra Visualizar El Tiempo De Llegada Del Promotor .
4. Understanding the User Environment
• Los Centro Educativos serán todos aquellos que registre el gerenete .

• Ya que el Sistema es interactivo con el Centro Educativo no se necesita de algún manual o curso .
• Cada Centro Educativo tiene una previa experiencia ya que trabajan en una finaciera y cuentan con la
experiencia de el seguimiento de las visitas.
• El sistema “HEY” debe ser clara y fácil de manejar por cliente de la finaciera para la connsulta de sus
visitas.
• El Sistema sera adaptado hacia una aplicación web/ movil .
• La aumentación requerida es toda la antes especificada para el empleo del Sistema

Hey Version: 1.1
SR
5. Recap for Understanding

• El gerenete comenta que tienen una gran lista de visitas a diferentes Centros educativos poero estas muchas
veces llegan con retardos o se envia a mas de un promotor a realizarla.
• La solución que le estamos ofreciendo cubre con las necesidades especificadas por el gerente.
.
6. Analyst’s Inputs on Stakeholder’s Problem (validate or invalidate
assumptions)
o Que el Sistema sea confuso y los Centro Educativos no comprendan o se les haga imposible entender su
uso.
o La interfaz no sea de agrado al publico causando desinterés en la aplicación.
o La interacción dentro del sistema no sea didáctica que el Centro Educativo se aburra y salga del
sistema.
o For each suggested problem, ask:
o Si, si la aplicación no esta bien diseñada causara el desinterés de los Centro Educativo causando
perdidas financieras a los creadores. • El mal planteamiento de la aplicación desde el inicio.
o El problema se resolviera desde el inicio planteado o creando esquemas de como seria, funcionaria
y luciría la aplicación mostrando a un supervisor ya que este aprobaba comenzar un la
programación de esta.
o •Si, mediante una estrategia previamente diseñada
o . • Problemas que se pueden generar a lo largo de tiempo que se desarrolle el proyecto
7. Assessing Your Solution (if applicable)

• General una interfaz sencilla y fácil de entender para Centro Educativos de la financier y clientes (Centros
Educativos)
• El sistema sea sencillo y practico
. •Ayuda en línea un caso de que llegara a fallar algo dentro del Sistema
.
8. Assessing the Opportunity
• El Centro Educativo que dara el otorgamiento por zona sera el gerente
• Los promotores podran modificar su informacion y consultar las visitas otorgadas por el gerente
• El cliente solo podra consultar la guia de rastreo de la visita .
• Es necesario que cada uno de los actors descritos cuente con una cuenta para poder Iniciar Sesion
• Aquella que cubra con la necesitas a solucionar o le respuestas al Centro Educativo de cómo solucionar
la acción que no puede hacer.
9. Assessing Reliability, Performance, and Support Needs
• Un Sistema que no pueda acceder cualquiera a la parte del administrador solo personal designado por la
empresa.
• El servidor sea capaz de soportar toda la información que se agregue.
• La misma empresa le dará el mantenimiento necesario al sistema cada cierto tiempo.

Hey Version: 1.1
SR
• Hosting :Hostinger web premium .
Other Requirements
• Visualizacion en el navegador Google Chrome
10. Wrap-Up
Concluyendo el centro educativo entrevistado comenta que no cuenta con ninguna duda hasta el momento,
le hemos proporcionado nuestros datos si es que surge alguna, y de igual manera contamos con el.
11. Analyst’s Summary
1. Sea un Sistema fácil de usar.

2. Poder generar los registros de las visitas por promotor.
3.- Que la guia de rastreo de las visitas para la visualizacion del los centros educativos .

Hey Version: 1.1
SR
Stakeholders Necesidades Actividades

• Gerente Tener un control sobre las Registrar los promotores,
visitas que realiza cada uno de Registrar las visitas .
sus promotores y una lista sobre
el estatus de cada una de estas.
Registrar a los centros
educativos que se les realizara
las visitas .
• Promotor Realizar las vistas a los centros Consultar las visitas cambiar el
educativos asignados por el estatus de la visita .
gerenete, cambiar el estatus de
la visita .
• Centro Educativo Podra consultar su visita y Consultar su seguimiento de la
checar el tiempo que esta tardara visita .
, que promotor se le asigno .

Ingeniería en
software
II
GUIA DE ESTILO PARA LA
APLICACIÓN WEB FINANCIERA
“INDEPENDIENTE”
Nombre de los integrantes: Cabrera Paulin Miriam
Ceballos Cervantes Viviana Elizabeth
Espinosa Dimas Jorge Enrique
Romero Martínez Yessica
Toxqui Jiménez Alan José
Grupo: IC-51
Guía de Estilo Financiera Independiente IC-51

Contenido
Índice .............................................................................................................................. ¡Error! Marcador no definido.
Introducción .................................................................................................................................................................. 3
Estructura ...................................................................................................................................................................... 4
Áreas de la retícula ...................................................................................................................................................... 4
Distribución de los elementos .................................................................................................................................... 4
Crecimiento y escalabilidad........................................................................................................................................ 4
Tipografía ...................................................................................................................................................................... 5
Usos del color ............................................................................................................................................................... 6
Imágenes....................................................................................................................................................................... 7

Introducción
La Guía de estilo web para la Financiera Independiente, tiene como objetivo establecer un
marco de intervención controlado en su interfaz.
Para ello se han establecido estándares para el desarrollo correcto, igual el fácil manejo del
mantenimiento de esta. Se crear un documento de consulta rápida que permita asimilar
ágilmente los objetivos en cuanto a imagen se refieren.
De esta forma la presente guía brinda un conjunto de pautas que significarán cualquier
futura modificación que pueda requerir. Estas pautas permitirán asegurar la coherencia
entre la aplicación entregada y sus futuras modificaciones. Igualmente, la guía suministra
los medios para asegurar el mantenimiento de una imagen uniforme y adecuada en el
futuro.

Estructura
La Interfaz se construye sobre una retícula de 8 columnas en horizontal, empleada de guía para la
distribución de los módulos. Dichos bloques son Cabecera, Cuerpo y Pie de página.
La retícula permite:
• Estructura de interfaz escalable.

• Amigabilidad con el gestor de contenidos.
• Adaptación a varias resoluciones.
• Tratamiento modular de los elementos.
Áreas de la retícula
1. Fila superior: espacio destinado para Perfiles y Titulo de la página.
2. Fila central: espacio destinado a navegación contextual y buscador general
3. Fila inferior: especio destinado a un flash mantenerle y acceso a Formación Integral.
Distribución de los elementos
La distribución de los elementos dentro de la retícula debe seguir unas pautas que aseguren su función en la
pantalla.
❖ Formación de los módulos.
Las piezas deben mantenerse de manera ortogonal (cuadrada o rectangular) Nunca de manera irregular.
❖ Horizontalidad y Verticalidad de las piezas.
Se recomienda que en la medida de lo posible la formación de los módulos sea en sentido horizontal, debido
que favorece la lectura al permitir anchos de línea más cortos y composiciones más armónicas.
Crecimiento y escalabilidad
❖ La retícula deberá adaptarse a las necesidades concretas de cada sección.
❖ Los módulos son reutilizables y suficientes para cubrir todas las necesidades gracias a su flexibilidad de
combinación. La decisión de seleccionar un módulo se basará en la relevancia del contenido, la
jerarquía, su naturaleza contextual y el tamaño.
❖ El crecimiento deberá ser controlado.
❖ La retícula no puede crecer de manera horizontal pero si verticalmente.

Tipografía
Para el sitio web se ha empleado Arial una de las tipografías estándar en HTML que aseguran una perfecta
legibilidad en web. Usada en su versión regular y a un tamaño mínimo de 0.6em.
Arial
Abcdefghijklmnñopqrstuvwxyz
áéíóúü
ABCDEFGHIJKLMNÑOPQRSTUVWXYZÁÉÍÓÚÜ
1234567890 $%&(.,;:’”!?
Se utiliza la Helvetica Neue para todos los textos que aparecen siempre como imagen. Su uso se ha limitado a
los banners de todo el portal en combinación con la Arial.
Helvetica Neue
áéíóúü
ABCDEFGHIJKLMNÑOPQRSTUVWXYZ
ÁÉÍÓÚÜ
1234567890 $%&(.,;:’”!?)
Helvetica Neue Bold

áéíóúü
ABCDEFGHIJKLMNÑOPQRSTUVWXYZ
ÁÉÍÓÚÜ
1234567890 $%&(.,;:’”!?)

Usos del color
• Colores primarios corporativos
La aplicación destaca por la utilización de una gama cromática suave, con predominio del verde y los azules. Como
colores de contraste destacamos el azul, y el gris dado por la imagen corporativa. Usos del color.
• Colores secundarios corporativos

Imágenes
Tratamiento de las imágenes
Las imágenes de carácter e iconografía dentro no deben considerarse como elementos aislados de ornamentación,
sino como apoyo a su imagen de marca y como extensión de los valores.
Tratamiento de las imágenes – Subhome.
Imágen subhome 250 x 120 px
Tratamiento de las imágenes – Interiores.
Imágen contenido - interior 235 x 150 px
Tratamiento de las imágenes - Honoris
Causa Imagen contenido Honoris Causa 235 x 105px.
Tratamiento de las imágenes - Banners
Tamaño de Banners 230 x 90px.

JIREH
HEY
Software Architecture Document
Version 1.0
HEY Version: 1.0
Software Architecture Document Date: 12/10/2018
SAD.docx
Revision History
12/10/2018 1.0 Definición de la arquitectura el software Espinosa Dimas Jorge
mostrando las diversas vistas Enrique
Romero Martinez
Yessica
Confidential JIREH 2018 Page 2 of 12

HEY Version: 1.0
SAD.docx
Table of Contents
1. Introduction 4
1.1 Purpose 4
1.2 Scope 4
1.3 Definitions, Acronyms, and Abbreviations 4
1.4 References 4
1.5 Overview 5
2. Architectural Representation 5
3. Architectural Goals and Constraints 5
4. Use-Case View 6
4.1 Use-Case Realizations 8
5. Logical View 8
5.1 Overview 8
5.2 Architecturally Significant Design Packages 9
6. Process View 9
7. Deployment View 9
8. Implementation View 11
8.1 Overview 11
8.2 Layers 11
9. Data View (optional) 11
10. Size and Performance 12
11. Quality 12

HEY Version: 1.0
SAD.docx
Software Architecture Document

1. Introduction
1.1 Purpose
Este documento nos mostrara los componentes que conforman la estructura del sistema
HEY las cuales se componen de distintas capas para su correcta funcionalidad y el
entendimiento del equipo de involucrado en su desarrollo
1.2 Scope
Se mostrara lo que contiene todas las vista del sistema las cuales se involucran en todo
momento se complementa con los documentos de UC anteriormente mostrados, esta
arquitectura de software se basara en el patrón arquitectónico MVC.
1.3 Definitions, Acronyms, and Abbreviations
 Arquitectura de software: también denominada arquitectura lógica, consiste en un
conjunto de patrones y abstracciones coherentes que proporcionan un marco definido y
claro para interactuar con el código fuente del software.
 Controlador: actúa como intermediario entre el Modelo y la Vista, gestionando el flujo de
información entre ellos y las transformaciones para adaptar los datos a las necesidades de
cada uno.
 Modelo : contiene una representación de los datos que maneja el sistema, su lógica de
negocio, y sus mecanismos de persistencia.
 MVC: modelo vista controlador
 UC : Use case
 Vista: interfaz de usuario, que compone la información que se envía al cliente y los
mecanismos interacción con éste
1.4 References
 Problem Statement
 Use Case Specification :Programar visita
 Use Case Specification : mantener promotor
 Use Case Specification :mantener Centro educativo
 Use Case Specification :seguimiento Visita
 Design Guidelines
 https://www.colmex.mx/assets/pdfs/10-LGPDPPSO_57.pdf
 https://jarroba.com/modelo-41-vistas-de-kruchten-para-dummies/

HEY Version: 1.0
SAD.docx
1.5 Overview
El siguiente documento nos mostrara los diagramas principales de la arquitectura de
software como lo son el diagrama de caso de uso diagrama de deployment y la vista
lógica cada uno de los diagramas contiene una breve descripción de su funcionalidad y
las partes que contiene con una descripción breve de su funcionalidad en el sistema HEY
2. Architectural Representation
Modelo ”4+1” vistas de Kruchten.
¿Qué es? Es un modelo de vistas, diseñado por el profesor Philippe Kruchten que se utiliza para
describir la arquitectura de un sistema software intensivo basado en el uso de múltiples puntos de
vista. Cada una de estas vistas se encarga de demostrar toda la arquitectura del sistema software
que se esté documentando, cada una de ellas de forma diferente y muestra aspectos diferentes del
sistema software. (Garlan., 1995)
Vistas que emplea:
• Vista lógica: Ofrece soporte a los requerimientos funcionales, lo que el sistema debe
proveer en términos de servicios a sus usuarios. En la vista lógica se mostrará la división
del sistema en subsistemas y paquetes. Para los paquetes significativos se describirán las
clases que lo componen, utilizando un diagrama de paquetes y subsistemas dada la
aproximación orientada a objetos de la implementación.
 Vista de procesos: La vista de procesos permite describir los procesos del sistema y
como estos se comunican. Esta vista toma en cuenta algunos requerimientos no-
funcionales, como:
 Disponibilidad
 Desempeño
 Tolerancia a fallos
 Distribución
 Integridad
 Concurrencia del sistema.
 Vista física o de despliegue: La vista física describe como es instalada la aplicación y
como se ejecuta. Esta vista toma en cuenta requerimientos no funcionales como:
 Tolerancia a fallos
 Escalabilidad
 Desempeño
 Vista de desarrollo o de implementación: Esta vista se concentra en la organización en
módulos del software. Esta vista no fue diseñada.
 Vista de casos de uso o de Escenarios: La vista de casos de uso consolida las vistas
anteriores, donde los escenarios se convierten en una abstracción de los requerimientos
más importantes.
3. Architectural Goals and Constraints
El sistema HEY contiene los siguientes aspectos para su programación y diseño
 Patron MVC

HEY Version: 1.0
SAD.docx
 Guia de Estilo
 Interfaces Responsibas
 No-SQL (firebase)
 Hosting : hostinger
4. Use-Case View
Vista en la que se modela la funcionalidad del Sistema utilizando el diagrama de casos de uso
Mantener Promotor
(from Use Cases)
Gerente
(f rom Actors)
Programar Vsita
(from Use Cases)
Iniciar Sesion
(from Use Cases)
Mantener Centro Eduactivo
(from Use Cases)
Seguimento Visita
Promotor SEP (cliente)
(from Use Cases)
(f rom Actors) (f rom Actors)
Tipo Nombre Funcion

Actor Gerente Es la persona con mayor
responsabilidad en el sistema
ya que permite el
mantenimiento de diversas
funciones como son al
promotor y servicios
educativos al igual la
programación de las visitas
Actor Promotor Esta persona es la encargada

HEY Version: 1.0
SAD.docx
de estar constantemente
actualizado los estatus de las
visitas que tiene anteriormente
programadas por el gerente
Actor SEP(Cliente) Son los centros educativos
que solicitaron de los
servicios de la financiera
“independiente” en este
apartado podrán verificar el
estado de la visita que
previamente se le asigno con
un gerente para la
continuación del tramite
solicitado con la financiera
Use Case Inicio Sesion Esta acción solo estará
permitida para el Gerente y el
promotor ya que a la
información que se le dará a
conocer a cada uno de ellos
es confidencial y solo el
gerente y el promotor podrán
tener interacción con este
apartado del sistema
Use Case Mantener promotor El gerente tendrá acceso a este
apartado la cual podrá
realizar acciones como
 Registro de un nuevo
promotor
 Actualizar la
información del
promotor
 Eliminar a un
promotor
anteriormente
registrado
 Consultar los
promotores que están
registrados

HEY Version: 1.0
SAD.docx
Use Case Programar Visita Este apartado es lo que podrá

tener acceso a la distribución
haca los promotores de visitas
que tendrán que realizar a los
centros educativos
Use Case Mantener Centro educativo En este apartado el gerente es
el encargado de tosas las
acciones tales como
 Registrar nuevo centro
educativo
 Modificar centro
educativo
 Eliminar centro
educativo
 Consultar centro
educativo
Que le servirán para la
programación de visitas y
pueda hacer más eficaz el
registro de cada una de ella
Use Case Seguimiento Visita En este apartando el promotor
podrá actualizar el estatus de
la cita cada vez que el realice
la visita al centro educativo
Por parte del centro educativo
podrá visualizar en que estado
se encuentra la visita que se le
realizo o esta por realizarse
4.1 Use-Case Realizations
5. Logical View
5.1 Overview
flujo de trabajo de análisis y diseño. Sólo hay una vista lógica del sistema, que ilustra las
realizaciones de guiones de uso clave, subsistemas, paquetes y clases que abarcan el
comportamiento significativo arquitectónicamente. La vista lógica se perfecciona durante
las iteraciones.
La vista lógica muestra un subconjunto significativo arquitectónicamente del modelo de

diseño, es decir, un subconjunto de las clases, subsistemas y paquetes, y realizaciones de
guiones de uso.

HEY Version: 1.0
SAD.docx
5.2 Architecturally Significant Design Packages

Se encarga de separar los datos de una aplicación, la interfaz de usuario y la lógica de
control en 3 componentes distintos (Modelo Vista Controlador )
<<layer>>
control
(from HEY)
HEY
<<layer>>
<<layer>> view
model (from HEY)
(from HEY)
js
(from HEY)
Nombre de la carpeta Que contiene

Model Contiene las entidades que se van a utilizar
en conjunto con la vista
Control Contiene los intermediarios entre el
modelo y la vista permitiendo la gestión de
la información
Vista Contiene los elementos que permiten la
muestra de las interfaces de usuario para
que pueda interactuar con el sistema
js Contiene los elementos que le permitirán a
las interfaces de usuario validar la
información que ingrese en ella
6. Process View
7. Deployment View
Muestra la distribución de los componentes del Sistema a distintos nodos de
procesamiento, se utiliza para modelar la instalación y configuración del Sistema

HEY Version: 1.0
SAD.docx
<<Web Server>>
<<Data Base>> Sistema de Seguimiento <<Browser>>
Base Datos HEY de visitas HEY SEP(cliente)
Verificar Visita
Mantto prom
Mantto SerEdu
Seguimiento Visita
Iniciar Sesion
Programar Visita <<Browser>>
Promotor
<<Browser>>
Gerente
Realizar Visita
asignar Visita
Tipo/Nombre Que realiza

Data Base HEY Contiene los datos personales de
promotores y la información necesaria para
la programación de visitas
Web Server Sistema HEY Se realizan las transacciones tales como el
inicio se sesión por parte del gerente y los
promotores el seguimiento de visita y la
programación que se hacen con ella
Browser SEP (cliente) Es la persona que realiza la búsqueda de la
información se su visita
Browser Gerente Es la persona que realiza la programación
de visitas y el mantenimiento de los centros
educativos y información de los
promotores
Browser Promotor Es la persona encargada de dar la
continuación de la visita que se le ha
programado anteriormente

HEY Version: 1.0
SAD.docx
8. Implementation View
8.1 Overview
8.2 Layers
9. Data View (optional)
Modelo Logico : modelo que no es específico de una base de datos que describe aspectos
relacionados con las necesidades de una organización para recopilar datos y las relaciones entre
estos aspectos.
Modelo Relacional: se caracteriza a muy grandes rasgos por disponer que toda la información
debe estar contenida en tablas, y las relaciones entre datos deben ser representadas
explícitamente en esos mismos datos.

HEY Version: 1.0
SAD.docx
10. Size and Performance

11. Quality
 Este sistema esta especialmente realizado para las personas que estén trabajando en la
financiera “independiente” y para los clientes que están utilizando los servicios de esta
financiera
 Los datos personales de los promotores y los centros educativos están protegidos por la
LEY GENERAL DE PROTECCIÓN DE DATOS PERSONALES EN POSESIÓN DE
SUJETOS OBLIGADOS
 El software estará realizado bajo la norma ISO 9126

JIREH
Hey
Use-Case Specification: Mantener Centro Educativo
Version <2.0>
HEY Version: <2.0>
Use-Case Specification :Mantener Centro Educativo Date: 03/11/2018
UCS-MV
Revision History
08/10/2018 1.0 Especificaciones del Caso de Uso Mantener Ceballos Cervantes
Centro educativo con los escenarios Viviana Elizabeth.
Agregar Centro educativo Y Modificar
Centro educativo
03/11/2018 2.0 Actualizacion , Diagrmas de Secuencias y Ceballos Cervantes
Clase Viviana Elizabeth.
Confidential JIREH 2018 Page 2

HEY Version: <2.0>
UCS-MV
Table of Contents
1. Brief Description 4
2. Flow of Events 4
2.1 Basic Flow 4
3. Subflows 4
3.1 Subflujo Agregar Centro educativo 4
3.2 Subflujo Modificar Centro educativo 5
3.3 Subflujo Eliminar Centro educativo 5
4. Alternative Flows 5
4.1 Datos Incorrectos 5
4.2 Centro educativo Existente 5
5. Preconditions 5
5.1 Iniciar Sesion 5
6. Postconditions 6
6.1 Mantener Informacion 6
7. Extensions Points 6
8. Special Requirements 6
8.1 Software 6
9. Story Board 6
10. Sequences Diagrams (Agregar) 8
11. Class Diagram 11

HEY Version: <2.0>
UCS-MV
Use Case Mantener Centro Educativo
1. Brief Description
Este caso de uso permite al Gerente del Sistema mantener actualizada la información de los Centros
educativos a través de las operaciones agregar, modificar, eliminar y consultar Centro educativo.
2. Flow of Events
2.1 Basic Flow
1.-Este caso de uso inicia cuando el Gerente selecciona de la interfaz la pestaña de “mantener centro
educativo ”.
2. – El sistema recupera de la base de datos la información de los centros educativos
3.- El sistema habilita las opciones agregar modificar y eliminar .
4.- El Gerente selecciona la operación a realizar y el sistema ejecuta la acción
a) Si el Gerente selecciona la opción Nuevo se ejecuta el Subflujo Agregar Centro educativo .
b) Si el Gerente selecciona la opción Modificar se ejecuta el Subflujo Modificar Centro educativo.
c) El Gerente selecciona la opción Eliminar se ejecuta el Subflujo Eliminar Centro educativo
3. Subflows
3.1 Subflujo Agregar Centro educativo

1. El Sistema muestra el formulario Nuevo Centro educativo y habilita los campos de captura :clave
nombre del centro educativo, dirección y turno.
2. El sistema recupera de la base de datos los de la Alcaldia, colonia en el formulario, los cuales
elegirá el gerente.
3. El Gerente confirma la operación seleccionando la opción “Aceptar”
4. El sistema verifica que los datos sean correctos, Si los datos son correctos el sistema valido que el
Centro educativo no existe en la base de datos.
5. El sistema actualiza la lista de Centros educativos .

HEY Version: <2.0>
UCS-MV
3.2 Subflujo Modificar Centro educativo

1.- El gerente selecciona de la lista de Centro educativo el que desea modificar .
2.- El sistema recupera de la base de datos la información del Centro educativo : clave, nombre y nivel
educativo .
3.-El sistema habilita los datos y campos que pueden ser modificados , excepto la clave.
4. El gerente cambia los datos necesarios y confirma la operación seleccionado la opción aceptar.
5.-El sistema verifica que los daros sean correctos ,Si los datos son correctos el sistema valido que el
Centro educativo no existe en la base de datos.
6.-Si el Centro educativo no existe , el sistema verifica los datos del Centro educativo
7.- El sistema actualiza la lista de Centros educativos .
3.3 Subflujo Eliminar Centro educativo

1.-El gerente selecciona de la lista de Centros educativos la que desea eliminar
2.-El sistema recupera de la base de datos la lista de Centros que desea eliminar
3.- El gerente elimina el Centro educativo deseado.
4.- El sistema envía mensaje de confirmación “Esta seguro de eliminar este Centro educativo”
5.-El gerente confirma eliminar Centro educativo
6.- El Sistema elimina el Centro educativo
7.- El sistema actualiza la lista de Centros educativos.
4. Alternative Flows
4.1 Datos Incorrectos

Si en los escenarios Agregar Centro educativo y Modificar Centro educativo los datos ingresados por el
gerente no corresponden al tipo de dato o se deja algún campo vacío , el sistema enviara un mensaje
indicando el tipo de error y como solucionarlo , el Centro educativo no será registrado y se solicitara
nuevamente los datos.
4.2 Centro educativo Existente
Si en los escenarios Agregar Centro educativo y Modificar Centro educativo la clave del centro ingresado
ya existe en la base de datos , el sistema enviara un mensaje indicando el tipo de error , el Centro educativo
no será registrado y se solicitara una clave de Centro educativo.
5. Preconditions
5.1 Iniciar Sesion
1.- El gerente debe iniciar sesión para poder tener acceso a esta funcionalidad del sistema .

HEY Version: <2.0>
UCS-MV
6. Postconditions
6.1 Mantener Informacion
1.- Si el proceso se realiza correctamente el sistema deberá agregar, modificar y eliminar los datos de los
Centros educativos ,actualizando en cada operación la lista de Centros educativos.
7. Extensions Points
No aplica para este Caso de Uso .
8. Special Requirements
8.1 Software
1. Sistema Operativo Windows 7 en adelante

2. Navegador :Chorome, Firefox .
9. Story Board

HEY Version: <2.0>
UCS-MV

HEY Version: <2.0>
UCS-MV
10. Sequences Diagrams (Agregar)

HEY Version: <2.0>
UCS-MV
Consultar

HEY Version: <2.0>
UCS-MV
Modificar

HEY Version: <2.0>
UCS-MV
Eliminar
11. Class Diagram

JIREH
Use-Case Specification: MantenerPromotor
Version 2.0
Financiera Independiente Version: 1.1
Use-Case Specification: <Use-Case Name> Date: 16/10/2018
UC_MP
Revision History
21/09/20118 1.0 Especificación del caso de uso Registrar Toxqui Jimenez Jose
Promotor con los escenarios Agregar Alan
Promotor, Modificar Promotor y Eliminar
Promotor
16/10/20118 1.1 Complementación de opción para subir Toxqui Jimenez Jose
fotografía del promotor. Alan
05/11/2018 2.0 Complementación de diagrama de clases y Toxqui Jimenez Jose
diagrama de secuencia. Alan
Confidential JIREH,2018 Page 2

UC_MP
Table of Contents
1. Use-Case Name 4
1.1 Brief Description 4
2. Flow of Events 4
2.1 Basic Flow 4
3. Subflows 4
3.1 Subflujo Agregar Promotor 4
3.2 Subflujo Modificar Promotor 4
3.3 Subflujo Eliminar Promotor 5
4. Alternative Flows 5
4.2 Promotor Existente 5
5. Preconditions 5
5.1 Iniciar Sesión 5
6. Postconditions 5
6.1 Mantener Información 5
7. Extension Points 5
8.1 Software 5
9. Storyboards 6
9.1 Registrar Promotor 6
9.2 Nuevo, Modificar y Eliminar 7
10. Logical View 8

10.1 Diagrama de clases 8
10.2 Diagrama de secuencia NuevoPromotor 9
10.3 Diagrama de secuencia ModificarPromotor 10
10.4 Diagrama de secuencia EliminarPromotor 11
10.5 Diagrama de secuencia ConsultarPromotor 12

UC_MP
Use-Case Specification: Registrar Promotor

1. Use-Case Name
1.1 Brief Description
Este caso de uso permite al gerente mantener la información actualizada del promotor, a través de la
operación agregar, modificar y eliminar promotor.
2. Flow of Events
2.1 Basic Flow
1.- Este caso de uso inicia cuando el gerente selecciona de la interfaz principal la opción Registrar
Promotor.
2.- El Sistema recupera de la base de datos la lista de Promotores Registrados.
3.- El gerente selecciona la operación que desea realizar.
a) Si el gerente selecciona la opción Nuevo, se ejecuta el Subflujo Agregar Promotor.
b) Si el gerente selecciona la opción Actualizar, se ejecuta el Subflujo Modificar Promotor.
c) Si el gerente selecciona la opción Eliminar, se ejecuta el Subflujo Eliminar Promotor.
3. Subflows
3.1 Subflujo Agregar Promotor
1.- El sistema muestra el formulario Nuevo Promotor y habilita los campos de captura: Nombre, Apellido
Paterno, Apellido Materno, Fecha de Nacimiento, RFC, Teléfono y Foto del promotor.
2.- El gerente captura los datos y confirma la operación seleccionando la opción aceptar.
3.- El sistema verifica que los datos sean correctos, Si los datos son correctos el sistema valido que el
promotor (RFC) no exista en la base de datos.
4.- Si el promotor no existe, el sistema agrega los datos del promotor y crea un identificador (id).
5.- El sistema actualiza la lista de promotores.
3.2 Subflujo Modificar Promotor
1.- El gerente selecciona de la lista de promotores el que desea modificar.

2.- El sistema recupera de la base de datos el detalle del promotor id, Nombre, Apellido Paterno, Apellido
Materno, Fecha de Nacimiento, RFC, Teléfono y Foto del promotor.
3.- El sistema habilita los datos que pueden ser modificados, excepto el id.
4.- El gerente cambia los datos necesarios y confirma la operación seleccionando la opción aceptar.
5.- El sistema verifica que los datos sean correctos, Si los datos son correctos el sistema valido que el
promotor (RFC) no exista en la base de datos.

UC_MP
6.- Si el cliente no existe, el sistema modifica los datos del promotor.

3.3 Subflujo Eliminar Promotor
1.- El gerente selecciona de la lista de promotores el que desea eliminar.

2.- El sistema recupera de la base de datos el detalle del promotor id, Nombre, Apellido Paterno, Apellido
Materno, Fecha de Nacimiento, RFC, Teléfono y Foto del promotor.
3.- El gerente confirma la operación seleccionando la opción eliminar.
4. Alternative Flows
Si en los escenarios Agregar Promotor y Modificar Promotor los datos ingresados por el gerente no
corresponden al tipo de dato o se deja algún campo vacío, el sistema enviara un mensaje indicando el tipo
de error y como solucionarlo, el promotor no será registrado y se solicitaran nuevamente los datos.
4.2 Promotor Existente

Si en los escenarios Agregar Promotor y Modificar Promotor el RFC ingresado por el gerente ya existe en
la base de datos, el sistema enviara un mensaje indicando el tipo de error, el promotor no será registrado y
se solicitara un RFC diferente.
5. Preconditions
5.1 Iniciar Sesión
1.- El gerente debe iniciar sesión para poder tener acceso a esta funcionalidad del sistema.
6. Postconditions
6.1 Mantener Información
1.- Si el proceso se realiza correctamente el Sistema deberá agregar, actualizar y eliminar los datos del
promotor, actualizando en cada operación la lista de promotores.
7. Extension Points
No aplica para este UC
8.1 Software
 Sistema Operativo Windows 7 en adelante
 Android 4.4.1 en adelante
 JDK1.8
 Navegador Chrome, Firefox, Opera, Explorer Edge
 DBMS MySQL

UC_MP
9. Storyboards
9.1 Registrar Promotor

UC_MP
9.2 Nuevo, Modificar y Eliminar

UC_MP
10. Logical View

10.1 Diagrama de clases

UC_MP
10.2 Diagrama de secuencia NuevoPromotor

UC_MP
10.3 Diagrama de secuencia ModificarPromotor

UC_MP
10.4 Diagrama de secuencia EliminarPromotor

UC_MP
10.5 Diagrama de secuencia ConsultarPromotor

JIREH
HEY
Use-Case Specification: Programar visita
Version 2.0
HEY Version: 1.1
Use-Case Specification: Programar VisitaProgramar Visita Date: 9/10/2018
ProgVisita.docx
Revision History
5/10/2018 1.0 Descripción del caso de uso programar Romero Martinez
visita con el escenario nueva visita Yessica
9/10/2018/ 1.1 Correccion del flujo básico del caso de uso Romero Martinez Yesica
programar Vista
03/11/2018 2.0 Actualizacion con Diagramas de Secuencia Ceballos Cervantes
y clase Viviana

HEY Version: 1.1
ProgVisita.docx
Table of Contents
1. Use-Case Name 4
2. Basic Flow of Events 4

2.1 Alternative Flows 4
2.1.1 No aplica para este caso de uso. 4
3.1 Software 4
4. Preconditions 4
4.1 Iniciar Sesion 4
5. Postconditions 4
5.1 Visita programada 4
7. Storyboards 5
7.1 Index gerente 5
8. Sequences Diagram 6
8.1 NuevaVisita 6
8.2 EliminarVisita 6
8.3 ModificarVisita 7
9. Class Diagram 8

HEY Version: 1.1
ProgVisita.docx
Use-Case Specification: Programar visita

1. Use-Case Name
Este caso de uso le permite al gerente realizar la asignación de las visitas a distintos
promotores a través de la operación nueva visita.
2. Basic Flow of Events
Este caso de uso inicia cuando el gerente selecciona del menú de su interfaz principal la opción
consultar visitas
El sistema despliega el formulario Programar nueva Visita.
1.-El gerente ingresa la hora de la visita.
2.-El sistema Recupera la claves y nombres de los promotores
3.-El gerente Selecciona el promotor de su elección
4.-El sistema recupera de la base de datos la lista de las Alcaldías disponibles
5.- El Gerente selecciona la alcaldía de su elección
6.- El sistema recupera la lista de centros educativos
7.- El Gerente selecciona de la lista los centros educativos el centro educativo a visitar
8.- El Gerente seleccionara el turno correspondiente a la visitar (matutino/vespertino)
9.- El Gerente selecciona el botón aceptar
10.- El Sistema guarda los datos de la visita programada
2.1 Alternative Flows
2.1.1 No aplica para este caso de uso.
3.1 Software
1.- Sistema operativo Windows 7 en adelante
2.-Navegador Chrome ,Explorer
3.-Conexión a internet
4. Preconditions
4.1 Iniciar Sesion
El gerente deberá iniciar sesión para poder tener acceso a las funcionalidades del sistema
5. Postconditions
5.1 Visita programada
De guardar correctamente los datos el sistema deberá mostrar la visita ya programada en la interfaz de
visitas y deberá aparecer para el promotor asignado.
6. Extension Points
No aplica para este UC

HEY Version: 1.1
ProgVisita.docx
7. Storyboards
7.1 Index gerente

HEY Version: 1.1
ProgVisita.docx
8. Sequences Diagram
8.1 NuevaVisita
8.2 EliminarVisita

HEY Version: 1.1
ProgVisita.docx
8.3 ModificarVisita

HEY Version: 1.1
ProgVisita.docx
9. Class Diagram

<Company Name>
HEY
Use-Case Specification: <Use-Case Name>
Version <2.0>
HEY Version: 1.0
Use-Case Specification: <Use-Case Name>Seguimiento Visita Date: 5/10/2018
Visita.docx
Revision History
05.10.2018 1.0 Descripción del caso de uso programar Cabrera Paulin Miriam
visita con el escenario de consultar el
seguimiento de la visita.
05.11.18 2.0 Inserción de Diagramas de Clase y Cabrera Paulin Miriam
Secuencia
Confidential <Company Name>, 2018 Page 2

HEY Version: 1.0
Visita.docx
Table of Contents
1. Use-Case Name 7
2. Flow of Events 7
2.1 Basic Flow 7
2.2 Alternative Flows 7
2.2.1 “Registro no modificado”. 7
3.1 Software 7
4. Preconditions 7
5. Postconditions 8
7. Storyboards 8
7.1 < Storyboard One > 8
8. Inserción de Diagramas de Clase. 9

HEY Version: 1.0
Visita.docx
9. Inserción de Diagrama de Secuencia. 10
9.1 Consultar Visita 10

HEY Version: 1.0
Visita.docx
10
9.2 Modificar Estatus. 11

HEY Version: 1.0
Visita.docx
11

HEY Version: 1.0
Visita.docx
Use-Case Specification: <Use-Case Name> Seguimiento

Visita
1. Use-Case Name
Este caso de uso permite el promotor continuar viendo el seguimiento de las visitas que a
realizado con los distintos clientes que a visitado en un periodo de tiempo definido.
2. Flow of Events
2.1 Basic Flow
Este caso de uso iniciara cuando el promotor ingrese su usuario y contraseña para acceder a
la interfaz de promotor.
1. El sistema desplegara el listado de todas las visitas programadas que tenga el promotor, en
este listado aparecerá toda la información de cada visita.
2. El promotor solo podrá cambiar el estatus de la visita (visita hecha, visita no hecha), para
hacerlo bastara seleccionar el botón que aparece en la columna de “estatus”.
5. Si el promotor modifica el estatus de la escuela deberá guardar los cambios del registro
dando clic en el botón de guardar.
6. El sistema actualizara la información almacenándola en la base de datos.
7. El sistema regresara la lista de visitar actualizadas.
2.2 Alternative Flows
2.2.1 “Registro no modificado”.

El registro solo se podrá modificar una vez posteriormente el sistema no te permitirá hacerlo.
3.1 Software
1.- Sistema operativo Windows 7 en adelante
2.-Navegador Chrome ,Explorer
3.-Conexión a internet
4. Preconditions
Software.
1. Inicio de Sesión.
2. Registro de Programa de visitas

HEY Version: 1.0
Visita.docx
5. Postconditions
Tener registro previos para consultar las visitar programadas.
6. Extension Points
No aplica en este caso de uso.
7. Storyboards
[Storyboards of the use case.]
7.1 < Storyboard One >

HEY Version: 1.0
Visita.docx
8. Inserción de Diagramas de Clase.

HEY Version: 1.0
Visita.docx
9. Inserción de Diagrama de Secuencia.

9.1 Consultar Visita

HEY Version: 1.0
Visita.docx
9.2 Modificar Estatus.

JIREH
Casos de Prueba
Casos de prueba: Mantener Promotor
Version 1.0
HEY Version : 1.0
Casos de pruebas (Mantener Promotor) Date:26/11/2018
CP
Revision History
26/11/2018 1 Casos de pruebas Cabrera Paulin Miriam

HEY Version : 1.0
CP
Table of Contents
1. Particiones de equivalencia: Caso de uso “Mantener Centro Educativo” 5
2. TEST CASE ¡Error! Marcador no definido.

2.1 Nombre de Caso de Prueba: Mantener promotor (Insertar) ¡Error! Marcador no definido.
3. TEST CASE 6
3.1 Nombre de Caso de Prueba: Mantener promotor (Campo vacio) 6

4.1 Nombre de Caso de Prueba: Mantener promotor (Datos Incorrectos) ¡Error! Marcador no definido.
5. Condiciones de Ejecucion ¡Error! Marcador no definido.

5.1 Software ¡Error! Marcador no definido.

HEY Version : 1.0
CP
1. Descripción
Este Test Case de Mantener Promotor permite encontrar los errores de programación para tener la menor cantidad
al momento de interactividad con el usuario.
2. Precondición
2.1 Iniciar Sesión
1.- El gerente debe iniciar sesión para poder tener acceso a esta funcionalidad del sistema.
3. Condiciones de Ejecución
3.1 Software
• Sistema Operativo Windows 7 en adelante
• JDK1.8
• Navegador Chrome, Firefox, Opera, Explorer Edge
DBMS MySQL
3.2 Hardware
• Laptop (disco duro mínimo de 500GB y memoria RAM de 2 GB)
• Computadora de escritorio (disco duro mínimo de 500GB y memoria RAM de 2 GB)

HEY Version : 1.0
CP
4. Particiones de equivalencia: Caso de uso “Mantener Promotor”
Condición Externa Clase de equivalencia valida Clase de equivalencia no valida

Nombre Rango : nombre >=3 , nombre nombre <3, nombre >20
<=20 Dominio :0……..9
Tipo:Varchar2 Caracteres especiales
Dominio: A-Z a-z
pellidoP Rango : ApellidoP >=3 , Apellidop<3 , apellidoP>30

ApellidoP <=30 Dominio:0…….9
Dominio : A-Z a-z Caracteres especiales
Tipo :Varchar2
ApellidoM Rango : ApellidoM >=3 , ApellidoM<3 , apellidoM>30
ApellidoM<=30 Dominio:0…….9
Dominio : A-Z a-z Caracteres especiales
Tipo :Varchar2
Teléfono Rango : teléfono ==10 Teléfono > 10 , teléfono <10
Tipo : Number Tipo : Varchar2
Dominio:0….9 Caracteres especiales
Fecha N Tipo : Date Tipo : Varchar2
Formato: 00/00/00 Caracteres especiales
Foto Tipo : png,pjg Caracteres especiales

HEY Version : 1.0
CP
3. TEST CASE(Inserción)
Proyecto: Hey Nombre de Caso de Prueba: Mantener promotor
Versión del Caso de Prueba:1.0 Nivel de prueba:
Nombre del escenario: Registro Promotor
Objetivo: Evaluar y comprobar que el sistema funcione de acuerdo a lo Nombre del Probador:
establecido. Cabrera Paulin Miriam
Autor de Caso de Prueba:Cabrera Paulin Miriam
Tipo de Prueba: Caja Negra Fecha:26/11/2018

ID PASOS ENTRADA RESULTADO RESULTADO EVALUACION(Re SEVERIDAD DE LA
ESPERADO OBTENIDO al) FALLA OBSERVACIONES
EXIT FALLIDO BAJO MEDIO ALTO
OSO
1 Nombre >=3 Caracteres Inserta x Campo de entrada
Nombre (letras) Correctamente validado
<=20
2 Apellido Caracteres Inserta x Campo de entrada
paterno >=3 (letras) Correctamente validado
Apellido
paterno<=20
3 Apellido Caracteres Inserto x Campo de entrada
materno >=3 (letras) Correctamente validado
Apellido
materno<=20
5 Teléfono Caracteres Inserto x Campo de entrada

>=10 (numeros) Correctamente validado
Telefono
<=15
6 Imagen Extensión Inserto de x x Campo de entrada
(png,phhuu (png, Forma no validado,
u) jpg,etc) Incorrecta permite insertar
archivos con
distinta existencia.
Decisión de Aprobación del Caso de Prueba: Aprobó: ___ Fallo: ___ (marque con x el resultado)
Fecha de Aprobación del Caso de Prueba: ___________

HEY Version : 1.0
CP
3.1 Figura 1.0 Test Case promotor.

HEY Version : 1.0
CP
4. Test case (Modificar )

Nombre del escenario: Registro Promotor
Autor de Caso de Prueba: Cabrera Paulin Miriam

OSO
1 Nombre >=3 Caracteres Inserción Inserta x Campo de entrada
Nombre (letras) Correctamente validado
<=20 Maria
Guadalupe
2 Apellido Caracteres Inserción Inserta x Campo de entrada
paterno >=3 (letras) Correctamente validado
Apellido
paterno<=20
3 Apellido Caracteres Inserto x Campo de entrada
materno >=3 (letras) Correctamente validado
Apellido
materno<=20
5 Teléfono Caracteres Inserto x Campo de entrada

>=10 (numeros) Correctamente validado
Telefono
<=15
6 Imagen Extensión Inserto de x x Campo de entrada
(png,phhuu (png, Forma no validado,
u) jpg,etc) Incorrecta permite insertar
archivos con
distinta existencia.

HEY Version : 1.0
CP
4.1 Fig Modificacion

HEY Version : 1.0
CP
5. TEST CASE(Campos Vacíos

Nombre del escenario: Campos Vacios

OSO
1 Nombre >=3 Caracteres Manda alerta “campo x Campo de entrada
Nombre (letras) obligatorio” validado
<=20
2 Apellido Caracteres Manda alerta “campo x Campo de entrada
paterno >=3 (letras) obligatorio” validado
Apellido
paterno<=20
3 Apellido Caracteres Manda alerta “campo x Campo de entrada
materno >=3 (letras) obligatorio” validado
Apellido
materno<=20
5 Teléfono Caracteres Manda alerta “campo x Campo de entrada

>=10 (numeros) obligatorio” validado
Telefono
<=15
6 Imagen Extensión Inserto de Manda alerta “campo Campo de entrada
(png,phhuu (png, Forma obligatorio” x validado
u) jpg,etc) Incorrecta

HEY Version : 1.0
CP
5.1 Figura 3Campos Vacíos

HEY Version : 1.0
CP

Nombre del escenario: Campos Incorrectos

OSO
1 Nombre >=3 Caracteres Manda alerta “Dato x Campo de entrada
Nombre (letras) No Valido” validado
<=20
2 Apellido Caracteres Manda alerta “Dato x Campo de entrada
paterno >=3 (letras) No Valido validado
Apellido
paterno<=20
3 Apellido Caracteres Manda alerta “Dato x Campo de entrada
materno >=3 (letras) No Valido validado
Apellido
materno<=20
4 Rfc Caracteres Manda alerta “Dato x Campo de entrada

Carácter 1-4 (letras y No Valido validado
A-Z números)
Carácter 5-
10 0-9
Carácter 11-
12 A-Z
Carácter 13
0-9
5 Teléfono Caracteres Manda alerta “Dato x Campo de entrada
>=10 (numeros) No Valido validado
Telefono
<=15
6 Imagen Extensión Inserto de Manda alerta “Dato Campo de entrada
(png,phhuu (png, Forma No Valido x validado
u) jpg,etc) Incorrecta

HEY Version : 1.0
CP
Figura 3.0 Test Case promotor Campos Incorrectos.

HEY Version : 1.0
CP

JIREH
Casos de Prueba
Casos de prueba :Mantener Centro Educativo
Version <1.0>
HEY Version : 1.0
CP
Revision History
26/11/2018 1 Casos de pruebas y Partición de Ceballos Cervantes
equivalencia Viviana Elizabeth

HEY Version : 1.0
CP
Table of Contents
1. Particiones de equivalencia: Caso de uso “Mantener Centro Educativo” 4

2.1 Nombre de Caso de Prueba: Mantener promotor (Insertar) ¡Error! Marcador no definido.
3. TEST CASE 7
3.1 Nombre de Caso de Prueba: Mantener promotor (Campo vacio) 7
4. TEST CASE 9
4.1 Nombre de Caso de Prueba: Mantener promotor (Datos Incorrectos) 9
5. Condiciones de Ejecucion 11
5.1 Software 11
5. Condiciones de Ejecucion 11
8.1 Software 11

HEY Version : 1.0
CP
1. Particiones de equivalencia: Caso de uso “Mantener Centro Educativo”
Condición Externa Clase de equivalencia valida Clase de equivalencia no valida

Clave Rango : clave==10 Rango clave > 10 , clave < 10
Carácter 1-2 Dominio:0-9 Carácter 1-2 Dominio: a-z A-Z
Carácter 3-5 Dominio A-Z Carácter 3-5 Dominio 0-9
Carácter 6-10 Domino 0-9 Carácter 6-10 Domino a-z A-Z
Tipo: Varchar2
Nombre-centro Rango: nombre-centro> 3 Rango: nombre-centro <3 , nombre-

Nombre-centro <25 centro > 25
Domino: 0-9 A-Z a-z Domino: caracteres especiales
Tipo : Varchar2
Calle Rango: calle >5 , calle >25 Rango: calle <5

Domino: 0-9 , A-Z , a-z Domino: Caracter especiales , A-Z
Tipo: Varchar2
Numero Rango numero >1 , numero < 5 Rango: numero >6

Domino: 0-9 Domino: caracteres especiales
Tipo: Number
Tipo: Varchar2
Codigo postal Rango : código postal ==5 Rango : código postal >6 código postal<
Domino: 0-9 5
Tipo :Number Domino: A-Z

HEY Version : 1.0
CP
ID/Nombre/Sistema/Proyecto: Nivel de Prueba:
ID Caso de Uso: Tipo(s) de Pruebas(s): Ambiente de Prueba:

ID Requerimiento: (Si es Caso de Uso no Funcional) (Ubicación)
ID/Nombre Escenario: Autor del Caso de Prueba:
ID PASOS ENTRADA RESULTADO RESULTADO EVALUACION(Real) SEVERIDAD DE LA

ESPERADO OBTENIDO FALLA OBSERVACIONES
EXITOSO FALLIDO BAJO MEDIO ALTO
1 Nombre >=3 Ana Inserción Se inserto x Ninguna
Nombre observación
<=20
2 Apellido lopez Inserción Se inserto x Ninguna
paterno >=3 observación
Apellido
paterno<=20
3 Apellido estrada Inserción Se inserto x Ninguna
materno >=3 observación
Apellido
materno<=20
4 Rfc EIDJ900902hd4 Inserción Se inserto x Ninguna

Carácter 1-4 observación
A-Z
Carácter 5-
10 0-9
Carácter 11-
12 A-Z
Carácter 13
0-9
5 Teléfono 5528899797 Inserción Se inserto x Ninguna
>=10 observación
Telefono
<=15
6 Imagen x x Se debe de validar
(png,phhuu que se selleccione
u) un elemnto para
poder hacer un
registro.

HEY Version : 1.0
CP

HEY Version : 1.0
CP
2. TEST CASE
ID:2-CV
2.1 Nombre de Caso de Prueba: Mantener promotor (Campo vacio)
Objetivo: evaluar las funcionalidades del sistema a partir de las entradas del sistema.
Tipo de Prueba Fecha:26/11/2018
Negra
ID PASOS ENTRADA RESULTADO RESULTADO EVALUACION(Real) SEVERIDAD DE LA FALLA
ESPERADO OBTENIDO EXITOSO FALLIDO BAJO MEDIO ALTO OBSERVACIONES
1 Nombre >=3 NO inserte x Ninguna
Nombre observación
<=20
2 Apellido NO inserte x Ninguna
paterno >=3 observación
Apellido
paterno<=20
3 Apellido NO inserte x Ninguna
materno >=3 observación
Apellido
materno<=20
4 Rfc NO inserte x Ninguna

Carácter 1-4 observación
A-Z
Carácter 5-10
0-9
Carácter 11-
12 A-Z
Carácter 13
0-9
5 Teléfono NO inserte x Ninguna
>=10 observación
Telefono
<=15
6 Imagen NO inserte x Ninguna
(png,phhuu observación
u)

HEY Version : 1.0
CP

HEY Version : 1.0
CP
3. TEST CASE
ID:3-DI
3.1 Nombre de Caso de Prueba: Mantener promotor (Datos Incorrectos)
Objetivo : evaluar las funcionalidades del sistema a partir de las entradas del sistema.

ID PASOS ENTRADA RESULTADO RESULTADO EVALUACION(Real) SEVERIDAD DE LA
ESPERADO OBTENIDO FALLA OBSERVACIONES
EXITOSO FALLIDO BAJO MEDIO ALTO
1 Nombre Valentina del NO inserte NO inserto x Ninguna
<3 Sagrado Corazon observación
Nombre
>20
2 Apellido HH NO inserte NO inserto x Ninguna
paterno <3 observación
Apellido
paterno>20
3 Apellido LL NO inserte NO inserto x Ninguna
paterno <3 observación
Apellido
paterno>20
4 Rfc 1234EIDJGR11A NO inserte NO inserto x Ninguna

Carácter 1- observación
4 0-9
Carácter 5-
10 A-Z
Carácter
11-12 0-9
Carácter
13 A-Z
5 Teléfono 5512234567891234 NO inserte NO inserto x Ninguna
<10 observación
Telefono
>15
6 Imagen x x Se debe de
(png,jpeg) seleccionar
almenos un
elemento para
poder validar.

HEY Version : 1.0
CP

HEY Version : 1.0
CP
4. Condiciones de Ejecucion
4.1 Software
• Sistema Operativo Windows 7 en adelante
• JDK1.8
• Navegador Chrome, Firefox, Opera, Explorer Edge
DBMS MySQL
Hardware
• Laptop (disco duro mínimo de 500GB y memoria RAM de 2 GB)
• Computadora de escritorio (disco duro mínimo de 500GB y memoria RAM de 2 GB)

Integradora
II
YESSICA ROMERO MARTINEZ
CORREO
yessica.romero501@gmail.com
TELEFONOS
5567523362
70382279
REDES SOCIALES
Facebook : yessi.romero.900 ⧫
Twitter: yessrom
JIREH
MIRIAM CABRERA PAULIN
CORREO
nyunora7@gmail.com
TELEFONOS
551236275
22378293
REDES SOCIALES
Facebook : Hydeki Hayashi⧫
Twitter: hydeki_hayashi
Responsable :Yessica Romero Martinez

JIREH
VIVIANA ELIZABETH
CEBALLOS CERVANTES
CORREO
viviseliza@hotmail.com
TELEFONOS
5519330400
22378741
REDES SOCIALES
Facebook : viviana.ceballos.79⧫
Twitter: viviana20375225

JIREH
JOSE ALAN
TOXQUI JIMENEZ
CORREO
alantox10@hotmail.com
TELEFONOS
5527172356
58572005
REDES SOCIALES
Facebook : alantox⧫

JIREH
JORGE ENRIQUE
ESPINOSA DIMAS
CORREO
Jurgen9790@gmail.com
TELEFONOS
5532401738
47520034
REDES SOCIALES
Facebook : zven.kruspe.31 ⧫

JIREH
Horario reunión en equipo
LUNES MARTES MIERCOLES JUEVES VIERNES

7:00-8:00 Reunión Reunión
profesora profesora
Esmeralda Esmeralda
Contreras Trejo Contreras Trejo
profesora profesora
Esmeralda Esmeralda
Contreras Trejo Contreras Trejo
9:00-10:00 Organización de
tareas próximas
a entrega
10:00-11:00
11:00-12:00
12:00-1:00 Organización de
tareas próximas
a entrega
profesor profesor
Juan Mexica Juan Mexica
Rivera Rivera
2:00-3:00 Reunión Organización de Organización de
profesor tareas próximas tareas próximas
Juan Mexica a entrega a entrega
Rivera

Version: <1.0>
Especificaciones y Alcance del Proyecto Date: <07/10/18>
Cabrera Paulin Miriam
Revision History
<07/10 /18> <1.0> <Especificación de alcances e interfaces> <Cabrera Paulin Miriam>
Version: <1.0>
Alcances de Proyecto.
Version: <1.0>
El proyecto tiene como alcance fundamental el control general de las visitas que realiza un promotor hacía
clientes que acreditan cierto perfil para solicitar un préstamo.
El sistema contara con un inicio de sesión, al igual que el registro de un promotor por parte del
Administrador. Para mantener información dentro de la base de datos se implementará mediante formularios
de ingreso, modificación y eliminación.
El sistema solo se limitará a esta parte de visitas, queda fuera del proceso para adquirir un préstamo,
cumpliendo solo con la función de organización y control. Al igual que no se hace acreedor al manejo de las
diversas arenas de la financiera.
Identifican de Interfaces.
Interfaz Actor(es) Descripción Función
Inicio Sesión Promotor, Gerente Se inicializa una vez el Validar la información en
promotor o gerente la base de datos y
ingresa el nombre de autentificar que exista el
usuario y contraseña en usuario dentro del sistema
los campos de textos y pueda hacer uso de las
dando clic en el botón de funciones que brinda.
inicio. Para que este se
conecte a la base y
redireccione al index
Mantener Promotor Gerente Dar de alta a un nuevo Validar la información del
promotor dentro del promotor, para que
Sistema, este podrá posteriormente el nuevo
registrar y modificar los promotor pueda iniciar
datos. sesión y consulte sus
visitas.
Programas Visitas Gerente Consultar las visitar que Tiene como función la
debe realizar en un consulta de información
periodo de tiempo. En directa sobre los clientes,
estas estará toda la en este no se podrá hacer
información el cliente que modificaciones o agregar
deberán visitar nuevas visitas por parte
del promotor.
JIREH
UNIVERSIDAD TECNOLÓGICA DE NEZAHUALCÓYOTL

Organismo Público Descentralizado del Gobierno del Estado de México
Informática y Computación
Tecnologías de la Información y Comunicación Área Sistemas Informáticos
Integradora II
JIREH
Integrantes :
Cabrera Paulin Miriam (organización Carpetas)
Ceballos Cervantes Viviana Elizabeth (documentacion BD)
Espinosa Dimas Jorge Enrique (Base de Datos local)
Romero Martínez Yessica (libro Digital)
Toxqui Jiménez José Alan (Base de Datos Hosting)
Grupo: IC51
Septiembre – Diciembre 2018

JIREH
Base de datos en Firebase
Elaborado por : Espinosa Dimas Jorge Enrique

JIREH
Hosting con datos
Elaborado por : Toxqui Jiménez José Alan

JIREH
Problem Statement
Se desarrollara un sistema para la financiera “independiente” que permita tener un control sobre
el Seguimiento y programación de visitas , sin la necesidad de recurrir al promotor para para
confirmar las visitas.
El gerente de la financiera independiente podrá mantener la información de promotores ,hacer la
programación de visitas y tendrá el acceso a la base de datos que le permitirá realizar la
programación de la visitas la cual contara un número de folio, la clave del promotor y el turno
correspondiente
El gerente podrá mantener la información de los centros educativos ingresando los datos como la
clave CCT ,nombre ,tipo de servicio educativos, delegación ,y su domicilio si el gerente requiere
modificar los datos de centro educativo se le podrán mostrar los datos tomándolos de la base de
datos , se le podrán mostrar los centros educativos por medio de un filtro que es por nivel o
delegación,
El gerente podrá ingresar la información de los promotores la cual deberá contener nombre
apellido paterno apellido materno Fecha de Nacimiento, RFC y Teléfono el sistema le asignara
una ID a cada promotor nuevo para su posterior búsqueda en el sistema, podrá eliminar algún
promotor anteriormente registrado , de tener alguna modificación de los datos personales del
promotor se le podrá modificar todos los datos exceptuando su ID
El promotor deberá estar registrado por parte del gerente para tener acceso al sistema . Una vez
validada la información podrá visualizar las visitas asignadas para llevar su seguimiento la cual
contendrá la dirección del centro educativo al cual tendrá que realizar la visita el nombre del
centro educativo podrá modificar el estatus que se encuentre la visita ya sea terminada o se
reprogramo la visita los centros educativos también podrán ver el seguimiento de la visita la cual
tendrá la hora de llegada del promotor y una foto del promotor designado
Elaborado por : Ceballos Cervantes Viviana Elizabeth

JIREH
Diagrama de Caso de Uso general de la “FINANCIERA INDEPENDIENTE ”
Mantener Promotor
(from Use Cases)
Gerente
(f rom Actors)
Programar Vsita
(from Use Cases)
Iniciar Sesion
(from Use Cases)
Mantener Centro Eduactivo
(from Use Cases)
Seguimento Visita
Promotor SEP (cliente)
(from Use Cases)
(f rom Actors) (f rom Actors)

JIREH
Alcance

JIREH
Modelo Relacional

JIREH
Tablas
window.onload = inicializar;
var formPromotor;
var refPromotor;
var tbodyPromotor;
var CREATE = "Añadir Promotor";
var UPDATE = "Modificar Promotor";
var modo = CREATE;
var refPromotorEditar;
function inicializar(){
formPromotor = document.getElementById("regPromotor");
formPromotor.addEventListener("submit", enviarPromotorFirebase, false);
tbodyPromotor = document.getElementById("tbody-promotor");
refPromotor = firebase.database().ref().child("promotor");
mostrarPromotorDeFirebase();
}
function mostrarPromotorDeFirebase(){
refPromotor.on("value", function(snap){
var datos = snap.val();
var filasAMostrar = "";
for(var key in datos){
filasAMostrar += "<tr>" +
"<td>" + datos[key].idp + "</td>" +
"<td>" + datos[key].nombre + "</td>" +
"<td>" + datos[key].apePa + "</td>" +
"<td>" + datos[key].apeMa + "</td>" +
"<td>" + datos[key].fecha + "</td>" +
"<td>" + datos[key].rfc + "</td>" +
"<td>" + datos[key].telefono + "</td>" +
"<td>"+
'<button class="btn btn-default editar" href="" data-toggle="modal" data-
target="#myModal" data-promotor="' + key + '">'+
'<span class="glyphicon glyphicon-pencil"></span>' +
'</button>' +
"</td>" +
'<td>' +
'<button class="btn btn-danger borrar" data-promotor="' + key + '">'+
'<span class="glyphicon glyphicon-trash"></span>' +
'</button>' +
'</td>' +
"</tr>";
}
tbodyPromotor.innerHTML = filasAMostrar;
if(filasAMostrar != ""){
var elementosBorrables = document.getElementsByClassName("borrar");
for(var i=0; i < elementosBorrables.length; i++){
JIREH
elementosBorrables[i].addEventListener("click",borrarPromotorDeFirebase,false);
}
var elementosEditables = document.getElementsByClassName("editar");
for(var i=0; i < elementosEditables.length; i++){
elementosEditables[i].addEventListener("click",editarPromotorDeFirebase,false);
}
}
});
}
function borrarPromotorDeFirebase(){
var keyPromotorABorrar = this.getAttribute("data-promotor");
var refPromotorABorrar = refPromotor.child(keyPromotorABorrar);
refPromotorABorrar.remove();
}
function editarPromotorDeFirebase(){
var keyPromotorAEditar = this.getAttribute("data-promotor");
refPromotorAEditar = refPromotor.child(keyPromotorAEditar);
refPromotorAEditar.once("value",function(snap){
var datos =snap.val();
document.getElementById("nombre").value = datos.nombre;
document.getElementById("apePa").value = datos.apePa;
document.getElementById("apeMa").value = datos.apeMa;
document.getElementById("fecha").value = datos.fecha;
document.getElementById("rfc").value = datos.rfc;
});
document.getElementById("enviar").value = UPDATE;
modo = UPDATE;
}
function enviarPromotorFirebase(event){
event.preventDefault();
switch(modo){
case CREATE:
refPromotor.push({
idp: event.target.idp.value,
nombre: event.target.nombre.value,
apePa: event.target.apePa.value,
apeMa: event.target.apeMa.value,
fecha: event.target.fecha.value,
rfc: event.target.rfc.value,
telefono: event.target.telefono.value,
});
break;
JIREH
case UPDATE:
refPromotorAEditar.update({
nombre: event.target.nombre.value,
apePa: event.target.apePa.value,
apeMa: event.target.apeMa.value,
fecha: event.target.fecha.value,
rfc: event.target.rfc.value,
telefono: event.target.telefono.value,
});
document.getElementById("enviar").value = CREATE;
modo = CREATE;
break;
}
reg.reset();
}

Diccionario de datos
JIREH
Gerente
Atributo Tipo de Tamaño Tipo de Descripción Opcio Domin RESTRIC Rango Relaci Carnalidad
dato llave nalida io CION ón
d
Id_gere Integer 3 Primari Clave del Obliga A……..Z NOT A…….Z Vista 1:M
nte a gerente toria NULL
PRIMAR
Y KEY
nom_ge Varchar2 20 Nombre Obliga A……..Z NOT A……..Z
rente del gerente toria NULL
ape_pa Varchar 2 20 Apellido Obliga A……..Z NOT A……..Z
_gerent paterno toria NULL
e
correo Varchar2 20 Correo del Obliga A……..Z NOT A……..Z
gerente toria NULL
Contras Varcahr2 15 Contraseña Obliga A……..Z NOT A……..Z
eña para el toria NULL
acceso su
cuenta.
Promotor
Tamaño Opcio Carnalidad
Tipo de Tipo de Domin RESTRI
Atributo Descripción nalida Rango Relación
dato llave io CCION
d
3 PRIMAR
Id_pomot Primari Clave del Obliga Y KEY Detalle_
Number 0……9 >=10 1:M
or a promotor toria NOT Vista
NULL
20 Nombre
nom_pro Obliga NOT
Varchar 2 del A…….Z A……..Z
motor toria NULL
promotor
20 Apellido
ape_pa_p Obliga NOT
Varchar2 del A…….Z A……Z
romotor toria NULL
promotor
ape_Ma_ 20 Apellido Obliga NOT
Varchar2 A……..Z A…….Z
promotor materno toria NULL
15 Correo del Obliga NOT
Correo Varchar2
promotor toria NULL
Contraseñ 20 Obliga NOT
Varchar2 Contraseña A…….Z A…….Z
a toria NULL
15 Fecha de
Fecha_na nacimiento Obliga NOT
Varchar2 A…….Z
cimiento del toria NULL
promotor
15 Registro
Obliga NOT
Rfc Varchar2 Federal de
toria NULL
Contribuye
JIREH
nte del
promotor
20 Foto del Obliga NOT
Foto Varchar2 A…….Z A……..Z
promotor toria NULL
Centro Educativo

dato llave io CCION
d
NOT
id_centro Clave de Nivel
10 Primari Obliga NULL
_educativ Varchar2 centro A…….Z A…….Z Eduacti 1:m
a toria PRIMAR
o educativo vo
Y KEY
nom_cent 20 Nombre NOT
Obliga
ro_educat Varchar2 del centro A…….Z NULL A…….Z
toria
ivo Educativo
10 NOT
Turno del Obliga
Turno Varchar2 A…….Z NULL A…….Z
centro toria
Nivel
dato llave io CCION
d
5 Clave del
Primari Obliga NOT
id_nivel Varchar2 nivel A……Z A…….Z
a toria NULL
educativo
20 Nivel
Obliga NOT
Nivel Varchar2 educativo A……Z A…….Z
toria NULL
del centro
Dirección
dato llave io CCION
d
10 Clave de la NOT
id_direcci Primari dirección Obliga 0……… NULL
Numeric >=10 Alcaldía 1:M
on a del centro toria 9 PRIMAR
educativo Y KEY
20 Calle
donde se
Obliga NOT
Calle Varchar2 encuentra A…….Z A…..Z
toria NULL
el centro
educativo
20 Breve
Descripcio Opcio NOT
Varchar2 descripción A…….Z A…..Z
n nal NULL
de la
JIREH
ubicación
del centro
Alcaldía

dato llave io CCION
d
2 NOT
id_alcaldi Primari Clave de la Obliga NULL
Numeric 0….9 >=10
a a alcaldía toria PRMAY
KEY
Nom_alc 15 Nombre de Obliga NOT
Varchar2 A…….Z A…….Z
aldia la alcaldía toria NULL
Colonia

dato llave io CCION
d
15 NOT
Primari Clave de la Opcio NULL
Id_colonia Varchar2 A……Z A……..Z Alcaldia 1:M
a colonia nal PRIMAR
Y KEY
Visita

dato llave io CCION
d
5 NOT
Primari Clave de la Obliga NULL
id_vista Numeric A……..Z 0…….9 Alcaldia 1:M
a visita toria PRIMAR
Y KEY
fecha_hor Primari Clase la lla opcina NOT
Date A……..Z A……..Z
a_rel a fiests l NULL
Detalle Vista
dato llave io CCION
d
10 NOT
Primari Folio de las Obliga NULL
Folio numeric A…….. Gerente
a vsitas toris PRIMAR
Y KEY
15 Comentari
comentar Opcio NOT
Varchar2 o de la A…..Z A…….Z
io nal NULL
visita
JIREH
Organización de Carpetas del Proyecto.

JIREH
La organización de la documentación del proyecto se repartirá mediante carpetas y subcarpetas,
estas llamadas con el nombre de cada asignatura que tenga que ver con el desarrollo del
proyecto.
Cada carpeta y subcarpeta contendrá la documentación clasificada según los avances que se
vayan presentando.
Administración de Proyecto.
En esta carpeta se encontrará alojada toda la documentación referente al desarrollo del
proyecto enfocado a diagramas de Gantt, diagramas de Nodos, documentación con referencia al
PMBOK.
Organización.
Nombre de la carpeta: Administración de Proyecto
Subcarpetas: Diagramas, Plantillas, PFD’s.
Diagramas.
En esta subcarpeta se encontrarán organizados los diagramas solicitados por el profesor. Estos
tendrán la notación “Nombre del diagrama_numero de versión.mmp”. Esto con el fin de que e
distinga entre todos los archivos el progreso o correcciones que hay uno del otro.
Plantillas.
Se encontrará arrojado todo lo referente con las plantillas a llenas del PMBOK. Dentro de ellas ya
existe bitácora incluida.
PD’s
Se colocarán los PD’s que se generen alrededor de proyecto, estos se generaran a partir que se
creen diagramas o mapas. Esto con el fin de tener una mejor visualización del resultado.
Ingeniería en Software.
Se encontrará la documentación referente a la estructura del sistema, caso de uso general, use
case specification, diagramas de clase, deploymen, clase, etc.
Nombre de la carpeta: Ingeniería de Software.
Subcarpetas: Diagramas, Documentación, Arquitectura.
Diagramas.
Se añadirán todos los diagramas que genere la herramienta a modo de documentar
gráficamente los resultados.
Documentación.
Se añadieran todos los apartados extras como el SAD, Guía de Estilo, Especificaciones de caso de
Uso, Problem Statement, etc.
Arquitectura.
Se encontrará el archivo que genera la herramienta “Rational Rose”.
JIREH
Desarrollo de Aplicaciones III.
Se organizará de manera en que el proyecto este planteado es decir una carpeta de HTML, otra
de JS, Imágenes, CSS etc.
Ejemplo de como esta organizada la carpeta “Administración de Proyecto”.

Link Directo a la Carpeta del Proyecto.
https://drive.google.com/drive/u/4/folders/1y-BTt0Tog8ksUi8Nimpk8hIddPeP3r5Y
Elaborado por : Cabrera Paulin Miriam

Bitácora de Registro de Profesores
Alumno Romero Martinez Yessica Materia Integradora
Profesor Catalina Barbeyto Chalte Grupo IC51

Fecha 19/10/2018
Datos de Reunión
Recordatorio de las Tareas Asignadas Realización Diagramas de Gantt con Equipo Jireh
en la semana el profesor Mexica
Realizar Dialogo Expresión Oral y
Escrita
____________________________ ____________________________

Fecha 22/10/2018
Datos de Reunión
Repartición de elaboración de Mantener promotor es el caso de uso a Toxqui Jiménez José

diagramas de secuencia realizar Alan
Realizar SAD Terminar de definir los puntos que Romero Martinez

lleva le plantilla Yessica
____________________________ ____________________________
Página 2 de 6

Fecha 24/10/2018
Datos de Reunión
Recordatorio de las Tareas Asignadas el Realización Diagramas de Gantt con Equipo Jireh
día Lunes el profesor Mexica
Realizar mapa conceptual de los tipos
de planes
____________________________ ____________________________
Página 3 de 6

Fecha 25/10/2018
Datos de Reunión
Asignación de actividades de la Realización de documentación acerca Equipo Jireh

profesora Barbeyto del software hey
____________________________ ____________________________
Página 4 de 6

Fecha 14/11/2018
Datos de Reunión
Recordatorio de las Tareas Asignadas el Realización Diagramas de Gantt con Equipo Jireh
día Lunes el profesor Mexica
Realizar mapa conceptual de los tipos
de planes
____________________________ ____________________________
Página 5 de 6

Fecha 26/11/2018
Datos de Reunión
Recordatorio de los temas asignados a Repartición de los puntos mas Equipo Jireh
exponer importantes a exponer en expresión
oral y escrita
____________________________ ____________________________
Página 6 de 6

Software HEY

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Software HEY

Transféré par

Droits d'auteur :

Formats disponibles

HEY

Ingreso demedio por la cual se

1.0 INTRODUCTION ............................................................................................................. 1

1.2 PROJECT BACKGROUND

1.3 COMMUNICATION MANAGEMENT PLAN OVERVIEW

Communications Management Plan <HEY> 1

Communications Management Plan <HEY> 2

Communications Management Plan <HEY> 3

Motivo Acuerdo Asistente

Recordatorio de las Tareas Realización Diagramas de Gantt Equipo Jireh

4.6 DATOS DE REUNIÓN

Communications Management Plan <HEY> 4

Comprobante Descripción Importe Fecha Folio

2 Papelería(paquete de folders, 24/10/2018 100

3 Papelería ( papel opalina ,marca 183.80 26/10/2018 1771

4 papelería(hojas negras, 54.10 26/10/2018 1772

Confidential ©JIREH, 2018 Page 1 of 4

Confidential ©JIREH, 2018 Page 2 of 4

Tareas no críticas Tareas marcadas

Hitos críticos Tareas externas críticas

Tareas de resumen Tareas críticas resaltadas

Tareas críticas insertadas Tareas no críticas resaltadas

ITEMS Cumple Observaciones/notas

Fecha Versión Descripción Autor

En esta sección, el lector encontrará dos conjuntos de definiciones. El primer conjunto

Actividad: un conjunto de tareas cohesivas de un proceso.

Paso: en un paquete de despliegue, una tarea es descompuesta en una serie de pasos.

Producto: pieza de información o entregable que puede ser producida (no

3. Descripción de Procesos, Actividades, Tareas,

Figura 1 Prácticas de Gestión de Proyectos

Actividad: Planificación de Proyecto

elementos del Plan de Proyecto corresponden con la definición de

Proceso de Planificación de Proyecto

Objetivos: Determina el alcance de la gestión del proyecto y las actividades

Paso 2. Estimar los recursos, esfuerzo y duración:

Paso 3. Crear un cronograma:

Actividad: Ejecución de Plan de Proyecto

Ejecución de Plan de Proyecto

Objetivos: Implementar el trabajo actual de las tareas del proyecto de acuerdo

El contenido característico de este reporte es:

Paso 3. Tomar acciones correctivas:

Actividad: 4.3 Evaluación y control de proyecto

3.2 Establecer acciones para corregir desvíos o problemas e identificar LT, ET

Evaluación y Control de Proyecto

Objetivos: determinar el estado del proyecto y asegurar que el proyecto se

Roles: Lider de Proyecto

requerir la ejecución de una Acción Correctiva, resultando en un

Paso 2. Identificar desvíos en el plan:

Paso 3. Procesar las solicitudes de cambio:

Actividad: 4.4 Cierre del proyecto

Cierre del Proyecto

Objetivos: liberar los entregables finales al cliente, entregar la documentación

Paso 2. Aceptación del cliente:

Estructura de Descomposición de Trabajo (EDT)

26/10/2018 1.0 Documento para el plan de desarrollo de Cabrera Paulin Miriam

Coryringht JIREH, 2018 Page 2 of 8

2.1 Project Purpose, Scope, and Objectives 5

3.1 Organizational Structure 5

4.1 Project Estimates 6

Coryringht JIREH, 2018 Page 3 of 8

Software Development Plan (Small Project)

Coryringht JIREH, 2018 Page 4 of 8

2.2 Assumptions and Constraints

2.4 Evolution of the Software Development Plan