UNIVERSIDAD TECNOLÓGICA DEL PERÚ

Desarrollo de un sistema web para la gestión de

citas en la posta médica “Santa Clarita”

Carrera: Ingeniería de Sistemas e Informática / Software

Ciclo: 7mo

Curso: Desarrollo de Software I

Docente: MARZAL MARTINEZ, WALTER ROLANDO

Estudiantes:

- Cavero Winchez, Oneyda Johanna - U19217480

- Claure García, José David - U21203243

- Leon Curo, Andy Daniel - U19314056

- Lozano Marroquin, Hector Rodrigo - U19100551

- Nuñez Timoteo, Andony - U18207477

Lima – Perú

2022

1
1. Caso del Negocio 4
1.1. Resumen ejecutivo del proyecto 4
1.2. Análisis del contexto de la empresa 4
1.3. Identificación y definición de los problemas 5
Problema General 6
Problema Específicos 6
1.4. Visión general del proyecto 6
1.5. Alineación del proyecto con los objetivos estratégicos de la empresa 7
1.6. Análisis costo beneficio del proyecto 7

2. Planificación del proyecto 9

2.1. Elaboración del diagnóstico del proceso de desarrollo de software actual 9
2.2. Desarrollo del alcance del proyecto 9
2.2.1. Alcance del proyecto 9
2.2.2. Entregables 9
2.2.3. EDT 9
2.3. Establecimiento del cronograma 11
2.4. Elaboración del presupuesto 13
2.5. Establecimiento estándar de ciclo de vida del proyecto 14
2.6. Elaboración del registro de riesgo del proyecto 16

3. Gestión de requerimientos 17
3.1. Elaboración del proceso de gestión de requerimientos (requisitos) 17
3.2. Definición de requerimientos (Funcionales /No funcionales) 19
3.3. Elaboración de solicitud de cambios a los requerimientos 21
3.4. Desarrollo del formato para validación de los requerimientos; considerando los
conceptos teóricos definidos para cada aspecto según el modelo CMMI nivel 2. 21

4. Seguimiento y control del Proyecto 23

4.1. Elaboración de reportes y estado actual del proyecto 24
4.2. Realización del registro y seguimiento de problemas y riesgos 25
4.2.1. Seguimiento de riesgos 28
4.3. Desarrollo de actas 29
4.4. Seguimiento de acciones pendientes 38
4.5. Elaboración de registros de cambios al proyecto 47

5.- Elaboración del área de medición y análisis del proyecto 50

5.1 Desarrollo de procesos de medición y análisis 50
5.2 Elaboración de métricas del proyecto 51
5.3 Realización del registro de mediciones 53
5.3.1 Procedimientos de recogida y de almacenamiento de datos: 53
5.3.2 Herramientas de análisis de datos. 57

2
6.- Establecimiento del área de gestión de calidad de procesos y productos 59
6.1 Designación de equipo de QA 59
6.2. Establecimiento de proceso de QA 59
6.3. Realización del registro de no conformidades de QA 61

7.- Elaboración del área de gestión de la configuración 63

7.1 Desarrollo del proceso de gestión de la configuración 63
7.2. Elaboración del plan de gestión de configuración 64
7.3. Desarrollo del entorno de gestión de la configuración 64
7.4 Establecimiento de repositorio de información del proyecto 65
7.5 Realización del registro de seguimiento 68

8.- Elaboración del área de gestión y acuerdo con proveedores (SAM) 70

8.1.- Desarrollo sobre la clasificación de las adquisiciones: 71
8.2.- Realización de evaluación de las adquisiciones: 71
8.3.- Elaboración de contrato: 74
8.4.- Desarrollo del informe del estado de las adquisiciones 78

9.- Fase de inicio del proyecto según SCRUM 87

9.1.- Desarrollo de la planificación del lanzamiento del proyecto 87
9.2.- Desarrollo de la visión del proyecto 88
9.3.- Definición de los roles de Scrum 89
9.4.- Desarrollo de las épicas 90
9.5.- Creación del backlog priorizado 91

10.- Elaboración de la fase de planificación y estimación 92

10.1.- Creación de historias de usuario 92
10.2.- Realización de estimación y asignación de historia de usuarios 93
10.3.- Creación de sprint backlog 93

11.- Fase de Implementación 94

11.1.- Creación de entregables 94
11.2.- Mantenimiento de la lista priorizada de pendientes 96

12.- Fase de Revisión y Retrospectiva 97

12.1.- Creación de evidencias de revision y validacion de sprint 97
12.2.- Elaboración de evidencias de retrospectiva de sprint 98

13.- Fase de Lanzamiento 98

13.1.- Creación de la arquitectura del proyecto 99
13.2.- Elaboración de documentación 99

3
 1. Caso del Negocio
1.1. Resumen ejecutivo del proyecto

Los servicios de salud han cobrado alta importancia a ojos de la población en estos
últimos años, esto ha llevado a que los centros de salud tengan una demanda cada
día más elevada. En vista que la posta médica Santa Clarita actualmente no cuenta
con una sistema donde puedan acceder, de forma fácil, segura y actualizada, a las
diferentes citas realizadas, además de cualquier otro tipo de información relativa al
entorno laboral, comercial e institucional.
Es por ello, que presente proyecto surge en base a la idea de mejorar la situación
por la que pasa el personal de la posta médica ya que hemos logrado identificar que
se pierde demasiado tiempo en funciones al no contar con un sistema interno, y que
es posible automatizar y coordinar con la implementación de un sistema web. De
esta forma estaríamos reduciendo los tiempos de registro de cada paciente.

1.2. Análisis del contexto de la empresa

VISIÓN
La posta Santa Clarita tiene como visión crear y sostener un sistema integral de
salud que ofrezca un espacio de crecimiento y desarrollo profesional enfocado en la
excelencia y calidez en la asistencia a los pacientes y su familia.

MISIÓN
Contribuir al cuidado de la vida y la recuperación de la salud, a través de la
prestación de servicios preventivos, centrados en la persona, con un equipo humano
cálido y calificado para satisfacer las necesidades de los pacientes.

OBJETIVO
Brindar un servicio adecuado en el área preventiva de salud y así evitar los altos
índices de contagios o positivos en enfermedades que sea posible prevenir dentro
de la jurisdicción.

4
Organigrama de la empresa

1.3. Identificación y definición de los problemas

La empresa en la que basamos nuestro proyecto es la posta médica 'Santa Clarita', en la

actualidad, los trabajadores no cuentan con una herramienta corporativa que permita
almacenar, administrar y controlar toda la información y protocolos de una empresa de
forma fácil, rápida, segura y actualizada.
Aunque se trata de una empresa pequeña en continuo crecimiento, actualmente ha crecido
el número de clientes y se hace difícil gestionar de manera efectiva las citas, esto ha dado
origen a una baja productividad laboral.
Asimismo, la empresa tiene como meta a mediano plazo mejorar su imagen creando una
cultura de trabajo con un mejor ambiente de trabajo y organización al realizar tareas entre
los trabajadores.
Finalmente, la posta médica busca evitar los estantes llenos de papeles con los registros de
los clientes Y almacenar grandes cantidades de información en una base de datos, por lo
que surge ¿En qué medida la implementación del Sistema Web mejorará la Gestión de
Citas y la productividad interna en la posta médica ‘Santa Clarita’?

Problema General

¿En qué medida la implementación del Sistema Web mejorará la Gestión de Citas

5
en la posta médica Santa Clarita?
Ayudará a mejorar la confiabilidad y disponibilidad del registro de citas así como a reducir el
tiempo que se demora un usuario en atender al paciente.

Problema Específicos

¿En qué medida la implementación del Sistema Web mejorará la Gestión de Citas en la
posta médica Santa Clarita?, en cuanto a funcionalidad?
Cumplirá las funciones del papel de una manera más eficiente y segura pues reducirá el
riesgo de error o de pérdida del papel.
¿En qué medida la implementación del Sistema Web mejorará la Gestión de Citas en la
posta médica Santa Clarita?, en cuanto a la eficiencia?
Logrará mejorar la gestión de citas pues llegará a funcionar de manera que los tiempos de
atención y registro se reducirán considerablemente.
¿En qué medida la implementación del Sistema Web mejorará la Gestión de Citas en la
posta médica Santa Clarita?, en cuanto a usabilidad?
Contará con una alta usabilidad pues implementaremos la metodología de Diseño Centrado
en el Usuario (DCU) esto lo lograremos involucrando al usuario en las fases de
conceptualización y pruebas.

1.4. Visión general del proyecto

1.4.1. Propósito, alcance y objetivo:

a) Propósito: Optimizar el proceso de registro de citas al implementar una

herramienta que permita una mayor rapidez. Aumenta la eficiencia y productividad
de la organización.

b) Alcance: Desarrollar un sistema web que facilite la gestión de citas de la posta

médica Santa Clarita.

c) Objetivos:
Objetivo general:
● Desarrollar e implementar un sistema web que permita mejorar la gestión
automatizada del proceso de reserva de citas de la posta médica Santa
Clarita.
Objetivos específicos:
● Reducir el tiempo requerido para gestionar las citas en un 20%
● Aumentar la satisfacción de los pacientes en un 15%
● Reducir los errores reportados en la gestión de citas como pérdida o
confusión en un 40%

6
 1.5. Alineación del proyecto con los objetivos estratégicos de la empresa

En esta sección se planea presentar los objetivos estratégicos de la posta médica Santa
Clarita , estos representan los objetivos generales y de largo plazo que buscan definir el
rumbo de la empresa; para luego mostrar una tabla con el despliegue de los objetivos
estratégicos organizacionales y los objetivos del proyecto de software.

Para el 2023 se plantean los siguientes objetivos estratégicos:

• Llevar un control de la información más organizado.
• Mejorar la imagen de la empresa brindando hacia los pacientes un servicio eficiente y
rápido.
• Mejorar los indicadores de atención.
• Posicionarse como líder dentro de la red de salud por la calidad en la atención.

Alineación de los objetivos del proyecto con los objetivos estratégicos de la posta médica

1.6. Análisis costo beneficio del proyecto

El análisis costo-beneficio mide la relación entre los costos y beneficios asociados a un

proyecto de inversión, en este caso a una propuesta de mejora, con el fin de evaluar su
rentabilidad.

A continuación, se muestra la estimación de la inversión que debe realizar la posta médica

Santa Clarita para el desarrollo del proyecto:

7
Figura X. Presupuesto del proyecto
Fuente: elaboración propia

Los beneficios producidos por la implementación de una nueva tecnología, en este caso un
sistema web, aunque requiere una inversión inicial para tu total implementación, a medio
plazo supone un ahorro de tiempo mejorando el tiempo de respuesta, esto ayudando en la
generación de informes o reportes estadísticos, que apoyen la toma de decisiones; por lo
tanto conlleva a un ahorro de costos.

“De acuerdo a un estudio realizado por el Delphi Group®, el 98% de las instalaciones de
intranets dan un Retorno Sobre la Inversión (ROI) favorable, siendo un indicador muy
importante en comparación con otras aplicaciones, como por ejemplo CRM en donde éste
valor alcanza solamente un 60% y menos aún ERP, BPM, etc.. Del mismo estudio se
desprende que el 22% de las firmas encuestadas reportaron un ROI de entre el 22% y el
50%, mientras que un 18% reportaron ROI superiores al 100%.
Otro estudio realizado el año pasado por la International Data Corporation (IDC) acerca del
Retorno Sobre la Inversión (ROI) en proyectos de intranet corporativas revela qué
implementaciones comunes respaldadas por una decisión estratégica alcanzar un ROI
mayor a 1000 por ciento.”

(Beneficios de usar una Intranet. (s/f). Innovaportal.com. Recuperado de

https://www.innovaportal.com/innovaportal/v/77/1/innova.front/beneficios-de-usar-una-
intranet)

8
2. Planificación del proyecto
2.1. Elaboración del diagnóstico del proceso de desarrollo de software actual

Cada hospital, clínica o posta del mundo tiene un registro de los clientes,
datos importantes de ellos, y un historial de citas, también tiene el historial
e información de los médicos que están trabajando en la posta.
Actualmente esta posta no tiene un sistema actualizado, tiene equipo
obsoleto, también que solo guardan su historial mediante hojas en un
fichero, haciendo este una pérdida de tiempo en su búsqueda de datos de
paciente.
Se está desarrollando un sistema web que ayude al registro de datos de
pacientes, médicos y generación de citas, evitando la búsqueda o
transcripción física de sus datos.

2.2. Desarrollo del alcance del proyecto

2.2.1. Alcance del proyecto

Para este proyecto, se está creando un sistema web que ayude con:
● Gestión de la atención de los pacientes en citas, registrar sus datos,
ver su historial si están en el sistema o no, o eliminarlos(ocultarlos) si
están inactivos durante varios años.
● Gestión de los datos del personal de trabajo, sus datos, historiales de
atención o eliminarlos(ocultarlos) en caso el trabajador se retire de la
posta.
2.2.2. Entregables
Para el cierre del proyecto se entregara lo siguiente a la posta:
● Manual del sistema web
● Sistema web y Base de datos
● Credenciales para el acceso
2.2.3. EDT

9
10
2.3. Establecimiento del cronograma

11
Secuencia de tiempo

12
 2.4. Elaboración del presupuesto

Reuniendo información de la posta y necesidades del equipo encargado del

proyecto podemos recaudar:

Descripción Monto

Compra de software o hardware 4000 S/:

necesarios para trabajar en el proyecto

13
 Pago de trabajadores C/U 5000 S/.

Instalación y configuración de equipos 100 S/.

más base de datos c/u

2.5. Establecimiento estándar de ciclo de vida del proyecto

Inicio

o Verificar la información del hospital y analizar los puntos que necesita el

cliente, también cronometrar la duración del proyecto.

o Identificar funciones que requiere la posta y que sean eficientes.

o Analizar software y hardware requeridos para el sistema web

o Verificar el uso de lenguaje que se programará durante el desarrollo del

sistema web

Diseño

o Revisar la propuesta, enfoque y metodología.

o Revisar el alcance.

o Validar calendario y entregables de proyecto.

o Desarrollar arquitectura, el modelo como ira la pagina y las plantillas que

se usaran.

14
o Se evaluará si la arquitectura y las plantillas son validas de usar para el
proyecto.

Desarrollo

o Revisar y validar el alcance, entregables y avance respecto a la

planificación.
- Documentación completa de cualquier cambio de alcance y validación
del mismo.
- Revisar y validar todos los entregables generados durante el desarrollo
del proyecto.

o Ejecutar la planificación y en diseño al proyecto

o iniciara con la creación de cada acción del sistema.

o Gestionar los riesgos identificados que pueda tener el software.

o Realizar de forma periódica reuniones de seguimiento (según

periodicidad establecida).

Cierre

o Validar los documentos finales.

o Evaluar los resultados del proyecto: calidad de los productos, encuestas

de satisfacción realizadas, experiencias de éxito y negativas, obstáculos
encontrados, riesgos identificados, etc.

o Liberar los recursos utilizados durante el desarrollo del proyecto: baja de

proyecto y recursos en las distintas herramientas corporativas.

o Entregar un manual con las acciones que realizará el software y instalarlo

en su sistema

15
 2.6. Elaboración del registro de riesgo del proyecto

RIESGO DESCRIPCIÓN DESCRIPCI PROBABILI NOTAS DE

DEL RIESGO ÓN DEL DAD DE MITIGACIÓN
IMPACTO RIEGO

Múltiples Se registra el Se podría Probable Validaciones a la

ingresos del mismo dato de crear varios hora de ingresar
mismo dato un paciente malentendid los datos
varias veces os
que no se lleva
un informe
correcto

Falta de Se asigno solo Podría crear Probable Adquirir discos

espacio para el 250GB de un problema duros mayores a
llenado de almacenamiento en la 1TB
información en atención al
la BD cliente en la
parte de
citas

Falta de Un integrante Podría No probable Capacitar al

conocimientos del equipo no retener el involucrado en
en el equipo tiene los desarrollo los
conocimientos del software requerimientos
necesarios para necesarios
ayudarnos

Información Información de Afecta a los Probable Realizar un

importante pacientes y pacientes y backup e
eliminada doctores doctores en implementar una
faltantes en la el control y validación al
BD desarrollo momento de
del historial hacer cambios
en el en la BD
sistema

No contar con No se cuenta Podrian Muy Comprar un

16
antivirus con un antivirus robar los probable antivirus
para proteger la datos
información personales
de los
pacientes y
medicos

No especificar No escribir las El Muy Corregir y

en el manual funcionalidades encargado probable especificar cada
correctamente no sabría función del
en el manual como software en el
del cliente registrar, manual
editar,
eliminar o
sacar citas a
los clientes

3. Gestión de requerimientos
3.1. Elaboración del proceso de gestión de requerimientos (requisitos)

En base al estándar de CMMI nivel 2, para desarrollar el proceso de gestión de

requisitos se debe tener en cuenta los objetivos de este proceso, los cuales nos
permitirán desarrollar, asegurar la alineación entre los requisitos del usuario y los
planes del proyecto. Los objetivos son los siguientes:

● Obtener, comprender y revisar los requisitos

Los requerimientos de usuario definirán las funcionalidades que deberá

cumplir el software, esto a partir de la información identificada desde la
perspectiva del usuario. Los requerimientos deben ser claros, completos y
concisos. Esto se coloca en la Especificación de Requisitos de
sistema(ERS), junto con las pruebas de aceptación de requisitos. Los
implicados que han colaborado en la elaboración de los requisitos
analizarán los requerimientos con el cliente para asegurar que se alcanza
una comprensión compatible y compartida del significado de los requisitos.

17
 Y finalmente corroborar si cumplen con los criterios de aceptación
definidos.

● Validar los requerimientos

Se valida la aprobación de los requisitos por parte de los interesados y se

procederá a informarse sobre la aprobación de los requisitos.

● Definición y mantener la trazabilidad

❖ Definición de la trazabilidad

La definición de la trazabilidad identifica todo lo que está relacionado en el

proyecto, como los requisitos , los involucrados en el desarrollo de los
requisitos (cliente, y los responsables de su implementación) y la
planificación de las actividades. De esta forma,nos permite ocupar toda la
implementación de los requisitos y analizar el impacto que tendrá en la
gestión de cambio, y tener un control ante posibles amenazas.

❖ Mantener la trazabilidad de los requisitos

La intención de esta práctica específica es mantener la trazabilidad

bidireccional de los requisitos. Cuando se gestionan bien los requisitos, se
puede establecer la trazabilidad desde un requisito fuente hasta sus
requisitos de más bajo nivel y desde estos requisitos de más bajo nivel de
vuelta hasta sus requisitos fuente. Esta trazabilidad bidireccional ayuda a
determinar si todos los requisitos fuente se han tratado totalmente y si
todos los requisitos de nivel más bajo pueden trazarse hacia una fuente
válida (CMMI, 2010).

● Gestionar los cambios a los requisitos.

El cambio de los requisitos surge cuando se encuentran defectos con

respecto a lo solicitado por el cliente o si falta alguna especificación
requerida. En ese caso se procede a analizar el impacto de los cambios en
los requisitos, es fundamental que se comprenda la utilidad de cada requisito
y que esté documentado el análisis de evaluación de cualquier cambio. Se
realizará una revisión a los cambios realizados a los requisitos y se evaluará

18
si son aceptadas por el cliente y los involucrados en el proyecto, de igual
forma si se aprueba el cambio, se tendrá que dar seguimiento a los requisitos
modificados, ya que puede afectar a otros requisitos de usuario, si este no es
controlado. Por lo cual, sería ideal plantear requisitos que cumplan con las
exigencias del cliente y este a las expectativas del proyecto, con el objetivo
de evitar que se retrase la fecha de entrega y el incremento del costo del
proyecto.

Tal como menciona Peña (2009) el proceso de gestión del cambio en

requisitos son los siguientes:

● Registrar los cambios que se desean incorporar en los requisitos.

● Analizar el impacto que provocará la introducción del cambio.
● Evaluar el impacto de los cambios en el proyecto.
● Permitir el seguimiento de los cambios en los requisitos registrados
para un proyecto.

Esta cita nos ayuda a comprender de una manera más simplifica el proceso
que se debe realizar en el cambio de requisitos.

3.2. Definición de requerimientos (Funcionales /No funcionales)

19
 Para llevar a cabo esta actividad se realizó una reunión virtual con las
partes implicadas en el desarrollo del proyecto y se identificaron los
requisitos de usuario, los cuales son presentados en la siguiente tabla.

Condiciones de prueba de Aprobación

20
3.3. Elaboración de solicitud de cambios a los requerimientos

Se presenta una hoja de cambios para realizar una mejora en los requisitos
anteriormente presentados. Si se registra una petición de cambio por parte

21
del cliente, este será evaluado por los implicados y se verificará si la
modificación afecta a otros requerimientos.

3.4. Desarrollo del formato para validación de los requerimientos;

considerando los conceptos teóricos definidos para cada aspecto
según el modelo CMMI nivel 2.

La siguiente matriz de valoración de los requisitos, es la que nos permite

valorar si el requisito cumple con todas las etapas llevadas a cabo en la
metodología. En caso de que todos los criterios se cumplan se dará por
cerrado y aprobado el requisito.

Modo de desarrollo, la persona encargada de revisar la lista de chequeo

deberá tener en cuenta todo el proceso y documentación de la metodología
para así dar un dictamen correcto, el manejo es el siguiente.

Cumple=C, No Cumple= N y No aplica= En caso de que el criterio no aplique

en ese caso para el requisito se mostrar en amarillo informando que no hay
problema.

22
23
 4. Seguimiento y control del Proyecto

Aquí se establece el conjunto de acciones que se llevarán a cabo para la

comprobación de la correcta ejecución de las actividades del proyecto con el fin de
proporcionar un conocimiento en cómo va encaminado el progreso de este y así
poder tomar acciones correctivas cuando el proyecto se desvíe de su planificación
inicial. Estas actividades son responsabilidad del project manager, estas están
movidas por la necesidad de rendir cuentas sobre el logro de los resultados, los
recursos que se le han confiado y el aprendizaje de la organización.

La etapa de seguimiento y control se encuentra asociada a la ejecución, ya que se

desarrolla a lo largo del proyecto hasta que este finalice.

Las tareas a realizar durante el seguimiento y control de Proyectos son los

siguientes

24
 4.1. Elaboración de reportes y estado actual del proyecto

En este punto el project manager elabora dicho documento con el fin de informar el
conocimiento del progreso del proyecto y además de ser una herramienta muy útil
para la gestión del proyecto.

● Comunicar el grado de progreso del proyecto.

● Informar de las incidencias y riesgos encontrados.
● Proponer un plan de acciones a realizar para el próximo periodo de
seguimiento.
● Comunicar la relación de entregables y cambios que deban ser aprobados.
● Resaltar modificaciones en el alcance o peticiones de cambio

25
 4.2. Realización del registro y seguimiento de problemas y
riesgos

Es particularmente clave en aquellos procesos que tienen un impacto directo

sobre el servicio de nuestra empresa. También será imprescindible realizarlo, no
sólo cuando haya un impacto financiero o económico, sino cuando pueda afectar a
ámbitos clave de la organización o proyecto como la reputación corporativa o la
gestión de los recursos humanos de la compañía.

Para realizar este registro seguimos los siguientes pasos:

1.- Identificación: primero se realizó una lista de todos los casos en los que
se podrían presentar y riesgos que podrían afectar al proyecto.

● Se consultó con todos los involucrados en el proyecto

● Se organizó una lluvia de ideas sobre los riesgos posibles con el
equipo de proyecto.
● Se documento y ratificó los supuestos
● Se consultó una lista de verificación (Check List)

2.- Análisis de riesgo: por cada riesgo encontrado se analizó la gravedad y

el plan de respuesta. Se registró la fecha en la que ocurrió dicho evento y se
clasificó en una categoría de riesgo.

3.- Priorización: para establecer las prioridades de los riesgos, nos

percatamos cual tenía mayor probabilidad de producirse o cuales eran
potencialmente los que podrían afectar más al proyecto.

4.- Asignación: dependiendo la complejidad y otros factores se eligió un

responsable distinto. La persona asignada se encargó de controlar el caso,
tomó las decisiones y desarrolló un plan de mitigación de riesgos con todo su
equipo a cargo.

5.- Supervisión: se mantiene en revisión cada riesgo en conjunto con los

encargados de estos, para ello se realizó lo siguiente:

● Se envio actualizaciones de estado con regularidad

● Se consulto con frecuencia a los gerentes responsables de
cada riesgo

26
● No se perdió de vista el registro de riesgos para enterarnos de
las novedades.

27
28
4.2.1. Seguimiento de riesgos

29
 4.3. Desarrollo de actas

El project manager convocará mediante un email a los diferentes miembros del

proyecto para la reunión de seguimiento, durante la reunión se validará el informe
de seguimiento correspondiente comprobando así que todos los acuerdos
especificados en reuniones anteriores estén registrados en el informe actual, aquí
comentaremos los posibles riesgos y problemas asociados a la ejecución del
proyecto y en el caso que sea necesario comunicar modificaciones en el alcance del
proyecto.

El project manager elaborará el Acta de Reunión de Seguimiento y

actualizará el Informe de seguimiento con los comentarios aportados en la reunión.
El objetivo es poder recoger todos los temas tratados, así como los temas
pendientes y futuros pasos a realizar en el proyecto.

A continuación se muestra la agenda de nuestras reuniones durante la realización

del proyecto:

30
31
32
33
34
35
36
37
38
 4.4. Seguimiento de acciones pendientes

Una acción pendiente es una tarea creada durante o luego de una reunión con otros
participantes para lograr que un proyecto avance hacia el logro de sus objetivos. Las
acciones pendientes pueden ser parte de un plan de acción o una lista de tareas
mayor, y son tan importantes para la gestión de proyectos como las reuniones
efectivas. Las acciones pendientes son esenciales para el éxito de un proyecto, pero
se deben comunicar claramente las acciones que se deben tomar después de una
reunión.

39
Con respecto a cada reunión agendada mostrada anteriormente, ahora se
mostrarán los acuerdos, tareas y puntos pendientes de cada una de ellas:

40
41
42
43
44
45
46
47
48
4.5. Elaboración de registros de cambios al proyecto

Un proceso de control de cambios permite a los gerentes de proyectos

enviar solicitudes a las partes interesadas para su revisión, que luego se
aprueban o rechazan. Un proceso de control de cambios eliminará la
confusión en torno a los entregables del proyecto y permitirá que te centres
en la ejecución en lugar de recopilar información.

Es un proceso importante para ayudar a gestionar grandes proyectos

con muchas piezas en movimiento. Aquí se encuentra detallado todos los
cambios que ha tenido el proyecto coordinando el presupuesto, el
cronograma, las comunicaciones y los recursos.

49
Asana

50
5.- Elaboración del área de medición y análisis del proyecto

5.1 Desarrollo de procesos de medición y análisis

En esta sección de Medición y Análisis (MA) tiene como propósito desarrollar

y mantener la capacidad de medición utilizada para dar soporte a las
necesidades de información de la gerencia.

La primera actividad que se va a desarrollar es especificar los objetivos de

medición y análisis para alinearlos con las necesidades de información y con
los objetivos del proyecto, de la organización o del negocio.

En la siguiente tabla se muestra el despliegue de los objetivos de medición

en función a los objetivos de la organización y del proyecto para dar a
conocer el motivo de la medición y análisis. Los objetivos están sujetos al
cambio, por lo cual se procederá a actualizarlos cada cierto tiempo.

51
5.2 Elaboración de métricas del proyecto

52
53
5.3 Realización del registro de mediciones

5.3.1 Procedimientos de recogida y de almacenamiento de datos:

Especificados previamente los indicadores se procede a establecer los

mecanismos de recogida de datos, los cuales son formularios y plantillas
automatizadas.

INSTRUMENTO DE RECOLECCIÓN DE DATOS

Estimado Sr.(a), el presente cuestionario forma parte del proyecto

titulado: Desarrollo de un sistema web para la gestión de citas en la posta
médica “Santa Clarita”, el cual tiene fines exclusivamente académicos.
Agradecemos su comprensión.

Instrucciones: Lea detenidamente las preguntas formuladas y responda

con seriedad, marcando con un aspa (X) en la alternativa que considere
conveniente.

54
55
56
 PLANTILLA DE CUMPLIMIENTO DE ACTIVIDADES

Permitirá administrar visualmente el cronograma del proyecto, los Sprints y la

duración de las tareas, realizar un seguimiento a los requisitos y asegurar
que todos los sprints del proyecto se mantengan encaminados.

5.3.2 Herramientas de análisis de datos.

Indicador: % de variación de los costos del planificados para el

proyecto.

Para conocer si se está generando pérdidas económicas en el proyecto. Se

usará la herramienta MS Project, para poder calcular automáticamente el
valor planificado(PV), mientras que el costo real(CR) será obtenido de las
horas reales invertidas en las tareas del proyecto.

A partir de eso se calculará el Índice de Rendimiento del Costo (IRCosto). El

IRCosto es igual a la razón entre el VG y el CR. El IRCosto es el indicador de

57
eficiencia de costos más comúnmente usado. Un valor del IRCosto inferior a
1.0 indica un sobrecosto con respecto a las estimaciones. Un valor del
IRCosto superior a 1.0 indica un costo inferior con respecto a las
estimaciones. Fórmula: IRCosto = VG / CR.

Imagen. Análisis del valor Ganado(PMI,2004)

Indicador: % Cumplimiento de las actividades especificadas del

proyecto en el plazo establecido.

Se aplicará el uso de la Plantilla de cumplimiento en la cual se tiene el

registro de los hitos realizados en el tiempo planificado. El resultado obtenido
al aplicar la fórmula, será representado en un diagrama de tarta, para mejor
interpretación y la toma de decisiones.

Indicadores : Medir la satisfacción del cliente y % Eficacia de los

reportes brindados.

De los resultados obtenidos de la encuesta se procederán a realizar 2 tablas

para cada indicador, de las cuales se obtendrán xi( Frecuencia absoluta) y fi .

Para calcular el nivel de satisfacción del cliente se realizará la suma de

puntuaciones d= xi*fi = y el total de valoraciones obtenidas = muestra total.

Nivel de Satisfacción: xi*fi/muestra

58
 En el caso de % de eficacia de los reportes desarrollados ,se aplicará la
misma fórmula xi*fi = y el total de valoraciones obtenidas = muestra total.
% Eficacia : xi*fi/muestra

Los resultados obtenidos serán almacenados en C:\user\misdocumentos\

Resultados. En el caso de los indicadores de %Eficacia de los reportes
brindados y Medir la satisfacción del cliente, se realizará el recojo de los
datos al finalizar el proyecto para su posterior análisis.

6.- Establecimiento del área de gestión de calidad de procesos y

productos

6.1 Designación de equipo de QA

Rol Encargado Funciones

Jefe de QA Claure García, José Supervisión de todas las

David operaciones que afecten
a la calidad.

Analista QA Cavero Winchez, Oneyda Revisar, monitorear y

Johanna supervisar el
Lozano Marroquin, Hector cumplimiento de los
Rodrigo procedimientos y el plan
de aseguramiento y
control de calidad de las
pruebas a realizar.

Desarrolladores Leon Curo, Andy Daniel Encargado del diseño e

implementación del
cambio en el código del
programa

6.2. Establecimiento de proceso de QA

En el presente proyecto, con el fin de prevenir errores en la etapa de desarrollo del

Software, el equipo está aplicando la Metodología de Diseño Centrado en el Usuario
junto a la Ingeniería de requisitos basada en pruebas (Test-Driven Requirements
Engineering) bajo el Modelo de Verificación y Validación.

59
 Figura x: Modelo de Verificación y Validación.

Como se observa en la figura, se pueden observar todos los pasos necesarios para
la realización completa de un sprint, desde la formulación de la necesidad hasta la
verificación final de su conformidad con esta misma necesidad.

Al inicio de cada Sprint, el equipo define el objetivo que se define los el objetivo que
se quiere lograr en base a los requisitos del cliente, estos mismos quedan
establecidos como las Pruebas de Aceptación que se deben cumplir para alcanzar
dicho objetivo del Sprint.

Las fases son las siguientes:

● Identificación: Se obtienen los requisitos del cliente.

● Definición: Se especifica el contenido del requisito y se decide si será
realizado o no.

60
 ● Implementación: Los programadores y analistas escriben código con el fin de
cumplir los objetivos del Sprint.
● Diseño de pruebas: El Tester verifica y valida la funcionalidad del software
desarrollado. De misma manera, Los programadores junto a los analistas
realizan las Pruebas de Integración y Pruebas Unitarias.
● Aplicación: Se valida la implementación.

Posteriormente, el jefe de QA asegura que el software desarrollado funciona

correctamente antes de entregarla a los clientes y dar por concluido el Sprint.

De esta manera se explicó porque definir las Pruebas de Aceptación son pieza clave
para el desarrollo, de esta forma para mitigar fallos en el producto.

6.3. Realización del registro de no conformidades de QA

Según ISO 9001, la no conformidad es el incumplimiento de los requisitos

especificados, por lo tanto aparece un fallo o un error en una empresa debido a que
no se han ejecutado bien los procesos que se han establecido.

Para realizar la gestión de la No conformidad se sigue el siguiente flujo que incluye

6 pasos:

Crear informe de no Conformidad

Corrección

Análisis de las causas

Establecer acción correctiva

Verificar acción correctiva

Cierre de no conformidad

Informe de No Conformidad

Tipo Solución temporal

Prioridad Medio
Recursos Retroalimentación
Procesos

61
Descripción detallada

Insertar foto (Opcional)

Nombre y firma del personal

encargado

Figura: Informe de No Conformidad

Checklist de revisiones de las No Conformidades

CheckList de No Conformidades
Item Detalle Resuelto
1 Falta de Documentación ✔️
2 Registro de errores ✔️
3 Cliente no satisfecho ✔️
4 Personal no capacitado ✔️
5 Servidor con capacidad limitada ❌
6 Falta de procedimientos ✔️
7 No documentar las no conformidades ❌
8 No se han identificado los procesos ✔️

Figura: Checklist de No conformidades

4. Elaboración del informe de seguimiento a las revisiones de QA

Desarrollo de un sistema web para la Posta Médica "Santa

Proyecto Cliente
gestión de citas Clarita"
Equipo G07 Fecha 15/10/2022

Objetivos Identificar y corregir problemas en

62
 procesos causados por el
incumplimiento un requisito, además de
evitar su recurrencia
Estado y Avances
- Se solucionó la falta de documentación en el código, esto nos ayudo a prevenir posibles errores
futuros.
- Se registraron y solucionaron los errores en el producto.
- Prototipos aprobados por el cliente.
- Se identificaron todas las necesidades del cliente intercambiando ideas y retroalimentación del
mismo.
- Se lograron definir los procesos y procedimientos del proyecto.
Problemas o Riesgos Recomendaciones
Adquirir mayor almacenamiento si
Servidor con capacidad limitada es necesario
No documentar las no conformidades Revision del sistema

7.- Elaboración del área de gestión de la configuración

7.1 Desarrollo del proceso de gestión de la configuración

Se gestionan los avances de la configuración que son:
la planificación de diagramas que nos ayudaría a evaluar necesidades que
tenemos para poder desarrollar el software del cliente poder desarrollar el
software del cliente.
● la gestión del lenguaje de programación y con qué entorno hacer, es
importante de toda consultora tener un lenguaje fijo o auxiliar para
hacer el software.
● Análisis de los estados de las computadoras para averiguar si
necesitan un mantenimiento y evitar retrasos más adelantes, también
se verifica la base de datos para que no tenga problema con el código.

63
 ● Necesitar la autorización de cambios o modificaciones al cliente, esto
ayudaría a optimizar más el sistema en base a las necesidades de la
persona u empresa.
● Manual de usuario, esto se desarrolla después de los cambios hechos
al proyecto.

7.2. Elaboración del plan de gestión de configuración

El análisis de proyecto indica que se tiene que llevar un plan que ayude a que
el producto final salga correcto dentro de la consultora, con cada modificación
y agregados dependerá de cada persona trabajando en este
proyecto,autorizado también por el cliente.
tenemos que identificar los elementos de la configuración:
● Diagramas.
● Github.
● hardware.
● programas.
● prototipos.
Con esto se pondría a cargo a las personas que harán cambios a los
elementos identificados.
● Rol de cambios en los equipos y programas del proyecto: Andy Daniel
Leon Curo
● Rol de cambios en la documentación general del proyecto:Jose
● Rol de cambios en planificación:Rodrigo
● Rol de cambio en prototipos:Jose
● Rol de cambios en la evaluación de estructura del proyecto:Oneyda
● Rol de cambios en el desarrollo de programación del proyecto:Andony

64
7.3. Desarrollo del entorno de gestión de la configuración
Reconociendo las líneas base de nuestro proyecto, se ha creado un control
de versiones para ir viendo el ritmo que va teniendo el proyecto.
Para la elaboración de esto usaremos:
● Spring boot
● Mysql
● bootstrap
● drive
● Github
● Draw IO
● balsamiq
● adobe illustrator

7.4 Establecimiento de repositorio de información del proyecto

Para este proyecto estamos usando Drive, para poder hacer la
documentación y tratar de corregir unos cuantos detalles del proyecto.

65
En caso al programa estamos trabajando en base a Github, en el cual los
trabajadores podemos hacer cambios al proyecto tanto el diseño como en
código fuente.

7.5 Realización del

66
 8.- Elaboración del área de gestión y acuerdo con proveedores
(SAM)

Cubre la adquisición de productos o servicios que serán entregados al cliente o que se

requieren para su desarrollo o mantenimiento. Estas prácticas del área de proceso
también pueden ser utilizadas para otros propósitos que beneficien el proyecto. Para
minimizar los riesgos del proyecto, este área de proceso puede tratar también la
adquisición de productos y de componentes de producto importantes no entregados al
cliente del proyecto, pero usados para desarrollar o mantener el producto o servicio.

Diagrama de flujo para seleccionar al proveedor

67
8.1.- Desarrollo sobre la clasificación de las adquisiciones:

Como consultora principal de la posta médica Santa Clarita en conjunto con

el departamento de proveeduría nos encargamos de realizar la búsqueda y selección

de proveedores que mejor se adecuen a las necesidades de la organización

Para ello tomamos en cuenta el impacto que tendrían los productos o servicios que

ofrecian y si esta seria un impacto positivo con la productividad, calidad y

competitividad de la organización. Se hizo una exhaustiva búsqueda donde se tomó

todas las fuentes de información existentes para poder localizar estos proveedores.

Entre estas sitios web, recomendaciones, prensas, directorios telefónicos,

redes sociales, etc…

Lista de requerimientos y criterios que deseamos conocer:

● Adquisición de equipos y servicios de telecomunicaciones.

● Adquisición, mantenimiento de equipos, servicios eléctricos y/o electrónicos.
● Adquisición de software, equipos y servicios TI.
● Adquisición de auditoría y evaluación de personal.
● Adquisición de equipos de limpieza y seguridad material/humana.
● Adquisición de servicios de salud ocupacional.
● Adquisición de inmueble e infraestructura.
● Adquisición de sistema de seguridad informática y prevención de intrusos.
● Adquisición de servicios de capacitación para labor empresarial.
● Adquisición de servicios de asesoría contable y tributaria.

8.2.- Realización de evaluación de las adquisiciones:

Las evaluaciones de proveedores Ti han sido evaluados con parámetros objetivos, que al fin y

al cabo son los que nos permitieron comparar un proveedor con otro:

Teniendo una recopilación de los posibles proveedores se inicia el contacto directo o telefónico

68
para solicitar citas con los encargados de ventas o enviar correos solicitando información

necesaria para la selección de proveedores según los siguientes aspectos:

Tabla 1. criterios

Para establecer la relevancia entre criterios [Tabla 1] se tuvo en cuenta el orden de importancia

que tiene para la consultora, como segunda medida como segunda medida los requisitos

que afectan directamente el cumplimiento ante el cliente final por los compromisos adquiridos

por el área comercial y como tercera el cumplimiento de requisitos legales que salvaguardan

69
la integridad de la empresa.

En este momento se verifica si los proveedores contactados cumplen las expectativas en

cuanto a los criterios solicitados, es ahí donde se crea un cuadro comparativo entre ellos,

de esta forma se puede tomar una decisión de manera más fácil para que el proveedor

forme parte del panel de posibles proveedores de la organización.

70
Estos son los proveedores que cumplen los criterios mencionados anteriormente, de los

escogimos uno por servicio.

Tabla 3: Posibles proveedores

71
8.3.- Elaboración de contrato:

Administrar los documentos que comprueban relaciones comerciales considerando las

buenas prácticas que favorecen la conformidad legal, tributaria y financiera, algo esencial para la

vigencia de las actividades y el crecimiento corporativo.

Es por ello que de acuerdo a la relación y particularidades que tenemos con nuestros proveedores

optamos por hacer contratos de precio fijo y actas de conformidad donde ambos establecimos

un determinado precio independientemente de las circunstancias externas.

72
73
74
8.4.- Desarrollo del informe del estado de las adquisiciones

Lo que hicimos fue elaborar una ficha por proveedor, donde se les evaluó
con respecto a los criterios estipulados en la Tabla 2. Además, una tabla de
puntuación con la siguiente descripción:

Tabla 4. Sistema de Puntuación

75
 Tabla 5. Actividades a mejorar

Estas calificaciones serán enviadas a cada uno de los proveedores evaluados con
la respectiva retroalimentación basada en sus calificaciones de acuerdo al
siguiente formato el cual busca la mejora continua en el desempeño de cada
proveedor. En caso el resultado del proveedor fuera inferior a 4 inmediatamente
será notificado que ingresa a proceso de reevaluación.

76
El resultado de la evaluación de Proveedores para la empresa Telefonica del Peru
S.A.A es de 4.05 como se mencionó anteriormente este puntaje conlleva a un buen
comportamiento como proveedor.

77
El resultado de la evaluación de Proveedores para la empresa Egener S.A.C es de
3.1 como se mencionó anteriormente este puntaje necesariamente conlleva la
reevaluación. El proveedor deberá mejorar su desempeño en calidad de
entregables, precio unitario, Rappels y localización geográfica basándose en la
tabla 4.

78
El resultado de la evaluación de Proveedores para la empresa IBM del Peru S.A.C
es de 4.1 como se mencionó anteriormente este puntaje conlleva a un buen
comportamiento como proveedor.

79
El resultado de la evaluación de Proveedores para la empresa Egener S.A.C es de
1,95 como se mencionó anteriormente este puntaje necesariamente conlleva a la
suspensión. Se evaluará la posibilidad de contratar otro proveedor en caso no haya
una mejora rápida.

80
El resultado de la evaluación de Proveedores para la empresa DE & AD Ingenieros
S.A.C es de 4.2 como se mencionó anteriormente este puntaje conlleva a un buen
comportamiento como proveedor.

81
El resultado de la evaluación de Proveedores para la empresa Ocp Tech Peru
S.T.L es de 4.15 como se mencionó anteriormente este puntaje conlleva a un buen
comportamiento como proveedor.

82
El resultado de la evaluación de Proveedores para la empresa Inversiones Econ
S.R.L es de 3 como se mencionó anteriormente este puntaje necesariamente
conlleva la reevaluación. El proveedor deberá mejorar su precio unitario, Rappels,
cumplimiento del presupuesto, lineamiento con las normas técnicas y el personal de
instalación disponible basándose en la tabla 4.

83
9.- Fase de inicio del proyecto según SCRUM

9.1.- Desarrollo de la planificación del lanzamiento del proyecto

Las ideas fueron:

84
9.2.- Desarrollo de la visión del proyecto

Como equipo buscamos captar la atención e interés de algún cliente potencial o un posible colaborador con el fin de marcar el valor del
nuestro negocio priorizando las épicas y las historias de usuario.

85
9.3.- Definición de los roles de Scrum

Ya que por falta de presupuesto por ahora al solo ser cinco personas hicimos un solo equipo scrum con las personas necesarias para
que el proyecto se termine de manera satisfactoria.

86
9.4.- Desarrollo de las épicas

Se realizó un total de 4 sprints para la realización de todo el proyecto y cada epica ha sido dividida como se muestra en el siguiente
cuadro.

87
9.5.- Creación del backlog priorizado

88
10.- Elaboración de la fase de planificación y estimación

10.1.- Creación de historias de usuario

89
10.2.- Realización de estimación y asignación de historia de usuarios

Para el desarrollo de la estimación de las historias de usuario, se realizó una reunión

de planning Poker con los miembros del equipo, en la cual los integrantes del
proyecto asignaron puntos de historia a las historias de usuario en función a la
complejidad y del volumen del trabajo. Para ello, se usó la aplicación Scrum Poker
como medio de votación para estimar los puntos de historia, se aplicó la secuencia
estándar (0, 1, 1/2, 1, 2, 3, 5, 8, 13, 20, 40, 100) para facilitar el modo de votación.

Historias de usuario estimadas

10.3.- Creación de sprint backlog

Las tareas definidas en cada Sprint fueron seleccionadas en una reunión de equipo
denominada Sprint Planning Meeting. Para esta reunión los miembros del equipo
determinaron las tareas que lo conforman, la duración de estas y el responsable de
cumplirla.

90
 11.- Fase de Implementación

11.1.- Creación de entregables

El presente proyecto se dividió en 4 sprints de aproximadamente 4 semanas cada uno. Las

salidas o entregables que se van a entregar a lo largo de cada Sprint son:

Sprint N°1

Sprint N°1

Fecha de inicio 26/01/2022

Fecha de fin 24/02/2022

Revisión de los avances Las fechas de revisión serán las

siguientes:
02/02/2022
09/02/2022
18/02/2022

● Página principal
Entregables
● Acceso al sistema (Login)
● Creación de doctores
● Gestionar datos de doctores

Sprint N°2

Sprint N°2

Fecha de inicio 27/02/2022

Fecha de fin 24/03/2022

Revisión de los avances Las fechas de revisión serán las

siguientes:

91
 01/03/2022
10/03/2022
17/03/2022

● Creación de pacientes
Entregables
● Visualizar información de
pacientes
● Gestionar datos de los pacientes

Sprint N°3

Sprint N°3

Fecha de inicio 27/03/2022

Fecha de fin 21/04/2022

Revisión de los avances Las fechas de revisión serán las

siguientes:
04/04/2022
13/02/2022

● Creación de registros clínicos

Entregables
● Visualizar registros clínicos
existentes
● Gestionar datos de los registros

Sprint N°4

92
 Sprint N°4

Fecha de inicio 24/04/2022

Fecha de fin 22/05/2022

Revisión de los avances Las fechas de revisión serán las

siguientes:
02/05/2022
09/05/2022
16/05/2022

● Mantenimiento de los reportes

Entregables
detallados e informes
● Imprimir los reportes detallados
e informes
● Entrega del producto final

11.2.- Mantenimiento de la lista priorizada de pendientes

El product backlog priorizado muestra una lista de tareas pendientes de alto nivel que
aporten mayor valor al cliente. Para el siguiente gráfico el equipo Scrum se reunió para
dialogar las tareas pendientes a realizar en cada Sprint eliminando tareas que antes
creíamos necesarias y resolviendo los incidentes o impedimentos que ocurran.

N° Entregables Product backlog refinado

Sprint 1 Interfaz de usuario ● Crear la estructura y diseño de la

página web.
● Diseñar el logo de la empresa.
● Ingresar el formulario de contacto.
● Diseñar la estructura y modelo de la
interfaz de acceso (Login).
● Validar formularios mostrando
mensajes de error.
● Diseñar la estructura y diseño del
menú de bienvenida.
● Agregar diferentes secciones
dependiendo del tipo de usuario.

93
 ● Mostrar el nombre y rol de usuario.
Sistema de doctores ● Validar formulario de acceso para
crear el rol de doctor.
● Ingresar nuevo usuario y contraseña.
● Validar el registro en la base de datos.
● Crear mensaje de verificación o
advertencia al completar el formulario.
● Agregar los datos ingresados del
nuevo usuario en la base de datos.
● Crear mensaje al finalizar el registro.
Sprint 2 Sistema de pacientes ● Diseñar el formulario de creación de
pacientes.
● Crear mensaje de verificación o
advertencia al completar el formulario.
● Ingresar nuevo usuario y contraseña.
● Validar los datos ingresados en el
formulario en la base de datos.
● Crear mensaje satisfactorio.
● Agregar los datos ingresados del
nuevo paciente a la base de datos.
● Crear mensaje al finalizar registro.

Sprint 3 Sistema de registros ● Diseñar la interfaz y el formulario para

agregar nuestro registro clínico.
● Crear mensaje de verificación o
advertencia al completar el formulario.
● Actualizar el registro si es que ya
existe en la base de datos.
● Crear mensaje satisfactorio.
● Agregar los datos ingresados en el
formulario a la base de datos.
● Crear mensajes de creación exitosa.

Sprint 4 Sistema de importes y ● Resolver error de eliminación de datos

reportes de los pacientes.
● Diseñar la interfaz para observar el
importe final del servicio.
● Actualizar y/o agregar el importe a la
base de datos para generar reporte.
● Crear mensaje importe generado
satisfactoriamente.
● Agregar los datos ingresados en el

94
 formulario a la base de datos.
● Crear mensaje de finalización.
Entrega producto final ● Verificar que el producto cumpla con
los requisitos de los interesados.
● Perfeccionar el diseño de las
interfaces de usuario.
● Verificar que el sistema web pueda
consultar los datos correctamente.
● Generar reportes de información de
doctores, pacientes e importes.

12.- Fase de Revisión y Retrospectiva

12.1.- Creación de evidencias de revision y validacion de sprint

Durante los sprint de cada mes,Enero a Mayo, se fue presentando diferentes

controladores a los involucrados del producto, lo que se llegó a avanzar e involucrando las

opiniones que tenga el involucrado a cada controlador para su producto.

95
12.2.- Elaboración de evidencias de retrospectiva de sprint

13.- Fase de Lanzamiento

96
13.1.- Creación de la arquitectura del proyecto

97
13.2.- Elaboración de documentación

Mientras se iba avanzando con el proyecto, hubo cambios tanto en la documentación

como en el software mientras que otros son aceptados por el product owner.

98
99
100