Capstone_Nota_Menor_ (1).docx

CAPSTONE PROJECT
PRACTICA DE CAMPO
NOTA MENOR 18
Integrantes:
▪ Ramos Torres Mariana Krishe
▪ Ramos Ayala Jose Antonio
▪ Trujillo Mendoza Jackeline
Xiomara
▪ Saavedra Gilio Miguel Fulber
▪ Cáceres Álvarez Eduardo Ricardo
▪ Torres Muñoz, Ricardo Alonso
Josue
Docente:
Robert Roy Saavedra Jiménez
Carrera profesional:
Ingeniería de Sistemas
Computacionales
LIMA – PERÚ
2022 - 2

Contenido
Capítulo I. Introducción................................................................................................................. 6
1.1. Realidad Problemática .................................................................................................. 6
1.2. Antecedentes ................................................................................................................ 7
Internacionales:..................................................................................................................... 7
Nacionales:............................................................................................................................ 9
1.3. Formulación del problema.......................................................................................... 10
1.3.1. Problema General ............................................................................................... 10
1.3.2. Problema Específico ............................................................................................ 11
1.4. Objetivos ..................................................................................................................... 11
1.4.1. Objetivo General ................................................................................................. 11
1.4.2. Objetivo Específico.............................................................................................. 11
1.5. Hipótesis...................................................................................................................... 11
1.5.1. Hipótesis General................................................................................................ 11
1.5.2. Hipótesis específicas ........................................................................................... 11
1.6. Otras Definiciones....................................................................................................... 11
1.6.1. Solución – Diseño de ingeniería .......................................................................... 12
1.6.2. Investigación........................................................................................................ 12
1.6.3. Conceptualización ............................................................................................... 12
1.6.4. Evaluación de viabilidad...................................................................................... 12
1.6.5. Establecimiento de requisitos de diseño ............................................................ 12
1.6.6. Diseño de herramientas y producción ................................................................ 12
1.6.7. Metodología Scrum............................................................................................. 12
Capitulo II. Metodología.............................................................................................................. 16
2.1. Tipo de investigación................................................................................................... 16
2.2. Población y muestra (Materiales, instrumentos y métodos)...................................... 16
2.2.1. Población............................................................................................................. 16
2.2.2. Muestra............................................................................................................... 16
2.3. Técnicas e instrumentos de recolección y análisis de datos....................................... 17
Capítulo III. Plan de Desarrollo de Software ............................................................................... 19
3.1. Antecedentes ................................................................................................................... 19
3.2. Introducción ..................................................................................................................... 20
3.3. Evolución del Plan de Desarrollo del Software ........................................................... 21
Capítulo IV Desarrollo e Implementación Del Sistema De Información ....................................... 2
4.1. Modelamiento de Empresa................................................................................................ 2
4.1.1. Descripción del Proyecto............................................................................................. 2

4.1.2. Objetivos ..................................................................................................................... 2
4.1.3. Contexto del proyecto................................................................................................. 2
4.1.4. Modelo Canvas............................................................................................................ 1
4.2. Estudio de la Factibilidad ................................................................................................... 2
4.2.1. Alcance del estudio de factibilidad ............................................................................. 2
4.2.2. Factibilidad Técnica..................................................................................................... 3
4.2.3. Factibilidad económica................................................................................................ 2
4.2.4. Factibilidad de recursos............................................................................................... 3
4.2.5. Factibilidad operacional .............................................................................................. 4
4.2.6. Factibilidad de tiempo................................................................................................. 4
4.3. Descripción detallada del sistema...................................................................................... 5
4.4. Restricción del Sistema ...................................................................................................... 5
4.5. Restricción del Hardware................................................................................................... 6
4.6. Plan de riesgos y limitaciones ............................................................................................ 6
4.7. Generación de Soluciones.................................................................................................. 7
4.7.1. Identificación y análisis de todas las restricciones, criterios y suposiciones .............. 7
4.8. Criterios para seleccionar la solución................................................................................. 8
4.9. Justificación........................................................................................................................ 9
Capítulo V GESTIÓN DE CALIDAD ................................................................................................ 11
5.1. Plan de Gestión de la Calidad...................................................................................... 11
5.2. Plantilla de Métrica de Calidad ................................................................................... 22
5.3. Línea Base de Calidad.................................................................................................. 32
5.4. Matriz de Actividad de Calidad ................................................................................... 33
5.5. Procedimientos de Gestión de la Calidad ................................................................... 37
5.6. Burndown Chart.......................................................................................................... 47
ANEXOS ....................................................................................................................................... 48
Anexo 01: Matriz de Consistencia............................................................................................. 1
Anexo 02: Metodología Scrum.................................................................................................. 1
Fase I: Sprint Planning........................................................................................................... 1
Fase II: Historia de Usuario.................................................................................................... 3
Sprint N1................................................................................................................................ 7
Sprint N2................................................................................................................................ 9
Sprint N3.............................................................................................................................. 10
Sprint N4.............................................................................................................................. 11
Sprint N5.............................................................................................................................. 11
Anexo 03: Plan de Calidad....................................................................................................... 12

Anexo 04: Plantilla de Caso de Prueba.................................................................................... 13
Anexo 05: Plan de Gestión de Cambios .................................................................................. 13
Anexo 06: Plan de Gestión de Cambios .................................................................................. 14

Capítulo I. Introducción
1.1. Realidad Problemática
En la actualidad la emergencia sanitaria generada por el Covid-19 ha
afectado a los diferentes tipos de negocios, por este motivo, las empresas
generaron la digitalización para un mejor posicionamiento en el escenario
comercial, esto permite a las empresas encajar en estos nuevos tiempos
del comercio y poder aligerar los procesos de sus negocios (Chowdhury
et al., 2022).
La pandemia ha agilizado mucho en el tema de la tecnología, ya que el
internet fue la herramienta que ayudó a las personas a conectarse y poder
vender o comprar los productos que requerían u ofrecían sin la necesidad
de ir a una tienda física. De modo que el sector en los negocios desde la
posición del cliente se vio directamente favorecida (Economista et al.,
2021).
Sumba-Bustamante (2020) “La revolución de la tecnología ha tenido
mucha influencia para que las ventas tradicionales disminuyan, pues los
emprendedores no tienen los conocimientos necesarios para adaptarse a
los canales de compra y venta virtuales, que son la herramienta utilizada
para transformar el comercio tradicional a un comercio electrónico”
El e-commerce es un instrumento que se puede manejar en un ambiente
de venta directa e indirecta de artículos, manteniendo soporte técnico
continuo que otorga que los mismos clientes puedan buscar sus
productos, esta herramienta es de gran provecho para los negocios, ya
que acceden a conectar sus bases de datos para la preparación de
pedidos, trato con proveedores, entre otros, afianzando la optimización de
costos y mejorando la canalización de ventas. (Felipe González et al.,
2021)

1.2. Antecedentes
Internacionales:
 Aguilar (2020) “propuesta para implementar un sistema de gestión
de la calidad en la empresa “filtración industrial especializada s.a.
de CV” de Xalapa, Veracruz” El propósito de este trabajo es el de
realizar una propuesta para el establecimiento de un sistema de
aseguramiento de la calidad y de la gestión de la calidad total en la
empresa “Filtración Industrial Especializada, S.A. de C.V.”,
analizando los principios y las prácticas existentes en esta empresa.
Esta teoría se centra en el enfoque de la administración de la
calidad que tiene una dirección proactiva y un carácter fundamental,
a la vez que une normas e ideas clave que están progresivamente
de acuerdo con el entorno de la seriedad actual. La administración
de la calidad ha evolucionado desde sus puntos de partida hacia
una visión indiscutiblemente mundial. La administración de la
calidad defiende progresivamente los métodos de calidad operativa
y aplica más procedimientos identificados con el activo humano el
tablero y todo lo que tiene que ver con la cultura organizacional.
 Kherissi y Meslati (2015) “Un enfoque basado en la extensión del
RUP para hacer frente a los cambios anticipados en los sistemas
de software ontogenéticos”. La ontogenia del software se refiere a
la capacidad del mismo para evolucionar dinámicamente de forma
autónoma para satisfacer las necesidades del usuario y los cambios
previstos e imprevistos de requisitos. La evolución de un sistema
ontogénico tiene la particularidad de ser un continuo proceso que le
da forma desde el principio de su creación. Esta característica no
coincide con los métodos de desarrollo actuales, que consideran
que la evolución es un proceso esporádico. En consecuencia, las
plataformas, herramientas y metodologías que utilizamos para
desarrollar sistemas de software no son adecuadas y se necesita
un es necesario un enorme trabajo para adaptarlas a la ontogenia
del software. En este artículo, proponemos una combinación de tres
enfoques de ingeniería de requisitos: el método de la rueda de los
futuros la ingeniería de requisitos orientada a objetivos y los casos
de cambio, junto con una extensión del proceso unificado racional
(RUP) para modelar y manejar los cambios previstos en el
hipotético contexto de los sistemas ontogenéticos.

 Pereira y Oliveira (2017). “Desarrollo de sistemas de información
basados en procesos: Aprovechando una infraestructura basada en
componentes”. El objetivo fue definir una infraestructura
tecnológica, acompañada de un conjunto de requisitos de desarrollo
metodológico, que pueda ayudar a satisfacer esas necesidades.
Donde se propone una infraestructura informática específica,
inspirada en el concepto de proceso de negocio y que utiliza las
funcionalidades proporcionadas por las tecnologías de colaboración
y de flujo de trabajo, que permite el desarrollo de soluciones
informáticas distribuidas, los Sistemas de Información Basados en
Procesos (PBIS), de forma basada en componentes. Concluyendo
que los Sistemas de Información Basados en Procesos permiten a
las organizaciones evolucionar rápidamente y sin problemas frente
a los cambiantes requisitos empresariales, facilitando la integración
de los artefactos de TI existentes y futuros, al tiempo que simplifican
el esfuerzo general de desarrollo y mantenimiento de los sistemas
de información.
 Sievers, Pires y Coelho (2015) "El uso de la metodología Extreme
Program y RUP para el desarrollo de experimentos de domótica”.
tiene como objetivo mostrar el uso de la metodología Extreme
Program y algunos documentos RUP - Rational Unified Process
para crear Domótica de experimentos en una residencia, orientados
a bajo costo. El proyecto impregna el desarrollo de un sistema
informático multiplataforma que puede ser utilizado por los
navegadores actuales y teléfonos Android, capaz de controlar las
características básicas de una residencia como iluminación, aire
acondicionado, sonido y seguridad.
 Wysocki, Orłowski, Ziółkowski y Bocewicz (2017) “Modelo de
procesos de agentes de RUP para organizaciones de TI
Preparación para la evaluación de transformación ágil” Proponemos
el uso del modelo de proceso de la metodología de desarrollo RUP
como patrón para compararlo con el proyecto probado. Los valores
porcentuales del coeficiente de conformidad determinan la tarea de
conformidad del proyecto probado con el patrón de flujo de
actividades. Este concepto de modelo RUP se basa en una
simulación basada en múltiples agentes (MABS). Presenta agentes
y sus comportamientos, así como objetos colocados en el entorno
del sistema de agentes. El comportamiento de los agentes se
presenta como un conjunto de autómatas de estado finito. La
utilidad del método para evaluar la madurez de la organización se
examinó en un experimento de dos partes. El resultado de la

primera parte del experimento se utilizó en la segunda parte como
patrón de proceso para determinar la conformidad de un proyecto
de muestra con el resultado del modelo simulado. Los resultados
confirmaron la utilidad del modelo en la evaluación de la madurez.
Nacionales:
 Gonzales (2016) “Desarrollo e Implementación de un Sistema de
Información para el control del proceso de capacitación de una
empresa del rubro de las telecomunicaciones en el Perú” El objetivo
principal de la tarea es controlar los ciclos ejecutados por La
Academia Perú, a través de un marco de programación web, para
disminuir el margen de maniobra en los Informes de Gestión. El
avance del ítem se ha realizado bajo el procedimiento Open Unified
Process (OpenUP) y comprendió la originación, elaboración,
desarrollo y progreso de un escenario web utilizando la innovación
ASP.NET WebForms, HTML5, SQL Server 2008 R2 y otros
avances de vanguardia.
 Huamán y Huancayo (2017) “desarrollo e implementación de un
sistema de información para mejorar los procesos de compras y
ventas en la empresa HUMAJU”. Se ejecutará un Sistema de
Información en la organización Humaju para mejorar estos ciclos, el
marco de trabajo se fundamentará en la problemática actual que
atraviesa la organización, para el marco de trabajo se llevará a cabo
el enfoque AUP (Agile Unified Process) y se creará en Visual Studio
2010 y SQL Database Engine 2012. El Sistema de Información será
excepcionalmente útil para mejorar los ciclos de Compras y Ventas
que se crean en la organización Humaju.
 López y Saldarriaga (2015) “modelo de sistema de gestión por
procesos en la municipalidad distrital de Oyotún”. Se crea el sistema
institucional, normativo y referencial, que incorpora un retrato de la
zona de Oyotún, la Municipalidad Distrital de Oyotún, y los
esfuerzos de modernización de la administración pública; A
continuación se da cuenta de la determinación de los ciclos de la
Municipalidad Distrital de Oyotún relativos a las diferentes unidades
naturales de dicha organización, consolidando además el enfoque
de interacción en una unidad particular como es la de suministros;
por último, se da cuenta de la propuesta del ROF con un enfoque
de Gestión por Procesos; para cerrar con el pertinente índice de
libros utilizados para construir esta investigación.
 Ponce (2016) “Propuesta de implementación de gestión por
procesos para incrementar los niveles de productividad en una

empresa textil”. la opción más ventajosa se crea a través de la
técnica PDCA, que comienza con la etapa de organización donde
se verá el sistema de la organización para evaluar la similitud de la
tarea en cuanto a las disposiciones de la organización. Se reconoce
la situación actual de la interacción (AS-IS), se realiza el ciclo
racionalizado (TO-BE) y se distingue lo que es importante para
cubrir el hueco descubierto (Gap) por último se establecen las
estimaciones, dispositivos y punteros para que la ejecución de la
técnica funcione con la mejora persistente. se infiere que la
ejecución de la Gestión de Procesos funcionará con la disminución
de los ítems no ajustados y la salvaguarda de un marco de mejora
ininterrumpida y ampliará los niveles de eficiencia.
 Zevallos (2017) “aplicación de la metodología rational unified
process (RUP) en el desarrollo de un sistema informático para el
control de servicio académico del instituto tecnológico de Paucara
– Huancavelica”. Esta investigación fue conducida a través de la
estrategia científica y el enfoque RUP, el tipo de examen es
innovador, con un grado de estudio expresivo, informativo y
correlacional, la configuración del examen es exploratoria; el
universo de la investigación comprende 525 alumnos, personal de
regulación y de exhibición del Instituto, el tipo de inspección es
coordinada y comprende 25 funcionarios de gestión y de instrucción
asociados al territorio escolar. El resultado global de esta
investigación es el avance de un marco de trabajo de PC para el
control escolar, aplicando la estrategia científica y la técnica del
Proceso Racional Unificado (RUP) con sus períodos de inicio,
elaboración, desarrollo y progreso para satisfacer todo el patrón de
vida del avance del producto, para mejorar los ciclos en el control
de la ayuda escolar del Instituto Tecnológico de Monterrey.
1.3. Formulación del problema
1.3.1. Problema General
¿De qué manera la gestión de ventas y control del sistema web
influye en las empresas en estos tiempos de pandemia?

1.3.2. Problema Específico
¿Cuáles fueron los cambios más radicales de adaptación de las
empresas para poder optar con canales de ventas relacionadas a
las TIC durante la pandemia?
¿De qué manera influyo los tics para el comercio electrónico en
épocas de pandemia?
1.4. Objetivos
1.4.1. Objetivo General
Determinar de qué manera la gestión de ventas del sistema web
influye en la tienda de ropa.
1.4.2. Objetivo Específico
Determinar si un sistema web mejora el registro de usuarios para la
tienda de ropa.
Comprobar si un sistema web mejora la calidad de ventas para la
tienda de ropa.
1.5. Hipótesis
1.5.1. Hipótesis General
El sistema web influye significativamente en la gestión de calidad y
control de ventas.
1.5.2. Hipótesis específicas
El sistema web mejora significativamente el registro de usuarios
para la gestión de ventas.
El sistema web mejora significativamente la calidad de servicios
para la gestión de ventas.
1.6. Otras Definiciones

1.6.1. Solución – Diseño de ingeniería
Para hallar la solución a problemática del proyecto se requiere
realizar un análisis divido en las siguientes etapas:
1.6.2. Investigación
El proyecto está basado en una tienda física de venta de ropa
femenina perteneciente a una colaboradora, por lo cual se cuenta
con los detalles necesarios para el desarrollo del proyecto.
1.6.3. Conceptualización
De acuerdo con el objetivo de ordenar la información del negocio-
cliente, se tienen los datos necesarios como nombre, ruc,
ubicación, tipo de producto, entre otros datos de la empresa.
1.6.4. Evaluación de viabilidad
De acuerdo con el análisis previo en la pág. (poner página), se
puede afirmar que la implementación de este nuevo sistema web
es factible y viable para el negocio, el cual impulsara las ventas en
general ya que amplía el alcance del público objetivo.
1.6.5. Establecimiento de requisitos de diseño
Los requisitos de diseño van de acuerdo con las historias de
usuario de la metodología SCRUM y las funciones planteadas.
1.6.6. Diseño de herramientas y producción
El sistema web se desarrolla utilizando los siguientes lenguajes:
 Lenguaje de programación Java
 Lenguaje de etiquetado HTML5
 Lenguaje de diseño gráfico CSS
Además, utiliza una base de datos local: MySQL.
El detalle de producción es de acuerdo con la metodología SCRUM
y los Sprints designados.
1.6.7. Metodología Scrum
Para el desarrollo del proyecto se utilizó la metodología SCRUM,
ya que es la que se ajustó a las necesidades del proyecto y,
además es la única que nos proporciona flexibilidad en la
modificación de ciertos parámetros en el proceso de desarrollo de
sistema web. Este punto es muy importante ya que se adapta a los
contratiempos que vayan surgiendo durante el proceso de
desarrollo.
De acuerdo con la elección de esta metodología, todo el proceso
de desarrollo sigue las fases y procesos de la metodología
SCRUM.

El Equipo Scrum (Scrum Team)
Según (Sutherland, 2018) menciona que son auto organizados y
multifuncionales, en la cual los equipos auto organizados escogen
la forma correcta de llevar a cabo su trabajo, y los equipos
multifuncionales cuentan con las competencias necesarias para
llevar a cabo el trabajo. El equipo Scrum está diseñado para reducir
la flexibilidad, creatividad y la productividad.
El Dueño de Producto (Product Owner)
Según (Altman, 2016) menciona que el dueño de producto es solo
la persona responsable de tramitar la lista del producto (Product
Backlog).
El equipo de Desarrollo (Development Team)
Según (Edge, 2017) menciona que el equipo de desarrollo cuenta
con profesionales en la cual desempeñan un trabajo de poder
entregar un incremento de producto (terminado), que posiblemente
se pueda colocar en producción.

El equipo cuenta con los siguientes cargos:
Cargo Integrante
Product Owner Jose A. Ramos Ayala
Equipo de desarrollo
Miguel F. Saavedra Gilio
Eduardo R. Cáceres Álvarez
Jackeline X. Trujillo Mendoza
Mariana K. Ramos Torres
SCRUM Master Ricardo A. J. Torres Muñoz

Capitulo II. Metodología
2.1. Tipo de investigación
En la elaboración de la presente investigación es de enfoque cuantitativa,
este indica que es un proceso deductivo, donde cada etapa dirige de
manera lógica, lo cual sirve para obtener la gestión de ventas, llegando a
cuantificar los resultados.
2.2. Población y muestra (Materiales, instrumentos y
métodos)
2.2.1. Población
La población que conforma la investigación está conformada por
100 usuarios.
Usuarios
Personas 100
Total 100
Tabla 2: Elaboración propia
2.2.2. Muestra
Mora García (2008, p.44) “Este indicador tiene por objeto describir
las características para el cálculo, manejo, control e interpretación
de la calidad de los pedidos generados. El objetivo específico es
controlar la calidad de los pedidos generados.”)
Se ha utilizado el muestreo de manera probabilística. Tomando en
cuenta la siguiente fórmula:
n= Tamaño de la muestra
N= Tamaño de la población
P= Probabilidad que ocurra un evento (0.5)
Q= Probabilidad que no ocurra un evento (0.5)
E= Margen de error (0.05)
Z= Nivel de confianza (95%<>1.96)
Reemplazando los valores en la formula se obtiene el siguiente
resultado:
𝑛 =
(1.96)2
× (0.5) × (0.5) × (100)
((100 − 1) × (0.05)2) + ((1.96)2 × (0.5) × (0.5))
𝑛 = 79.51

2.3. Técnicas e instrumentos de recolección y
análisis de datos
El estudio tendrá en cuenta la meticulosidad necesaria para la
recolección de los datos y el instrumento es la ficha de observación.
2.3.1. Métodos de investigación
La investigación fue de método cuantitativo, debido a que las
variables fueron evaluadas mediante análisis estadístico
siendo las escalas numéricas
2.3.2. Técnicas e instrumentos
Se desarrollará con la técnica de la encuesta, que anexara
acciones para afirmar la efectividad de los cuestionarios, y así,
medir las variables que se pretenden investigar, atravesando
por análisis estadísticas dependiendo el caso (Macías,
2006).
2.3.3. Procedimiento.
La investigación es de proceso cuantitativo por ser secuencial
y probatorio. Cabe precisar, que cada etapa antecede a la
siguiente y no podemos saltar pasos, el orden es muy
importante. Por medio de una idea, se provienen objetivos y
preguntas de indagación, y con ello se construye un aspecto
teórico, se analizan las variables en un contexto; se determina
las conclusiones respecto a las hipótesis. (Hernández,
Fernández y Baptista, 2011)

CAPÍTULO III
MARCO REFERENCIAL

Capítulo III. Plan de Desarrollo de Software
3.1. Antecedentes
En los últimos años, la cantidad de información que las empresas manejan
se ha ido incrementando exponencialmente, es muy complicado manejar
tanta información de manera manual, como por ejemplo libros contables,
notas y demás medios no digitales. Además de que provoca un aumento
en el tiempo necesario para realizar determinadas tareas y existe un riesgo
mayor en cuanto a la perdida de información vital. “mediante la
digitalización, las empresas son capaces de gestionar un mayor flujo de
información, no solo captando los datos, sino interrelacionándolos y
empleándolos para la creación de información útil” (Rosales, 2020, p.10).
Debido a ello se ha impulsado la transformación digital en las empresas a
nivel global para tener un manejo de información más rápido, eficiente y
seguro. Esta transformación digital ha sido aceptada por empresas de
todos los sectores.
En cuanto a América Latina, cada vez son más las empresas que brindan
soluciones tecnológicas para impulsar la transformación digital en la región
siendo las medianas y grandes empresas sus principales clientes. “La
transformación digital ha estado en expansión incesante por todo el
mundo” (Montenegro, 2021 p.23).
En el Perú, todavía hay empresas que siguen manejando su información
a base de lápiz y papel, y generalmente son las pequeñas empresas, como
puede ser la tienda de ropa, restaurantes, pequeñas tiendas, entre otras.
Y hasta cierto punto pueden seguir trabajando correctamente de esa
forma, sin embargo, a medida que va avanzando el tiempo estas empresas
van generando grandes cantidades de ventas y se vuelve muy complicado
gestionar sus todas las ventas por lo que se generan varios problemas al
no contar con sistemas digitales de ventas. Algunos de estos problemas
son, perdida de información, información sucia o incorrecta ya que no hay
un control de cómo se ingresa la venta, falta de datos para validar las
acciones o ventas de la empresa, entre otros.
Una de las principales razones por la que algunas empresas no deciden
invertir en un sistema digital para el manejo de su información es el costo
de esta. En el mercado actual existen diferentes alternativas como por
ejemplo sistemas ya creados que se ofrecen a las empresas a cambio de
una subscripción que deben pagar durante el tiempo que usen la
plataforma, por otra parte, están los sistemas que son creados a demanda
según la necesidad del cliente, en este caso los costos suelen ser muy
altos.

En cuanto a los costos de desarrollo de los sistemas estos pueden variar
según las tecnologías que se usen y estas tienen diferentes beneficios y
contras, por ejemplo, una herramienta desarrollada en Cloud es más
costosa que una herramienta desarrollada en un servidor local ubicado en
la empresa del cliente o en la ubicación definida por el proveedor, en este
caso la alternativa en servidor local tiene el beneficio del costo para
nuestro cliente.
3.2. Introducción
Este Plan de Desarrollo del Software nace con la necesidad de
implementar un Sistema de gestión de ventas que permita registrar, listar
y modificar los productos, con una interfaz amigable al usuario Este
documento provee una visión global del enfoque de desarrollo propuesto.
Para desarrollar un sistema de información primero debemos elaborar un
plan de desarrollo de software orientado a una metodología, que en
nuestro caso será el RUP (Rational Unified Processing) basada en UML
(Unified Modeling Language), el cual nos guiará por todo el camino hasta
la implementación del sistema de información.
Se desarrolla la mayoría de los diagramas UML, con el fin de servir de guía
para futuros desarrollo de software. Este proyecto servirá para fomentar el
desarrollo de sistemas de información siguiendo un plan de desarrollo
basado en una metodología particular, con el fin de optimizar la
elaboración del software.

3.3. Evolución del Plan de Desarrollo del Software
El Plan de Desarrollo del Software se revisará semanalmente y se
refinará antes del comienzo de cada iteración.

CAPÍTULO IV
DESARROLLO E IMPLEMENTACIÓN
DEL SISTEMA DE INFORMACIÓN

Capítulo IV Desarrollo e Implementación Del Sistema
De Información
4.1. Modelamiento de Empresa
4.1.1. Descripción del Proyecto
El propósito del proyecto es implementar un sistema web de
gestión de ventas en un negocio local. El sistema impulsara las
ventas de ropa femenina gracias al mayor alcance que este
proyecto brinda al negocio.
4.1.2. Objetivos
El proyecto cumplirá las necesidades del cliente las cuales son:
 Sistema de ingreso, modificación y eliminación de productos
(ropa).
Este sistema permitirá ingresar los productos considerando
parámetros como nombre, precio, talla, entre otras.
 Sistema de registro de ventas (comprobante).
Al finalizar el proceso de venta se generará un comprobante el
cual se registrará en la base de datos, para su futuro análisis en
caso se requiera.
 Sistema de usuarios (roles) para una experiencia
personalizada.
Al ingresar a la página web, se considerará el tipo de usuario para
permitir negar diversas funciones.
4.1.3. Contexto del proyecto
La empresa tiene como fin convertirse en una empresa líder en el
rubro de ventas de ropa femenina, el rango de venta se ha
convertido en una limitante importante en el proceso de crecimiento
de la empresa. Por tal caso, se ha optado por desarrollar un
sistema web que resolverá en gran medida ese problema. El
objetivo simbólico de la implementación de este proyecto es
generar un espacio confortable para nuestro público femenino.

4.2. Estudio de la Factibilidad
En esta etapa se elabora un estudio de factibilidad el cual permite
determinar si la solución es alcanzable tomando en cuenta restricciones
y recursos de la organización, en este caso, la tienda de ropa. Aquí se
analizará las tres áreas principales de la factibilidad: factibilidad técnica,
factibilidad operativa y económica que se detallará a continuación.
4.2.1. Alcance del estudio de factibilidad
Este proyecto agilizará el proceso de ventas y control de los productos e
inventariar todas las ventas. Asimismo, este proyecto incluye la
capacitación a los trabajadores y la entrega a la tienda de ropa de una
versión local definitiva para la gestión de sus procesos que requieren.
El alcance también comprende la implementación de una interfaz que
incluirá todos los datos registrados de cada operación.
Asimismo, hemos cotizado el alcance y ganancias que puede llegar a
tener la implementación de la web para la tienda de ropa.
Finalmente observamos que tenemos un CB mayor al 1.0 esto quiere
decir que nuestro proyecto es considerado viable

4.2.2. Factibilidad Técnica
Mediante esta factibilidad vamos a explicar todos los recursos técnicos con
lo que cuenta el equipo de desarrollo tanto software y hardware.
1. Sistema operativo
Se mostrará a continuación una lista de los SO que cumplen lo
necesario para el desarrollo del proyecto.
 Windows 10
 Mac os
 Linux
2. Lenguaje de desarrollo
Se va a mostrar a continuación una lista de diferentes Lenguajes de
desarrollo que cumplen con las siguientes características: sencillo de
Aplicar y desarrollar.
 JavaScript
 PHP
3. Base de datos
El gestor de base de datos debe tener las siguientes características:
que sea estable y que aguante una cantidad enorme de datos.
 MySQL.
 SQL server 2017.
4. Hardware
Se listará las características de las PCs para desarrollar el sistema.
PC1
 Procesador: Intel Core i5
 Memoria RAM: 8gb
 Almacenamiento: 512gb SSD
PC2
 Procesador: Intel Core i3
 Memoria RAM: 8gb
 Almacenamiento: 500gb HDD
5. Estudio de viabilidad técnica
Se puede concluir que el equipo de desarrollo posee el equipo
necesario, tanto hardware y software, para el correcto desarrollo del
sistema. El equipo está completamente capacitado ya que poseen
experiencia en cada una de las fases del desarrollo del sistema

4.2.3. Factibilidad económica
 Flujo de Pago:
Recursos Costos
Recursos humanos S/. 6120,00
Recursos Tecnológicos S/. 930,00
Recursos Materiales S/. 460,00
Total S/. 7510,00
 Costo de Operación:
Recursos Costos
Gastos S/. 500
Diseñador Grafico S/. 450
Total S/. 950
 Proyección del proyecto:
A continuación, se visualiza la proyección del Software en unos 3 años.
Concepto 2022 2023 2024
Ingresos
Actividades del
sistema
0 6500 8000
Costos
Trabajadores -6120 0 0
Materiales -460 0 0
Recursos
Tecnológicos
-930 -700 -700
Operación -800 0 0
Mantenimiento 0 -250 0

4.2.4. Factibilidad de recursos
Se describe los costos del recurso necesario para el desarrollo de nuestro
Sistema de ventas para el negocio “Jackeline y Angella”:
Recursos Humanos:
N° Cargo
Costo
Individual
Costo Total
1
Ing. Sistema (Líder del
proyecto)
1300,00 1300,00
2 Analista/Diseñador 930,00 1860,00
1 Ing. de Software 1100,00 1100,00
2 Programador 930,00 1860,00
TOTAL S/. 6120,00
Recursos Tecnológicos:
 Hardware
Cantidad Descripción Costo/Hora Total
5 120 horas de computadora 1,0 600,00
TOTAL S/. 600,00
 Software
Cantidad Descripción Costo Total
1 Hosting 280 280
1 Dominio 50 50
Total S/. 330,00
Recursos Materiales:
Cantidad Descripción Costo Total
4
Cursos de capacitación
de Diseño con CSS
115 460
Total S/. 460,00

4.2.5. Factibilidad operacional
El proyecto será implementado por cuatro personas, 2 analistas y 2
programadores, quienes se repartirán las diferentes actividades para
finalizar el proyecto de la forma más rápida y eficaz.
Cliente (dueña del negocio).
Los dueños del negocio serán capacitados y serán los únicos en usar la
funcionalidad de administración. Tendrán dos días de formación con
cuatro horas diarias de la mano de un analista y un programador. El otro
analista y programador restantes ayudarán a los usuarios a aclarar
posibles inquietudes y resolver problemas que surjan durante la
observación de una semana.
Estos acompañamientos se realizarán in situ 12 horas a la semana de
lunes a viernes (excepto festivos). Después de una semana, los
programadores de soporte visitarán a los usuarios 3 veces al mes durante
6 horas con fines de mantenimiento y/o para resolver posibles problemas
de los clientes. En caso de imprevisto, como máximo 1 mes después del
período de seguimiento, si el período de seguimiento no está claro, las
dudas restantes que puedan tener los usuarios se resolverán ante ellos.
Adicional a lo anterior, el usuario recibirá una guía con información sobre
cómo utilizar el sistema.
4.2.6. Factibilidad de tiempo
Para realizar el proyecto tendremos disponibles 14 semanas. El cual
empezara su desarrollo el día 22 de agosto.
El desarrollo de la aplicación no afectará las operaciones normales del
personal y será un desarrollo independiente a otros proyectos internos del
negocio.
Durante el tiempo disponible realizaremos las siguientes acciones en un
primer momento.
• Recolección de datos.
• Creación de BD.
• Formulación de prototipos.

En un segundo momento realizaremos lo siguiente:
Creación de la interfaz gráfica con la aprobación del product owner.
• Formulación de código.
• Presentables del aplicativo.
• Las pruebas funcionales.
• Corrección de errores
En un tercer momento realizaremos:
• La implementación y correcciones de ser necesario.
• La capacitación al personal del negocio.
Es a grandes rasgos un listado de las funciones previstas en este proyecto.
El tiempo estimado de recuperación de la inversión es de 5 meses.
Que va a ser solventado por la reducción de logística utilizada, así como
el sobre esfuerzo de llevar un control administrativo del sistema web.
4.3. Descripción detallada del sistema
Persona: La computadora/laptop que realiza un inicio de sesión con su
cuenta de la tienda de ropa para realizar la acción que desee hacer según
el rol que se le haya asignado.
Servidor: Recibe la consulta de la persona, y el sistema le responde con
la acción o visualización correspondiente.
Proveedor: Empresa externa de la cual se adquiere la mercancía para la
tienda.
Producto: Mercancía que se adquiere a través del proveedor, la cual será
vendida en la tienda.
Comprobante: Documento donde se visualizará la prenda adquirida y
precio total de la compra, a su vez se mostrará el ruc de la empresa y el
DNI del comprador.
4.4. Restricción del Sistema
El sistema fue diseñado considerando las siguientes restricciones para su
funcionamiento:

 Escases de recursos para implementar nuevas tecnologías de
software y las licencias que requieren las mismas.
 No está implementado para su uso en dispositivos móviles.
4.5. Restricción del Hardware
El hardware fue considerando con las siguientes restricciones para la
correcta ejecución del software:
 Escases de recursos para implementar las nuevas tecnologías de
hardware virtualizado.
4.6. Plan de riesgos y limitaciones

4.7. Generación de Soluciones
4.7.1. Identificación y análisis de todas las restricciones, criterios y
suposiciones
4.7.1.1. Matriz de Riesgo
Análisis Cualitativo De Riesgos
ID RIESGOS WBS
item
Imp Prob Score Trigger Owner Resp
Stat
Response
1 Retraso en
culminación
6,5 0,7 0,9 0,72 Falta de
interés
AN AV Gestión de
cambio
2 Demora de los
entregables
Todos 0,9 0,7 0,28 Modificaciones
en último
momento
DE AV Aprobaciones
detalladas
3 Modificación de
requisitos
Todos 0,2 0,7 0,14 Paga
insuficiente
AN AC Escalar SM
4 Falta apoyo
equipo
Todos 0,4 0,5 0,20 Falta de
interés
SM MI Contratar
nuevo personal
5 Falta
aprobación
Product Owner
7,7 0,8 0,3 0,20 Correcciones AN MI Plan de
contingencia
6 Diferente SO 4,0 0,1 0,9 0,09 Errores por el
SO
TE AV Ascender a TE
7 Probabilidad de
retraso del
sistema
7,0 0,2 0,3 0,06 Problemas
pruebas
tempranas
TE MI Mejorar el
sistema
8 Actualizaciones
tecnológicas
4,0 0,1 0,1 0,01 Problemas
pruebas
tempranas
TE AC Capacitaciones
LEYENDA
DC=DOCUMENTADOR AV= Avoidance
AN=ANALISTA MI=Mitigation
DE=DESARROLLADOR AC=Acceptance
SM=SCRUM MASTER
TE=TESTER

Análisis Cuantitativo De Riesgos
ID Riesgo IMP PROB SCORE
1 Retraso en culminación 0,7 0,9 0,72
2 Demora de los entregables 0,9 0,7 0,28
3 Modificación de requisitos 0,2 0,7 0,14
4 Falta apoyo equipo 0,4 0,5 0,20
5 Falta aprobación Product Owner 0,8 0,3 0,20
6 Diferente SO 0,1 0,9 0,09
7 Probabilidad de retraso del sistema 0,2 0,3 0,06
8 Actualizaciones tecnológicas 0,1 0,1 0,01
4.7.1.2. Plan de calidad de software
4.8. Criterios para seleccionar la solución
Herramientas y lenguajes de programación
Los lenguajes que se va a usar para la creación del sistema web deberán
darle estabilidad al sitio web y la correcta administración de datos. Los
lenguajes que cumplen con estas características serán javascript y
HTML5.
Gestor de base de datos
El gestor de base de datos que se usara para el sistema web deberá ser
un gestor seguro, asociable y que sea capaz de soportar grandes
cantidades de información. El gestor de base de datos adecuado es
MySQL.
ACTIVIDAD RESPONSABLE DESCRIPCION
Verificación de importantes
entregables
-Equipo de
desarrollo
-Analista
programador
Los entregables serán debidamente
revisados y validados por el analista
programador y el equipo de desarrollo
apoyara antes de concluir los entregables.
Cumplimiento de objetivos -Equipo de
desarrollo
-Analista
programador
Las actividades del proyecto deberán cumplir
con todos los objetivos abordados y
verificados por el analista programador.
Diseño de procesos -Diseñador
-Analista Funcional
Los procesos de la organización deben
considerar las actividades de control de
calidad en cada proceso. El diseño del
sistema se va a mantener en continuo
seguimiento.
Revisiones -Analista
programador
El diseño del software será verificado por el
analista programador.

4.9. Justificación
Justificación Tecnológica:
La empresa necesitaba contar con un sistema de información que le agilice los
procesos que se realizan en ella y que tenga una alta confiabilidad en cuanto a los
datos personales del cliente.
El correcto uso del sistema influyó en el progreso de la empresa, puesto que
permitió tener información en tiempo real con datos correctos.
Desarrollar un sistema de web permitió mejorar el proceso logístico de la empresa.
Justificación Institucional:
En cuanto a la justificación institucional como empresa privada esta se encuentra
en constante competencia con otras empresas en brindar sus productos de moda
por ello necesita que uno de los procesos influyentes sea optimizado para satisfacer
al cliente.
Este tipo de proceso es parte fundamental para este tipo de empresas se
desempeñe eficientemente en el mercado, puesto que es el proceso sobre el cual
depende la productividad de la misma. Al optimizar este proceso se nota la mejorar
y asimismo la imagen Institucional permitiendo empatizar con más cantidad de
clientes.
Justificación Económica:
Según estudios realizados por el área de planificación y presupuestos de la
empresa, el monto promedio en gastos redondea aproximadamente los S/.
25000.00. Así mismo redujo el tiempo de búsqueda de los materiales que maneja la
empresa, también evitó que el personal no se encuentre sin poder trabajar por falta
de materiales, al personal se le paga por su trabajo, la empresa paga por trabajador
S./450.00 mensuales.
Por problemas logísticos la empresa estaba perdiendo dinero y por ello se
pretendió administrar de la mejor manera automatizando el proceso logístico. Por
lo tanto, la presente investigación buscó reducir costos a través del seguimiento del
flujo de los procesos de reabastecimiento, además agilizó los procesos de
despacho, haciendo que los productos lleguen sin retraso.
Justificación Operativa:
La justificación operacional determinó la veracidad en cuanto la agilización con data
que genera la empresa, seguimiento de los productos en cuanto a su stock y
especificación de los requisitos a detalle que se requieren.

CAPÍTULO V
GESTIÓN DE CALIDAD

Capítulo V GESTIÓN DE CALIDAD
5.1. Plan de Gestión de la Calidad
NOMBRE DEL PROYECTO SIGLAS DEL PROYECTO
Sistema Web de gestión de venta SWGV
POLÍTICA DE CALIDAD DEL PROYECTO
El presente proyecto debe cumplir con los requisitos de calidad planteados por INNOVA, es
decir acabar dentro del tiempo y el presupuesto planificados, asimismo debe cumplir con
los requisitos de calidad del Líder Usuario.
LÍNEA BASE DE CALIDAD
PROYECTO
FACTOR DE
CALIDAD
RELEVANTE
OBJETIVO
DE
CALIDAD
MÉTRICA A
UTILIZAR
FRECUENCIA Y
MOMENTO DE
MEDICIÓN
FRECUENCIA Y
MOMENTO DE
REPORTE
Performance
del Proyecto
CPI≥0.95 CPI = Cost
Performance
Index Acum.
• Frecuencia: Cada
fase finalizada.
• Medición: El día que
culmine la última
actividad de cada fase.
fase finalizada.
• Reporte: Al día
siguiente de la
medición.
SPI≥0.95 SPI =
Schedule
Performance
Index Acum.
fase finalizada.
• Medición: El día que
culmine la última
actividad de cada fase.
fase finalizada.
siguiente de la
medición.
Satisfacción de
los clientes
𝑋≥4 X = Promedio
entre 1 a 5 de
14 factores
sobre
productos.
• Frecuencia: Una
encuesta por cada
categoría.
• Medición: El
momento de medición
se manejará
internamente.
• Frecuencia: Una vez
por cada categoría.
siguiente de la
medición
PRODUCTO

FACTOR DE
CALIDAD
RELEVANTE
OBJETIVO
DE
CALIDAD
MÉTRICA A
UTILIZAR
FRECUENCIA Y
MOMENTO DE
MEDICIÓN
FRECUENCIA Y
MOMENTO DE
REPORTE
Conformidad
con
requerimientos
𝑋≤0.1 X = Índice de
conformidad con
requerimientos.
• Frecuencia: Al
final de las
actividades de
los paquetes 4.4,
4.5, 5.4.1 y 5.2.4
del WBS.
• Medición:
16/10/2022, y
18/10/2022,
respectivamente.
• Frecuencia: Al final
de los paquetes 4.4,
4.5, 5.4.1 y 5.2.4 del
WBS.
siguiente de la
medición
Seguridad de
Acceso
𝑋=0 X = Instrucciones no
permitidas realizadas
• Frecuencia: Al
final de las
actividades de
los paquetes
5.1.2.1 del WBS.
• Medición:
13/10/2022
respectivamente.
de los paquetes 5.1.2.1
del WBS.
• Reporte: Dentro de
las 8 horas después de
realizar la prueba.
Aprendizaje 𝑋=1 X = Índice de
funciones en manual
de usuario.
• Frecuencia: Al
final de las
actividades de
los paquetes
5.2.1, 5.2.2,
5.2.3 y 5.2.4 del
WBS.
• Medición:
16/10/2022,
17/10/2022,
17/10/2022 y
18/10/2022
respectivamente.
de los paquetes 5.2.1,
5.2.2, 5.2.3 y 5.2.4 del
WBS.
siguiente de la
medición.
DOCUMENTACIÓN
FACTOR DE
CALIDAD
RELEVANTE
OBJETIVO
DE
CALIDAD
MÉTRICA A
UTILIZAR
FRECUENCIA Y
MOMENTO DE
MEDICIÓN
FRECUENCIA Y
MOMENTO DE
REPORTE
Contenido 𝑋=1 X = Coherencia • Frecuencia: Al final de
las actividades de los
paquetes 1.1, 1.2.1,
1.2.2, 1.2.3, 1.3.1,
1.3.2, 2.1, 2.2, 2.3, 2.7,
3.1.1, 3.1.2, 3.1.3, 3.5,
4.5, 5.1.2.2, 5.2.1,
5.2.2, 5.2.3, 5.2.4,
5.3.1, 5.3.2 y 5.5 del
WBS y cuando se
desee emitir un
• Frecuencia: Al
final de las
actividades de
los paquetes 1.1,
1.2.1, 1.2.2,
1.2.3, 1.3.1,
1.3.2, 2.1, 2.2,
2.3, 2.7, 3.1.1,
3.1.2, 3.1.3, 3.5,
4.5, 5.1.2.2,
5.2.1, 5.2.2,
𝑋=0 X = Ortografía
𝑋=𝑆I X = Formal
𝑋=𝑆I X = Paginación
𝑋=1 X = Gráficos

documento dentro del
proyecto.
• Medición: En la fecha
que se termine con el
paquete de trabajo y
cada vez que se quiera
emitir algún documento
dentro del proyecto.
5.2.3, 5.2.4,
5.3.1, 5.3.2 y 5.5
del WBS y
cuando se desee
emitir un
documento
dentro del
proyecto.
• Reporte: Dentro
de las 8 horas
siguientes de
realizado el
proyecto.
𝑋=𝑆I X = Anexos
Referencias 𝑋=𝑆I X = Versión
𝑋=𝑆I X = Creador
𝑋=𝑆I X = Revisor
𝑋=𝑆I X = Aprobador
𝑋=𝑆I X = Fecha
𝑋=𝑆I X = Motivo
Formato 𝑋=𝑆I X = Cumplimiento
con el formato
PLAN DE MEJORA DE PROCESOS
Cada vez que se quiera mejorar un proceso se seguirá los siguientes pasos :
Delimitar el proceso:
Definir el primer y último paso del proceso a mejorar.
Determinar la oportunidad de mejora:
Analizar los pasos del proceso que son susceptibles a mejorar.
Tomar información sobre el proceso:
Toda la información del proceso a mejorar.
Analizar la información levantada:
Identificar que problemas existen dentro del proceso a mejorar.
Definir acciones preventivas o correctivas:
Implementar las prevenciones o correcciones en el proceso con problemas.
Aplicar acciones correctivas:
Implementar las correcciones en el proceso con problemas.
Verificar la efectividad de la aplicación de acciones preventivas/correctivas:
Evaluar si el proceso ha mejorado.
Documentar las mejoras y hacerlas parte del proceso:
Redefinir el proceso con las mejoras ya aplicadas.

DIAGRAMA DE FLUJO PARA MEJORA DE PROCESOS

MATRIZ DE ACTIVIDAD DE CALIDAD
PAQUETE DE
TRABAJO
TAREAS DE
PREVENCION
TAREAS DE CONTROL
1.1 Plan General del
Proyecto Actualizado
Aprobación por el Sponsor
1.2.1.1 Verificación del
Alcance
Revisión del Proyect
Charter
Revisión por Jefe de
Proyecto
1.2.1.2 Mediciones del
Rendimiento en Tiempo
Revisión por el Jefe de
Proyecto
1.2.1.3. Mediciones del
Rendimiento en Costo
Proyecto y Jefe de Gestión
Costo
1.2.1.4. Mediciones de
Control de Calidad
Mediciones de métricas de
calidad
Proyecto y Jefe de Control
de Calidad
1.2.1.5. Documento de
Información de
Monitoreo de Riesgos
Proyecto y Consejero de
Riesgo
1.2.1.6. Evaluación del
Rendimiento del Equipo
Proyecto
1.2.2. Acciones
Correctivas y
Preventivas
Proyecto
1.2.3 Autorización de
Cambios
de Cambio y Actualización
1.2.4 Documentación de
Lecciones Aprendidas
Proyecto
1.3.1.Cierre Operativo
Aprobación por Jefe de
Proyecto
1.3.2.1 Cierre Contable
Proyecto
1.3.2.2 Cierre de
Contrato
Aprobación por Sponsor
2.1 Arquitectura de
Negocio (Mapa de
Procesos)
Desarrollo
2.2 Glosario de Negocio
Desarrollo
2.3 Reglas de Negocio
Desarrollo
2.4 Modelo de Casos
de Uso del Negocio
Desarrollo

2.5 Diagrama de
Actividad del Negocio
Desarrollo
2.6 Diagrama de Clases
del Negocio
Desarrollo
2.7 Cierre de Fase Aprobación por Sponsor
3.1.1 Requerimientos de
los Interesados
(Usuarios)
Proyecto
3.1.2 Requerimientos
Funcionales del Sistema
Revisión de la
Documentación e
Requisitos
Aprobación de Jefe de
Desarrollo
3.1.3 Requerimientos No
Documentación de
Requisitos
Desarrollo
3.2.1.1 Matriz de
Trazabilidad del Sistema
Proyecto
3.2.1.2 Especificación
de Casos de Uso
Revisión de Requisito
Desarrollo
3.2.1.3 Diagrama de
Casos de Uso del
Sistema
Revisión de requisitos
Desarrollo
3.2.2 Diagrama de
Clases
Revisión de requisito
Desarrollo
3.2.3 Diagrama de
Estados
Desarrollo
3.2.4 Diagrama de
Secuencia
Desarrollo
3.2.5 Diagrama de
Comunicación
(Colaboración)
Revisión de Requisitos
Desarrollo
3.3.1 Diagrama Entidad
– Relación
Desarrollo
3.3.2 Diagrama del
Modelo de Datos
(Modelo Físico)
Desarrollo
3.3.3 Diccionario de
Datos
Revisión del Modelo de
Datos
Desarrollo
3.4 Prototipos de
Interfaz de Usuario
Desarrollo

4.1 Priorización de
Subsistemas
Desarrollo
4.2 Base de Datos
datos
Desarrollo
4.3.1 Módulo de Gestión
de Usuarios
Desarrollo
4.3.2 Módulo de
Mantenimiento
Desarrollo
4.3.3 Módulo de
Reportes y Consultas
Desarrollo
4.3.4 Módulo de
Procesos
Aprobación pro Jefe de
Desarrollo
4.4 Sistema Integrado
Desarrollo
5.1.1 Plan de Pruebas
Desarrollo
5.1.2.1 Realización de
Prueba
Desarrollo
5.1.2.2 Informe de
Prueba
Desarrollo
5.2.1 Manual Técnico
(Instalación y
Configuración)
Revisión de Módulos
Desarrollo
5.2.2 Manual de Sistema Revisión de Módulos
Aprob ación por Jefe de
Desarrollo
5.2.3 Manual de Usuario Revisión de Módulos
Desarrollo
5.2.4 Ayuda del Sistema Revisión de Módulos
Desarrollo
5.3.1 Plan de
Capacitación
Desarrollo
5.3.2 Informe de
Capacitación
Desarrollo
5.4.1 Diagrama de
Despliegue
Proyecto
5.4.2 Software
Empaquetado
Proyecto

ROLES PARA LA GESTION DE CALIDAD
Rol Nº1
SPONSOR
Objetivo del rol: Responsable ejecutivo y final por la
calidad del proyecto.
Funciones del rol: Revisar, aprobar, y tomar acciones
correctivas para mejorar la calidad.
Nivel de autoridad: Aplicar a discreción los recursos de
Dharma para el proyecto, renegociar
contratos.
Reporta a: Directorio
Supervisa a: Jefe del Proyecto
Requisitos de conocimientos: Gestión en General.
Requisitos de habilidades: Liderazgo, comunicación,
negociación, motivación y solución de conflictos.
Rol Nº2
JEFE DEL PROYECTO
Objetivo del rol: Gestionar operativamente la calidad.
Funciones del rol: Revisar estándares, revisar
entregables, aceptar entregables o disponer su reproceso,
deliberar para generar acciones correctivas, aplicar
acciones correctivas.
Nivel de autoridad: Exigir el cumplimiento de entregables
al Equipo del Proyecto.
Reporta a: Sponsor
Supervisa a: Equipo del Proyecto
Requisitos de conocimientos: Gestión de proyectos,
gestión financiera, administración de personal,
tecnologías de la información.
Requisitos de habilidades: Liderazgo, comunicación,
negociación, motivación y solución de conflictos.
Rol Nº 3
MIEMBROS DEL ÁREA
DE CONTROL DE
CALIDAD
Objetivos del rol: Medir frecuentemente la calidad dentro
del proyecto y promover mejoras para el cumplimiento de
los objetivos de calidad del proyecto.
Funciones del rol: Medir los factores de calidad mediante
métricas de calidad, evaluar la performance del proyecto
mediante informes de seguimiento, reportar el estado de
las mediciones de calidad obtenidas, formular acciones
preventivas y correctivas.
Nivel de autoridad: Exigir el cumplimiento de los objetivos
de calidad planificados al Equipo del Proyecto.

Reporta a: Jefe del Proyecto
gestión de la calidad, tecnologías de la información.
Requisitos de habilidades: Comunicación, objetividad,
influencia, negociación.
Rol Nº 4
MIEMBROS DEL ÁREA
DE GESTIÓN DE
CAMBIOS Y
ACTUALIZACIONES
Objetivos del rol: Gestionar las solicitudes de cambio que
puedan formularse a lo largo del proyecto.
Funciones del rol: Analizar la viabilidad de las solicitudes
de cambio, formular acciones preventivas y correctivas,
implementar los cambios aprobados.
Nivel de autoridad: Implementar cambios previa
aprobación del Jefe del Proyecto.
gestión de la calidad, tecnologías de la información.
Requisitos de habilidades: Comunicación, objetividad,
influencia, negociación.
Rol Nº 5
MIEMBROS DEL
EQUIPO DEL
PROYECTO
Objetivos del rol: Elaborar entregables con la calidad
requerida y según estándares.
Funciones del rol: Elaborar los entregables.
Nivel de autoridad: Aplicar los recursos que se le han
asignado.
Requisitos de conocimientos: Gestión de Proyectos y las
especialidades que le tocan según sus entregables
asignados.
Requisitos de habilidades: Específicas según los
entregables.
ORGANIZACIÓN PARA LA CALIDAD DEL PROYECTO

DOCUMENTOS NORMATIVOS PARA LA CALIDAD
PROCEDIMIENTOS
1. Para Mejora de Procesos
2. Para Auditorias de Procesos
3. Para reuniones de Aseguramiento de la Calidad.
4. Para medición de Métricas de Calidad
FORMATOS
1. Línea Base de Calidad
2. De Informe de Performance del Proyecto
3. De Informe de Métrica de Calidad
4. De Acciones correctivas
5. De Acciones preventivas
PROCESOS DE GESTIÓN DE LA CALIDAD
ENFOQUE DE
ASEGURAMIENTO
DE LA CALIDAD
(QA)
El aseguramiento de calidad se hará monitoreando
continuamente la performance del trabajo, los resultados del
control de calidad, y sobre todo las métricas.
De esta manera se descubrirá tempranamente cualquier
necesidad de auditoría de procesos, o de mejora de procesos.

Los resultados se formalizarán como solicitudes de cambio
y/o acciones
correctivas/preventivas.
Se verificará que las solicitudes de cambio aprobadas y/o
acciones preventivas o correctivas se hayan ejecutado y
hayan sido efectivas.
ENFOQUE DE
CONTROL DE LA
CALIDAD (QC)
El control de calidad se ejecutará revisando los entregables
para ver si son conformes o no.
Los resultados de estas mediciones se consolidarán y se
enviarán al proceso de aseguramiento de calidad.
Asimismo, en este proceso se hará la medición de las
métricas y se informarán al proceso de aseguramiento de
calidad.
Los entregables que hayan sido reprocesados se volverán a
revisar para verificar su conformidad.
Para los defectos detectados se tratará de encontrar sus
causas raíces y eliminar las fuentes de los errores. Los
resultados se formalizarán como solicitudes de cambio y/o
acciones preventivas o correctivas.
ENFOQUE DE
MEJORA DE
PROCESOS
Cada vez que se requiera mejorar un proceso se
seguirán los siguientes pasos:
1. Delimitar el proceso.
2. Determinar la oportunidad de mejora.
3. Tomar información sobre el proceso.
4. Analizar la información levantada.
5. Definir acciones preventivas o correctivas.
6. Aplicar acciones preventivas o correctivas.
7. Verificar la efectividad de la aplicación de acciones
preventivas/correctivas.
8. Documentar las mejoras para hacerlas parte del
proceso.

5.2. Plantilla de Métrica de Calidad
PLANTILLA DE MÉTRICA DE CALIDAD Nro. 01
MÉTRICA DE:
PRODUCTO PROYECTO X
FACTOR DE CALIDAD RELEVANTE
Performance del Proyecto
DEFINICIÓN DEL FACTOR DE CALIDAD
La performance del proyecto significa la culminación del cronograma y del presupuesto del proyecto.
Este factor de calidad permitirá al equipo de proyecto saber si están desarrollando las actividades que están
en el cronograma o si existe adelanto o retrasos.
PROPÓSITO DE LA MÉTRICA
Supervisar la ejecución del proyecto en el cronograma y el presupuesto.
DEFINICIÓN OPERACIONAL
El área para la medición de control de calidad va calcular el valor ganado, el número de días
hasta el final de cada fase, calculará el CPI (Índice de performance del costo) y el SPI (Índice del
performance del cronograma) y obtendrá indicadores de rendimiento del proyecto.
MÉTODO DE MEDICIÓN
1. Se recopilará información de avances reales, valor ganado, fecha de inicio y fin, trabajo y costo, estos
datos serán ingresados en el MS Project.
2. El MS Project calculará los índices de CPI y SPI.
3. Estos índices se trasladarán al Informe de Performance del Proyecto.
4. Se revisará el informe junto con el jefe del Proyecto y se tomarán las acciones correctivas.
5. Se comunicará al cliente de dichas acciones de ser el caso.
RESULTADO DESEADO
1. Para el CPI se desea un valor acumulado no menor de 0.95
2. Para el SPI se desea un valor acumulado no menor de 0.95
ENLACE CON OBJETIVOS ORGANIZACIONAL

La realización de esta métrica es indispensable para manejar de manera correcta la gestión del
proyecto SWGV; el cual hará posible el aumento de práctica y experiencia.
RESPONSABLE DEL CONTROL DE CALDIAD
El jefe del departamento de control de calidad es responsable de monitorear los factores de
calidad y promover las mejoras de proceso necesarias para alcanzar los objetivos de calidad
establecidos.
La responsabilidad de cumplir con la calidad requerida recae en el jefe del proyecto.
MÉTRICA DE:
PRODUCTO PROYECTO X
Satisfacción de los clientes
Es la situación en donde el cliente está satisfecho con el desarrollo y la obtención de nuestro producto,
situación que le permite confiar y contar con nuestro equipo de proyectos para futuros proyectos.
Este factor de calidad es muy importante debido a que un cliente satisfecho es el mejor indicador de nuestra
gestión en el proyecto.
El propósito de la métrica es determinar si nuestros recursos están trabajando correctamente,
con un trato amigable y siempre cumpliendo con los requerimientos de nuestros clientes.
La métrica operará en base a valores predefinidos entre 1 y 5:
1. Muy malo
2. Malo
3. Regular
4. Bueno
5. Muy bueno
El jefe de Calidad del proyecto será el encargado de entrevistar al cliente mediante una encuesta
que se realizará por cada categoría. El contacto con el cliente se manejará de forma interna
dependiendo de su disponibilidad. Los resultados serán reportados el mismo día.

1. Se realizará una encuesta dirigida a los clientes.
2. El jefe de calidad del proyecto pedirá a los clientes que respondan la encuesta.
3. El jefe de calidad del proyecto revisara las encuestas.
4. Se informará los resultados al área de gestión de Cambios.
RESULTADO DESEADO
Se espera que todas las encuestas den un resultado mayor o igual a 4.
El cumplimiento de esta métrica es importante para manejar de manera adecuada la gestión del
proyecto SWGV desde la perspectiva de la satisfacción de los clientes
El responsable de vigilar estos factos de calidad y los resultados es la jefa de calidad del
proyecto. Mejorar los procesos que son tan importantes para obtener los objetivos de calidad
planteados es responsabilidad del deje fe área del control de calidad.
MÉTRICA DE.
PRODUCTO X PROYECTO
Conformidad con requerimientos
La conformidad con requerimientos del producto de software significa como el grado en que los
requerimientos del software tienen la conformidad del usuario. Este factor de calidad es relevante ya que
permitirá gestionar las acciones pertinentes si es que los requerimientos del software cambian
indiscriminadamente.
NOMBRE DE LA MÉTRICA
Índice de conformidad con requerimientos.
Reducir los cambios de los requerimientos del software.

El jefe de calidad actualizará los esquemas de Conformidad con requerimientos cuando terminen las
actividades de los paquetes 4.4, 4.5, 5.4.1 y 5.2.4 del WBS. El reporte de los resultados se hará al día siguiente.
1. Fórmula: 𝑋=𝐴/𝐵
2. Valores: A = número de requerimientos cambiados, B = requerimientos totales.
3. Tipo de medida: A y B son números enteros, X es decimal.
4. Audiencia: Programadores, Usuarios.
RESULTADO DESEADO
Se espera que en la medición se obtenga un valor menor o igual 0.1
El cumplimiento de esta métrica es importante para poder manejar de forma correcta la gestión del desarrollo
del producto.
RESPONSABLE DEL CONTROL DE CALIDAD
El responsable de observar este factor de calidad y elevar las mejoras que sean necesarias será el jefe de
calidad. La responsabilidad de cumplir con la calidad requerida recae en el jefe del proyecto.
MÉTRICA DE:
PRODUCTO X PROYECTO
Seguridad de acceso
La seguridad de acceso del producto de software significa la capacidad de proteger la información de las
personas no autorizadas no puedan leer o modificar los datos de los usuarios.
Intrusiones no permitidas realizadas
Contabilizar el número de accesos no permitidos.
El jefe de calidad actualizará los esquemas de seguridad de acceso una vez se terminen las actividades de los
paquetes 5.1.2.1 del WBS. El reporte de los resultados se hará luego de 8 horas.

Se realizarán intentos de intrusiones manuales y ejecutables al software y a la base de datos.
1. Fórmula: 𝑋=Cantidad de instrucciones no permitidas realizadas
2. Interpretación: 𝑋≥0
3. Tipo de medida: X entero.
4. Fuentes: Pruebas, Informe de revisión.
5. Audiencia: Programadores.
RESULTADO DESEADO
Se desea que en todas las mediciones se obtenga un valor de 𝑋=0. Si se llegara a obtener un valor mayor a
cero no se garantiza la seguridad.
El cumplimiento de esta métrica es importante para manejar de manera adecuada la gestión del desarrollo
del producto.
RESPONSABLE DEL CONTROL DE CALIDAD
El responsable de observar este factor de calidad y elevar las mejoras que sean necesarias
será el jefe de calidad.
MÉTRICA DE:
PRODUCTO X PROYECTO
Aprendizaje
El aprendizaje del producto significa aprender sobre su aplicación.
Índice de funciones en el manual del usuario.
Conocer qué proporción de las funciones del software se detallan en el manual de usuario.

El jefe de calidad actualizará los esquemas de aprendizaje una vez que finalicen las actividades de los paquetes
5.2.1, 5.2.2, 5.2.3 y 5.2.4 del WBS. El reporte de los resultados se realizará al día siguiente.
2. Valores: A = número de funciones en el manual de usuario. B = total de funciones del programa.
3. Interpretación: 0≤𝑋≤1
4. Tipo de medida: A y B son números enteros. X es decimal.
5. Fuentes: Diseño del sistema, Software, Manual de usuario.
6. Audiencia: Programadores, Documentadores.
RESULTADO DESEADO
Se espera que en todas las mediciones se obtenga el valor X=1. Si el valor llegara ser menor a uno indicaría
que existen funciones del software que no se detallan en el manual del usuario.
El cumplimiento de esta métrica es importante para manejar de manera adecuada la gestión del desarrollo
del producto.
El responsable de observar este factor de calidad y elevar las mejoras que sean necesarias
será el jefe de calidad.
PLANTILLA DE MÉTRICA DE CALIDAD Nro.06
MÉTRICA DE:
PRODUCTO X PROYECTO
Contenido
La documentación presenta un contenido de calidad que desea informar acerca del proyecto, este es un factor
de calidad relevante debido a que la información mostrada en dicha documentación debe ser coherente, legible
y formal.

Mejorar la comprensión del documento.
Los miembros del equipo actualizarán los esquemas de Calidad de Documentación una vez terminadas las
actividades de los siguientes paquetes de trabajo: 1.1, 1.2.1, 1.2.2, 1.2.3, 1.3.1, 1.3.2, 2.1, 2.2, 2.3, 2.7, 3.1.1,
3.1.2, 3.1.3, 3.5, 4.5, 5.1.2.2, 5.2.1, 5.2.2, 5.2.3, 5.2.4, 5.3.1, 5.3.2 y 5.5 del WBS y cada vez que se intente emitir
algún documento dentro del proyecto.
Coherencia
2. Valores: A = número de párrafos coherentes, B = total de párrafos del documento.
Ortografía
2. Valores: A = número de palabras con faltas ortográficas. B = total de palabras escritas en el documento.
Formal
1. ¿Es formal? (SI - NO)
Paginación
1. Número de página sin inconsistencias. (SI - NO)
Gráficos (aplicable o no)
2. Valores: A = gráficos comentados, B = total de gráficos.
Anexos (aplicable o no)
1. ¿Posee anexos requeridos? (SI - NO)
RESULTADO DESEADO
Valores deseados de medición:
1. Coherencia: 𝑋=1
2. Ortografía: 𝑋=0
3. Formal: 𝑋 = SI
4. Paginación: 𝑋=SI
5. Gráficos: 𝑋=1
6. Anexos: 𝑋=SI
El cumplimiento de esta métrica es indispensable para manejar de forma adecuada la gestión del proyecto
desde el punto de vista de calidad de la documentación. Ello hará posible el aumento de práctica y
experiencia en cuanto a Gestión de Proyectos se refiere para todos los miembros del equipo.

Los miembros del equipo del proyecto son los responsables directo de vigilar este factor de calidad y promover
las mejoras necesarias para lograr los objetivos designados. Asimismo, reportan al jefe del proyecto los
resultados de los entregable.
MÉTRICA DE:
PRODUCTO X PROYECTO
Referencias
El documento porta referencias que ayudan al equipo del proyecto y al usuario a comprender quienes son los
que intervienen en la elaboración, revisión y aprobación. Las referencias son conocidas como indicaciones
para ubicar el documento en un contexto específico.
Mejorar la especificidad de referencias para cada documento.
actividades de los siguientes paquetes de trabajo: 1.1, 1.2.1, 1.2.2, 1.2.3, 1.3.1, 1.3.2, 2.1, 2.2, 2.3, 2.7, 3.1.1,
3.1.2, 3.1.3, 3.5, 4.5, 5.1.2.2, 5.2.1, 5.2.2, 5.2.3, 5.2.4, 5.3.1, 5.3.2 y 5.5 del WBS y cada vez que se intente emitir
algún documento dentro del proyecto.
Versión
1. Se especifica la versión sin inconsistencias (SI - NO)
Creador
2. Se especifica el creador (SI - NO)
Revisor
3. Se especifica el revisor (SI - NO)
Aprobador
4. Se especifica el aprobador (SI - NO)
Fecha
5. Se especifica la fecha sin inconsistencias (SI - NO)
Motivo
6. Se indica el código del documento sin inconsistencias (SI - NO)
RESULTADO DESEADO

Valores deseados de medición:
Versión:
1. Se especifica la versión sin inconsistencias SI
Creador:
2. Se especifica el creador SI
Revisor:
3. Se especifica el revisor SI
Aprobador:
4. Se especifica el aprobador SI
Fecha:
5. Se especifica la fecha sin inconsistencias SI
Código:
6. Se indica el código del documento sin inconsistencias SI
Los miembros del equipo son los responsables de vigilar este factor de calidad y de promover las mejoras que
sean necesarias para lograr los objetivos de calidad planeados junto con el jefe del proyecto.

MÉTRICA DE:
PRODUCTO X PROYECTO
Formato
El formato de la documentación se define como el orden visual en que debe ser editado el documento. Este
factor de calidad es relevante porque permitirá a la persona un mejor entendimiento en cuanto a la
organización del documento.
Generalizar la edición de toda documentación por medio de formatos preestablecido.
actividades de los siguientes paquetes de trabajo1.1, 1.2.1, 1.2.2, 1.2.3, 1.3.1, 1.3.2, 2.1, 2.2, 2.3, 2.7, 3.1.1, 3.1.2,
3.1.3, 3.5, 4.5, 5.1.2.2, 5.2.1, 5.2.2, 5.2.3, 5.2.4, 5.3.1, 5.3.2 y 5.5 del WBS y cada vez que se intente emitir algún
documento dentro del proyecto.
Se compara el documento editado con el formato preestablecido:
1. Cumple con el formato (SI - NO)
RESULTADO DESEADO
Para todas las mediciones de esta métrica se desea un resultado SI.
Los miembros del equipo son los responsables de vigilar este factor de calidad y de promover las mejoras que
sean necesarias para lograr los objetivos de calidad planeados junto con el jefe del proyecto.

5.3. Línea Base de Calidad

5.4. Matriz de Actividad de Calidad

MATRIZ DE ACTIVIDAD DE CALIDAD
PAQUETE DE TRABAJO
TAREAS DE
PREVENCION
TAREAS DE CONTROL
1.1 Plan General del
Proyecto Actualizado
Aprobación por el Sponsor
1.2.1.1 Verificación del
Alcance
Revisión del Proyect
Charter
Proyecto
1.2.1.2 Mediciones del
Rendimiento en Tiempo
Proyecto
1.2.1.3.Mediciones del
Rendimiento en Costo
Costo
1.2.1.4.Mediciones de
Control de Calidad
Mediciones de métricas
de calidad
Proyecto y Jefe de Control
de Calidad
1.2.1.5.Documento de
Información de Monitoreo
de Riesgos
Proyecto y Consejero de
Riesgo
1.2.1.6.Evaluación del
Rendimiento del Equipo
Proyecto
1.2.2.Acciones Correctivas
y Preventivas
Proyecto
1.2.3 Autorización de
Cambios
de Cambio y Actualización
1.2.4 Documentación de
Lecciones Aprendidas
Proyecto
1.3.1.Cierre Operativo
Proyecto
1.3.2.1 Cierre Contable
Proyecto
1.3.2.2 Cierre de Contrato Aprobación por Sponsor
2.1 Arquitectura de Negocio
(Mapa de Procesos)
Desarrollo

2.2 Glosario de Negocio
Desarrollo
2.3 Reglas de Negocio
Desarrollo
2.4 Modelo de Casos de
Uso del Negocio
Desarrollo
2.5 Diagrama de Actividad
del Negocio
Desarrollo
2.6 Diagrama de Clases del
Negocio
Desarrollo
3.1.1 Requerimientos de los
Interesados (Usuarios)
Proyecto
3.1.2 Requerimientos
Revisión de la
Documentación e
Requisitos
Desarrollo
3.1.3 Requerimientos No
Documentación de
Requisitos
Desarrollo
3.2.1.1 Matriz de
Trazabilidad del Sistema
Proyecto
3.2.1.2 Especificación de
Casos de Uso
Revisión de Requisito
Desarrollo
3.2.1.3 Diagrama de Casos
de Uso del Sistema
Desarrollo
3.2.2 Diagrama de Clases Revisión de requisito
Desarrollo
3.2.3 Diagrama de Estados Revisión de requisito
Desarrollo
3.2.4 Diagrama de
Secuencia
Desarrollo
3.2.5 Diagrama de
Comunicación
(Colaboración)
Desarrollo
3.3.1 Diagrama Entidad –
Relación
Desarrollo
3.3.2 Diagrama del Modelo
de Datos (Modelo Físico)
Desarrollo

3.3.3 Diccionario de Datos
Datos
Desarrollo
3.4 Prototipos de Interfaz
de Usuario
Desarrollo
4.1 Priorización de
Subsistemas
Desarrollo
4.2 Base de Datos
datos
Desarrollo
4.3.1 Módulo de Gestión de
Usuarios
Desarrollo
4.3.2 Módulo de
Mantenimiento
Desarrollo
4.3.3 Módulo de Reportes y
Consultas
Desarrollo
4.3.4 Módulo de Procesos
Desarrollo
4.4 Sistema Integrado
Desarrollo
5.1.1 Plan de Pruebas
Desarrollo
5.1.2.1 Realización de
Prueba
Desarrollo
5.1.2.2 Informe de Prueba
Desarrollo
5.2.1 Manual Técnico
(Instalación y
Configuración)
Revisión de Módulos
Desarrollo
5.2.2 Manual de Sistema Revisión de Módulos
Desarrollo
5.2.3 Manual de Usuario Revisión de Módulos
Desarrollo
5.2.4 Ayuda del Sistema Revisión de Módulos
Desarrollo
5.3.1 Plan de Capacitación
Desarrollo

5.3.2 Informe de
Capacitación
Desarrollo
5.4.1 Diagrama de
Despliegue
Proyecto
5.4.2 Software
Empaquetado
Proyecto
5.5. Procedimientos de Gestión de la Calidad
1. MEJORA DE PROCESOS
PROCEDIMIENTO
Cada vez que se quiera mejorar un proceso se seguirá los siguientes
pasos:
1. Documentar las mejoras y hacerlas parte del proceso: Redefinir el
proceso con las mejoras ya aplicadas.
1. Delimitar el proceso: Definir el primer y último paso del proceso a mejorar.
2. Determinar la oportunidad de mejora: Analizar los pasos del proceso que
son susceptibles a mejorar.
3. Tomar información sobre el proceso: Toda la información del proceso a
mejorar.
4. Analizar la información levantada: Identificar que problemas existen
dentro del proceso a mejorar.
5. Definir acciones preventivas o correctivas: Implementar las prevenciones
o correcciones en el proceso con problemas.
6. Aplicar acciones correctivas: Implementar las correcciones en el proceso
con problemas.
7. Verificar la efectividad de la aplicación de acciones
preventivas/correctivas: Evaluar si el proceso ha mejorado.
8. Documentar las mejoras y hacerlas parte del proceso: Redefinir el
proceso con las mejoras ya aplicadas.

2. CONTROL DE REGISTROS
PROCEDIMIENTO
Cada vez que se requiera hacer un Registro de Calidad se debe realizar el
siguiente procedimiento:
1. Determina los registros: El Encargado Área debe determinar los registros
que son necesarios para mostrar evidencia de cumplimiento de sus
actividades.
2. Los protege: El Encargado de Área es el responsable de mantener el
“Control de Registros de Calidad”.
3. Almacena: El Encargado de Área debe proporcionar los formatos a las
personas que estén incluidas en la operación. Todo el Personal debe
conservar sus registros de acuerdo con lo establecido en este
procedimiento.
4. Recupera: Los Registros deben ser sometidos al Comité de Calidad y al
COMERI junto con los documentos del cual se derivan, como un sólo legajo
de documentos.
5. Retiene: Todos los registros deben ser llenados en todos sus campos, en
caso de que algún campo deba quedar vacío, se coloca una línea diagonal
cancelando el espacio que quedará sin ser llenado o se colocará la frase “No
Aplica” o N/A.
6. Control de los registros: Todos los registros deben ser legibles
(asegurando la claridad de lectura, no realizarlos a lápiz, sin tachaduras, ni
correcciones); estar identificados, almacenados y conservados facilitando
la localización de estos sin demora.
7. Disposición de los registros: Todos los registros del Sistema de Gestión
deben estar a disponibles a través del Intranet, en su formato original
(editable), de tal manera que puedan ser utilizados por el personal que los
requiera.

DIAGRAMA DE FLUJO
3. AUDITORIAS INTERNAS DE CALIDAD
PROCEDIMIENTO
Cada vez que se requiera hacer una Auditoria Interna de Calidad se deben
seguir los siguientes pasos:
1. Elaboración del programa anual de auditorias internas: Para la
realización de estas se debe tener en cuenta los resultados de auditorias
previas y la importancia de las actividades a auditar. El sistema de Gestión
de Calidad debe auditarse anualmente.
2. Aprobación del programa anual: La Dirección General es la encargada de
revisar el programa y darle el visto bueno.
3. Emisión del programa anual de auditorias internas: El programa
aprobado debe ser enviado a cada jefe de área o unidad de trabajo.
4. Selección de auditores internos: Los auditores deben ser personas
externas al área a auditar y debe ser seleccionado por el director de Calidad.
5. Plan de auditoría: La elaboración del plan de auditoría queda a cargo del
auditor seleccionado y es de libre formato libre.

6. Preparación de la auditoria: El auditor encargado prepara una lista de
chequeo si se requiere y prepara la auditoría.
7. Reunión de apertura: El auditor inicia con los trabajadores del área a
auditar presentes para evaluación.
8. Ejecución de la auditoría: El auditor inicia mediante la búsqueda de
evidencias objetivas.
9. Reunión de cierre: El auditor culmina la reunión informando el resumen
de las conformidades detectades.
10. Emisión de informe: El auditor realiza el informe detallado de la auditoria
realizada especificando el año, N° de auditoría, áreas auditas, desviaciones,
etc.
11. Propuesta de acciones correctivas: El director general realiza el propone
acciones correctivas en el informe de acciones correctivas y acciones
preventivas.
12. Aprobación de acciones correctivas: El auditor es el encargado de aprobar
estas acciones correctivas/preventivas.
13. Implementar acciones correctivas: El director general ejecuta las acciones
correctivas/preventivas.
14. Verificación de efectividad de acciones: El director evalúa la efectividad
de las acciones correctivas/ preventivas en el plazo establecido.
15. Registro en el informe de acción correctiva/ preventiva: Se registra la
adecuada implementación de las acciones correctivas/preventivas en el
informe de estas.

4. CONTROL DE NO CONFORMIDADES
PROCEDIMIENTO
Cada vez que se quiera realizar un Control de No Conformidades se debe
realizar el siguiente procedimiento:
1. Detección de No conformidades: Todo el personal debe comunicar los
procesos o servicios que sufrieron algún incidente.
2. Identificar el proceso/servicio No conforme: Se debe comunicar con el
responsable de Calidad para identificar los procesos que sufrieron alguna
incidencia.
3. Documentar la No conformidad: El responsable de Calidad debe
documentar estos incidentes y emitir un Informe de No Conformidad.
4. Definir y ejecutar medidas inmediatas: El responsable de Calidad
informará a la Dirección de Calidad, y definirá las medidas inmediatas a
tomar, así como el responsable de su ejecución. Será el responsable de
Calidad el que registre dichas medidas en el Informe de No Conformidad.
5. Verificar eficacia de medidas: El responsable de Calidad verifica la eficacia
de las medidas adoptadas para contrarrestar las incidencias.
6. Registro de resultados y cierre de la No conformidad: El responsable de
Calidad registra los resultados en el Informe de No Conformidad.
DIAGRAMA DE FLUJO

5. ACCIONES CORRECTIVAS
PROCEDIMIENTO
Cada vez que se quiera realizar Acciones Correctivas se deben tener en
cuenta los siguientes pasos:
1. Control de No Conformidades: Se revisa el documento para poder realizar
el análisis de causas por parte del responsable de Calidad.
2. Definir y registrar la acción correctiva: El responsable de Calidad definirá
la acción correctiva a aplicar y luego registrarlo en el informe de Acción
Correctiva/Preventiva.
3. Implantar la acción correctiva: El encargado de Calidad implanta la acción
correctiva, los procedimientos realizados y los cambios que resultaron
como consecuencia de la implementación de la acción correctiva.
4. Registro de resultados: El responsable de Calidad hará el registro de
resultados en el informe de Acción Correctiva/Preventiva luego de realizar
el estudio.
5. Verificar la eficacia de la acción correctiva: El encargado de Calidad junto
con el encargado del área verifican la efectividad de la acción correctiva.
6. Registro de resultados y cierre de la AC/AP: El encargado de Calidad
realiza el registro de resultado y el cierre del documento de Acción
DIAGRAMA DE FLUJO

6. ACCIONES PREVENTIVAS
PROCEDIMIENTO
Cada vez que se quiera realizar Acciones Preventivas se deben tener en
cuenta los siguientes pasos:
1. Detección de una No Conformidad: Se realiza la detección de potenciales
incidentes en servicios o procesos.
2. Definir y registrar la acción preventiva: El responsable de Calidad
definirá la acción preventiva a aplicar y luego registrarlo en el informe de
Acción Correctiva/Preventiva.
3. Implantar la acción preventiva: El encargado de Calidad implanta la
acción preventiva, los procedimientos realizados y los cambios que
resultaron como consecuencia de la implementación de la acción correctiva.
4. Registro de resultados: El responsable de Calidad hará el registro de
resultados en el informe de Acción Correctiva/Preventiva luego de realizar
el estudio.
5. Verificar la eficacia de la acción preventiva: El encargado de Calidad
junto con el encargado del área verifican la efectividad de la acción
preventiva.
6. Registro de resultados y cierre de la AC/AP: El encargado de Calidad
realiza el registro de resultado y el cierre del documento de Acción

0
20
40
60
80
100
120
140
día 0 día 1 día 2 día 3 día 4 día 5 día 6 día 7 día 8 día 9 día
10
día
11
día
12
día
13
Sprint 2
Esfuerzo Pendiente Ideal
5.6. Burndown Chart
Día
Esfuerzo
Pendiente
Ideal
día 0 130 130
día 1 115 120
día 2 105 110
día 3 90 100
día 4 90 90
día 5 90 80
día 6 65 70
día 7 55 60
día 8 48 50
día 9 37 40
día 10 19 30
día 11 5 20
día 12 0 10
día 13 0 0
Día
Esfuerzo
Pendiente
Ideal
día 0 120 120
día 1 110 105
día 2 95 90
día 3 70 75
día 4 50 60
día 5 50 45
día 6 20 30
día 7 15 15
día 8 0 0
0
20
40
60
80
100
120
140
día 0 día 1 día 2 día 3 día 4 día 5 día 6 día 7 día 8
Sprint 1
Esfuerzo Pendiente Ideal

Anexo 01: Matriz de Consistencia
PROBLEMA GENERAL OBJETIVO
GENERAL
HIPOTESIS GENERAL VARIABLES METODOLOGIA POBLACION Y
MUESTRA
¿De qué manera la
gestión de ventas y
control del sistema web
influye en las empresas
en estos tiempos de
pandemia?
Determinar de qué
manera la gestión
de ventas del
sistema web influye
en la tienda de ropa.
El sistema web influye
significativamente en la
gestión de calidad y
control de ventas.
VARIABLE
INDEPENDIENTE:
Sistema web
DIMENSIONES:
Plataforma
Simplificación
Eficiencia
Productividad
VARIABLE
DEPENDIENTE:
Gestión de calidad y
control
DIMENSIONES:
Registro de usuario
Calidad de servicios
TIPO:
Aplicativo
ENFOQUE:
Cuantitativo
METODO:
Hipotético y deductivo
NIVEL:
Explicativo
DISEÑO:
Correlacional causal
POBLACION:
MUESTRA:
En los centros de
salud
MUESTREO:
No probabilístico
PROBLEMA
ESPECIFICOS
¿Cuáles fueron los
cambios más radicales de
adaptación de las
empresas para poder
optar con canales de
ventas relacionadas a las
TIC durante la pandemia?
¿De qué manera influyo
los tics para el comercio
electrónico en épocas de
pandemia?
OBJETIVOS
ESPECIFICOS
Determinar si un
sistema web mejora
el registro de
usuarios para la
tienda de ropa.
Comprobar si un
sistema web mejora
la calidad de ventas
para la tienda de
ropa.
HIPOTESIS
ESPECIFICOS
El sistema web mejora
significativamente el
registro de usuarios
para la gestión de
ventas.
El sistema web mejora
significativamente la
calidad de servicios
para la gestión de
ventas.

Anexo 02: Metodología Scrum
Según (César Rodríguez & Rubén Dorado, 2015) menciona que scrum es una
metodología ágil, en la cual el comparativo con las metodologías tradicionales
parte de la base del comparativo que se realiza entre una tradicional y una ágil.
En la cual la metodología scrum se basa en iteraciones cortas que entregan una
parte del producto, incremento del producto y no su completitud, para que a partir
de esta el producto evolucione.
Fase I: Sprint Planning
En la fase de planificación de sprint se desarrolló lo siguiente:
Para la planificación. La visión, el presupuesto, el financiamiento, el backlog
del producto, la fecha de desarrollo de cada sprint, el equipo de trabajo y las
herramientas de desarrollo.
Para la Arquitectura. El diseño de la implementación de las funcionalidades en
relación con las especificaciones del product backlog y el diseño.
Product Backlog
Prioridad Historia de Usuario Tarea Puntos
1 H1 - Inicio de sesión
T1 - Pagina Log In
30
T2 - Conexión a BD
2 H2 - Modificar credenciales T3 - Pagina Modificar Usuario 50
3 H3 - Agregar productos
T4 - Apartado Productos
70
T5 – Apartado Agregar producto
4 H4 - Lista de productos T6 – Enlistar productos 20
5
H5 – Lista de productos
filtrados
T7 – Tabla para filtrar productos 40
6 H6 – Modificar Productos
T8 – Agregar opción modificar en la tabla
70
T9 – Crear funcion para modificar producto
7 H7 – Eliminar Productos
T10 – Agregar opción eliminar en la tabla
40
T11 – Crear funcion para eliminar producto
8 H8 – Compra de productos T12 – Agregar carrito de compras 80
9 H9 – Lista de usuarios
T13 – Enlistar usuarios
40
T14 – Crear la opción eliminar en la tabla
10 H10 – Contraseña encriptada
T15 – Crear la funcion para encriptar
contraseña de manera automática
40

Sprint Backlog
Nro. Historia de Usuario Actividades
Estimación
(/días)
Total
(/días)
1
H1 - Inicio de sesión
T1 - Pagina Log In
T2 - Conexión a BD
4
8
H2 - Modificar credenciales T3 - Pagina Modificar Usuario 1
H10 – Contraseña encriptada
T15 – Crear la función para encriptar
contraseña de manera automática
3
2
H3 - Agregar productos
T4 - Apartado Productos
7
13
T5 – Apartado Agregar producto
H4 - Lista de productos T6 – Enlistar productos 2
H5 – Lista de productos
filtrados
T7 – Tabla para filtrar productos 4
3
H6 – Modificar Productos
T8 – Agregar opción modificar en la
tabla
5
10
T9 – Crear funcion para modificar
producto
H7 – Eliminar Productos
T10 – Agregar opción eliminar en la
tabla
5
T11 – Crear funcion para eliminar
producto
4 H8 – Compra de productos T12 – Agregar carrito de compras 7 7
5 H9 – Lista de usuarios
T13 – Enlistar usuarios
7 7
T14 – Crear la opción eliminar en la
tabla

Fase II: Historia de Usuario
Historia de Usuario
Número: 1 Usuario: Cliente
Nombre historia: Inicio de sesión
Prioridad en negocio:
Media
Riesgo en desarrollo:
Medio
Puntos estimados: 30
Programador responsable: Jose Ramos
Descripcion: El sistema debe contar con una página de inicio
de sesión, donde solicita ingresar usuario y contraseña.
Validación: Si se ingresa un usuario o contraseña invalido, se
redireccionará a una página mostrando el error.
Historia de Usuario
Nombre historia: Modificar credenciales
Media
Media
Programador responsable: Eduardo Cáceres
Descripcion: El usuario deberá ser capaz de modificar sus
credenciales de acceso al sistema.
Validación: Debe existir un apartado de "Datos del usuario", en
el cual se muestra la opción de modificar contraseña.
Historia de Usuario
Número: 3 Usuario: Empleado
Nombre historia: Agregar productos
Alta Riesgo en desarrollo: Alta
Descripcion: Permitir agregar catálogos y productos al sistema
web.
Validación: El sistema permitirá agregar catalogo y, asimismo,
agregar productos los cuales se alojarán en la base de datos
MySQL

Historia de Usuario
Nombre historia: Lista de productos
Descripcion: Debe existir la posibilidad de visualizar los
productos ingresados.
Validación: El sistema web debe contener un apartado el cual
muestra la lista de productos registrados, mostrando STOCK,
etc.
Historia de Usuario
Nombre historia: Lista de productos filtrados
Descripcion: Debe existir la posibilidad de filtrar la lista de
productos de acuerdo a sus características.
Validación: En la tabla de lista de productos debe existir la
forma de filtrar los productos de acuerdo a su Talla, Precio,
Stock, entre otros.
Historia de Usuario
Nombre historia: Modificar productos
Media
Media
Descripcion: El rol de empleado o superior debe permitir
modificar los datos de un producto.
Validación: Debe existir un apartado el cual permita la
modificación de las características de un producto.

Historia de Usuario
Nombre historia: Eliminar productos
Media
Media
Descripcion: El sistema web debe permitir la eliminación de
un producto.
Validación: Existe un botón "eliminar" en la lista de productos,
el cual permitirá la eliminación del producto seleccionado.
Historia de Usuario
Nombre historia: Compra de productos
Descripcion: El sistema web debe permitir agregar a la orden
de compra aquellos productos de acuerdo a su stock.
Validación: Debe existir un carrito de compras.
Historia de Usuario
Número: 9 Usuario: Administrador
Nombre historia: Lista de usuarios
Media
Media
Descripcion: El sistema web debe permitir eliminar usuarios.
Validación: Debe existir un listado de todos los usuarios

Historia de Usuario
Número: 10 Usuario: Administrador
Nombre historia: Contraseña encriptada
Media Riesgo en desarrollo: Media
Descripcion: La contraseña debe estar encriptada.
Validación: Debe existir una funcion que encripte las
contraseñas de manera automática para mayor seguridad.

Sprint N1
Pagina de inicio de sesión
Conexión a base de datos y muestra de contraseña encriptada

Cambiar contraseña:
Video de funcionalidad del prototipo:
https://youtu.be/vxE6oQ3Iar8

Sprint N2
Categorias
Productos : tabla donde se puede filtrar producto de acuerdo a
talla, precio y stock
Productos: tabla donde se puede filtrar producto de acuerdo con la
talla, precio y stock

Agregar productos y filtrarlos
Video de funcionalidad del prototipo: https://youtu.be/R3WHMVfT05s
Sprint N3
Modificar producto

Sprint N4
Selecciona product a comprar
Sprint N5
Listar usuarios

Cerrar Sesión.
Anexo 03: Plan de Calidad

Anexo 04: Plantilla de Caso de Prueba
ID Caso de
Prueba
Descripción Fecha Área
funcional/Subproceso
Funcionalidad
/ Característica
1 Límite de
valores
En el registro de un usuario se
solicita el DNI y el sistema debe
validar que el límite de dígitos que se
puede ingresar debe ser 8 y solo
números.
2/11/2022 Registro de usuario Registrar un
usuario
2 Validar no
repetir el
DNI
En el registro de un usuario el
sistema debe validar que un DNI ya
esté registrado y no permita
registrarlo otra vez.
2/11/2022 Registro de usuario Registrar un
usuario
3 Contador
de lista de
usuario
El sistema debe actualizar el id de la
cantidad del número de usuarios que
están registrados.
2/11/2022 Listado de usuario Lista de
usuarios
4 Cargar
imágenes
El sistema cargar correctamente las
imágenes.
2/11/2022 Página de inicio Página de inicio
Anexo 05: Plan de Gestión de Cambios

Capstone_Nota_Menor_ (1).docx

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Ähnlich wie Capstone_Nota_Menor_ (1).docx

Ähnlich wie Capstone_Nota_Menor_ (1).docx (20)

Mehr von RoySaavedraJimenez2

Mehr von RoySaavedraJimenez2 (7)

Capstone_Nota_Menor_ (1).docx