Está en la página 1de 36

Trabajo Colaborativo Modelos de calidad de software

Facultad de ingeniería, diseño e innovación, Politécnico Grancolombiano.

Pruebas y Calidad de Software

Tabla de contenido
1

1. Introducción 1

2. Objetivos 2

2.1. Objetivo general 2

2.2. Objetivos específicos 3

3. Modelos de calidad de software 4

4. Empresa seleccionada 14

4.1. Entrevista al ingeniero de software de la empresa 14

4.2. Respuestas a la entrevista 14

4.3. Dofa de la empresa 15

5. Modelo Seleccionado 17

5.1. Mejoramiento de la calidad de la empresa 19

6. Conclusiones 22

7. Referencias 23

8. Anexos 24
2

Listado de Tablas

Tabla 1. DOFA de la empresa 15

Tabla 2. Análisis para decisión de modelo 18


1

1. Introducción

Existe un escenario muy competitivo entre las empresas que desarrollan software, sus

productos demandan que tengan una mayor calidad y cumplan con las expectativas de los

usuarios, por lo cual producir un software de calidad conlleva a la utilización de métodos

más eficientes que aborden el mejoramiento continuo de los procesos, la optimización de

los recursos, detección de errores tempranamente y la disminución del costo del producto

software. En este trabajo se explican los diferentes modelos de calidad el cual cada uno

tiene su descripción, características, ventajas y desventajas, para brindar un espectro de

opciones que se tuvieron en cuenta para la elección del método a utilizar en una empresa

que fue seleccionada por los participantes de este trabajo, y que de acuerdo a la información

brindada por el ingeniero de software de la empresa, se escogió el método más efectivo

para mitigar la problemática y mejorar los procesos dentro de la empresa permitiéndole ser

más eficiente, óptima y para destacarse de sus productos de las demás empresas.
2

2. Objetivos

2.1. Objetivo general

A través del conocimiento de una empresa dedicada al desarrollo de software.

conocer los modelos de calidad de software aplicados por esta y las pruebas que se realizan

al producto en desarrollo.
3

2.2. Objetivos específicos

1. Conocer los modelos de calidad de software aplicados por la empresa.

2. Conocer el plan de aseguramiento de la calidad que aplica la empresa.

3. Determinar las fortalezas, debilidades y oportunidades que se observen de los

modelos y del ciclo de vida de las pruebas que realiza la empresa seleccionada.
4

3. Modelos de calidad de software

Descripción modelo CCM

El Modelo CCM se dio como la necesidad de un modelo a seguir para avanzar hacia

la madurez en los procesos consecuentes del desarrollo de software logrando establecer una

serie de buenas prácticas dirigidas hacia los KPA (Key Procces Area) que se llevan a cabo

durante todo el ciclo de desarrollo en la organización, estas buenas prácticas KPA se

agrupan en cinco áreas clave que son las definidas como de necesario cumplimiento y se

basan en documentación específica y se complementan con las provistas por la propia

organización, posteriormente deben ser ejecutadas, se deben documentar y obtener métricas

o medidas y posteriormente verificadas.

Madurez y KPA

Las KPA su aplicabilidad y cumplimiento son el camino a seguir para llegar a la

madurez la cual se define como el punto en el cual el proceso en conjunto de desarrollo es

completamente definido, administrado, medido, controlado y efectivo lo cual garantiza el

cumplimiento hacia el cliente y su satisfacción con la funcionalidad del producto brindado

y pueden clasificarse en tres tipos de proceso para cada nivel de madurez clasificándose en

tres tipos de proceso de gestión, organizacional e ingeniería y para cada área del proceso las

prácticas están organizadas en cinco características principales:

● Compromiso de realización.

● Capacidad de realización.
5

● Actividades realizadas.

● Mediciones y análisis.

● Verificación de implementación.

Los niveles de madurez de acuerdo a las KPA se pueden agrupar en cinco niveles clave

donde de acuerdo a la clasificación o nivel que se tiene se pueden identificar mejoras y

posibles rutas para avanzar hacia un mayor nivel de madurez.

Los niveles de madurez y sus generalidades son los siguientes:

● Inicial: Es el punto inicial del camino y aun que es el primer nivel se entiende que hay

bastantes oportunidades de mejora pero también se reconoce que ya hay un objetivo a

alcanzar y se están dando los primeros pasos aplicando tecnicas de ingenieria,

generalmente no se tiene un ambiente de desarrollo y mantenimiento estable y se

depende más del esfuerzo personal lo cual puede provocar frecuentemente retrasos y

sobrecostes en los proyectos.

● Repetible: Se solventan las dificultades del nivel anterior, se aplican prácticas ya

institucionalizadas y procedimientos a los grupos de trabajo de los cuales se pueden

obtener métricas básicas y hacer un seguimiento adecuado a la calidad en todos los

proyectos de forma recurrente.

● Definido: Es claro que ya se consolidaron las buenas prácticas y su aplicabilidad en el

ciclo del software lo cual lleva a una buena gestión de los proyectos se tienen

procedimientos claros y bien definidos entre los diferentes grupos de trabajo y las

métricas son más detalladas, en este nivel se hace necesario la implementación de

técnicas de revisión por pares.


6

● Gestionado: Para este punto las organizaciones que se encuentren en el aplican todos

los procesos y prácticas definidas obteniendo métricas de calidad y productividad bien

definidas, las cuales se emplean de forma recurrente y sistemática para tomar decisiones

y gestión de riesgos lo cual da como resultado software de calidad.

● Optimizado: La organización se encuentra encuentra completa, entiende y aplica todas

las buenas prácticas y su enfoque de lleno es la mejora continua y aplicación de todos

los procesos, adicional las métricas se usan de forma intensiva y continua y ahora se

avanza más allá de la calidad hacia la innovación.

Es importante entender y lograr definir el momento en el que se encuentra la

organización en su proceso de madurez haciendo una retrospectiva de la satisfacción o

insatisfacción en conjunto del cumplimiento o no de las metas que se definen en el día a día

de la organización.

BOEHM:

Es un modelo de evaluación de la calidad del software propuesto por Barry Boehm, en

donde se toma a la calidad como un atributo cualitativo y por métricas para hacer las

medidas respectivas a los procesos.

Características

Se basa en que el software debe hacer lo que el usuario quiere que haga. El modelo es

incremental dividido en fases y cada fase tiene un conjunto de tareas.


7

Ventajas

Une elementos de otros modelos Contiene un alto rango de características.

Desventajas

Es un modelo muy costoso. Genera mucho tiempo el análisis funciona mejor en

proyectos.

CMMI:

Es un modelo creado por el Software Engineering Institute de la Universidad Carnegie

Mellon en Estados Unidos, sus siglas en inglés nos dice “Capability Maturity Model

Integration” que en español es integración de los modelos de madurez de capacidades. Es

un modelo que busca mejorar y optimizar los procesos e igualmente la calidad para

promover eficiencia y la productividad.

Características

Es el modelo donde se establecen las mejores prácticas de la industria provee a las

organizaciones aquellos elementos esenciales para los procesos de negocio.

Ventajas

Aumento de productividad, Mejora en la calidad del producto, Los clientes están más

informados.
8

Desventajas

Es muy costoso en tiempo y esfuerzo, requiere mayor inversión para implementarlo.

FURPS:

Modelo propuesto por Robert Grady y la empresa Hewlett-Packard, sus siglas en inglés

son Functionality, Usability, Reliability, Performance, Supportability, que en español es

funcionalidad, usabilidad, confiabilidad, desempeño y Compatibilidad. Bajo estos factores

se hacen métricas de calidad para las distintas actividades del proceso de desarrollo del

software.

Características

Establece cinco características como factores de calidad que son: Funcionalidad,

Usabilidad, Confiabilidad, Prestación y soporte las cuales son las que le da su nombre.

Ventajas

Proporciona una vista común y comparable que se utiliza en cada proyecto Sus criterios

son de fácil compresión y esto facilita su implementación.

Desventajas

Genera mayor uso de tiempo y costos más elevados. Tiene poca flexibilidad ya que

sume que bastará siempre con un subconjunto de actores Gran cantidad de métricas que

tiene el modelo.
9

CMM:

Es un modelo que sus siglas en inglés son Capability Maturity Model que significa

Modelo de Madurez de Capacidades y fue creado por la Universidad Carnegie Mellon. En

este modelo se implantan prácticas y procesos que están agrupados en "áreas clave del

proceso" y en cada una de las áreas se agrupan en "niveles de madurez" donde se evalúan

los procesos que dictaminan si el proceso a conseguido el nivel de madurez necesario. El

modelo CMM en 2005 fue reemplazado por el modelo CMMI.

Características

Es un modelo de evaluación de procesos de una organización es el modelo más utilizado

mide la capacidad del proceso para desarrollo de software.

Ventajas

Proporciona una vista común y comparable que se utiliza en cada proyecto Sus criterios

son de fácil compresión y esto facilita su implementación.

Desventajas

Desviaciones en plazo.
10

MAC CALL:

En este modelo se propone los "Factores de MacCall" que son factores de calidad que se

dividen tres capacidades (Operación, transición y revisión) que a su vez también se dividen

en varios factores que son evaluados por métricas que miden la calidad.

Características

El modelo se basa en la descomposición del concepto genérico de calidad en

capacidades importantes todo desde la mirada del usuario.

Ventajas

Práctico y fácil de entender y aplicar, focalizado en el producto final y en medidas

precisas de alto nivel.

Desventajas

Las características son en general propiedades abstractas mediante métricas. No siempre

existe una relación lineal entre valores de las métricas y la característica.

EFQM:

Este modelo está resumido por el éxito a largo plazo en lo que tiene que ver a resultados

económicos sostenidos por un buen tiempo y que vayan de la mano por la satisfacción de

los usuarios, el bienestar de los empleados y el impacto social. Es un modelo orientado a la

sostenibilidad de la empresa con buenas prácticas, entre ellas tener trazados buenos
11

objetivos, metas y planes, todo esto se controla mediante un cuadro de mando integral,

estructurado por 9 criterios (1. Liderazgo, Estrategia, Personas, Alianzas y Recursos,

Productos y Servicios, Resultados en los Clientes, Resultado en las Personas, Resultado en

la Sociedad y Resultados Clave) que expresan el QUÉ hacer y QUE medir todo esto va

conectado entre lo que hacemos y lo que logramos.

Características

El modelo se puede aplicar con los objetivos de autoevaluación de la organización,

realizada por terceros.

Ventajas

Favorece la competitividad y calidad en la gestión. Genera motivación y participación

interna.

Desventajas

Rechazo inicial por el nivel de exigencia y mejora continua.

DEMING:

Es un espiral de mejora continua de la calidad en cuatro pasos (Planificar-Hacer-

Verificar-Actuar), es muy utilizado por los Sistemas de Gestión de la Calidad (SGC), los

Sistemas de Gestión Ambiental (SGA) y los Sistemas de Gestión de la Seguridad de la

Información (SGSI), regulados por ISO. Con este modelo se logran resultados y mejora
12

integral de la competitividad, productos y servicios de la empresa, todo girando en torno a

satisfacer a los clientes con mejoras dentro de la empresa optimizando la productividad,

reduciendo los precios, incrementando la participación del mercado y aumentando la

rentabilidad.

Características

Cada empresa realiza su autoevaluación, tiene políticas de despliegue en relación con la

gestión de calidad.

Ventajas

Evaluación, efectividad, consistencia, continuidad y minuciosidad. Los procedimientos

dan como resultado escalas con un alto nivel de validez.

Desventajas

Toma mucho tiempo y esfuerzo desarrollarlo. Escala diseñada para un puesto ya que su

diseño es específicamente para este.

SPICE/ISO/IEC 15504:

Esta norma establece requisitos para una evaluación de procesos y los modelos de

evaluación pretendiendo que estos requisitos puedan ser aplicados en cualquier modelo de

evaluación en una organización, también establece requisitos para la evaluación de

procesos para las fases de ciclo de vida del software que se definen en la norma ISO/IEC

12207, así como requisitos para la evaluación de procesos las fases del ciclo de vida del
13

sistema definidos en el estándar ISO/IEC 15288. Es importante hacer uso de esta

herramienta ya que así se podrá ingresar al mercado competitivo, participar en licitaciones

dentro de los desarrollos de Software.

Características

Establece un marco de requisitos para cualquier proceso. Proporciona requisitos para los

modelos de evaluación de los procesos de las organizaciones.

Ventajas

Modelo de las dimensiones. Modelo más consensuado y probado con otros modelos de

calidad ya implementados.

Desventajas

No contiene una estrategia de mejora del proceso. Poco reconocimiento en el mercado.

Permite que el dominio de procesos sea tan amplio que se hace difícil el manejo de los

mismos.


14

4. Empresa seleccionada

La empresa que se escogió fue Qvision Technologies, es una empresa que ofrece

soluciones en el desarrollo de software como aplicaciones web y móviles, aseguramiento de

la calidad, automatización de procesos, talento TI, consultoría TI, la formación y la

certificación.

4.1. Entrevista al ingeniero de software de la empresa

1. ¿La empresa establece un plan de aseguramiento de la calidad?, y por quienes es

aprobado y aceptado este plan de generarse?

2. ¿Cuál o cuáles métodos utiliza la empresa para garantizar la calidad de software?

3. ¿Teniendo en cuenta que la calidad implica cumplir con los criterios de éxito y que

sirva a la necesidad del cliente, las pruebas que realizan para asegurar esta calidad

en que ciclo de vida del desarrollo de software se aplican por parte de su empresa?

4. ¿Su empresa genera documentación para el usuario y del sistema que sirva para

cambios a futuro?

5. ¿Realizan inspecciones sobre el producto que se está desarrollando?, ¿en qué etapas

las realizan y qué roles se asignan, qué documentación se genera una vez terminada

la inspección?

4.2. Respuestas a la entrevista

● Respuesta ingeniero Jorge Leonaro Rubio Beltran (Anexo A).


15

● Respuesta ingeniera Andrea Tobar Gaitan (Anexo B).

● Respuesta ingeniero Jeisson Rodriguez (Anexo C).

● Respuesta ingeniero Nicolas Rodriguez Gutierrez (Anexo D)

4.3. Dofa de la empresa

Tabla 1.

DOFA de la empresa

Fortalezas Oportunidades
Factores a
favor F1 Trabajadores capacitados. O1 Participación activa de los
integrantes del área.

F2 Atención especializada. O2 Reconocimientos a los empleados.

F3 Trabajo en equipo para mejorar O3 Fortalecimientos de relaciones con


la productividad del área. los usuarios.

F4 Disponibilidad de políticas O4 Implementación de nuevas


adecuadas. tecnologías.

Debilidades Amenazas
Factores
encontrados D1 Falta del servicio oportuno en el A1 Pérdidas de usuarios del sistema.
proceso.

D2 Ausencia de innovación A2 Metas no logradas definidas en el


tecnológica. área.

D3 Estructura organizacional en el A3 Demandas jurídicas de parte de los


proceso. clientes.

D4 Ausencia de manuales de A4 Llamados de atención desde la alta


funciones. gerencia.

F1-D1: Esta combinación se puede ejecutar ya que al tener personal capacitado y entrenado

en los nuevos procesos que la compañía implementaría, con el objeto de aumentar la

eficiencia y entrega oportuna de las facturas a los clientes, foco de esta investigación.
16

O1-A1: En esta estrategia se implementa toda vez que los colaboradores de la organización

mantengan una interacción constante con los procesos que se implementaran, así habría un

mejor tiempo de respuesta a los requerimientos de nuestros usuarios y mayor satisfacción a

los mismo.

F2-D4: Se obtiene esta estrategia al momento de implementar los manuales de funciones

por cargo para que los mismos permitan generar un servicio eficiente y que cumpla con las

expectativas de nuestros usuarios.

O3-A3: Una estrategia que nos permitirá prever de manera oportuna las inconformidades

de cada uno de nuestros usuarios así evitar futuras pérdidas debido a las posibles demandas

jurídicas que se puedan presentar por la falta de acercamiento con los usuarios.

5. Modelo Seleccionado

Al implementar el modelo CMM se puede mejorar y direccionar el desarrollo del

proyecto para así tener una orientación hacia un proceso estándar y así poder reducir el
17

tiempo de aprendizaje de cómo ejecutar lo que está planteado en el desarrollo, y así se

pueda ejecutar los niveles del CMM satisfactoriamente en esta metodología de calidad de

software.

En los criterios para evidenciar el avance de la empresa se debe tener en cuenta las

debilidades y las oportunidades, que en pocas palabras esto nos indica un desarrollo sin

metodologías ágiles en las cual se evidencia la poca comunicación con el cliente.

Con un modelo que obtenga calidad y optimización podemos solventar este problema

para que ambas partes ganen.

En ese orden de ideas la empresa se encuentra en el nivel 2 de CMM donde los

requerimientos del proyecto no suelen ser claros, comprendidos y controlados.

Tabla 2.

Análisis para selección de modelo.


18

Criterio Hallazgo
Las instrucciones ni el plan de trabajo son claros
para el líder del proyecto, esto conlleva a que las
Planeación del proyecto
diferentes áreas involucradas tengan una mala
comunicación y no trabajen en sincronía.

Este este criterio es muy importante porque así se


Gestión de calidad de software tenga una buena organización, sin una buena
calidad de software no habría ningún avance del
proyecto, se recomienda entrar hacer pruebas
desde un inicio del desarrollo.

Hay que mejorar la fase de requerimientos ya que


Gestión de requisitos esto hace que los tiempos de gestión sean altos y
esto impacta en fechas estipuladas con los
clientes.

Hay que trabajar de la mano con los


Seguimiento y supervisión del proyecto desarrolladores para que entre el equipo de QA y
desarrollo no haya pérdidas de tiempo y solo se
realicen los cambios necesarios.

Hay evidencia que la compañía no tiene


controlados todos los criterios anteriores, esto
Definición el proceso de QA de la organización
demuestra falencias en la organización lo que nos
lleva a tener un gran gasto de tiempo y dinero en
los procesos de desarrollo.

Partiendo de lo anterior se podrá trabajar con los modelos PPQA y Sm3. Se tendrá como

prioridad el proceso de mantenimiento del software con el modelo de madurez junto con el

de calidad, en cual se puede optimizar en tiempos y recursos y usándolos de una forma más

productiva, esto permite tener un mejor control de necesidades para el cliente.

5.1. Mejoramiento de la calidad de la empresa

5.1.1. Plan de pruebas


19

Una de las acciones de mejora de mayor relevancia es sin duda alguna el plan de

pruebas, pues este, ejecutado con criterios de calidad y observando las buenas prácticas

puede ahorrarnos tiempo, trabajo y dinero. Basados en las entrevistas realizadas y teniendo

como premisa el presentar a la empresa QVision herramientas para la mejora de sus

proyectos y desarrollos desde sus ciclos de vida temprana, y teniendo en cuenta lo

aprendido en los escenarios de estudio, esbozamos lo siguiente:  

● Objetivo

Diseñar las estrategias, documentación, cronología y demás condiciones necesarias para

la ejecución de un plan de pruebas que permita en todas las etapas del ciclo de vida del

desarrollo y/o proyecto el cumplimiento de los requerimientos establecidos.

● Elementos a probar

● Se identificarán aquí los elementos sujetos a pruebas que deberán ser definidos según su

relevancia.

● Estrategia

Escoger la estrategia a trabajar que sea compatible con el desarrollo y/o proyecto.

● Entorno (Ambiente)

Preparación de las condiciones para el correcto desarrollo de las pruebas.

● Criterios de aceptación

Elección de parámetros de aceptación de la prueba, de los cuales podemos afirmar que, a

mayor exigencia mayor calidad.


20

● Datos de prueba

Información con la cual se simularán las pruebas.

● Responsables

Quienes participan de manera directa en la ejecución y valoración de las pruebas.

• Cronograma

Definición de los tiempos de ejecución de las pruebas.

• Control de cambios

Informe de los resultados, correcciones, mejoras.

● Formatos y reportes

5.1.2. Planeación

● Proyecto

● Documento base del proyecto

● Actas de contextualización

● Documentos de estrategias de calidad de software

● Cronograma

5.1.3. Diseño

● Datos del proyecto


21

● Matriz de casos de pruebas

5.1.4. Ejecución

● Ciclos 1, 2

● Ciclo de regresión

● Documento de Certificación del proyecto

5.1.5. Evaluación y gestión

● Actas de reuniones

● Informes de avance

● Bitácoras de la línea de vida del proyecto

● Matriz de gestión de riesgos

SEGUNDA ENTREGA - SEMANA 5

6. Roles, responsabilidades y actividades para el cumplimiento de la Calidad

Gerente de Proyecto:

Es aquel que realiza seguimiento por requerimiento funcional y si la certificación no da el

aval para la producción, hace la solicitud al comité de control la revisión respectiva para

poder generar el plan de acción correspondiente.


22

Líder Encargado:

Es el que realiza el control de las actividades de certificación y es el que aclara sobre cuál

es el alcance y propone que validaciones se deben tener en cuenta sobre la solución que se

está desarrollando.

Líder de Certificación:

Es el que realiza la lectura, verificación y validación de los entregables. Ayuda a

contextualizar las pruebas que va a realizar al ingeniero o analista de certificación y realiza

el seguimiento periódico durante todo el proceso de certificación.

Líder Técnico:

Es aquel que analiza en un nivel técnico el alcance del proyecto, lo que se debe realizar, los

prerrequisitos necesarios para la ejecuciòn y verifica el esfuerzo de las actividades del

desarrollo.

Líder Técnico:

Es aquel que analiza en un nivel técnico el alcance del proyecto, lo que se debe realizar, los

prerrequisitos necesarios para la ejecuciòn y verifica el esfuerzo de las actividades del

desarrollo.
23

Analista de pruebas:

Es aquel que realiza la ejecución de los casos de pruebas, contextualiza las pruebas a

realizar. Realiza los reportes de gestión de incidentes, mantiene informado al Líder

Encargado con los avances de la ejecución, brinda soporte a las pruebas ejecutadas por el

cliente y realiza revisión final de todos los entregables.

7. Tipos de pruebas que serán aplicadas al proyecto

Pruebas unitarias:

Pruebas realizadas en componentes individuales en la etapa de desarrollo. Orientadas

principalmente a validar el cumplimiento de los estándares de presentación y demás

características visuales de la aplicación como la salida de los reportes y la apariencia de las

interfaces de entrada y salida de datos.

Pruebas funcionales:

Pruebas de Humo y Pruebas funcionales de seguridad. Son evaluaciones que se hacen sobre

la ejecución de una funcionalidad que está siendo ajustada en la solución informática.

Pruebas no funcionales

Evaluaciones que se hacen sobre elementos que intervienen en el resultado de la ejecución

de una funcionalidad de la solución informática (rendimiento, carga, estrés y seguridad).

Pruebas de integración

Comprueban que las interfaces entre los distintos módulos y/o productos son correctas.
24

Pruebas de sistema

En estas se incluyen la funcionalidad, de usabilidad, de seguridad, de internacionalización y

de localización, de confiabilidad y de disponibilidad, de capacidad, de funcionamiento de

recuperación, de portabilidad.

Pruebas de procesos

Valida que los procesos soportados por la aplicación se cumplen completamente, que

fluyen desde su inicio hasta su final.

Pruebas de aceptación

Se hacen con los clientes finales quienes definen la aceptación del sistema, son las más

exhaustivas posibles.

Pruebas de regresión:

Consiste en repetir la ejecución de un conjunto de casos de prueba para verificar que unos

cambios en los componentes mantengan la funcionalidad y que las características agregadas

no han creado conflicto con las versiones anteriores.

Análisis de vulnerabilidades:

Tiene como objetivo detectar las vulnerabilidades en la parte de seguridad del software.

Todo análisis de vulnerabilidad se debe realizar en todas las aplicaciones que están ya de

cara al usuario final, estas pruebas estarán a cargo de un Ingeniero de Seguridad. Las etapas

que se deben tener en cuenta son:


25

1. Ejecución de las pruebas de vulnerabilidad.

2. Revisar las vulnerabilidades para determinar cuáles son falsos positivos y cuáles se

deben tratar.

3. Calificar las vulnerabilidades con nivel de calificación alto y medio.

4. Aplicar remediaciones sobre las vulnerabilidades que se identifiquen en el ambiente de

certificación.

5. Ejecutar de nuevo las pruebas de vulnerabilidad para verificar que se hayan corregido.

8. Políticas de calidad

Las políticas de calidad son las instrucciones y objetivos generales que una empresa debe

aplicar para alcanzar la calidad esperada. Los encargados de administrar y dirigir el proceso

son los gerentes de operaciones. A continuación, las políticas de calidad a seguir por parte

de la empresa.

● Guía del proceso.

Objetivo: Servir de guía indicando ciertos controles en los procesos de desarrollo del

producto o del servicio.

● Uso adecuado de herramientas de calidad.

Objetivo: Se utilizará las herramientas de calidad y de estadística que indicaran una medida

que ayude a mejorar el proceso de desarrollo, el producto software, y los servicios.


26

● Auditorías internas.

Objetivo: Se realizarán dos ciclos de auditorías internas cada año, para verificar que lo

planeado se esté ejecutando correctamente.

● Escuchar a los clientes.

Objetivo: Se entenderá con sumo cuidado los requerimientos del cliente y se anotarán para

tener una guía durante el proceso de desarrollo del software y se tomarán en cuenta las

necesidades futuras del cliente.

● Cumplimiento de los compromisos.

Objetivo: Se realizará un control de los compromisos de los entregables haciendo

inspecciones rutinarias sobre ellos.

● Satisfacción del cliente.

Objetivo: Se mejorará el tiempo de entrega del producto y se optimiza la ejecución de los

servicios para los clientes.

● Mejora continua.

Objetivo: Se hará control a cada actividad para mejorar sus tiempos dentro del proyecto.

Objetivo: Al personal del proyecto se les mejorará sus habilidades con capacitaciones.

● Eficiencia de los recursos.


27

Objetivo: Se realizará un uso adecuado de los recursos para hacer control sobre aquellos

productos que no satisfacen los requerimientos del cliente y que generan muchos reclamos.

8. Plantilla Estimación de tiempos - Pruebas Funcionales

8. Conclusiones

1. Por medio del modelo CMM (Modelo de madurez de Capacidades) que nos permite

conocer las áreas claves del proceso y aplicado a la empresa Qvision Technologies se pudo

evidenciar que los requerimientos del proyecto no suelen ser claros, comprendidos y

controlados.

2. Con el plan de pruebas pudimos evidenciar que los modelos a aplicar a la empresa

correctamente son PPQA y Sm3 que busca darle prioridad al proceso de mantenimiento de

software y de calidad.

3. Es indispensable la incorporación de estrategias de innovación tecnológica, ya que

permiten a la empresa alcanzar mejores niveles de competitividad en el ámbito comercial,

social, frente a las exigencias de los clientes, sus necesidades y por tanto, el óptimo

desarrollo de sus proyectos.

4. A partir del reconocimiento de los diferentes modelos de calidad, se nos ha facilitado la

identificación de aquellos que desde sus contenidos y estructuras contribuyen al logro de

mejoras en la calidad de los productos y servicios ofrecidos por la empresa.


28

5. En el diseño e implementación de estrategias en torno al plan de calidad en un proceso de

software, juega un papel esencial el apoyo de cada uno de los actores del proyecto

retroalimentando continuamente para el cumplimiento de los requerimientos funcionales y

no funcionales del cliente.

6. Es fundamental que cada actor responsable del proyecto conozca y aplique lo necesario

de estas actividades, pruebas, formatos y medios de comunicación, procedimientos etc, que

garantizan el cumplimiento de las necesidades del cliente, asegurando de esta manera la

calidad de los productos software, teniendo en cuenta que gracias a las pruebas de calidad

de software se puede contribuir a minimizar los posibles riesgos, fallos que puedan existir a

corto, mediano y largo plazo en las aplicaciones, permitiendo identificar los defectos antes

de que se desarrollen y tomar las decisiones correctivas de manera oportuna.

9. Referencias
29

Comité Internacional de Estándares de Ingeniería de Software y Sistemas. (2005). ISO/IEC

15504. Obtenido de https://www.normas-iso.com/iso-iec-15504-spice/

Garcia, C. (s.f.). El Modelo de Capacidad de Madurez y su Aplicación en Empresas. (M. d.

software, Editor) Obtenido de https://tinyurl.com/4ss6rr7c

Proquo Intelligent Management. (s.f.). Software de Excelencia Empresarial. Obtenido de

https://proquo.pro/software-excelencia-empresarial.html

Tuya, J. (2007). Técnicas cuantitativas para la gestión en la ingeniería del software. (E.

Oleiros, Editor, & S. Gesbiblo, Productor) Obtenido de https://tinyurl.com/5kpc6ps

Wiiliam, D. (1989). Calidad, Productividad y Competitividad: La Salida de la Crisis.

Obtenido de https://tinyurl.com/2mretuku

Esquen, J.P. y Ramos, Y.C. Gestión de información integrado para la toma de decisiones.

Recuperado de https://tinyurl.com/769pd3h7
30

10. Anexos

Anexo A. Entrevista ingeniero Jorge Leonardo Beltrán


31

Anexo B. Respuesta ingeniera Andrea Tobar Gaitán.


32

Anexo C. Respuesta ingeniero Jeisson Rodriguez.


33

Anexo D. Respuesta ingeniero Nicolas Rodriguez Gutierrez.

También podría gustarte