Desarrollo de un sistema de administración de recursos audiovisuales con aseguramiento de calidad

UNIVERSIDAD AUTÓNOMA DE CHIAPAS
FACULTAD DE CONTADURÍA Y ADMINISTRACIÓN

CAMPUS I
LICENCIATURA EN SISTEMAS COMPUTACIONALES
GENERACIÓN
2016-2020
ASEGURAMIENTO DE LA CALIDAD DEL SOFTWARE EN EL

DESARROLLO DE UN SISTEMA DE ADMINISTRACIÓN DE
RECURSOS AUDIOVISUALES
TESIS
Que para obtener el título de:
LICENCIADOS EN SISTEMAS COMPUTACIONALES
Presentan:
DEYSI ESTEFANÍA VELÁZQUEZ LIRA A160336
DAVID ALONSO UTRILLA TORIJA A160332
Directora de tesis:
DRA. REBECA ROMÁN JULIÁN
TUXTLA GUTIÉRREZ, CHIAPAS ABRIL DE 2022

1
2
ÍNDICE
CONTENIDO PÁGINA
DEDICATORIAS Y AGRADECIMIENTOS.................................................. 10
INTRODUCCIÓN ……………………………………………………………….. 12
CAPÍTULO 1. PROBLEMATIZACIÓN DEL OBJETO DE ESTUDIO
1.1 Planteamiento del problema ……………………………………………. 14
1.2 Objetivos ……………………………………………………….................. 16
1.2.1 Objetivo general ………………………………………………….. 16
1.2.2 Objetivos específicos ……………………………………………. 16
1.3 Justificación ……………………………………………………………….. 17
1.4 Delimitación de la investigación…………...,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, 19
CAPÍTULO 2. REFERENTE CONCEPTUAL

2.1 Desarrollo de software ………………………………………………….. 20
2.1.1 Modelos de desarrollo…………………………………………… 20
2.1.1.1 Modelos convencionales ……………………………… 21
2.1.1.2 Modelos ágiles …………………………………………. 22
2.1.1.3 Selección del modelo de desarrollo …………………. 24
2.1.2 Definición de requerimientos de software …………………….. 26
2.1.3 Análisis y diseño de software ………………………………...... 28
2.1.4 Codificación ………………………………………………………. 30
2.1.5 Pruebas ………………………………………………….............. 30
2.1.6 Implementación ………………………………………………….. 31
2.1.7 Operación y mantenimiento ……………………………………. 31
2.2 Paradigmas de desarrollo de software ………………………............ 31
2.2.1 Programación estructurada …………………………………….. 32
2.2.2 Programación procedimental …………………………………… 32
2.2.3 Programación orientada a objetos …………………………….. 33
3
2.2.3.1 Lenguajes de programación orientada a objetos ….. 33
2.2.3.1.1 Java ……………………………………….…... 34
2.2.3.1.2 Ruby …………………………………………... 34
2.2.3.1.3 Phyton ………………………………………… 35
2.2.3.1.4 C# ……………………………………………… 36
2.2.3.2 Herramientas y entornos de desarrollo de software .. 37
2.3 Calidad del software ……………………………………………………… 38
2.3.1 Conceptos de calidad …………………………………………... 39
2.3.1.1 Estándares de calidad ………………………………… 40
2.3.2 Aseguramiento estadístico de la calidad del software............. 44
2.3.3 Técnicas de aseguramiento de la calidad de software ……… 45
2.3.3.1 Técnicas de revisión …………………………………... 47
2.3.3.1.1 Aplicación de revisión técnica informal …… 48
2.3.3.1.2 Aplicación de revisión técnica formal ……... 49
2.3.3.1.3 Reporte de evaluación de software ……….. 50
2.3.4 Prueba de aplicaciones orientada a objetos …………………. 51
2.3.4.1 Guía y aplicación de pruebas ………………………... 53
2.3.4.2 Reporte de casos de prueba de software ………….. 55
2.3.5 Resultados del aseguramiento de la calidad de software …... 55
CAPÍTULO 3. MARCO CONTEXTUAL

3.1 Sistema Chiapaneco de Radio, Televisión y Cinematografía …….. 58
3.1.1 Historia, Misión y Visión …………………………………………. 58
3.1.2 Cine, radio y televisión hecho en Chiapas …………………….. 60
3.2 Área de recursos audiovisuales y programación televisiva ……… 62
3.2.1 Funciones e importancia de su operación …………………….. 62
3.2.2 Procesos y necesidades del área ……………………………… 63
3.2.3 Optimización y mejora de los procesos mediante soluciones de
software ………………………………………………………………….. 64
CAPÍTULO 4. DISEÑO METODOLÓGICO

4.1 Enfoque de la investigación …………………………………………….. 66
4.2 Método de investigación ………………………………………………… 67
4
4.3 Técnicas de investigación ………………………………………………. 67
4.3.1 Observación ………………………………………………………. 67
4.3.2 Entrevista ………………………………………………………….. 68
4.4 Participantes de la investigación ………………………………………. 69
4.5 Instrumentos de investigación …………………………………………. 71
4.5.1 Cédula de observación ………………………………………….. 71
4.5.2 Guía de entrevista ……………………………………………….. 72
4.6 Análisis de datos …………………………………………………………. 73
CAPÍTULO 5. PROCESO DE ASEGURAMIENTO DE LA CALIDAD EN EL

DESARROLLO DEL SISTEMA DE ADMINISTRACIÓN DE RECURSOS
AUDIOVISUALES
5.1 Descripción global ……………………………………………………….. 75
5.1.1 Necesidad, problema u oportunidad de la organización …….. 75
5.1.2 Suposiciones y Restricciones …………………………………... 75
5.2 Definición de requerimientos …………………………………………... 76
5.2.1 Obtención de Requerimientos ………………………………….. 76
5.2.1.1 Métodos interactivos …………………………………... 76
5.2.1.2 Requerimientos Funcionales …………………………. 76
5.2.1.2.1 Requerimientos de base de datos …………. 77
5.2.1.3 Requerimientos No Funcionales ……………………… 78
5.2.2 Especificación de casos de usos ………………………………. 79
5.2.3 Análisis de requerimientos ……………………………………… 79
5.2.4 Modelo de la base de datos …………………………………….. 80
5.3 Proceso de desarrollo del software …………………………………… 81
5.4 Proceso de aseguramiento de la calidad del software …………….. 81
5.4.1 Revisión informal …………………………………………………. 82
5.4.2 Revisión Técnica Formal ………………………………………… 84
5.4.2.1 Evaluación de los requerimientos de software ……… 84
5.4.2.2 Evaluación de interfaz ………………………………….. 85
5.4.2.3 Evaluación de código …………………………………… 88
5.4.2.4 Reporte de evaluación de software …………………… 89
5.4.3 Guía y aplicación de pruebas …………………………………… 92
5
5.4.3.1 Guía de prueba orientado a objetos ………………….. 92
5.4.3.1.1 Caso de prueba “agregar productoras” ……. 92
5.4.3.1.2 Caso de prueba “eliminar productoras” ……. 93
5.4.3.1.3 Caso de prueba “modificar productoras” …... 94
5.4.3.1.4 Caso de prueba “agregar programa” ………. 95
5.4.3.1.5 Caso de prueba “eliminar programa” ………. 97
5.4.3.1.6 Caso de prueba “modificar programa” ……… 98
5.4.3.1.7 Caso de prueba “catálogo de programas” …. 99
5.4.3.1.8 Caso de prueba “generar pauta programática” 100
5.4.3.1.9 Caso de prueba “añadir contacto” ………….. 102
5.4.3.1.10 Caso de prueba “eliminar contacto” ………. 103
5.4.3.1.11 Caso de prueba “añadir capítulo” …………. 104
5.4.3.1.12 Caso de prueba “modificar capítulo” ……… 105
5.4.3.1.13 Caso de prueba “eliminar capítulo” ……….. 107
5.4.3.1.14 Caso de prueba “modificar pauta
programática” …………………………………………….. 108
5.4.3.1.15 Caso de prueba “diseño de interfaz” ………. 109
5.4.3.2 Reporte de casos de prueba de software …………….. 111
5.4.4 Aseguramiento de la calidad …………………………………….. 113
5.4.5 Producto final ……………………………………………………… 114
CONCLUSIONES ………………………………………………………………... 119
REFERENCIAS …………………………………………………………………... 120
6
ÍNDICE DE TABLAS
PÁGINA
Tabla 2.1 Tabla de percepciones del concepto de calidad …………………...….. 39
Tabla 5.1 Métodos interactivos ………………………………………………………. 76
Tabla 5.2 Requerimientos funcionales ……………………………………………… 76
Tabla 5.3 Requerimientos de base de datos ………………………………………. 77
Tabla 5.4 Requerimientos no funcionales ………………………………………….. 78
Tabla 5.5 Evaluación de los requerimientos del software ………………………… 85
Tabla 5.6 Evaluación de interfaz …………………………………………................ 85
Tabla 5.7 Evaluación de código …………………………………………................. 88
Tabla 5.8 Caso de prueba “agregar productoras” …………………………………. 92
Tabla 5.9 Caso de prueba “eliminar productoras” …………………………………. 93
Tabla 5.10 Caso de prueba “modificar productoras” ………………………………. 94
Tabla 5.11 Caso de prueba “agregar programa” …………………………………... 95
Tabla 5.12 Caso de prueba “eliminar programa” …………………………………… 97
Tabla 5.13 Caso de prueba “modificar programa” ………………………………… 98
Tabla 5.14 Caso de prueba “catálogo de programas” ……………………………… 99
Tabla 5.15 Caso de prueba “generar pauta programática” ………………………. 100
Tabla 5.16 Caso de prueba “añadir contacto” ..................................................... 102
Tabla 5.17 Caso de prueba “eliminar contacto” ................................................... 103
Tabla 5.18 Caso de prueba “añadir capítulo” ....................................................... 104

Tabla 5.19 Caso de prueba “modificar capítulo” .................................................. 105
Tabla 5.20 Caso de prueba “eliminar capítulo” .................................................... 107
Tabla 5.21 Caso de prueba “modificar pauta programática” ................................ 108
Tabla 5.22 Caso de prueba “diseño de interfaz” .................................................. 109
8
ÍNDICE DE FIGURAS
PÁGINA
Figura 4.1 Cédula de observación ....................................................................... 71
Figura 5.1 Especificación de casos de usos ........................................................ 79
Figura 5.2 Modelo de la base de datos ................................................................ 80
Figura 5.3 Cronograma para atender la revisión informal .................................... 83
Figura 5.4 Pantalla de inicio ................................................................................. 114
Figura 5.5 Pestaña “Programación”, interfaz “crear pauta programática” ............ 115
Figura 5.6 Pestaña “Programas”, interfaz “agregar programas” .......................... 115
Figura 5.7 Pestaña “Programas”, interfaz “agregar capítulos” ............................. 116
Figura 5.8 Pestaña “Programas”, interfaz “buscar programas” ............................ 116
Figura 5.9 Pestaña “Programas”, interfaz “búsqueda de programas con vista de

capítulos y bloques” .............................................................................................. 117
Figura 5.10 Pestaña “Productoras”, interfaz “agregar productoras” ..................... 117
Figura 5.11 Pestaña “Productoras”, interfaz de “búsqueda de productoras” ........ 118
Figura 5.12 Pestaña “Productoras”, interfaz “agregar contacto” ........................... 118
9
DEDICATORIA
“A mi madre, padre y hermano porque han sido parte de mi formación y crecimiento
cada día, por inculcarme buenos valores, sentimientos y hábitos, mismos que me
han permitido sobrellevar los momentos difíciles, por ser mi mayor motivación para
no rendirme y siempre dar lo mejor de mí”.
“A mi abuela, que desde el cielo me ilumina para seguir adelante con mis proyectos
y me enseñó el significado de ser fuerte y valiente”.
“A toda mi familia, por siempre estar presente, por motivarme, apoyarme y por todo
su cariño”.
AGRADECIMIENTO
Principalmente agradezco a Dios, por hacer su voluntad en mí, por ser mi guía en
todo momento y por darme la fortaleza para continuar cada día.
A mis padres, Víctor y Natalia y a mi hermano Daniel, por toda su comprensión, por
todo su apoyo y esfuerzo a lo largo de mi vida personal y profesional, por darme
todo lo necesario para que cumpliera este sueño, muchos de mis logros se los debo
a ustedes, les estaré eternamente agradecida.
A mi compañero de aventuras David, por ser más que mi amigo y compañero de

tesis, gracias por este tiempo compartido, por cada momento y por todos los que
vendrán, un placer compartir todo contigo.
Gracias a todos mis familiares y amigos, que de una forma u otra me han apoyado
a lo largo de esta maravillosa travesía, ustedes también han sido parte de este logro.
Finalmente, un agradecimiento especial para la directora de esta tesis la Dra.

Rebeca Román, por su paciencia, dedicación y compromiso con nosotros para
hacer de este un mejor trabajo, por siempre tener palabras para motivarnos, por
ayudarnos y por ser una extraordinaria persona y docente.
Deysi Estefanía Velázquez Lira
10
DEDICATORIA
“A mi madre, por forjar a la persona que soy hoy, por creer en mí siempre y nunca
dudar de mi capacidad, por todo el esfuerzo que ha realizado para permitirme seguir
adelante y alcanzar este logro, por ser ella el motivo de que esté y siga aquí”.
“A mis hermanos, por apoyarme aún en los momentos más difíciles, por
demostrarme que nunca es tarde para cambiar y volver a intentarlo, por ser un
ejemplo para mí, aconsejándome y aclarándome el panorama en mis decisiones”.
“A mi padre, que dejó en mí parte de su persona, forjó parte de mi carácter, me

inculcó sus valores y desde el cielo me guía”.
AGRADECIMIENTO
A mi madre Eloina, por todo el esfuerzo que ha realizado para salir adelante a pesar
de la adversidad, por hacer el rol de padre cuando hizo falta y darme las
oportunidades que me han traído hasta aquí, por la confianza que siempre ha tenido
en mí y en mis ideales, gracias.
A mis hermanos Francisco y Eloina, quienes han sido parte importante de mi vida,
que en los momentos más difíciles fueron mi respaldo, por ser guías y consejeros
en momentos necesarios y siempre estar ahí.
A mi compañera en este viaje, Estefanía, por impulsarme a continuar y querer

alcanzar una meta más alta siempre, por ser parte vital de este trabajo, por ser más
que mi amiga y compañera, gracias por todo lo que hemos vivido juntos y por todo
lo que aún está por venir.
A nuestra directora de tesis, la persona que nos permitió ver que cuando algo se
hace con pasión y entrega, deja de ser un simple trabajo. A la Dra. Rebeca Román
que con paciencia y dedicación nos apoyó para alcanzar esta meta, gracias por
guiarnos y demostrar que ama su trabajo y, sobre todo, por aceptar ser nuestra
directora y ser parte fundamental de este trabajo.
David Alonso Utrilla Torija
11
INTRODUCCIÓN
La tesis que se expone es el producto de una investigación cualitativa aplicada a

través de un estudio de caso que tiene por objetivo, presentar todo el proceso de
desarrollo y aseguramiento de la calidad del software aplicado a un sistema de
administración de recursos audiovisuales para el área de programación televisiva
del Sistema Chiapaneco de Radio, Televisión y Cinematografía, con la finalidad de
mejorar sus procesos de trabajo y hacerlos más eficientes, con apoyo de una
herramienta tecnológica de calidad.
Para ello el capítulo 1 plantea el problema de la investigación, junto con los objetivos
tanto general como específicos, la justificación y delimitación de la misma.
El capítulo 2 describe la fundamentación conceptual del proyecto, respecto a las

bases de un desarrollo de software, abordando temas como los modelos de
desarrollo, paradigmas y lenguajes de programación, así como aspectos referentes
al aseguramiento de la calidad del software.
El capítulo 3 se refiere al marco contextual del proyecto, describiendo al Sistema

Chiapaneco de Radio, Televisión y Cinematografía, abordando su historia, misión y
visión, y teniendo como objeto de estudio el área de programación televisiva,
planteando temas como el funcionamiento e importancia del área, sus procesos y
necesidades, al mismo tiempo que se describe la propuesta de optimización de los
procesos a través de un sistema de información.
El capítulo 4 expone el diseño metodológico, describiendo el enfoque, método y

técnicas utilizadas en la investigación. Así mismo, describe el rol del personal del
área de programación televisiva. Los datos se obtuvieron a través de instrumentos
de investigación como las guías de entrevista y observación, las cuales fueron
aplicadas al personal del área en cuestión para definir los requerimientos del
sistema de acuerdo con las necesidades de los usuarios, así como las restricciones
en cuanto a hardware y software.
12
Una vez obtenida toda la información de los usuarios y sus necesidades respecto al
software, se realizó el análisis de la información mediante las herramientas UML,
para posteriormente realizar el desarrollo del sistema requerido.
Finalmente, el capítulo 5 detalla paso a paso el proceso de aseguramiento de la

calidad del software, teniendo su inicio en el proceso de obtención de
requerimientos funcionales y no funcionales, la especificación de casos de usos, el
diseño de módulos y del modelo de base de datos del sistema, así como el proceso
de codificación del software, en el cual se utilizó el paradigma orientado a objetos y
la metodología del Proceso de Desarrollo Unificado (RUP). El entorno para la
programación fue Visual Studio 2013, junto con el paquete de software libre XAMPP
para la gestión de la base de datos. Posteriormente, se presentan los resultados de
las revisiones formales e informales, así como las guías de aplicación de pruebas y
del aseguramiento de la calidad del software.
13
CAPÍTULO I. PROBLEMATIZACIÓN DEL OBJETO DE ESTUDIO
1.1 Planteamiento del problema
El uso del software se ha incrementado a lo largo de los años; es decir, cada

día la dependencia hacia la tecnología es más notoria y, en los últimos años, el
software se ha hecho presente en todas las partes de nuestra sociedad, eso ha
provocado que la calidad del mismo hoy día tenga mayor relevancia. Para usuarios
y desarrolladores de software esto significa que cada vez es más importante obtener
y entregar un software con calidad, lo que lleva a plantear diferentes
cuestionamientos acerca del significado de la calidad del software, cómo se mide y
cómo se evalúa, derivado de esto, surge la pregunta inicial ¿Qué es la calidad del
software?
Se entiende la calidad del software como un concepto complejo que no es

directamente comparable con la calidad de la manufactura de productos
(Sommerville, 2015). Esto significa que la calidad del software abarca más que solo
el resultado de un producto que cumple con las especificaciones dadas por el
usuario. Al mismo tiempo, según Pressman (2010), David Garvin sugiere que la
calidad de software debe adoptarse desde un punto de vista de múltiples fases, que
inicie con evaluar la conformidad y culmine con una visión trascendental, estética.
Sin embargo, definir la calidad del software suele ser más complicado, esto
dependerá de lo que los desarrolladores e incluso el usuario considere importante
en el resultado final y durante su proceso, lo cual lo convierte en un concepto un
tanto ambiguo que puede tener diversas definiciones.
Pressman (2010) expone que:
Actualmente, la calidad del software es preocupante, pero, ¿de quién es la

culpa? Los clientes culpan a los desarrolladores, pues afirman que sus
prácticas descuidadas producen software de mala calidad. Los
desarrolladores culpan a los clientes (y a otros participantes) con la
afirmación de que las fechas de entrega irracionales y un flujo continuo de
14
cambios los obligan a entregar software antes de haber sido validado por
completo. ¿Quién tiene la razón? Ambos, y ése es el problema. (p. 339)
Así que, aunque sea complejo definir el concepto de calidad de software, no

se debe olvidar que es parte fundamental del desarrollo del mismo, contemplar la
calidad desde el inicio del proceso y hasta concluirlo. Bajo este orden de ideas cabe
mencionar que un software con calidad tendrá el propósito de satisfacer una
necesidad o resolver un determinado problema sea cual sea el ámbito o área para
el que se desarrolla.
Pero ¿Qué pasa si un software no cumple con la calidad adecuada en el

proceso y el producto? Bueno, esto fácilmente se puede reducir tan solo a pérdidas
económicas, pues podría representar el desperdicio de miles de millones de pesos
en software que no cumple con las especificaciones ni la funcionalidad para la que
fue desarrollado. Sin embargo, esto va más allá de solo pérdidas materiales o
económicas esto se debe a que existe también la posibilidad de que un software
defectuoso represente una amenaza y un riesgo para la salud e inclusive la vida,
puesto que, se sabe que hay software utilizado en el campo de la medicina, de la
aeronáutica, las telecomunicaciones, entre otros. Un ejemplo sería si el analizador
de detección de enfermedades de un hospital fallara en algún momento, un paciente
que goza de buena salud podría recibir un resultado incorrecto y, esto lo expondría
a someterse a un determinado tratamiento o procedimiento quirúrgico, si fuese el
caso, lo cual podría traerle riesgos y consecuencias para su salud (Pressman,
2010).
Debe considerarse además que, el software no sólo puede encargarse de

realizar determinadas funciones o tareas, sino que, también puede realizar la
función de guardar y gestionar información que puede ser sensible, un fallo en el
software de este tipo, podría comprometer esa información causando su pérdida, lo
cual ya es bastante grave o peor aún, provocando su divulgación. Esto se traduciría
en problemas legales, pérdidas económicas o mal uso de la información de acuerdo
al tipo de datos expuestos, ya sea de clientes o personal de determinada empresa
u organización.
15
Es por estas razones que el tema de la calidad cobra aún más relevancia y,
por lo tanto, los desarrolladores tienen una responsabilidad más allá de simplemente
entregar un software funcional y a tiempo, caso como el que se presenta en el
Sistema Chiapaneco de Radio, Televisión y Cinematografía que es el dependencia
pública estatal de radio, televisión y cinematografía de Chiapas y tiene un área
designada para las actividades de programación televisiva, la cual tiene ciertas
dificultades al realizar los procesos de almacenamiento, consulta y manejo del
material audiovisual, así como en la creación de las pautas programáticas que se
realizan diariamente para proponer la programación que se transmite en televisión.
Actualmente estos procesos se realizan a través de las herramientas básicas

de Office, lo cual ha resultado poco eficiente debido a los retrasos en las actividades
del área y al evidente riesgo que puede representar el fallo de los equipos de
cómputo si el material no se encuentra respaldado, situación que pl antea la
interrogante ¿Cómo desarrollar un software de calidad para la gestión de los
recursos audiovisuales y la programación televisiva?
1.2 Objetivos
1.2.1 Objetivo general
Optimizar la gestión de los recursos audiovisuales y la programación

televisiva del Sistema Chiapaneco de Radio, Televisión y Cinematografía, mediante
el desarrollo de un software aplicando el proceso de aseguramiento de la calidad.
1.2.2 Objetivos específicos
1. Comprender las características, elementos, técnicas y procesos de calidad

que pueden aplicarse al desarrollo de software orientado a objetos.
2. Analizar el proceso de gestión de recursos audiovisuales y la programación

televisiva para definir los requerimientos del software.
3. Diseñar un proceso de estándares, métricas y modelos de calidad aplicado

al desarrollo de un sistema de administración de recursos audiovisuales.
16
1.3 Justificación
La calidad de un producto es un aspecto a tener en cuenta sin importar la

naturaleza del mismo, la diferencia entre un producto de calidad y uno genérico es
notable y no precisamente tendrá que ser al momento de su primer uso, puede que
la falta de calidad en un producto se muestre paulatinamente con el paso del tiempo,
y en un software es igual, puede que un programa funcione al principio de manera
adecuada, sin fallos ni errores, realiza las tareas para las que fue programado y
solventa la necesidad del cliente, pero incluso siendo así, cuando el software no es
de calidad podría representar una bomba de tiempo para los usuarios del mismo,
por motivos de seguridad, por obsolescencia apresurada o por situaciones externas
que no se previeron en los procesos iniciales, tal como indica Pantaleo (2011) “la
calidad es un valor en sí mismo y no un gasto que las empresas deben realizar para
que su negocio prospere” (p. 33).
Estos son sólo ejemplos de posibles problemas derivados de un software que

no llevó un proceso de calidad adecuado, la importancia de un proceso de desarrollo
de calidad toma el papel principal en cuanto se habla de los peligros que representa
tener productos que carecen de calidad, de esta premisa deriva el objetivo principal
de esta investigación.
Al responder a la interrogante principal de esta investigación, no solo se

podrán conocer cuáles son los aspectos a considerar cuando se realiza un sof tware,
sino también identificar buenas prácticas del proceso de desarrollo de software que
eviten que los errores de modelado, diseño y codificación trasciendan a etapas
futuras del desarrollo y tengan que llegar a ser detectados finalmente hasta la etapa
donde se debe evaluar que el software se encuentra en funcionamiento, esto a su
vez permitirá al desarrollador realizar mejoras que hagan de su producto de software
uno de mejor funcionamiento y por ende de mejor calidad.
Entender todo el proceso que implica un desarrollo de calidad incluye conocer

la gestión de la calidad, esto permite que se identifiquen las tareas importantes que
se deben realizar y a los responsables de cada parte del proyecto, de este modo el
17
grupo se responsabiliza de la evolución del software y permite saber qué ha hecho
cada uno de los que participan en el equipo de desarrollo.
Según Sommerville (2015) la gestión de calidad del software se estructura en tres

actividades principales:
1. Garantía de la calidad. El establecimiento de un marco de trabajo de

procedimientos y estándares organizacionales que conduce a software de
alta calidad.
2. Planificación de la calidad. La selección de procedimientos y estándares

adecuados a partir de este marco de trabajo y la adaptación de éstos para
un proyecto de software específico.
3. Control de la calidad. La definición y fomento de los procesos que

garanticen que los procedimientos y estándares para la calidad del
proyecto son seguidos por el equipo de desarrollo de software. (p.589)
Por ello, es importante considerar estos aspectos dentro de la investigación

para tener un panorama más amplio del trabajo que conlleva el lograr el objetivo
deseado, abarcando los aspectos de calidad que nos permitan ir evolucionando en
la mejora del proceso y realizar una correcta planificación y gestión desde el inicio
de un proyecto de desarrollo de software.
Existen diversos modelos, métricas, técnicas de desarrollo y revisión, que

conllevan a su vez fases diferentes para la planeación, ejecución y finalización de
un proyecto de software, estos implementan medidas de control de calidad de
distintas maneras, pero así como en todas existen puntos clave durante el proyecto
en los cuales se pone a prueba la calidad de los productos entregados en esa fase,
también existen hábitos y buenas prácticas que se implementan y se recomiendan
adoptar lo antes posible durante todo el diseño y desarrollo del software.
Existen también diferentes estándares que describen y ejemplifican cómo

debe llevarse a cabo un desarrollo de calidad, cómo debe medirse la calidad del
software, qué puntos deben ser especialmente atendidos y cómo tener una visión
18
completa del desempeño como desarrollador o en su caso, como equipo de
desarrollo, pero cada proyecto y cada equipo debe tomar en consideración con qué
estándar se adecúa mejor el proyecto en marcha, además del modelo de desarrollo
que se ajusta más a su personal, a su presupuesto e incluso a las peticiones del
cliente; la calidad es en mayor medida, subjetiva, pero aún en lo subjetivo existen
guías y estándares que proponen medidas, reglas y metas a cumplir.
1.4 Delimitación de la investigación
Este trabajo de investigación aplicada involucra un proceso de recopilar

información de tal manera que pueda haber un enlace comprobable entre la teoría
y la práctica relacionada con la calidad de un producto de software, desarrollado
durante el periodo comprendido de los meses de enero a junio de 2021; aborda de
manera general los procesos, técnicas y procedimientos que involucran al control
de calidad de un software en proceso de desarrollo, así como, la medición de la
calidad al momento de finalización del proyecto, se delimita esta investigación al
rubro de desarrollo de software bajo el contexto orientado a objetos y en el marco
del Sistema Chiapaneco de Radio, Televisión y Cinematografía.
19
CAPÍTULO 2. REFERENTE CONCEPTUAL
2.1 Desarrollo de software
El desarrollo de software implica más que solo la creación de un programa

informático, también se trata de la aplicación sistemática, disciplinada y cuantificable
para crear, operar y dar mantenimiento a un software, a su vez, implica la
documentación escrita que incluye manuales, diarios de desarrollo, diagramas y
modelados, entre otros, según Sommerville (2005):
El software no son sólo programas, sino todos los documentos asociados y

la configuración de datos que se necesitan para hacer que estos programas
operen de manera correcta. Por lo general, un sistema de software consiste
en diversos programas independientes, archivos de configuración que se
utilizan para ejecutar estos programas, un sistema de documentación que
describe la estructura del sistema, la documentación para el usuario que
explica cómo utilizar el sistema y sitios web que permitan a los usuarios
descargar la información de productos recientes. (p. 5)
De acuerdo con lo anterior, el desarrollo de software comienza desde la concepción

de la idea hasta el mantenimiento y mejora del mismo, es decir, consta de varias
etapas que generalmente coinciden en los diferentes modelos de desarrollo de
software existentes, entre las cuales se encuentran: Análisis, diseño,
implementación, pruebas y mantenimiento.
2.1.1 Modelos de desarrollo
Las metodologías o modelos de desarrollo, aplican un proceso cuidadoso sobre el

desarrollo de software con el objetivo de hacerlo más predecible y eficiente debido
a que son una serie de pautas, actividades y recomendaciones que permiten a un
equipo de desarrolladores crear software de calidad, ajustándose a las necesidades
y habilidades de los involucrados en el desarrollo, según Sommerville (2005) “estos
modelos generales no son descripciones definitivas de los procesos del software.
Más bien, son abstracciones de los procesos que se pueden utilizar para explicar
diferentes enfoques para el desarrollo de software” (p. 61), existen varios modelos
20
de proceso de desarrollo entre los cuales destacan dos grupos importantes, los
modelos convencionales y los modelos ágiles.
2.1.1.1 Modelos convencionales
Los modelos convencionales como su nombre lo dice, son aquellos que se

asemejan más a lo tradicional, es decir, son modelos que mantienen una estructura
rigurosa en cuanto a las fases o etapas de desarrollo, las cuales incluyen, el análisis,
el diseño, la implementación, las pruebas y el mantenimiento, trabajan sobre esa
línea constante que rara vez se desvía y se centran especialmente en el control del
proceso y la documentación exhaustiva del mismo. La base de estos modelos sirve
como pilar para todos los proyectos de software independientemente del paradigma
de programación que se utilice, ya que permite abordar cada una de las actividades
que conforman el ciclo de vida de un proyecto de desarrollo.
De acuerdo con Báez (2013), Pressman (2010) y Méndez (2016), entre los
principales modelos de desarrollo convencionales se encuentran:
● Modelo RUP: El proceso unificado de desarrollo de software es un modelo

de desarrollo que se diferencia de otros por ser iterativo e incremental y está
dirigido por casos de uso y se cen tra en la arquitectura. Según Báez (2013)
RUP implementa soluciones escalonadas, llamadas iteraciones, las cuales
se refieren a realizar una o más disciplinas o flujos de trabajo, lo cual modera
los riesgos y ayuda a cumplir algunos requisitos, ya sean fun cionales o no.
● Modelo en cascada: Según Pressman (2010) este modelo aplica un enfoque
sistemático y en secuencia utilizado para el desarrollo del software, que inicia
con la recopilación y análisis de los requerimientos que satisfacen las
necesidades del cliente y avanza a través de las etapas de diseño,
implementación y pruebas, para concluir con el mantenimiento del software
terminado.
● Modelo incremental: Este modelo de proceso está diseñado para escenarios
donde el software se produce mediante incrementos, de ahí su nombre
modelo incremental, es de gran utilidad cuando hay una necesidad imperiosa
21
por incluir de manera rápida alguna función en el software a los usuarios y
considerarla en las entregas posteriores del desarrollo. Este modelo consta
de las etapas de comunicación, planeación, modelado, construcción y
despliegue, que en esencia equivalen a las etapas de un modelo de cascada
respectivamente, con la peculiaridad de que, cada incremento conlleva a la
repetición de cada una de estas etapas (Pressman, 2010).
● Modelo espiral: Este es un modelo que permite hacer entregas evolutivas del
software, por lo tanto, permite que este evolucione con el paso del tiempo,
es posible trabajar de manera iterativa y en la primera iteración del proyecto
entregar un prototipo del software que de manera paulatina evolucione y
cubra las necesidades del cliente para posteriormente ir actualizándose en
versiones más completas hasta conseguir el producto final. Este modelo al
igual que los anteriores está conformado por las etapas de comunicación,
planeación, modelado, construcción y despliegue, las cuales de manera
indefinida hasta cumplir con las necesidades del cliente y obtener el producto
final de software (Méndez, 2006).
2.1.1.2 Modelos ágiles
Este enfoque tiene su origen en la necesidad de hacer menos complejas las etapas
de desarrollo de un proyecto de software con respecto a los modelos
convencionales, a diferencia de estos los modelos ágiles tienen como uno de sus
principios la adaptabilidad de los procesos ya que establecen pautas para que
entregar el proyecto sea más conveniente para clientes y desarrolladores, evitando
los modelos convencionales y por lo tanto generando únicamente la documentación
esencial del software. Según Maida y Paziencia (2015), “estas metodologías ponen
de relevancia que la capacidad de respuesta a un cambio es más importante que el
seguimiento estricto de un plan” (p. 18).
Del mismo modo que con los modelos convencionales, también existen diferentes
modelos ágiles entre los cuales se encuentran:
22
● Programación Extrema (XP): Este modelo ágil es uno de los más conocidos
y utilizados, se destaca por incluir una serie de buenas prácticas de desarrollo
de software que permiten el trabajo colaborativo entre desarrolladores y
cliente, mismo que se involucra de tiempo completo con el equipo de tal
manera que participe activamente durante el desarrollo del proyecto, los
escenarios en este modelo son llamados historias de usuario y se efectúan
como una serie de tareas para las cuales los desarrolladores realizan
pruebas para cada una, previas a la codificación del software. Las etapas de
este modelo son las siguientes, seleccionar las historias de usuario para la
entrega, dividir las historias en tareas, planificar la entrega, desarrollar,
integrar o probar el software, entrega y la evaluación del sistema.
Cabe destacar que este modelo ágil se enfoca en el interés en las personas,
en vez de en los procesos y permite un desarrollo sostenible que no implique
largas jornadas de trabajo (Sommerville, 2005).
● Scrum: Pressman (2010) lo describe como un método de desarrollo ágil
utilizado como guía de las tareas de desarrollo en el proceso de análisis, está
conformado por las siguientes actividades: requerimientos, análisis, diseño,
evolución y entrega. Este modelo está enfocado en los desarrollos que
generalmente implican cambios significativos de los requerimientos del
software durante su desarrollo. Una de las características importantes de
Scrum es que su forma de trabajo le permite ser altamente adaptable a las
necesidades del cliente.
Maida y Paziencia (2015) lo describen a su vez como:
Un proceso en el que se aplican de manera regular un conjunto de

buenas prácticas para trabajar colaborativamente, en equipo, y
obtener el mejor resultado posible de un proyecto. Estas prácticas se
apoyan unas a otras y su selección tiene origen en un estudio de la
manera de trabajar de equipos altamente productivos. (p. 73)
23
● Kanban: Según Maida y Paziencia (2015) es un sistema de gestión del
trabajo en curso, fundamentalmente se basa en el aseguramiento de una
producción continua y sin sobrecargas de trabajo en el equipo de producción
evitando la inversión innecesaria de tiempo y esfuerzo.
Además, Maida y Paziencia (2015) también sugieren que:
El aporte principal de Kanban a las metodologías agiles es que, a

través de la implementación de tarjetas visuales, proporciona
transparencia al proceso, ya que su flujo de trabajo expone los cuellos
de botella, colas, variabilidad y desperdicios a lo largo del tiempo y
todas las cosas que impactan al rendimiento de la organización en
términos de la cantidad de trabajo entregado y el ciclo de tiempo
requerido para entregarlo. (p. 90)
2.1.1.3 Selección del modelo de desarrollo
Según Maida y Paziencia (2015), “desarrollar un buen software depende de un gran

número de actividades y etapas, donde el impacto de elegir la metodología para un
equipo en un determinado proyecto es trascendental para el éxito del producto.” (p.
17), ciertamente es vital saber elegir la metodología adecuada para explotar el 100%
de las capacidades de un equipo de desarrolladores; sin embargo, cabe destacar
que no todas las metodologías existentes son las más aptas para cualquier tipo de
desarrollo, es decir, siempre existe cierta compatibilidad o incompatibilidad entre las
características de un modelo y el contexto y requerimientos de un proyecto, por lo
tanto, hay ciertas consideraciones a tomar en cuenta para elegir el modelo de
desarrollo ideal para cada tipo de software, esta decisión podría permitir una mejor
experiencia de desarrollo tanto para el equipo como para el cliente.
Tanto para un sistema que requiere precisión extrema, como para un sistema que
está en constante evolución, existe un modelo que se adecúe a él, a pesar de que
los modelos convencionales son en ocasiones descartados por ser rigurosos y
exigentes, muchos proyectos requieren de ellos, dado que estos modelos tienen
especial atención en una documentación exhaustiva y completa no suelen ser
24
tomados en cuenta para proyectos que buscan una constante mejora o cambio,
puesto que estos proyectos, al ser tan volátiles con respecto al cambio, dejarían
obsoleta la documentación previa. También es de tomar en cuenta para la elección,
el número de desarrolladores que componen el equipo, pues hay modelos que
funcionan mejor en equipos pequeños y otros que permiten hacer uso de todo el
recurso humano en equipos numerosos de desarrollo.
La pregunta surge al iniciar un proyecto nuevo ¿Qué modelo de desarrollo debería

implementar para este desarrollo? Esta es una interrogante complicada de
responder, más aún cuando se está iniciando en la gestión de proyectos, existen
algunos puntos a tomar en consideración que pueden ayudar a la toma de esta
decisión, lo primero y más importante es que no hay opción incorrecta en la elección
de modelo de desarrollo, todos los modelos fueron creados para llevar a cabo un
proceso eficiente y de calidad durante la programación del software, por tanto, no
hay que presionarse por encontrar la metodología perfecta para el proyecto, más
bien, se trata de encontrar la que mejor se acople al equipo, ciertamente como se
mencionó anteriormente algunos proyectos deben llevarse a cabo con un nivel de
documentación más precisa y exhaustiva, como lo podría ser un sistema de control
de espacio aéreo, el cual necesita una precisión y fiabilidad alta, por tanto sería
recomendable hacer uso de un modelo convencional, pero aún en estos casos,
sería viable realizar el proyecto con un modelo ágil, por supuesto, ajustando algunas
de las características originales, como sumarle importancia a la documentación y la
precisión de las respuestas que el software entregue.
Algunas sugerencias a tomar en cuenta al momento de seleccionar el modelo de

desarrollo del software son las siguientes:
● Considerar que sea un modelo de fácil acceso para el equipo de desarrollo

para garantizar la fluidez y eficiencia del trabajo.
● Tomar en cuenta el grado de adaptabilidad del modelo, de acuerdo con lo
que necesita el proyecto.
● Tomar en consideración el número de integrantes del equipo de desarrollo.
25
● Asegurarse de que el modelo que se elija permita cumplir con los tiempos
establecidos, así como los costos del proyecto.
2.1.2 Definición de requerimientos de software
La etapa de definición de los requerimientos del software, es probablemente la

etapa más importante, según Sommerville (2005), “las definiciones de
requerimientos del sistema especifican qué es lo que el sistema debe hacer (sus
funciones) y sus propiedades esenciales y deseables” (p. 24), también suele ser la
más compleja tanto para desarrolladores como para el cliente, debido a que los
resultados obtenidos son completamente subjetivos, en el mismo proceso, dos
personas podrían obtener diferentes conclusiones y siendo esta la base del proyecto
donde se especifican las necesidades y funcionalidades que el software debe
cumplir, es importante que tanto desarrolladores como clientes lleguen a un
consenso que satisfaga a ambos y por lo tanto, se requiere realizar consultas con
los clientes del sistema y los usuarios finales para obtener el mejor resultado, cabe
destacar que esta etapa es fundamental pues es la base de todo el proyecto y en
modelos convencionales representará el éxito o fracaso del mismo, la etapa de
definición y análisis de requerimientos se divide en distintas actividades que se
complementan entre sí.
Antes de iniciar con la definición de los requerimientos es importante conocer cuáles

son o cómo están identificados, según Sommerville (2005) a menudo los
requerimientos de software se clasifican como:
● Requerimientos funcionales: Son aquellos que nos dan una idea abstracta
de los servicios que el software debe realizar, es decir, nos indican cómo
debería responder, reaccionar o comportarse, de acuerdo con las entradas
que el usuario realice en determinadas situaciones. Sin embargo, en algunos
casos, estos requerimientos también nos permiten comprender el
comportamiento que el software no debe tener.
● Requerimientos no funcionales: Son requerimientos que no tienen relación
directa con los servicios o respuestas que entrega el sistema al usuario, es
26
decir, se suelen aplicar al sistema como un todo, y no como una característica
individual, suelen estar impuestas por los estándares e incluyen restricciones
que pueden estar relacionadas con la fiabilidad, el uso de almacenamiento y
el tiempo de respuesta del software.
Además de la clasificación de los requerimientos de software, existen también

herramientas que nos permiten la recolección de los mismos, estas pueden ser de
carácter formal e informal y cada una es un método de obtención distinto a la otra,
aunque todas comparten un propósito entre sí.
Entre las herramientas para la adquisición de requerimientos del software se

encuentran los cuestionarios, los cuales describen Kendall y Kendall (2011) como
un conjunto de preguntas con respuestas abiertas que los usuarios clave en la
organización pueden responder sin un horario específico, por las cuales se obtendrá
información de los procesos y dificultades que los usuarios viven al verse afectados
por el sistema actual o por el propuesto, al ser preguntas abiertas, los usuarios
pueden narrar con sus propias palabras los procesos e incluso sugerir
funcionalidades para el software que podrían ser de utilidad para ellos, logrando así
una comprensión más completa del entorno de trabajo.
La siguiente herramienta es la observación, es un método de obtención de

información pasiva, pues Somerville (2005) expone que no requiere una
participación activa de los usuarios, en esta, los desarrolladores deben prestar
atención a cómo los usuarios llevan a cabo sus actividades y permite a los
desarrolladores comprender cuales son los puntos a mejorar en cuanto a la
eficiencia de los procesos.
Y, por último, una de las herramientas vitales para la recopilación de requerimientos

son las entrevistas. Kendall y Kendall (2011) exponen que, las entrevistas suelen
ser el método ideal en la mayoría de los casos, estas pueden contener preguntas
de dos tipos, las cerradas o también llamadas formales, donde los entrevistados
responden a las preguntas seleccionando de un conjunto de respuestas
preestablecidas la más acertada según su perspectiva y las abiertas o informales,
27
donde los entrevistados exponen las necesidades y conflictos a los que debe dar
solución el software, es importante hacer uso de ambos tipos de preguntas ya que
estas son complementarias entre ellas y proveen de valiosa información a los
desarrolladores, lo cual les permite tener un panorama más amplio del contexto en
que se desenvolverá el sistema informático.
2.1.3 Análisis y diseño de software
El análisis y el diseño en un proyecto de software son las etapas en las que los
desarrolladores analizan todas las ideas, explicaciones y necesidades recopiladas
en la etapa de definición de requerimientos se comienzan a aterrizar y a plasmar en
diversos diagramas y modelados, Sommervile (2005) explica que “La gestión
efectiva de un proyecto de software depende de planificar completamente el
progreso del proyecto” (p. 88), es decir que, es aquí donde las aptitudes de los
ingenieros de software cobra más relevancia, pues deben ser capaces de usar la
información recabada en la etapa anterior y proponer una solución que atienda
todas las necesidades de los usuarios así como, manejar y mejorar los procesos
para los que se inició este desarrollo.
El análisis consta de tomar la información que ya se recabó y especificar de manera

concreta y minuciosa las características operacionales del software, ya que como
Kendall y Kendall (2011) proponen, este sirve a su vez, para delimitar el alcance del
proyecto, esta es una fase bastante delicada del desarrollo, pues es bastante
proclive a una mala interpretación o propenso a generar ambigüedades que son
difíciles de analizar correctamente y, que pueden trascender como errores en las
demás etapas del proyecto.
El diseño del software es completamente dependiente del análisis previamente

realizado, usando modelados como el diagrama de casos de uso, el modelo de base
de datos o el diagrama de módulos del sistema, se comien za a tener una noción
completa del resultado final, junto a las pantallas frías, se comienzan a hacer
palpables las ideas que se recopilaron entre desarrolladores y clientes.
28

de datos o el diagrama de módulos del sistema, se comienza a tener una noción



29

2.1.4 Codificación
Esta etapa tiene como fin traducir en un lenguaje comprensible para la computadora
las instrucciones del diseño desarrollado en las etapas anteriores, en ella participan
los lenguajes de programación, así como los paradigmas o modelos de desarrollo
apropiados, según Maida y Paziencia (2015), “la complejidad y la duración de esta
etapa está íntimamente relacionada al o a los lenguajes de programación utilizados,
así también como a la calidad del diseño previamente realizado” (p. 30).
2.1.5 Pruebas
Durante esta fase se realiza una última revisión de las especificaciones, diseño y
codificación para garantizar la calidad del software. Dependiendo del modelo de
desarrollo que se implemente, es como se realizarán las pruebas correspondientes
del producto, por ejemplo, existen modelos como el iterativo por mencionar alguno,
donde las pruebas se realizan en cada iteración del desarrollo, hasta la versión final
del software.
Según Alonso y Martínez (2005):
Esta etapa incorpora pruebas de unidad, integración y de validación. Las

pruebas de “unidad” validan la eficacia funcional de cada módulo del sistema.
Las de “integración” validan la eficacia funcional de los subsistemas y de todo
el sistema software. Y las de “validación” validan que todos los
requerimientos han sido incorporados. (p. 88)
30
2.1.6 Implementación
La fase de implementación consiste en la aplicación del software en el entorno de

trabajo para el que fue diseñado e involucra muchas personas, herramientas y
recursos por lo que suele ser la más costosa, además consume mucho tiempo
debido a que las etapas previas son completadas en esta fase.
Tal como lo describen Maida y Paziencia (2015), “en la fase de implementación se

instala el nuevo sistema de información para que empiece a trabajar y se capacita
a sus usuarios para que puedan utilizarlo” (p. 32).
2.1.7 Operación y mantenimiento
La etapa de operación y mantenimiento involucra actividades de mejora del software

mediante retroalimentación de los usuarios, en esta etapa se pretende dar
seguimiento al proyecto, actualizándolo de manera periódica durante su ciclo de
vida útil en respuesta a los nuevos requerimientos y necesidades del usuario.
De acuerdo con Sommerville (2005), “aunque los costos de «mantenimiento» son a

menudo varias veces los costos iniciales de desarrollo, el proceso de mantenimiento
se considera a veces menos problemático que el desarrollo del software original” (p.
76).
2.2 Paradigmas de desarrollo de software
Un paradigma de programación es un modelo de diseño y desarrollo básico de

programas, es decir, se refiere a la forma en que los programadores dan solución a
problemas definidos. Es importante mencionar que, los lenguajes de programación
se encuadran en uno o varios paradigmas a la vez a partir del tipo de órdenes que
pueden implementar, por lo tanto, hay que tomar en cuenta las características de
los paradigmas para identificar cual es el adecuado para ofrecer soluciones más
óptimas y funcionales (Domínguez, 2005).
Existen diversos paradigmas de programación que se diferencian entre sí, sin

embargo, entre los paradigmas más destacados y más relevantes para esta
31
investigación se encuentran la programación estructurada, procedimental y
orientada a objetos.
2.2.1 Programación estructurada
La programación estructurada es un paradigma de programación imperativa, fue la

primera forma de organización de un programa aceptada de manera universal,
sugieren Martínez y Quetglás (2003) que para ello debe cumplir con objetivos
específicos como los siguientes:
1. Debe ser fácil de leer y comprender leyendo el código.

2. Debe ser fácil de localizar los errores del programa (depurar).
3. Debe ser fácil de ampliar o modificar de acuerdo a especificaciones.
4. Debe permitir el trabajo colaborativo en un mismo programa.
Tomando en cuenta las características anteriores, la programación estructurada

organiza los programas en un orden jerárquico y descendente siguiendo un método
que resuelve determinado problema y que este a su vez, está dividido en
subproblemas donde es más fácil identificar cada uno de ellos gracias a la
organización con la que se representan y, por ende, son más fáciles de resolver
debido a que se convierten en problemas más sencillos. Su objetivo es el desarrollo
de programas fiables y fácilmente mantenibles, estableciendo una pauta
disciplinaria que permita leer más fácilmente cualquier programa desarrollado bajo
este paradigma.
2.2.2 Programación procedimental
La programación procedimental, también llamada operacional es un paradigma

imperativo y su principal característica es el orden computacional que se realiza
etapa a etapa y que permite resolver un problema.
De acuerdo con Domínguez (2005), “los programas realizados con lenguajes

procedimentales deben incluir en su codificación las instrucciones de control para
determinar el flujo de la ejecución, como decisiones, iteraciones y otras,
conformando, de esta manera, diferentes algoritmos” (p. 8).
32
A su vez tiene una estrecha relación con la arquitectura de la computadora y pueden
ser implementados al principio, de manera muy eficiente (Ruíz, 2001).
2.2.3 Programación orientada a objetos
El paradigma orientado a objetos es uno de los más populares en el área de la

programación, se fundamenta en los conceptos de objetos y clases de objetos en
donde, un objeto es una variable a la cual pertenecen un conjunto de operaciones
o están definidas para ellos (Ruíz, 2001). Lo que diferencia a la programación
orientada a objetos de la programación tradicional es la forma de colocar todos los
atributos y métodos de un objeto dentro de una clase (Kendall y Kendall, 2005).
De manera general de acuerdo con Rodríguez, Sosa y Prieto (2004), los aportes de
este paradigma se resumen en:
● Conceptos de clase y objeto, que proveen una percepción del mundo

centrada en los seres y no en los verbos.
● Los datos son englobados en el concepto de clase. Acceder a los datos se
lleva a cabo de forma controlada e independiente de cómo se representan
finalmente los mismos. A resultado de ello el mantenimiento y la evolución
de los sistemas se vuelven más sencillos, dado que las distintas partes del
sistema se vuelven independientes.
● A través de criterios como la composición, la herencia y el polimorfismo se
logra hacer más simple el desarrollo de sistemas. La composición y la
herencia nos da la oportunidad de formar clases partiendo de otras clases, lo
que permite aumentar significativamente la reutilización de código.
2.2.3.1 Lenguajes de programación orientada a objetos
Existen diferentes lenguajes de programación cada uno de ellos se enmarca en uno

o varios paradigmas a la vez a partir del tipo de órdenes que pueden implementar
(Domínguez, 2005). En el caso del paradigma orientado a objetos, hay lenguajes
que soportan o no algunas de sus características, sin embargo, dada su popularidad
han surgido una gran cantidad de lenguajes que se adaptan a hacer más sencilla
su implementación.
33
2.2.3.1.1 Java
Java es un lenguaje de programación orientado a objetos de alto nivel y de

propósitos generales, el principal motivo para la creación de este lenguaje fue
permitir que se crearan programas que funcionaran en internet y Web.
De acuerdo con Groussard (2012), Java aportó una respuesta eficiente a

necesidades como:
● Ser un lenguaje de sintaxis sencilla, orientada a objetos e interpretada, que

optimiza la compilación y ejecución.
● Las aplicaciones se pueden portar sin necesidad de hacer modificaciones
para su funcionamiento en diversas plataformas y sistemas operativos.
● Su mecanismo de detección de errores permite escribir programas sin error,
comparado con C++, por ser un más estricto y evolucionado mecanismo.
Al mismo tiempo, de manera general Groussard (2012) lo describe como “un

lenguaje sencillo, orientado a objetos, distribuido, interpretado, robusto, securizado,
independiente de las arquitecturas, portable, eficaz, multihilo y dinámico” (p. 12).
2.2.3.1.2 Ruby
Ruby es un lenguaje de programación creado siguiendo la tradición de los lenguajes

más adelantados de su época, es un lenguaje interpretado, de código abierto y
orientado a objetos, está inspirado en los lenguajes Perl y Python, con la diferencia
de que en Ruby es más orientado a objetos, es decir, todo en este lenguaje son
objetos. De acuerdo con Guillén (2007), “Ruby es un lenguaje genérico que se
puede utilizar en muchos campos: desde procesamiento de texto y programación
web con CGI, hasta ingeniería, genética, y programación comercial a gran escala”
(p. 4).
Este lenguaje reúne las características de lenguajes como Java, C, Python, entre
otros, en ello radica su popularidad. Algunas de sus características de acuerdo con
Pérez y Esquivel (2007) son las siguientes:
34
● Es poderoso: Combina la potencia de los lenguajes orientados a objetos con
los basados en scripts.
● Simple: Su sintaxis y semántica son intuitivas y muy limpias.
● Transparente: No es necesario compilar el código para cada mejora o para
adiciones de nuevos módulos.
● Posee alta disponibilidad: Se pueden generar aplicaciones y ejecutarlas sin
ningún inconveniente en sistemas como Unix, Linux, entre otros.
2.2.3.1.3 Python
El lenguaje de programación Python, contiene estructuras de datos implícitas como,

listas, diccionarios, conjuntos y tuplas, lo cual lo convierte en un lenguaje de alto
nivel, este lenguaje permite realizar tareas más complejas de manera más legible y
con pocas líneas de código. Según lo indican Challenger, Díaz y Becerra (2014),
“Python, a diferencia de otros lenguajes interpretados, ha implementado toda su
librería estándar en el lenguaje C, lo que hace que sus funciones primitivas sean
bastante eficientes” (p. 5).
Conforme a lo escrito por Marzal y Gracia (2003), Python tiene una serie de ventajas
que lo hacen muy atractivo, entre las cuales se encuentran:
● Es muy expresivo, es decir, los programas suelen ser más consistentes y

cortos que su equivalente en un lenguaje como C.
● Es muy legible: Su sintaxis suele ser muy formal, lo cual permite que la
escritura del código sea más cómoda y sencilla que con otros lenguajes de
programación.
● Su entorno es muy interactivo, esto favorece la realización de las pruebas y
permite aclarar dudas respecto al lenguaje.
● El entorno de ejecución descubre muchos de los errores en la programación,
que generalmente pasan desapercibidos por los controles de los
compiladores y permite corregirlos de una manera más sencilla.
● Python es versátil, lo cual permite que pueda usarse como lenguaje
procedimental u orientado a objetos.
35
2.2.3.1.4 C#
El lenguaje de programación C#, es una evolución de los lenguajes C y C++, es un

lenguaje de alto nivel que pertenece al paquete .NET de Microsoft, permite crear
programas en interfaces gráficas de usuario o en interfaces de texto como las
aplicaciones de consola ya sean convencionales o para internet, además es un
lenguaje orientado a objetos
De acuerdo con Sánchez (2016) “C# es un lenguaje de programación que toma las
mejores características de lenguajes preexistentes como Visual Basic, Java o C++
y las combina en uno solo” (p. 1). Además, Sánchez (2016) sugiere algunas de las
características más destacables de C# son las siguientes:
● Sencillez: C# elimina elementos de otros lenguajes que son innecesarios y

que se incluyen en otros lenguajes.
● Modernidad: C# incluye elementos que han demostrado a lo largo del tiempo
que son muy útiles para desarrollar aplicaciones.
● Orientado a objetos: A diferencia de lenguajes como C y C++, C# es más
puro, todo el código debe ser bien definido dentro de tipos de datos, esto
reduce significativamente los conflictos de nombre y hace más sencilla la
lectura del código.
● Gestión automática de memoria: C# tiene un mecanismo a través de la
instrucción using, que permite la liberación de recursos de memoria.
● Instrucciones seguras: C# tiene restricciones en el uso de algunas de sus
instrucciones de control, lo que permite evitar errores comunes.
● Extensibilidad de operadores: C# admite cambiar el significado de la mayor
parte de sus operadores ya sea para conversiones explícitas o implícitas
cuando son aplicadas a diferentes tipos de objetos.
● Eficiente: En C#, pueden saltarse algunas restricciones mediante del uso de
punteros en circunstancias donde sea requerida la eficiencia y velocidad de
procesamiento muy complejos.
36
2.2.3.2 Herramientas y entornos de desarrollo de software
Los entornos de desarrollo son herramientas usadas por los programadores con las
cuales, mediante código escrito en un lenguaje de programación, crean software.
Ciertamente se puede realizar la programación de estos sistemas mediante editores
o compiladores (incluso con depuradores), pero lo más recomendado es usar un
IDE, por sus siglas “Integrated Development Environment”, o en español “Entorno
de Desarrollo Integrado” (Moreno, 2018).
Según Moreno (2018), un IDE consta de las siguientes herramientas:
1. Editor: Generalmente utilizado para colorear la sintaxis del código y ayudar

al programador a comprender mejor el programa y detectar fácilmente
errores.
2. Compilador o intérprete: Dependiendo del lenguaje utilizado, se necesitará
para la ejecución el intérprete o el compilador para la generación del código
ejecutable.
3. Depurador (intérprete): Un buen depurador suele tener un intérprete para
ejecutar órdenes paso a paso e inspeccionar el funcionamiento del código.
4. Constructor de interfaces gráficas: Ayuda al desarrollador a la creación de
ventanas, botones, campos de texto y todos los componentes necesarios
para una interfaz gráfica.
Visual Studio es un entorno de desarrollo integrado creado por Microsoft, que

incluye la última tecnología de esta empresa. Visual Studio 2013 es una herramienta
enorme, según Johnson (2014) puede llegar incluso a ser intimidante para los
nuevos usuarios y difícil para los desarrolladores experimentados, pero es una
herramienta muy completa, además de tener todas características de un IDE,
cuenta con el soporte para múltiples lenguajes de programación, integración a los
servicios en la nube desarrollados por Microsoft y a su vez, una variedad de
versiones que se adecúan a las necesidades de cada usuario, entre ellas está la
versión “community”, que es una versión gratuita que permite a los estudiantes
desarrollar sus proyectos con prácticamente todas las funciones del IDE disponibles
37
sin costo adicional, lo cual lo hace una de las herramientas más completas en el
mercado.
XAMPP es una distribución de Apache gratuita y que permite una fácil instalación
que engloba herramientas como MariaDB, PHP y Perl. El paquete de instalación de
XAMPP ha sido diseñado para ser increíblemente fácil de instalar y usar (Apache
Friends, s.f.). Al ser un paquete de herramientas tan completo y gratuito, es perfecto
para proyectos de desarrollo de estudiantes o de software libre. El manejador de
base de datos MariaDB funciona con las mismas instrucciones que manejadores de
base de datos como MySQL, siendo ésta la principal herramienta de interés de este
paquete de software, así mismo, su integración con el servidor local Apache, permite
alojar la base de datos en una computadora y permitir el acceso a otros equipos
conectados por red, permitiendo así que un software desarrollado con la posibilidad
de acceder a bases de datos remotas, permita trabajar desde diversas terminales
manteniendo la información centralizada y actualizada para el resto de los equipos,
permitiendo a su vez, la gestión y visualización por medio de la herramienta
phpMyAdmin, la cual necesita del lenguaje de programación PHP incluido en el
paquete de software XAMPP.
2.3 Calidad del software
La calidad del software es un tema ampliamente reconocido en la actualidad esto

ha conllevado a que se le dé mayor relevancia y se tome mayor conciencia sobre lo
que implica, misma razón por la que las compañías han ido adoptando nuevas y
mejores técnicas y herramientas para el desarrollo.
De acuerdo con Moreno, Bolaños y Navia (2010), “la calidad del software se refiere
al conjunto de atributos deseables que posee un producto software, los cuales son
medibles (cuantitativa o cualitativamente), permitiendo hacer comparaciones para
conocer si se cumple con las expectativas del cliente o no” (p. 41).
Sin embargo, definir el concepto de calidad del software resulta más complejo de lo
que parece, esto debido a que la acepción de dicho concepto depende la mayoría
de las veces de la percepción y el ángulo del que se le mire.
38
2.3.1 Conceptos de calidad
Distintas percepciones sobre la calidad del software lo han convertido en un

concepto un tanto ambiguo que puede parecerse o diferir de entre un significado u
otro, por lo tanto, es importante conocer las definiciones de dicho concepto desde
la perspectiva de cada uno de los in volucrados en el desarrollo del software, estos
pueden ser los usuarios, desarrolladores, la empresa misma, entre otros.
La calidad del software es una meta importante para los desarrolladores, pero
difícilmente se puede definir como un todo, Pressman (2010) lo define de manera
más general, como “proceso eficaz de software que se aplica de manera que crea
un producto útil que proporciona valor medible a quienes lo producen y a quienes lo
utilizan" (p. 340).
Además, Garvin (1984) citado en Pressman (2010, p. 339) en un nivel algo

pragmático sugiere que, “la calidad es un concepto complejo y de facetas múltiples”
y puede describirse desde cinco diferentes puntos de vista, los cuales se presentan
en la tabla 2.1.
Tabla 2.1 Tabla de percepciones del concepto de calidad
Tipo de punto de vista. Concepto de la calidad del software.
Indica que la calidad es algo que se reconoce de

Punto de vista trascendental
inmediato, pero que no es posible def inir explícitamente.
Concibe la calidad en términos de las metas específ icas

Punto de vista del usuario
del usuario f inal. Si un producto satisf ace, tiene calidad.
La def ine en términos de las especif icaciones originales

Punto de vista del f abricante
del producto, si este las cumple, tiene calidad.
Sugiere que la calidad tiene que ver con las

Punto de vista del producto
características inherentes de un producto.
La mide de acuerdo con lo que el cliente está dispuesto

Punto de vista basado en el valor
a pagar por un producto.
Fuente: Adaptado de Pressman (2010) que cita a Garvin (1984).
39
Además de las definiciones sobre el concepto de calidad del software, también
existen diferentes factores de la calidad según autores como Garvin, McCall y el
estándar ISO 9126 citados en Pressman (2010).
Garvin (1987) citado en Pressman (2010) propone 8 dimensiones, estas son la

calidad del desempeño, calidad de las características, confiabilidad, conformidad,
durabilidad, servicio, estética y percepción. Y aunque, no fueron desarrolladas para
el software únicamente, son aplicadas a la calidad de este.
Por otro lado, McCall (1977) citado en Pressman (2010) propone una clasificación
útil de los factores de la calidad del software y son, corrección, confiabilidad,
eficiencia, integridad, usabilidad, facilidad de recibir mantenimiento, flexibilidad,
susceptibilidad de someterse a pruebas, portabilidad, reusabilidad e
interoperabilidad, sin embargo, cabe mencionar que es difícil realizar mediciones
directas de estos factores de la calidad.
A su vez, también existen los factores de la calidad según ISO 9126, que fue
desarrollado para identificar los atributos clave de cómputo, los 6 atributos clave son
funcionalidad, confiabilidad, usabilidad, eficiencia, facilidad de recibir mantenimiento
y portabilidad (Pressman, 2010).
De acuerdo con esta información, Pressman (2010) plantea tres diferentes

perspectivas acerca de los factores que incluye la calidad del software y en más de
uno de ellos los autores coinciden, lo cual nos permite tener una noción más clara
sobre lo que conlleva el concepto de calidad del software.
2.3.1.1 Estándares de calidad
Un estándar de calidad es una serie de recomendaciones que deben seguirse para

la entrega de productos, dentro de la ingeniería de software, hay diversos
estándares para los diversos productos y procesos que se llevan a cabo , desde la
documentación, hasta el producto final, como explica Córdova (2015) “Los
estándares de calidad son aquellos que permiten definir un conjunto de criterios de
desarrollo que guían la forma en que se aplica la Ingeniería del Software” (p. 39),
esto permite a los equipos de desarrollo trabajar de forma conjunta aumentando la
40
productividad, puesto que estandarizar las entradas y salidas de los procesos
realizados por cada miembro del equipo, hace que no existan pasos intermedios
extra entre el final de un proceso y el inicio del siguiente.
Así mismo, dentro de la ingeniería de software, los estándares se dividen en dos

grupos importantes, el primer grupo es el de estándares de producto, los cuales son
aplicados al producto de software que comienza a desarrollarse y que incluyen a los
estándares de documentación, como encabezamiento de comentarios estándar
para definir clases y estándares de codificación, mismos que indican el cómo debe
usarse el lenguaje de programación. El segundo grupo es el de los estándares de
proceso, los cuales definen los procesos que deben seguirse durante el desarrollo
del software, estos incluyen definiciones de procesos de especificación, diseño y
validación, así como una descripción de los documentos que deben escribirse en la
realización de estos procesos (Somerville, 2005).
El seguimiento de los estándares tanto en los procesos, como en los productos, es

la meta que deben buscar los equipos de desarrollo, cumplir con las normas y
especificaciones en un proyecto, certifica a éste de haber creado un producto de
calidad, como menciona Pantaleo (2011) “un fin para el cual se ha utilizado estos
modelos ha sido la calificación, clasificación y comparación de empresas por parte
de los compradores de productos de software” (p. 25), esto quiere decir, que si un
equipo de desarrollo es capaz de realizar productos de calidad, sustentados en el
cumplimiento de las métricas y normativas validadas por un estándar, es más
atractivo para los compradores, pues reflejan seguridad y profesionalismo, lo cual
hace que los posibles clientes valoren de mejor manera su trabajo.
Existen diversas entidades nacionales e internacionales que desarrollan

estándares, entre los cuales podemos encontrar:
● ISO (International Organization for Standardization): Es una organización
mundial no gubernamental independiente con una membresía de 166
organismos nacionales de normalización. A través de sus miembros, reúne
a expertos para compartir conocimientos y desarrollar Normas
Internacionales voluntarias, basadas en consenso y relevantes para el
41
mercado que respaldan la innovación y brindan soluciones a los desafíos
globales (ISO, 2021).
● IEEE (Institute of Electrical and Electronics Engineers): Es una organización
que promueve la innovación y excelencia tecnológica en beneficio de la
humanidad, es la sociedad técnica más grande del mundo (IEEE, 2021).
● W3C (World Wide Web Consortium): El Consorcio World Wide Web es una
comunidad mundial donde organizaciones, personal de tiempo completo y el
público trabajan en conjunto en el desarrollo de estándares web. Dirigido por
el inventor y director de la Web Tim Berners-Lee y el CEO Jeffrey Jaffe, la
misión del W3C es llevar la Web a su máximo potencial (W3C, 2021).
Así mismo existen diversos estándares para la ingeniería de software, algunos de

ellos son:
● ISO/IEC 9126: Su finalidad es la de cuantificar los productos de sof tware,
esta norma describe las características de la calidad del software, fue
diseñada con los siguientes factores: calidad de proceso, calidad de
producto, calidad del software y calidad de uso (Acosta, Espinel y García,
2017).
Este sistema establece seis atributos clave de la calidad, el primer atributo
es la funcionalidad, que se trata del nivel en el que el software cumple con
las necesidades planeadas y de acuerdo con los subatributos: adaptabilidad,
exactitud, interoperabilidad, cumplimiento y seguridad. El segundo atributo
es la confiabilidad, la cual comprende el tiempo en el que el software está
disponible para ser utilizado según los siguientes subatributos: madurez,
tolerancia a fallas y recuperación. El tercer atributo es la usabilidad, que se
refiere al nivel en el que el software es de fácil uso, según lo indican los
siguientes subatributos: entendible, aprendible y operable. El cuarto atributo
es la eficiencia, el cual describe el nivel en que el software utiliza de forma
óptima los recursos del sistema, de acuerdo con los subatributos:
comportamiento del tiempo y de los recursos. El quinto atributo es la facilidad
de recibir mantenimiento, el cual se refiere a la facilidad en la que se puede
42
efectuar una reparación al software, según lo establecen los siguientes
subatributos: analizable, cambiable, estable, apto para someterse a pruebas.
Y el último atributo, es la portabilidad, que es la facilidad con la que el
software puede llevarse de un ambiente a otro, según lo indican los
subatributos: adaptable, instalable, conformidad y sustituible (Pressman,
2010).
● CMMI: Sucesor de CMM es el modelo de referencia más difundido a nivel

mundial, brinda una guía integrada de lineamientos para el desarrollo de
productos y procesos, centrándose en las mejores prácticas del desarrollo de
software (Córdova, 2015).
Es un modelo bastante complejo, pero se puede simplificar en tres grupos

importantes de características, el primero es el de áreas de proceso, en el
cual se identifican 24 áreas de procesos relevantes para la capacidad y
mejora del proceso de software, el segundo grupo es el de metas, las cuales
son descripciones abstractas de un estado deseable que debería ser
alcanzado por una organización, en CMMI se establecen metas asociadas a
cada área de proceso y que definen el estado deseable de esa área, aunque
también cuenta con metas genéricas que son asociadas con la
institucionalización de buenas prácticas, el tercer grupo es el de las prácticas,
las cuales son descripciones de vías para con seguir una meta, estas se
pueden asociar hasta a sietes prácticas específicas o genéricas con cada
meta dentro de cada área de procesos, aunque CMMI reconoce que lo
importante es la meta y no el camino que lleva hacia ella (Somerville, 2005).
● MoProSoft: De acuerdo con Pilar (2007) se define como:

Un modelo de procesos para el desarrollo y mantenimiento de
software dirigido a la pequeña y mediana industria y a las áreas
internas de desarrollo de software. Su objetivo principal es incorporar
las mejores prácticas en gestión e ingeniería de software. Su
43
incorporación en la industria eventualmente permitirá elevar la
capacidad de ofrecer productos y servicios de software con calidad.
MoProSoft fue desarrollado por expertos mexicanos que recopilaron

las experiencias exitosas de la industria de software a nivel mundial,
las adaptaron a las necesidades y características de las pequeñas y
medianas industrias mexicanas (Pymes) desarrolladoras de software.
(p.3)
Los procesos realizados son cuidadosamente detallados a través de un

instrumento llamado parón de procesos, esta descripción está dividida en tres
partes, la descripción general, la descripción de prácticas y la guía de ajustes.
La descripción general incluye los siguientes componentes: nombre del
proceso, categoría, propósito, descripción, objetivos, indicadores, metas
cuantitativas, responsabilidad y autoridad. La descripción de la práctica que
incluye: roles involucrados y capacitación, actividades, diagrama de flujo de
trabajo (en UML), verificaciones y validaciones, incorporación a la base de
conocimiento, recursos de infraestructura, mediciones, capacitación,
situaciones excepcionales, lecciones aprendidas.
MoProSoft determina el nivel de madurez de la capacidad de cada proceso

mediante una evaluación, la cual permite colocar a la empresa en uno de los
5 niveles, los cuales son, 1. Proceso Realizado, 2. Proceso Administrado, 3.
Proceso Establecido, 4. Proceso Predecible y 5. Optimización de procesos.
Existe a su vez un nivel 0, el cual indica que el proceso está incompleto. Para
pasar de un nivel a otro, la empresa debe cumplir con los requisitos de los
niveles anteriores además de los del nuevo nivel (Pilar, 2007).
2.3.2 Aseguramiento estadístico de la calidad del software
El aseguramiento estadístico de la calidad del software es un concepto

relativamente simple pero importante ya que representa la creación de un proceso
adaptativo del software en donde se realizan cambios para la mejora de elementos
del proceso que producen errores. (Pressman, 2010)
44
Este proceso estadístico requiere que se realicen los siguientes pasos según lo
explica Pressman (2010):
1. Se recaba y clasifica la información acerca de errores y defectos del software.

2. Se hace un intento por rastrear cada error y defecto hasta sus primeras
causas (por ejemplo, no conformidad con las especificaciones, error de
diseño, violación de los estándares, mala comunicación con el cliente, etc.).
3. Con el uso del Principio de Pareto (80 por ciento de los defectos se debe a
20 por ciento de todas las causas posibles), se identifica 20 por ciento de las
causas de errores y defectos (las pocas vitales).
4. Una vez identificadas las pocas causas vitales, se corrigen los problemas
que han dado origen a los errores y defectos. (p. 374)
De acuerdo con Pressman (2010), la estrategia más utilizada para el aseguramiento
estadístico del software es Seis Sigma y se trata de una metodología que utiliza
datos y análisis estadísticos para la medición y el mejoramiento en el rendimiento
operativo de una empresa para identificar y eliminar defectos en el proceso de
producción y servicios.
Las etapas que Seis Sigma sugiere y que son fundamentales y algunas de ellas
adicionales de acuerdo con el tipo de proceso que se requiere mejorar son: Definir,
medir, analizar, mejorar y controlar (Pressman, 2010).
2.3.3 Técnicas de aseguramiento de la calidad de software
El concepto de calidad de software es complejo, como Somerville (2005) describe

“no es directamente comparable con la calidad de la manufactura de productos” (p.
588), pero su concepto ha ido desarrollán dose con el tiempo, se han propuesto
diversas técnicas para el aseguramiento de la calidad de un software, estas
proponen que además de tomar en cuenta las características necesarias para su
desarrollo, también deben aplicarse métodos de la ingeniería de software y técnicas
para la administración de proyectos, acompañados del control de calidad, por lo que
al respecto Pressman (2010) menciona el establecimiento de características tales
45
como la confiabilidad, usabilidad, facilidad de dar mantenimiento, funcionalidad y
portabilidad como indicadores de calidad.
Es importante aplicar el aseguramiento de calidad de software desde las fases

tempranas de un ciclo de desarrollo, pues debe crearse una base firme para el
proyecto y así continuar con un constante proceso de mejora, buscando conseguir
un número de fallos significativamente menor al llegar a las etapas finales, sobre
esto Córdova (2015) explica que:
La Gestión de la Calidad es un proceso con una sola filosofía de trabajo:

lograr conseguir mayor confiabilidad, mantenibilidad y facilidad de prueba,
elevando en gran número la productividad, tanto para desarrolladores como
para el área de control de la calidad del software. (p. 19)
Siendo una constante el uso de conceptos como la confiabilidad y la facilidad de dar

mantenimiento como reflejo de calidad. Retomando la gestión de calidad, Córdova
(2015) expone que:
Un Sistema de Gestión de la Calidad significa disponer de una serie de

elementos como Procesos, Manual de la Calidad, Procedimientos de
Inspección y Ensayo, Instrucciones de Trabajo, Plan de Capacitación,
Registros de la Calidad, entre otros, todo funcionando en equipo para
producir bienes y servicios de la calidad requerida por los clientes. (p. 19)
De manera que, el proceso de aseguramiento de calidad se entiende como un

conjunto de procesos, documentos y prácticas enfocadas en minimizar los errores
durante un ciclo de desarrollo de software, potenciando la productividad y
efectividad de los equipos de desarrollo. Existen modelos de desarrollo y
certificaciones, las cuales sirven como guía para los equipos de trabajo, pues
proponen objetivos y presentan un conjunto de buenas prácticas para lograrlos, así
mismo, proveen una forma de evaluación, lo cual permite corroborar que se trata de
un producto de calidad (Pantaleo, 2011).
46
Viendo esto desde el enfoque de la ingeniería de software Kendall y Kendall (2011)
describen los tres métodos para el aseguramiento de la calidad como “1) afianzar
un aseguramiento de calidad total al diseñar sistemas y software con una
metodología modular descendente (arriba-abajo o top-down); 2) documentar el
software con las herramientas apropiadas, y 3) probar, mantener y realizar
auditorías en el software” (p. 515), reafirmando que durante el ciclo de desarrollo,
esta idea proviene de una suposición subyacente de la gestión de calidad, la cual
dice que la calidad de un proceso de desarrollo afecta directamente a la calidad de
los productos derivados (Somerville, 2005).
2.3.2.1 Técnicas de revisión
Las revisiones de software son una parte importante del aseguramiento de la

calidad, estas pueden variar desde lo muy formal hasta lo muy informal, Sánchez
(2015) explica que los objetivos de una revisión son “debatir, tomar decisiones,
evaluar alternativas, resolver problemas técnicos, comprobar la conformidad con las
especificaciones, estándares y normativas y se centran en alcanzar un consenso”
(p. 30). Estos métodos son utilizados para “purificar” los productos, pues pueden ser
usados para descubrir errores y defectos en varios puntos del ciclo de vida del
software y, por consiguiente, antes de liberar el software al usuario final. Las
ventajas que tiene realizar estas revisiones son, detectar a tiempo los errores del
software, de modo que no afecte en las siguientes etapas del desarrollo. La mayor
parte de las fallas del sistema según varios estudios, indican que, es la actividad de
diseño la que introduce la mayor parte de los errores durante el proceso del
software, sin embargo, las técnicas de revisión han demostrado tener una eficacia
muy alta para descubrir las fallas de diseño, al detectar y eliminar estos errores
(Pressman, 2010).
47
2.3.3.1.1 Aplicación de revisión técnica informal
Estas revisiones son muy comunes en un desarrollo, pero no suelen ser muy
reconocidas durante el proceso, esto se debe a que son revisiones sin planeación
previa, no generan documentación precisa de los errores encontrados y corregidos,
pues en su mayoría se tratan de simples conversaciones entre compañeros de
trabajo, los cuales de manera casual revisan el trabajo realizado, es decir, se trata
de una reunión o charla espontánea cuyo tema central es el producto de software o
un aspecto de él, esto hace que la eficacia de este tipo de revisión no se compara
a la eficacia de una revisión formal, pues no es una revisión a profundidad, pero
permite descubrir de manera temprana errores que de otra manera, podrían
esparcirse en otras áreas del desarrollo. Este tipo de revisiones son más notorias
en la programación por pares, como en el modelo de desarrollo XP, de esta manera
las revisiones informales son constantes y se amplía el rango de detecciones de
fallos (Pressman, 2010).
Al ser revisiones de índole espontánea, Sánchez (2015) remarca que “los revisores
carecen de instrucciones escritas, los resultados de las mismas no tienen por qué
estar documentados y el objetivo principal es obtener defectos de forma barata” (p.
29), es decir, que se tratan de revisiones que no se centran en la documentación o
en la formalización de la misma, si no en los resultados y la eficiencia con respecto
al costo y tiempo que estas representan para el desarrollo.
Retomando las revisiones de la programación por pares, Pantaleo (2011) describe

que los roles de una revisión informal son desdibujados y no tienen un
procedimiento definido, también establece que si se alcanza un nivel de madurez y
habilidad para su aplicación, lo números de detecciones de errores de un desarrollo
se elevaría a un 60%, mientras que el 40% restante sería detectado por las pruebas
formales, es decir, que más de la mitad de los fallos en un desarrollo serían
detectados antes de que fuera realizado un test formal, minimizando así el número
de errores que trascienden a una etapa avanzada de un proyecto.
48
2.3.3.1.2 Aplicación de revisión técnica formal
La revisión técnica formal es una actividad de control de calidad del software, esta
involucra a un grupo de personas que examinan todo o parte del proceso de
software, como explica Somerville (2005), este grupo debe tener un núcleo de tres
o cuatro personas, quienes serán los revisores principales, estos a su vez, pueden
invitar a más miembros del proyecto para colaborar en la revisión, con la meta de
tener diversos puntos de vista y ampliar la efectividad de la revisión, estos invitados
no se involucran en toda la revisión, más bien se limitan a participar en las partes
que conciernen a su trabajo. A su vez, Pressman (2010) especifica que los objetivos
de una revisión técnica formal son:
1) descubrir los errores en funcionamiento, lógica o implemen tación de

cualquier representación del software; 2) verificar que el software que se
revisa cumple sus requerimientos; 3) garantizar que el software está
representado de acuerdo con estándares predefinidos; 4) obtener software
desarrollado de manera uniforme y 5) hacer proyectos más manejables. (p.
362)
Todo este proceso es planeado con antelación, se agenda la reunión y es

documentado, todo esto lo diferencia de una técnica informal y como menciona
Córdova (2016) este es un proceso concreto, específico y disciplinado, donde el
equipo de personas que la lleva a cabo, estudia y examina el producto mediante la
lectura, buscando la detección de los defectos tempranamente en el proyecto.
Sánchez (2015) simplifica el concepto describiendo que “se basa en el examen

visual de documentos para detectar defectos como puede ser el no cumplimiento
de estándares de desarrollo. Es un proceso documentado e incluye recopilación de
métricas y un informe con una lista de conclusiones” (p. 30).
Tanto Somerville (2005), como Pressman (2010) coinciden en que la reunión debe
ser corta, con un máximo de 2 horas de duración, durante la cual, se revisan
documentos previamente seleccionados para su evaluación, esto durante la
planeación de la revisión técnica formal, estos documentos deben ser distribuidos
49
con anterioridad, pues los revisores deben leer y comprender con certeza lo que
será tratado durante la reunión, la eficacia de la revisión es dependiente de la
comprensión de los revisores sobre los documentos en cuestión, pues si los
revisores no identifican completamente la meta de la reunión, esta carece de
sentido.
Durante la reunión, acuden los revisores y el productor del proceso de software a

revisar, uno de los revisores toma el papel de “secretario” y es quien se encarga de
registrar los sucesos importantes que surgen durante la revisión, esta inicia con el
análisis de la agenda, seguido de una breve introducción del productor, seguido de
esto, se procede con un “recorrido” del producto del trabajo, explicando el material
y al mismo tiempo, los revisores realizan sus comentarios con base en la
preparación previamente hecha con la documentación que les fue otorgada con
antelación, cuando se descubre un problema o error valido, el secretario toma nota,
al finalizar esta reunión, existen 3 alternativas de decisión, la primera es aceptar el
producto sin modificaciones, la segunda es rechazarlo por errores de gravedad, los
cuales deben ser corregidos para una nueva revisión o como tercer alternativa, el
producto es aceptado de forma provisional, pues aunque tiene errores, estos son
pequeños y no se necesita una segunda revisión luego de su corrección (Pressman,
2010).
2.3.3.1.3 Reporte de evaluación de software
Al finalizar una revisión técnica formal, el revisor que fungió como secretario ha
registrado todos los eventos destacables de la reunión y como describe Somerville
(2005), el responsable de la reunión debe firmar dicho registro, dado que en este
aparecerán todos los comentarios y decisiones tomadas. De estos registros se crea
una lista de pendientes de la revisión, a su vez, se debe producir un reporte técnico
formal de la revisión, como expone Pressman (2010), este reporte responderá a tres
preguntas, 1. ¿Qué fue lo que se revisó?, 2. ¿Quién lo revisó? y 3. ¿Cuáles fueron
los descubrimientos y las conclusiones? De manera que sea fácil conocer los
propósitos de la reunión y quede el registro de lo descubierto en la misma.
50
El resumen del reporte de la revisión debe contener solo una página, este puede
incluir anexos en caso de ser necesarios y será parte del registro del proyecto, debe
ser entregado al líder del proyecto y a otras partes interesadas.
La lista de pendientes de la revisión tiene dos propósitos, el primero, identificar las

áreas cuestionables del producto y segundo, tiene la función de servir como listado
de verificación de acciones y de esta forma guiar al productor cuando se realicen
las correcciones, esta lista también es anexada al reporte técnico en la mayoría de
los casos.
2.3.4 Prueba de aplicaciones orientada a objetos
Las pruebas de software son muy importantes dentro del tema de la calidad del
software y tienen por objetivo convencer a desarrolladores y clientes de que este es
lo suficientemente bueno para iniciar su operación, sin embargo, las pruebas no
pueden demostrar que el software está libre de defectos o que su comportamiento
será siempre el esperado, siempre hay posibilidad de que alguna prueba que haya
pasado desapercibida pueda encontrar problemas adicionales con el sistema
(Sommerville, 2005).
Mera (2016) indica que “las pruebas son necesarias porque con ellas se puede
ayudar a reducir los riesgos en las aplicaciones, y lograr de esta manera que se
identifiquen los defectos antes de que se ejecuten, con esto se previenen los fallos”
(p. 167). Al mismo tiempo sugiere que, “la implementación de un proceso de
pruebas brinda las pautas para definir objetivos, analizar y viabilizar los
requerimientos, diseñar, detallar, programar, implementar y asegurar la calidad de
un producto de desarrollo software” (p. 168).
Las pruebas de software clásicas comienzan con la prueba de unidad,

posteriormente se realiza la prueba de integración y finaliza con las pruebas de
validación y sistema, sin embargo, desde la perspectiva del paradigma orientado a
objetos, el objetivo de las pruebas de software se mantiene invariable, pero, la
naturaleza de los programas cambia en la estrategia y las tácticas de prueba
(Pressman, 2010).
51
a) Pruebas de unidad en el contexto orientado a objetos
De acuerdo con Pressman (2010) cuando hablamos de software orientado a objetos

el concepto de unidad es diferente debido a que las clases y objetos encapsulan los
atributos y operaciones que manipulan dichos datos, y en lugar de que las pruebas
se realicen individualmente, en estos casos, la unidad más pequeña que puede
comprobarse es la clase encapsulada, por lo tanto, ya no es posible probar de
manera aislada una sola operación, si no como parte de una clase.
b) Pruebas de integración en el contexto orientado a objetos
Según lo indica Bradac citado en Pressman (2010) para las pruebas de integración
de los sistemas orientados a objetos, existen dos estrategias diferentes:
La primera es la prueba basada en hebra, la cual constituye el conjunto de clases

que se requieran para dar respuesta a una entrada o evento del sistema, y cada
hebra es integrada y probada de manera individual. La segunda estrategia es la
prueba basada en uso, donde inicialmente se prueban las clases independientes y
posteriormente aquellas llamadas dependientes hasta que se construye todo el
sistema.
De acuerdo con Maida y Paziencia (2015) “en la prueba de integración el foco de

atención es el diseño y la construcción de la arquitectura del software” (p. 31).
c) Pruebas de validación en el contexto orientado a objetos
En las pruebas de validación orientadas a objetos, la atención se enfoca en las

acciones visibles y en las salidas reconocibles por el usuario, para ello se debe
recurrir a los casos de uso que sean parte del modelo de requerimientos, ya que
estos facilitan un escenario con probabilidades altas de descubrir errores de
interacción del usuario (Pressman, 2010).
Según lo indican Maida y Paziencia (2015) “la prueba de validación está constituida
por una serie de pruebas diferentes cuyo propósito primordial es ejercitar
profundamente el sistema basado en computadora” (p. 31).
52
De manera general, cabe mencionar que, según Dijkstra citado en Sommerville
(2005) indica que “las pruebas sólo pueden demostrar la presencia de errores, no
su ausencia” (p. 493).
2.3.4.1 Guía y aplicación de pruebas
Tal como se describe en el tema anterior, Córdova (2015) indica que las pruebas de
software se orientan a la detección de errores, en donde, un buen caso de prueba
tiene una probabilidad alta de detectar defectos del software. Si las pruebas no son
efectivas, pueden ocasionar que el software defectuoso sea entregado al cliente y
esto podría ocasionar graves problemas.
Por lo tanto, la planificación de las pruebas es fundamental a la hora de probar un

proyecto, dado que, hay que tener controlados todos los aspectos que implica,
desde la forma en que se va a probar, el cómo se va a probar, los recursos
disponibles, la documentación del proyecto, entre otros (Sánchez, 2015).
Córdova (2015) sugiere que:
El proceso de pruebas es uno de los más costosos dentro del ciclo de vida
del software, ya que deben realizarse validaciones por cada nivel de pruebas
durante la construcción de un producto, los objetivos de las pruebas en cada
nivel tienen un enfoque diferente y por tanto se aplican diferentes tipos y
técnicas de prueba. (p.31)
Las pruebas funcionales tienen como objetivo probar lo que hace el sistema
enfocándose en los requisitos funcionales y considerando el comportamiento
externo del mismo de acuerdo con las características con las que tiene que cumplir
en cuanto a su funcionamiento y se basan en los casos de uso. Al ejecutar estas
pruebas, se espera que, usando combinaciones de datos válidos, se obtenga el
resultado esperado o, en su caso, se espera que el sistema arroje alertas de error
o precaución, al usar datos inválidos.
Por otro lado, las pruebas no funcionales, se encargan de probar los atributos o el
ambiente del sistema, es decir, los requerimientos no funcionales de este. Realizar
53
estas pruebas no funcionales como lo son la usabilidad, estabilidad, escalabilidad,
eficiencia, seguridad, también permiten la evaluación y medición de la calidad del
software (Córdova, 2015).
Al respecto, Berard citado en Pressman (2010) sugiere un enfoque global en el

diseño de casos de prueba orientado a objetos, el cual hace énfasis en el diseño de
secuencias adecuadas de operaciones para ejercitar los estados de una clase.
Sommerville (2005) indica que “para validar que el sistema satisface los
requerimientos, la mejor aproximación a utilizar es la prueba basada en escenarios,
en la que se idean varios escenarios y se desarrollan casos de prueba a partir de
estos escenarios” (p. 498).
Además, Sommerville (2005) sugiere que:
Para diseñar un caso de prueba, se selecciona una característica del sistema

o componente que se está probando. A continuación, se selecciona un
conjunto de entradas que ejecutan dicha característica, documenta las
salidas esperadas o rangos de salida y, donde sea posible, se diseña una
prueba automatizada que prueba que las salidas reales y esperadas son las
mismas. (p. 504)
Finalmente, en la aplicación de dichas pruebas, autores como Whittaker citado en

Sommerville (2005) han establecido en base a su experiencia de pruebas un
conjunto de guías que incrementan la probabilidad de que las pruebas de defectos
sea un éxito:
1. Elegir entradas que fuerzan a que el sistema genere todos los mensajes
de error.
2. Diseñar entradas que hacen que los búferes de entrada se desborden.
3. Repetir la misma entrada o series de en tradas varias veces.
4. Forzar a que se generen las salidas inválidas.
5. Forzar los resultados de los cálculos para que sean demasiado grandes o
demasiado pequeños. (p.498)
54
Con base en lo anterior Pressman (2010) menciona que, las pruebas basadas en
escenario descubren los errores de interacción, no obstante, para ello los casos de
prueba deben ser más complejos y objetivos debido a que este tipo de prueba
generalmente ejercita múltiples subsistemas en una sola prueba.
2.3.4.2 Reporte de casos de prueba de software
Según lo explica Córdova (2015) “las actividades de prueba del software incluyen la
planificación, diseño, ejecución y reporte sobre los distintos niveles de prueba
existentes durante el proyecto” (p. 24).
Los reportes de prueba pueden anexarse con la especificación de pruebas, si así

se desea o requiere, en él se registran los resultados, problemas o particularidades
de prueba reales. La información incluida en el reporte puede ser trascendental para
la etapa de mantenimiento del software, además ahí se presentan la referencias y
complementos convenientes sobre el mismo. De la misma manera que con otros
elementos de la configuración del software, este formato puede adaptarse a las
necesidades del equipo de desarrollo, sin embargo, es importante señalar que una
estrategia de integración y los detalles de la prueba, son aspectos esenciales y, por
lo tanto, deben aparecer (Pressman, 2010).
2.3.5 Resultados del aseguramiento de la calidad de software
El aseguramiento de la calidad del software es una actividad que se aplica en cada

etapa del proceso del software, donde se incluyen procedimientos para la aplicación
de métodos y herramientas, supervisa las actividades del control de calidad,
revisiones técnicas y las pruebas del software, los procedimientos de control de
cambio y para asegurar que se cumplan las pautas y mecanismos de medición,
además de la elaboración de reportes. Para llevarlo a cabo de manera efectiva
deben recabarse, evaluarse y divulgarse datos sobre el proceso de ingeniería del
software (Pressman 2010).
55
Según lo explican Álvarez, Solé y Quintero (2013):
El objetivo de este proceso es la generación de reportes que permitan

informar a los equipos de desarrollo de las aplicaciones de software
evaluadas las disconformidades observadas tanto en el proceso de
desarrollo como en las aplicaciones, así como algunos otros aspectos que se
consideren pertinentes de reportar. (p.47)
En la elaboración de los reportes del aseguramiento de la calidad, quien evalúa

debe resaltar la importancia de mejorar la calidad de los componentes evaluados,
con el objetivo de desarrollar software que cumpla de manera completamente
satisfactoria las características que han sido definidas para este (Álvarez, Solé y
Quintero, 2013).
La estructura de un proyecto debe ser sólida para asegurar la calidad del producto
final, es importante conocer a profundidad la capacidad de tu equipo, así como el
presupuesto y otros factores que ayuden a discernir el mejor plan de acción. La
elección de un paradigma de desarrollo que se acople a las habilidades del equipo
de desarrollo es vital para optimizar el tiempo de desarrollo y mantener la eficiencia,
así mismo, el realizar las elecciones correctas y aplicar buenas prácticas durante el
proceso, hará más factible el aseguramiento de la calidad del software.
Un software de calidad es importante tanto para el cliente como para el

desarrollador, pues, al ser capaces de hacer productos de calidad, el desarrollador
se vuelve más competitivo en el mercado, mientras que, en el caso del cliente, la
seguridad, confiabilidad y disponibilidad son vitales para que la inversión realizada
en software sea beneficiosa, pues como explica Pressman (2010) “el software que
no tiene alta calidad es fácil de penetrar por parte de intrusos y, en consecuencia,
el software de mala calidad aumenta indirectamente el riesgo de la seguridad, con
todos los costos y problemas que eso conlleva” (p. 349).
Como se ha explicado a lo largo de este capítulo, existe una alta variedad de

lenguajes de programación y modelos de desarrollo, las combinaciones para
trabajar con ellos son inmensas y a esto se suma la elección de herramientas de
56
trabajo que aporten seguridad, estabilidad y ayuden a hacer más eficiente el
proceso de desarrollo, el conocimiento de las habilidades de un equipo ayuda a
delimitar estas opciones y a encontrar la manera óptima de trabajar, es por eso que
se deben valorar diversas posibilidades y elegir las más adecuadas para el perfil del
equipo, estas elecciones son vitales para el proceso de aseguramiento de la calidad,
pues también proporcionan métricas, estándares y parámetros con los cuales guiar
y calificar el proceso de desarrollo.
Para el proceso de desarrollo aplicado en este estudio de caso se realizó el análisis

descrito en este capítulo, basándose en la experiencia y conocimientos del equipo
de desarrollo se decidió trabajar con el paradigma orientado a objetos, pues era el
más acorde al proyecto, dado que se eligió este enfoque, se hizo una valoración de
lenguajes de programación para elegir el más adecuado, de las opciones se llegó a
la conclusión de que C# era el indicado porque permitía la creación de las funciones
requeridas en el software. Como modalidad de trabajo, se concretó que RUP era el
modelo más adecuado, pues el uso de los diagramas UML permite una mejor
comprensión de la idea del proyecto y documentar de manera más certera el mismo.
Como herramienta de desarrollo se hizo uso de Visual Studio, dado que C# es un
lenguaje creado por Microsoft y éste cuenta con una gran integración con este IDE,
siendo la versión Community 2013 la que mejor se acopló a las computadoras
utilizadas en este desarrollo, así mismo, el paquete de software libre XAMPP fue
elegido como complemento de herramientas para el desarrollo, pues contaba con
el manejador de base de datos y el servicio de servidor local necesarios para el
proyecto.
57
CAPÍTULO 3. MARCO CONTEXTUAL
3.1 Sistema Chiapaneco de Radio, Televisión y Cinematografía
El Sistema Chiapaneco de Radio, Televisión y Cinematografía es un organismo

desconcentrado del gobierno del estado de Chiapas, se encarga de la operación de
las diferentes estaciones de radio y televisión del estado, así como, de la promoción
de localidades para producciones de material audiovisual autorizado por la
secretaría de Comunicaciones y Transportes del Gobierno del Estado.
Se centra en la transmisión de contenido cultural e informativo del estado, así como

la trasmisión de programas infantiles y diversos programas en diversos dialectos,
tales como el chol, el tzeltal, el tzotzil y el zoque, llegando así según la información
en su página oficial, al 77.36% del estado y cubriendo el 84.7% de la geograf ía
estatal (Sistema Chiapaneco de Radio, Televisión y Cinematografía, s.f.).
3.1.1 Historia, Misión y Visión
Durante la época de oro del radio en México a finales de los años treinta, el gobierno
del estado de Chiapas decidido incursionar en la radio, fundando la primera
radiodifusora de estado la cual se llamó “XEXJ, La Voz de la Marimba desde
Chiapas”. Mucho tiempo después, en el año de 1973, se fundó una nueva
radiodifusora, que se estableció en el municipio de San Cristóbal de las Casas, esta
emisora llevó de nombre “XERA, Radio Comunidad Indígena” la cual cambió de
nombre tiempo después a “Radio Uno” (Martínez y Cortés, 2008). Tal como expone
Martínez y Cortés (2008), veinte años después, el gobierno del estado comenzó a
establecer más estaciones de radio en diversos municipios del estado, en
posiciones estratégicas de la geografía chiapaneca, estos estados fueron:
Palenque, Ocosingo, Tuxtla Gutiérrez, Tapachula, Tonalá, Tecpatán, Las
Margaritas, Santo Domingo y Pichucalco, hasta construir el Sistema Chiapaneco de
Radio y Televisión.
Con respecto a la televisión, durante el año 1980 y según narran Martínez y Cortés
(2008), Juan Sabines Gutiérrez, el entonces Gobernador del estado de Chiapas,
firmó un convenio en el marco de la Tercera Reunión Nacional de la República en
58
el cual el mandatario, así como algunos de sus homónimos de otros estados, se
comprometían a crear televisoras regionales.
Es así como a su regreso a Tuxtla Gutiérrez, el Gobernador del estado encomendó

a Arturo Toscano hacerse cargo de dicho proyecto, el en ese entonces director de
Comunicaciones y Transportes, quien también en el pasado había trabajado en el
Canal 8 de Monterrey, a su vez Arturo Toscano tenía familiares vinculados con el
mundo del espectáculo, como relatan Martínez y Cortés (2008) “Su tío, Salvador
Toscano Barragán, había ganado un espacio memorable en la cinematografía como
uno de los pioneros del cine en México. De hecho, una de las salas de la Cineteca
Nacional lleva su nombre” (p. 8).
Poco a poco la televisora se fue afianzando y creciendo, así como las diversas
estaciones de radio, según Martínez y Cortés (2008) “El viernes 9 de marzo del año
2001 apareció publicado, en el Periódico Oficial número 24, el decreto con el que
se creaba el organismo público descentralizado denominado Sistema Chiapaneco
de Radio y Televisión” (p. 85), de esta manera, el gobierno del estado intentaba
asegurar el crecimiento y la fomentación de la difusión de programas públicos de
diversa índole, desde orientación, hasta cultura y entretenimien to infantil.
Poco a poco y a lo largo de los años que el Sistema Chiapaneco de Radio,

Televisión y Cinematografía ha crecido hasta consolidarse tal como lo conocemos,
en la actualidad cuenta con 10 radiodifusoras y 1 canal de televisión, así como la
producción de diversos programas originales y la constante promoción de
locaciones del estado para la filmación de cortometrajes y largometrajes aprobados
por la Secretaría de Comunicaciones y Transportes del Gobierno del Estado.
Misión:
Ser un Organismo descentralizado del Gobierno del Estado, que tiene la meta de
producir, coproducir y transmitir programas informativos, culturales y educativos y
atraer empresas que realicen filmaciones audiovisuales, para la población de habla
hispana y lenguas indígenas, desarrollando contenidos que impulsen el desarrollo
humano de los Chiapanecos, a través de la Radio, Televisión y la difusión de las
59
factibles locaciones cinematográficas (Sistema Chiapaneco de Radio, Televisión y
Cinematografía, s.f.).
Visión
Ser el Sistema de Comunicación Audiovisual reconocido a nivel nacional e

internacional, que promueva la calidad de nuestros programas radiofónicos y
televisivos y la diversidad de locaciones factibles para el mercado cinematográfico,
que sirva para contribuir al desarrollo social y económico del Estado de Chiapas
(Sistema Chiapaneco de Radio, Televisión y Cinematografía, s.f.).
3.1.2 Cine, radio y televisión hecho en Chiapas
En el estado de Chiapas, el radio llegó a través de la incursión del gobierno, en el

año 1935, se instaló un radio receptor en la Casa del Pueblo, en Tuxtla Gutiérrez
Chiapas y según nos narran Martínez y Cortés (2008) era utilizado para que todo
ciudadano pudiera escuchar las transmisiones en vivo de La Voz de la América
Latina, programa muy popular en aquellos años y transmitido desde la Ciudad de
México.
Dado este furor sobre las transmisiones de radio, no se tardó mucho tiempo en
fundar XEXJ, La Voz de la Marimba desde Chiapas, aunque su programación era
reducida, pues solo se transmitía una hora y sólo se podía escuchar en la capital
del estado (Martínez y Cortés, 2008). Las transmisiones de dicho programa fueron
ampliándose y fueron dedicadas a la cultura, se dedicaron transmisiones a poetas,
escritores e intelectuales chiapanecos, y los periodistas aplaudieron la propuesta,
pues permitía conocer el trabajo de chiapanecos y fomentaron el arte del estado
entre los ciudadanos.
Con el crecimiento de la popularidad y cultura de las radiodifusoras en el estado,

crecieron también las aspiraciones de consegu ir mejores resultados, pues como
relatan Martínez y Cortés (2008) a pesar de que en La Voz de la Marimba
participaban varios conductores, no se contaba con un locutor profesional, lo cual
sería resuelto por el administrador de la radiodifusora, Artemio López Martínez,
quien realizó un concurso de talentos para encontrar al primer locutor chiapaneco.
60
Armando Arévalo fue el ganador y elegido como el locutor oficial de la XEXJ y varios
participantes del concurso, mantuvieron apariciones en los programas, como Jaime
Sabines, quien fue un declamador habitual en los mismos.
En 1990, Víctor Cancino Villar director de Radio de Gobierno del Estado fundó Red
Radio Chiapas S.A. de C.V., una entidad autónoma encargada de la gestión de
concesiones radiofónicas, esto permitió un mejor manejo de las radiodifusoras del
estado y en 1991 se inauguró la primera estación de radio bajo este modelo
autónomo, esta radiodifusora fue el XEPL, Radio Palenque (Martínez y Cortés,
2008).
Con la llegada del canal televisivo en el año 1980, amplió el abanico de medios de
comunicación en el estado y en 2001 se materializó la creación del Sistema
Chiapaneco de radio y televisión¸ quien de manera autónoma y descentralizada se
encargaría de las estaciones de radio y televisión del estado, tiempo después y
como narran Martínez y Cortés (2008):
La señal televisiva comenzó a expandirse con dos nuevas repetidoras: El

cinco de diciembre de 2002, en el Cerro El Tamborazo, se instaló, con mil
watts de potencia, el XHOLQ-Canal 3 de Palenque; dos días después, el
siete de diciembre de ese mismo año, en el Cerro Miraló, se puso en marcha,
con 100 watts, el XHITC-Canal 4 de Motozintla. (p. 87)
En el año siguiente se instalaron seis repetidoras más en lugares como Lacanjá,

Yajalón, Frontera Comalapa, entre otros, expandiendo la televisora a la mayor parte
del estado.
En la actualidad también se producen programas televisivos completamente

chiapanecos, entre los que destacan el noticiero Diez Noticias, el programa matutino
Mañanas de diez y el programa de cocina Entre Comales, producidos, conducidos
y editados por personal del Sistema Chiapaneco de Radio, Televisión y
Cinematografía.
En cuanto al cine, no es común ver producciones realizadas por chiapanecos en la

actualidad, pero una de las tareas que realiza el Sistema Chiapaneco de Radio,
61
Televisión y Cinematografía es la promoción de los paisajes del estado para la
grabación de producciones nacionales e internacionales, buscando de esta manera
aumentar la difusión de los paisajes del estado para atraer turismo y ganar
notoriedad como un destino fascinante, así como obtener ingresos por el derecho
de realizar filmaciones en el territorio estatal.
3.2 Área de recursos audiovisuales y programación televisiva
Dentro de una organización como lo es el Sistema Chiapaneco de Radio, Televisión

y Cinematografía, existen diversas áreas que permiten el óptimo desempeño de las
actividades realizadas en un canal de televisión, como son el área de producción,
recursos humanos, informática, programación, entre otros. Cada una de estas áreas
realizan tareas diversas, pero una de las principales para la operación del canal es
el área de programación, quien se encarga de los programas que serán transmitidos
en el canal, los horarios de transmisión y los convenios con otras productoras y
televisoras nacionales e internacionales para surtir al canal con material nuevo de
transmisión y spots para el ingreso de dinero en el mismo. La descripción de las
funciones que se presentan es producto del análisis de requerimientos realizado en
interacción con los usuarios del sistema solicitado.
3.2.1 Funciones e importancia de su operación
El área de programación se especializa en el manejo del catálogo de recursos

audiovisuales, esto consta de obtener, registrar y ordenar todos los programas de
entretenimiento, spots, documentales y todo el material que pueda ser transmitido
en televisión. Esta área se encuentra en constante comunicación con el resto, pues
es la mantiene el orden de todos los materiales audiovisuales con los que cuenta el
canal, a su vez, se encarga de crear las cartas programáticas, es decir, de
seleccionar qué programas serán transmitidos día a día y en qué horario serán
emitidos, también selecciona los spots o comerciales que serán presentados
durante la transmisión manteniendo la coherencia del tiempo.
Parte de las funciones que realiza el área es mantener contacto con otras
productoras y televisoras nacionales e internacionales para conseguir nuevo
62
material para transmitir, tales como series de televisión, programas infantiles,
derechos de transmisión de eventos en vivo, documentales, películas y todo lo que
pueda ser de interés para el público chiapaneco.
Es un área vital para el canal televisivo, pues controla completamente la transmisión

y de ello depende el interés del público hacia el canal, debe conocer los gustos de
la gente que los sintoniza, en que horario quienes lo ven son jóvenes, amas de casa
o adultos mayores, entre otros grupos a los que está dirigido el contenido, de esta
manera lograr un balance entre los espectadores y de así, se sientan atraídos al
contenido del canal. Toda la logística que se despliega en esta área es bastante
compleja y por ello es importante el orden y eficiencia con que se maneja la
información.
3.2.2 Procesos y necesidades del área
Dentro del área de programación se llevan a cabo procesos relacionados con el

material audiovisual del canal, el primer proceso es el de registro de cada uno de
los elementos audiovisuales que están a disposición para las transmisiones diarias
del canal, de estos se registra:
● El título.
● La fecha en la que se llevó a cabo la producción.
● La sinopsis o resumen.
● El formato en el que será almacenado, ya sea digitalmente o físicamente en
un DVD o Blu-ray.
● La clasificación otorgada por la Secretaría de Gobernación a través de la
Dirección de Radio, Televisión y Cinematografía (RTC), es decir, el público
al que va dirigido el programa.
● El tipo de programa, ya sea un spot, un documental, una serie o cualquier
otra categoría.
● El nombre productora creadora o poseedora de los derechos del material.
El segundo proceso que se encuentra a cargo del área es la creación de convenios

con otros canales de televisión u organismos similares al Sistema Chiapaneco de
63
Radio, Televisión y Cinematografía para la obtención de nuevo material para el
canal. De estos convenios se registran tanto los datos de la organización, como lo
son el nombre, el puesto y número telefónico del contacto responsable, como de la
vigencia de los convenios, pues esta marca la fecha límite del permiso que tiene el
canal para la transmisión de los programas, estos datos son utilizados para la
posible renovación de dichos convenios y prevenir la transmisión de programas
cuyo permiso ha expirado.
El siguiente proceso y el más importante, es el manejo de los horarios de

transmisión del canal mediante la creación de pautas programáticas, este proceso
es el que le da nombre al área, este depende de los procesos anteriores y del área
de producción, pues en estas pautas se debe agendar la transmisión de los
programas en vivo, los spots publicitarios y los programas que se decidan transmitir
durante el día, todo esto con un manejo de tiempo que requiere precisión, es de
suma importancia el cálculo de la duración de los elementos, pues algunos de los
spots publicitarios solicitan un horario específico de transmisión, así como la
necesidad de mantener la coherencia de los contenidos emitidos.
Dado que los procesos están ligados entre sí, el área necesita mantener en orden
la información, que esta sea accesible en todo momento y así conseguir eficiencia
al momento de crear las pautas programáticas del día, centralizar la información de
los diversos procesos en un mismo sistema y acceder a una herramienta que
permita realizar cada de ellos se convirtió en una necesidad, dado que, con el paso
del tiempo, el canal ha ido en crecimiento y el volumen de información es claramente
mayor.
3.2.3 Optimización y mejora de los procesos mediante soluciones de software
Cuando se trata de la implementación de soluciones de software, es importante

conocer muy bien los procesos que se desean automatizar o mejorar, ciertamente
un software puede agilizar mucho los procesos de una organización, pero con un
mal planteamiento o un entendimiento incorrecto de los procesos, un sistema
informático pueden causar un efecto totalmente contrario, como explican Kendall y
64
Kendall (2011), “al tomar una perspectiva de sistemas, los analistas pueden
empezar a descifrar y comprender en términos generales las diversas empresas
con las que entrarán en contacto” (p. 27).
Los procesos en general, suelen estar interrelacionados entre sí, la salida de uno
es parte de la entrada de otro, tal como los conceptos que Kendall y Kendall (2011)
aplican a los subsistemas que componen a una organización y por tanto a un
sistema más grande, este hecho tiene grandes implicaciones que los analistas de
sistemas que buscan mejorar el cumplimiento de objetivos deben tener presentes y
siempre en consideración.
Dada la naturaleza de los procesos que lleva a cabo el área de programación

televisiva, es deducible que la centralización de la información mediante el uso de
un software optimiza en gran medida la eficiencia en la que dicha área puede llevar
a cabo sus tareas, una herramienta que permite el registro de los datos de contacto
de las productoras con las que se crean convenios y permite registrar
posteriormente el material que estas proveen, hace más eficiente y prácticamente
combina dos de los procesos, así mismo, habilitar un módulo que permite la
creación de pautas programáticas mediante el acceso a los registros previamente
descritos, hace mucho más eficiente este proceso medular, el uso de la información
almacenada en la base de datos es sin duda una característica crucial en la
optimización de estos procesos, puesto que minimiza los errores humanos en la
escritura, además de, directamente eliminar la necesidad de escribir información ya
registrada en el sistema para la creación de las pautas.
65
CAPÍTULO 4. DISEÑO METODOLÓGICO
4.1 Enfoque de la investigación
Las investigaciones son un proceso sistematizado, riguroso y cuidadoso que busca

la resolución de problemáticas, esto garantiza la producción de nuevos juicios
lógicos o alternativas viables para la solución de problemas y la producción de
conocimiento (Otero, 2018).
Existen dos enfoques esenciales para la investigación, la cuantitativa y la cualitativa,

para esta investigación se utilizó un enfoque cualitativo, el cual utiliza el texto como
material empírico en lugar de los números, Flick (2007) explica que este enfoque
parte de la noción de la construcción social de las realidades sometidas a estudio,
interesándose en las perspectivas de los participantes, en sus prácticas cotidianas
y el conocimiento cotidiano que hace referencia a la cuestión estudiada, esto nos
deja en claro que a través del estudio de comportamiento social o un caso cotidiano,
se busca plasmar en texto el conocimiento empírico, tratando de transmitir lo que
un investigador descubre e interpreta con la observación de una realidad cotidiana.
Según Jiménez-Domínguez (2000) citado en Salgado (2007), los métodos

cualitativos parten del supuesto básico de que el mundo social está construido de
significados y símbolos, es decir, que la intersubjetividad es una pieza clave de la
investigación, siendo entonces un intento de obtener una comprensión profunda de
los significados y definiciones de la situación tal como nos la presentan las
personas, más allá de obtener una medida cuantitativa de sus características o
conductas.
Siendo entonces que esta investigación es un caso de estudio acerca de la

descripción del proceso de aseguramiento de la calidad de software, el enfoque
cualitativo se ajusta perfectamente, pues lo que se busca es la creación de
conocimiento empírico mediante un texto que describe un caso práctico en concreto;
es decir, que la investigación se centra en la recopilación de datos, el análisis de
ellos y la forma de narrar las situaciones descubiertas y no el análisis estadístico de
las mismas.
66
4.2 Método de investigación
El método de investigación empleado para la presente investigación es el estudio

de caso, en la investigación cualitativa se puede definir como un proceso de
indagación que se enfoca en la descripción y examen detallado, comprehensivo,
sistemático y profundo de un caso ya definido, como puede ser un acontecimiento,
fenómeno o alguna situación en particular (Durán, 2012). Por otro lado, Martínez
(2011) lo define como “una investigación que mediante los procesos cuantitativo,
cualitativo o mixto; se analiza profundamente una unidad para responder al
planteamiento del problema, probar hipótesis y desarrollar teoría” (p.31).
Aplicar este método de investigación permitió recolectar y analizar datos para

comprender el entorno de trabajo de la organización que fue objeto de estudio en
un escenario real, esto fue posible a través de técnicas de recolección de datos
como las entrevistas y la observación, posteriormente se realizó el análisis de la
información para finalmente dar propuestas de solución.
4.3 Técnicas de investigación
Las investigaciones con enfoques cualitativos difieren de las investigaciones

cuantitativas en las técnicas de investigación, pues los datos a recabar no son datos
numéricos o medibles a manera de estadística, aunque como sugiere Monje (2011),
es recomendable utilizar ambos métodos de recolección de datos para una mayor
comprensión de un tema. En esta investigación se usaron dos técnicas de
investigación las cuales se describen a continuación.
4.3.1 Observación
La observación es considerada como la médula espinal del conocimiento científico,

es también el eje que articula la metodología de investigación cualitativa, Guerrero
(2016) explica que esta técnica permite obtener información sobre un fenómeno o
acontecimiento tal y como se produce, también menciona que es la técnica más
recomendada para las investigaciones de enfoque cualitativo. Según Ramos (2016),
como procedimiento puede ser utilizada en diversos momentos de una
investigación, en la etapa inicial de la misma, se utiliza para realizar un diagnóstico
67
del problema a investigar y es de gran utilidad en el diseño de la investigación, así
mismo, al finalizar la investigación, la observación puede llegar a predecir
tendencias y desarrollo de los fenómenos.
La observación según Ramos (2016), también puede usarse con otras técnicas,
como lo es la entrevista, esto hace posible la comparación de resultados, los cuales,
al ser obtenidos por diferentes medios, se complementan y permiten tener una
mayor precisión en la información recabada.
Para esta investigación se utilizó concretamente la observación participante o

participativa, la cual según Guerrero (2016) se origina de la observación pura, pero
se presenta por situaciones específicas que modifican la relación clásica del
observador y los observados, entre sus características básicas encontramos que el
objeto de investigación debe ser ajeno al investigador, la convivencia en el sistema
sometido al estudio, supone el pilar fundamental de la aplicación del método, como
Ramos (2016) lo describe, en esta modalidad de observación, el observador forma
parte del grupo observado y participa en él durante el tiempo que dure la
observación.
Durante la investigación se realizaron observaciones de los procesos de creación

de las pautas programáticas realizadas por el personal del área de programación
televisiva, así como del registro y gestión de información de los programas y de
contactos provenientes de las productoras que tienen un convenio con el Sistema
Chiapaneco de Radio, Televisión y Cinematografía, con el objetivo de conocer a
profundidad los procesos que se llevan a cabo en el área, así como la búsqueda de
su optimización y mejora de los mismos.
4.3.2 Entrevista
La entrevista es una técnica en la que una persona solicita información de otra o de

un grupo, esto con el fin de obtener datos sobre un problema determinado (Herrera,
2008). Como expone Ramos (2016), de acuerdo con la finalidad de la entrevista,
ésta puede o no estar estructurada a través de un cuestionario previamente
elaborado, con preguntas que tienen un determinado fin y que son indispensables
68
para esclarecer la tarea de investigación, además de las preguntas de apoyo que
sirven para desarrollar la entrevista.
Para esta investigación se utilizó el método no estructurado, que como explica

Monje (2011) se trata de una entrevista flexible y abierta, en la cual se procede sin
un concepto preconcebido del contenido o flujo de la información que se desea
obtener, pero las preguntas serán regidas por los objetivos de la misión; siguiendo
este concepto, Guerrero (2016) expone que durante el desarrollo de esta entrevista
pueden surgir nuevas interrogantes que se adecuen a las necesidades del mismo,
de esta manera, es posible que el entrevistador profundice y aclare los conceptos
que sean importantes dentro de los objetivos de la investigación.
En este caso, una técnica adecuada para entender de mejor manera los procesos
realizados en el área de programación televisiva y comprendiendo a profundidad las
necesidades de las personas que realizan dichos procesos, siempre y cuando como
entrevistadores se tenga una alta capacidad de comunicación, pues como explica
Ramos (2016), la preparación del entrevistador con respecto a la estructuración de
preguntas, sus condiciones psicológicas, la fidelidad a la hora de transcribir
respuestas y la influencia que éste tenga sobre el entrevistado, son factores que
determinan la efectividad y veracidad de la entrevista realizada, así como de la
información obtenida.
4.4 Participantes de la investigación
En una investigación cualitativa no se tiene muestreo ni representación estadística

como se describió anteriormente, dado que se busca el análisis de una realidad o
escenario, el propósito es conocer lo que los actores sociales tienen que decir y lo
que hacen. En esta investigación, los actores sociales que participaron como
objetivo de las técnicas de investigación fueron quienes trabajan en el área de
programación televisiva del Sistema Ch iapaneco de Radio, Televisión y
Cinematografía, cuyos puestos se describen a continuación:
a) Jefe del área de programación televisiva: Es el responsable de todas las

actividades del área, administra la información de los programas televisivos
69
que están registrados en el área, toma las decisiones de las pautas
programáticas del día, maneja, firma y promueve los convenios realizados
con las productoras y televisoras externas.
b) Personal del área de programación televisiva: Realiza las actividades básicas
del área, es quien realiza los registros de los programas televisivos, realiza
propuestas de pautas programáticas para que el jefe de área realice la
autorización, mantiene organizada la información nueva y da de baja
información obsoleta.
70
4.5 Instrumentos de investigación
Para aplicar las técnicas explicadas previamente, se diseñaron los instrumentos que
se presentan en la figura 4.1.
4.5.1 Cédula de observación
Figura 4.1 Cédula de observación
Fuente: Creación propia.
71
4.5.2 Guía de entrevista
A continuación se presentan las preguntas para el levantamiento de requerimientos,

fundamentales para conocer las necesidades que deben cubrirse y las tareas que
debe abarcar y cumplir el sistema.
Nombre:
Compañía/Organización:
Puesto:
Del Usuario
● ¿Quién es el cliente?
● ¿Quién es el usuario?
● ¿Son sus necesidades diferentes?
● ¿Cuáles son sus habilidades, capacidades, ambiente?
Del Proceso
● ¿Cuál es el problema que se ha identificado?
● ¿Cuál es la razón por la que se quiere resolver este problema?
● ¿Cuál es el valor de una solución exitosa?
● ¿Cómo usted resuelve el problema actualmente?
● ¿Cómo le gustaría que se resolviera?
● ¿Qué retrasos ocurren o pueden ocurrir si no se resuelve el problema?
Del Producto
● ¿Qué problemas podría causar este sistema en la organización?
● ¿En qué ambiente se usará el sistema?
● ¿Cuáles son sus expectativas para los conceptos fácil de usar, confiable y
rendimiento?
● ¿Qué obstáculos afectan la eficiencia del sistema?
● ¿Cuál es la perspectiva que se tiene del sistema?
● ¿Qué tipos de documentación impresa y en línea necesita?
72
4.6 Análisis de datos
El análisis de los datos es la etapa que se realiza una vez que se ha obtenido la
información requerida durante todo el proceso de recopilación de datos. Es parte
fundamental del proceso ya que implica trabajar con los datos, ordenarlos,
sintetizarlos, homogeneizarlos de manera que puedan manejarse de una mejor
forma y descubrir qué aportan para la investigación (Guerrero, 2016).
Coffey y Atkinson (2005), citados en González y Cano (2010) sugieren que:
Podríamos definir el análisis como el proceso a través del cual vamos más
allá de los datos para acceder a la esencia del fenómeno de estudio, es decir,
a su entendimiento y comprensión; el proceso por medio del cual el
investigador expande los datos más allá de la n arración descriptiva. (p. 1)
Para el análisis de datos de esta investigación se utilizaron las herramientas del

Lenguaje Unificado de Modelado también conocido como UML, que de acuerdo con
Ferré y Sánchez (2011), “es un lenguaje que permite modelar, construir y
documentar los elementos que forman un sistema software orientado a objetos” (p.
1); es decir, se desarrollaron modelos que representan el sistema analizado.
a) Diagrama de casos de uso
Este diagrama está dirigido a presentar las funcionalidades y características

del sistema y la relación de sus elementos con los usuarios y entidades
externas que se involucran en un determinado proceso (García y
Rubí, 2018).
b) Diagrama de base de datos
De acuerdo con Márquez (2011) “una base de datos es un conjunto de datos

almacenados en memoria externa que están organizados mediante una
estructura de datos” (p. 2).
La base de datos se puede percibir como un almacén grande de datos que

es definido y creado una sola vez y que puede utilizarse al mismo tiempo por
diferentes usuarios (Márquez, 2011).
73
El modelo de base de datos relacional muestra los datos en forma de tablas
y relaciones y es uno de los modelos más populares (Sánchez, 2004). De
acuerdo con Suárez (2008) algunas características del modelo relacional
son:
• Una base de datos relacional se compone de varias tablas o

relaciones.
• No pueden existir dos tablas con el mismo nombre ni registro.
• Cada tabla es a su vez un conjunto de registros (filas y columnas).
• La relación entre una tabla padre y un hijo se lleva a cabo por medio
de las claves primarias y ajenas (o foráneas).
• Las claves primarias son la clave principal de un registro dentro de
una tabla y éstas deben cumplir con la integridad de datos.
• Las claves ajenas se colocan en la tabla hija, contienen el mismo
valor que la clave primaria del registro padre; por medio de éstas
se hacen las relaciones. (p.2)
En la presente investigación, UML por ser un lenguaje orientado a objetos, permitió

hacer un análisis más certero de la información que fue provista en el proceso de
recolección de datos acerca del objeto de estudio y gracias a sus características se
logró sintetizar la información y obtener la que era de mayor relevancia para su
análisis y aplicación en el desarrollo del proyecto.
74
CAPÍTULO 5. PROCESO DE ASEGURAMIENTO DE LA CALIDAD EN EL
DESARROLLO DEL SISTEMA DE ADMINISTRACIÓN DE
RECURSOS AUDIOVISUALES
5.1 Descripción global
5.1.1 Necesidad, problema u oportunidad de la organización
El personal del área de programación televisiva del Sistema Chiapaneco de Radio,

Televisión y Cinematografía, realiza las actividades del área utilizando las
herramientas básicas de Office que tienen a su alcance, esto en reiteradas
ocasiones provoca que haya retrasos en las actividades propias del área, por ello,
respondiendo a la necesidad de hacer más rápido y eficiente el llevar a cabo sus
correspondientes tareas, se realizó el desarrollo de un sistema de administración de
recursos audiovisuales, que pueda facilitar el almacenamiento, consulta y manejo
de la información del contenido audiovisual que utilizan, o bien, la información que
puedan requerir de las productoras con las que tengan convenios.
5.1.2 Suposiciones y Restricciones
El sistema de administración de recursos audiovisuales, ha sido desarrollado

basándose en la información suministrada por el jefe del departamento de
programación televisiva, a través de la Especificación de Requerimientos de
Software. Se establece la seguridad a nivel de aplicación del sistema, por ello en el
caso de que se cuente con un sistema previo, toda la información del mismo, será
portada y administrada normalmente con el sistema nuevo.
Se requirió que el equipo del área en el que se administra el sistema, contara con
el paquete de software libre “Xampp”, que cuenta principalmente con el sistema de
gestión de bases de datos MariaDB, el servidor web Apache y los intérpretes para
lenguajes de script PHP y Perl. El sistema de información funciona de forma
autónoma, sin que haya necesidad de comunicación con sistemas externos a la
institución, por lo que no existen dependencias con respecto a otros recursos. Los
equipos adicionales que hagan uso del sistema, no requieren software extra,
únicamente el sistema de administración instalado.
75
5.2 Definición de requerimientos
5.2.1 Obtención de Requerimientos
5.2.1.1 Métodos interactivos
Tabla 5.1 Métodos interactivos
Método Descripción
Entrevista Se realizaron con los responsables del manejo del sistema

para conocer sus necesidades y las f unciones que desean que
el sistema contenga, se pueden grabar o documentar, según
la complejidad del requerimiento.
Observación Se trató de una actividad realizada en el entorno de trabajo del

negocio, y tiene por objetivo f amiliarizarnos con los procesos
realizados en el área.
5.2.1.2 Requerimientos Funcionales
Tabla 5.2 Requerimientos funcionales
Nombre Descripción
Registro de productora Consiste en registrar las productoras con las que el área de
producción tiene convenio.
Registro de contacto Consiste en registrar a los contactos de las productoras con las
que se tiene convenio.
Registro de programas Consiste en registrar los programas correspondientes a cada

productora con la que se tiene convenio, estableciendo los
atributos que conf orman a los programas como su nombre,
duración, tipo de programa, etc.
76
Registro de capítulos Consiste en registrar los capítulos de los programas registrados
previo convenio con las productoras, asignándoles los atributos
como, nombre, duración, entre otros.
Crear pauta programática Consiste en crear la pauta programática del día, de acuerdo con
los programas y capítulos de las productoras previamente
registradas. Utilizando campos de atributos como f echa, tipo de
programa, tipo de transmisión, programas, horarios, capítulos y
bloques.
Exportar pauta Consiste en exportar en f ormato PDF, la pauta programática del

día que se haya creado, para proponerla a la dirección general de
producción y post producción.
5.2.1.2.1 Requerimientos de base de datos
Tabla 5.3 Requerimientos de base de datos
No. Nombre Descripción
En la base de datos se creó la tabla programa, la cual tiene las

siguientes características o atributos, Id del programa, tipo de
1 Tabla programa programa, nombre del programa, f echa de producción, f echa de
expiración, sinopsis, calidad, número de capítulos, f ormato,
clasif icación y productora.
Existe la tabla capítulo, donde se almacenan los siguientes

2 Tabla capítulo
atributos, id del capítulo, nombre del capítulo y duración.
En la tabla productora los atributos son los siguientes, nombre de

3 Tabla productora
la productora, estado de procedencia, tipo de producciones.
En esta tabla se guarda la inf ormación de los contactos con los

que se tenga convenios, sus atributos son los siguientes, id del
4 Tabla contacto
enlace, nombre del enlace, correo electrónico, teléf ono y
dirección.
77
Tabla La tabla programación tiene los siguientes atributos, id de
5
programación programación, f echa y horario.
5.2.1.3 Requerimientos No Funcionales
Tabla 5.4 Requerimientos no funcionales
REQUERIMIENTO DESCRIPCIÓN
El sistema garantiza que los usuarios que hagan uso de él,

contarán con una excelente ef icacia y rapidez al momento de
Requisitos de rendimiento
realizar las actividades que se requieran.
Se mantiene la integridad de la inf ormación que f orme parte

de la base datos del sistema, tal como inf ormación de la
Seguridad
institución o empresa, documentación y, en este caso,
procedimientos que el sistema realice.
El sistema cuenta con una interf az sencilla para su uso, lo que

garantiza su f iabilidad, además de que of rece ser segura para
Fiabilidad
el usuario y cumplir con las f unciones necesarias y requeridas.
La base de datos que es utilizada en el sistema cuenta con un

respaldo de f orma periódica de toda la inf ormación que ésta
Mantenimiento
contiene, además el sistema se desarrolló con posibilidad de
hacer mejoras a f uturo y agregar nuevas f uncionalidades.
Por ser un sistema de escritorio, no se garantiza su

portabilidad, ya que depende de f actores internos para hacer
Portabilidad
uso de él; sin embargo, puede hacer uso del sistema, siempre
y cuando los otros equipos también tengan instalado el
sistema y se encuentren conectados en la misma red.
78
5.2.2 Especificación de casos de usos
Figura 5.1 Especificación de casos de usos
Fuente: Creación propia
5.2.3 Análisis de requerimientos
El análisis de requerimientos se llevó a cabo de la mano del jefe de departamento

de programación televisiva, para definir los requisitos del sistema y los pasos a
seguir. Se realizó el estudio de la necesidad tecnológica de la organización, se
especificaron las características operacionales que tendría el software, esto a través
de entrevistas y observación. Posteriormente se describió el plan de proyecto a
seguir, y finalmente se llevó a cabo dicho plan dentro del tiempo asignado para el
mismo y atendiendo los objetivos establecidos.
79
5.2.4 Modelo de la base de datos
Figura 5.2 Modelo de la base de datos
80
5.3 Proceso de desarrollo del software
El enfoque metodológico utilizado para este proyecto fue el Proceso Unificado de

Desarrollo de Software (RUP), el cual es un enfoque iterativo e incremental que
junto con el modelado UML se utiliza para el análisis, implementación y
documentación de software orientado a objetos.
Las etapas aplicadas en este modelo fueron:
1. Inicio
2. Elaboración
3. Construcción
4. Transición
Cabe mencionar que cada etapa de este modelo está constituida por varias
actividades que permiten realizar un correcto análisis y diseño del software tomando
en cuenta las funcionalidades que éste debe cumplir y, de esta forma garantizar en
la última etapa que el software esté listo para su entrega.
Las herramientas utilizadas para este desarrollo fueron el IDE Visual Studio 2013 y
el paquete de software libre XAMPP que cuenta con el sistema de gestión de base
de datos María DB.
5.4 Proceso de aseguramiento de la calidad del software
El proceso de aseguramiento de la calidad del software consistió en una serie de

actividades centradas en analizar y evaluar el proceso de desarrollo de software y
los resultados obtenidos del mismo. Estas actividades fueron imprescindibles para
conocer las deficiencias, errores, fallos o mejoras que podían hacerse al sistema de
administración de recursos audiovisuales, así como verificar que se cumplan los
procedimientos y estándares pertinentes y reportar los resultados de todo el
proceso.
81
5.4.1 Revisión informal
a) Lista de pendientes de software

1. Filtro en las cajas de texto para ingresar información (Filtros básicos para
que el usuario ingrese datos congruentes en los campos de texto).
Se refiere a que, en los campos en los que el usuario, deba agregar

información concreta como correos electrónicos o números de teléfono,
el software evalúe que los datos ingresados son válidos, es decir, que
cumplan con los criterios propios del atributo.
2. Corregir exportación en PDF.
Se trata de que, si el documento de exportación tiene dos o más páginas,

que en cada salto de página se vuelva a colocar el encabezado o título
del documento.
3. Corregir el orden en el que se despliegan las búsquedas, mantener la
integridad de los datos aun cuando se editen.
Se refiere a que, al momento de realizar una búsqueda general de datos

ya sea en orden alfabético o numérico, el orden en el que se muestran los
resultados de la lista desplegable, sea el correcto. Y en caso de modificar
algún registro de alguna de las tablas, que no quede ningún registro
huérfano, es decir, que las relaciones entre tablas no fallen .
4. Agregar mensajes de advertencia al realizar algunas acciones en el
sistema.
Se requiere esta funcionalidad, considerando que se realizan acciones

importantes como eliminar registros o modificarlos. Y de esta manera
asegurar que la información no se pierda por error o, se realicen cambios
inesperados.
82
b) Cronograma para atender la revisión informal
Figura 5.3 Cronograma para atender la revisión informal
83
5.4.2 Revisión Técnica Formal
5.4.2.1 Evaluación de los requerimientos del software
Tabla 5.5 Evaluación de los requerimientos del software
Nivel de
importancia
Evaluación de los (1) Poca Cumplimiento

Observaciones
requerimientos (2) (0 – 100%)
Moderada
(3) Alta
¿El modelado de
El levantamiento de requerimientos del
levantamiento de
usuario se realizó a través de entrevista y
requisitos es claro y
análisis de documentación, por lo cual
representa de f orma 3 90% quedó muy clara la necesidad del usuario,
adecuada los
sin embargo, se pudo considerar otro
requerimientos del
método como el de historias de usuario.
usuario?
Dado que algunas f unciones del sistema

¿Se identif ican con
dependen de otras entre sí, el usuario puede
claridad las
o no, identif icar que los procesos que
f uncionalidades 3 90% especif icó existen, esto debido a que sus
solicitadas por el
requerimientos no se presentan de f orma
usuario?
jerárquica en el sistema.
En caso de existir,
¿Se tomaron en Se consideraron por completo los
cuenta, los requerimientos especiales, considerando
requerimientos 1 100% que f ueron pocos y sencillos, por eso su
especiales de los nivel de importancia f ue bajo.
usuarios?
¿Se cumplen los Considerando que no hay requisitos de

requerimientos de conf idencialidad del usuario, el sistema
seguridad 1 90% cumple con lo necesario, pero se consideró
establecidos por el que podría implementarse la seguridad
usuario? mediante cuentas de usuario.
En caso de existir,
¿Se cumple con los
requerimientos
sobre estándares No hubo aspectos ambientales o legales a
2 100%
ambientales o considerar en el desarrollo del sistema.
regulaciones legales
que se deben
obedecer?
84
¿Cada
requerimiento es Todos los requerimientos del sistema,
consistente con el 2 100% f ueron considerados de acuerdo a los
objetivo general del objetivos planteados.
sof tware?
¿El sof tware cumple

con las
El sof tware cumple con los requisitos
f uncionalidades de
3 95% f uncionales establecidos en el modelado de
acuerdo con los
requerimientos.
requisitos
f uncionales?
¿El sof tware cumple

con las
El sof tware ha considerado todos los
f uncionalidades de
3 100% requisitos no f uncionales establecidos en el
acuerdo con los
modelado de requerimientos.
requisitos no
f uncionales?
¿Se cumplen los

requerimientos Se estima que todos los requisitos
generales 3 100% especif icados por el usuario, se han
especif icados por el abordado de manera general en el sof tware.
usuario?
Fuente: Creación propia con base en Pressman (2010).
5.4.2.2 Evaluación de interfaz
Tabla 5.6 Evaluación de interfaz
Nivel de
importancia
Cumplimiento
Evaluación de la interfaz (1) Poca Observaciones
(0 – 100%)
(2) Moderada
(3) Alta
Aunque muchas de las

operaciones son intuibles
¿La interf az lleva hacia una para realizar, hay ciertas
2 90%
comprensión f ácil? acciones que requieren al
menos una pequeña
explicación previa.
Las f unciones principales

¿Todas las operaciones son son reconocibles a simple
3 100% vista, e iniciables al
f áciles de localizar e iniciar?
momento, se encuentran
centradas y eso permite
85
localizar rápido los
controles.
Las f unciones principales

están a un botón de
acceder, pero f unciones
¿La entrada está especif icada de
secundarias usadas
modo que economiza el uso del 2 80% regularmente como las
teclado o del ratón? búsquedas, se encuentran
un poco más ocultas para
su acceso.
La mayoría de los
controles están colocados
de manera que siguiendo
la secuencia de llenado de
f ormularios sea sencillo
¿La estética ayuda a la encontrar los botones,
3 80%
comprensión y uso? aunque en situaciones
como las opciones de
búsqueda de programas,
los botones se pueden
perder un poco a la vista
del usuario.
Para las opciones de

ingreso de datos, los
f ormularios son bastante
simples de completar,
incluso en algunos, se
¿La distribución y estilo de la
autocompletan con datos
interf az permite que un usuario
2 100% f altantes (aunque no son
introduzca con ef iciencia las
necesariamente los
operaciones y la inf ormación?
correctos), y da avisos de
datos f altantes o en el caso
del correo electrónico para
los contactos, valida que
estén bien escritos.
Los f ormularios se pueden

llenar de manera sencilla
usando la tecla
¿Una secuencia de operaciones
“Tabulador” para saltar al
(o entrada de datos) puede
2 100% siguiente campo que
realizarse con economía de
requiere llenado, aunque
movimientos?
campos como las f echas,
requieren el uso del
mouse.
¿Los datos de salida o el Para un usuario nuevo,

contenido están presentados de puede ser algo complicado
modo que se entienden de 3 85% leer los datos en pantalla
inmediato? de manera correcta, pero
para usuarios con un uso
86
más habitual (no
necesariamente experto)
pueden memorizar pronto
la ubicación de los datos y
leer con f acilidad la interf az
y las salidas presentadas.
La mayoría de ingresos de
datos y f unciones
primarias son accesibles
desde el menú lateral de
¿Las operaciones jerárquicas manera simple, solo en
están organizadas de manera que caso de ingresos
minimizan la prof undidad con la 2 90% secundarios de datos, o
que debe navegar el usuario para datos complementarios
hacer que alguna se ejecute? que no se tenían en el
ingreso original, es
necesario acceder a una
página que requiere un
botón extra.
El sof tware reconoce datos

mal ingresados en ciertos
apartados, como el correo
electrónico, así como
permite únicamente el
¿El sof tware reconocerá el error ingreso de números en los
si entran datos en el límite de lo campos de “número de
permitido o más allá y, lo que es 2 95% contacto” bloqueando el
más importante, continuará teclado, así como datos
operando sin f allar ni degradarse? corruptos en los datos de
programación, permitiendo
eliminarlos en caso de
f allos, lo cual permite
mantener los datos lo más
limpios posible.
El sistema tiene mensajes

de advertencia en
¿La interf az da un diagnóstico y acciones clave que permite
guía útiles cuando se descubre evitar errores de pulsación,
una condición de error (asociada 1 100% muestra errores de
con la f uncionalidad del conexión y muchas veces
sof tware)? permite continuar con el
trabajo e intentar
nuevamente.
¿La interf az tiene gran capacidad Los 3 módulos principales

para permitir al usuario moverse son accesibles de manera
entre pantallas principales con sencilla gracias al menú
pocos movimientos, permitiendo 2 100%
lateral que acompaña
así cambiar de módulo de manera siempre al usuario, de esta
práctica? manera puede hacer
87
movimientos rápidos entre
ellos.
5.4.2.3 Evaluación de código
Tabla 5.7 Evaluación de código
Nivel de
importancia
Evaluación de Cumplimiento
(1) Poca Observaciones
código. (0 – 100%)
(2) Moderada
(3) Alta
Es intuitivo debido a que la

codif icación está muy bien
estructurada y ordenada por clases
(Buena estética de codif icación).
Además de tener un uso adecuado
Intuitivo. Moderada 85% del try catch para determinar posibles
errores de escritura.
Por otro lado, sería bueno que tuviera
comentarios para tener más en claro
sus f uncionalidades.
El sof tware cuenta con un grado de

alta ef iciencia debido a que tiene una
adecuada agrupación de códigos que
evitan que éste se esté repitiendo.
Además de tener una optimización
Ef iciencia. Moderada 100% adecuada de los bucles.
La adecuada optimización del código
se usa para que éste sea más rápido,
de igual f orma f unciona sólo que entre
menos líneas de código se escriba es
mucho mejor.
Es un código robusto ya que tiene en

cuenta todos los posibles errores en
cuanto a la mala inserción de datos ya
sea a través de un if -else o un try-
catch. Los métodos set y get ayudan
Robustez. Alta 90% a que haya un control en f lujo de
datos de una a otra interf az.
La robustez del código es de gran
importancia ya que si no se cuenta
con una prevención en los posibles
errores o no se encuentre una
88
operación no contemplada podría
inclusive dejar colgado al sof tware, ya
que éste no tendría f orma de
responder.
Tiene un alto grado de riqueza en la

codif icación ya que cuenta con una
estructura entendible con el simple
hecho de tener conocimientos de
programación se puede adecuar a los
requisitos específ icos. También tiene
la f acilidad en aplicarle
Riqueza. Moderada 95% mantenimiento por su f ácil
comprensión en cuanto a la
codif icación.
Es muy importante que el código
siempre sea entendible, aunque por
lo regular el mismo equipo o empresa
es el que le da mantenimiento al
sof tware.
5.4.2.4 Reporte de evaluación de software
Una vez completado el proceso de desarrollo del software en un 100%; es decir,

después de hacer las modificaciones previamente establecidas para que el software
estuviera completo y, de acuerdo con las evaluaciones realizadas al mismo, los
resultados obtenidos fueron en su mayoría satisfactorios ya que, de acuerdo a las
preguntas que se realizaron en la evaluación de cada aspecto del software, los
cuales fueron la interfaz, los requerimientos y el código se han considerado
favorables y consistentes debido a que se evaluaron criterios específicos, tales,
como, el nivel de importancia del aspecto evaluado, su nivel de cumplimiento, y
además, se agregaron algunas observaciones que permiten identificar qué mejoras
aún son necesarias o qué modificaciones deben realizarse al software.
a) Requerimientos
Según la evaluación correspondiente a los requerimientos de software, la

cual se basó o enfocó al resultado del software y no tanto al proceso de
levantamiento de requerimientos, se puede describir que, se cumple en un
95% con los requisitos, estos están bien definidos y en su mayoría se han
89
constituido bien en el desarrollo del software, esto considerando que se han
tomado en cuenta todos y cada uno de los requerimientos especificados por
el usuario y, que además, se realizaron correctamente los procedimientos de
levantamiento de requerimientos los cuales se identifican con claridad y se
puede distinguir en qué parte del software están constituidos; también se
hicieron las consideraciones legales que pudiesen afectar en algún momento
dado, el funcionamiento del mismo, o bien, al usuario final. Cabe destacar
también que los requerimientos fueron lo más específicos posibles, esto con
la finalidad de cumplir con el objetivo principal del desarrollo del software, es
decir, se han constituido de manera que todos cumplan con el funcionamiento
general que debe cumplir el software, además se establecieron de manera
clara, concisa y bien identificados los requisitos funcionales y no funcionales
del software para de esta forma garantizar su correcto funcionamiento.
b) Interfaz
De acuerdo con la evaluación respectiva de la interfaz esta cumple en un

93% con todos los criterios evaluados, ya que tiene una comprensión fácil
para el usuario, lo que le permite, a su vez, que las operaciones sean fáciles
de localizar, y utilizando los recursos del equipo del usuario. La estética es
buena, el estilo de la interfaz y los colores del sistema favorecen a que el
usuario pueda manejarlo de manera eficiente, realizando las operaciones
correspondientes al software sin mayor problema y, economizando en
movimientos, lo cual también conlleva a la obtención de respuesta y
resultados de los procedimientos del software, que se entienden de manera
clara y concisa. Además, el software reconoce los errores de entrada de
datos, mismos que se muestran en la interfaz durante su uso, es decir, los
mensajes de error del software o advertencias sobre datos que están
incorrectos o fuera de la longitud permitida, se muestran en la pantalla.
Finalmente, la interfaz permite al usuario moverse de manera efectiva sobre
el software, y realizar los procedimientos y/u operaciones que corresponden
90
a lo requerido por el usuario, haciendo uso de los recursos con los que esta
cuenta y de manera práctica, cumpliendo así, los objetivos correspondientes.
c) Código
Tomando en consideración la evaluación de la codificación se considera que

es muy clara; sin embargo, para mayor entendimiento los comentarios son
de gran importancia, ese es uno de los aspectos que se consideraron en el
proceso de mejoramiento del software, ya que cuando se están construyendo
muchas características en la misma aplicación, la situación tiende a
complicarse debido a que existen diferentes variables y parámetros. Es por
ello que, para que el código sea más entendible, es de vital importancia que
tenga comentarios.
Es muy importante optimizar el código para que éste sea más eficaz, es por
ello que esto lo hace más legible, ya que un código mal estructurado es
menos probable que sea comprendido, además de ser menos eficiente.
En cuanto a la robustez el software contiene un grado muy bueno, es decir,

tiene la acción propia en cuanto a la respuesta a una mala acción del usuario
es por ello que en esa parte no es necesario mejorar ya que es un punto
donde se tiene mucha fortaleza.
El software tiene una gran riqueza en cuanto a la codificación debido a que

está dividido en clases, objetos y métodos. Es por ello que en esta parte sólo
es necesario que éste sea un poco más optimizado, quizás aplicar menos
codificación, en caso de ser posible su redacción, por otro lado, se considera
que el código del software está muy bien elaborado y estructurado.
Estos fueron los resultados obtenidos después de realizar la primera evaluación del
software en el tema de las revisiones técnicas; sin embargo, hasta ese momento
aún era posible que durante el proceso de pruebas software, surgieran nuevas
posibilidades de mejora, y nuevas modificaciones que realizar, puesto que todavía
había algunos aspectos que podían ser mejor detallados, para cumplir con las
métricas del software y finalmente, lograr la calidad del mismo.
91
5.4.3 Guía y aplicación de pruebas
5.4.3.1 Guía de prueba orientado a objetos
5.4.3.1.1 Caso de prueba “agregar productoras”
Tabla 5.8 Caso de prueba “agregar productoras”
Caso de prueba Agregar productoras
Número de caso
1
de prueba
Agregar una productora a la base de datos con la cual se haya realizado un

Propósito
convenio.
El usuario ingresa en el f ormulario el nombre y, la ciudad o estado al que

Descripción pertenece la productora con la que se ha realizado el convenio, se agregan
breve también el nombre, el número telef ónico, el correo electrónico y la dirección del
contacto en caso de existir y se guardan en la base de datos.
Nivel de
importancia
(1) Poca
3
(2) Moderada
(3) Alta
Acción del usuario. Respuesta esperada del sistema.
1.- El encargado del área de 4.- El sistema registra la inf ormación

programación televisiva obtiene un de la productora en la base de
convenio con una productora. datos.
Curso (Flujo)
típico de eventos 2.- El encargado del área de 5.- El sistema termina el proceso.
programación televisiva comienza el
registro de una nueva productora.
3.- El encargado del área de
programación televisiva ingresa los datos
requeridos por el sistema.
a.- El encargado del área de 1a.- El sistema habilita los campos

programación televisiva requiere ingresar de registro de contacto.
Extensiones datos de contacto.
3a.- El sistema guarda y vincula los
(flujo alternativo) 2a.- El encargado del área de datos de la productora y el contacto.
programación televisiva ingresa los datos
4a.- El sistema termina el proceso.
del contacto para la productora.
92
Cumplimiento
100%
(0-100 %)
El sistema realiza las acciones correspondientes a las peticiones del usuario en

Observaciones este escenario. Los datos correspondientes se almacenan en la base de datos
y en determinado momento, permite que estos sean consultados por el usuario.
5.4.3.1.2 Caso de prueba “eliminar productoras”
Tabla 5.9 Caso de prueba “eliminar productoras”
Caso de
Eliminar productoras
prueba
Número de
2
caso de prueba
Eliminar una productora de la base de datos cuyo convenio haya expirado o por
Propósito
petición de la misma.
El encargado del área de programación televisiva realiza una búsqueda de la

Descripción productora que desea eliminar, una vez que los resultados se muestran en pantalla,
breve selecciona la productora a eliminar, pulsa el botón y se eliminará tanto la pro ductora
como los datos de su contacto, así como los programas relacionados a la misma.
Nivel de
importancia
(1) Poca 3
(2) Moderada
(3) Alta
1.- El encargado del área de 2.- El sistema devuelve la lista de

Curso (Flujo) programación televisiva realiza una productoras según las
típico de búsqueda de productoras. especif icaciones del encargado del
eventos área de programación televisiva.
programación televisiva selecciona la 4.- El sistema elimina los datos de la
productora que desea eliminar. productora y toda la inf ormación
relacionada con la misma.
93
5.- El sistema termina el proceso.
a.- Ocurre un error de conexión a la base 1.- El sistema muestra un mensaje de

de datos. error por la conexión a la base de
Extensiones
(flujo datos.
alternativo) programación televisiva revisa la
conexión y vuelve a intentar el proceso.
Cumplimiento
100%
(0-100 %)
El sistema responde a la acción del usuario, de acuerdo al escenario previsto,

Observaciones donde la inf ormación, en este caso, de las productoras, es eliminada de f orma
satisf actoria de la base de datos a petición del usuario.
5.4.3.1.3 Caso de prueba “modificar productoras”
Tabla 5.10 Caso de prueba “modificar productoras”
Caso de
Modif icar productoras
prueba
Número de
3
caso de prueba
Propósito Corregir o cambiar los datos de una productora en caso de necesitarlo.
El encargado del área de programación televisiva realiza una búsqueda de la

Descripción productora que desea corregir, una vez que los resultados aparecen en pantalla, el
breve usuario puede cambiar los datos en la tabla de resultados, pulsa el botón de
actualizar y se modif icarán los datos en la base de datos.
Nivel de
importancia
(1) Poca
3
(2) Moderada
(3) Alta
94
1.- El encargado del área de 2.- El sistema devuelve la lista de
programación televisiva realiza una productoras según las especif icaciones
búsqueda de productoras. del encargado del área de programación
Curso (Flujo) televisiva.
típico de 3.- El encargado del área de
eventos programación televisiva modif ica la 4.- El sistema actualiza la inf ormación en
inf ormación necesaria en la tabla de la base de datos que ha sido modificada.
resultados.
a.- Ocurre un error de conexión a la 1.- El sistema muestra un mensaje de

Extensiones base de datos. error por la conexión a la base de datos.
(flujo
Cumplimiento
100%
(0-100 %)
El sistema realiza la modif icación correspondiente a la productora de la que el

Observaciones usuario desee actualizar la inf ormación almacenada en la base de datos y la guarda
correctamente.
5.4.3.1.4 Caso de prueba “agregar programa”
Tabla 5.11 Caso de prueba “agregar programa”
Caso de prueba Agregar programa
Número de caso
4
de prueba
Propósito Agregar programas al catálogo en la base de datos.
El encargado del área de programación televisiva ingresa en el f ormulario el ID

del programa, el tipo de programa (spot, documental, etc.), el nombre del
programa, la productora a la que pertenece, la clasif icación, una pequeña
Descripción sinopsis, la f echa de producción y expiración en caso de tenerla, la calidad del
breve video, el f ormato en el que está grabado y en caso d e ser un programa único (no
contar con más capítulos o ser un spot), la duración exacta. Los datos serán
guardados en la base de datos y se enlazarán con la productora a la que
pertenece el programa.
95
Nivel de
importancia
(1) Poca 3
(2) Moderada
(3) Alta
1.- El encargado del área de programación 4.- El sistema registra la inf ormación
televisiva recibe la inf ormación de un del programa en la base de datos.
nuevo programa.
6.- El sistema guarda y vincula los
2.- El encargado del área de programación capítulos.
Curso (Flujo) televisiva comienza el registro de un nuevo
típico de programa 7.- El sistema termina el proceso.
eventos
3.- El encargado del área de programación
televisiva ingresa los datos requeridos por
el sistema.

televisiva comienza el registro de capítulos
para el programa
a.- El encargado del área de programación 1a.- El sistema habilita el campo de

televisiva agrega un spot o un programa duración.
Extensiones sin capítulos.
3a.- El sistema guarda los datos
(flujo alternativo) 2a.- El encargado del área de ingresados por el encargado.
programación televisiva ingresa la
duración del contenido que desea agregar. 4a.- El sistema termina el proceso.
Cumplimiento
100%
(0-100 %)
La respuesta del sistema en el escenario de registro de un nuevo programa,

Observaciones f unciona correctamente y ref leja la acción esperada por el usuario, la cual es,
almacenar en la base de datos, el nuevo programa que el usuario añadió.
96
5.4.3.1.5 Caso de prueba “eliminar programa”
Tabla 5.12 Caso de prueba “eliminar programa”
Caso de prueba Eliminar programa
Número de caso
5
de prueba
Eliminar programas cuya vigencia haya terminado o por petición de la

Propósito
productora.
El encargado del área de programación televisiva realiza una búsqueda del

Descripción programa que desea eliminar, cuando los datos aparecen en pantalla, el usuario
breve selecciona el programa, presiona el botón de eliminar y esto borrará los datos del
programa de la base de datos, así como los capítulos de dicho programa.
Nivel de
importancia
(1) Poca 3
(2) Moderada
(3) Alta
Curso (Flujo) 1.- El encargado del área de 2.- El sistema devuelve la lista de
típico de programación televisiva realiza una programas según las especif icaciones
eventos búsqueda del programa que desea dadas por el encargado del área de
eliminar. programación televisiva.
3.- El encargado del área de 4.- El sistema elimina los datos del
programación televisiva selecciona el programa y toda la inf ormación
programa que desea eliminar. relacionada con el mismo, por ejemplo,
los capítulos.

base de datos. error por la conexión a la base de
Extensiones datos.
(flujo alternativo) 2.- El encargado del área de
programación televisiva revisa la
Cumplimiento
95%
(0-100 %)
97
La respuesta del sistema a la acción de eliminar un programa es correcta y se
logra de manera satisf actoria. Sin embargo, podría implementarse una medida
para no eliminar completamente los programas, es decir, mantener su
Observaciones inf ormación en otra parte de la base de datos del sistema. Aunque cabe
mencionar que, por cuestiones legales de la dependencia, no se puede realizar
esta acción, en el sistema podría ser una buena implementación.
5.4.3.1.6 Caso de prueba “modificar programa”
Tabla 5.13 Caso de prueba “modificar programa”
Caso de prueba Modif icar programa
Número de caso de
6
prueba
Propósito Corregir o cambiar los datos de un programa en caso de necesitarlo.
El encargado del área de programación televisiva realiza una búsqueda del

programa que desea corregir, una vez que los resultados aparecen en
Descripción breve pantalla, el usuario puede cambiar los datos en la tabla de resultados, pulsa
el botón de actualizar y se modif icarán los datos en la base de datos.
Nivel de importancia
(1) Poca
3
(2) Moderada
(3) Alta
Respuesta esperada del

Acción del usuario.
sistema.
1.- El encargado del área de 2.- El sistema devuelve la lista

programación televisiva realiza una de programas según las
búsqueda del programa que desea especif icaciones de la
Curso (Flujo) típico de modif icar. búsqueda.
eventos
3.- El encargado del área de 4.- El sistema actualiza la
programación televisiva modif ica la inf ormación que ha sido
inf ormación necesaria en la tabla de modif icada en la tabla y se
resultados. guarda en la base de datos.
5.- El sistema termina el

proceso.
98
a.- Ocurre un error de conexión a la base 1.- El sistema muestra un
de datos. mensaje de error por la
conexión a la base de datos.
Extensiones (flujo
alternativo)
programación televisiva revisa la
Cumplimiento
100%
(0-100 %)
Este escenario f unciona correctamente, ya que cumple con la respuesta a

Observaciones la acción de modif icar la inf ormación de los programas del sistema en la
base de datos.
Fuente: Creación propia
5.4.3.1.7 Caso de prueba “catálogo de programas”
Tabla 5.14 Caso de prueba “catálogo de programas”
Caso de
Catálogo de programas
prueba
Número de
caso de 7
prueba
Exportar en f ormato PDF una lista de programas que será presentada como
Propósito
propuesta para la programación televisiva del día.
El encargado del área de programación televisiva realiza una búsqueda de

Descripción programas que compartan una característica (duración, categoría, título, etc.), se
breve presentará una lista de programas con dicha característica, la cual puede ser
exportada en f ormato PDF por el botón exportar.
Nivel de
importancia
(1) Poca 3
(2) Moderada
(3) Alta
99
1.- El encargado del área de 2.- El sistema devuelve una lista con los
programación televisiva realiza una programas que compartan la
búsqueda de programas que comparten característica deseada.
Curso (Flujo) una característica.
típico de 4.- El sistema crea y exporta un archivo
eventos 3.- El encargado del área de en f ormato PDF con la tabla de
programación televisiva revisa la lista y resultados.
si es la deseada la exporta.

Extensiones base de datos. error por la conexión a la base de datos.
(flujo
Cumplimiento
100%
(0-100 %)
Este escenario del sistema simplemente consiste en realizar consultas del usuario,
donde este realiza una búsqueda de algún programa determinado y el sistema a su
Observaciones vez, le muestra los resultados de la inf ormación dada por el usuario, estas consultas
se realizan de manera satisf actoria, es decir, el sistema cumple con esta f unción.
5.4.3.1.8 Caso de prueba “generar pauta programática”
Tabla 5.15 Caso de prueba “generar pauta programática”

Caso de
Generar pauta programática
prueba
Número de
8
caso de prueba
Crear la barra programática y almacenarla en la base de datos, así como

Propósito
exportarla en f ormato PDF.
El encargado del área de programación televisiva debe llenar el f ormulario con la

f echa, la hora, el programa, el capítulo, el tipo de transmisión y si las hay,
Descripción
observaciones de la transmisión, sin repetir horarios para la misma f echa, para así
breve
llenar la tabla de la barra programática, la cual puede ser exportada en f ormato
PDF.
Nivel de
importancia 3
(1) Poca
100
(2) Moderada
(3) Alta

sistema.
1.- El encargado del área de programación 2.- El sistema realiza una

televisiva selecciona la f echa en la cual búsqueda de esa f echa y carga los
trabajara. datos en caso de existir.
3.- El encargado del área de programación 6.- El sistema llena la tabla de

televisiva selecciona el horario del programa programación con los datos
que está por añadir a la programación. proporcionados y busca los datos
Curso (Flujo) necesarios para llenar la tabla.
típico de 4.- El encargado del área de programación
eventos televisiva selecciona el programa, el capítulo 7.- El sistema crea un archivo PDF
y el tipo de transmisión que será. con los datos de la tabla de
programación y lo guarda en la
5.- En caso de existir el encargado del área ubicación que el usuario
de programación televisiva escribe seleccione.
observaciones sobre la transmisión y añade
los datos. 8.- El sistema termina el proceso.

televisiva revisa que los datos sean correctos
y exporta los datos en f ormato PDF.
a.- Ocurre un error de conexión a la base de 1.- El sistema muestra un mensaje

datos. de error por la conexión a la base
Extensiones
(flujo de datos.
alternativo) televisiva revisa la conexión y vuelve a
intentar el proceso.
Cumplimiento
100%
(0-100 %)
Este escenario es uno de los más importantes del sistema, por lo que ha sido
f undamental que la respuesta del sistema a la acción del usuario, se resuelva de
Observaciones
manera satisf actoria, dando como resultado que, la f unción esté bien
implementada.
101
5.4.3.1.9 Caso de prueba “añadir contacto”
Tabla 5.16 Caso de prueba “añadir contacto”

Caso de
Añadir contacto
prueba
Número de
9
caso de prueba
Agregar contactos nuevos a las productoras con las que se tenía previo convenio
Propósito
y estaban guardadas en la base de datos.
El encargado del área de programación televisiva debe buscar la productora a la

cual se le añadirá el nuevo contacto, después llenar el f ormulario con el nombre, el
Descripción
número telef ónico, el correo electrónico y la dirección del contacto y presionar el
breve botón de agregar, esto vinculará al contacto con la productora y lo guardará en la
base de datos.
Nivel de
importancia
(1) Poca 3
(2) Moderada
(3) Alta

sistema.
1.- El encargado del área de programación 2.- El sistema devuelve una tabla
televisiva realiza una búsqueda de la con los resultados de la búsqueda.
productora a la que se le añadirá el contacto.
4.- El sistema despliega una
Curso (Flujo) 3.- El encargado del área de programación ventana con el f ormulario
típico de televisiva selecciona la productora y presiona necesario para ingresar el nuevo
eventos el botón de agregar contacto. contacto.
5.- El encargado del área de programación 6.- El sistema guarda la

televisiva ingresa el nombre, el número inf ormación en la base de datos y
telef ónico, el correo electrónico y la dirección vincula el contacto con la
del nuevo contacto. productora.

Extensiones
(flujo de datos.
102
Cumplimiento
100%
(0-100 %)
Este escenario es complementario al de agregar productoras, ya que este proceso

se puede llevar a cabo al momento de agregar una productora, sin embargo, en
Observaciones casos donde no se haya tenido la inf ormación de un contacto previo al registro, el
usuario puede realizar la acción, mediante esta opción, la cual f unciona
correctamente para dar respuesta al usuario.
5.4.3.1.10 Caso de prueba “eliminar contacto”
Tabla 5.17 Caso de prueba “eliminar contacto”

Caso de
Eliminar contacto.
prueba
Número de
10
caso de prueba
Propósito Eliminar contactos obsoletos de la base de datos.
El encargado del área de programación televisiva debe realizar una búsqueda de

la productora de la cual se eliminará el contacto, una vez seleccionada la
Descripción
productora aparecerán los contactos de la misma, el usuario debe seleccionar el
breve
contacto a eliminar y después pulsar el botón de borrar, esto eliminará al contacto
de la base de datos.
Nivel de
importancia
(1) Poca 3
(2) Moderada
(3) Alta

sistema.
Curso (Flujo) 1.- El encargado del área de programación 2.- El sistema muestra una tabla
típico de televisiva realiza una búsqueda de la con los resultados de la búsqueda.
eventos productora de la cual eliminará el contacto.
4.- El sistema muestra una tabla
3.- El encargado del área de programación con los contactos de la productora
televisiva selecciona la productora de la cual seleccionada.
eliminará el contacto.
103
5.- El encargado del área de programación 6.- El sistema desvincula al
televisiva selecciona al contacto que desea contacto de la productora y lo
eliminar y pulsa el botón para borrarlo. elimina de la base de datos.

Extensiones
(flujo de datos.
Cumplimiento
100%
(0-100 %)
La respuesta del sistema a la acción de eliminar un contacto es correcta y se logra

de manera satisf actoria. Sin embargo, podría implementarse una medida para no
eliminar completamente los contactos, es decir, mantener su inf ormación en otra
Observaciones parte de la base de datos del sistema por si el usuario la requiere en otro momento.
Aunque cabe mencionar que, por cuestiones legales de la dependencia, no se
puede realizar esta acción, podría ser una buena implementación en el sistema.
5.4.3.1.11 Caso de prueba “añadir capítulo ”
Tabla 5.18 Caso de prueba “añadir capítulo”

Caso de
Añadir capítulo.
prueba
Número de
11
caso de prueba
Propósito Añadir nuevos capítulos a programas guardados en la base de datos.
El encargado del área de programación televisiva debe seleccionar el programa al

Descripción que se le agregaran los capítulos, luego ingresar el ID del capítulo, el nombre del
breve capítulo y su duración, al presionar el botón guardar, los capítulos serán añadidos
a la base de datos y se vincularan con el programa seleccionado.
Nivel de
importancia
3
(1) Poca
(2) Moderada
104
(3) Alta

sistema.
1.- El encargado del área de programación 3.- El sistema guarda la

Curso (Flujo) televisiva elige el programa al que desea inf ormación en la base de datos y
típico de agregar capítulos. vincula los capítulos con el
eventos programa antes seleccionado.
televisiva ingresa el ID del capítulo, el nombre 4.- El sistema termina el proceso.
y la duración de los capítulos en la tabla que
se presenta y presiona el botón guardar.

Extensiones
(flujo de datos.
Cumplimiento
100%
(0-100 %)
El sistema cumple con esta especif icación de manera correcta, siendo esta una
f unción que complementa a la de agregar programa, por lo que ha sido
Observaciones
imprescindible para que ambas f uncionen en conjunto, en las pruebas de unidad
del sistema.
5.4.3.1.12 Caso de prueba “modificar capítulo”
Tabla 5.19 Caso de prueba “modificar capítulo”
Caso de
Modif icar capítulo.
prueba
Número de
12
caso de prueba
Propósito Modif icar datos de los capítulos en caso de ser requerido.
El encargado del área de programación televisiva debe realizar una búsqueda del
Descripción capítulo que será modif icado, una vez realizada la búsqueda se visualizará una
breve tabla con los datos del capítulo, el usuario modif ica los datos que requiera y luego
presiona el botón actualizar, esto modif icará los datos en la base de datos.
105
Nivel de
importancia
(1) Poca 3
(2) Moderada
(3) Alta

sistema.
1.- El encargado del área de programación 2.- El sistema muestra el resultado

televisiva realiza una búsqueda del programa de la búsqueda.
Curso (Flujo) al que se le modif icaran los capítulos.
típico de 4.- El sistema muestra los
eventos 3.- El encargado del área de programación capítulos de ese programa.
televisiva selecciona el programa deseado.
6.- El sistema actualiza la
5.- El encargado del área de programación inf ormación en la base de datos.
televisiva modif ica la inf ormación de los
capítulos que necesita y presiona el botón 7.- El sistema termina el proceso.
actualizar.

Extensiones
(flujo de datos.
Cumplimiento
100%
(0-100 %)
Este escenario modif ica correctamente la inf ormación de los capítulos de algún
programa determinado directamente a la base de datos, ya sea que se desee
Observaciones actualizar la inf ormación de los mismos. Cumple correctamente con la solicitud del
usuario.
106
5.4.3.1.13 Caso de prueba “eliminar capítulo”
Tabla 5.20 Caso de prueba “eliminar capítulo”

Caso de
Eliminar capítulo.
prueba
Número de
13
caso de prueba
Propósito Eliminar capítulos cuya vigencia haya expirado o por petición de la productora.
El encargado del área de programación televisiva debe realizar una búsqueda del
Descripción capítulo que será eliminado, luego seleccionará de la tabla de resultados el capítulo
breve a eliminar, al presionar el botón borrar, el capítulo será eliminado de la base de
datos.
Nivel de
importancia
(1) Poca 3
(2) Moderada
(3) Alta

sistema.
1.- El encargado del área de programación 2.- El sistema muestra los

televisiva realiza una búsqueda del programa resultados de la búsqueda
al que desea eliminar capítulos. realizada.
Curso (Flujo)
típico de
eventos 3.- El encargado del área de programación 4.- El sistema muestra los
televisiva selecciona el programa al que capítulos del programa
desea eliminar capítulos. seleccionado.
5.- El encargado del área de programación 6.- El sistema elimina la

televisiva selecciona el capítulo que desea inf ormación de ese capítulo de la
eliminar y presiona el botón borrar. base de datos.

Extensiones
(flujo de datos.
107
Cumplimiento
100%
(0-100 %)
En caso de que el usuario lo requiera, este escenario f unciona de manera

satisf actoria a la petición de eliminar uno o más capítulos de los programas
Observaciones
almacenados en la base de datos, por lo que se considera que cumple con la
f unción para la que f ue implementado.
Fuente: Creación Propia.
5.4.3.1.14 Caso de prueba “modificar pauta programática”
Tabla 5.21 Caso de prueba “modificar pauta programática”

Caso de
Modif icar pauta programática.
prueba
Número de
14
caso de prueba
Propósito Modif icar la pauta programática de distintas f echas.
El encargado del área de programación televisiva debe seleccionar la f echa de la

pauta a modif icar, una vez que la tabla de resultados aparezca, puede seleccionar
Descripción
programas o spots de diversos horarios y eliminarlos, para poder sustituirlos por
breve
nuevos programas o spots, al presionar el botón añadir, la base de datos se
actualizará.
Nivel de
importancia
(1) Poca 3
(2) Moderada
(3) Alta

sistema.
Curso (Flujo) 1.-El encargado del área de programación 2.-El sistema muestra la pauta
típico de televisiva selecciona la f echa en la cual se programática de esa f echa.
eventos realizará la modif icación.
4.-El sistema modif ica la base de
3.-El encargado del área de programación datos con los nuevos datos que
televisiva elimina y agrega los datos que sean ingresó el encargado del área de
necesarios, programación televisiva.
108
5.-El sistema termina el proceso.

Extensiones
(flujo de datos.
Cumplimiento
100%
(0-100 %)
Este escenario, es complementario del escenario donde se crea la pauta

programática, debido a que nos permite realizar una modif icación en las pautas
creadas, ya sea agregando o quitando los programas y horarios añadidos
Observaciones previamente. También es una de las f uncionalidades más relevantes del sistema,
por lo que ha sido desarrollada e implementada de tal f orma que el usuario pueda
hacer uso de la misma, de manera satisf actoria.
5.4.3.1.15 Caso de prueba “diseño de interfaz”
Tabla 5.22 Caso de prueba “diseño de interfaz”
Caso de prueba Diseño de interf az
Número de caso de
15
prueba
Propósito Permitir al usuario una f ácil comprensión y manejo del sof tware.
La interf az permite al usuario hacer uso del sistema de una f orma ef iciente y
que permita la f ácil comprensión del mismo. Además, permite un mejor
Descripción breve manejo de manera que el usuario lleve a cabo los procesos de manera más
sencilla.
Nivel de importancia
(1) Poca
(2) Moderada 3
(3) Alta
Aspectos a
Cumplimiento Observaciones
considerar.
109
(0-100 %)
¿La interf az lleva La mayoría de las operaciones en el sistema son intuibles,

hacia una 98% sin embargo, puede que, en algunos casos, los usuarios
comprensión f ácil? requieran de alguna explicación previa.
¿Todas las
Las f unciones principales son reconocibles a simple vista,
operaciones son
100% y se pueden iniciar al momento, se encuentran centradas y
f áciles de localizar e
eso permite localizar rápido los controles.
iniciar?
La mayoría de los controles están colocados de manera

lógica de f orma que, siguiendo la secuencia de llenado de
¿La estética ayuda a
90% f ormularios sea sencillo encontrar los botones, aunque en
la comprensión y uso?
situaciones como las opciones de búsqueda de programas,
los botones se pueden perder un poco a la vista del usuario.
¿La distribución y
La interf az permite que el usuario haga uso del
estilo de la interf az
autocompletado de datos en caso de que estos ya existan,
permite que un
lo cual hace que las operaciones se puedan realizar con
usuario introduzca con 99% mayor ef iciencia. También muestra aviso de datos f altantes
ef iciencia las
lo cual permite al usuario notar con f acilidad si hubo algún
operaciones y la
error al introducir la inf ormación.
inf ormación?
¿Los datos de salida o Para los usuarios con previo conocimiento del sistema, es
el contenido están muy sencillo identif icar la inf ormación que requieran al
presentados de modo 98% momento de consultarla, sin embargo, para usuarios
que se entienden de nuevos puede llevar más tiempo interpretar la inf ormación
inmediato? representada.
¿Las operaciones
jerárquicas están
La mayoría de ingresos de datos y f unciones primarias son
organizadas de
accesibles desde el menú lateral de manera simple, solo
manera que minimizan
en caso de ingresos secundarios de datos, o datos
la prof undidad con la 100% complementarios que no se tenían en el ingreso original, es
que debe navegar el
necesario acceder a una página que requiere un botón
usuario para hacer
que alguna se extra.
ejecute?
¿El sof tware El sof tware reconoce datos mal ingresados, ya sea que
reconocerá el error si tengan una longitud dif erente a la que es necesaria para el
entran datos en el campo, ciertos datos que no sean válidos, así como, datos
límite de lo permitido o 100%
corruptos en los datos de programación, permitiendo
más allá y, lo que es eliminarlos en caso de f allos, lo cual permite mantener los
más importante, datos lo más limpios posible.
continuará operando
110
sin f allar ni
degradarse?
¿La interf az da un
diagnóstico y guía
útiles cuando se El sistema tiene mensajes de advertencia en acciones
descubre una clave que permite evitar errores de pulsación, muestra
condición de error 100% errores de conexión y muchas veces permite continuar con
(asociada con la el trabajo e intentar nuevamente.
f uncionalidad del
sof tware)?
¿La interf az tiene gran

capacidad para
permitir al usuario
moverse entre Los 3 módulos principales son accesibles de manera
pantallas principales sencilla gracias al menú lateral que acompaña siempre al
con pocos 100% usuario, de esta manera puede hacer movimientos rápidos
movimientos, entre ellos.
permitiendo así
cambiar de módulo de
manera práctica?
¿La interf az se limita a

Aunque la interf az de algún modo es intuible y se han
usar solo los espacios
utilizado colores que benef ician un poco la vista del usuario,
necesarios, sin tener
hay espacios “muertos” en la interf az, es decir, hay
espacios innecesarios 90%
espacios vacíos que no se aprovechan por ningún
que estéticamente no
f ormulario o botón del sistema, lo cual estéticamente no lo
sean adecuados para
hace ver del todo bien.
el usuario?
5.4.3.2 Reporte de casos de prueba de software
La guía aplicada para las pruebas de software consistió en un formato de tabla

propuesto en UML, en este caso para documentar los casos de prueba con base en
los escenarios. En las tablas se muestra el nombre del caso de prueba, su
identificador o número, el objetivo, la descripción, el nivel de importancia y se
muestra el curso típico del evento de acuerdo a la acción del usuario y respuesta
del sistema, esto con la finalidad de evaluar si el software cumple con su respectiva
funcionalidad. Además, también se muestra el flujo alternativo, es decir, las otras
posibles acciones y respuestas del sistema que podrían ocurrir al momento del uso
del mismo.
111
Finalmente, se muestra una fila donde se debe indicar el porcentaje en el que se
cumple satisfactoriamente cada escenario y las observaciones correspondientes.
Una vez aplicada la guía de pruebas al software y en función de los resultados

obtenidos, se observó que había mejorado de acuerdo a las modificaciones que se
realizaron después de la revisión técnica formal; como bien se mencionó
previamente, las pruebas se realizaron basadas en escenarios, lo cual permitió
evaluar si el software responde adecuadamente a las acciones y peticiones del
usuario. Una vez evaluados estos escenarios, se pudo ir descartando errores y
también identificando posibles mejoras en el funcionamiento del sistema.
Se realizaron las pruebas correspondientes y enfocadas en los métodos orientados

a objetos; en este sentido, los resultados han sido en su mayoría satisfactorios ya
que se han considerado favorables en los aspectos que corresponden a la calidad
del software. Cabe mencionar que algunas de las observaciones que posiblemente
aún se pueden atender, son solamente detalles pero que en su mayoría
corresponden a las limitaciones en los requerimientos de software del área de
programación televisiva, un ejemplo de ello es el aspecto de eliminar datos del
sistema, en donde no podemos hacer ningún tipo de respaldo de la información o
mantenerla en la base de datos como si fuera una papelera de reciclaje, si el usuario
ha decidido eliminarla, ya que esto podría ocasionar inconformidades en los
convenios de las distintas productoras con el Sistema Chiapaneco de Radio,
Televisión y Cinematografía.
Para los resultados de las pruebas de software que se aplicaron con base en la guía
de pruebas realizada previamente, debe tomarse en cuenta que se han realizado
por los mismos desarrolladores, lo cual da apertura a que pruebas de externos
puedan arrojar algunas otras observaciones y mejoras que se puedan realizar al
software. Las observaciones obtenidas en estas pruebas permiten que aún se
pueda seguir trabajando en la mejora del proyecto hasta hacerlo trascender en un
producto de total calidad.
112
5.4.4 Aseguramiento de la calidad
Luego de realizar todo el proceso de análisis de la calidad del software, el cual

incluyó la revisión, verificación, pruebas y corrección del mismo, se puede concluir
de manera general y con base en los resultados obtenidos durante el proceso, que
el software se encuentra completado y funcionando en un 95 % del nivel esperado.
Sin embargo, cabe mencionar que, eso no significa que no se haya podido lograr el
otro 5% faltante, sino que, las limitaciones en los requerimientos de los usuarios
fueron claros y específicos en cuanto a algunos aspectos, lo cual no permitió hacer
los cambios que quizás en su momento se consideraron para la mejora completa
del software. No obstante, los cambios que se fueron realizando en el proceso de
mejora son completamente notables en el producto final de software, esto
considerando que se hicieron las correcciones de acuerdo a las observaciones que
se fueron obteniendo durante el análisis, la revisión y verificación del mismo. Lo cual
ha garantizado que el resultado del producto obtenido cumpla en su totalidad con
los requisitos expuestos por el usuario, lo cual es sin lugar a dudas el objetivo de
todo este proceso.
Conforme se llevaron a cabo todas las revisiones y evaluaciones del sistema se

fueron encontrando detalles que en su momento podían representar un riesgo o un
error del software, lo cual afectaría en su funcionamiento; sin embargo, gracias al
procedimiento llevado a cabo durante todo el proceso, se lograron resolver y como
resultado se obtuvo un software de calidad.
Finalmente, cabe mencionar que todo lo aplicado en esta etapa del proyecto ha
permitido identificar los posibles errores que pueden representar pérdidas y
problemas más complejos durante el desarrollo del software y durante su uso, y ha
sido de suma importancia conocer en qué consiste todo el proceso y todo lo que
conlleva para tenerlo presente en cualquier tipo de desarrollo que se realice,
además, también permite conocer el enfoque que debe seguirse de acuerdo al
proyecto que se esté realizando, de esta manera se obtendrá como resultado un
software que satisfaga las necesidades de sus usuarios finales y que al mismo
tiempo, sea un software de calidad.
113
5.4.5 Producto final
Figura 5.4 Pantalla de inicio
114
Figura 5.5 Pestaña “Programación”, interfaz “crear pauta programática”
Figura 5.6 Pestaña “Programas”, interfaz “agregar programas”
115
Figura 5.7 Pestaña “Programas”, interfaz “agregar capítulos”
Figura 5.8 Pestaña “Programas”, interfaz “buscar programas”
116
Figura 5.9 Pestaña “Programas”, interfaz “búsqueda de programas con vista de
capítulos y bloques”
Figura 5.10 Pestaña “Productoras”, interfaz “agregar productoras”
117
Figura 5.11 Pestaña “Productoras”, interfaz de “búsqueda de productoras”
Figura 5.12 Pestaña “Productoras”, interfaz “agregar contacto”
118
CONCLUSIONES
El objetivo de este proyecto de investigación fue optimizar la gestión de los recursos

audiovisuales y la programación televisiva del Sistema Chiapaneco de Radio,
Televisión y Cinematografía, mediante el desarrollo de un software y aplicando el
proceso de aseguramiento de la calidad. Con base en un análisis cualitativo y
utilizando como método de investigación el estudio de caso, se aplicaron las
técnicas de observación a los procesos del área de programación televisiva y
entrevistas al personal y, como resultado de ello, se obtuvo información a través de
la cual se realizó la ingeniería de requisitos para posteriormente realizar el desarrollo
del software.
Tomando en cuenta la relevancia que tiene el tema de la calidad del software en la

actualidad, es importante identificar las buenas prácticas del proceso de desarrollo
y aplicarlas desde las etapas iniciales del mismo, esto evita que errores de
modelado, diseño y codificación trasciendan a etapas tardías del proyecto. Además,
el paradigma orientado a objetos y la metodología RUP utilizados para el desarrollo
del sistema, son aspectos importantes que ayudaron a cumplir el objetivo del
proyecto puesto que proveen algunas pautas que permiten la evolución constante y
mejora del sistema.
Los resultados de la investigación indican que las características, elementos,

técnicas, métricas y modelos que se aplicaron en el proceso de aseguramiento de
la calidad del software, ayudaron a generar un producto que cumple con los
estándares de la industria y con ello se garantiza que la gestión de los recursos
audiovisuales y la programación televisiva se realice con apoyo de una herramienta
tecnológica de calidad.
119
REFERENCIAS
Apache Friends. (s.f.). Apache Friends Web Site. Obtenido de:

https://www.apachefriends.org/es/about.html
Báez Pérez, C. I. (2013). Proceso de desarrollo de software basado en la

articulación de RUP y CMMI. Boyacá: Universidad de Boyacá.
Pérez, H., & Esquivel, J. A. (2007). Ruby: Lenguaje de programación para sistemas
distribuidos. Aguascalientes: Instituto tecnológico de Aguascalientes.
Challenger-Pérez, I., Díaz-Ricardo, Y. & Becerra-García, R. A. (2014). El lenguaje

de programación Python. Holguín: Centro de información y gestión
tecnológica de Santiago de Cuba.
Córdova, D. F. (2015). Análisis comparativo de los modelos y estándares de calidad

de software y aplicación de las mejores prácticas para el levantamiento del
proceso de gestión de calidad de productos de software. Quito: Universidad
central del Ecuador.
Domínguez, I. (2005). Fundamentos teóricos de los paradigmas de programación.

Buenos Aires: Universidad tecnológica nacional.
Durán, M. M. (2012). El estudio de caso en la investigación cualitativa. San José:

Universidad estatal a distancia.
Ferré, X., & Sánchez, M. I. (2011). Desarrollo orientado a objetos con UML. Madrid:
Universidad politécnica de Madrid.
Flick, U. (2007). El diseño de investigación cualitativa. Madrid: Ediciones Morata.
García, T. & Rubí, S. (2018). UML, introducción al UML, modelando con UML,
utilidad del UML, conceptos de USE CASE, objetos, clases y atributos,
operaciones, aplicaciones. Lima: Universidad nacional de educación Enrique
Guzmán y Valle.
González, T., & Cano, A. (2010). Introducción al análisis de datos en investigación

cualitativa: Conceptos y características. Madrid: Nure Investigación.
Guerrero, M. A. (2016). La investigación cualitativa. Quito: Universidad Internacional

del Ecuador.
120
Guillen, D. F. (2007). Ruby Fácil. Bogotá: Universidad de los Andes.
Herrera, J. (2008). La investigación cualitativa. Guadalajara: Universidad de

Guadalajara.
Institute of Electrical and Electronics Engineers. (s.f.). IEEE Web Site. Obtenido de
History of IEEE: https://www.ieee.org/about/ieee-history.html
International Organization for Standardization. (s.f.). ISO Web Site. Obtenido de

About Us: https://www.iso.org/about-us.html
Kendall, K. E. & Kendall, J. E. (2011). Análisis y diseño de sistemas. Ciudad de

México: Pearson Education.
Maida, E. G. & Pacienzia, J. (2015). Metodologías de desarrollo de software. Buenos

Aires: Universidad católica de Argentina.
Marqués, M. (2011). Bases de datos. Castellón de la Plana: Universitat Jaume I.
Martínez, S. & Cortés, H. (2008|). Historias de las Sintonías. Tuxtla Gutiérrez:

Talleres Gráficos de Gobierno del Estado.
Martínez, J. (2011). Métodos de investigación cualitativa. Bogotá: Silogismos de

investigación.
Marzal, A. & García, I. (2003). Introducción a la programación con Python. Castellón

de la Plana: Universitat Jaume I.
Mera, J. A. (2016). Análisis del proceso de pruebas de calidad de software.

Popayán: Universidad cooperativa de Colombia.
Monje, C. A. (2011). Metodología de la investigación cuantitativa y cualitativa - Guía

Didáctica. Neiva: Universidad Surcolombiana.
Moreno, J. C. (2018). Entornos de desarrollo. Madrid: Editorial Síntesis.
Otero-Ortega, A. (2018). Enfoques de Investigación. Barranquilla: Universidad del

Atlántico.
Pantaleo, G. (2011). Calidad en el Desarrollo de Software. Ciudad de México:

Alfaomega.
Pilar, G. (2007). MOPROSOFT: Un camino hacia el éxito mundial en el desarrollo

del software mexicano. Puebla: Instituto Tecnológico de Puebla.
121
Pressman, R. S. (2010). Ingeniería del software un enfoque práctico. Ciudad de
México: Mc Graw Hill.
Ramos, E. (2016). Métodos y Técnicas de investigación. Minatitlán: Universidad

Valle de México.
Rodríguez, R., Sosa, E. & Prieto, Á. (2004). Programación orientada a objetos.

Cáceres: Librería papelería Álvaro.
Ruíz L. E. (2001). Lenguajes de programación: Conceptos y paradigmas. Lima:

Universidad nacional mayor de San Marcos.
Salgado, A. C. (2007). Investigación cualitativa: Diseños, evaluación del rigor

metodológico y retos. Lima: Universidad de San Martín de Porres.
Sánchez, J. M. (2015). Pruebas de software. Fundamentos y técnicas. Madrid:

Universidad Politécnica de Madrid.
Sánchez, D. (2016). Lenguaje de programación C#. Los Olivos: Universidad privada

del norte.
Sánchez, J. (2004). Principios sobre bases de datos relacionales. California:

Creative commons.
Sistema Chiapaneco de Radio, T. y. (s.f.). Radio, Tv y Cine, Chiapas. Obtenido de

Radio, Tv y Cine, Chiapas: http://radiotvycine.chiapas.gob.mx/
Solé, S., Venegas, M., Quintero, J. & Alvares, J. (2013). Aseguramiento de calidad
en el desarrollo de software libre. Mérida: Fundación CEDINTEL.
Somerville, I. (2005). Ingeniería del software. Madrid: Pearson Education.
Suárez, E. (2008). ¿Qué es una base de datos relacional? Humacao: Universidad

de Puerto Rico.
The World Wide Web Consortium. (s.f.). W3C Web Site. Obtenido de About W3C:
https://www.w3.org/Consortium/
122

Desarrollo de un sistema de administración de recursos audiovisuales con aseguramiento de calidad

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

Desarrollo de un sistema de administración de recursos audiovisuales con aseguramiento de calidad

Cargado por

Copyright:

Formatos disponibles

UNIVERSIDAD AUTÓNOMA DE CHIAPAS

FACULTAD DE CONTADURÍA Y ADMINISTRACIÓN

LICENCIATURA EN SISTEMAS COMPUTACIONALES

ASEGURAMIENTO DE LA CALIDAD DEL SOFTWARE EN EL

LICENCIADOS EN SISTEMAS COMPUTACIONALES

DEYSI ESTEFANÍA VELÁZQUEZ LIRA A160336

DAVID ALONSO UTRILLA TORIJA A160332

DRA. REBECA ROMÁN JULIÁN

TUXTLA GUTIÉRREZ, CHIAPAS ABRIL DE 2022

CAPÍTULO 2. REFERENTE CONCEPTUAL

CAPÍTULO 3. MARCO CONTEXTUAL

CAPÍTULO 4. DISEÑO METODOLÓGICO

CAPÍTULO 5. PROCESO DE ASEGURAMIENTO DE LA CALIDAD EN EL

Tabla 2.1 Tabla de percepciones del concepto de calidad …………………...….. 39

Tabla 5.1 Métodos interactivos ………………………………………………………. 76

Tabla 5.2 Requerimientos funcionales ……………………………………………… 76

Tabla 5.3 Requerimientos de base de datos ………………………………………. 77

Tabla 5.4 Requerimientos no funcionales ………………………………………….. 78

Tabla 5.5 Evaluación de los requerimientos del software ………………………… 85

Tabla 5.6 Evaluación de interfaz …………………………………………................ 85

Tabla 5.7 Evaluación de código …………………………………………................. 88

Tabla 5.8 Caso de prueba “agregar productoras” …………………………………. 92

Tabla 5.9 Caso de prueba “eliminar productoras” …………………………………. 93

Tabla 5.10 Caso de prueba “modificar productoras” ………………………………. 94

Tabla 5.11 Caso de prueba “agregar programa” …………………………………... 95

Tabla 5.12 Caso de prueba “eliminar programa” …………………………………… 97

Tabla 5.13 Caso de prueba “modificar programa” ………………………………… 98

Tabla 5.14 Caso de prueba “catálogo de programas” ……………………………… 99

Tabla 5.15 Caso de prueba “generar pauta programática” ………………………. 100

Tabla 5.16 Caso de prueba “añadir contacto” ..................................................... 102

Tabla 5.17 Caso de prueba “eliminar contacto” ................................................... 103

Tabla 5.18 Caso de prueba “añadir capítulo” ....................................................... 104

Tabla 5.20 Caso de prueba “eliminar capítulo” .................................................... 107

Tabla 5.21 Caso de prueba “modificar pauta programática” ................................ 108

Tabla 5.22 Caso de prueba “diseño de interfaz” .................................................. 109

Figura 4.1 Cédula de observación ....................................................................... 71

Figura 5.1 Especificación de casos de usos ........................................................ 79

Figura 5.2 Modelo de la base de datos ................................................................ 80

Figura 5.3 Cronograma para atender la revisión informal .................................... 83

Figura 5.4 Pantalla de inicio ................................................................................. 114

Figura 5.6 Pestaña “Programas”, interfaz “agregar programas” .......................... 115

Figura 5.7 Pestaña “Programas”, interfaz “agregar capítulos” ............................. 116

Figura 5.8 Pestaña “Programas”, interfaz “buscar programas” ............................ 116

Figura 5.9 Pestaña “Programas”, interfaz “búsqueda de programas con vista de

Figura 5.10 Pestaña “Productoras”, interfaz “agregar productoras” ..................... 117

Figura 5.11 Pestaña “Productoras”, interfaz de “búsqueda de productoras” ........ 118

Figura 5.12 Pestaña “Productoras”, interfaz “agregar contacto” ........................... 118

A mi compañero de aventuras David, por ser más que mi amigo y compañero de

Finalmente, un agradecimiento especial para la directora de esta tesis la Dra.

Deysi Estefanía Velázquez Lira

“A mi padre, que dejó en mí parte de su persona, forjó parte de mi carácter, me

A mi compañera en este viaje, Estefanía, por impulsarme a continuar y querer

David Alonso Utrilla Torija

La tesis que se expone es el producto de una investigación cualitativa aplicada a

El capítulo 2 describe la fundamentación conceptual del proyecto, respecto a las

El capítulo 3 se refiere al marco contextual del proyecto, describiendo al Sistema

El capítulo 4 expone el diseño metodológico, describiendo el enfoque, método y

Finalmente, el capítulo 5 detalla paso a paso el proceso de aseguramiento de la

1.1 Planteamiento del problema

El uso del software se ha incrementado a lo largo de los años; es decir, cada

Se entiende la calidad del software como un concepto complejo que no es

Pressman (2010) expone que: