PRUEBAS Y CALIDAD DE SOFTWARE

PRESENTADO POR:

Luis Fernando Rodríguez Hernández. (1911983357)

Cristian Camilo Rodríguez Arevalo (1911028768)
Carlos Orlando Herrera Ardila (1611021135)
Osso Cortés Andrés Felipe (1721980914)
Rodríguez Espitia Oscar Yeisson (1821021513)
Octavio David Robles Pacheco (100209703)
Alexander Mejía Guzmán (1521022510)
Germán David Liévano Suárez (100090254)
Ricardo Adolfo Sáenz (1611026251)

TUTORA:

Alexandra María Silva Monsalve

Politécnico Grancolombiano
Ingeniería de Software
 2021

Tabla de contenido

Introducción ……………………………………………………………………………. 3

Objetivo General ……………………………………………………………………….. 4

Objetivos Específicos ………………………………………………………………...… 4

Justificación ……………………………………………………………………………. 4

Desarrollo

Comparativa de los Diversos Modelos de Calidad del Software ………………………. 5

Entrevista para el Proceso de Mejora de la Empresa …………………………………... 11

Modelos de la calidad del software …………………………………………………….. 13

Modelos de calidad del producto …………………………………………………….... 19

Actividades y Procesos en el ciclo de desarrollo……………………………………..… 22

Conclusiones …………………………………………………………………………… 29

Lista de Referencias ……………………………………………………………………. 30

2
Introducción

En esta entrega abordaremos aquellos modelos de calidad que se pueden aplicar al desarrollo
de producto de software para identificar sus características, ventajas y desventajas.

Un producto es exitoso si se definen las características de calidad adecuadas que contribuyan

a satisfacer las necesidades y gustos del cliente. Para poder dar cumplimiento a cada uno de los
requisitos de calidad, están establecidos unos modelos que a través de ciertos criterios
proporcionan herramientas y estrategias que facilitan el cumplimiento de los requerimientos de
calidad.

Un procedimiento adecuado que es muy importante tener en cuenta en la actualidad del

desarrollo de productos de software de alta calidad ya que estos conllevan al éxito o bien sea
al fracaso.

3
Objetivo General

Identificar los distintos modelos de calidad que se pueden llegar a aplicar en un proyecto. Esto
se hace con el fin de lograr determinar pros y contras de cada modelo tal y como es el esfuerzo,
tiempo, costo y beneficios a la hora de ejecutar un proyecto de software.

Objetivos Específicos

● Establecer la manera de lograr una mejora en los procesos de la empresa

● Definir adecuadamente los modelos necesarios para lograr la calidad en los productos
de software que la empresa desarrolla
● Fijar las actividades, procesos y procedimientos que harán parte del ciclo de vida de la
calidad del software que es requerido para la empresa

Justificación

Con el desarrollo de la primera entrega lo que se pretende es realizar la recolección de

la información necesaria con el objetivo de llevar a cabo el análisis correspondiente y de esta
manera identificar los aspectos más relevantes que deben ser evaluados y mitigados para lograr
un desarrollo adecuado de cada uno de los procesos de calidad del software.

4
Desarrollo

1) Describa los elementos de los diversos modelos de calidad que se pueden aplicar al desarrollo de productos de software, que le permitan
realizar un comparativo entre ellos y determine los pro y contras de cada uno en esfuerzo, tiempo, costo y beneficios.

Tabla 1.
Comparativa Modelos de Calidad de Software

Modelo Características Ventajas Desventajas Factores Criterios

Mc Call Operatividad del Práctico y fácil de No existe una Usabilidad Operatividad
producto: entender y aplicar relación lineal entre
Características de los valores de las Integridad Entrenamiento
operación Focalizado en el producto métricas y las
final desde el punto de Corrección Comunicación
características
Revisión del producto: vista del usuario
Fiabilidad Control de
Habilidad para ser acceso
cambiado Focaliza medidas precisas
Eficiencia
de alto nivel
Auditoría de
Transición del Mantenibilidad acceso
producto:
Adaptabilidad al nuevo Facilidad de prueba Rastreabilidad
ambiente
Flexibilidad Consistencia

Reusabilidad Completitud

Interoperabilidad Tolerancia a

5
 fallos
Portabilidad
Almacenamiento

Ejecución
Mohem ó Conforman un espiral en Análisis de riesgo de Genera mucho tiempo Portabilidad Independencia
Espiral cada bucle o iteración forma explícita y clara en el desarrollo del
sistema Fiabilidad Completitud
Representa un conjunto Une elementos de los
de actividades restantes modelos Es costoso Eficiencia Exactitud

Las actividades no están Reduce riesgos del Requiere experiencia Ingeniería humana Consistencia
fijadas a ninguna proyecto en la identificación de
prioridad riesgos Comprensibilidad Eficiencia
Objetivos de Calidad
Se eligen en función del Funciona mejor en Modificabilidad Estructuración
análisis de riesgo Integra desarrollo con proyectos grandes
mantenimiento Legibilidad
Determinar objetivos Trabaja bajo un
Análisis de riesgo Tiene en cuenta Mejoras protocolo que debe
y requerimientos ser seguido para su
Desarrollar y probar buen funcionamiento
Planificación No es rígido ni estático
Mosca Estimar la calidad Se enfoca en el producto El proceso es Funcionalidad Cuenta con
sistemática dentro de y el proceso complicado si no algoritmo para
una organización existe una guía Usabilidad medir la calidad
desarrolladora de Es efectivo en análisis y sistémica:
software estimación de la calidad Fiabilidad
global sistémica Calidad del

6
 Características producto de
software
Dimensiones Calidad del
proceso de
Producto desarrollo

Métricas Integración de
los submodelos
de calidad del
producto y
calidad del
proceso

ISO/IEC Calidad interna Representa la calidad de Funcionalidad Adaptabilidad

9126 un producto de software
Calidad externa Usabilidad Seguridad
Valida el cumplimiento
Calidad en Uso del software respecto a Fiabilidad Exactitud
los requisitos de calidad
interna Mantenibilidad Análisis

Predice el nivel de calidad Eficiencia Madurez

de uso del producto:
Efectividad Portabilidad Satisfacción
Productividad
Seguridad Efectividad
Satisfacción
Productividad

7
 Mejora la calidad del
proceso, producto y uso.

Metodologías Rápida, específica, Dar soluciones durante el Se depende en gran La organización y Producto
ágiles dinámica proceso de trabajo, sin parte del líder del su contexto. potencialmente
tener que esperar al final equipo entregable y
Hace más fácil la División efectiva usable
comunicación entre El cliente puede aportar Falta de del trabajo en
equipos para que la producción y documentación, las iteraciones. Establecer un
Considera al cliente el consumo mejoren soluciones se criterio de
como parte del equipo proponen para Roles bien calidad
de producción La entrega del producto o llevarse a cabo. establecidos.
servicio es más rápida.
Las entregas son Pueden surgir Transparencia en la
tempranas y continuas Se eliminan tareas soluciones erróneas información.
innecesarias. que pueden llevar a
Su estructura es consecuencias graves
cambiable Al crear prioridades se en pleno trabajo de
optimizan los recursos y producción.
Conversación cara a los resultados.
cara
Flexibilidad laboral
Negocio y desarrollo
trabajan de la mano

Las acciones son

ajustables y simples

8
Modelo Modelo de Madurez de Proceso de gestión del Falta de adecuación al Mejora continua ERS,
CMMI Capacidades Integrado proyecto, desarrollo y enfoque de servicio del proceso Especificación
mantenimiento del que está de Requisitos de
Este establece un software está definido e experimentando el Control software
conjunto de prácticas o implementado. área TI. cuantitativo del
procesos claves proceso Definir como
agrupado en áreas Clave La estimación de costo de El proceso de cumplir los
de Proceso (KPA-Key evaluación es muy Procesos objetivos
los procesos se
Process Àrea) costoso en tiempo y caracterizados por
retroalimenta y se nutren
esfuerzo. la organización y Test sobre el
con las experiencias de
proactivo código de
los proyectos
La complejidad de la desarrollo
implementados. Gestión Básica del
evaluación continua
puede atentar contra Proyecto Entrega al
Mejora en el
la definición de cliente
cumplimiento de los
plazos establecidos y objetivos concretos
Adaptaciones
compromisos asumidos. de madurez.
finales y cierre
del proyecto
Aumento en la
satisfacción del Cliente,
por el soporte dado al
proyecto

Los roles y
responsabilidades de
grupos y miembros del
proyecto están claramente
definidos.

9
 Se implementa la
reusabilidad en un sentido
amplio, pues alcanza no
sólo al código sino a toda
pieza involucrada en un
proyecto de software

10
2) Lleve a cabo las entrevistas necesarias en la empresa para determinar: debilidades, fortalezas, oportunidades y amenazas. En general,
conocer el modo de lograr una mejora en los procesos de la empresa.

Tabla 2.

Matriz DOFA

Proceso Calidad de Software Fortalezas Debilidades

1. Altos salarios para los programadores. 1. Estrategias de estimación (Plazos de

2. Planes de capacitación interna construcción impuestos por negocio, sin
tener consideraciones técnicas en las
estimaciones)
2. Soluciones no escalables

Oportunidades FO DO

1. Contratación de personal calificado para
las capas intermedias entre negocio y
desarrollo.
2. Implementación de metodologías ágiles
de desarrollo.
1. Mantener los salarios competitivos y
beneficios como capacitación interna
para atraer el personal idóneo a la
compañía
2. Capacitar al personal en el uso de
metodologías ágiles
1. Implementar un proceso de gestión de
proyectos para articular mejor el
proceso de desarrollo con los requisitos
financieros, técnicos y humanos
2. Capacitar al personal en el desarrollo
de soluciones escalables con el tiempo

Amenazas FA DA

11
1. Renuncias de los trabajadores, por
mal manejo de la presión y baja
calidad en las implementaciones.
2. Despidos por parte de negocio, por
incumplimento de los plazos
impuestos
1. Establecer una metodología de
desarrollo para el manejo de los
tiempos en los sprints de desarrollo
2. Capacitar a los líderes en gestión de
proyectos para el manejo de tiempos y
actividades de los desarrolladores
1. En el proceso de diseño de los
proyectos involucrar más al personal
técnico, para así tener una mejor
estimación del tiempo.
12
 3) Establezca varios criterios que le permitan validar el estado de avance de su
empresa (puede tomar las KPA del modelo CMM y otros adicionales que
considere afecten su decisión) frente a cada modelo y los elementos que describió.

Modelos de Calidad del Software

CMM

Características:

Este modelo establece un conjunto de prácticas o procesos clave agrupados en

Áreas Clave de Proceso (KPA -Key Process Area).

● Definidas en un procedimiento documentado.

● Provistas (la organización) de los medios y formación necesarios.
● Ejecutadas de un modo sistemático, universal y uniforme (institucionalizadas).
● Medidas
● Verificadas

Centrado en:

A su vez estas Áreas de Proceso se agrupan en cinco ”niveles de madurez”, de

modo que una organización que tenga institucionalizadas todas las prácticas incluidas
en un nivel y sus inferiores, se considera que ha alcanzado ese nivel de madurez. Los
niveles son:

1. Inicial: Las organizaciones en este nivel no disponen de un ambiente estable para el

desarrollo y mantenimiento de software. Aunque se utilicen técnicas correctas de
ingeniería, los esfuerzos se ven minados por falta de planificación. El éxito de los
proyectos se basa la mayoría de las veces en el esfuerzo personal, aunque a menudo se
producen fracasos y casi siempre retrasos y sobrecostes. El resultado de los proyectos
es impredecible.

2. Repetible: En este nivel las organizaciones disponen de unas prácticas

institucionalizadas de gestión de proyectos, existen unas métricas básicas y un
razonable seguimiento de la calidad. La relación con subcontratistas y clientes está
gestionada sistemáticamente.

3. Definido: Además de una buena gestión de proyectos, a este nivel las organizaciones
disponen de correctos procedimientos de coordinación entre grupos, formación del
personal, técnicas de ingeniería más detallada y un nivel más avanzado de métricas en
los procesos. Se implementan técnicas de revisión por pares (peer reviews).

13
 4. Gestionado: Se caracteriza porque las organizaciones disponen de un conjunto de
métricas significativas de calidad y productividad, que se usan de modo sistemático
para la toma de decisiones y la gestión de riesgos. El software resultante es de alta
calidad.

5. Optimizado: La organización completa está volcada en la mejora continua de los

procesos.

MC CALL

Características:

Describe la calidad de un concepto elaborado mediante relaciones jerárquicas. se

focaliza en el producto final identificando atributos claves desde el punto de vista del
usuario

Antecedentes:

El modelo de McCall fue el primero en ser presentado en 1997 y se originó motivado

por Air Forcé Y Dod.

Centrado en:

● Revisión del producto

● Transición del producto
● Operación del producto

Ventajas:

Mantenibilidad, Flexibilidad Testabilidad Portabilidad Reusabilidad Interoperabilidad.

Desventajas:

No siempre existe una relación perfectamente lineal entre valores de las métricas y las
características.

BOHEM

Características:
Es un modelo incremental, dividido en regiones de tareas y estas a su vez en conjuntos
de tareas, las cuales se ajustan a la cantidad de iteraciones que el equipo defina.

Antecedentes:

14
Es el Segundo modelo de Calidad más usado este se presentado por Barry Bohem en
1978

Centrado en:

Se focaliza en medidas más precisas de alto nivel

Ventajas:

● Utilidad perseverante en cuanto a la Mantenibilidad.

● Utilidad general.

Desventajas:

Genera mucho tiempo en el desarrollo del sistema Costoso Requiere experiencia en la

identificación de riesgos

CMMI

Características:

Constituye una forma de medir el grado de madurez de las organizaciones.

Antecedentes:

Se dio en 1987 como Capability Maturity Model en proyecto Software Engineering

Institute.

Centrado en:

Administración de riesgos e indica la capacidad de una organización para

administrarlo.

Ventajas:

● Reducción de defectos
● Fiabilidad
● Guía paso a paso a través de los niveles de madurez.

Desventajas:

● Alto esfuerzo de implementación que exige

● requiere mayor inversión para ser implementado

15
EFQM

Características:

Busca determinar fortalezas y oportunidades de mejora de las organizaciones.

Antecedentes:

Fue enunciado por la EFQM en 1991, bajo el patrocinio de la comisión europea.

Centrado en:

Ayudar a las organizaciones a conocerse más a sí mismas y mejorar su

funcionalidad .

Ventajas:

● Aumenta rentabilidad.
● Favorece la competitividad.
● Servir el estímulo a la mejora continua.
● Emplea un lenguaje común de excelencia.

Desventajas:

● Rechazo inicial por el nivel de exigencia y mejora continua.

● Es más conocido en Europa.

FURPS

Características:

Incluye además de los factores de calidad y atributos, restricciones de diseño y

requerimientos de implementación, físicos y de interfaz.

Antecedentes:
Fue desarrollado por HP (Helwett – Packcard) en 1987 y se publicó por primera vez
por Grady y Caswell.

Centrado en:

Requerimientos Funcionales y No funcionales URPS.

16
Ventajas:

● Tiene en cuenta las fallas del producto y el proceso para su mayor corrección.
● Criterios claros para su fácil utilización.

Desventajas:

● Necesita de muchas métricas lo que implica mayor esfuerzo en tiempo y dinero.

● No tiene en cuenta la portabilidad de los productos Software.

DEMING

Características:

Mantenimiento y mejora de calidad operativa del producto y establecimiento del

sistema para mejorar la calidad.

Antecedentes:

Ha estado presente en Japón desde 1951.

Centrado en:

Comprobar que, mediante la implantación del control de calidad de toda la compañía,

se hayan obtenido buenos resultados.

Ventajas:

● Evaluación Efectividad Consistencia Continuidad Minuciosidad.

Desventajas:

● Toma mucho tiempo y esfuerzo desarrollarlo.

SPICE/ISO/ IEC 15504

Características:

Establece un marco y requisito para cualquier proceso y proporciona guías para la

definición de competencias de un evaluador de procesos.

Antecedentes:

17
Recibió el nombre de SPICE en 1998, tras las primeras evaluaciones pasó a la fase de
ISO/IEC TR 15504 y actualmente se han presentado nuevas versiones para fortalecer
este estándar.

Centrado en:

Contempla las partes normativas, donde se definen los requisitos mínimos para realizar
una mejora de procesos de desarrollo y medir la madurez de la empresa.

Ventajas:

● Dimensiones independientes para los procesos y la capacidad.

● Modelo más consensuado.
● Coherencia con ISO 9001, ISO 20000 E ISO 27000.

Desventajas:

● Poco reconocimiento en el mercado Norte Americano.

● No contiene una estrategia de mejora del proceso.

MOSCA

Características:

Estimar la calidad sistemática dentro de una organización desarrolladora de software.

Centrado en:

Soporta la administración de calidad software en sus 3 actividades de aseguramiento,

planeación y control de la calidad.

Ventajas:

● Se enfoca tanto al producto como al proceso.

● Constituye una herramienta efectiva de análisis y estimación de la calidad.

Desventajas:

● Proceso complicado si no cuenta con una guía adecuada de la aplicación.

18
 4) Indique los dos modelos que considere más adecuados para lograr la
calidad en los productos de software que su empresa desarrolla ya sean
internos o externos.

Modelos de Calidad del Producto

“Un modelo de calidad para la evaluación de un producto de software define en su totalidad

los atributos de calidad, organizados en niveles jerárquicos, en el nivel más alto se definen sus
características y en el más bajo los atributos de calidad del software.” (Caponi, De Vera, Ibarra
y Fojo, 2014, p. 5).

En la historia autores como McCall, Boehm y Grady, etc. Han definido factores y
características cuantificables para garantizar la calidad del software, como respuesta a estos
autores los organismos de estandarización internacional han publicado las normas de producto
software como es el modelo es el modelo ISO/IEC 9126 y el modelo ISO/IEC 14598 (Plaza,
Medrano, Posa, 2010).

La norma ISO/IEC 9126 define un modelo de calidad de propósito general, que describe un
conjunto de características de calidad y brinda ejemplos de métricas, mientras que la norma
ISO/IEC 14598 muestra una descripción general de los procesos en la evaluación de productos
de software, así como también guías y requerimientos para su evaluación, por tal razón se
recomienda de su uso en conjunto. (Caponi, De Vera, Ibarra y Fojo, 2014).

ISO/IEC 9126

La norma ISO/IEC 9126 promueve un entorno que permite la evaluación de la calidad del
software, definiendo la calidad del software como un conjunto de aspectos con características
y subcaracterísticas importantes según el propósito de la evaluación del software, La calidad
del software según el modelo de calidad del estándar ISO/IEC 9126 puede evaluarse con las
características y subcaracterísticas del software, midiendo los atributos de calidad internos con
medidas estáticas es decir cuando el software no está en ejecución, calidad externa midiendo
atributos de calidad externos a través de medidas del código cuando se ejecuta o midiendo los
atributos de calidad en uso sobre el software, es decir cuando se ejecuta en el ambiente final y
trabaja en condiciones reales (Sánchez, Sicilia, Rodríguez, 2012).

Algunos conceptos que se introdujeron en la norma en 1994, dividieron los conceptos

de la calidad interna y externa en 4 partes:

1. ISO 9126-1. Modelo de calidad.

2. ISO 9126-2. Métricas externas.

3. ISO 9126-3. Métricas internas

4. ISO 9126-4. Calidad en las métricas de uso.

De esta forma se encuentra estructurada la norma ISO/IEC 9126, de acuerdo con los

19
requerimientos o requisitos iniciales de un producto, se deben elegir adecuadamente las
características utilizadas en cuanto a la evaluación de la calidad y así poder pasar a la
evaluación del producto final.

ISO/IEC 14598

La evaluación de un producto de software es importante para determinar el grado de calidad

que tiene el producto final de acuerdo a sus características, con el objetivo de cubrir en su
totalidad las expectativas del cliente, por tal motivo el software debe ser diseñado de acuerdo
a los requisitos funcionales y de rendimiento establecidos, estándares de desarrollo
debidamente documentados y elaborados profesionalmente. (Caponi, De Vera, Ibarra y Fojo,
2014). Para que se cumpla se requiere implantar un modelo de evaluación del producto de
software.

La norma ISO/IEC 14598 brinda un marco de trabajo para evaluar la calidad de los tipos de
productos de software, indicando los requisitos que serán medidos y analizados en este proceso.
Esta norma específicamente otorga métodos para medir y evaluar la calidad del producto
software que pueden ser utilizados por las personas que van a adquirir el software, por los
desarrolladores o los que van a evaluar el producto para obtener una certificación. Los
resultados de la evaluación sirven como base para identificar el nivel de conformidad con los
requisitos que el usuario solicitó y realizar mejoras si es necesario (Caponi, De Vera, Ibarra y
Fojo, 2014).

La norma ISO/IEC 14598 puede utilizarse conjuntamente con la norma ISO/IEC 9126, ya que
el primer paso en la evaluación es seleccionar las características de calidad importantes,
utilizando un modelo de calidad y precisamente la norma ISO/IEC 9126 describe un modelo
de calidad de esa forma. En la figura 1, se muestra la relación entre las normas ISO/IEC 9126
e ISO/IEC 14598. El nivel superior corresponde a los procesos que realizan los modelos
ISO/IEC 9126 e ISO/IEC 14598, el nivel inferior son las actividades que se desglosan de cada
proceso, indicado por la norma que se encarga de esa actividad.

20
 Figura 1. Relación entre las normas ISO/IEC 9126 e ISO 14598 (Piattini,et al, 2012, p. 98)

La norma ISO/IEC 14598 contempla los siguientes seis estándares:

1. ISO/IEC 14598-1. Descripción general.

2. ISO/IEC 14598-2. Planificación y gerenciamiento.

3. ISO/IEC 14598-3. Proceso para desarrolladores.

4. ISO/IEC 14598-4. Proceso para compradores.

5. ISO/IEC 14598-5. Proceso para evaluadores

6. ISO/IEC 14598-6. Documentación de módulos de evaluación del software.

La norma ISO/IEC 14598 implementa estándares que garantizan una efectiva evaluación al
software mitigando errores que puedan presentarse en su ejecución, cumpliendo con las
expectativas del cliente, también es importante aplicar normas a los procesos del desarrollo de
software, con el fin de poder evaluar dichos procesos y obtener un buen producto.

5) Establezca la lista de actividades, procesos y procedimientos a lo largo

del ciclo de vida del desarrollo de productos de software que requieren

21
 de definición en su empresa para permitir la implantación de un
proceso de pruebas que aumente la calidad y permita que un plan de
pruebas fluya. Hasta ahora lo que se ha hecho es un proceso de análisis
de las condiciones actuales y la detección de los aspectos a atacar de
manera prioritaria. gráficas como el “Rincón del Vago”, “Wikipedia”,
o similares

Ciclo de vida del software

Para la puesta en marcha de un plan de pruebas y calidad de software es necesario establecer

el ciclo de vida que se va usar en dicha actividad, para ello se ha propuesto hacer uso del modelo
incremental el cual permite realizar entregas acordes se va desarrollando el producto.

Actores involucrados

Para que un proceso de pruebas y calidad sea exitoso es necesario que mínimo estén
involucrados el stakeholder quien es la persona que tiene conocimiento del producto que se va
desarrollar en este caso el gerente de la empresa o un product owner asignado, por otra parte,
del equipo de desarrollo es necesario tener presencia del líder de QA, un documentador y un
líder de desarrollo.

Lista de actividades

Como sistema base para dicha lista de actividades vamos a tener en cuenta un sistema POS de
ventas e inventario el cual establece los siguientes objetivos:

Requerimientos del sistema

- El sistema debe tener módulos los cuales permiten administrar clientes, proveedores,
productos e inventario.
- El sistema debe contar con la opción de generación de informes de los módulos
administrados (clientes, proveedores, productos e inventarios)
- El sistema debe contar con la opción de carro de compras donde pueda validar los
productos solicitados, así como también el historial de los mismos.
- El sistema debe tener a disposición del cliente una pasarela de pagos la cual permita
realizar la compra de manera online desde la misma página.
- El sistema debe tener un sistema de inicio de sesión para brindar seguridad a la misma.
El login aplica para Clientes, proveedores, así como para administradores de la
plataforma.
Procesos

Procedimientos

22
 ETAPA DESARROLLO
Comunicación Se realiza contacto con el
cliente para la validación
de sus necesidades, se
acuerda mantener una
comunicación fluida en
los dos canales de un total
de 3 veces por semana.
Requerimientos del Una vez ya se ha tenido
sistema reunión con el cliente se
busca captar la mayor
cantidad de
requerimientos
planteados por el cliente.
Estudio de Factibilidad Al contar con todos los
requerimientos
planteados tanto por el
cliente como por el
proveedor del cliente, se
realiza un plan
estratégico para evaluar
qué viabilidad tiene el
proyecto
OBJETIVO
Se busca captar las
necesidades planteadas
por el cliente
(Administrador), así
como también mostrar los
avances que se tienen del
proyecto.
Captar los requerimientos
manifestados por los
actores partícipes del
desarrollo del lado del
Administrador, se debe
tener en cuenta las
necesidades tanto para el
usuario como para los
proveedores puesto que
ambos tendrán
interacción con el sistema
en desarrollo además del
cliente final
Tomando los
requerimientos del
Administrador y
proveedor se pone en
marcha las pruebas de
viabilidad con las cuales
se busca evidenciar si es
posible cubrir la totalidad
de los requerimientos, de
igual manera se debe
validar si conforme a
dichas necesidades y el
nivel financiero es
rentable la generación del
proyecto.
23
Análisis del sistema Basado en los puntos Tomar la decisión más
anteriores se procede con acertada del modelo de
la elección del más software con el cual
adecuado modelo de generar el desarrollo.
software para la Tener en cuenta que como
realización del sistema. el proyecto cuenta con
Se debe tenerse en cuenta requerimientos tanto del
las limitaciones a las que cliente como del
se tenga cabida dentro de proveedor se crean
los requerimientos. algunas limitantes que
deben ser contempladas
durante el desarrollo del
sistema POS de ventas e
inventario

Diseño del Software Dentro de este Plasmar el posible diseño

procedimiento en base a para el sistema elaborado
los aportes realizados teniendo en cuenta la
anteriormente se procede facilidad de uso que
con la creación de los faciliten el entendimiento
diseños tanto lógicos y manejo por parte del
como físicos, Diagramas cliente final (cliente y
lógicos, diagramas de proveedor del cliente)
flujos

Códigos Después de tener una Es momento de realizar la

base realizada en el implementación del
pseudocódigo se procede código y se debe tener en
con la implementación cuenta el lenguaje más
del código el cual inicia adecuado para el
con la elección del programa con esto se
lenguaje de programación minimizará la cantidad de
más adecuado errores creando así un
programa mucho más
eficiente.

24
Pruebas Teniendo en cuenta que Se procede con la
aun cuando se han implementación de un
seguido los pasos plan de pruebas que
planteados anteriormente permita solventar
para disminuir la posible cualquier error percibido
aparición de error dentro tanto en la plataforma
del proyecto, ningún como la parte lógica del
software esta libre de proyecto lo que pueda
tener error, por tal razón desencadenar fallas.
se deben realizar pruebas
para encontrar posibles
fallas

Integración Conexión del proyecto Garantizar la conexión

con las diferentes exitosa del programa con
bibliotecas o Bases de las bases de datos
datos necesarias para su necesarias teniendo en
correcto funcionamiento cuenta que es en ella
donde se van a
administrar los datos así
como productos, todo el
tema de inventarios para
el proveedor los cuales
van a poder ser
consultados y adquiridos
por el cliente final

Implementación Se procede con la Se debe evaluar temas de

instalación del producto adaptabilidad del sistema
en las máquinas del así como de portabilidad
administrador o el garantizando que los
alojamiento en el host actores involucrados
presentando (Administradores,
proveedores y clientes)
cuenten con el acceso
correcto al sistema

25
 Mantenimiento y Se valida el correcto Para garantizar el
funcionamiento funcionamiento correcto funcionamiento
entregando la mayor y uso del sistema se
eficiencia posible realiza la entrega del
manual al Administrador,
de igual manera si es
necesario se puede
proceder con la
capacitación de
administradores y
proveedores del Sistema
POS de ventas e
inventario

Disposición Para evitar obsolescencia Dar el ciclo de vida al

del programa En el programa para encontrar
tiempo y su correcta las posibles
eliminación actualizaciones que
requiera con el pasar de
un determinado tiempo,
actividades de
disposición y terminación
del sistema

Objetivo del proceso o procedimiento

Para el software POS de ventas e inventario se establece un plan de pruebas al software que
estará involucrados en cada una de las etapas del desarrollo del software. Dicho plan abarca
análisis de requerimientos, definición y aceptación de casos de pruebas, ejecución y aceptación
de casos de pruebas, proceso de mejora continua, capacitación e identificación de riesgos y
fortalezas

Alcance del proceso o procedimiento

Para dicho alcance se resalta realizar pruebas de verificación sobre las funcionalidades
realizadas por el equipo de desarrollo, para ello es necesario realizar una lista de chequeo con
las funcionalidad abarcadas en los requerimientos y casos de pruebas, al igual dichas pruebas
deben ser probadas y validadas en navegadores de internet y dispositivos móviles, cada prueba
de verificación debe ser realizada en cada una de las fases en el modelo a implementar; también
se debe respaldar y apoyar en cualquier falla que se presente durante estas pruebas.

Prerrequisito y entregables

26
Para poder realizar dichas pruebas es necesario contar con toda la documentación necesaria la
cual está en manos del equipo de QA (Tester y documentadores), este equipo deberá entregar
documentado las pruebas realizadas y junto a una lista de chequeo constatar las pruebas
realizadas y los fallos reportados, estos fallos van a ser categorizados según el peso y nivel de
importancia de cada uno quedando así:

Peso: siendo evaluado de 1 a 5 donde 1 son casos no primordiales y 5 son casos primordiales

Peso Descripción

1 Son defectos que no afectan un requisito

2 Son defectos que afectan a más de un requisito

3 Son defectos que afectan a más de un requisito primordial pero no es

bloqueante a la verificación de la funcionalidad

4 Son defectos que afectan a más de un requisito primordial, pero es bloqueante

a la verificación de la funcionalidad

5 Son defectos que no cumplen en ninguna medida con el requisito y por tanto
no es posible continuar con la verificación

El equipo de calidad va a poder categorizar los errores si existen durante la prueba que se
realiza en los diferentes acompañamientos de calidad, cabe resaltar que, si durante las pruebas
existe algún funcionamiento que no se estableció en el proceso de requerimientos, este se
tomará como adicional y no se tendrá en cuenta durante el proceso de pruebas.

27
Conclusiones

Es de vital importancia la definición de los modelos necesarios para lograr la calidad en los
productos de software que la empresa desarrolla.

Es fundamental fijar las actividades, procesos y procedimientos que hacen parte del ciclo de
vida de la calidad del software para la empresa

Se identificaron los distintos modelos de calidad factibles de aplicar en el proyecto, logrando

determinar pros y contras de cada modelo tal y como es el esfuerzo, tiempo, costo y beneficios
a la hora de evaluar el impacto en el proyecto de software.

Se estableció una metodología para mejorar los procesos de la empresa

28
Lista de Referencias

Caponi, M., De Vera, D., Ibarra, J. L., y Fojo, S. (2014). Gestión de software, informe
sobre evaluación de productos. Uruguay: Universidad de la RepúblicaFacultad de Ingeniería.
[En línea] http://www.fing.edu.uy/inco/cursos/gestsoft/Presentaciones/Evaluacion%20de%20
Productos%20-%20G2/Evaluacion%20de%20Productos.pdf

Plaza García, I., Medrano Sánchez, C. T., y Posa Gómez, A. B. (2010). Calidad en
actividades de I+D+i Aplicación en el sector TIC. San Fernando de Henares, Madrid: RC
Libros

Sánchez, S., Sicilia, M. Á., y Rodríguez, D. (2012). Ingeniería del Software Un

enfoque desde la guía SWEBOK. Madrid: Alfaomega Grupo Editor, S.A de C.V.

PiattiniVelthuis, M. G., García Rubio, F. O., García Rodríguez de Guzmán, I., y Pino,
F. (2012). Calidad de sistemas de información. México, D.F.: Alfaomega Grupo Editor, S.A.
de C.V.

Bolger, A., & Giorgi, F. Trimmomatic: A Flexible Read Trimming Tool for Illumina
NGS Data. URL http://www. usadellab. org/cms/index. php.

Mauro Callejas-Cuervo ,Andrea Catherine Alarcón-Aldana: A Flexible Read Data.

URLhttp://www.scielo.org.co/pdf/entra/v13n1/1900-3803-entra-13-01-00236.pdf

https://www.slideshare.net/yessicagongora/comparativo-modelos-de-calidad

29