Calidad de Software 5

1
Herramientas para la Productividad
Pruebas y Calidad de Software
Samuel D. Gamarra, Oscar D. Palacios, Diego F. Pinzón, Daniel F. Maldonado, Melissa
F. Zapata y Verónica A. Olaya
Politécnico Grancolombiano
GRUPO B01: Plan de Calidad Orientado a Pruebas
Avellaneda Vargas Margarita
Marzo 28, 2023

2
Tabla de Contenido
1 Objetivo General...................................................................................................................5
2 Objetivos Específicos...........................................................................................................6
3 Desarrollo de la actividad.....................................................................................................6
3.1 Descripción de la empresa:............................................................................................6
3.2 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,
luego determine los pro y contras de cada uno respecto al esfuerzo, tiempo, costos y
beneficios..................................................................................................................................7
Nota. Descripción, ventajas, desventajas de los diversos modelos de calidad.........................9
3.3 Matriz DOFA:...............................................................................................................9
Nota. Fortaleza, Debilidades, Oportunidades, Amenazas DOFA............................................9
Nota. Fortalezas, Debilidades de Estrategias DOFA.............................................................10
3.4 Establezca varios criterios que le permitan validar el estado de la empresa (puede
tomar las KPA del modelo CMM u otros que considere afecten su decisión) frente a cada
modelo y los elementos que describió. Indique los dos modelos que considere más adecudos
para lograr la calidad en los productos de software que su empresa desarrolla ya sean
internos o externos..................................................................................................................10
3.5 Tabla de actividades del ciclo de vida de software.....................................................12
Nota. Procesos, procedimientos y actividades de las etapas..................................................14
4 Desarrollo de trabajo...........................................................................................................15
4.1 Estrategia e hilo conductor en la implementación de los procesos de calidad............15
4.2 Medios de Comunicación............................................................................................18
4.3 Reuniones de Control..................................................................................................21
4.4 Métricas.......................................................................................................................22
4.5 Políticas.......................................................................................................................23
4.6 Responsables y Roles..................................................................................................23
4.7 Esquema de informes de cambio.................................................................................25
4.8 Responsabilidades y actividades de las personas involucradas en el proyecto...........25
5 Bibliografía.........................................................................................................................34
3
Lista de Tablas
Tabla 1.............................................................................................................................................7
Tabla 2.............................................................................................................................................9
Tabla 3...........................................................................................................................................10
Tabla 4...........................................................................................................................................12
4
Lista de Figuras
Figura 1..........................................................................................................................................15
5
1 Objetivo General
Establecer una estrategia clara y detallada para diseñar, construir e implementar un
sistema de software que cumpla con los requisitos y expectativas de los usuarios y la
organización. La finalidad de este plan es lograr la satisfacción del cliente y el éxito del proyecto,
entregando un software de alta calidad, eficiente y seguro que sea fácilmente mantenible a largo
plazo.
Para lograr este objetivo, el plan de desarrollo de software debe incluye una descripción
detallada de los requisitos del sistema, identificando los objetivos y las funcionalidades
necesarias para cumplir con los requerimientos del negocio y los usuarios. Además, se deben
establecer las metodologías de desarrollo a utilizar, las técnicas de programación avanzadas y las
mejores prácticas de la industria para garantizar la calidad del código y la eficiencia del proceso
de desarrollo.
El equipo de desarrollo debe estar integrado por profesionales altamente capacitados, con
experiencia en el desarrollo de software, que estén comprometidos con la visión y objetivos del
proyecto. Asimismo, se deben establecer plazos de entrega y un presupuesto detallado para
asegurar la eficiencia del proceso y la rentabilidad del proyecto.
El plan de desarrollo de software también debe incluir una estrategia de pruebas
rigurosas, utilizando las mejores prácticas para garantizar la calidad del software y la eliminación
6
de errores. La documentación adecuada del código y la revisión por pares son elementos
esenciales para asegurar la calidad y la mantenibilidad del software a largo plazo.
Por último, es importante establecer medidas de seguridad para proteger el software
contra posibles amenazas y vulnerabilidades. Se deben implementar buenas prácticas de
seguridad en todo el proceso de desarrollo para asegurar la integridad y privacidad de la
información, garantizando la confidencialidad y disponibilidad del sistema.
2 Objetivos Específicos
1. Descripción de la empresa.
2. Describir los diferentes modelos de calidad, luego realizar una comparativa de
modelos, puede establecer algunos criterios aplicados a cada modelo que permitan darle una
evaluación cualitativa o cuantitativa. A partir de esta evaluación escoger el modelo adecuado
para la empresa.
3. Análisis DOFA de la empresa con los datos tomados en las entrevistas.
4. Plantear los dos modelos que más se ajusten para implementar en la empresa y lograrla
calidad en los productos de software.
5. Construcción de tabla de actividades, procesos, procedimientos, plan de pruebas del
ciclo de vida del software.
3 Desarrollo de la actividad

3.1 Descripción de la empresa:
7
Se trata de una empresa que pertenece al sector de tecnología, específicamente a
desarrollo de software para empresas del sector público y privado. Es de tamaño mediano y
cuenta con 15 años en el mercado, pero hasta ahora no cuenta con misión y visión. Tiene 2.200
empleados en ciudades como Bogotá, Cali, Medellín y Cartagena y actualmente tiene clientes en
14 ciudades principales del País.
Se estima que la empresa crezca en los próximos 5 años y llegue a mercados
internacionales. La empresa posee área de tecnología, contabilidad, finanzas, administración,
tesorería y activos fijos. La empresa cuenta con procesos logísticos claramente establecidos, con
funciones, tiempos y seguimiento para la recepción, alistamiento y despacho de pedidos.
Además, tiene una buena organización para el almacenamiento de inventario, mantenimiento del
stock y la distribución de las instalaciones, generando una utilización optima del espacio y sus
activos representados en vehículos propios, que pueden apoyar las necesidades que se presenten
por parte del cliente en las zonas de Bogotá, la sabana de occidente e Ibagué. Se detectaron
falencias en el seguimiento efectivo a las funciones que realiza el personal hacia los clientes
potenciales, determinando en que grado se generó un impacto positivo o negativo y cuántos de
ellos actualmente se han convertido en clientes de la organización, así como investigaciones y
planteamiento de estrategias para aumentar su cuota de mercado.
3.2 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, luego determine los pro y contras de cada uno respecto al esfuerzo, tiempo, costos
y beneficios.
Tabla 1
8
Diversos Modelos de Calidad
Modelo Descripción Ventajas Desventajas

CMMI Consiste en una herramienta de - Reducción del coste de - Falta de adecuación al
mejora de procesos que ayuda a desarrollo. enfoque al servicio que
las organizaciones a optimizar la - Localización y está experimentando el
mejora de procesos, fomentando resolución de defectos. sector de las TIC.
una cultura productiva y eficiente - Mejora en la fiabilidad - El proceso de
que reduce los riesgos en el de la planificación, en evaluación es muy
desarrollo de software, términos de dedicación y costoso en tiempo y
productos y servicios. calendario. esfuerzo
-Aumento de la - La complejidad de la
productividad. evaluación puede
atentar contra la
definición de objetos
concretos de madurez
PSP El PSP es un proceso definido - Mejora la - Tensión emocional por
para ayudar a realizar mejor el productividad de las sentirse controlado.
trabajo, cuyo objetivo es obtener personas implicadas al - Manejo del tiempo al
y reportar datos precisos y desarrollo del software. hacer el registro de los
completos del trabajo que se - Se reducen los errores tiempos
realiza a nivel individual, con el en la codificación.
fin de mejorar el proceso - Se lleva un mejor
individual, afectando de esta control del trabajo
manera al desempeño de todo el individual.
equipo - Facilita la identificación
de las fortalezas y las
falencias para entrar a
mejorarlas.
TSP Es un modelo de referencia de - Eleva la calidad de los - Los miembros debe
ingeniería de software que proyectos tener el compromiso, la
provee un énfasis en los - Ayuda a las disciplina de seguir el
procesos, los productos y el organizaciones a plan.
trabajo en equipo. El TSP toma establecer una práctica - Debe de llenar toda la
de base los principios de PSP da la ingeniería madura y documentación
para realizar los procesos y disciplinada. requerimiento.
principios de ingeniería de - Reduce el número de - Se debe de contar con
software en un ambiente de los defectos. un buen conjunto de
trabajo en equipo. - Reducción en los costos métricas y parámetros
de pruebas y de los de calidad.
tiempos - Cada miembro debe de
estar entrenado en el
PSP.
FURPS Es un modelo de calidad fijo - Los criterios son - Se necesita de
propuesto por Hewlett Packard y claramente entendibles, muestras métricas lo que
Robert Grady (1987) el cual esto implica su fácil implica un mayor
incluye, además de los factores utilización. esfuerzo de tiempo y
9
de calidad y el atributo, - Tiene en cuenta las costo.

restricciones de diseño y fallas en el producto y en
requerimientos de el proceso esto permite
implementación, físicos y de una mayor corrección.
interfaz. Se podría utilizar no para
una sino para varios
proyectos.
BOEHM Este se basa en que el software - Presenta un rango alto - Genera mucho tiempo
debe hacer lo que el usuario de características el análisis.
quiere que haga, por lo tanto, se primitivas. - Es un modelo costoso.
espera que el software: - Une los mejores - Funciona mejor en
- Utilice los recursos del elementos de otros grandes proyectos.
computador correcta y modelos. - Se trabaja siguiendo un
eficientemente. - Integra el desarrollo del protocolo y debe ser
- Sea fácil de usar y de aprender software con el seguido estrictamente
para los usuarios. mantenimiento. para un buen
- Estar bien diseñado, codificado - Es el segundo modelo funcionamiento.
y ser probado y mantenido de calidad más conocido.
fácilmente.
Nota. Descripción, ventajas, desventajas de los diversos modelos de calidad.
3.3 Matriz DOFA:
Tabla 2
Cuadro DOFA
Nota. Fortaleza, Debilidades, Oportunidades, Amenazas DOFA

10
3.3.1 Propuesta de mejora DOFA:
Tabla 3
Estrategias DOFA
Estrategias DOFA Fortalezas Debilidades
F1O2 Diseñar planes logísticos que permitan
D5O1 Implementar una estrategia financiera a largo
ampliar la entrega a productos a los hogares del
plazo que permita maximizar los beneficios de la
país, asegurando cumplimiento de los tiempos y un
compañía en el tiempo
costo mínimo de transporte
F3O5 Establecer una planeación financiera y
D2O2 Formular estrategias de marketing para la
tributaria que permita aprovechar los beneficios que
obtención de nuevos clientes, a través de
otorga el estado para disminuir la carga impositiva
promociones, posicionamiento en redes, y otras.
y maximizar las utilidades
Oportunidades
F5O4 Buscar nuevas alianzas que permitan D4O1 Negociar disminución de tasas de interés o
posicionar a la marca a través del profesionalismo y diferentes estrategias de crédito que permitan bajar
capacidad técnica de sus empleados, lo cual pueda el endeudamiento y asegurar un menor pago de
asegurar negocios futuros intereses
F5O3 Asegurar la prestación de un excelente
servicio con las nuevas empresas que contraten a la
compañía, de tal manera que se puedan crear
relaciones de largo plazo
D5A1A3 Establecer indicadores que permitan
F5A4 Establecer planes de retención de personal,
medir el riesgo máximo que está dispuesto a asumir
los cuales incluyan beneficios extralegales, salario
la compañía, de tal manera que si se alcanzan
emocional, beneficios a la salud, tiempo libre, entre
dichos escenarios los socios decidan si la compañía
otros.
puede seguir o no.
F5A5 Crear un grupo de investigación de nuevos D3D4A5 Diseñar un plan de actualización de
avances y tecnologías, el cual establezca un plan de equipos el cual no afecte o empeore el
capacitación para mantener a un equipo endeudamiento actual, ya sea a través de
competitivo, y recomendaciones para implementar arrendamientos financieros o compra de equipos
Amenazas nuevos procesos en la compañía. usados en buen estado.
F3A3 Establecer planes financieros que permitan
disminuir el riesgo ante variaciones en el mercado,
tales como tasa de cambio, índices bursátiles,
precio de materias primas, entre otros.
F3A1 Designar un equipo de trabajo encargado de
la investigación de posibles cambios tributarios y su
impacto en la compañía, de tal manera que se
puedan anticipar sus efectos y diseñar estrategias
para contrarrestarlos
Nota. Fortalezas, Debilidades de Estrategias DOFA.
3.4 Establezca varios criterios que le permitan validar el estado de la empresa (puede
tomar las KPA del modelo CMM u otros que considere afecten su decisión) frente a
cada modelo y los elementos que describió. 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.
Para validar el estado de la empresa en términos de calidad de software, se pueden
utilizar varios criterios. A continuación, se presentan algunos ejemplos:

11
1. Cumplimiento de los requisitos: La empresa debe asegurarse de que los productos de
software cumplen con los requisitos establecidos por los clientes y usuarios. Se puede medir el
grado de cumplimiento a través de pruebas de aceptación y retroalimentación de los usuarios.
2. Estabilidad y confiabilidad: Los productos de software deben ser estables y confiables,
evitando errores y fallas. Se puede medir la estabilidad y confiabilidad a través de pruebas de
rendimiento, pruebas de estabilidad y seguimiento de incidencias.
3. Mantenibilidad: El software debe ser fácil de mantener y actualizar. Se puede medir la
mantenibilidad a través de pruebas de mantenimiento y actualización, así como evaluando la
calidad de la documentación y el código.
4. Eficiencia y rendimiento: El software debe ser eficiente y tener un buen rendimiento,
evitando la sobrecarga de recursos del sistema. Se puede medir la eficiencia y el rendimiento a
través de pruebas de carga y evaluando el diseño y la implementación del software.
5. Seguridad: El software debe ser seguro, protegiendo la información y los sistemas
contra posibles amenazas y vulnerabilidades. Se puede medir la seguridad a través de pruebas de
seguridad y evaluando la implementación de buenas prácticas de seguridad.
En cuanto a los modelos más adecuados para lograr la calidad en los productos de
software, dos opciones podrían ser:
1. Modelo de madurez de capacidad de integración (CMMI): Este modelo proporciona un
marco para la mejora continua de procesos de software, ayudando a las empresas a identificar
áreas de mejora y establecer objetivos y metas para lograr la calidad en los productos de
software.
12
2. ISO/IEC 12207: Este estándar internacional establece los procesos para el ciclo de vida
del software, desde la adquisición hasta la retirada, lo que ayuda a las empresas a establecer
procesos estandarizados para asegurar la calidad del software en cada etapa del ciclo de vida.
En resumen, para validar el estado de la empresa en términos de calidad de software se
pueden utilizar varios criterios como el cumplimiento de los requisitos, estabilidad y
confiabilidad, mantenibilidad, eficiencia y rendimiento, y seguridad. Los modelos más
adecuados para lograr la calidad en los productos de software podrían ser el modelo de madurez
de capacidad de integración (CMMI) y el estándar internacional ISO/IEC 12207.
3.5 Tabla de actividades del ciclo de vida de software.
El software “vivo” evoluciona…
Teniendo en cuenta el ciclo de vida del Software el cual podría ser flexible a cambios
según el framework con el cual se implemente, para este caso hemos optado por alinearnos y
tener en cuenta el maro de trabajo DevOps en donde cómo su nombre lo indica es la unificación
del desarrollo y operaciones de una manera ágil para aumentar la entrega de valor continua a los
clientes finales.
Las actividades marcadas en color anaranjado harán parte de la propuesta de
implementación de un correcto ciclo de pruebas, esto teniendo siempre en cuenta el plan de
pruebas que se construyó en la planeación.
Tabla 4
Etapas vida del software
Etapas Procesos/Procedimientos/Actividades
13
Definición de los valores empresariales ¿Quiénes somos?, ¿Qué hacemos?, ¿Por

qué lo hacemos?, ¿Cuál es nuestro valor agregado?, ¿Cuáles es nuestra visión y
misión?
Identificación de los requerimientos de todos los interesados (Funcionales y no

funcionales). ¿Qué quieren? ¿Qué resultados esperan? ¿En cuánto tiempo
planean obtener el ROI?
Planeación Definición del BugTracker a usar y los ANS (Acuerdos a nivel de servicio) para la
solución de los bugs que se encuentren
Elaboración del Testplan.
Definición de tiempos estimados para las entregas, Creación de diagnóstico,

oportunidades de mejora y estrategia a implementar para realizar la
construcción del software, por último, validación de métricas o estadísticas que
permitan validar que el software va por buen camino.
Creación de la arquitectura de la aplicación. Teniendo en cuenta la definición de

la planeación (Nube o Onpremise)
Diseño de MocksUps del front de la aplicación

Diseño Diseño del esquema de base de datos a implementar.
Diseño y refactorización de casos de uso. (Se realizan pruebas de

requerimientos dado que los casos se crean basándose en los objetivos y
condiciones del escenario.)
Codificación de los módulos y las funcionalidades de la aplicación
Definición y uso de los IDE's para la codificación del código de una manera más
rápida.
Realizar pruebas unitarias en el código.
Desarrollo Realizar pruebas de integración manuales o automatizadas que permitan validar

que las funcionalidades criticas mínimas del sistema funcionan después de cada
despliegue. (Mejor practica es automatizar las pruebas)
Realizar pruebas tempranas "Levantar el front en local, Levantar el

microservicio en local, construir los scripts de pruebas automatizadas", todo
esto para que el costo de solución de bugs sea menor.
14
Implementar Quality Gates que impidan un despliegue a ambientes si este no

cumple con los mínimos estándares de calidad en cuanto a codificación y
funcionalidad.
Implementación de Continuos testing dentro del ciclo de vida del software

(Puede ser manuales o automatizadas, pero preferiblemente automatizadas)
Vincular el proceso de continuos testing dentro del flujo del despliegue

continuo, es decir no se podrá desplegar sin que se hayan ejecutado las pruebas
exitosamente.
Implementación - Realizar junto con los interesados las pruebas UAT para validar su satisfacción
Pruebas con el producto construido
Realizar pruebas no funcionales, tales como pruebas de ciberseguridad y
performance.
Entregar informe de resultados de pruebas, dando el visto bueno para al

despliegue en producción. Se deben contemplar los riesgos y posibles bugs que
no han sido solucionados.
Se realizan pruebas exploratorias en producción, A pesar de que esto no es

demasiado común, debería tenerse la manera de realizar pruebas, dado que
existe el error humano, en donde por falta de una parametrización, variable,
configuración o gestión de ambiente. El sistema se puede comportar de una
manera no adecuada.
Mantenimiento Se deben monitorear el comportamiento de la iniciativa en producción para

validar los posibles errores desde el servidor que puedan existir, esto con
herramientas cómo Grafana, Dynatrace, CloudWatch o DataLog, E.TC.
El equipo funcional debe contar con herramientas tales como Google Tag
Manager o Algún formulario de satisfacción del cliente para recolectar las
oportunidades de mejora, errores o inconformidades por parte del usuario
final.
Nota. Procesos, procedimientos y actividades de las etapas.
Como se evidencia en la tabla anterior, el objetivo es velar por la adopción de las pruebas
tempranas para el ciclo de vida del software, esto trayendo como beneficios, reducción de
tiempos, Cumplimiento de la planeación, Menor impacto al existir incidentes, Más económica la

15
solución de los bugs y un acercamiento al proyecto desde etapas de planeación para obtener un
mayor contexto de lo que se requiere y así diseñar unas pruebas con una cobertura mayor.
4 Desarrollo de trabajo
4.1 Estrategia e hilo conductor en la implementación de los procesos de calidad
4.1.1 Aspectos importantes y críticos del producto y proyecto.
Hay involucramiento por parte de los usuarios.
Se cuenta con el apoyo por parte de la alta gerencia.
Hay sentido de pertenencia al proyecto.
Hay un equipo comprometido y disciplinado.
Hay buena comunicación.
El proyecto tiene claramente definida su misión.
El proyecto logra el propósito del negocio.
Se encuentra disponible la tecnología y los conocimientos adecuados.
4.1.2 Objetivo.
Identificar las falencias existentes con el fin de mejorar y optimizar un software con
calidad y eficiencia, para minimizar fallas e inconvenientes al momento de realizar pruebas de
implementación.
4.1.3 Cronograma.
Para la presentación del plan de trabajo, se emplearán Diagramas de GANTT. Su
objetivo es mostrar gráficamente las tareas y avances, durante todo el proceso desde el inicio
hasta su culminación, mostrando la forma como las distintas tareas están encadenadas entre
sí.
Figura 1
16
Cronograma de Actividades
Nota. Cronograma de actividades, inicio del plan, duración del plan, inicio real, duración
real, porcentaje completado y periodos.
4.1.4 Presupuesto.
17
El presupuesto necesario se limita más que nada a personal de desarrollo, se cuenta
con unos cuantos para el desarrollo de pruebas por lo que los desarrolladores deben
garantizar las pruebas unitarias con el documento antes mencionado
Cuantificación de necesidades y fechas de incorporación de recursos.
Obtener un patrón que marque los alcances del proyecto. Teniendo en cuenta las
siguientes operaciones:
Establecer el esfuerzo en semanas(con decimales).
Deducir la parte correspondiente a diseño funcional, ya que es una fase con un tipo de
actividades diferentes al resto.
Establecer la duración en semanas (con decimales). Normalmente este dato se
conocerá por el compromiso adquirido.
Deducir la duración correspondiente al diseño funcional.
Considerar que todo proyecto tiene tres situaciones claramente
diferenciadas(Arranque, Pleno Rendimiento, Finalización).
Distribución de recursos.
Considerar la capacidad, los conocimientos y la experiencia de cada recurso.
Considerar la complejidad, el tamaño y los requerimientos técnicos de cada tarea.
Asignar tareas sencilla a recursos con poca experiencia; para que los recursos con
poca experiencia no hagan perder el tiempo preguntando continuamente al resto del Equipo
con más experiencia.
Entre otros.
18
4.1.5 Actividades.
Organizadas por orden jerárquico, son las siguientes:
Capacitación para mejorar ambiente organizacional para que los desarrolladores
puedan llenar el documento correctamente.
Cada QA estará encargado de un grupo de no más de 6 desarrolladores este
supervisará cada uno de los documentos y validará que se encuentren incidencias ya que este
es el propósito del documento.
Creación del plan de incentivo por cumplimiento para el área de desarrollo, atacando
el tema de encontrar incidencias en cada desarrollo presentado y documentando.
4.2 Medios de Comunicación
Se usarán aplicaciones para la gestión de tareas como Trello, la comunicación se
manejará por grupos de desarrollo, estos se comunicarán a través de la herramienta Slack.
4.2.1 Roles Involucrados en el Proceso de Pruebas
En el modelo de comunicación participan los siguientes roles:
Coordinador del Proyecto
Líder del Proyecto del Cliente
Analista de Calidad
Desarrollo
4.2.2 Casos de Interacción de los Roles

19
A continuación, se nombran las actividades y artefactos en las cuales interactúan los
diferentes roles:
4.2.3 Casos de Interacción, Actividades de los Roles Project Director
 Implementar cambios que resulten en mejoras en la eficiencia y competitividad
del proyecto.
 Comunicación efectiva con el equipo
 Disposición y decisión en actividades que requieren de su autoridad, tanto para
el equipo PROVEEDOR, como para la CLIENTE
 Actividades relacionadas con el contrato CLIENTE
 Supervisión de tareas
 Resolutor de temas que le sean escalados
 Contextualización y alineación de la metodología
 Convoca y asiste a reuniones
 Análisis y evaluación de informes
 Análisis de métricas
 Gestión transversal
4.2.4 Casos de Interacción, Actividades de los Roles Analista líder de Calidad

20
 Propone cambios que resulten en mejoras en la eficiencia y competitividad del
proyecto.
 Escala los temas a quien tiene la autoridad para tomar decisiones.
 Convoca y asiste a reuniones
 Socializa las directrices emitidas por el Project manager o el cliente
 Rendición de informes solicitados por parte del Project manager o el cliente
 Contextualización de aplicaciones
 Estrategia de pruebas
 Informes de avance
 Casos de prueba
 Cierre del proyecto
4.2.5 Casos de Interacción, Actividades de los Roles Analista de Calidad de
Software
21
 Propone cambios que resulten en mejoras en la eficiencia y competitividad del
proyecto.
 Escala los temas a quien tiene la autoridad para tomar decisiones.
 Contextualización de aplicaciones
 Estrategia de pruebas
 Informes de avance
 Casos de prueba
 Cierre del proyecto
4.2.6 Casos de Interacción, Actividades de los Roles Desarrollo
 Contextualización de Aplicaciones
 Gestión de Incidencias (Solución de Incidencias)
 Realización de documento con pruebas unitarias.
4.3 Reuniones de Control
4.3.1 Reuniones de seguimiento de casos de prueba: el equipo de pruebas debe
reunirse regularmente para revisar el progreso de los casos de prueba en curso,
identificar y solucionar problemas, y actualizar la documentación de las pruebas.
4.3.2 Reuniones de revisión de requisitos: el equipo de pruebas debe reunirse con los
analistas de negocios y otros miembros del equipo para revisar los requisitos y
especificaciones del software y asegurarse de que se están probando los aspectos
más importantes.
22
4.3.3 Reuniones de resolución de problemas: cuando surgen problemas o errores
durante las pruebas, el equipo de pruebas debe reunirse para analizar los
problemas y trabajar juntos para resolverlos.
4.3.4 Reuniones de retroalimentación del equipo: el equipo de pruebas debe
reunirse regularmente para compartir feedback y discutir formas de mejorar la
eficacia y eficiencia de la etapa de desarrollo del ciclo de pruebas.
4.4 Métricas
4.4.1 Cobertura de pruebas: Esta métrica mide la cantidad de código fuente que ha
sido probado por los casos de prueba. La cobertura de pruebas puede ser medida en
términos de líneas de código o de porcentaje de código probado.
4.4.2 Defectos encontrados: Esta métrica mide la cantidad de errores o defectos que
se han encontrado durante las pruebas. Es importante mantener un registro
detallado de los defectos encontrados para poder analizar y corregirlos
posteriormente.
4.4.3 Tiempo dedicado a pruebas: Esta métrica mide la cantidad de tiempo que el
equipo de pruebas ha dedicado a la etapa de desarrollo del ciclo de pruebas. Esto
puede ayudar a identificar posibles cuellos de botella o problemas de eficiencia.
4.4.4 Tiempo medio de resolución de defectos: Esta métrica mide el tiempo
promedio que se tarda en corregir un defecto después de que se ha identificado.
Una tasa alta de resolución de defectos puede ser un indicador de una buena
eficacia en la corrección de errores.
4.4.5 Calidad de los casos de prueba: Esta métrica mide la efectividad de los casos
de prueba diseñados en la etapa de planificación. Si los casos de prueba no son

23
eficaces, entonces el equipo de pruebas podría estar perdiendo tiempo y recursos
valiosos.
4.5 Políticas
4.6 Responsables y Roles
4.6.1 Responsable de pruebas:
La persona encargada de liderar y coordinar la etapa de desarrollo del ciclo de
pruebas. Es responsable de asegurarse de que las pruebas se lleven a cabo de acuerdo con el
plan de pruebas y de que se cumplan los objetivos y metas establecidos.
4.6.2 Ingeniero de pruebas:
El ingeniero de pruebas es responsable de diseñar y ejecutar los casos de prueba,
desarrollar scripts de prueba y hacer un seguimiento de los resultados de las pruebas.
También debe asegurarse de que se realice una depuración adecuada de los errores y de que
se lleve a cabo el retesteo necesario.
4.6.3 Desarrollador de software:
El desarrollador de software es responsable de desarrollar y mantener el software, y de
colaborar con el ingeniero de pruebas para asegurarse de que se cumplan los requisitos y
especificaciones definidos. Además, debe corregir los errores encontrados durante las pruebas
y proporcionar soporte adicional si es necesario.
4.6.4 Analista de negocio:

24
El analista de negocio es responsable de definir los requisitos y especificaciones del
software, lo que ayuda al ingeniero de pruebas a desarrollar los casos de prueba necesarios.
También deben estar disponibles para responder preguntas y proporcionar información
adicional durante la etapa de desarrollo de pruebas.
4.6.5 Ingeniero de pruebas:
es responsable de diseñar, crear y ejecutar casos de prueba para evaluar el software y
verificar que cumpla con los requisitos y especificaciones definidos. Además, deben
asegurarse de que se registren los resultados de las pruebas, reportar y rastrear errores
encontrados, y trabajar con otros miembros del equipo para corregirlos.
4.6.6 Desarrollador de software:
es responsable de desarrollar el software y trabajar con el ingeniero de pruebas para
asegurarse de que se cumplan los requisitos y especificaciones definidos. También deben
corregir los errores encontrados durante las pruebas y proporcionar soporte adicional si es
necesario.
4.6.7 Líder de equipo de pruebas:
es responsable de coordinar y supervisar el trabajo de los ingenieros de pruebas y otros
miembros del equipo de pruebas. También es responsable de asegurarse de que se cumplan los
objetivos y metas establecidos en la etapa de planificación del ciclo de pruebas.
4.6.8 Gerente de proyecto:

25
es responsable de supervisar el ciclo de pruebas en su totalidad y garantizar que se
cumplan los objetivos y metas del proyecto. Además, deben garantizar que se asignen los
recursos adecuados para la etapa de desarrollo del ciclo de pruebas y que se cumpla con el
presupuesto y el cronograma establecidos.
4.6.9 Analista de negocios:
es responsable de definir los requisitos y especificaciones del software, lo que ayuda al
ingeniero de pruebas a desarrollar los casos de prueba necesarios. También deben estar
disponibles para responder preguntas y proporcionar información adicional durante la etapa
de desarrollo de pruebas.
4.7 Esquema de informes de cambio
4.8 Responsabilidades y actividades de las personas involucradas en el proyecto
4.8.1 Administrador del proyecto

26
El administrador de proyecto es la persona que administra y controla los recursos
asignados a un proyecto. Los recursos asignados pueden ser recursos humanos, económicos,
tecnológicos, espacio físico, etc. En un proyecto, siempre debe existir un administrador. No
obstante, un administrador puede dirigir más de un proyecto. El administrador no es dueño de
nada, es sólo un administrador temporal de los recursos. Como no es dueño de nada, debe
dejarlos en la misma o mejor condición de cómo los recibió. Por ello, el foco de una buena
administración debe estar en el control y coordinación de los diferentes eventos y actividades
de un proyecto. Adicionalmente, deben crearse las mejores condiciones posibles para que se
realicen las actividades. Una de las preocupaciones principales para los administradores debe
ser el tener una visión y misión claras del proyecto, trabajando para que ambas se cumplan.
En otras palabras, el foco de un administrador de proyecto debe estar en el bosque más que en
los árboles. Sin embargo, debe cuidar cada árbol ya que cada uno de ellos contribuye al
bosque. El rol de administrador de proyecto es un rol muy importante, debido a que sus
acciones y decisiones afectan al proyecto completo.
4.8.2 Plan de trabajo Administrador del proyecto

27
A continuación, se mencionan algunas de las actividades a realizar por el
administrador de proyecto, que forman parte de su plan de trabajo.
• Definir y establecer estándares a seguir por el grupo.
• Definir una estructura organizacional y hacer un diagrama organizacional.
• Capacitar al grupo en las metodologías y estándares a utilizar.
• Crear un modelo de ciclo de vida para el proyecto.
• Definir un plan y protocolo para desarrollo de reuniones.
• Definir una agenda de reuniones con cada rol.
• Construir un plan de trabajo específico que contenga diagramas Gantt y de flujo de
actividades. • Definir protocolos para asignar y evaluar actividades. Nótese que, durante el
proyecto, será necesario redefinir tareas, y con ello, miembros del equipo deberán alterar su
carga de trabajo para realizarlas.
• Realizar estimación de horas-hombre por actividad y por persona.
• Realizar reuniones generales para evaluación y planificación.
• Realizar un contrato con el cliente que defina las características y condiciones en que
se desarrollará el producto.
4.8.3 Analista
28
La palabra “análisis” se refiere a una característica típicamente relacionada con la
inteligencia humana. Esta se refiere a la habilidad de poder estudiar un problema de una
complejidad determinada, descomponiendo el problema en subproblemas de menor
complejidad. De esa forma, la solución del problema completo se obtiene como la suma de las
soluciones de los subproblemas de menor complejidad. Lo anterior indica que la fase de
análisis en un proyecto de construcción de software se refiere a la especificación de un
problema como la suma de subproblemas de menor complejidad. Como el experto en el
problema es el cliente, se hace necesario trabajar junto a él para realizar la especificación
correctamente. Los miembros del grupo que trabajan con el cliente para realizar el análisis y
especificación del sistema a construir son precisamente los analistas. Para que el trabajo de
los analistas tenga sentido para todos los integrantes del grupo, se hace necesario ponerse de
acuerdo en la forma como se realizará la especificación, así como la forma como el resto del
grupo la entenderá. Esto sugiere el uso de un estándar para realizar la fase de análisis del
problema. En el caso del estándar de la ESA, el análisis se divide en dos fases: especificación
de requisitos de usuario y especificación de requisitos de software. Los analistas deben liderar
ambas fases. Una de las razones más frecuentes del fracaso de un desarrollo de software es la
de realizar un análisis pobre. Debido al insuficiente esfuerzo dedicado a conocer y especificar
el sistema que desea el cliente, los desarrolladores construyen sistemas que no cuentan con las
características que el cliente desea. Ese error se repite una y otra vez, y se debe básicamente a
la inexperiencia del grupo de desarrolladores
4.8.4 Plan de trabajo Analista

29
A continuación, se menciona algunas de las actividades a realizar por los analistas, las
que forman parte de su plan de trabajo.
• Preparar un documento con preguntas a realizar al cliente durante las entrevistas.
• Determinar las fechas de reunión con el cliente.
• Generar un documento de especificación de requisitos de usuario en base a los
acuerdos alcanzados en la primera reunión.
• Presentación del documento de especificación al cliente en la siguiente reunión.
• De ser necesario, realizar las modificaciones al documento de especificación de
requisitos de usuario y presentarlas al cliente en la próxima reunión. Repetir esta actividad las
veces que sea necesario.
• Estudiar la metodología de diseño.
• Explorar las herramientas CASE a utilizar.
• Generar los diagramas de arquitectura.
• Revisar los diagramas de arquitectura con los diseñadores.
• De ser necesario, realizar las modificaciones a los diagramas.
• Presentar los diagramas de arquitectura finales.
• Construir el documento de requisitos de software.
• Revisar el documento con los ingenieros de aseguramiento de la calidad y cliente,
realizando modificaciones de ser necesario.
4.8.5 Diseñadores
30
Es el encargado de generar el diseño del sistema. Entre sus funciones está:
• Generar el diseño arquitectónico y diseño detallado del sistema, basándose en los
requisitos.
• Generar prototipos rápidos del sistema (con analistas y programadores) para
chequear los requisitos.
• Generar el documento de diseño arquitectónico de software (DDA), y mantenerlo
actualizado durante el proyecto.
• Velar porque el producto final se ajuste al diseño realizado (funciones de téster).
En cada disciplina de la ingeniería, el diseño acompaña el enfoque disciplinado que se
utiliza para inventar la solución de un problema, entregando así un camino entre los
requisitos y la implementación. En ingeniería de software, el propósito del diseño es la
construcción de un sistema que cumpla con los siguientes aspectos:
• Satisfaga una especificación funcional dada.
• Cumpla con las limitaciones del medio receptor del sistema.
• Cumpla requisitos implícitos y explícitos de rendimiento y uso de recursos.
• Satisfaga criterios de diseño implícitos y explícitos en la forma del artefacto
construido.
• Satisfaga restricciones del mismo proceso de diseño, tal como su duración y costo, o
las herramientas disponibles para realizar el diseño.
4.8.6 Plan de trabajo Diseñadores

31
El plan de trabajo de los diseñadores incluye las siguientes actividades para el diseño
del sistema.
• Organizar el sistema en subsistemas.
• Identificar concurrencias inherentes al problema.
• Asignar los subsistemas a procesos y tareas.
• Seleccionar un administrador de datos.
• Identificar recursos globales y determinar mecanismos de acceso.
• Elegir un enfoque para implementar el control de la ejecución.
• Considerar condiciones de borde.
4.8.7 Programadores
Los programadores deben convertir la especificación del sistema en código fuente
ejecutable utilizando uno o más lenguajes de programación, así como herramientas de
software de apoyo a la programación. El éxito del desarrollo de software depende
grandemente de conocimiento. Este conocimiento no sólo corresponde a habilidades de
programación y de administración de proyectos, sino que a una percepción y entendimiento de
los últimos desarrollos de la industria del software. En los mercados actuales, rápidamente
cambiantes y altamente competitivos, se hace necesario conocer los últimos desarrollos, quien
da soporte, y como pueden beneficiar al proyecto y a la organización. A través de este
conocimiento es que la organización genera un camino hacia el éxito futuro.
4.8.8 Plan de trabajo Programadores

32
El plan de trabajo de los programadores debe contener, al menos, las siguientes
actividades:
• Explorar los diferentes ambientes de desarrollo.
• Explorar los diferentes lenguajes disponibles para el ambiente.
• Explorar las diferentes herramientas de desarrollo (compiladores, bases de datos,
depuradores, etc.) disponibles para el lenguaje seleccionado.
• Explorar sistemas ya construidos de los cuales, el nuevo sistema será parte.
• Elegir el estilo de programación.
• Programar las herramientas utilitarias y rutinas comunes.
• Codificar y depurar.
• Testear.
• Realizar revisiones personales y reuniones.
• Escribir la documentación técnica.
4.8.9 Tester
El desarrollo de un sistema de software requiere la realización de una serie de
actividades de producción. En dichas actividades existe la posibilidad de que aparezcan
errores humanos. Dichos errores pueden empezar a aparecer desde el primer momento del
proceso. Por ejemplo, los requisitos del sistema pueden ser especificados en forma errónea o
imperfecta. Por ello, el desarrollo de software considera una actividad que apoye el proceso de
detección y eliminación de los errores y defectos del sistema en construcción. El objetivo del
rol de téster es precisamente realizar dichas tareas.
4.8.10 Plan de trabajo Tester

33
El plan de trabajo del téster debe incluir, al menos, las siguientes actividades:
• Participar en la revisión de los requisitos del sistema.
• Construir un plan de testeo.
• Coordinarse con los diseñadores para incluir el test del diseño en el documento.
• Ejecutar los tests de bajo nivel.
• Ejecutar los tests de mediano nivel.
• Ejecutar los tests de alto nivel.
• Construir la documentación del proceso de tests.
4.8.11 Aseguradores de calidad

34
En la actualidad, los factores dominantes en la administración de proyectos de
software son los tiempos y costos de desarrollo. Existen buenas razones para ello. Los tiempos
y costos de desarrollo son con frecuencia, muy grandes. Por ello, la administración se ha
concentrado en tratar de resolver dichos problemas. Sin embargo, existe un gran peligro en
esto. En la medida que crece la presión por cumplir con las fechas estipuladas, y reducir los
costos, es la calidad del producto la que sufre. Cuando se acelera el desarrollo de un sistema
que está atrasado, generalmente se corta todo lo que no se considere “esencial”, usualmente
cortando las actividades de verificación y testeo, resultando en un producto de calidad
reducida. Se hace necesario encontrar una nueva ecuación para el desarrollo de software. No
debe ser simplemente “producto de software = a tiempo + dentro de los costos”. Debiese ser
“producto de software = calidad + a tiempo + dentro de los costos”. Para ello, debe existir el
convencimiento individual y de la gerencia de considerar la calidad como una meta final,
junto con el cumplimiento de plazos y costos. Como se mencionó antes, la calidad corresponde
a un conjunto de atributos a cumplir por el desarrollador. Típicamente, dichos atributos se
encuentran definidos en la forma de un estándar, el que debe cumplirse.
4.8.12 Plan de trabajo Aseguradores de calidad
El plan de trabajo de un asegurador de calidad es extenso, ya que debe estar
involucrado en todas las fases del desarrollo del software.
5 Bibliografía
Robert Grady y Hewlett Packard Co. (s.f.). FANDOM. Obtenido de FANDOM: https://modelos-de-
evaluacion-red-grupo9.fandom.com/wiki/MODELO_DE_CALIDAD_FURPS
Chinchilla, , Z., Fernández, , A., Domínguez,, E., De Armas,, I., Otamendi, , A., Belfer, , K., . . . Prieto, , M.
(31 de 06 de 2018). modeloseredigitales.blogspot.com. Obtenido de
modeloseredigitales.blogspot.com: https://modeloseredigitales.blogspot.com/2018/07/el-
modelo-de-boehm.html
35
Excel Total. (2022). TIPOS DE GRÁFICOS EN EXCEL. Obtenido de Excel Total: https://exceltotal.com/tipos-
de-graficos-en-excel/
Excel, M. S. (2007). Microsoft Excel. Denver Co., USA. (2007). INTRODUCCIÓN A LA INFORMÁTICA.
Obtenido de Universidad Nacional del Nordeste:
http://www.ing.unne.edu.ar/assets/pdf/academica/departamentos/computacion/mod_info/
apexcel.pdf
Flores Núñez, L. C., & Zarate Mendoza, A. (s.f.). eveconde.neocities.org. Obtenido de

eveconde.neocities.org: https://eveconde.neocities.org/unidad4/evidencias/pspytsp.pdf
Murillo Montaño, , R. (., Rey Piedrahita , , A., & Vargas Arteaga, ,. A. (s.f.). Modulo Evaluación RED.
Obtenido de Modulo Evaluación RED:
https://sites.google.com/site/moduloevaluacionred/modelo-de-calidad-boehm
politecnico grancolombiano. (febrero de 2022). mensajes ocultos. Obtenido de politecnico

grancolombiano: file:///C:/Users/velasquez/Downloads/TC_Algebra_2022%20(1).pdf
textoscientificos.com. (26 de junio de 2005). criptosistema hill. Obtenido de textoscientificos.com:

http://www.textoscientificos.com/criptografia/hill
Urgino, G. V. (2016). Introduccion a la Seguridad Informatica. grupo editorial patria.
(NetApp) https://www.netapp.com/es/devops-solutions/what-is-devops/
(keepcoding.io, 2023) https://keepcoding.io/blog/ciclo-de-vida-del-desarrollo-del-sistema/

Calidad de Software 5

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Calidad de Software 5

Cargado por

Copyright:

Formatos disponibles

1

Herramientas para la Productividad

Pruebas y Calidad de Software

Samuel D. Gamarra, Oscar D. Palacios, Diego F. Pinzón, Daniel F. Maldonado, Melissa

F. Zapata y Verónica A. Olaya

GRUPO B01: Plan de Calidad Orientado a Pruebas

Avellaneda Vargas Margarita

Marzo 28, 2023

Establecer una estrategia clara y detallada para diseñar, construir e implementar un

proyecto. Asimismo, se deben establecer plazos de entrega y un presupuesto detallado para

asegurar la eficiencia del proceso y la rentabilidad del proyecto.

El plan de desarrollo de software también debe incluir una estrategia de pruebas

esenciales para asegurar la calidad y la mantenibilidad del software a largo plazo.

Por último, es importante establecer medidas de seguridad para proteger el software

contra posibles amenazas y vulnerabilidades. Se deben implementar buenas prácticas de

seguridad en todo el proceso de desarrollo para asegurar la integridad y privacidad de la

información, garantizando la confidencialidad y disponibilidad del sistema.

2. Describir los diferentes modelos de calidad, luego realizar una comparativa de

evaluación cualitativa o cuantitativa. A partir de esta evaluación escoger el modelo adecuado

3. Análisis DOFA de la empresa con los datos tomados en las entrevistas.

calidad en los productos de software.

5. Construcción de tabla de actividades, procesos, procedimientos, plan de pruebas del

ciclo de vida del software.

Se trata de una empresa que pertenece al sector de tecnología, específicamente a

14 ciudades principales del País.

Se estima que la empresa crezca en los próximos 5 años y llegue a mercados

internacionales. La empresa posee área de tecnología, contabilidad, finanzas, administración,

funciones, tiempos y seguimiento para la recepción, alistamiento y despacho de pedidos.

potenciales, determinando en que grado se generó un impacto positivo o negativo y cuántos de

ellos actualmente se han convertido en clientes de la organización, así como investigaciones y

planteamiento de estrategias para aumentar su cuota de mercado.

desarrollo de productos de software, que le permitan realizar un comparativo entre

Diversos Modelos de Calidad

Modelo Descripción Ventajas Desventajas

de calidad y el atributo, - Tiene en cuenta las costo.

3.3 Matriz DOFA:

Nota. Fortaleza, Debilidades, Oportunidades, Amenazas DOFA

3.3.1 Propuesta de mejora DOFA:

adecuados para lograr la calidad en los productos de software que su empresa

desarrolla ya sean internos o externos.

Para validar el estado de la empresa en términos de calidad de software, se pueden

utilizar varios criterios. A continuación, se presentan algunos ejemplos:

grado de cumplimiento a través de pruebas de aceptación y retroalimentación de los usuarios.

2. Estabilidad y confiabilidad: Los productos de software deben ser estables y confiables,

evitando errores y fallas. Se puede medir la estabilidad y confiabilidad a través de pruebas de

rendimiento, pruebas de estabilidad y seguimiento de incidencias.

3. Mantenibilidad: El software debe ser fácil de mantener y actualizar. Se puede medir la

mantenibilidad a través de pruebas de mantenimiento y actualización, así como evaluando la

calidad de la documentación y el código.

4. Eficiencia y rendimiento: El software debe ser eficiente y tener un buen rendimiento,

evitando la sobrecarga de recursos del sistema. Se puede medir la eficiencia y el rendimiento a

través de pruebas de carga y evaluando el diseño y la implementación del software.

5. Seguridad: El software debe ser seguro, protegiendo la información y los sistemas

contra posibles amenazas y vulnerabilidades. Se puede medir la seguridad a través de pruebas de

seguridad y evaluando la implementación de buenas prácticas de seguridad.

software, dos opciones podrían ser:

1. Modelo de madurez de capacidad de integración (CMMI): Este modelo proporciona un

En resumen, para validar el estado de la empresa en términos de calidad de software se

pueden utilizar varios criterios como el cumplimiento de los requisitos, estabilidad y

confiabilidad, mantenibilidad, eficiencia y rendimiento, y seguridad. Los modelos más

de capacidad de integración (CMMI) y el estándar internacional ISO/IEC 12207.

3.5 Tabla de actividades del ciclo de vida de software.