Ventana informatica / Edicción 25

FACULTAD DE CIENCIAS E INGENIERÍA
Carrera 9 No. 19-03 - Apartado Aéreo: 868
Conmutador (6) 887 9680 extensión: 299
Manizales, Colombia
www.umanizales.edu.co
ventanainformatica@umanizales.edu.co
ventanainformatica@gmail.com

Nº 25 - julio - diciembre / 2011

GUILLERMO ORLANDO SIERRA SIERRA
Rector

JORGE IVÁN JURADO SALGADO
Vicerrector

Guillermo Arias Ostos
Decano
Facultad de Ciencias e Ingeniería

Director / Editor
OMAR ANTONIO VEGA
PhD(c)

VENTANA INFORMÁTICA
ISSN 0123-9678

Diseño y Diagramación
Gonzalo Gallego González

Impresión
Centro Editorial Universidad de Manizales

Derechos Reservados
2011

VENTANA INFORMÁTICA es una publicación semestral especializada de la Facultad
de Ciencias e Ingeniería de la Universidad de Manizales.
Está clasificada en la CATEGORÍA C, en IBN – Publindex (Actualización I – 2010),
para el periodo 10/01/2010 A 31/12/2011

2

Universidad de Manizales Facultad de Ciencias e Ingeniería

Comité Editorial
María Cecilia CALANI BARANUSKAS, PhD.
Instituto de Computação UNICAMP
Campinas, Sao Paulo, Brasil

David GRAU MERCONCHINI, MSc.
Centro de Información y Gestión Tecnológica, MEGACEN
Santiago de Cuba, Cuba

Héctor MORA PÁEZ, MSc
Instituto Colombiano de Geología y Minería, INGEOMINAS
Bogotá, Colombia

Carlos Eugenio OLIVEROS TASCÓN, PhD.
Centro Nacional de Investigaciones de Café, CENICAFÉ
Chinchiná, Colombia

Luis RODRÍGUEZ BAENA, PhD.
Universidad Pontificia de Salamanca, UPSAM
Madrid, España

Comité Científico de Redacción
Luis Carlos CORREA ORTIZ, MSc.
Universidad de Manizales
Manizales, Colombia

Julio César GÓMEZ CASTAÑO, PhD(c).
Manizales, Colombia

John Makario LONDOÑO BONILLA, PhD.
Instituto Colombiano de Geología y Minería, INGEOMINAS
Manizales, Colombia

Marcelo LÓPEZ TRUJILLO, PhD.
Universidad de Caldas
Manizales, Colombia

Omar Antonio VEGA, PhD(c).
Manizales, Colombia

3


Comité Científico de Arbitraje
(Integrantes que realizaron arbitraje de artículos para este número)

Andrea Catherine ALARCÓN ALDANA, MSc.
Universidad Pedagógica y Tecnológica de Colombia, UPTC
Tunja, Boyacá, Colombia

Carlos Alberto AMAYA TARAZONA, MSc.
Universidad Nacional Abierta y a Distancia, UNAD
Duitama, Boyacá, Colombia

Line Yasmín BECERRA SÁNCHEZ, MSc.
Universidad Católica de Pereira, UCP
Pereira, Risaralda, Colombia

Luis Marcial BERTEL PATERNINA, Esp.
Manizales, Caldas, Colombia

Mauro CALLEJAS CUERVO, MSc.
Universidad Pedagógica y Tecnológica de Colombia, UPTC
Tunja, Colombia

Luis Carlos CORREA ORTIZ, MSc.

Andrés David EPIFANÍA HUERTA, MSc.
Universidad Católica Los Ángeles de Chimbote, ULADECH
Chimbote, Ancash, Perú

Luis Alejandro FLÉTSCHER BOCANEGRA, MSc.

Mario Andrés GIRALDO FADUL, PhD.
Kennesaw State University, KSU
Kennesaw, Georgia, USA

Jorge Eliécer GIRALDO PLAZA, MSc.
Politécnico Colombiano Jaime Isaza Cadavid Medellín, Antioquia, Colombia

Julio César GÓMEZ CASTAÑO, PhD(c).

Marlene Lucila GUERRERO JULIO, MSc.
Universidad Pontificia Bolivariana
Bucaramanga, Santander, Colombia

4


Ricardo Alonso HURTADO MOSQUERA, MSc(c).

Gustavo Adolfo ISAZA ECHEVERRY, PhD.

Alejandro LONDOÑO VALENCIA, MSc.

Marcelo LÓPEZ TRUJILLO, PhD.

André Atanásio MARANHÃO ALMEIDA, MSc.
Instituto de Computación, UNICAMP
Campinas, São Paulo, Brasil

Carlos Eduardo MARULANDA ECHEVERRY, MSc.
Universidad de Caldas – Universidad Nacional de Colombia

Ana Teresa ORTEGA MINAKATA, MSc.
Instituto de Información Territorial del Estado de Jalisco
Zapopan, Jalisco, México

Liliana María PUERTA ESCOBAR, MSc.
OFG
Tres Cantos, Madrid, España

Luis RODRÍGUEZ BAENA, PhD.
Universidad Pontificia de Salamanca,
Madrid, España

Silvio Ricardo TIMARÁN PEREIRA, PhD.
Universidad de Nariño
Pasto, Nariño, Colombia

Saulo de Jesús TORRES RENGIFO, PhD(c).
Universidad Tecnológica de Pereira

Ábilo Andrés VELÁSQUEZ SALAZAR, MSc.
Universidad Nacional de Colombia

Ronald Eduard VINASCO SALAZAR, MSc.

5


6


En esta edición
Página

Editorial.....................................................................................................9-10
Omar Antonio VEGA

Sistema de administración y supervisión
de equipos en una red de datos............................................................ 11-24
[Management System and Monitoring Workstations in a Data Network]
Marco Emilio MONTES BOTERO y Julio César GOMEZ CASTAÑO

Simulación de técnicas de encolado con prioridad............................25-39
[Simulation of Techniques for Priority Queues]
Néstor Jaime CASTAÑO PÉREZ y Germán William LONDOÑO JIMÉNEZ

Certificación de la calidad del proceso y producto:
Ruta para pymes colombianas que fabrican software.......................41-61
[Certification process and product quality:
Route Colombian SME manufacturing software]
Luis Eduardo PELÁEZ VALENCIA; Ricardo Alonso HURTADO MOSQUERA y
Jorge Alberto FRANCO ESCOBAR

EquipAsso: un algoritmo para el descubrimiento de
conjuntos de ítems frecuentes sin generación de candidatos..........63-82
[EquipAsso: An Algorithm for Discovery Large
itemsets without Candidate Generation]
Ricardo TIMARÁN PEREIRA

Buses de campo y protocolos en redes industriales.......................83-109
[Fieldbus and Protocols in Industrial networks]
César Augusto SALAZAR SERNA y Luis Carlos CORREA ORTIZ

SMA Aplicado a la gestión de tráfico de voz en LAN...................... 111-127
[MAS Applied to Voice’s Traffic Management at LAN]
Néstor Jaime CASTAÑO PÉREZ y José Julián CARVAJAL VARGAS

Minería de datos con conjuntos aproximados
para clasificación de imágenes satelitales......................................129-158
[Data Mining with Rough Sets for Classification of Satellite Images]
Juan Olegario MONROY VÁSQUEZ

7


Propuesta metodológica para el desarrollo
de SIG mineros en Colombia............................................................159-172
[Methodological proposal for the development of GIS in Colombia mining]
Jorge Iván DELGADO ARIAS y Humberto Iván RÍOS ARIAS

Planeación, análisis y diseño del SIG
del Campus de la Universidad del Quindío.....................................173-188
[Planning, analyzing, and designing the SIG of the University of Quindío campus]
José Joaquín VILA ORTEGA; Lina María CASTRO BENAVIDES; Diana Marcela
RIVERA VALENCIA y Sergio Augusto CARDONA TORRES

Gestionar el conocimiento:
Una necesidad empresarial para sobrevivir en el siglo XXI...........189-216
[Managing knowledge: A business need to survive in the XXI century]
Carlos PETRELLA TÓFFOLO y Luis JOYANES AGUILAR

Construcción de conocimiento
significativo en ingeniería mecánica................................................217-230
[Construction of Significant Knowledge in Mechanical Engineering]
Alejandro Arturo PÉREZ VILLEGAS y Adriana María SÁNCHEZ NAVARRETE

Políticas editoriales de la revista Ventana Informática.....................231

Nota:
Los conceptos expresados en esta publicación son responsabilidad de los autores y no
comprometen el pensamiento de la Universidad ni de la Facultad de Ciencias e Ingeniería.
COPYRIGHT © UNIVERSIDAD DE MANIZALES

8


Editorial
Omar Antonio VEGA
Director/Editor

En la edición No. 25 se publican 11 artículos, seleccionados de los 36
presentados dentro de la convocatoria cerrada en agosto 20 de 2011,
procedentes de universidades colombianas (Industrial de Santander,
Católica de Pereira, Central, de Nariño y obviamente, de Manizales),
así como de Senect (Uruguay), la Universidad Pontificia de Salamanca
(campus Madrid, España), Universidad de Oriente (Santiago de Cuba)
y la Universidad Autónoma de San Luis de Potosí (México).
Los artículos se distribuyen tratando de seguir líneas temáticas, de la
siguiente manera:
Los primeros seis, relacionados con informática, presentan: - un sistema
de administración y supervisión de una red de datos, utilizando la meto-
dología ágil Scrum, que permite visualizar la estructura e inventario de
hardware y software, - la gestión de tráfico de paquetes con prioridad
en la cola, mediante la generación de variable aleatorias de tiempo
utilizando métodos de simulación de eventos discretos, - el abordaje
de los procesos de certificación de calidad de software en el ámbito
colombiano, - el algoritmo EquipAsso, que encuentra directamente los
conjuntos de ítems frecuentes sin la generación de conjuntos candida-
tos, utilizando los operadores algebraicos relacionales EquiKeep y As-
sociator, - el funcionamiento de las redes industriales, sus componentes
y protocolos principales, y - la aplicación de un Sistema Multi-Agente
a la gestión de tráfico de Voz IP en una red de datos de área local sin
equipos activos de alta gama
Luego, se presentan tres artículos en el área de Geomática, que con-
sisten en: - el estado del arte frente al uso de Rough Set en la clasifi-
cación de imágenes satelitales, - una propuesta metodológica para el
desarrollo de SIG mineros en Colombia, y – una metodología de trabajo
para la fase de análisis y diseño del proceso de desarrollo de SIG en
la Universidad del Quindío.
A continuación, aparecen dos artículos donde se trata, respectivamente,
- la necesidad que tienen las empresas de gestionar su conocimiento,
como una manera de lograr la sobrevivencia, y - el desarrollo de un
prototipo para realizar pruebas de tensión, por un grupo de alumnos de
Ingeniería Mecánica de la Universidad Autónoma de San Luis de Potosí.
Para finalizar, se presentan las políticas editoriales, en la búsqueda de
la mayor claridad en los procesos de recibo, selección, publicación y

9


distribución, como manera de facilitar e incitar la participación de dife-
rentes comunidades científicas.
Es de recordar que la revista cierra su convocatoria en febrero 20 para
los números del primer semestre y para el segundo, en agosto 20, lo
cual ratifica la invitación abierta a participar en ellas, porque…

Alguien está necesitando la información que usted
está dispuesto a brindar. Usted está necesitando la
información que alguien está dispuesto a brindar…

Ventana Informática se mantiene abierta para que
la información fluya en ambas direcciones.

10


Sistema de administración
y supervisión de equipos
en una red de datos*1
[Management System and Monitoring
Workstations in a Data Network]
Marco Emilio MONTES BOTERO2 , Julio César GOMEZ CASTAÑO3

Recibo: 02.03.2011 - Ajuste: 20.05.2011 - Ajuste: 20.10.2011 - Aprobación: 10.12.2011

Resumen
El sistema de administración y supervisión del hardware y el
software de los equipos en una red de datos, es de tipo cliente/
servidor y permitirá, a los administradores de red, visualizar en
un plano arquitectónico de la empresa, todos los equipos que
componen la red, a través de una interfaz gráfica, y sobre ésta
tendrán la posibilidad de consultar la información del inventario
de hardware y software de cada uno de ellos, los cambios que
se presenten en los mismos, y las funciones de supervisión.
El desarrollo del proyecto está basado en la metodología ágil
Scrum. Las herramientas de desarrollo e implementación utiliza-
das para la elaboración del sistema web corresponden a software
libre; entre ellas Ruby on Rails, Rest, XML, Apache, Passenger
y Netbeans. Se logró implementar el sistema de administración
y supervisión, utilizando un sistema agente, con diferencias res-
pecto a otras herramientas similares existentes en el mercado.

* Modelo para citación de este artículo de reflexión:
MONTES BOTERO, Marco Emilio y GÓMEZ CASTAÑO, Julio César (2011). Sistema de
administración y supervisión de equipos en una red de datos. En: Ventana Informática. No.
25 (jul. – dic., 2011). Manizales (Colombia): Facultad de Ciencias e Ingeniería, Universidad
de Manizales. p. 11-24. ISSN: 0123-9678
1 Artículo proveniente del proyecto titulado Sistema SCADA para la administración y supervisión
de equipos en una red de datos, ejecutado entre octubre de 2009 y febrero de 2011, e inscrito
en el grupo de investigación y desarrollo en Informática y Telecomunicaciones, para optar al
título, en la Universidad de Manizales, de Ingeniero de Sistemas y Telecomunicaciones por
parte del primer autor, bajo la dirección del segundo.
2 Ingeniero de Sistemas y Telecomunicaciones. Gerente, Siete Cumbres S.A.S, Manizales
(Colombia). Correo electrónico: marcomontes@gmail.com.
3 Docente, Facultad de Ciencias e Ingeniería, Universidad de Manizales. Correo electrónico:
jgomez@umanizales.edu.co.

Nº 25 - Universidad de Manizales, julio-diciembre/2011 - pp 11-24 11


El proyecto llegó a ser finalista en la cuarta convocatoria del
programa nacional Destapa Futuro año 2009-2010 realizado
por la Fundación Bavaria.
Palabras Clave: Supervisión, Administración, Inventario, Alarma,
OWASP, Scrum.

Abstract
The management and monitoring system is client/server, and
enable network administrators to view an architectural plan of
the company, all computers in the network. On the graphical
interface, they can check the information hardware and software
inventory of each of these teams, the changes that occur in them,
and monitoring functions. The project is based on the Scrum
agile methodology and free tools for development and implemen-
tation, such as Ruby on Rails, Rest, XML, Apache, Passenger
and Netbeans. It was possible to implement the management
and monitoring system, using a broker. The article shows the
differences of the system with other similar tools on the market.
The project was presented to the fourth edition of the national
Uncover Future 2009-2010, conducted by the Foundation Ba-
varia, which was a finalist.
Keywords: Monitoring, Management, Inventory, Alarm, OWASP,
Scrum.

Introducción
La administración de los activos tecnológicos de una empresa, en mu-
chos casos está mal enfocada o hace uso de medios y metodologías
inapropiadas para su buen desempeño. Juega un papel importante el
manejo eficiente y seguro de la información relacionada con los equipos
de cómputo disponibles en una empresa, ya que se hacen inventarios
y revisiones manuales sólo en caso de ocurrir algún incidente en estos
equipos.
Este proyecto tiene como sustento la sistematización de estos proce-
sos, mediante actividades de administración y supervisión, como son el
control de supervisión, automatización y adquisición de datos, con el fin
de agilizar y garantizar la seguridad en la administración de los activos
tecnológicos de una empresa, generando innovación y posibilidades
de empleo en campos de estudio específicos de la informática como lo
son el desarrollo de software, la seguridad informática y el supervisión
de equipos.

12


Además, el uso de la metodología ágil Scrum, se adapta perfectamente
al desarrollo de un proyecto de este tipo, en el cual los requerimientos
surgen o cambian en cualquier momento, permitiendo un alto nivel
de adaptabilidad a las circunstancias cambiantes de la evolución del
proceso.
Finalmente, el ciclo de vida del desarrollo del proyecto, adaptado a las
metodologías ágiles de desarrollo, recomendaciones de desarrollo más
seguro y el seguimiento de estándares y protocolos para intercambio de
datos entre aplicaciones, permitirá una perfecta sinergia de herramientas
de software nuevas o existentes que requieran el acceso a consultas
y/o manipulación de la información generada por este proyecto.

1. Fundamento teórico
1.1 Windows Management Instrumentation
Según AJPDSoft (2010), Windows Management Instrumentation (WMI
o Instrumental de administración de Windows) es una iniciativa que
pretende establecer normas estándar para tener acceso y compartir
la información de administración a través de la red de una empresa.
WMI incluye un repositorio de objetos, a modo de base de datos de
definiciones de objetos, y el administrador de objetos CIM, que controla
la recopilación y manipulación de objetos en el repositorio y reúne infor-
mación de los proveedores de WMI. Los proveedores de WMI actúan
como intermediarios entre los componentes del sistema operativo, las
aplicaciones y otros sistemas.
Los proveedores proporcionan información acerca de sus componentes,
y podrían proporcionar métodos para manipular los componentes, las
propiedades que se pueden establecer, o los sucesos que le pueden
alertar de las modificaciones efectuadas en los componentes.
Por ejemplo, con WMI se podría obtener información detallada del
procesador y de los diferentes componentes de hardware y software
del equipo.
1.2 Representational State Transfer, REST
REST es un estilo de arquitectura de software para sistemas hiper-
medias distribuidos tales como la Web y se refiere estrictamente a
una colección de principios para el diseño de arquitecturas en red.
Estos principios resumen cómo los recursos son definidos y disec-
cionados. Está basado en estándares HTTP, URL, representación
de recursos XML/HTML/GIF/JPEG y tipos MIME text/xml, text/html.
Su funcionamiento en la identificación de recursos y manipulación

13


de ellos a través de representaciones, mensajes autodescriptivos y
mecanismos de reconocimiento del estado de la aplicación, como lo
expresa Navarro (2007).
1.3 Open Web Application Security Project, OWASP
Consiste en un proyecto de código abierto dedicado a determinar y com-
batir las causas que hacen inseguro al software. La misión de OWASP
(2011) «es hacer la seguridad en aplicaciones “visible”, de manera
que las organizaciones pueden hacer decisiones informadas sobre
los riesgos en la seguridad de aplicaciones». La Fundación OWASP,
un organismo sin ánimo de lucro que apoya y gestiona proyectos e
infraestructura, está formada por empresas, organizaciones educativas
y particulares de todo mundo. Juntos constituyen una comunidad de
seguridad informática que trabaja para crear artículos, metodologías,
documentación, herramientas y tecnologías que se liberan y pueden
ser usadas gratuitamente por cualquiera.
1.3.1 OWASP Top 10. Proyecto de la Fundación OWASP que pretende
recopilar los diez tipos de vulnerabilidades en aplicaciones web que
suponen el mayor riesgo para su seguridad. Según OWASP (2010a)
las diez vulnerabilidades más críticas que se han recogido en la versión
del año 2010, son las siguientes:
• Inyecciones: Vulnerabilidades de inyección de código, desde SQL
hasta comandos del sistema.
• Cross-site Scripting: Una de las vulnerabilidades más extendidas y
a la par subestimadas, que abarca cualquier ataque que permitiera
ejecutar código scripting.
• Gestión defectuosa de sesiones y autenticación: Comprende los
errores y fallos en las funciones de administración de sesiones y
validación de usuario.
• Referencias directas a objetos inseguras: Errores al exponer par-
tes privadas o internas de una aplicación sin control y accesibles
públicamente.
• Cross-site Request Forgery: Vulnerabilidad consistente en el des-
encadenamiento de acciones legítimas por parte de un usuario
autenticado, de manera inadvertida por este último y bajo el control
de un atacante.
• Configuración de seguridad mala o ausente: Más que un error en
el código, se trata de la falta o mala configuración de seguridad de
todo el conjunto de elementos que comprende el despliegue de una
aplicación web, desde la misma aplicación hasta la configuración
del sistema operativo o el servidor web.

14


• Almacenamiento con cifrado inseguro: Referida a la ausencia o mal
uso de los sistemas de cifrado en relación a los datos almacenados
o manejados por la aplicación.
• Falta de restricciones en accesos por URL: Falta de validación en
el procesamiento de URL que podrían ser usadas para invocar
recursos sin los derechos apropiados o páginas ocultas.
• Protección insuficiente de la capa de transporte: Relacionada con la
vulnerabilidad penúltima, pero orientada a la protección del tráfico
de red, indica una elección de un cifrado débil o mala gestión de
certificados.
• Datos de redirecciones y destinos no validados: Errores en el trata-
miento de redirecciones y uso de datos no confiables como destino.
1.4 Scrum
Según Infante (2010), es una metodología ágil, que puede ser usada
para manejar el desarrollo de productos complejos de software usando
prácticas iterativas e incrementales. Ha sido usado desde proyectos
simples hasta en cambios estructurales completos en las empresas
para sus negocios. Con él se incrementa significativamente la produc-
tividad y reduce el tiempo de espera, para ver los beneficios así como
facilitar la adaptación de los sistemas desarrollados. El mencionado
autor considera estas características:
• Procesos ágiles para el manejo y control del trabajo de desarrollo.
• Es un contenedor de prácticas de ingeniería existentes.
• Es un enfoque basado en equipos, incrementa el desarrollo cuando
los requerimientos cambian rápidamente.
• Es un proceso que controla el caos entre los conflictos de interés y
las necesidades.
• Es un camino para mejorar las comunicaciones y maximizar la
cooperación.
• Es la vía para detectar la causa y solucionar cualquier problema en
el desarrollo.
• Es escalable desde proyectos simples a proyectos completos
organizacionales.
Asimismo, expresa que esta metodología consiste en un conjunto
de prácticas interrelacionadas y reglas que optimizan el entorno de
desarrollo, reducen la sobrecarga organizativa y sincronizan los requi-
sitos del mercado con los prototipos de cada iteración. Se basa en el
trabajo en equipo, en reuniones diarias presididas por el máster para
establecer el estado del proyecto y en la salida cada 30 días de las
características del proyecto finalizadas y listas para trabajar. El corazón

15


de esta metodología es la iteración; en cada iteración se presenta una
mejora del funcionamiento del producto final y se evalúa la tecnología
y capacidades requeridas, además, diariamente se puede modificar el
enfoque si se encuentran nuevas dificultades.
1.5 Antecedentes
1.5.1 Aranda Asset Management. Herramienta de gestión y soporte
que permite tener información actualizada y detallada sobre el estado
de la infraestructura tecnológica de forma automatizada, cuyas carac-
terísticas, según Aranda (2010), son:
• Inventario actualizado y detallado de hardware, software, periféricos,
agendas de bolsillo (PDAs) y activos fijos minimizando costos de
inventarios manuales.
• Control de licenciamiento de software en cada equipo y del utilizado
por cada usuario.
• Control especial de eventos mediante la generación de alarmas que
indican cualquier cambio en el inventario.
• Control y administración remota a estaciones inventariadas y no
inventariadas en tiempo real para minimizar los tiempos de soporte.
• Ejecución en línea de tareas de administración remota a estaciones
inventariadas y no inventariadas.
• Módulo de reportes que permite unificar y presentar toda la infor-
mación recogida.
• PC Web, alternativa móvil para la visualización de la información
de una estación de trabajo en particular y Módulo PC Browser Web
edition, que permite su administración y control remoto.
• Sincronización bidireccional permanente con el Directorio Activo de
Windows.
1.5.2 Dexon Control de Plataforma IT. De acuerdo con Dexon (2010),
permite un sistema totalmente integrado para cubrir todas las necesi-
dades de administración y supervisión de una plataforma de la infraes-
tructura tecnológica. Diseñada para asegurar el control, seguimiento
y auditoria de todos los componentes tecnológicos que conforman la
plataforma IT de cualquier organización. Brindando prácticas de adminis-
tración basadas en la metodología ITIL (Biblioteca de Infraestructura de
Tecnologías de la Información). Ofreciendo servicios sobre Inventarios
automáticos, administración de activos fijos, control de licenciamiento
de software, auditoría y control remoto, recuperación y respaldo de ar-
chivos críticos. Además, por tratarse de un sistema flexible, totalmente
Integrado y que dinámicamente se ajusta a las necesidades del negocio,
permite la administración y supervisión de Servidores, Impresoras, Dis-

16


positivos de Red, Recursos de red, Servicios y SNMP. La suite Dexon
brinda soluciones específicas para:
• Administración de computadoras de escritorio,
• Supervisión de redes y servidores,
• Administración de dispositivos de red,
• Distribución e Instalación desatendida de software,
• Restauración y copias de seguridad e imágenes de disco de esta-
ciones de trabajo,
• Control remoto y virtualización del mantenimiento remoto,
• Administración de activos fijos.
Otros sistemas para la gestión de inventario de los recursos de los
equipos utilizados son Lever IT Discovery (LeverIT, 2010) y Excalibur
(CMN-Consulting, 2010).

2. Metodología
El trabajo estuvo basado en la metodología ágil de desarrollo Scrum
(Control Chaos, 2009), que no se basa en el seguimiento de unas fases
específicas, sino en la adaptación continua a las circunstancias de la
evolución del proyecto, permitiendo de este modo, un desarrollo de
carácter adaptable en lugar de predictivo y una estructura de desarro-
llo ágil e incremental basada en iteraciones y revisiones. Además, se
siguieron las recomendaciones de las guías de desarrollo y pruebas
propuestas por OWASP (2008, 2009, 2010b).
El producto finalizado fue usado como prototipo de pruebas en la red
de datos de la Universidad de Manizales, llevando a cabo un pilotaje
específico sobre un segmento de red compuesto por un número reducido
de equipos de cómputo bajo la plataforma Windows XP, en tres salas
de cómputo de la Facultad de Ciencias e Ingeniería.
El proyecto se realizó en tres fases, siendo la segunda, un ciclo iterativo
que se adaptó al modelo de desarrollo ágil, así:
2.1.1 Adecuación de entorno de trabajo. Comprendió la Instalación
del entorno de desarrollo, con tres actividades:
- Acondicionamiento de un equipo de cómputo (con las especificacio-
nes de software: Sistema operativo Microsoft Windows XP, Entorno
de desarrollo integrado Microsoft Visual Studio versión 2008 con
soporte para el lenguaje Visual C#, Entorno de desarrollo integrado
Netbeans versión 6 con soporte para el lenguaje Ruby, Distribución
binaria compilada del lenguaje de programación Ruby para la plata-

17


forma Windows, Framework Rails, Servidor de aplicaciones Mongrel,
Servidor de base de datos MySQL versión 5, Software para control de
versiones Subversion y Software para virtualización VMware Server).
- Instalación del entorno de pruebas, donde se consideraron un servi-
dor (especificaciones de software para el equipo servidor: Sistema
operativo Ubuntu Server Edition versión 10.04, Software para control
de versiones Subversion, Sistema web para la gestión de proyectos
y seguimiento de errores Trac, Distribución binaria compilada del
lenguaje de programación Ruby para la plataforma Linux, Framework
Rails, Servidor de aplicaciones Mongrel, Servidor de base de datos
MySQL versión 5 y .NET Framework versión 3), y varios clientes
virtualizados (con Sistemas operativos Windows XP, Windows Vista,
Windows Server 2003 y Windows Server 2008 en sus diferentes
versiones de Service Pack).
- Instalación del entorno de producción, en un servidor virtualizado
bajo el entorno de desarrollo (Sistema operativo Ubuntu Server
Edition versión 10.04, Distribución binaria compilada del lenguaje
de programación Ruby para la plataforma Linux, Framework Rails,
Servidor Web Apache + Módulo Passenger y Servidor de base de
datos MySQL versión 5).
2.1.2 Desarrollo Ágil. Patrón de ciclo de vida del modelo de desarrollo
ágil, el cual comprendió las siguientes actividades:
- Concepto, o creación de la visión del proyecto y conocimiento del
alcance del mismo.
- Especulación, que se repite en cada iteración del desarrollo y teniendo
como referencia la anterior actividad y consiste en Desarrollo / revisión
de los requisitos generales del proyecto (priorizados), Desarrollo de
una lista con las funcionalidades esperadas del proyecto, Construc-
ción de un plan de entrega: Fechas en las que se entregarán las
versiones, hitos e iteraciones del desarrollo.
- Exploración, que consiste en el desarrollo de las funcionalidades que,
para generar el siguiente incremento de producto, se han determinado
en la actividad anterior.
- Revisión de las funcionalidades construidas hasta el momento y
puesta en marcha en el entorno de producción para determinar su
alineación y dirección con los objetivos.
- Cierre, que implica la fecha de entrega de una versión del proyecto
con el producto esperado.
2.1.3 Transición. La puesta en marcha del prototipo de pruebas en la
red de datos de la Universidad de Manizales, considerando:

18


- Documentación de Usuario, que comprende la documentación téc-
nica requerida para el despliegue e instalación de componentes de
hardware y software en la red de datos,
- Puesta en marcha, con la instalación y ejecución del hardware y
software requerido y creado.

3. Resultados y discusión
3.1 Descripción de resultados
Se logró crear un agente para las plataformas Windows que obtiene
automáticamente el inventario de hardware y software en los equipos
clientes, adquiriendo los parámetros de supervisión a través de un ser-
vicio web y por medio del mismo reporta los cambios encontrados en
dicho inventario. En la figura 1 (parte superior) se muestran los datos
obtenidos para los dispositivos (Board, bios, arquitectura, RAM, etc.)
que están siendo monitoreados en un equipo de prueba.
Se creó una vista que permite la manipulación y visualización en el plano
arquitectónico de los equipos registrados, con su ubicación, estado de
alerta, funciones para mostrar y ocultar dispositivos, controles de zoom
y movimiento del plano, registro e información de equipos. En la figura
1 (parte inferior) se muestra el plano arquitectónico del segundo piso
de la Universidad de Manizales, con la ubicación de los dispositivos
registrados, su estado y los controles de manipulación.

Figura 1. Datos
y distribución
de los equipos
monitoreados

19


Figura 2. Alar-
mas por equipo
y listado general
de alarmas

Además, se creó un módulo de alarmas que reporta, de manera general
y por cada equipo, la información de las propiedades no equivalentes,
donde aparece el valor original y el valor repostado con su respectiva
fecha y hora de reporte, como se observa en la figura 2, donde hay
alarmas por los dispositivos mouse y Unidad de CD-DVD, así como el
listado general de alarmas. De igual manera, se logró la integración de
algunas herramientas adicionales que permiten extender las funciona-
lidades propias del sistema. En la figura 3 se muestra la utilidad ping
ejecutada sobre uno de los equipos registrados y con el respectivo
despliegue de resultados.

Figura 3.
Repuesta
enviada por la
herramienta ping
ejecutada sobre
un equipo

20


Otro aspecto conseguido es el servicio web que permite el intercambio
de datos entre el agente instalado en los equipos cliente y el servidor.
En la figura 4 se muestra una parte de la estructura XML entregada por
el servicio web al agente instalado en los equipos cliente y que contiene
la configuración de los parámetros de supervisión.
3.2 Discusión de resultados
El sistema de administración y supervisión del hardware y el software
de los equipos que conforman una red de datos, utiliza un sistema
agente instalado en los equipos cliente, un sistema web que permite la
visualización y manipulación de la información reportada y un servicio
web que permite la comunicación e intercambio de datos entre los
clientes y el servidor.
Las herramientas de desarrollo e implementación utilizadas para la
elaboración del sistema web y el servicio web son todas de libre uso
y se usan sobre el sistema operativo Linux; entre ellas Ruby on Rails,
Rest, XML, Apache, Passenger, y Netbeans.
El sistema agente que se ejecuta en los equipos cliente fue desarro-
llado con tecnologías .NET, que permite un mejor acoplamiento con la
plataforma Windows y su instrumental de administración. En la figura
5 se muestra
el software
agente ins-
talado como
un servicio
en el siste-
ma operativo
Windows.

Figura 4. Do-
cumento XML
obtenido por el
servicio web.

21


Figura 5.
Agente de
supervisión
como servicio
de Windows

Para el sistema de autenticación en web se usó el componente Restful
Authentication que permite el manejo de usuarios con autenticación
por contraseña, cookies del browser, o básica por medio del protocolo
HTTP, con características de validación, autorización y cifrado de datos.
El sistema se diferencia de otras herramientas similares existentes en
el mercado en:
- Funcionalidades de visualización y administración basadas en un
plano arquitectónico.
- Acceso administrativo vía web a diferencia de otras herramientas
que disponen únicamente de una aplicación de escritorio.
- El acceso al código fuente permite tareas de modificación de funcio-
nalidades, programación de nuevos módulos e integración de nuevas
herramientas.
- Se permite la personalización y configuración de los parámetros de
supervisión, a diferencia de la supervisión preestablecida que usan
las otras herramientas.

El proyecto se da a conocer en el IV Encuentro Regional Semilleros de
Investigación, celebrado en la ciudad de Cartago (Valle del Cáuca, Co-
lombia), en el año 2009, además de participar en la cuarta convocatoria
del programa nacional Destapa Futuro año 2009-2010, realizado por
la Fundación Bavaria, llegando a ser finalista, luego de concluir varias
etapas de selección entre más de 7000 proyectos de emprendimiento,
procedentes de las diferentes regiones del territorio colombiano.

22


4. Conclusiones
• El software agente instalado en los equipos clientes funciona
como un servicio del sistema operativo Windows, opera en forma
automatizada y transparente para al usuario, pues no requiere de
su intervención para la recopilación de información del sistema y
envío de reportes. El software agente solo requiere una interven-
ción previa por parte del usuario administrador, quien debe realizar
la instalación de las librerías necesarias para asegurar el correcto
funcionamiento del agente, y además, de forma manual, estable-
cerá las configuraciones necesarias en el sistema para evitar que
los usuarios sin privilegios de administración puedan manipular el
servicio.
• La integración del módulo de visualización de planos empresariales
y la ubicación visual de los equipos en dicho plano representa una
gran diferencia competitiva ante otros sistemas similares existentes
en el mercado, pues permite mayor agilidad y una mejor usabilidad
en las tareas de administración que ofrece el sistema de monitoreo,
evitando la clásica revisión de extensas listas y hojas de datos.
• La información correspondiente al inventario de hardware y software
de cada equipo cliente está disponible en el sistema y es obtenida
de forma automática a través del software agente, de esta forma
se garantiza la agilidad y exactitud de la información en el proceso
de recolección de datos.
• La información del inventario obtenida a través del software agente
no permite alteración por parte de los usuarios del sistema; de este
modo se garantiza la seguridad en el control y supervisión de datos
y alarmas generadas en el momento de realizarse un cambio en el
hardware o el software de un equipo cliente.
• El uso del framework Ruby on Rails permitió agilidad en el desarrollo
del software y facilitó un rápido acoplamiento ante los cambios y
novedades que surgieron en el transcurso del desarrollo del proyecto
sin mayores contratiempos.
• El desarrollo bajo el framework Ruby on Rails se incorpora perfec-
tamente a la metodología ágil Scrum en sus distintas fases y acti-
vidades, permite una fácil adaptación y reacción ante los cambios
y da continuidad al proyecto para desarrollar nuevas versiones.
• El uso de técnicas de seguridad en programación permitió que el
sistema en general sea más confiable y seguro, aplicando métodos
de protección ante las amenazas y vulnerabilidades especificadas
en el Top 10 de OWASP.

23


Bibliografía
AJPDSOFT (2010). Enciclopedia Definición WMI [en línea]. Murcia (España): Proyecto Ajpdsoft. <http://
www.ajpdsoft.com/modules.php?name=Encyclopedia&op=content&tid=827> [consulta: 01/11/2010]
ARANDA SOFTWARE CORPORATION (2010). Asset Management [on line]. Miami (USA): Aranda.
<http://www.arandasoft.com/solucion_aam.php> [consult: 01/11/2010]
AUTOMATAS.ORG (2006). Sistemas Scada [en línea]. Valladolid (España): Autómatas
Industriales<http://www.automatas.org/redes/scadas.htm> [consulta: 01/11/2010]
CMN CONSULTING (2010). Excalibur [en línea]. Bogotá (Colombia): CMN Consulting. <http://
www.cmn-consulting.com/soluciones/soluciones_index.htm> [consulta: 01/11/2010]
CONTROL CHAOS (2009). Scrum [en línea]. s.l: Advanced Development Methods. <http://www.
controlchaos.com> [consulta: 01/12/2009]
DAVE, Thomas (2005). Programming Ruby: The Pragmatic Programmers Guide. 2 ed. Lewisville
(Texas, USA): The Pragmatic Programmers. 833 p. ISBN: 0-9745140-5-5
DAVE, Thomas and HEINEMEIER HANSSON, David (2006). Agile Web Development with Rails.
2 ed. Lewisville (Texas, USA): The Pragmatic Programmers. 715 p. ISBN: 978-0-9776-1663-3
DEXON SOFTWARE(2010).DexonImaxt It Management Suite [en línea]. Bogotá (Colombia):
Dexon Software Inc. <http://dexon.us/soluciones/dexon_it_asset.html> [consulta: 01/11/2010].
INFANTE, Luis (2010).Metodología ágil SCRUM [en línea]. Monterrey (México): Business Intelligence
Latin America <http://www.bi-la.com/profiles/blog/list?user=1v7ecmaqe9u7d> [consulta: 01/11/2010].
JANOFF, Norman (2000). The Scrum Software Development Process for Small Teams [on line].
Phoenix (USA): IEEE Software. <http://members.cox.net/risingl1/Articles/IEEEScrum.pdf>
[consult: 28/11/2008]
KNIBERG, Henrik (2007). Scrum and XP from the Trenches [on line]. Ontario (Canada): Java
Zealot Solutions. <http://www.infoq.com/minibooks/scrum-xp-from-the-trenches> [consult:
01/11/2010].
LEVER IT (2010). Discovery Advantage [on line]. Bogotá (Colombia): LeverIT Asset Management
IT. <http://www.leverit.com> [consult: 01/11/2010].
MARSHALL, Kevin (2006). Web Services on Rails. Sebastopol (California, USA): O’Reilly. 32 p.
ISBN: 0-596-52796-9
MARSHALL, Kevin. (2007). PRO Active Record: Databases with Ruby on Rails. New York (USA):
Apress. 280 p. ISBN: 1-59059-847-4
NAVARRO, Rafael (2007). REST vs Web Services [en línea]. Valencia (España): Universidad Po-
litécnica de España. <http://users.dsic.upv.es/~rnavarro/NewWeb/docs/RestVsWebServices.
pdf> [Consulta: 01/11/2010].
OWASP FOUNDATION (2008). OWASP Testing Guide v3.0 [on line]. Columbia (USA): OWASP.
<http://www.lulu.com/items/volume_66/5691000/5691953/9/print/5691953.pdf> [consult:
01/11/2010]
OWASP FOUNDATION (2009). OWASP Ruby on Rails Security Guide [on line]. Columbia (USA):
OWASP. <http://www.lulu.com/items/volume_64/5811000/5811294/3/print/5811294.pdf>
[consult: 01/11/2010]
OWASP FOUNDATION (2010a). OWASP Top 10 [on line]. Columbia (USA): OWASP. <http://
www.lulu.com/items/volume_68/1400000/1400974/5/print/1400974.pdf> [consult: 01/11/2010].
OWASP FOUNDATION (2010b). OWASP Guide 2.1: A Guide to Building Secure Web Applications
and Web Services [on line]. Columbia (USA): OWASP/VRG Editions. <http://www.fecj.org/
extra/Owasp2.1.0.pdf> [consult: 01/11/2010]
OWASP FOUNDATION (2011). OWASP - The Open Web application Security Project [on line].
Columbia (USA): OWASP/VRG Editions. <https://www.owasp.org/index.php/Main_Page>
[Consult: 18/11/2011]
PALACIO, Juan (2007) Flexibilidad con Scrum [en línea]. Zaragoza (España): Navegapolis. <http://
www.navegapolis.net/files/navegapolis_2009.pdf> [consulta: 28/11/2008]
SCHWABER, Ken (2004). Agile Project Management with Scrum. Redmond (USA): Microsoft
Press. 156 p. ISBN: 0-7356-1993-X
SCHWABER, Ken (2007). The Enterprise and Scrum. Redmond (USA): Microsoft Press. 176 p.
ISBN: 0735623376

24


Simulación de técnicas de
encolado con prioridad*1
[Simulation of techniques for priority queues]
Néstor Jaime CASTAÑO-PÉREZ2, Germán William LONDOÑO-JIMÉNEZ3


Resumen
Motivados por la necesidad de generar ambientes de desarrollo
donde se prueben y analicen los comportamientos de equipos y
algoritmos de conmutación de paquetes en un router, se presenta
una arquitectura para la gestión de paquetes con priorización de
tráfico, que consta de generador de trafico de voz y de video, ges-
tor de colas y receptor del tráfico procesado. Como método para la
gestión de tráfico se usa la generación de variables aleatorias de
tiempo de llegada y tamaño de paquetes de voz y video, utilizando
métodos de simulación de eventos discretos. Se plantea un política
de encolado basada en etiquetado de paquetes y descarte por
saturación de un sistema de espera M/M/1/K. Los programas se
realizaron en Java y se utilizó Matlab para el análisis y graficación
de los resultados. Como resultado principal, se demostró que los
tiempos de espera promedio del los paquetes etiquetados para
ser procesados con prioridad alta en la cola no sufrieron cambios
significativos, cuando se aumentó el tráfico de baja prioridad.
Palabras Claves: Programación de Hilos, Simulación, Encolado,
Priorización de Tráfico.

* Modelo para citación de este reporte de caso:
CASTAÑO PÉREZ, Néstor Jaime y LONDOÑO JIMÉNEZ, Germán William (2011). Simulación
de técnicas de encolado con prioridad. En: Ventana Informática. No. 25 (jul. – dic., 2011).
Manizales (Colombia): Facultad de Ciencias e Ingeniería, Universidad de Manizales. p. 25-39.
ISSN: 0123-9678.
1 Artículo proveniente de reflexiones académicas realizadas en el periodo 2009-2010, en el
desarrollo del proyecto de aula para la integración de los Sistemas y Telecomunicaciones en
la Universidad de Manizales.
2 Ingeniero Electrónico, Especialista en Telecomunicaciones, Magister en Automatización
Industrial. Docente, Universidad de Manizales, Manizales (Colombia). Correo electrónico:
ncastano@umanizales.edu.co.
3 Ingeniero Electricista, Especialista en Sistemas de Transmisión y Distribución, Especialista
en Informática y Computación. Docente, Universidad de Manizales, Manizales (Colombia).
Correo electrónico: glondono@umanizales.edu.co.



Abstract
Due to the need to create environments where behavioral deve-
lopment, equipment and packet switching algorithms in a router,
are tested and analyzed, the paper presents an architecture for
managing packet traffic prioritization, which is composed of a traffic
generator for voice and video, a queue manager and a receiver
processing traffic. For this architecture, the random variables were
generated arrival time and size of packet voice and video, using
methods of discreet event simulation. In addition, programs were
conducted in Java and Matlab was used for analysis and graphing
of results. Besides, considering a policy-based sizing and discard
packet tagging saturation of a queuing system M/M/1/K. The pa-
per shows that the average waiting times labeled packets to be
processed with high priority, to increase the low-priority traffic, did
not suffer significant changes.
Keywords: Threads programming, Simulation, Queuing, Priori-
zation of traffic.

Introducción
Las colas son elementos fundamentales en los sistemas de telecomu-
nicaciones modernos y nacen de la necesidad de volver las redes más
eficientes por medio de la multiplexación estadística de datos, concepto
planteado por Gross, et al (2008, 5). Las colas se dan en los momentos
en los que el flujo de entrada a un dispositivo de comunicaciones es
mayor que el flujo de salida, por lo tanto existe una acumulación de datos
o paquetes en la entrada del elemento de red. Si el flujo de entrada es
superior o igual al flujo de salida, la acumulación de datos sería infinita
y se rompería el equilibrio estadístico requerido en los modelos de Le
Boudec y Thiran (2001, 53). Por este motivo los diseños de redes de
telecomunicaciones están concebidos para que en la mayor parte del
tiempo, el flujo de salida sea mayor al flujo de entrada. Aún, con estas
consideraciones, existen instantes de tiempo en los cuales, por la mis-
ma naturaleza de la multiplexación estadística la red tiene un mayor
volumen de paquetes a su entrada de los que puede procesar y es justo
en estos momentos en los que se deben aplicar diferentes algoritmos
para administrar el envío de los paquetes que se encuentran en la cola,
temáticas tratadas por Olifer (2009, 201).
Uno de los primeros algoritmos para la administración de las colas es
conocido como PEPS (Primero en Entrar - Primero en Salir), Tanem-
baum (2003, 34), en el cual los paquetes son atendidos en la cola en

26


el mismo orden en el cual fueron llegando a ésta. Para el transporte
de datos planos este simple algoritmo puede desempeñarse adecua-
damente y brindar una buena experiencia para el usuario. El problema
con este tipo de colas, es que no es posible de forma alguna diferenciar
un tráfico de otro, y con la necesidad de ofrecer servicios integrados
sobre redes de datos, se hace necesario dar prioridad al trato de deter-
minado flujo de datos que requiere en determinados casos minimizar
variables como el tiempo de transmisión. Para solucionar este tipo de
problemas se implementaron las colas con prioridad, expuestas por
García y Widjaja (2003, 340).
Las colas con prioridad son en realidad una colección de colas PEPS,
en las que a cada una se les asigna una prioridad específica y por
medio del algoritmo de servicio, se atienden las colas PEPS por orden
de prioridad de mayor a menor.
Para utilizar las colas de prioridad es necesario distinguir los paquetes
cuando llegan al dispositivo para poder saber a qué cola se deben
asignar. Es por este motivo que en la mayoría de los casos los paque-
tes son marcados antes de ser enviados al dispositivo de encolado, el
cual utilizando una marcación predeterminada está en la capacidad de
distinguir el tráfico y por ende tratarlo de una forma adecuada, según
señala Donahue (2008, 24).
También se pueden dar casos en los cuales no es necesario marcar los
paquetes sino que se utilizan los campos ya definidos en el encabezado
de los paquetes para su diferenciación, como es el caso de la dirección
de origen o dirección destino de los paquetes, o protocolo de transporte,
o en programación de routers proyecto propuesto por la Universidad de
Stamford, documentado por Reforgiato (2011, 22).
Ahora, en cuanto al funcionamiento de las colas de prioridad se pueden
identificar dos tipos se sistemas: preemptive y non-preemptive. En un
sistema non-preemptive una vez se da inicio a la atención de una unidad
de datos el sistema no se puede detener hasta que termine su servicio,
mientras que en un sistema preemptive es posible detener una unidad
que está siendo atendida para la transmisión de otra unidad de mayor
prioridad, considera Daigle (2010,248).
En este documento se simulará una cola de prioridad con dos niveles
distintos de servicio en los cuales se utilizarán sistemas non-preemptive,
es decir que una vez se inicie la transmisión de un paquete, esta se
debe finalizar.
Idealmente, un sistema estricto de colas debería estar en la capacidad
de parar la transmisión de un paquete ante la llegada de flujo de una
mayor prioridad, pero al estar tratando con sistemas discretos no es

27


posible detener la transmisión de un paquete una vez esta se inicia.
Además de ser algo que no es posible de implementar, se podría pensar
en cancelar la transmisión del paquete como un error, pero esto obligaría
a la retransmisión del paquete lo que a la final haría que aumentara
el retraso en la red, por la constante retransmisión de paquetes que
tuvieron que ser interrumpidos a causa de flujos de mayor prioridad.

1. Marco teórico
1.1 Caracterización de las variables aleatorias
Antes de emprender cualquier proceso de simulación de eventos
discretos se hace necesario caracterizar las variables aleatorias que
intervienen en el sistema. Esta caracterización se realiza mediante los
histogramas de cada variable. En la literatura se encuentran diferentes
métodos para la generación de estas variables aleatorias, expuestos
con claridad por Kay (2005,18). En este caso se encontró que el tiempo
entre llegadas del tráfico de VoIP es exponencial (Figura 1) y el número
de paquetes que llega por segundo es de tipo Poisson (Figura 2). La ca-
racterización de trá-
fico permite generar
vectores de tráfico en
Matlab de acuerdo
con las necesidades
experimentales.

Figura 1. Histograma
Tiempo entre llegada

Figura 2. Número de
Paquetes que llegan por
segundo

28


1.2 Tráfico tipo Poisson
En los sistemas de teletráfico, las llegadas de paquetes pueden ser
modeladas como sistemas tipo Poisson, si se considera que son pro-
ducto de una población amplia de usuarios independientes, como lo
afirma Coosbu (2002, 43).
Si se desea calcular el retraso y el throughput del buffer de un enlace
de red que opera con una capacidad de N Mbps. Ésta situación se
ilustra en la figura 3, donde los paquetes se representan como cajas
rectangulares.
Un modelo muy popular para representar el número de paquetes que
llegan en un intervalo de tiempo es el proceso de Poisson. En un proceso
de Poisson con tasa λ el número de llegadas de eventos en un intervalo
de tiempo [t, t+τ], denotado por N[t+τ] - N[t] está dado por:

(1)

Figura 3. Llegada y Salida de paquetes en una cola

Un proceso de Poisson tiene algunas propiedades interesantes Youn-
gjae (2008, 1) y útiles como:
El tiempo de llegada entre dos eventos (en este caso, paquetes) sigue
una distribución tipo exponencial:
(2)

Si se suman las llegadas de dos procesos tipo Poisson con tasa λ y μ,
es equivalente a tener un solo proceso tipo Poisson con tasa de λ + μ.
1.3 Tráfico de video
El video digital consiste de una secuencia de tramas de video que
son mostradas a una tasa de típicamente 30 cuadros por segundo.
Asumiendo que un cuadro tiene un tamaño de 720 x 480 pixeles (un
formato estándar utilizado para video digital) y una profundidad de 24
bits por pixel, esto resulta en una tasa de datos de 240 Mbps por línea
de video. Utilizando métodos de compresión modernos, como MPEG y

29


H.264, la tasa de datos puede ser drásticamente reducida a unos pocos
Mbps, como asegura Richardson (2010, 9).
Un codificador MPEG (y casi la gran mayoría de algoritmos de com-
presión) generan, según Harte (2006, 19), tres tipos de tramas: Intra-
Codificadas (I), Inter-Codificadas o Predictivas (P) y Bi-direccionales
(B). Las tramas I son codificadas como imágenes congeladas como
JPEG; las tramas P codifican las diferencias entre la trama P o I más
reciente; y las tramas B son interpolaciones de las tramas anteriores
y posteriores P o I. Un codificador MPEG genera estas tramas en un
patrón repetitivo, llamado Grupo de Imagen (Group Of Picture -GOP-).
Con 30 cuadros por segundo, el tiempo que pasa entre dos tramas es
aproximadamente 33 ms. Un patrón de GOP típico es IBBPBBPBB,
donde las dependencias entre las tramas están indicadas por flechas,
como se muestra en la figura 4.

Figura 4. GOP de una trama de video (Sniderman, 2011)

Los diferentes tipos de trama tienen tamaños distintos, siendo las tramas
I las más grandes y las B las más pequeñas. Se debe tener en cuenta
que las tramas B son construidas a partir de dos tramas de referencia
tipo I o P. Por lo tanto, para codificar o decodificar una trama tipo B es
necesario que el transmisor o el receptor tengan disponible las tramas
P o I correspondientes. Para cumplir con esta característica, las tramas
son transmitidas en una secuencia diferente a la cual son presentadas.
En la figura 4, la secuencia de transmisión y de presentación es como
se describe en la tabla 1.

Tabla 1. Orden de secuencia de presentación y transmisión de una trama de video

Secuencia de Presentación 1 2 3 4 5 6 7 8 9 10
Secuencia de Transmisión 1 4 2 3 7 5 6 10 8 9

Debido a las diferencias en tamaño de las tramas I, P y B, la tasa de
datos de un video MPEG cambia de trama a trama. Por esta razón, el

30


video comprimido como MPEG, es referido como video de tasa variable
(Variable BitRate-VBR-) o video VBR.
1.4 Consideraciones de tráfico
Es necesario tener en cuenta que el tráfico tipo Poisson es posible
modelarlo a partir de una distribución específica, desde la cual es
posible desprender características y variables que permiten inferir el
comportamiento del tráfico en un futuro, y por ende planear de acuerdo
a estas perspectivas.
El video, al ser un tráfico tipo VBR, no obedece una distribución específi-
ca y para su análisis es necesario adoptar otro tipo de estrategias como
es el caso de las metodologías presentadas por Dunrkin (2003, 22).
Aunque en este documento no se profundiza en temas como curvas de
llegada o curvas de servicio, es importante hacer la aclaración de que
los dos tipos de tráficos con los que se trata se comportan de forma
distinta e independiente aunque ambos son aleatorios.

2. Implementación
En el presente artículo se presenta, a partir de Foster (2004, 23), la
implementación de una cola de prioridades utilizando el lenguaje de
programación JAVA y sus librerías para Sockets para la implementación
de la cola, el envío de paquetes y la recepción de los mismos y Matlab
para realizar el análisis de los resultados obtenidos por medio de la
cola. Como parte del análisis, se incluirá el tiempo medio de espera de
un paquete y el tamaño promedio de cada una de las colas.
Como se mencionó anteriormente, para implementar la cola de prioridad
es necesario marcar los paquetes que se están enviando a la cola para
que una vez lleguen a este dispositivo sea posible su ubicación en el
buffer respectivo dependiendo de su prioridad. En el presente caso, se
pretende diferenciar tráfico de video, de tráfico tipo Poisson. Por eso se
utilizan dos fuentes de datos, cada una de las cuales marca los datos
que envía colocando el byte 0 (cero) del paquete enviado en 1 en el
caso del generador de datos Poisson y en 2 en el caso del generador
de tráfico de video.
La implementación propuesta es la de una cola de prioridades, que
permita la diferenciación en cuanto al tratamiento en cola del tráfico
de video y tráfico tipo Poisson, como se muestra en la Figura 5. La
solución propuesta son dos programas que generan el tráfico: - El pro-
grama representado por el rectángulo Tráfico de voz que se encarga
de generar el tráfico tipo Poisson a partir de un archivo de texto que

31


contiene la información del tráfico, además marca los paquetes antes de
ser enviados a la cola, y - el programa representado por el rectángulo
Tráfico de video que genera tráfico de video igualmente a partir de un
archivo de texto que contiene la información del tráfico.

Figura 5. Diseño general de la cola de prioridad

El tercer programa implementado es la cola, la cual está compuesta por
dos hilos, para que la cola pueda recibir paquetes y enviarlos de forma
paralela. El primero se encarga de recibir los paquetes y clasificarlos, ubi-
cándolos en el buffer correspondiente por medio de la marcación realizada
en el proceso de envío, mientras el segundo se encarga de implementar
la cola de prioridad, tomando los elementos del buffer de mayor prioridad
en primera instancia, y los del buffer de menor prioridad en segunda
medida siempre y cuando el buffer de alta prioridad se encuentre vacío.
Luego de tomar un elemento de alguno de los buffers, este es enviado.
El diseño del hilo que se encarga de recibir los paquetes en la cola de
prioridad se muestra en la Figura 6.

Figura 6. Diseño General del hilo para recibir los paquetes.

32


En este caso, los paquetes se reciben y se consulta el valor del primer
byte del paquete. Si éste es 1, se mira el tamaño del buffer de la cola
de baja prioridad, y si la cola tiene un tamaño superior a 100 Kbytes,
entonces el paquete se descarta, de lo contrario se agrega a la cola de
baja prioridad. Si el primer byte del paquete es 2, se toma el tamaño de
la cola de alta prioridad y si éste excede igualmente los 100Kbytes se
descarta el paquete, si no, se ubica en la cola de alta prioridad.
Ahora, el funcionamiento de la cola de prioridad se muestra en la Figura
7. El hilo para enviar está en un ciclo, el cual siempre verifica el estado de
la cola de prioridad alta. Si este buffer tiene algún elemento, se remueve
el primer ítem del arreglo y se envía. Solo en el caso en que el buffer de
la cola de prioridad alta esté vacío se monitorea el buffer de la cola de
baja prioridad y si tiene elementos, se remueve el primer ítem del arreglo
y es enviado. Una vez un paquete sea enviado, el hilo vuelve a su estado
inicial, que es monitorear el buffer de la cola de prioridad alta.

Figura 7. Diseño General del hilo para implementar la cola de prioridad.

La cola de prioridad no atenderá la cola de prioridad baja a no ser que
la cola de prioridad alta este vacía. Aunque este es el comportamiento
programado, en ocasiones puede no ser el deseado, ya que si el tráfico
de la cola de alta prioridad es alto se pueden dar casos en los que el
retraso de la cola de baja prioridad es grande, lo que se convierte en
una denegación de servicio para el tráfico de baja prioridad, como lo
plantean García y Widjaja (2003, 221).
Es por este motivo que las colas de prioridad, se utilizan para procesar
tráfico que requiere transmisión en tiempo real, como es el caso de

33


voz en las redes de datos. Este tipo de colas son implementadas en
equipos de comunicaciones como enrutadores CISCO que proporcio-
nan opciones para la calidad de servicio bajo el nombre de LLQ (Low
Latency Queueing).
En el caso en el que se desee diferenciar tráfico sin necesidad de recurrir
a las colas de prioridad, se tienen otro tipo de algoritmos como el WFQ,
GPS o EDF los cuales no serán considerados en el presente documento,
pero se mencionan como referencia para el lector. Con el objetivo de ob-
servar el comportamiento de la cola en cuanto la diferenciación en el trato
del tráfico se decide crear una variable en el generador de tráfico Poisson
que permita la variación de la intensidad o tasa promedio de transmisión
de tráfico entre 0 y 10Mbps. Esta variable se le asigna el nombre de N,
y varía entre 0 y 10; por lo tanto, para un valor de N=5 se tiene un tráfico
tipo Poisson con una tasa de transmisión promedio de 5 Mbps.
Lo que se quiere observar es cómo se comporta la cola de prioridad
para diferentes valores de N y cómo afecta el aumento en el tráfico de
baja prioridad el comportamiento del buffer de alta prioridad. También
se puede observar que sucede con el buffer de baja prioridad a medida
que se aumenta el tráfico tipo Poisson.
El programa diseñado para la simulación de la cola, fue pensado para
emular el comportamiento de tráfico a diferentes niveles de carga, mo-
tivo por el cual el programa encargado de generar el tráfico de video
posee una variable N que se introduce en el momento de ejecución,
la cual permite generar datos con velocidad promedio desde 0 hasta
10 Mbps. Es necesario aclarar que la tasa de transmisión de datos
correspondientes al tráfico de video es la misma, sin importar el valor
de N que se esté utilizando para el transmisor de datos tipo Poisson.

3. Resultados
3.1 Tiempo de espera
Es interesante conocer el tiempo de espera de los paquetes en la cola
debido a que éste es un factor que está estrechamente relacionado
con el retraso en el que los paquetes incurren al atravesar la red. Éste
retraso de los paquetes afecta de una forma directa la interactividad de
la experiencia de tiempo real (audio o video) por lo cual se debe tratar
de minimizar su impacto sobre el tráfico de datos.
Para medir el tiempo de espera de los paquetes en la cola de prioridad
se implementó un arreglo de tipo flotante, el cual guarda el tiempo en el
cual un paquete ha llegado al buffer (de alta o de baja prioridad según
sea el caso). Una vez se vaya a enviar un paquete específico se toma

34


el tiempo en el que ocurre la transmisión y el tiempo asociado a ese
paquete contenido en el arreglo de valores flotantes. La diferencia entre
los dos tiempos da como resultado el tiempo durante el cual el paquete
estuvo esperando a ser servido. Una vez el paquete es enviado, el
tiempo asociado a éste es borrado del arreglo de tiempos.
Adicionalmente, en cuanto al tiempo de espera se presentan dos mé-
tricas: Tiempo de Espera Máximo y Tiempo de Espera Promedio como
se puede apreciar en la Figura 8, donde se muestran como puntos en el
plano los valores arrojados por la simulación de la cola, acompañados
de una línea de proyección producto de una interpolación cúbica de los
valores de Tiempo de Espera Máximo y Tiempo de espera promedio
obtenidos para N=1, N=5 y N=9 realizada en Matlab.
Respecto al desempeño del Tiempo de Espera Promedio de los paque-
tes en el buffer de alta prioridad se observa que es prácticamente estable
y cercano a los 0.8 ms. Este tipo de comportamiento era el esperado,
pues sin importar la intensidad del tráfico tipo Poisson, los paquetes
presentes en el buffer de alta prioridad van a ser atendidos, y para el
caso de la simulación no se modificó la cantidad de tráfico de video
que llega a la cola. El tiempo de diferencia entre el tiempo promedio de
espera de los paquetes de la cola de alta prioridad presenta variabilidad
por factores como la no dedicación de un procesador a la ejecución de
ésta tarea. Las funciones de la CPU se redujeron al mínimo para evitar
la interferencia con el procesamiento de la información concerniente a
la Cola de Prioridades, pero de todas formas es imposible garantizar la
dedicación total del procesador a realizar estos cálculos.

Figura 8. Resultados de la simulación de la cola de prioridad

35


Debido a que el canal por el cual se transmite la información no ha
aumentado su tamaño, y considerando que se ha incrementado la tasa
de transmisión de datos de baja prioridad, es de esperarse que para
garantizar la transmisión de la información de alta prioridad, deban
existir peritadas o descartes de paquetes pertenecientes al grupo de
prioridad menor, tal como se puede apreciar en la Figura 9. También
es interesante notar que como se ha demostrado en la teoría de redes,
el comportamiento de un sistema de comunicaciones cuando alcanza
su punto de saturación deja de ser lineal. Es decir que para el caso
anterior, el punto de quiebre de la linealidad a la no-linealidad se da
aproximadamente para valores de N=5.

Figura 9. Paquetes Descartados en Cola de Baja Prioridad.

Luego de haber observado el comportamiento de la cola de alta prioridad
y de la cola de baja prioridad, también pueden verse los resultados de
la simulación, los cuales se muestran en la Tablas 2 y 3.

Tabla 2. Resultados para cola de baja prioridad
Parámetros N=1 N=5 N=9
Tiempo Máximo de Espera 31302.76 ms 36553.04 ms 25672.84 ms
Tiempo Promedio de Espera 22343.7 ms 19910.28 ms 17460.3 ms
Tamaño Máximo de la Cola 99993 Bytes 100000 Bytes 99990 Bytes
Tamaño Promedio de la Cola 85766 Bytes 88201 Bytes 89570 Bytes
Numero de Paquetes Descartados 4170 7651 7965
Porcentaje de Paquetes descarados 41.7% 76.51% 79.65%

36


Tabla 3. Resultados para cola de alta prioridad
Parámetros N=1 N=5 N=9
Tiempo Máximo de Espera 662.15 ms 828.2 ms 652.75 ms
Tiempo Promedio de Espera 100.15 ms 131.13 ms 154.99 ms
Tamaño Máximo de la Cola 14875 Bytes 16651 Bytes 14432 Bytes
Tamaño Promedio de la Cola 3118 Bytes 3328 Bytes 3056 Bytes
Numero de Paquetes Descartados 0 0 0
Porcentaje de Paquetes descarados 0% 0% 0%

En el caso de la cola de baja prioridad, se observa como el tamaño
promedio de la cola se incrementa a medida que aumenta la carga o
tasa de transmisión de la información, así mismo como el número de
paquetes que son descartados por el sistema. Para esto se recuerda
que los programas realizados en JAVA fueron configurados de forma
tal que las colas no aceptan paquetes si éstas ya tienen su buffer
100.000Bytes.
Ahora, teniendo en cuenta los datos arrojados por el simulador para
el flujo de datos de alta prioridad es posible apreciar que no existen
paquetes descartados, debido a que todo paquete que entra en la cola
siempre es servido y además se muestra que en promedio la tasa de
llegada de los paquetes a su cola es inferior a la tasa de salida de es-
tos. Por otro lado, también es posible apreciar como el tamaño, tanto
promedio como máximo de la cola de alta prioridad posee valores muy
interiores a los arrojados por el simulador para el caso de la cola de
baja prioridad.

4. Conclusiones
• Luego de realizar las simulaciones en JAVA y analizar los resultados
en Matlab fue posible demostrar de una forma clara que las colas de
prioridad son altamente confiables cuando se trata de aislar un tipo
de tráfico de otro. Esto se demuestra en el caso en el que el tráfico
de alta prioridad se comportó de una forma estable ante la presencia
de diferentes cargas de tráfico de baja prioridad. Simulaciones con
generación de tráfico como las mostradas, se constituyen en una
herramienta fundamental para futuros experimentos en netFPGA,
en donde se necesite probar algoritmos de gestión o tiempos de
retardo en LAN o WAN.
• Por ser colas que permiten un gran aislamiento del tráfico son al-
tamente importantes para el transporte de información en tiempo
real, tales como audio y video en vivo.

37


• En cuanto a los resultados arrojados por el simulador, para su
análisis también es necesario considerar que se trata de tráfico
VBR – Variable BitRate – lo cual, al interactuar con la diferencia
de tasas de transmisión y por ende diferente funcionamiento de la
cola de baja prioridad presenta resultados con leves diferencias
en números pero que son concordantes con el comportamiento
general esperado de la cola de alta prioridad.
• La variabilidad de los datos arrojados por la simulación es debida
a la no dedicación exclusiva del procesador a realizar las tareas
asignadas por la Cola de prioridad, y un próximo paso hacia la
comprobación de resultados, sería la implementación del algoritmo
en un dispositivo de dedicación exclusiva como un FPGA.
• Es necesario tener en cuenta que la sincronización en las colas
juega un papel preponderante, debido a que se pueden dar ca-
sos en los que un elemento esté ingresando a la cola mientras
otro esté siendo retirado. Si no se pone cuidado a este tipo de
eventos se incurre en errores de cálculo y pérdidas de paquetes.
Para evitar esto, se utilizó la clase “Vector” en java, la cual por
herencia ya se encuentra sincronizada.

Bibliografía
COOSBU, Raúl (2002) Simulación: Un enfoque práctico. México: Limusa, 157 p. ISBN:
9681815068.
DAIGLE, John N. (2010). Queueing Theory with Applications to Packet Telecommunication. 2 ed.
Mississippi (USA): Springer, 315 p. ISBN: 0-387-22857-8
DONAHUE, Gary A. (2008) Network Warrior: Everything you need to know that wasn’t on the CCNA
exam. Sebastopol (USA): O’Reilly, 545 p. ISBN: 978-0-596-10151-0.
DUNRKIN, James F. (2003) Voice-enabling The Data Network: H.323, MGCP, SIP, QOS, SLAS,
AND SECURITY. Indianapolis (USA): Cisco Press. 227 p. ISBN: 1-58705-014-5.
FOSTER, James C. (2004) Sockets, Shellcode, Porting & Coding: Reverse Engineering Exploits
and Tool Coding for Security Profesionals. Rockland (USA): Syngress Publishing Inc, 653 p.
ISBN: 1-597490-05-9.
GARCÍA, Alberto and WIDJAJA, Indra. (2003) Communication Networks: Fundamental Concepts
and Key Architectures. 2 ed. New York (USA): McGraw-Hill, 871 p. ISBN: 0-07-246352-X.
GROSS, Donal; SHORTLE, John; THOMPSON, Jim and HARRIS, Carl (2008). Fundamentals
of Queueing Theory. New York (USA): John Wiley & Sons, 600 p. ISBN: 978-0470547830.
KAY, Steven (2005) Intuitive Probability and Random Processes using MATLAB. Kingston (USA):
Springer, 851 p. ISBN: 978-0387241579
LAWRENCE, Harte (2006). Introduction to MPEG; MPEG-1, MPEG-2 and MPEG-4. Fuquay Varina
(NC, USA): Althos, 92 p. ISBN: 978-1932813531
LE BOUDEC, Jean-Yves and THIRAN, Patrick (2001) Network Calculus: A Theory of Deterministic
Queuing Systems for the Internet. New York (USA): Springer Verlag. 274 p. ISBN: 354042184X.
NEMBAUM, Andrew (2003) Redes de Computadoras. 5 ed. México (México). Prentice- Hall, 34
p. ISBN: 970-26-0162-2
OLIFER, Natalia (2009). Redes de Computadoras. México (México): McGraw-Hill, 751 p. ISBN:
9789701072493

38


REFORGIATO, Diego (2011). A Traffic Monitor on NetFPGA platform: Comparisons against a
Software Implementation on the Click Modular Router. Rome (Italy): Lambert, 84 p. ISBN:
978-384338140
RICHARDSON, Iain (2010). The H.264 Advanced Video Compression Standard. London (United
Kingdom): Wiley, 256 p. ISBN: 978-0-470-51692-8
SNIDERMAN, Andrew (2011). VGA Conferencing in Lync Server 2010 [on line]. Redmond (WA,
USA): Markmonitor. <http://blogs.technet.com/b/nexthop/archive/2011/06/22/vga-conferencing-
in-lync-server-2010.aspx> [consult: 30/06/2011].
TANEMBAUM, Andrew (2003). Redes de Computadoras. 5 ed. México (México): Prentice- Hall,
912 p. ISBN: 970-26-0162-2
TSUHAN, Chen (2005). Multimedia Systems Standards and Networks. Pittsburgh (USA): Marcel
Dekker, 631 p. ISBN: 0-8247-9303-X
YOUNGJAE, Lee (2008). Characterization of Large-Scale SMTP Traffic: the Coexistence of the
Poisson Process and Self-Similarity. In: IEEE International Symposium on Modeling, Analysis
and Simulation of Computers and Telecommunication Systems. MASCOTS. p. 1-10. ISSN:
1526-7539.

39


40


Certificación de la calidad
del proceso y producto: ruta
para pymes colombianas
que fabrican software*1
[Certification process and product
quality: route colombian SME
manufacturing software]
Luis Eduardo PELÁEZ-VALENCIA2, Ricardo Alonso HURTADO-MOSQUERA3
Jorge Alberto FRANCO-ESCOBAR4


Resumen
En el contexto del desarrollo del software, se hace relevante
implementar modelos de reconocimiento internacional que bus-
quen lograr la calidad que tienen los procesos y productos de las
grandes industrias. Así, si las MiPymes productoras de software
de Colombia se quieren comparar con el mercado mundial de su
sector, deben comprender la importancia de las certificaciones de
calidad que estas últimas ya han logrado. Sin embargo, lograr de-
terminado nivel de certificación, exige seguir modelos reconocidos

* Modelo para citación de este artículo científico:
PELÁEZ VALENCIA, Luis Eduardo; HURTADO MOSQUERA, Ricardo Alonso y FRANCO
ESCOBAR, Jorge Alberto (2011). Certificación de la calidad del proceso y producto: Ruta
para pymes colombianas que fabrican software. En: Ventana Informática. No. 25 (jul. – dic.,
2011). Manizales (Colombia): Facultad de Ciencias e Ingeniería, Universidad de Manizales.
p. 41-61. ISSN: 0123-9678
1 Artículo proveniente de la investigación titulada Propuesta de aseguramiento de la calidad del
software para que las pymes colombianas puedan medir su proceso y producto, desarrollada
desde la Universidad Católica de Pereira.
2 Magister en Ingeniería del Software, Especialista en Propiedad Intelectual: Propiedad indus-
trial, Derechos de autor y Nuevas tecnologías, Ingeniero de Sistemas. Líder del Grupo de
Investigación TICs. Docente Investigador, Universidad Católica de Pereira, Pereira (Colombia).
Correo electrónico: luis.pelaez@ucp.edu.co
3 Estudiante de Magister en Ingeniería de Sistemas y Computación, Ingeniero de Sistemas y
Telecomunicaciones. Integrante Grupo de Investigación TICs. Docente Investigador, Universi-
dad Católica Popular del Risaralda, Pereira, Colombia). Correo electrónico: ricardo.hurtado@
ucp.edu.co
4 Ingeniero de Sistemas y Telecomunicaciones. Gerente de Ingecol Internacional, Pereira
(Colombia). Correo electrónico: gerencia@ingecolint.com



en la industria del software, aunque su adopción represente altos
riesgos por la inexperiencia en el campo para una MiPyme colom-
biana. Lo anterior se debe a que las principales propuestas fueron
desarrolladas principalmente para ser implantadas por empresas
con una trayectoria marcada, experiencia notable, disponibilidad
de recursos económicos, entre otras características, que impo-
sibilitan que una pyme en el contexto colombiano pueda aspirar
fácilmente a la implementación de un modelo de calidad. Con lo
anterior, es necesario explorar el estado de las propuestas enfo-
cadas a la calidad en el software, existentes y más reconocidas
en el contexto y las certificaciones y organizaciones enfocadas en
el mejoramiento de la calidad en el software colombiano.
Palabras Clave: Mejora de Procesos de Software (SPI), CMMI,
ITMark, ISO/IEC 15504, Agile MECPDS.

Abstract
In the context of software development, it becomes very important
to implement models internationally recognized, whose aim might
be to reach the quality that processes and products have in large
industries. Thus, if the SMEs from Colombia which produce soft-
ware want to be compared to those of the same sector included
in the worldwide market, they must consider the importance of
quality certification these have already achieved. However, rea-
ching a certain level of certification requires the consideration of
recognized models in the software industry, although its adoption
represents high risk due to inexperience in the field for a Colombian
SME. This is because the main proposals were developed prima-
rily to be implemented by companies with a strong track record,
remarkable experience, and availability of financial resources,
among other conditions, which limits a SME in the Colombian
context to implement a quality model. With this, it is necessary to
explore the status of proposals focused on the software quality
which exist and are the most recognized in our context and also
the certifications and organizations focused on improving software
quality in Colombia.
Keywords: Software Processes Improvement (SPI), CMMI, IT-
Mark, ISO/IEC 15504, Agile MECPDS.

42


Introducción
La dependencia generada por parte de la sociedad a las tecnologías
de la información, la demanda generada por usuarios que reclaman
servicios que den solución a sus necesidades y las exigencias de un
entorno cambiante, han impulsado un número significativo de compañías
desarrolladoras de software a buscar soluciones enfocadas en mejorar
organizacional y estratégicamente sus procesos para desarrollar pro-
ductos software de mayor calidad.
En Colombia, muchas de las soluciones propuestas por pymes desarro-
lladoras de software no cumplen con los requerimientos mínimos que sa-
tisfagan las necesidades puntuales de sus clientes, ni mucho menos que
les permita competir a nivel de calidad del software en mercados interna-
cionales, provocando problemas de diversa índole que pueden acarrear no
solo grandes costos de inversión si no de mantenimiento, administración,
adecuación y reparación de las soluciones software implantadas.
Es por este motivo que surge la necesidad de hacer uso de propuestas,
metodologías y guías avaladas por organismos reconocidos en el área
de la calidad del software en el ámbito internacional, que se enfoquen
principalmente en el contexto y la idiosincrasia Colombiana, cuyo obje-
tivo se centre en auditar y certificar la forma como se emplean métodos
organizados y sistemáticos que contribuyan a mejorar los procesos de
las empresas enfocadas en el desarrollo del software y por ende lograr
productos de mayor calidad.
El artículo inicia con la presentación y evolución del concepto de ca-
lidad en el contexto del proyecto de investigación; seguidamente, el
significado de la calidad en la industria del software. Se continúa con
las propuestas de evaluación y certificación de calidad del software
explicando la metodología seguida en el proyecto para clasificarlas y
sistematizarlas y finalmente algunas conclusiones, a manera de reco-
mendaciones, para las MiPymes5 de Colombia.

1. Marco teórico
1.1 Importancia y evolución del concepto de calidad
Existe calidad cuando las necesidades del cliente son cubiertas y el
mismo está dispuesto a pagar y contratar a la misma empresa en otras

5 La pequeña y mediana empresa, conocida también como PYME, es una empresa con ca-
racterísticas distintivas. Las pymes son agentes con lógicas, culturas, intereses y un espíritu
emprendedor específicos. Usualmente se ha visto también el término MiPyME (acrónimo de
“micro, pequeña y mediana empresa”), que es una expansión del término original, en donde
se incluye a la microempresa.

43


ocasiones por el mismo u otro servicio. La calidad ha sido un tema
de constante evolución que, según Clarke (2000), se ha hecho cada
vez más importante en el último siglo, el mismo se evidencia en las
siguientes etapas:
• Primera etapa: La calidad se relaciona con el proceso de producción
que parte de la década de 1920, mediante la inspección, el control
estadístico y el concepto de calidad como principio de productos
sin defectos.
• Segunda Etapa: La calidad se integra como objetivo de la adminis-
tración a partir de la mitad de la década de 1940, con el asegura-
miento de la calidad, como un concepto necesario para el desarrollo
adecuado de las áreas funcionales de las empresas. La meta es
evitar productos defectuosos, y su responsabilidad se centra en el
conocimiento sobre el control estadístico de la calidad. En el ase-
guramiento de la calidad, la administración involucra a todos los
integrantes de la empresa.
• Tercera etapa: Se inicia en la década de 1970 e implica la interpre-
tación de la calidad como una estrategia fundamental para alcanzar
la competitividad, y como un símbolo organizacional que trasciende
las fronteras a través de la propuesta de calidad. Aparece un cambio
paulatino en la actitud de la alta gerencia, surgen nuevos paradigmas
en la administración representados por la cultura corporativa, la rein-
geniería de procesos y el aprendizaje organizacional. La doctrina de
la calidad involucra a la empresa, coordinándose los esfuerzos de la
dirección y de los empleados para favorecer la calidad de productos
y servicios y así responder a los requerimientos del consumidor y
ser competitivos en los mercados internacionales.
• Cuarta etapa: A partir de 1980, la calidad es sinónimo de cliente,
en donde todas las entidades de una compañía deben trabajar en
conjunto por llenar las expectativas de su cliente final y como único
fin desarrollar productos y soluciones que cubran sus necesidades
directas. Como describe Barba Álvarez (2001), el concepto de la
calidad asume un alto contenido simbólico al constituirse como un
compromiso interiorizado y compartido por la empresa y sus inte-
grantes, que implica cambio de actitudes y mejora continua en todos
los niveles, actividades y procesos de la empresa, con un punto
focal hacia la satisfacción de necesidades y expectativas del cliente.
Con esta visión, muchas empresas mundiales empezaron a ver la calidad
como la forma de acceder a las expectativas del cliente lo que ha aunado
a rebajar costos, lograr el compromiso de los empleados y asegurar la
mejora continua. De esta forma se generó una cultura de la calidad, que

44


buscaba siempre el beneficio del usuario final, pero que de esta forma
beneficiaba directamente a la empresa que producía dicho producto o
servicio, tal y como lo describía Clarke (2000), se enmarcaba en la con-
secución de una cultura de calidad y una administración activa y eficiente.
Según la norma ISO 8402:1994, descrita por Peach (1999), «calidad es
el total de las características de una entidad que atañe a su capacidad
para satisfacer necesidades explícitas e implícitas de un usuario o clien-
te»; al estudiar la calidad como una estrategia total, amplía un poco más
la definición el introducir el factor proceso. De esta forma lo ha definido
Feigenbaum (1986): «La calidad es la suma de los valores agregados
que se incorporan al producto y/o servicio a lo largo del proceso; es el
valor final a través del cual los clientes satisfacen sus necesidades y
expectativas». El mencionado autor, a estos elementos, les une el factor
económico y da una definición sobre la meta de la industria competitiva
respecto a la calidad del producto, que es «Proporcionar un producto o
servicio en el cual su calidad haya sido diseñada, producida y conser-
vada, a un costo económico y que satisfaga por entero al consumidor».
Con estas definiciones, la calidad se puede dividir en dos agrega-
dos: - el primero habla sobre eficiencia de la producción, que obliga
a las organizaciones a mejorar los procesos de producción y cuidar
el diseño del producto final, con el personal y los recursos técnicos y
económicos necesarios; - el segundo, definido por Espinosa y Pérez
(1994), da cuenta de los valores, la cultura y la filosofía que apoya a la
calidad entendiéndola como un valor, con actitudes y comportamientos
en el trabajo y en la vida privada de los trabajadores y con estándares
deseables.
También es importante entender las diferentes perspectivas desde las
cuales se puede definir la calidad:
• Enfoque basado en el juicio, con calidad como sinónimo de
excelencia.
• Enfoque hacia los productos, que reflejan la diferencia en algún
atributo.
• Enfoque hacia el usuario, de acuerdo con lo que el cliente quiere.
• Enfoque hacia el valor: la relación entre el uso o la satisfacción con
el precio.

En la actualidad existen definiciones por parte de autores reconocidos
con respecto a la calidad, pero es importante reconocer que la calidad
en la industria de software es diferente a la de otras industrias, como lo
definen Fairley, Aguilar y Rangel (1987), al afirmar que «la calidad en
el software es diferente al de la manufactura ya que el producto de un

45


proyecto de software es intangible, flexible; el proceso de desarrollo no
es estandarizado, muchos proyectos se hacen una sola vez y no son
parecidos a otros proyectos». Con base en lo anterior, el empresario
de software considera su trabajo como una labor de servicio más que
de manufactura, por lo que:
- Es difícil identificar y medir las necesidades de los clientes y los
estándares de desempeño.
- La producción de servicios requiere de un mayor grado de perso-
nalización y su calidad sólo se puede medir comparándola con las
expectativas de los clientes.
- Es necesario prestar mucha atención a la capacitación y la integración
de la calidad en el servicio, como medio de asegurar la calidad.

Por lo anterior, es importante definir un concepto de calidad único en-
focado principalmente a la calidad para el desarrollo de soluciones y
productos software. IEEE (2003), en su estándar 610-1990, considera
que «el concepto de calidad en el software es el grado con el que un
sistema, componente o proceso cumple los requerimientos especifica-
dos y las necesidades o expectativas del cliente o usuario». Y al igual
que consideran Espinosa y Pérez (1994), puede englobarse en las
dimensiones del producto y el servicio:
- Calidad del producto: Es el resultado de actividades o procesos que
comprende servicio, hardware, materiales procesados, software o
una combinación de ellos y está en función de aspectos como los
requerimientos del cliente, proyecto, diseño de la solución tecnoló-
gica, entrega a tiempo, etc.
- Calidad en el servicio: El servicio se define como el resultado ge-
nerado por actividades en la interrelación entre proveedor y cliente.
Diversos autores señalan ciertas proposiciones acerca de la calidad
y del trabajo del software, así Sanders y Curran (1994), indican que
la calidad es la llave del éxito en el negocio de software y el modo
más barato de mejorar la productividad, es visualizar la gente y la
cultura como entes tan o más importantes que la tecnología, pero
es necesario mejorar el proceso de software que incluye personal,
instalaciones, equipo, tecnología y metodología, esto quiere decir
que las personas deben trabajar de la mano con la tecnología para
simplificar el trabajo y llegar a productos de mejor calidad; la direc-
ción debe de mostrar un mando y un compromiso genuino, la calidad
debe adaptarse a las necesidades y circunstancias de la empresa o
no será ni eficaz ni eficiente.

46


Un buen proceso de desarrollo de software debe permitir la entrega de
productos de calidad económicamente y de modo oportuno, a través
de una práctica eficaz, base de los principios de calidad siguientes:
prevención y corrección de defectos y trabajo de conformidad con
estándares y procedimientos, consideran Sanders y Curran (1994),
quienes expresan que un programa de mejora de calidad debe tener
aspectos técnicos y culturales; el aspecto técnico implica desarrollar
estándares y procedimientos para poner en práctica la calidad en todas
las actividades y en el aspecto cultural la calidad es el valor central de la
compañía, con conciencia de responsabilidad personal y un programa
de capacitación permanente.
A diferencia de los anteriores, Pulido (2005), menciona que los factores
principales del funcionamiento de la industria del software son «el apoyo
gubernamental, el uso de la lengua inglesa, su cultura organizacional,
exportaciones, disponibilidad de mano de obra especializada, están-
dares de calidad y disponibilidad de recursos humanos en cantidad y
calidad». Por su parte, Verdines (1992), indica que para determinar el
estado actual de los productos de software en una organización, hay
que situarse en alguno de los niveles de la escala de calidad:
- Nivel inferior. La responsabilidad del producto terminado recae total-
mente en la persona que tiene que crear, revisar y probar el producto.
El proceso de desarrollo es una actividad individual, enfatizando la
solución de problemas en un contexto puramente técnico y con una
nula confiabilidad en los productos.
- Nivel intermedio. Se cuenta con métodos y procedimientos de desa-
rrollo, ordenados y consistentes, pero no tomados en cuenta en cada
una de las etapas del ciclo de desarrollo del producto de software. Ya
existe cierta interacción entre los equipos de desarrollo y el usuario
del producto y ya se considera la capacitación del personal y una
visión de cambio hacia la filosofía de calidad.
- Nivel superior. Existe un grupo de aseguramiento de calidad del
software responsable de establecer estándares, existe la actitud
de creatividad individual compatible con el espíritu de equipo
necesario.

1.2 Descripción de la calidad en la industria del software
El software es una industria relativamente nueva, su origen puede si-
tuarse en 1955. Algunas de las características de esta fase inicial son
la elaboración y distribución gratuita de programas por parte de los
fabricantes de hardware y el intercambio de programas e información
entre usuarios expertos.

47

Ventana informatica / Edicción 25

Ventana informatica / Edicción 25

Recomendados

Recomendados

Más contenido relacionado

Destacado

Destacado (20)

Similar a Ventana informatica / Edicción 25

Similar a Ventana informatica / Edicción 25 (20)

Más de Andres Epifanía Huerta

Más de Andres Epifanía Huerta (20)

Último

Último (13)

Ventana informatica / Edicción 25