Segunda Entrega pruebas y calidad de software

Presentado por:

Juan Manuel Gutierrez 1510650053

Cindy Lorena Castro López 1811981613

William Miguel Avila Medrano 1811982984

Jose Miguel Herazo Hoyos 1621022488

Johan Sebastian Salgado Junca 1710650392

Presentado a:

Nelson Orlando Pérez Echeverri

Ingeniería de software

2019
 1

Tabla de contenidos

Introducción 4

Objetivos 5

Primera Entrega 7

Comparativo modelos de calidad 7

Entrevista a la empresa 10

Criterios de validación estado de avance. 19

Implantación plan mínimo de pruebas. 21

Estrategias y modelo a seguir. 21

Actividades a mejorar. 21

Segunda Entrega 23

Documentación actividades, proceso y procedimientos. 23

Identificación. 23

Referencias. 24

Introducción. 25

Aspectos importantes y críticos del producto y proyecto. 25

Proceso de pruebas. 25

Objetivo. 25

Cronograma. 25

Presupuesto. 26

Actividades. 26

Personal. 27

Responsabilidades, roles y formatos. 27

2
 3

Lista de figuras

Figura 1. Cronograma de actividades.

 4

Introducción

Desde el principio de la ingeniería de software, se observó que la calidad en la realización de

software se es vital, con este trabajo planteamos un modelo de pruebas el cual será descrito a
medida que el lector avance en su lectura.
 5

Objetivos

● Identificar los distintos modelos de calidad que se pueden llegar a aplicar en un proyecto
analizar sus pros y contras.
● Determinar mediante una investigación cómo se aplica cada modelo a la empresa.
● Elegir el mejor modelo para la empresa y elaborar un plan para su implementación.
6
 7

Primera Entrega

Comparativo modelos de calidad

Describa los elementos de los diversos modelos de calidad que se pueden aplicar al desarrollo de
productos de software

Modelo Descripción Elementos Ventajas Desventaja

PMBOK Está orientado a la -Iniciación. -​ La guía PMBOK

Dirección de Proyectos, es un marco
-Planificación. estándar. -​ Complejo
abarcando todo el ciclo
para proyectos
de vida del producto, pequeños.
-Ejecución. -​ Es orientada a
pero con un tiempo procesos.
fijado y fecha de fin, -Monitoreo y
separando control. - Define para cada
- Tiene que ser
específicamente en la proceso sus
adaptado a la
propia norma el objetivo -Cierre. insumos,
industria del
de los proyectos de la herramientas y
área de
reportes.
operación continua de aplicación,
soporte y respaldo de la tamaño
- Define una base
organización. La guía alcance del
de conocimiento
proyecto,
establece un exceso de en el que
tiempo,
gestiones cualquier industria
presupuesto y
administrativas, lo que pueda construir las
apremios de
mejores prácticas
produce un exceso de calidad.
específicas para
complejidad en el caso sua área de
de proyectos pequeños. aplicación.

CMMI Tiene como objetivo 1 - Proceso - ​Reducción del - ​Su

general la mejora de imprevisible costo de implementació
todos los procesos en la poco controlado desarrollo. n es compleja
organización para la y reactivo (PSP Personal
consecución de un nivel (​inicial​). Software
de madurez. El modelo - ​Localización y Process y TSP
 8

es complejo y está 2 - Proceso resolución de Team

planteado para la caracterizado errores. Software
estandarización de los para los Process ).
procesos en la empresa, proyectos y
pero muy orientado al menudo reactivo
desarrollo de proyectos y (​gestionado​). - ​Mejora en la
a procesos ya definidos fiabilidad de la - Implantarlo
que necesitan mejora. 3 - Proceso aplicación. en una
Por otro lado, no guía en caracterizado empresa
el establecimiento de para la requiere de
métricas y, aunque organización y tiempo.
- ​Aumento de la
indica las actividades proactivo productividad.
que se deben de realizar, (​Definido​)
no se involucra en la
forma de hacerlas. 4 - Proceso
medido y
controlado
(​Gestionado
cuantitativame
nte​).

5 - centrado
en la mejora de
procesos
(​Optimizado​).

COBIT Plantea un marco de - Planificar y - Implementa dire -​ Adoptar el

trabajo completo y organizar (PO). ctrices destinados modelo de
orientado a toda la a la alta gerencia Cobit podría
organización a un alto - Adquirir e para tomar ser complicado
nivel. Es la guía de implementar decisiones adoptarlo ya
mejores prácticas más (AI). respecto al que el cambio
completas, muy servicio que se de cultura
orientada a la definición - Entregar y dar vaya implementar podría ser
de métricas, controles y soporte (ES). o modificar. difícil
objetivos en la gestión de (cambiar la
procesos para el buen - Evaluar y -Cobit integra forma de
gobierno de la monitorear (M). auditoría que es el pensar de las
organización. Aunque proceso para personas).
establece procesos y indicar cómo
define métricas deben hacerse las - COBIT es un
concretas, no establece cosas, a modelo
 9

cómo llegar a obtener comparacion de ambicioso que

dichos procesos. otros marcos que requiere de un
no tienen este profundo
apartado. estudio para
realizar la
implementació
n dentro de la
organización.
Si se desea
adoptar no
importa el
tamaño de la
organización
estos marcos
están hechos
para
adoptarlos (es
un mundo de
información
para
adoptarlo).

Modelo También conocido como - Evaluación de -Modelos de -Permite que el

ISO/IEC Software Process procesos. dimensiones para dominio de
15504 Improvement Capability los procesos y la procesos sea
(SPICE) Determinación, -Mejora de capacidad. tan amplio
abreviado SPICE, en Procesos. para abarcar
español, “Determinación -Resultado de los todos los
de la Capacidad de -Evaluación de procesos se posibles ciclos
Mejora del Proceso de la capacidad y/o representan en un de vida, por lo
Software”. madurez de los perfil de procesos. que hace
procesos. difícil que
Establece requisitos para -Es un modelo todos los
una evaluación de consensuado y atributos de
procesos y los modelos probado. proceso sean
de evaluación universales,
pretendiendo que estos -Mayor provocando
requisitos puedan ser reconocimiento en dificultad y
aplicados en cualquier el mercado confusión
modelo de evaluación en europeo. durante la
una organización. evaluación.
- Menores costos
de la certificación. -Poco
reconocimient
 10

o en el
mercado
Norteamerican
o.

Entrevista a la empresa

Se realiza una pequeña entrevista a una empresa de transporte la cual cuenta con su propio
departamento de desarrollo el cual se encarga del desarrollo y mantenimiento de la aplicación
web. Se tuvo en cuenta cualidades como la compatibilidad, usabilidad, entre otras.

ITEM PREGUNTA RESPUESTA MEJORA

Correctitud 1. ¿Al someter al Si. Realizar

programa a diversas revisiones a las
tareas básicas, este tareas con el fin
cumple con los de que el
requerimientos de los proceso se
usuarios? mantenga.

2. ¿Realiza las tareas Si. Realizar

de manera tal que el revisiones a las
resultado de las tareas con el fin
mismas sea correcto? de que el
proceso se
mantenga.

Usabilidad 1. ¿Es sencillo de Si. Se pueden crear

entender y manejar el ayudas con
software para los indicaciones de
usuarios a los cuales manejo
está destinado su mediante
uso? ventanas
emergentes.
 11

2. ¿Es intuitivo y Si. Resaltar las

posee la información ayudas y
y ayudas adecuadas actualizarlas en
como para que el caso de ser
usuario no tenga que necesario.
depender de alguien
que explique cómo
utilizar cada función?

3. ¿Son cómodos los No. Aunque el Crear la opción

menús, los botones, sistema cuenta con para actualizar
las ventanas de su manual de las ayudas.
interfaces, los usuario, este no
cuadros de diálogo, está actualizado,
los formularios, además el software
etc.?¿Las jerarquías cuenta con muy
visuales son pocas ayudas de
correctas? utilización de este.

4. ¿Es sencillo No. El software Implementar las

realizar búsquedas y solo permite opción de
filtrar información realizar filtros en búsqueda, sea
dentro del programa? todos los casos con una
mediante un solo herramienta
parámetro, lo cual existente o uno
resulta ser tedioso desarrollada por
en algunos casos. la organización.
 12

Documentación y 1. ¿Posee el proyecto No. El sistema Cuando se

visibilidad una buena cuenta con poca desarrollen
documentación documentación nuevas
interna y externa (del interna. Además de funcionalidades
código fuente, y de la esto el software o se cambien o
ayuda al usuario). tiene como única mejoren las
Esto está relacionado documentación existentes
a otros factores, externa el manual actualizar el
como la usabilidad y de usuario y este manual
la comprensibilidad? sin embargo se constantemente
encuentra y versionar el
desactualizado. manual.

2. ¿Hay No. No se realiza Se debe

transparencia hacia ninguna documentar cada
afuera en las etapas documentación en etapa en el ciclo
de desarrollo (ciclo ninguna de las de desarrollo.
de vida), están etapas de
documentadas y desarrollo.
disponibles para el
cliente?

Compatibilidad 1. ¿Puede interactuar Si. El sistema se Mejorar el API

el software con otras encuentra que se expone a
aplicaciones que conectado con otras otro sistemas
complementan plataformas. usando un
tareas, o procesos estándar como
que necesita abarcar por ejemplo
el usuario? JSON.

2. ¿Sus reportes y Si. Los informes Actualizar una

datos están en descargados de la vez o dos al año
archivos compatibles plataforma se las librerías que
con aplicaciones de pueden extraer en generan los
uso común y popular archivos Excel. archivos de
(por ejemplo planilla Excel.
de Excel, que es el
 13

estándar de las hojas

de cálculo)?

Comprensibilidad 1. ¿Es amigable el No. Esto debido a Aplicar

software para los que no se cuenta estándares de
desarrolladores? con la desarrollo y un
documentación modelo a seguir
necesaria, además para que los
de esto el código desarrolladores
fuente es poco lo sigan y lo
legible debido a cumplan.
que la mayor parte
de él se encuentra
sin sangría.

2. ¿Pueden La mayoría del Optimizar el

comprender su código fuente es código para su
estructura lógica, sus poco legible. Sin legibilidad, se
funciones de embargo su pueden usar IDE
ejecución y estructura lógica, de desarrollo
procesamiento, su sus funciones y para identar el
código fuente es procesamiento, es código.
fácilmente legible y comprensible.
comprensible?

Confiabilidad 1. ¿Es confiable el Si. Crear una

software para el opción de
usuario final? satisfacción para
el usuario final.
 14

2. ¿Después de un Si. Crear respaldos

buen periodo de uso: de los datos de
sucede a veces que el los usuarios si es
usuario “desconfía” necesario
porque en ocasiones diariamente.
anteriores ha perdido
datos importantes
que le ha llevado
tiempo cargar?

3. ¿Cuándo falla, son Fallas leves. Escalar el tipo

fallas graves o leves, de falla y el
según las origen para su
consecuencias que mejora.
provocan?

Eficiencia 1. Cuando el No. Realizar de

volumen de datos mediciones de
crece dentro de lo tiempo de carga
contemplado, ¿el con cantidades
software se vuelve de datos
lento? determinadas.

2. Es capaz el Si. Crear micro

software de servicios para el
procesar/almacenar manejo de datos
datos de manera de una manera
eficiente? más eficiente.

3. ¿Comienza a No. Realizar

consumir muchos mediciones de
recursos de recursos del
hardware? sistemas tanto
en el cliente
como en el
servidor.
 15

4. ¿Se ve afectada la No. Crear una alerta

productividad de los que el usuario
usuarios por esta pueda ejecutar si
lentitud? percibe lentitud
en algún proceso
de la aplicación.

Escalabilidad 1. Escalabilidad No. Debido a la Con el estándar

funcional: ¿Es falta de de desarrollo
sencillo y documentación del creado más una
relativamente breve software es más buena
implementar al complicado la documentación
software nuevas realización de estas de código y
funcionalidades y mejoras. manuales de
servicios, a medida desarrollo
que surgen nuevo actualizado se
requerimientos? puede facilitar la
(legibilidad, implementación
comprensibilidad, de nuevas tareas.
documentación).

Funcionalidad 1. ¿Hay operaciones Si. Determinar las

que el software operaciones y
podría realizar empezar a
internamente y sin suplirlas desde
embargo hay que la misma
hacerlas “a mano” o aplicación.
en otras
aplicaciones?

2. ¿Son muy Si. Determinar las

limitadas o tareas que
incompletas las limitan la
funciones que realiza aplicación y
el software? realizar un plan
de mejora.
 16

3. ¿Resuelve casi Si. Determinar si

todos los problemas hay problemas
de operatividad y que no resuelve
gestión de la y mejorarlos,
información? mejorar los
existentes.

Mantenibilidad 1. ¿Es sencillo Si. Capacitar a los

corregir errores de desarrolladores
software (bugs o en el manejo de
funcionalidades mal dbugs para un
definidas)? (esto manejo más
depende del grado de eficiente de los
modularidad del errores.
software) si el
software es modular
se aísla problema
fácilmente y se gana
tiempo encontrando
y corrigiendo errores.

2. ¿Es sencillo hacer No. No es sencillo Actualizar o

adaptaciones cuando por falta de crear los
se alteran levemente documentación. documentos
los requerimientos faltantes o
iniciales? existentes.

3. ¿Es sencillo Si. Crear un

adaptar el software si documento con
se modifica su requerimientos
entorno de mínimos para el
aplicación, si se uso de la
actualiza el sistema aplicación.
operativo o el
hardware?
 17

4. ¿Es sencillo Si. Documentar los

perfeccionar el existente para
software en un soportar las
proceso evolutivo cambios de
viable? proceso.

5. ¿Es sencillo Si. Documentar y

extender el software crear un
hacia nuevas estándar para el
funcionalidades sin desarrollo de
tener que modificar nuevas
el código funcionalidades.
“existente”?

Portabilidad 1. ¿El software es Si. Crear un

portable a diferentes documento con
sistemas operativos y requerimientos
plataformas? mínimos para el
uso de la
aplicación.

2. ¿Es sencillo Si. Documentar y

“trasladar” el crear un manual
software de una de configuración
intranet a otra, o de del sistema.
un dominio/servidor
a otro sin mayores
problemas,
configurando tan
solo unos pocos
parámetros?

Disponibilidad / 1. ¿El sistema, se No. Tener un

Recuperabilidad “cae” muy a sistemas de
menudo? respaldo para
contingencias.
 18

2. ¿Es preciso Si 15 minutos o Informar el

inhabilitar por mucho menos usuario minino
tiempo cada vez que aproximadamente. con una semana
hay que hacer tareas de anterioridad
de mantenimiento? la fecha y hora
de la
actualización.

3. ¿Cuánto tiempo Depende del Optimizar la

demora el sistema en hardware y ancho carga de
“arrancar” hasta su de bando del complementos
estado funcional? usuario. para un arranque
más rápido.

Reusabilidad 1. ¿Es el código Si. Crear clases y

fuente del software, funciones para
reusable? tareas
específicas con
el objetivo que
se pueden
implementar y
reusar en el
desarrollo.

Robustez 1. ¿Reacciona bien el No.

sistema ante
situaciones o casos
no previstos o no
contemplados en los
requerimientos?
 19

Seguridad 1. ¿Están protegidos No. Definir un plan

los datos que de mejora para
manipulan el seguridad de los
sistema, ya sea en su datos.
tiempo de proceso y
tránsito, como así
también en su estado
de almacenamiento?

2. ¿Es muy Si. Definir

vulnerable al ataque estándares de
de hackers? seguridad contra
ataques.

3. ¿Tiene No. Crear copias de

contemplado un seguridad en
sistema de datos se es
recuperación, ante necesario a
pérdida de datos? diario para
restablecer la
información en
caso de ser
necesario.

Criterios de validación estado de avance.

KPA APLICACIÓN

Software - Requisitos administración. · Se documentan los requerimientos

utilizando una plantilla específica para el
tipo de proyecto.

· Cuando se cambia el requerimiento se

realiza la documentación en un archivo.
 20

compartido que permite hacer seguimiento.

Software – Calidad y Garantía. · Cada proyecto tiene la asignación de un

tester (QA).

· Semanalmente se planifica una revisión

del proyecto.

· Se ejecuta la revisión y se crean

seguimientos a los casos identificados.

Software - Planificación del Proyecto. · Se escribe el proyecto según

recomendaciones IEEE.

· Los cronogramas se crean con

asignación de recursos.

· Los entregables sin priorizan según la

importancia de cara el proyecto.

· Se genera un informe de riesgos.

Software - seguimiento y vigilancia del · Se realizan y presentan informes de

proyecto avance a lo largo del proyecto

· Se evalúa el avance realizado

· Se realiza un seguimiento del tiempo de

desarrollo vs el tiempo estimado

· Se realiza un seguimiento de los riesgos

identificados en fases iniciales y se analiza
si existen nuevos riesgos

· Se hace un reunión semanal de

seguimiento
 21

Software – Configuración y administración · Se usan herramientas como GIT y SVN

para el control de versiones en código y
documentación

· Se siguen modelos de desarrollo y se

crean convenciones para nombres

Implantación plan mínimo de pruebas.

La mayoría de los clientes prefieren no pagar por un sistema de pruebas bastante elaborado, para
estos casos hemos pensado en un estándar mínimo el cual asegura que el producto funcione con
los parámetros definidos en la fase de recopilación de requerimientos.

Apenas se termina el desarrollo se procede la realización de pruebas, se gestiona un documento

diseñado en Excel el cual analiza un caso de uso. Si se encuentra un error en su gestión, el error
se registra como evidencia, el objetivo es lograr la ejecución óptima del caso de uso planteado.
Estas pruebas son funcionales y son el requisito mínimo por el cual el cliente paga para entregar
el desarrollo ha entorno de pruebas. El documento se entrega a petición del cliente como
evidencia de las pruebas solicitadas.

Estrategias y modelo a seguir.

Teniendo en cuenta la información obtenida mediante entrevista de la empresa escogida como

modelo para el presente proyecto, el grupo Nro. 15 opto como modelo a seguir el ISO/IEC 15504
(SPICE) , porque sus elementos se amoldan a las necesidades, ya que abarcan todos los temas de
la implantación de software.

El objetivo como empresa es crear un estándar de desarrollo que permita el bajo acoplamiento,
facilidad, rapidez de mantenimiento y permitir la agilización de procesos, aunque tome su tiempo
la visión a largo plazo permitirá dar a los clientes un servicio con excelencia.

Actividades a mejorar.

· Actualización y creación de manuales para la aplicación y para los usuarios

· Reuniones del equipo de desarrollo para determinar el estado de trabajo

 22

· Capacitar el equipo de desarrollo en nuevas tecnologías

· Mejorar el ambiente organizacional para mejora del ambiente laboral

· Crear un plan de incentivos por cumplimiento para el área de desarrollo

· Definir roles y jerarquía laboral

 23

Segunda Entrega

Documentación actividades, proceso y procedimientos.

Identificación.

Una vez finalizado el caso de uso y desarrollado se procede a llenar un deck de pruebas, este es
un documento realizado en excel.

como se ve en la imagen se divide en casos de pruebas, cada caso puede ser un caso de uso el
propósito es documentar el resultado de la prueba, si este es fallido se documenta. con esto se
demuestra al cliente que el trabajo está realizado.

En la parte inferior se pueden ver las pestañas que se ven en la parte inferior de la imagen.
 24

En cada una de estas pestañas habrá pantallazos de los casos estudiados.

como se ve en la pantalla superior se agregan las evidencias de esta forma se proporciona un

documento simple que demuestra las pruebas realizadas.

Referencias.

Se tendrá como referencia directa al personal de la empresa, además se contará con el manual de
usuario de la aplicación(teniendo en cuenta que este no se encuentra actualizado) y así mismo se
contará con MER desactualizado de la base de datos de la aplicación.
 25

Introducción.

Aspectos importantes y críticos del producto y proyecto.

1. Hay involucramiento por parte de los usuarios.

2. Se cuenta con el apoyo por parte de la alta gerencia.
3. Hay sentido de pertenencia al proyecto.
4. Hay un equipo comprometido y disciplinado.
5. Hay buena comunicación.
6. El proyecto tiene claramente definida su misión.
7. El proyecto logra el propósito del negocio.
8. Se encuentra disponible la tecnología y los conocimientos adecuados.

Proceso de pruebas.

Objetivo.

Identificar las falencias existentes con el fin de mejorar y optimizar un software con
calidad y eficiencia, para minimizar fallas e inconvenientes al momento de realizar
pruebas de implementación.

Cronograma.

Para la presentación del plan de trabajo, se emplearán Diagramas de GANTT. Su objetivo

es mostrar gráficamente las tareas y avances, durante todo el proceso desde el inicio hasta
su culminación, mostrando la forma como las distintas tareas están encadenadas entre sí.

Figura 1. Cronograma de actividades.

 26

Presupuesto.

El presupuesto necesario se limita más que nada a personal de desarrollo, se cuenta con
unos cuantos para el desarrollo de pruebas por lo que los desarrolladores deben garantizar
las pruebas unitarias con el documento antes mencionado

1. Cuantificación de necesidades y fechas de incorporación de recursos.

2. Obtener un patrón que marque los alcances del proyecto. Teniendo en cuenta las
siguientes operaciones:

- Establecer el esfuerzo en semanas(con decimales).

- Deducir la parte correspondiente a diseño funcional, ya que es una fase con un
tipo de actividades diferentes al resto.
- Establecer la duración en semanas (con decimales). Normalmente este dato se
conocerá por el compromiso adquirido.
- Deducir la duración correspondiente al diseño funcional.
- Considerar que todo proyecto tiene tres situaciones claramentes
diferenciadas(Arranque, Pleno Rendimiento, Finalización).
- Distribución de recursos.

3. Considerar la capacidad, los conocimientos y la experiencia de cada recurso.

4. Considerar la complejidad, el tamaño y los requerimientos técnicos de cada tarea.

5. Asignar tareas sencilla a recursos con poca experiencia; para que los recursos con poca
experiencia no hagan perder el tiempo preguntando continuamente al resto del Equipo
con más experiencia.

Entre otros.

Actividades.

Organizadas por orden jerárquico, son las siguientes:

1. Capacitación para mejorar ambiente organizacional para que los desarrolladores puedan llenar
el documento correctamente.

2. Cada QA estará encargado de un grupo de no más de 6 desarrolladores este supervisará cada

uno de los documentos y validará que se encuentren incidencias ya que este es el propósito del
documento.
 27

3. Creación del plan de incentivo por cumplimiento para el área de desarrollo, atacando el tema
de encontrar incidencias en cada desarrollo presentado y documentando.

Definiciones del proyecto

Personal.

Responsabilidades, roles y formatos.

PLAN DE COMUNICACIÓN

Se usarán aplicaciones para la gestión de tareas como Trello, la comunicación se manejara por
grupos de desarrollo, estos se comunicaran a través de la herramienta Slack.

Roles Involucrados en el Proceso de Pruebas

En el modelo de comunicación participan los siguientes roles:

● Coordinador del Proyecto

● Líder del Proyecto del Cliente
● Analista de Calidad
● Desarrollo

Casos de Interacción de los Roles

A continuación, se nombran las actividades y artefactos en las cuales interactúan los diferentes
roles:

Rol Actividades
 28

Project ● Implementar cambios que resulten en mejoras en la eficiencia y

Director competitividad del proyecto.
● Comunicación efectiva con el equipo
● Disposición y decisión en actividades que requieren de su
autoridad, tanto para el equipo PROVEEDOR, como para la
CLIENTE
● Actividades relacionadas con el contrato CLIENTE
● Supervisión de tareas
● Resolutor de temas que le sean escalados
● Contextualización y alineación de la metodología
● Convoca y asiste a reuniones
● Análisis y evaluación de informes
● Análisis de métricas
● Gestión transversal

Analista ● Propone cambios que resulten en mejoras en la eficiencia y

líder de competitividad del proyecto.
Calidad ● Gestión transversal
● Escala los temas a quien tiene la autoridad para tomar decisiones.
● Convoca y asiste a reuniones
● Socializa las directrices emitidas por el Project manager o el cliente
● Rendición de informes solicitados por parte del Project manager o
el cliente
● Contextualización de aplicaciones
● Estrategia de pruebas
● Informes de avance
● Casos de prueba
● Cierre del proyecto
 29

Analista de ● Propone cambios que resulten en mejoras en la eficiencia y

Calidad de competitividad del proyecto.
Software ● Gestión transversal
● Escala los temas a quien tiene la autoridad para tomar decisiones.
● Contextualización de aplicaciones
● Estrategia de pruebas
● Informes de avance
● Casos de prueba
● Cierre del proyecto

Desarrollo ● Contextualización de Aplicaciones

● Gestión de Incidencias (Solución de Incidencias)
● Realización de documento con pruebas unitarias.

CODIFICACIÓN DE VERSIONES DE COMPONENTES

Actualmente el versionamiento se realiza con la herramienta GitLap, lo que se hará en cada

entrega es versionar cada entregable con su fecha y con su respectivo deck de pruebas, tambien
vendra su documento con las instrucciones para que el cliente pueda realizar la instalación de los
desarrollos en su ambiente de pruebas.
 30

Cada desarrollador y rol llenará los entregables al proyecto que haya sido asignado.

CONCLUSIONES

● Por la falta de recursos se delega trabajo a los desarrolladores para que hagan
parte de la documentación de pruebas para lograr un alto desempeño y no afectar
su productividad es menester una excelente capacitación y una herramienta ágil.

● El mayor problema que se ha presentado en la empresa es el tiempo de desarrollo

ya que cualquier ajuste tiene un tiempo corto de respuesta es por esto que se busca
una solución ágil que aplique un plan que asegure la calidad del producto.
 31

● Es indispensable que se realice la actualización de los manuales tanto de usuario

final como la reorganización de la documentación de códigos fuentes con el fin de
garantizar su comprensión y la reutilización en futuras actualizaciones.

REFERENCIAS

● https://americalatina.pmi.org/latam/pmbokguideandstandards.aspx
● https://ipmoguide.com/comparativa-pmbok-cmmi-cobit-itil/
● https://www.youtube.com/watch?v=vysuoOKkNZo
● https://www.youtube.com/watch?v=hQWpuMoilZ8
● http://seispice.blogspot.com/2012/05/spiceiso-iec-15504-norma-spiceiso-iec.html
● https://www.normas-iso.com/iso-iec-15504-spice/
● https://www.ddw.com.ar/blog/113-tecnologia-software-aplicaciones-y-servicios-web/423
-test-de-calidad-de-aplicaciones-web
● http://ri.uaemex.mx/bitstream/handle/20.500.11799/41161/11+-+Factores+cr%C3%ADti
cos+de+%C3%A9xito+en+los+proyectos+de+software.pdf?sequence=1
● http://bibing.us.es/proyectos/abreproy/30060/fichero/PROYECTO.pdf
● https://www.microtech.es/blog/proceso-de-pruebas-de-calidad-de-software