Pruebas y Calidad de Software

Entrega 2
Ivan Andres Vidal Jojoa Cod.1721981132
Jaimer Leandro Burgos Ruiz Cod.1811982405
Deny Luz Vergara Barrios Cod.1811982177
Carlos Arvid Amin Barajas Cod.1320650524

16/04/2019

1 Introducción
Dentro de esta entrega previa generaremos una descripción básica de los mod-
elos de calidad que se pueden escoger para aplicar dentro del desarrollo de
productos software, para ello veremos sus ventajas y desventajas, junto con los
costos, beneficios y otras comparativas importantes para comprobar la calidad
de software.
Tras esto escogeremos los 2 modelos más apropiados para lograr la calidad de
los productos en nuestra empresa de desarrollo de software, de carácter externos
o de carácter interno.
Se establecerá una lista de actividades, de procesos y de procedimientos que
se implementará en el transcurso del ciclo de vida del desarrollo de productos
software que requieran esa definición en la empresa, logrando la aplicación de un
proceso de pruebas que nos asegure una mayor calidad y nos asegure la fluidez
de un plan de pruebas.
Para este caso particular analizaremos y generaremos el mejoramiento de
la empresa Colombia Telecomunicaciones (Telefónica - Movistar), la cual ac-
tualmente oferta desarrollo de soluciones Big Data para empresas. Con el
surgimiento de mejores canales de comunicación, con la importancia de im-
pulsar la telecomunicación y lograr llegar más mercados.

Palabras Clave: Pruebas, Calidad, Mejora, Software

2
2 Elementos de Calidad para Desarrollo de Soft-
ware
En este apartado se determinan elementos de los diferentes Modelos de Calidad
de aplicabilidad al proceso de desarrollo de software con el fin de:

• Definir y detallar todas las tareas que se desarrollarán durante el proceso.

• Definir las actividades que cada actor del proceso tendrá a cargo
• Evaluar la calidad

Lo anterior con el fin de asegurar la calidad en el proceso encaminado al

cumplimiento de los diferentes requerimientos de software objeto de desarrollo,
detectando ası́ las malas prácticas y errores de funcionalidad.
A continuación, se realiza un comparativo de los elementos que a consid-
eración influyen más en el proceso de Desarrollo de software realizando un
análisis de factores como esfuerzo, tiempo, costo y beneficios.

Figure 1: Evaluación Elementos de Calidad

3
3 Modelos de desarrollo de productos de soft-
ware
Es importante destacar que en los procesos administración de proyectos existen
3 términos básicos que debemos diferenciar:

• El Producto

• El Sistema.
• Los Entregables.

3.1 Modelo CMM

1
Este modelo establece un conjunto de prácticas o procesos clave agrupados
en Áreas Clave de Proceso (KPA -Key Process Area). Para cada área de proceso
define un conjunto de buenas prácticas que habrán de ser:
1
.

• 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 (institucional-

izadas).
• Medidas
• Verificadas

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 es-
table 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.
1 https://www.globales.es/imagen/internet/InformaciC3B3n20General20CMMI.pdf

4
 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 un
nivel más avanzado de métricas en los procesos. Se implementan técnicas
de revisión por pares (peer reviews).

4. Gestionado: Se caracteriza porque las organizaciones disponen de un con-

junto 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. Se hace uso intensivo de las métricas y se gestiona el
proceso de innovación.

3.2 Modelo CMMI

2
Es el máximo estándar en ingenierı́a de software Innovación, velocidad y
satisfacción del cliente se han convertido en la consigna de las organizaciones
que quieren sobrevivir y crecer en el cada vez más competitivo mundo moderno.
Como las tecnologı́as de información resultan fundamentales para lograrlas, el
software se ha constituido en la piedra angular sobre la cual se soportan la gran
mayorı́a de los nuevos modelos de empresa.

2
.
.Ventajas de base frente al modelo CMM:

• Merma del coste de desarrollo.

• Búsqueda y solución de defectos

• Aumento en la fiabilidad de la planificación.

• Una mayor productividad.
• Reducción de los trabajos derivados de correcciones tras las fases de prue-
bas.

• Aumento de la efectividad sobre la planificación realizada

• Mejora en la calidad de producto.
• Reducción del número de defectos y detección en las fases tempranas de
su ciclo de vida.

• Mejora de la Imagen de Marca.

2 EVALUACIÓN DE LA CALIDAD DE LA TECNOLOGÍA EDUCATIVA, LIDA

MARCELA GOMEZ YEPES

5
 Desventajas:

El problema de CMMI es su falta de adecuación al enfoque a servicio que está

experimentando el sector de las TI (procesos de desarrollo de productos de soft-
ware) en todas sus lı́neas de actividad, ası́ como el alto esfuerzo de implantación
que exige.

• El proceso de evaluación es muy costoso en tiempo y esfuerzo

• La complejidad de la evaluación continua puede atentar contra la definición

de objetivos concretos de madurez. De los cinco niveles de madurez que
establece este modelo, el nivel de Repetible es el que mayor porcentaje
de organizaciones presenta, seguido por los niveles Definido e Inicial esto
brinda una idea del desarrollo que ha tenido en las organizaciones, y el
interés que demuestran las mismas por alcanzar niveles de madurez may-
ores en aras de ganar eficiencia y mejorar los procesos de desarrollo de
software.

3.3 MODELO ISO/IEC 25000 O SQuaRE (System and

Software Quality Requirements and Evaluation)
Es una familia de normas que tiene por objetivo la creación de un marco de tra-
bajo común para evaluar la calidad del producto software. La familia ISO/IEC
25000 es el resultado de la evolución de otras normas anteriores, especialmente
de las normas ISO/IEC 9126, que describe las particularidades de un modelo
de calidad del producto software, e ISO/IEC 14598, que abordaba el proceso de
evaluación de productos software. Esta familia de normas ISO/IEC 25000 se
encuentra compuesta por cinco divisiones.

Ventajas

• El modelo representa la calidad esperada del producto de software.

• Planteo del desdoblamiento de las necesidades o expectativas en calidad
en uso, calidad externa y calidad interna.
• Permite una mayor eficacia en la definición n del software.

• Plantea la evaluación de productos intermedios.

• Propone una calidad final a través de las evaluaciones intermedias.
• Permite efectuar un rastreo entre las expectativas, requisitos y medidas
de evaluación.

• Mejora la calidad del producto.

6
 Desventajas.

• El soporte prestado a las empresas no concuerda con el modelo de evalu-

ación de la ISO/IEC 25000.
• En dado caso de no pasar la evaluación es mejor comenzar de nuevo que
reparar los errores de nuestro producto La refactorización del producto es
muy costosa

3.4 MODELO PDCA

Los resultados de la implementación de este ciclo permiten a las empresas una
mejora integral de la competitividad, de los productos y servicios, mejorando
continuamente la calidad, reduciendo los costos, optimizando la productividad,
reduciendo los precios, incrementando la participación del mercado y aumen-
tando la rentabilidad de la empresa u organización
El Ciclo de mejora continua PDCA se utiliza para llevar a cabo la mejora
continua y lograr de una forma sistemática y estructurada la resolución de prob-
lemas.
El cı́rculo de Deming es un método iterativo de gestión, cuyo fin es obtener
la mejora continua de un producto, proceso o servicio en una organización. Lo
primero que se debe tener claro es la toma de conciencia, tanto de la gerencia
como de los empleados, en adoptar la mentalidad de un mejoramiento continuo.

Etapas:

1. Planificar
2. Hacer

3. Verificar
4. Actuar

Ventajas.

• El carácter iterativo del cı́rculo permite una atención continua para mejo-
rar la calidad.
• Debido a que todos forman parte del proceso general, se produce un sen-
timiento de integración que afecta positivamente a toda la organización.
• Su aplicabilidad es ilimitada.

• Puede emplearse tanto en la resolución de problemas de liderazgo empre-

sarial como en los procesos de fabricación de productos, correspondientes
al área de producción y control de calidad.

7
 • Permite que una empresa pruebe en pequeña escala el cambio que desea
implementar antes de gastar en algún método que pudiera no funcionar o
requerir un ajuste.
• Permite efectuar un rastreo entre las expectativas, requisitos y medidas
de evaluación.

• Mejora la calidad del producto.

Desventajas.

• Funciona mejor cuando las condiciones son perfectas, no teniendo cabida

aquellas variables que puedan surgir durante el desarrollo del proyecto.
• Podrı́a no ser el enfoque adecuado para enfrentar una emergencia, ya
que con los cuatro pasos que se deben cumplir el avance suele ser lento.
El cı́rculo es más metódico que otros planes operativos, lo que lo hace
ineficiente si se necesita implementar una acción rápida.

• Un proyecto puede permanecer demasiado tiempo en las primeras etapas,

analizando la situación a la que se va a aplicar. El exceso de análisis
es una forma efectiva de matar un proyecto. Si bien el ciclo permite una
planificación cuidadosa, el trabajo real solo se produce en la fase de acción
final.

• Con frecuencia el resultado final queda relegado al proceso. En una or-

ganización los procesos son importantes, pero son los resultados los que
harán tangible los beneficios del cambio implementado.
• En cada una de las etapas de este cı́rculo se hace gran énfasis al tra-
bajo en equipo. Esto dificulta enormemente la evaluación del rendimiento
individual de los trabajadores.

3.5 MODELO EFQM

El modelo EFQM puede aplicarse con los siguientes objetivos:

• Autoevaluación de la organización
• Autoevaluación realizada por terceros

• Busca determinar fortalezas y oportunidades de mejora de las organiza-

ciones que lo implementa o se somete a él centrándose en la relación entre
su personal, procesos y resultados

8
3.6 MODELO Malcolm Baldrige
Establece que el lı́der de la organización debe estar orientados a la dirección
estratégica y a los clientes Dirige, responde y gestiona el desempeño basándose
en resultados Las medidas y los indicadores del desempeño y conocimiento or-
ganizativo deben ser la base sobre las áreas que construir y las estrategias clave
Consigue mejorar el desempeño general de la organización y la satisfacción de
consumidores y de los grupos de interés.

Ventajas.

• Evalúa
• Mejora

• Planifica: hacia la gestión de la excelencia

• Enfoque en los resultados y en la creación del valor
• Excelencia enfocada al cliente Visión de liderazgo
• Dirección por hechos

• Valoración de los empleados y socios

Desventajas.
• Toma mucho esfuerzo y tiempo desarrollarlo

9
4 Análisis FODA proceso Desarrollo de Soft-
ware
Se ha tomado como punto de partida la empresa Colombia Telecomunicaciones
(Telefónica - Movistar), la cual actualmente oferta desarrollo de soluciones Big
Data para empresas, se han realizado pequeñas entrevistas a personal de las
áreas inmersas en el proceso, posteriormente se ha realizado una evaluación de
sus respuestas y se ha podido identificar la matriz FODA a continuación.

Figure 2: Matriz FODA

5 Modelo de Desarrollo
Dentro del modelo de Capacidad de Madurez luego de analizar los procesos de
desarrollo de software que actualmente maneja la empresa Colombia Telecomu-
nicaciones se ha identificado estar en el nivel 4, Administrado.
Lo anterior debido a que se ha logrado evidenciar que la empresa basa sus
decisiones en datos estadı́sticos, realizando mediciones en todo el ciclo de vida
del proyecto, es importante que la premisa de la organización es la calidad del
producto y la satisfacción total de los requerimientos del cliente.
Dado que el desarrollo va encaminado a procesos de Big Data los repositorios
de información estadı́stica y de los proyectos son bastante amplios contando con
mejoras y puntos clave de los procesos ejecutados.
Dentro de los elementos más claramente identificados hemos encontrado:

• Procesos de Retroalimentación Grupales. (Celulas Agile)

• Definición de planes bajo metodologı́as Scrum.
• Aseguramiento continuo de la calidad y auditorias constantes.

• Capacitación continua y PI Planning (Metodologia Agile)

10
 • Uso de la información estructurada y no estructurada de los proyectos.
• Capacitación continua y PI Planning (Metodologia Agile)

6 Lista de actividades
• 1. Es importante realizar un debido análisis de los requerimientos de los
clientes ya que de este ı́tem se parte para que la ejecución del desarrollo
sea exitosa dentro de las labores más importantes para esta actividad se
destaca el análisis de historias de usuario y la correcta especificación de
los casos de uso abarcando todos los posibles escenarios que se puedan
presentar derivados de la operación especı́fica para la cual se desarrolla el
software.
• 2. Es importante destacar que ciertos aspectos influyen de manera más
relevante en la calidad del producto, estas funcionalidades deben ser eval-
uadas en cada una de las etapas del ciclo de desarrollo, es importante
desde la fase de requerimientos identificar plenamente estas y probarlas
secuencialmente.
• 3. El esquema de pruebas debe ser secuencial adaptable enfocado al
cumplimiento de los requerimientos con altos estándares de calidad, esto
se logra con una estrategia definida ejecutando pruebas funcionales en
primera instancia seguidas de pruebas de sistema.
En medida que el equipo de desarrollo va integrando los componentes de
la aplicacion en sus diferentes capas se deben ejecutar pruebas de caja
negra, no funcionales y de regresión.
• 4. El Plan de Pruebas del Sistema es una especificación de alto nivel
de los requerimientos funcionales y de calidad que serán probados, del
ambiente de pruebas, de la estrategia, de las responsabilidades y de los
criterios de éxito. El comportamiento de un producto bajo pruebas será
comparado con las especificaciones de los requerimientos que fueron usados
para implementar el sistema, incluyendo todos los cambios que han sido
aprobados e implementados.

• 5. Para poder comenzar la fase de pruebas del sistema, se deben cumplir

los siguientes criterios:

– Test unitarios realizados y completados para cada componente del

sistema.
– Fase completamenta integrada.

• 6. Al menos 95 por ciento de los casos de prueba principales deben haber

sido pasados exitosamente. El 5 por ciento restante deberá estar plena-
mente justificado.

11
• 7. Al menos 85 por ciento de los casos de prueba no principales deben
haber sido pasados exitosamente. El 15 por ciento restante deberá estar
plenamente justificado.
• 8. El equipo de arquitectura debe suministrar los requisitos mininos y
óptimos para la operación del sistema dentro de un entorno de confiabili-
dad para establecer un ambiente de pruebas idéntico al de producción que
permita evidenciar el comportamiento del software en estado final.
9. En modo de operación normal, el sistema debe ser capaz de detectar
malas prácticas de programación de código. Una vez detectada las malas
prácticas, el sistema debe indicar la dirección del archivo de código fuente
el número de lı́nea donde se detectó la mala práctica de programación y
de qué tipo de error que es. 10. Se realizará el Informe de Pruebas del
Sistema a modo de check list donde se dé la verificación de cada proceso
realizado con éxito, ası́ mismo se tomarán Pantallazos del sistema en cada
caso.
11. La secuencia de actividades para probar el sistema es:

– Ejecución de las pruebas en operación normal

– Ejecución de pruebas de excepción
– Corrección de errores
– Ejecución de las pruebas que fallaron en la primera pasada
– Repetición de los pasos 3 y 4 hasta que se logré un 100 por ciento de
éxito.
– Escritura del reporte

12. Se establece las responsabilidades de cada grupo que participa en la

fase de pruebas.
– Responsabilidades del Grupo de Desarrollo
∗ Ejecutar las pruebas unitarias
∗ Ejecutar y probar la integración
∗ Corregir los problemas reportados
– Responsabilidades del Grupo de Pruebas
∗ Planificar las pruebas del sistema
∗ Configurar el ambiente de prueba
∗ Ejecutar las pruebas del sistema
∗ Escribir el reporte de pruebas
– Responsabilidades de la Supervisión
∗ Aceptación final y aprobación de la liberación del producto
12. Por último se deben obtener las conclusiones del proceso y determinar
los puntos a mejorar a fin de Asegurar la Calidad del proyecto y satisfacer
plenamente los requerimientos.

12
 ENTREGA PREVIA 2
SEMANA 5
De acuerdo con las necesidades establecidas en la entrega ante-
rior, documente las actividades, procesos y procedimientos que se
requieran para llevar a cabo la mejora de la calidad en el desarrollo
de productos de software en la empresa.

Existen grandes diferencias entre tener un modelo y acogerse a él cubriendo

todas las caracterı́sticas que se consideran dentro del mismo como buenas prácticas
para el mejoramiento de los proceso de software, dado esta gran diferencia, la
búsqueda de una estrategia que lleve los proceso de esta empresa de software
a cubrir y aplicar cada una de las caracterı́sticas que se propone en el modelo,
llegamos a la conclusión que para suplir esta necesidad será necesario el uso del
modelo IDEAL (IDEAL Es un modelo de mejora organizacional que sirve como
mapa para iniciar, planificar e implementar acciones tendientes a mejorar los
procesos).

Ahora, aunque en este modelo IDEAL tiene cinco fases presentados en la tabla:

Figure 3: Modelo IDEAL

13
 Generaremos un diagnostico preliminar, que nos permita identificar el nivel
de capacidad de los procesos dentro de la organización y también nos propor-
ciones la identificación de las oportunidades de mejoramiento, esta evaluación
se puede realizar con el acompañamiento de un evaluador o de modo auto eval-
uativa.
Aquello que serı́a recomendable evaluar, es decir sus caracterı́sticas serian: cuál
es el ciclo de vida que esperamos cumpla el producto, cual es el estado actual de
ese ciclo de vida, cuales son los requerimientos del sistema como los del software;
encontrar el tamaño y la complejidad propia del problema; que tan crı́tico es el
proyecto y cuál es el tiempo de sistema, software o servicio que se está brindando.

Se propone el buscar cual es el nivel de capacidad de los procesos de la organi-

zación, su estado, y las oportunidades de mejora de éstos, con miras a plantear
los objetivos adecuados. Por ende, el objetivo serı́a producir un plan que nos
permita incluir la definición clara de las acciones a realizar, con el fin de llevar
a la empresa hacia el nivel deseado que es definido basado en el estado de los
procesos que nos arroje el diagnóstico que ya realizamos para este momento.

Con la finalidad de lograr lo anterior sabemos que se deben cubrir las sigu-
ientes tareas: cuales son las prioridades, definir la aproximación a la solución y
planear la acción, tras esto, crear los nuevos procesos y modificar los procesos
de la compañı́a que actualmente aplican, involucrando todo lo que dicta CMMI
para estar en el nivel óptimo deseado, aprender del ciclo IDEAL que se ha dado
a realizar e incrementar la habilidad de la organización para mejorar los proce-
sos por medio de socialización intra-grupal de las fallas y errores que se dieron,
en la definición de procesos o tan bien en el momento de conseguir el proyecto
de implantación de CMMI y el corregir de estos errores de los procesos previo
a generar un nuevo diagnóstico.
Sabemos perfectamente que el mejoramiento de la calidad es consecuencia del
uso de estándares de procesos, tanto como de actividades de medición y mejora
de manera perpetua y también se puede comprobar en la organización del soft-
ware cuando miramos la manera de realizar las actividades. De esta manera
serán las métricas las que nos ayuden dentro de la administración de las tareas
de desarrollo de los procesos como de los productos.

Es innegable, pues, que una ayuda extra será la medición de la satisfacción del
cliente, esta le permite a la empresa corregir y ajustar su proceso dependiendo
de la percepción que el cliente tiene cuando se da la generación de valor. además,
cuando tenemos esta valoración se genera un trabajo mutuamente solido en la
relación entre el cliente y la empresa, ya que el cliente tendrá más seguridad de
los servicios prestados.

Lo primordial seria el conocer a fondo la empresa seleccionada “Colombia Tele-

comunicaciones” saber cuáles son sus funciones y cuáles son los métodos que
usa para realizar dichas funciones para identificar procesos innecesarios, con el
fin de que al eliminarlos podamos mejorar y depurar el actuar de la empresa.

14
No podemos permitir que se generen procesos que hagan más de una vez una
actividad, para esto lo fundamental serı́a una revisión minuciosa a los procesos
actuales, haciendo que la empresa pueda generar más con menos recursos y en
consecuencia sea mucho más competitiva, además de ser más eficiente.

Se aplicará una madera de controlar el desempeño de los procesos de manera

que se pueda conseguir un alto nivel de calidad y capacidad en los resultados de
cada proceso, ya que esta caracterı́stica procura un alto nivel de satisfacción en
los individuos que miden bajo el concepto de calidad los resultados generados
por la empresa en su totalidad, es decir los clientes.

Creemos necesario el Analizar, Definir y redefinir el recurso humano requerido

para el proyecto esto será con el fin de poder estimarlo adecuadamente, por ello
recomendamos puntualizar los roles y los requerimientos o perfil para acceder en
estos roles y buscando, localizando y posicionando a los candidatos de manera
rápida e inequı́voca.

15
 Defina la estrategia e hilo conductor a largo plazo: el grupo de tra-
bajo destinado a pruebas, las polı́ticas, los responsables y sus roles, los
formatos y medios de comunicación, los capacitadores, las reuniones
de control, la recolección de datos, las métricas, la frecuencia de las
revisiones, la codificación de versiones de componentes, el esquema
de informe de cambios, etc.

Los grupos que cargarán con la responsabilidad del proyecto, son:

Figure 4: Comité Directivo

16
 Figure 5: Grupo de ingenierı́a de Proceso

Figure 6: Equipo de Definición de Procesos (PAT)

17
Figure 7: Gerentes y Jefes de Proyectos

Figure 8: Equipos Evaluadores

18
 Figure 9: Logı́stica

Además de estos grupos planteados hay personas particulares que también

deben hacer parte de todo esto los cuales serı́an:

• El o los patrocinadores

• Lı́der del proyecto o gerente

• Asesor CMMI
• Experto en procesos
• Comunicador

• Jefe de SQA

textbfSelección de estrategias para la implementación de Mejoras en los

procesos de Software.

La mejora de procesos software se ha convertido en la forma más lógica y

obvia de dirigir la creciente necesidad de aumentar la competitividad en las
empresas de desarrollo de software. Desafortunadamente no todas las imple-
mentaciones de mejoras en los procesos tienen el rendimiento deseado, debido a
que los modelos y estándares existentes centran su atención en qué actividades
implementar sin abordar el cómo implementarlas. Sin embargo, la identificación
de qué actividades implementar no es suficiente y el conocimiento del cómo im-
plementarlas es requerido para el éxito de la implementación de iniciativas de
Mejoras de Procesos Software (MPS) en las empresas de desarrollo de software.
Como parte de este trabajo, realizar entrevistas con empresas locales desar-
rolladoras de software con la finalidad de contrastar con resultados reales los

19
resultados obtenidos en la empresa contra los demás. Para obtener la infor-
mación, se puede elaborar un cuestionario como guı́a en las entrevistas para
poder obtener la la experiencia en MPS de las empresas.
Como resultado de las entrevistas a empresas que ya han tenido experien-
cia en MPS, obtener algunas prácticas que nos ayuden al éxito para la imple-
mentación de los proyectos de la empresa, por ejemplo:

• Establecer inicialmente los objetivos, definiendo por qué se quiere una

implantación de mejora procesos.

• Convencer a la alta gerencia para que sean promotores, patrocinadores y

guı́as de la implementación de mejoras.
• Visualizar el beneficio que se obtendrá con la mejora de procesos.

• Apostar por el capital intelectual de la empresa.

El proceso de desarrollo de software idealmente deberı́a estar en armonı́a

con el contexto en el cual el software es desarrollado y entregado.
Se inicia con profase en la que se confirma, mediante un checklist, que la em-
presa tiene identificado cómo se trabaja, cuáles son los objetivos de negocio que
busca alcanzar; cuál es su rendimiento y su objetivo al implementar la mejora de
procesos. Posteriormente, realizar por parte de la empresa una comparación de
su entorno con los entornos establecidos en la propuesta que tenga por realizar
por medio de categorı́as y ası́ se les pueda proporcionar aquella estrategia que
se adecue a sus necesidades. Para el establecimiento del conjunto de estrategias
se toman como base los seis aspectos contextuales propuestos (Petersen Wohlin
2009), considerados como aspectos a tener en cuenta para una implementación
de mejora de procesos en cualquier organización: producto, proceso, prácticas y
técnicas, recurso humano, organización y mercado. La planificación, depuración
y control de los procesos de trabajo, lo que se conoce como gestión por proce-
sos constituye una óptima estrategia de mejora de la calidad, puesto que sirve
para aumentar el rendimiento y la capacidad de las organizaciones. Por otro
lado, la gestión de procesos permite indagar de forma regular sobre la calidad
que percibe el cliente y las posibilidades de mejorar el servicio que recibe. A
continuación, se presenta a modo de ejemplo la representación del plan de la
calidad recomendado:

20
3

Figure 10: Tabla Extraı́da. Plan de Calidad

3
.
Prácticas de calidad:

• 25 horas semanales: cantidad de horas semanales que se pueden trabajar

para los programadores, esto es con el fin de mejorar el ánimo del equipo y
disminuir los errores que se pueden generar al producir frente a la presión
o cansancio, aumentando la productividad.
• Comunicación permanente con el cliente: comunicación perpetua o diaria
con cliente, se busca que el cliente este siempre al tanto de la evolución
e informar los cambios necesarios, permitiendo también que se preguntes
sobre cualquier duda de requerimientos de manera rápida.

Métricas de la calidad referenciadas al proyecto

1. Facilidad de auditoria
2. Exactitud
3. Normalización de las comunicaciones
4. Completitud
5. Concisión
6. Consistencia
7. Estandarización de los datos
8. Tolerancia de errores
3 https://es.slideshare.net/sergioalexis1994/planificacion-saha-copia-34781785

21
 9. Facilidad de expansión
10. Generalidad
11. Independencia del hardware
12. Instrumentación

Una de las principales amenazas encontradas para mantener la calidad de un

software, es el proceso de mantenimiento a través del cual se originan cambios
que pueden introducir errores o crear efectos laterales que propaguen errores. El
proceso de control de cambios contribuye directamente a mantener la calidad de
un programa al formalizar las peticiones de mantenimiento, evaluar la naturaleza
del cambio y controlar el impacto de éste en el resto del programa. Finalmente,
la medición de la calidad se fundamenta en las métricas, las cuales nos permiten
cuantificar y tener valores comparativos sobre el comportamiento y la eficiencia,
en el desarrollo de programas y sistemas para la organización.
Cronograma de actividades
Una vez se han estimado todos los paquetes de trabajo y se considera que
se tiene cubierto el cien por ciento del trabajo del proyecto y se ha definido el
recurso humano, se debe crear un cronograma real del proyecto que incluya los
responsables y el tiempo para cada actividad. Adicionalmente se recomienda
crear las actividades asociándolas con los paquetes de trabajo definidos. Es de
notar que este cronograma no es detallado, pues no se podrá conocer la ver-
dadera magnitud del proyecto sino hasta cuando se realice el diagnóstico y se
conozca el estado actual de los procesos, y por ende el esfuerzo a realizar. Se
recomienda utilizar un software que apoye el control de proyectos como MS
Project (preferiblemente integrada al Project Server para contar con la infor-
mación centralizada7) u otra herramienta para facilitar el control del crono-
grama y el avance. Al momento de realizar el cronograma se deben tener en
cuenta los 3 principales limitantes de todo proyecto:

1. Tiempo
2. Recursos
3. Alcance

El Cronograma de Actividades contiene el detalle de las actividades definidas

de acuerdo al requerimiento del usuario; es decir en base al Acta de Requerim-
iento; el responsable de elaborar este documento es el Desarrollador Lı́der con
el apoyo del Coordinador

En este documento deben considerarse los siguientes datos:

• Proyecto. - Indicar el proyecto al cual corresponde la actividad.

• Módulo. - Indicar el módulo al cual pertenece la actividad.

22
 • Nro. Requerimiento: Indica el número de requerimiento que da origen al
cronograma de actividades.
• Código de la Actividad. - Debe ser único en todo el documento; se re-
comienda utilizar este dato en los diálogos o consultas dentro del equipo
para facilitar la identificación de cada actividad.
• Estado. - Se deben manejar los siguientes estados: Sin empezar, En Pro-
greso, Terminado, Revisión, Cerrado.
• Descripción de la actividad. - Debe ser clara y precisa; evitar utilizar
palabras técnicas para que personas externas puedan entender lo que se
va a hacer.
• Desarrollador. - El nombre del desarrollador asignado a la actividad.
• Fecha de Inicio. - La fecha cuando se inicia el desarrollo de la actividad.
• Fecha de Término. - La fecha cuando se concluye la actividad.
• Etapa. - Para indicar en qué etapa se encuentra la actividad el cual debe
ser actualizado a lo largo del desarrollo.
• Nivel de dificultad. - Especificar el nivel de dificultad de la actividad de
acuerdo a: Simple, Media, Compleja.
• El nivel de dificultad es determinado en base a los criterios que establezca
el Desarrollador Lı́der basándose en su experiencia y la habilidad del de-
sarrollador.
• Prioridad. - Indicar el nivel de prioridad: Baja, Media, Alta.

Documentación

4 Es necesario especificar qué documentación se va generar durante cada etapa

del proceso; estos documentos deben realizarse de manera completa y usando
todos los valores de entrada y salida que se van generando, esto servirá para
recoger los resultados y tomar decisiones de las diferentes situaciones planteadas.
Por ejemplo; Actas de Reuniones, Formatos de Pruebas, etc.

Control y Evaluación: Las actividades de control y evaluación se deben de re-

alizar a lo largo de todas las fases para identificar errores y corregirlos a tiempo.
En resumen, consiste en realizar el seguimiento del avance de acuerdo al crono-
grama de trabajo; puede ser necesario tomar decisiones como el replanteamiento
de la planificación de las tareas asignadas para lograr los objetivos propuestos

4
.
4 https://issuu.com/rogeralfredogarridogarcia/docs/metodolog_as_de_desarrollo.

docx

23
 Documentos de Control

Los documentos de control evidencian el trabajo que se está haciendo en cada

una de las etapas del proceso de desarrollo; permiten realizar el seguimiento de
las actividades y establecen hitos en cada fase.

De acuerdo a la naturaleza de los requerimientos del usuario, se pueden uti-

lizar algunos o todos los documentos de control. Los documentos de control son
los siguientes:

1. Acta de Requerimiento
2. Formato de Resultados de Análisis de Requerimiento de Usuario

3. Formato de Conformidad de Cambios en Base de Datos

4. Cronograma de Actividades
5. Formato de Pruebas de Interfaces y Contenido
6. Formato de Validación de Requerimientos

7. Acta de Puesta en Producción

8. Acta de Cierre

Recordemos que La calidad involucra a todo el personal de la empresa; por lo

menos debe conocer el plan que se está llevando a cabo y el sitio y personas
a las cuales acudir para conocer más detalles. Adicionalmente, el personal que
participa en el proyecto tangencialmente deben conocer sus responsabilidades
y actividades, para dar cumplimiento a la calidad y los medios, herramientas y
formatos adecuados para dar fluidez al proceso de pruebas que se va a implantar.

24
7 Conclusiones
• Implementar el plan de calidad en un proceso de software apoyando cada
uno de los actores de cada proyecto y retroalimentando continuamente es
fundamental para el cumplimiento de los requerimientos funcionales y no
funcionales del cliente.
• Es de vital importancia que todos los actores del proceso conozcan y
apliquen las actividades, normas, procesos y procedimientos para garanti-
zar el cumplimiento de los requerimientos del cliente certificando la calidad
de los productos software, esto aplicando siempre todas las pruebas de cal-
idad de software necesarias para que con ellas se pueda ayudar a reducir
los riesgos en las aplicaciones, logrando que se identifiquen los defectos
antes de que se ejecuten, y de forma proactiva tomar decisiones en tiempo
real que permitan planear y ejecutar todas las actividades de mejora pre-
ventivamente y ofreciendo productos de alta calidad que cumplan con las
necesidades del cliente.
• Es importante que cada actor del proceso conozca y aplique lo necesario
de estas actividades, normas, proceso y procedimientos que garantizan el
cumplimiento de los requerimientos del cliente, asegurando de esta manera
la calidad de los productos software, siempre aplicarı́a esto en todas las
pruebas de calidad de software necesarias para que con ellas se pueda
ayudar a mermar los riesgos de las aplicaciones, permitiendo identificar
los defectos antes de que se puedan desarrollar y de esta manera tomar
decisiones de manera rápida.
• El proyecto de implantación CMMI dentro de una empresa es un proyecto
a mediano o largo plazo, sobre todo si la finalidad es conseguir niveles
altos de CMMI, la mayor razón es el cambio en el modo de trabajo y las
actividades del proyecto, estos son cambios estructurales, por lo cual no se
debe esperar que se consigan de manera coherente y correcta en un corto
plazo. Por este motivo es importante concienciar a los patrocinadores de
la magnitud del proyecto y puesto que se debe ser paciente, de esta manera
lograr que estos estén seguros con las actividades que se están realizando
la implementación de un modelo CMMI es de carácter organizacional lo
que de manera innata generara algunas resistencias que deberemos evitar
para esto y como se hace con los patrocinadores, es importante que los
empleados y participantes del proyecto sepan a ciencia cierta que se va a
desarrollar, hay que medir el riesgo y la cantidad de influencia de cada
persona sobre el proyecto para clarificar y hace un plan de entrega para
cada persona según sea su importancia en el mismo.
• Cualquier implementación de modelo es un proyecto a gran escala sobre
la empresa, sobre todo si esta no tiene un modelo previo, antes de la
implementación, es relevante hacer un cálculo de riesgos y no entregar
el mismo como algo extremadamente sencillo, sin olvidar el presupuesto
calculado y que todo lo que se hace debe tener un buen calculo.

25