& TELEMÁTICA - Universidad Icesi · WLAN en sus equipos; tal es el caso de Intel,1 que fabrica el...

1SISTEMAS& TELEMÁTICA

Seguridad en redes inalámbricas 802.11 13Juan Manuel Madrid Molina

Estructura básica del proceso unificadode desarrollo de software 29Robin Alberto Castro Gil

Realimentación como paradigmade integración conceptual en educación 43Daniel Martín Vega Barvo

Herramienta para el cálculode invariantes topológicos 59Juan Pablo Bedoya GiraldoAura Lucía Pérez EscobarJavier Guillermo Valdés Duque

Una aproximación a los indicadoresde gestión a través de la dinámica de sistemas 69Fernando Antonio Arenas Guerrero

Aplicación práctica del diseño de pruebasde software a nivel de programación 83Oscar Hernando Guzmán Cortés

2 SISTEMAS& TELEMÁTICA


INGENIERÍA DE SISTEMAS E INGENIERÍA TELEMÁTICA

UNIVERSIDAD ICESI

COMITÉ EDITORIAL DE LA UNIVERSIDAD

Francisco Piedrahíta Plata José Hernando BahamónRector Director Académico

Héctor Ochoa Díaz Henry Arango DueñasDecano de la Facultad de Ciencias Decano de la Facultad de Ingenierías

Administrativas y Económicas

Lelio Fernández Druetta Mario Tamayo y TamayoDecano de Derecho y Humanidades Director de Investigaciones

y Publicaciones

COMITÉ EDITORIAL DE LA REVISTA

R e v i s t a d e l a f a c u l t a d d e i n g e n i e r í a

OFICINA DE INVESTIGACIONES Y PUBLICACIONESUNIVERSIDAD ICESI

EDITOR•Los autores de los artículos de esta publicación son responsables de

los mismos.

•El material de esta publicación puede ser reproducido sin autorización,mencionando título, autor y, como fuente, S & T. Revista de Ingenieríade Sistemas e Ingeniería Telemática, Universidad Icesi.

Http://www.icesi.edu.coInformes: Tel.: 555 2334. Ext. 377

Fax: 555 1706 - 555 1745Editor. e-mail:[email protected]: e-mail:[email protected]

Cali, Valle, Colombia, Sudamérica

Guillermo Londoño AcostaDirector del Programa

de Ingeniería de Sistemas

Alvaro Pachón de la CruzJefe del Departamento de Redes

y Comunicaciones

Andrés Navarro CadavidProfesor de la Universidad Icesi

Gonzalo UlloaDirector de la Especialización

de Negocios en Internet

Luis Eduardo MúneraProfesor de la Universidad Icesi

Andrés Navarro NewballProfesor de la Pontificia

Universidad Javeriana, Cali

Juan Manuel Madrid MolinaDirector del Programa

de Ingeniería Telemática

Narcís CardonaProfesor de la Universidad Politécnica

de Valencia, España

Joaquín RestrepoProfesor de la Pontificia Universidad

Bolivariana de Medellín

Edwin MontoyaProfesor de la Universidad EAFIT, Medellín

David Fernández McCaanProfesor de la Universidad de Antioquia, Medellín

Homero OrtegaProfesor de la Universidad Industrial

de Santander, Bucaramanga


GUÍA PARA LOS AUTORESDE ARTÍCULOS

Para los autores de los artículos de laRevista «S & T Ingeniería de Siste-mas e Ingeniería Telemática» de laUniversidad Icesi.

• El autor debe garantizar que suartículo no ha sido publicado enningún medio.

• Los autores de artículos serán res-ponsables de los mismos, y portanto no comprometen ni los prin-cipios o políticas de la Universi-dad, ni los del Comité Editorial.

• El Comité Editorial se reserva elderecho de publicar o no los artí-culos que no cumplan con los cri-terios de publicación por parte dela Universidad Icesi.

• La temática de los artículos debeser de las diferentes áreas de In-geniería de Sistemas, Informáti-ca y Telemática, resultado de in-vestigación propiamente dicha,aplicaciones reales, productos deinvestigación formativa, procesossistémicos de análisis de proble-mas y propuestas de solución.

• Los artículos deben contener:

- Título (claro y preciso)

- Breve reseña del autor.

- Abstract o resumen ejecutivodel artículo (máximo doce ren-glones a doble espacio).

- Palabras claves.

- Clasificación Colciencias*.

- Introducción.

- Desarrollo.

- Referencias y notas de pie depágina.

- Conclusiones.

- Bibliografía o fuentes de infor-mación.

- Extensión: No exceder de 25páginas en total.

- Tipo de letra: Arial (o equiva-lente) fuente No. 12 y con in-terlineado a doble espacio.

- Una copia impresa y su respec-tivo disquete en Word Win ocompatible IBM. No enviarMacintosh.

Es conveniente resaltar los párrafosu oraciones más significativos delcontenido del artículo y todo aquelloque dé significado a la estructura delmismo.


Los artículos se deben redactar entercera persona del singular, imper-sonal, contar con adecuada puntua-ción y redacción, carecer de erroresortográficos. Conservar equilibrio enla estructura de sus párrafos.

* Clasificación Colciencias para ar-tículos científicos y tecnológicos:

a) Artículos de investigacióncientífica y de desarrollo tec-nológico: documentos que pre-sentan resultados derivadosde proyectos de investigacióncientífica y/o desarrollo tec-nológico.

b) Artículos de reflexiones origi-nales sobre un problema o tó-pico particular: documentos quecorresponden a resultados deestudios realizados por el o losautores sobre un problema teó-rico o práctico.

c) Artículos de revisión: estudioshechos por el o los autores conel fin de dar una perspectiva ge-neral del estado de un dominioespecífico de la ciencia y la tec-nología, de sus evoluciones du-rante un período y donde se se-ñalan las perspectivas de su de-sarrollo y evolución futuros.


GUÍA PARA LAS RESEÑASBIBLIOGRÁFICAS

• Tipo de libro reseñado: Debe serde tipo ejecutivo, no un texto aca-démico.

• Título del libro: Tomado de la ca-rátula.

• Autor del libro: Apellidos, Nombre(persona del autor, lo relevante).

• Nombre del traductor (si lo tuvie-re).

• ISBN

• Editorial, ciudad y fecha.

• Tamaño: 16.5 cm x 23.5 cm.Número de páginas.

• Fortalezas (puntos del porqué elejecutivo debe leerlo, cómo estáestructurado el libro: partes, ca-pítulos) etc.

• Debilidades (puntos no tan atrac-tivos del libro).

• Extensión entre 700 a 800 pala-bras (equivalente a página y me-dia, a doble espacio).

• Lenguaje ejecutivo (breve, no aca-démico, darle ayuda / consejopráctico para hoy, con ejemplos deltexto).


La Revista S & T Ingeniería de Sistemas eIngeniería Telemática, está dirigida a ingenie-ros de sistemas, ingenieros electrónicos, inge-nieros telemáticos y afines; profesores univer-sitarios y estudiantes en las diferentes áreasde la ingeniería; profesionales especialijadosen estas áreas.

Usted puede acceder a ella entrando en nues-tra página Web en internet y bajar en formatoPDF el artículo de su interés o la totalidad delnúmero que desee, sólo debe entrar a la direc-ción: http://www.icesi.edu.co/es/publicacionesy seleccionar la edición correspondiente.Cualquier duda o comentario dirigirlo a lacuenta de correo [email protected];[email protected]

EL EDITOR


Seguridad en redes inalámbricas 802.11

Fecha de recepción: 20-11-2003 Fecha de aceptación: 20-4-2004

Juan Manuel Madrid MolinaUniversidad Icesi

[email protected]

ABSTRACTLack of security in wireless LANs isa problem which has not been correc-tly assessed by network managersand people in charge of information,in spite of its seriousness. This arti-cle presents the existing technologiesfor heightening the security level in802.11 wireless LANs, among withtheir advantages, disadvantages andapplication scenarios.

KEYWORDSInformation Security, Network Secu-rity, Wireless Networks.

RESUMENLa falta de seguridad en las redesinalámbricas es un problema que, apesar de su gravedad, no ha recibidola atención debida por parte de losadministradores de redes y los res-ponsables de la información. Esteartículo presenta las tecnologías exis-tentes para mejorar el nivel de segu-ridad en las redes inalámbricas802.11, con sus ventajas, desventajasy escenarios de aplicación.

PALABRAS CLAVESSeguridad informática, seguridad enredes, redes inalámbricas.

Clasificación: B


INTRODUCCIÓNLas redes inalámbricas de área local(WLAN) tienen un papel cada vezmás importante en las comunicacio-nes del mundo de hoy. Debido a sufacilidad de instalación y conexión, sehan convertido en una excelente al-ternativa para ofrecer conectividaden lugares donde resulta inconve-niente o imposible brindar serviciocon una red alambrada. La populari-dad de estas redes ha crecido a talpunto que los fabricantes de compu-tadores y motherboards están inte-grando dispositivos para acceso aWLAN en sus equipos; tal es el casode Intel,1 que fabrica el chipset Cen-trino para computadores portátiles.

Una WLAN se puede conformar dedos maneras:

• En estrella. Esta configuraciónse logra instalando una estacióncentral denominada punto de ac-ceso (Access Point), a la cual acce-den los equipos móviles. El puntode acceso actúa como regulador detráfico entre los diferentes equi-pos móviles. Un punto de accesotiene, por lo regular, un cubri-miento de 100 metros a la redon-da, dependiendo del tipo de ante-na que se emplee, y del número ytipo de obstáculos que haya en lazona.

• Red ad hoc. En esta configura-ción, los equipos móviles se conec-tan unos con otros, sin necesidadde que exista un punto de acceso.

El tipo de conformación más comúnes en estrella; se emplea por lo gene-ral cuando se desea ofrecer accesoinalámbrico a una red alambrada yaexistente.

En el momento existen tres estánda-res diferentes para las WLAN, desa-rrollados por la IEEE:2,16

• 802.11b: Introducido en 1999,como extensión al estándar 802.11publicado en 1997. Los equiposinalámbricos que operaban con lanorma 802.11 nunca llegaron atener una buena acogida, porquela máxima velocidad de conexiónque ofrecían era de 2 Mbps. Lanorma 802.11b subsanó este pro-blema al permitir lograr una ve-locidad más alta de transferenciade datos. Dicha velocidad tiene unlímite de 11 Mbps (similar al deuna red Ethernet convencional).En la práctica, se logran velocida-des entre 2 y 5 Mbps, lo que de-pende del número de usuarios, dela distancia entre emisor y recep-tor, de los obstáculos y de la in-terferencia causada por otros dis-positivos. El factor interferenciaes uno de los que más influye, por-que los equipos 802.11b operan enla banda de 2.4 GHz, en la que sepresenta interferencia de equiposcomo teléfonos inalámbricos yhornos microondas. A pesar de susproblemas, el estándar 802.11b seha convertido en el más popular.

• 802.11a: Se introdujo al mismotiempo que 802.11b, con la inten-ción de constituirla en la normapara redes inalámbricas para usoempresarial (802.11b se enfocóhacia las redes caseras y para pe-queños negocios). Ofrece velocida-des de hasta 54 Mbps (típicamen-te 22 Mbps) y opera en la bandade 5 GHz. Su alto precio, el hechode que la banda de 5 GHz estéregulada en algunos países, y su


menor cubrimiento ha hecho quelos equipos 802.11a sean menospopulares que los 802.11b.

• 802.11g: Surgió en 2003, como laevolución del estándar 802.11b.Esta norma ofrece velocidadeshasta de 54 Mbps (22 Mbps típi-camente) en la banda de 2.4 GHz,y es compatible hacia atrás con losequipos 802.11b, por lo cual hatenido una gran acogida, y se pre-vé que reemplace por completo alestándar 802.11b en un futuro nomuy lejano.

EL PROBLEMADE LA SEGURIDADEl acceso sin necesidad de cables, larazón que hace tan populares a lasredes inalámbricas, es a la vez el pro-

blema más grande de este tipo de re-des en cuanto a seguridad se refiere.Cualquier equipo que se encuentre a100 metros o menos de un punto deacceso, podría tener acceso a la redinalámbrica. Por ejemplo, si variasempresas tienen sede en un mismoedificio, y todas ellas poseen red ina-lámbrica, el equipo de un empleadopodría encontrarse en cierto momen-to en el área de influencia de dos omás redes diferentes, y dicho emplea-do podría conectarse (intencional-mente o no) a la red de una compa-ñía que no es la suya. Aún peor, comolas ondas de radio pueden salir deledificio, cualquier persona que poseaun equipo móvil y entre en el área deinfluencia de la red, podría conectar-se a la red de la empresa.

Figura 1. Acceso no autorizado a una red inalámbrica.

Lo grave de esta situación es quemuchos administradores de redesparecen no haberse dado cuenta delas implicaciones negativas de poseerpuntos de acceso inalámbrico en lared de una empresa. Es muy comúnencontrar redes en las que el acceso

a internet se protege adecuadamen-te con un firewall bien configurado,pero al interior de la red existen pun-tos de acceso inalámbrico totalmentedesprotegidos e irradiando señal ha-cia el exterior del edificio. Cualquierpersona que desde el exterior capte


la señal del punto de acceso, tendráacceso a la red de la compañía, con laposibilidad de navegar gratis en lainternet, emplear la red de la compa-ñía como punto de ataque hacia otrasredes y luego desconectarse para noser detectado, robar software y/o in-formación, introducir virus o softwaremaligno, entre muchas otras cosas.Un punto de acceso inalámbrico malconfigurado se convierte en una puer-ta trasera que vulnera por completola seguridad informática de la com-pañía.

La mala configuración de un accesoinalámbrico es, desgraciadamente,una cosa muy común. Un estudiopublicado en 2003 por RSA SecurityInc.4 encontró que de 328 puntos deacceso inalámbricos que se detecta-ron en el centro de Londres, casi lasdos terceras partes no tenían habili-tado el cifrado mediante WEP (Wired

Equivalent Protocol). Además, cien deestos puntos de acceso estaban divul-gando información que permitía iden-tificar la empresa a la que pertene-cían, y 208 tenían la configuracióncon la que vienen de fábrica.

Existen dos prácticas bien conocidaspara localizar redes inalámbricas:

• El warchalking,3 que consiste encaminar por la calle con un com-putador portátil dotado de unatarjeta WLAN, buscando la señalde puntos de acceso. Cuando seencuentra uno, se pinta con tizaun símbolo especial en la acera oen un muro, indicando la presen-cia del punto de acceso y si tieneconfigurado algún tipo de seguri-dad o no. De este modo, otras per-sonas pueden conocer la localiza-ción de la red.

Figura 2. Warchalking y su simbología.3

let’s warchalk!

Key

OPENNODE

CLOSENODE

WEPNODE

Symbol

bandwidth

ssid

ssid accesscontact

bandwidthblackbeltjones.com/warchalking

ssid


• El wardriving, propio para loca-lizar puntos de acceso inalámbri-co desde un automóvil. Para estefin se necesita de un computadorportátil con una tarjeta WLAN,una antena adecuada (que se pue-de elaborar fácilmente con una

lata de conservas o de papas fri-tas,5) un GPS para localizar lospuntos de acceso en un mapa, ysoftware para detección de redesinalámbricas, que se consigue li-bremente en la internet.

Figura 3. Wardriving. A la izquierda puede observarse el equipo necesario(computador, GPS y antena); a la derecha, los triángulos indican sobre elmapa18 la posición de redes inalámbricas.

Una vez localizada una red inalám-brica, una persona podría llevar acabo dos tipos de ataques:

• Ingresar a la red y hacer uso ile-gítimo de sus recursos.

• Configurar un punto de accesopropio, orientando la antena de talmodo que los computadores queson clientes legítimos de la redatacada se conecten a la red delatacante. Una vez hecho esto, elatacante podría robar la informa-ción de dichos computadores, ins-talarles software maligno o dañarla información.

GARANTIZANDO LASEGURIDAD DE UNA REDINALÁMBRICAPara poder considerar una red ina-lámbrica como segura, debería cum-plir con los siguientes requisitos:

• Las ondas de radio deben confi-narse tanto como sea posible. Estoes difícil de lograr totalmente,pero se puede hacer un buen tra-bajo empleando antenas direccio-nales y configurando adecuada-mente la potencia de transmisiónde los puntos de acceso.

• Debe existir algún mecanismo deautenticación en doble vía, quepermita al cliente verificar que seestá conectando a la red correcta,y a la red constatar que el clienteestá autorizado para acceder aella.

• Los datos deben viajar cifrados porel aire, para evitar que equipos aje-nos a la red puedan capturar da-tos mediante escucha pasiva.

Existen varios métodos para lograrla configuración segura de una red


inalámbrica; cada método logra unnivel diferente de seguridad y presen-ta ciertas ventajas y desventajas. Sehará a continuación una presentaciónde cada uno de ellos.

Método 1:Filtrado de direcciones MACEste método consiste en la creaciónde una tabla de datos en cada uno delos puntos de acceso a la red inalám-brica. Dicha tabla contiene las direc-ciones MAC (Media Access Control)de las tarjetas de red inalámbricasque se pueden conectar al punto deacceso. Como toda tarjeta de red po-see una dirección MAC única, se lo-gra autenticar el equipo.

Este método tiene como ventaja susencillez, por lo cual se puede usarpara redes caseras o pequeñas. Sinembargo, posee muchas desventajasque lo hacen impráctico para uso enredes medianas o grandes:

• No escala bien, porque cada vezque se desee autorizar o dar debaja un equipo, es necesario edi-tar las tablas de direcciones de to-dos los puntos de acceso. Despuésde cierto número de equipos o depuntos de acceso, la situación setorna inmanejable.

• El formato de una dirección MACno es amigable (normalmente seescriben como 6 bytes en hexade-cimal), lo que puede llevar a co-meter errores en la manipulaciónde las listas.

• Las direcciones MAC viajan sincifrar por el aire. Un atacante po-dría capturar direcciones MAC detarjetas matriculadas en la redempleando un sniffer, y luegoasignarle una de estas direcciones

capturadas a la tarjeta de su com-putador, empleando programastales como AirJack6 o WellenRei-ter,7 entre otros. De este modo, elatacante puede hacerse pasar porun cliente válido.

• En caso de robo de un equipo ina-lámbrico, el ladrón dispondrá de undispositivo que la red reconoce comoválido. En caso de que el elementorobado sea un punto de acceso elproblema es más serio, porque elpunto de acceso contiene toda la ta-bla de direcciones válidas en su me-moria de configuración.

Debe notarse además, que este méto-do no garantiza la confidencialidad dela información transmitida, ya que noprevé ningún mecanismo de cifrado.

Método 2:Wired Equivalent Privacy(WEP)El algoritmo WEP10 forma parte dela especificación 802.11, y se diseñócon el fin de proteger los datos que setransmiten en una conexión inalám-brica mediante cifrado. WEP opera anivel 2 del modelo OSI y es soportadopor la gran mayoría de fabricantes desoluciones inalámbricas.

El algoritmo WEP cifra de la siguien-te manera (ver Figura 4):

• A la trama en claro se le compu-ta un código de integridad (Inte-grity Check Value, ICV) median-te el algoritmo CRC-32. DichoICV se concatena con la trama, yes empleado más tarde por el re-ceptor para comprobar si la tra-ma ha sido alterada durante eltransporte.

• Se escoge una clave secreta com-partida entre emisor y receptor.


Esta clave puede poseer 40 ó 128bits.

• Si se empleara siempre la mismaclave secreta para cifrar todas lastramas, dos tramas en claro igua-les producirían tramas cifradas si-milares. Para evitar esta eventua-lidad, se concatena la clave secretacon un número aleatorio llamadovector de inicialización (IV) de 24bits. El IV cambia con cada trama.

• La concatenación de la clave se-creta y el IV (conocida como semi-lla) se emplea como entrada de ungenerador RC4 de números seu-do-aleatorios. El generador RC4

es capaz de generar una secuen-cia seudo-aleatoria (o cifra de flu-jo) tan larga como se desee a par-tir de la semilla.

• El generador RC4 genera una ci-fra de flujo, del mismo tamaño dela trama a cifrar más 32 bits (paracubrir la longitud de la trama y elICV).

• Se hace un XOR bit por bit de latrama con la secuencia de clave,obteniéndose como resultado latrama cifrada.

• El IV y la trama se transmitenjuntos.

Figura 4. Funcionamiento del algoritmo WEP en modalidad de cifrado.10

Vectorde inicialización (IV)

En el receptor se lleva a cabo el pro-ceso de descifrado (Figura 5):

• Se emplean el IV recibido y la cla-ve secreta compartida para gene-rar la semilla que se utilizó en eltransmisor.

• Un generador RC4 produce la ci-fra de flujo a partir de la semilla.Si la semilla coincide con la em-pleada en la transmisión, la cifrade flujo también será idéntica ala usada en la transmisión.

• Se efectúa un XOR bit por bit dela cifra de flujo y la trama cifra-do, obteniéndose de esta manerala trama en claro y el ICV.

• A la trama en claro se le aplica elalgoritmo CRC-32 para obtenerun segundo ICV, que se comparacon el recibido.

• Si los dos ICV son iguales, la tra-ma se acepta; en caso contrario serechaza.

Clave secreta

Semilla GNSA Cifra de flujo

IV

Textocifrado

Texto en claro

Algoritmo de integridadCódigo deintegridad(ICV)

Mensaje


Figura 5. Funcionamiento del algoritmo WEP en modalidad de descifrado.10

Clave secreta

El algoritmo WEP resuelve aparen-temente el problema del cifrado dedatos entre emisor y receptor. Sinembargo, existen dos situaciones quehacen que WEP no sea seguro en lamanera que es empleado en la mayo-ría de aplicaciones:

• La mayoría de instalaciones em-plea WEP con claves de cifradoestáticas (se configura una claveen el punto de acceso y no se lacambia nunca, o muy de vez encuando). Esto hace posible que unatacante acumule grandes canti-dades de texto cifrado con la mis-ma clave y pueda intentar un ata-que por fuerza bruta.

• El IV que se utiliza es de longitudinsuficiente (24 bits). Dado quecada trama se cifra con un IV di-ferente, solamente es cuestión detiempo para que se agote el espa-cio de 224 IV distintos. Esto no esproblemático en una red caseracon bajo tráfico, pero en una redque posea alto tráfico se puedeagotar el espacio de los IV en máso menos 5 horas. Si el atacantelogra conseguir dos tramas con IVidéntico, puede efectuar un XORentre ellas y obtener los textos enclaro de ambas tramas mediante

un ataque estadístico. Con el tex-to en claro de una trama y su res-pectivo texto cifrado se puede ob-tener la cifra de flujo; conociendoel funcionamiento del algoritmoRC4 es posible entonces obtenerla clave secreta y descifrar todala conversación.17

• WEP no ofrece servicio de auten-ticación. El cliente no puede au-tenticar a la red, ni al contrario;basta con que el equipo móvil y elpunto de acceso compartan la cla-ve WEP para que la comunicaciónpueda llevarse a cabo.

Existen en este momento diversasherramientas gratuitas para romperla clave secreta de enlaces protegi-dos con WEP. El primer programaque hizo esto posible fue WEPCrack,8

que consiste en una serie de scriptsescritos en lenguaje Perl diseñadospara analizar un archivo de capturade paquetes de un sniffer. La herra-mienta AirSnort9 hace lo mismo, perointegra las funciones de sniffer y rom-pedor de claves, y por lo tanto es másfácil de usar. Airsnort captura paque-tes pasivamente, y rompe la claveWEP cuando ha capturado suficien-tes datos.

IV

Trama cifrada

Semilla

Mensaje

GNSACifra de flujo Trama en claro

Algoritmo de integridadICV*

OKICVICV = ICV*?

GNSA = Generador de números seudo-aleatorios


Método 3:Las VPNUna red privada virtual (Virtual Pri-vate Network, VPN) emplea tecnolo-gías de cifrado para crear un canalvirtual privado sobre una red de usopúblico. Las VPN resultan especial-mente atractivas para proteger redesinalámbricas, debido a que funcionansobre cualquier tipo de hardware ina-lámbrico y superan las limitacionesde WEP.

Para configurar una red inalámbricautilizando las VPN, debe comenzar-se por asumir que la red inalámbrica

es insegura. Esto quiere decir que laparte de la red que maneja el accesoinalámbrico debe estar aislada delresto de la red, mediante el uso deuna lista de acceso adecuada en unenrutador, o agrupando todos lospuertos de acceso inalámbrico en unaVLAN si se emplea switching. Dichalista de acceso y/o VLAN solamentedebe permitir el acceso del cliente ina-lámbrico a los servidores de autori-zación y autenticación de la VPN.Deberá permitirse acceso completo alcliente, sólo cuando éste ha sido de-bidamente autorizado y autenticado.

Servidor deautorización,autenticación ycifrado de datos

Figura 6. Estructura de una VPN para acceso inalámbrico seguro.

Los servidores de VPN se encargande autenticar y autorizar a los clien-tes inalámbricos, y de cifrar todo eltráfico desde y hacia dichos clientes.Dado que los datos se cifran en unnivel superior del modelo OSI, no esnecesario emplear WEP en este es-quema.

Método 4:802.1x802.1x es un protocolo de control deacceso y autenticación basado en laarquitectura cliente/servidor, que res-tringe la conexión de equipos no au-

torizados a una red.11 El protocolo fueinicialmente creado por la IEEE parauso en redes de área local alambra-das, pero se ha extendido también alas redes inalámbricas. Muchos de lospuntos de acceso que se fabrican enla actualidad ya son compatibles con802.1x.

El protocolo 802.1x involucra tresparticipantes (Figura 7):

• El suplicante, o equipo del clien-te, que desea conectarse con lared.

• El servidor de autorización/auten-

Clienteinalámbrico

Punto deacceso

Switch oenturador

Red corporativa


ticación, que contiene toda la in-formación necesaria para sabercuáles equipos y/o usuarios estánautorizados para acceder a la red.802.1x fue diseñado para emplearservidores RADIUS (Remote Au-thentication Dial-In User Servi-ce), cuya especificación se puedeconsultar en la RFC 2058. Estosservidores fueron creados inicial-mente para autenticar el accesode usuarios remotos por conexiónvía telefónica; dada su populari-

dad se optó por emplearlos tam-bién para autenticación en lasLAN.

• El autenticador, que es el equipode red (switch, enrutador, servi-dor de acceso remoto...) que reci-be la conexión del suplicante. Elautenticador actúa como interme-diario entre el suplicante y el ser-vidor de autenticación, y solamen-te permite el acceso del suplican-te a la red cuando el servidor deautenticación así lo autoriza.

EAPOL(EAP over LAN)

Figura 7. Arquitectura de un sistema de autenticación 802.1x. 12

La autenticación del cliente se llevaa cabo mediante el protocolo EAP (Ex-tensible Authentication Protocol) y elservicio RADIUS, de la siguientemanera:

• El proceso inicia cuando la esta-ción de trabajo se enciende y acti-va su interfaz de red (en el casoalambrado) o logra enlazarse o

asociarse con un punto de acceso(en el caso inalámbrico). En esemomento, la interfaz de red tieneel acceso bloqueado para tráficonormal, y lo único que admite esel tráfico EAPOL (EAP over LAN),que es el requerido para efectuarla autenticación.

Suplicante

Autenticador

Frontera de la red

EAP sobreRADIUS

Servidor deautenticación

(RADIUS)


• La estación de trabajo envía unmensaje EAPOL-Start al auten-ticador, indicando que desea ini-ciar el proceso de autenticación.

• El autenticador solicita a la es-tación que se identifique, me-diante un mensaje EAP-Request/Identity.

• La estación se identifica median-te un mensaje EAP-Response/Identity.

• Una vez recibida la informaciónde identidad, el autenticador en-vía un mensaje RADIUS-Access-Request al servidor de autentica-ción, y le pasa los datos básicosde identificación del cliente.

• El servidor de autenticación res-ponde con un mensaje RADIUS-Access-Challenge, en el cual en-vía información de un desafío quedebe ser correctamente resueltopor el cliente para lograr el acce-so. Dicho desafío puede ser tan

sencillo como una contraseña, oinvolucrar una función criptográ-fica más elaborada. El autentica-dor envía el desafío al cliente enun mensaje EAP-Request.

• El cliente da respuesta al desafíomediante un mensaje EAP-Res-ponse (Credentials) dirigido al au-tenticador. Este último reenvía eldesafío al servidor en un mensajeRADIUS-Access-Response.

• Si toda la información de auten-ticación es correcta, el servidorenvía al autenticador un mensajeRADIUS-Access-Accept, que auto-riza al autenticador a otorgar ac-ceso completo al cliente sobre elpuerto, además de brindar la in-formación inicial necesaria paraefectuar la conexión a la red.

• El autenticador envía un mensa-je EAP-Success al cliente, y abreel puerto de acuerdo con las ins-trucciones del servidor RADIUS.

Figura 8. Diálogo EAPOL-RADIUS.12,16

Suplicante

Conexión al puerto (Alambrado)Asociación (Inalámbrico)

Autenticador

Router, switch,punto de acceso...

ACCESO BLOQUEADO

EAPOL-Start

EAP-Response/Identity

EAP-Response (credentials)EAPOL

EAP-Request/Identity

EAP-Request

EAP-Success

RADIUS-Access-Request

RADIUS-Access-Challenge

RADIUS-Access-Response

RADIUS-Access-Accept

RADIUS

ACCESO OTORGADO

Servidor RADIUS


En el caso del acceso inalámbrico, elservidor RADIUS despacha en elmensaje RADIUS-Access-Accept unjuego de claves WEP dinámicas, quese usarán para cifrar la conexión en-tre el cliente y el punto de acceso. Elservidor RADIUS se encarga de cam-biar esta clave dinámica periódica-mente (por ejemplo, cada cinco minu-tos), para evitar el ataque de rompi-miento de la clave descrito en la sec-ción referente a WEP.

Existen varias variantes del protoco-lo EAP,13 según la modalidad de au-tenticación que se emplee. Se puedehablar de dos grupos de variantes: lasque emplean certificados de seguri-dad, y las que utilizan contraseñas.

Las variantes de EAP que empleancertificados de seguridad son las si-guientes:

• EAP-TLS: Requiere de instalaciónde certificados en los clientes y enel servidor. Proporciona autenti-cación mutua fuerte (es decir, elservidor autentica al cliente y vi-ceversa) y soporta el uso de cla-ves dinámicas para WEP. La se-sión de autenticación entre elcliente y el autenticador se cifraempleando el protocolo TLS(Transparent Layer Substrate).

• EAP-TTLS: Desarrollada porFunk Software y Certicom. Pro-porciona servicios similares aEAP-TLS, con la diferencia de querequiere solamente la instalaciónde un certificado en el servidor.Esto garantiza la autenticaciónfuerte del servidor por parte delcliente; la autenticación del clien-te por parte del servidor se efec-túa una vez que se establece la se-sión TLS, utilizando otro método

tal como PAP, CHAP, MS-CHAPó MS-CHAP v2.

• PEAP: Desarrollado por Micro-soft, Cisco y RSA Security. Fun-ciona de manera parecida a EAP-TTLS, en el sentido de que sola-mente requiere de certificado deseguridad en el servidor. Proveeprotección a métodos más anti-guos de EAP, mediante el estable-cimiento de un túnel seguro TLSentre el cliente y el autenticador.

El empleo de certificados permite unaautenticación fuerte entre cliente yservidor, sin embargo posee tambiénvarias desventajas:

• La administración de los certifi-cados de seguridad puede ser cos-tosa y complicada, especialmenteen los esquemas donde se necesi-tan certificados en los clientes yen el servidor. Es necesario com-prar los certificados a una autori-dad de certificación (CA) conoci-da, o montar una CA propia.

• El diálogo de autenticación es lar-go. Esto ocasiona que el procesosea algo demorado, siendo espe-cialmente molesto para usuariosque tienen que reautenticarse conmucha frecuencia (por ejemplo,usuarios en movimiento que cam-bien de un punto de acceso a otro).

• La manipulación del certificadopuede ser engorrosa para el usua-rio. En muchos casos se elige ins-talar el certificado en la terminaldel usuario, con lo cual, si la ter-minal es robada y el certificado esel único nivel de seguridad que seposee, la seguridad de la red es-taría en riesgo. Otra solución se-ría llevar el certificado en una tar-


jeta inteligente (smart card), loque obligaría a instalar hardwareadicional en las terminales paraleer dichas tarjetas.

Las variantes de EAP que utilizancontraseñas son las siguientes:

• EAP-MD5: Emplea un nombre deusuario y una contraseña para laautenticación. La contraseña setransmite cifrada con el algorit-mo MD5. Su gran inconvenienteconsiste en el bajo nivel de segu-ridad que maneja, ya que es sus-ceptible a ataques de diccionario(un atacante puede ensayar a ci-frar múltiples contraseñas conMD5 hasta que encuentre unacuyo texto cifrado coincida con lacontraseña cifrada capturada an-teriormente). Además, el clienteno tiene manera de autenticar alservidor (no se podría garantizarque el cliente se está conectandoa la red adecuada), y el esquemano es capaz de generar clavesWEP dinámicas. Por estos pro-blemas, EAP-MD5 ha caído endesuso.

• LEAP: Esta variante es propieta-ria de Cisco. Emplea un esquemade nombre de usuario y contrase-ña, y soporta claves dinámicasWEP. Al ser una tecnología pro-pietaria, exige que todos los pun-tos de acceso sean marca Cisco, yque el servidor RADIUS sea com-patible con LEAP.

• EAP-SPEKE: Esta variante em-plea el método SPEKE (SimplePassword-authenticated Expo-nential Key Exchange), que per-mite verificar que tanto clientecomo servidor comparten una in-formación secreta (en este caso,

una contraseña) a través de unmedio inseguro. Se ha comproba-do que el método es muy seguro,aun con contraseñas cortas. Ofre-ce protección contra ataques dediccionario, así como el servicio deautenticación mutua sin necesi-dad de certificados. Muchos pro-veedores lo implementan por serun método de autenticación robus-to y sencillo.

MÉTODO 5WPA (WI-FI Protected Access)WPA14 es un estándar propuesto porlos miembros de la Wi-Fi Alliance(que reúne a los grandes fabricantesde dispositivos para WLAN) en cola-boración con la IEEE. Este estándarbusca subsanar los problemas deWEP, mejorando el cifrado de los da-tos y ofreciendo un mecanismo deautenticación.

Para solucionar el problema de cifra-do de los datos, WPA propone un nue-vo protocolo para cifrado, conocidocomo TKIP (Temporary Key Integri-ty Protocol). Este protocolo se encar-ga de cambiar la clave compartidaentre punto de acceso y cliente cadacierto tiempo, para evitar ataques quepermitan revelar la clave. Igualmen-te se mejoraron los algoritmos de ci-frado de trama y de generación de losIVs, con respecto a WEP.

El mecanismo de autenticación usadoen WPA emplea 802.1x y EAP, que fue-ron discutidos en la sección anterior.

Según la complejidad de la red, unpunto de acceso compatible con WPApuede operar en dos modalidades:

• Modalidad de red empresarial:Para operar en esta modalidad serequiere de la existencia de un


servidor RADIUS en la red. Elpunto de acceso emplea entonces802.1x y EAP para la autentica-ción, y el servidor RADIUS sumi-nistra las claves compartidas quese usarán para cifrar los datos.

• Modalidad de red casera, o PSK(Pre-Shared Key): WPA opera enesta modalidad cuando no se dis-pone de un servidor RADIUS enla red. Se requiere entonces intro-ducir una contraseña compartidaen el punto de acceso y en los dis-positivos móviles. Solamente po-drán acceder al punto de accesolos dispositivos móviles cuya con-traseña coincida con la del puntode acceso. Una vez logrado el ac-ceso, TKIP entra en funciona-miento para garantizar la seguri-dad del acceso. Se recomienda quelas contraseñas empleadas seanlargas (20 o más caracteres), por-que ya se ha comprobado que WPAes vulnerable a ataques de diccio-nario si se utiliza una contraseñacorta.15

La norma WPA data de abril de 2003,y es de obligatorio cumplimiento paratodos los miembros de la Wi-Fi Allian-ce a partir de finales de 2003. Segúnla Wi-Fi Alliance, todo equipo de redinalámbrica que posea el sello “Wi-Fi Certified” podrá ser actualizadopor software para que cumpla con laespecificación WPA.

CONCLUSIONESLa seguridad en las redes inalámbri-cas es una necesidad, dadas las ca-racterísticas de la información quepor ellas se transmite. Sin embargo,la gran cantidad de las redes inalám-bricas actualmente instaladas no tie-nen configurada seguridad alguna, o

poseen un nivel de seguridad muydébil, con lo cual se está poniendo enpeligro la confidencialidad e integri-dad de dicha información.

Existen diversas soluciones paramejorar la seguridad en las redes ina-lámbricas. Su implementación depen-de del uso que se vaya a dar a la red(casera o empresarial), de si es unared ya existente o una nueva, y delpresupuesto del que se disponga paraimplantarla, entre otros factores.

La restricción de acceso mediante di-recciones MAC es insuficiente paracualquier red, dado el gran númerode herramientas disponibles libre-mente para cambiar la direcciónMAC de una tarjeta cualquiera.

El método mediante WEP con claveestática es el mínimo nivel de protec-ción que existe. En una red caserapuede ser suficiente; en una corpora-tiva, el uso de WEP está formalmen-te desaconsejado, por la facilidad conla que se pueden romper las clavesWEP en un entorno de alto tráfico.

El uso de las VPN es una alternativainteresante cuando ya se tiene una redinalámbrica, y no se posee hardwareinalámbrico que soporte el protocolo802.1x. Requiere de la instalación desoftware especializado en los clientesinalámbricos, y de un servidor o unaserie de servidores que manejen lastareas de cifrado de datos, autentica-ción y autorización de acceso.

La alternativa de 802.1x y EAP es laadecuada si los equipos de la red ina-lámbrica se pueden actualizar, o si seva a montar una red nueva. Puedeusarse la solución de WEP con clavedinámica, o la de WPA; ambas ofre-cen un excelente grado de protección.


Finalmente, todo mecanismo de pro-tección de información en una reddebe estar enmarcado dentro de unapolítica de seguridad adecuada. El se-guimiento de una política consisten-te evita que las medidas de protec-ción se vuelvan un obstáculo para eltrabajo habitual con los sistemas deinformación, y garantiza la calidady confidencialidad de la informaciónpresente en los sistemas de la em-presa.

BIBLIOGRAFÍA1. Intel Centrino Mobile Technolo-

gy. http://www.intel.com/pro-ducts/mobiletechnology/

2. 802.11 standards: 802.11b,802.11a, 802.11g: Which one isright for you? http://compnetworking.about.com/cs/wireless80211/a/aa80211standard.htm

3. Warchalking. http://www.warchalking.org

4. Dennis Fisher. Study ExposesWLAN Security Risks. Marzo 12de 2003. http://www.eweek.com/print_article/0,3048,a=38444,00.asp

5. Rob Flickenger. Antenna on theCheap (er, Chip). Julio 5 de2001. http://www.oreillynet.com/pub/wlg/448

6. AirJack. http://802.11ninja.net/airjack/

7. Wellenreiter – WLAN Hacking.http://www.wellenreiter.net/

8. WEPCrack Project Info. http://sourceforge.net/projects/wepcrack

9. AirSnort Homepage. http://airsnort.shmoo.com/

10.Authentication and Privacy. EnANSI / IEEE Standard 802.11,1999 Edition. http://standards.ieee.org/getieee802/download/802.11-1999.pdf , 59-68 pp.

11. Suhdir Nath. 802.1x Overview.Noviembre de 2003 http://www.cisco.com/warp/public/732/Tech/security/docs/8021xoverview.ppt

12. Paul Congdon. IEEE 802.1xOverview Port Based NetworkAccess Control. Marzo de 2000.http://www.ieee802.org/1/files/public/docs2000/P8021XOverview.PDF

13. IEC. EAP Methods for 802.11Wireless LAN Security. http://www.iec.org/online/tutorials/acrobat/eap_methods.pdf

14. Wi-Fi Alliance. Overview: Wi-FiProtected Access. Octubre 31 de2002. http://www.weca.net/OpenSection/pdf/Wi-Fi_Protected_Access_Overview.pdf

15. WPA’s Little Secret. Noviembre 4de 2003. http://www.stargeek.com/item/20270.html

16. Eduardo Tabacman. Seguridaden Redes Wireless. En las memo-rias de la I Jornada de Telemática“Comunicaciones Inalámbricas,Computación Móvil”. ACIS,Bogotá (Colombia), Noviembre 13y 14 de 2003.


17. Nikita Borisov, Ian Goldberg,David Wagner. Security of theWEP algorithm. http://www.isaac.cs.berkeley.edu/isaac/wep-faq.html

18. Wireless LAN in London. Enero26 de 2002. http://www.hoobie.net/wlan

CURRÍCULOJuan Manuel Madrid Molina es

Ingeniero de Sistemas de laUniversidad Icesi (1995), Espe-cialista en Gerencia de Informá-tica con concentración en Redesy Comunicaciones de la mismaUniversidad (1999) y candida-

to a Doctor en Ciencias de laComputación de la Universidadde Kansas, con la disertación“Aspectos temporales de perfi-les para búsqueda en la Web”.Ha estado vinculado laboral-mente con la Universidad Icesidesde 1994, y desempeñó hasta1999 funciones de soporte téc-nico a sistemas, diseño, puestaen marcha y administración dela red institucional. En la actua-lidad es profesor de tiempo com-pleto del Departamento de Re-des y Comunicaciones y direc-tor del programa de IngenieríaTelemática.


Estructura básica del proceso unificadode desarrollo de software


Robin Alberto Castro GilUniversidad Icesi

[email protected]

ABSTRACTFor a long time, the traditional water-fall model has been used in softwaredevelopment. Over this time it hasdemonstrated that it does not reflectproperly the inherent complexity ofthe software development process.The problems that this model pre-sents stem from its structure: a se-quence of large stages that have com-plete documentation as a milestonebefore being able to continue to thefollowing stage.

To solve this problem it is neccesaryto use iterative and incremental me-thods that together with other keypractices, such as risk managementand the adaptable planning, provide

a natural guidance to the softwaredevelopment process. IBM’s RUP istaken into special consideration. RUPis based on the spiral model and or-ganizes iterations into stages andphases in order to obtain a more so-lid, clear, and adjustable structure ofthe particular needs of every organi-zation.

This article aims to describe iterati-ve development iterative in generaland the advantages that its use offersin software develoment processes.

KEYWORDSSpiral Model, Iterative Development,Rational Unified Process.


RESUMENDurante mucho tiempo se ha utiliza-do el tradicional modelo en cascada,el cual ha demostrado que no reflejaadecuadamente la complejidad inhe-rente al proceso de desarrollo de soft-ware. Los problemas que presenta estemodelo nacen de su propia estructu-ra, al ser una secuencia de grandesetapas que requieren como hitos ladocumentación completa antes de con-tinuar con la siguiente etapa.

Para solucionar este problema sedebe hacer uso de métodos iterativose incrementales, que unidos a otrasprácticas claves como la orientaciónal manejo de riesgos y la planeaciónadaptable, permiten de forma natu-ral guiar adecuadamente el proceso

de desarrollo de software. En espe-cial se considerará el RUP1 de IBM,basado en el modelo en espiral queorganiza las iteraciones por etapas yfases para obtener una estructuramás sólida, clara y ajustable a lasnecesidades particulares de cada or-ganización.

Este artículo tiene como objetivo des-cribir en forma general el desarrolloiterativo, y las ventajas que ofrece suutilización en los procesos de desarro-llo de software.

PALABRAS CLAVESModelo en espiral, desarrollo iterati-vo, proceso unificado de rational

Clasificación: B

1. RUP: Rational Unified Process de IBM.


INTRODUCCIÓNEn los proyectos de tecnología se hanincorporado paulatinamente los cam-bios en los métodos de ingeniería,pero, desafortunadamente, no se hahecho lo mismo en su administración.A continuación se mostrará una vi-sión general de los cambios en los ci-clos de vida de los proyectos, señalan-do sus ventajas, desventajas y el porqué de dicha evolución.

Existe un conjunto de modelos de ci-clo de vida en la gerencia de proyec-tos que han evolucionado desde el tra-dicional modelo en cascada, pasandopor algunas propuestas de mejora-miento como son el caso de cascadascon fases solapadas o cascada consubproyectos. Estos modelos no per-miten una identificación temprana delos riesgos, los cuales pueden apare-cer en las etapas finales del desarro-llo o implantación, momento en queun cambio en el diseño del producto,en la arquitectura del sistema o en lainfraestructura de software y hard-ware puede llevar al fracaso comple-to del proyecto.

Estos modelos son muy prácticos paraproyectos pequeños y con muy bajosniveles de riesgos, tales como proyec-tos de nuevas versiones de algún soft-ware existente, donde haya requeri-mientos claros y cuya arquitectura einfraestructura de software y hard-ware no van a cambiar mucho respec-to a la versión anterior.

Como respuesta al problema presen-tado por los modelos anteriores, losciclos de vida evolucionaron y se hanpresentado propuestas como el mode-lo de entrega por etapas y el de en-trega evolutiva. Cada uno de ellosadicionó mayores niveles de comple-jidad a la administración, pero ase-guran poseer un marco de trabajo

más sólido y ajustado para el desarro-llo de proyectos con niveles modera-dos de riesgo. Se requería de todas for-mas un modelo de ciclo de vida de pro-yectos que trabajara adecuadamentecon niveles altos de riesgo, así que sedesarrolló el modelo en espiral. Estemodelo tiene como objetivos la identi-ficación de los riesgos para determi-nar la viabilidad del proyecto y defi-nir planes de manejo para garantizardesde las fases iniciales la eliminacióno mitigación de los riesgos donde esmenos costoso y la entrega desde lasfaces iniciales de productos probados,lo que permite un proceso continuo depruebas y retroalimentación.

PRÁCTICAS CLAVESDEL PROCESO DE DESARROLLODE SOFTWARE

• Desarrollo iterativoEl desarrollo iterativo es un métodode construcción de productos cuyo ci-clo de vida está compuesto por un con-junto de iteraciones, las cuales tienencomo objetivo entregar versiones delsoftware. Cada iteración se conside-ra un subproyecto que genera produc-tos de software y no sólo documenta-ción, permitiendo al usuario tenerpuntos de verificación y control másrápidos e induciendo un proceso con-tinuo de pruebas y de integracióndesde las primeras iteraciones.

Las iteraciones están compuestas porel conjunto de disciplinas o activida-des ya conocidas en el proceso de de-sarrollo de software. Estas son la es-pecificación de requerimientos, elanálisis y diseño, las pruebas, la ad-ministración de la configuración y elproceso de gerencia de proyectos. Enla Figura 1 se muestra gráficamentela relación existente entre las disci-plinas o actividades y las iteraciones.


Figura 1. Disciplinas a través de las iteraciones.

Fuente: IBM RUP Rational Unified Process®Versión 2002.05.00. Rational Software Corporation.

Phases

Inception Elaboration Construction Transition

Initial Elab No. 1 ElabNo. 2

ConstNo. 1

ConstNo. 2

ConstNo. N

TranNo. 1

TranNo. 2

Iterations

Project Management

Environment

Configuration& Change Mgmt

Deployment

Test

Implementation

Analysis & Design

Requirements

Disciplines

Business Modeling

A través del tiempo se han formali-zado algunos métodos de desarrolloiterativo, tales como Evo, MicrosoftSolution Framework, modelo en es-piral WinWin y UP. Este artículo secentrará en el método de desarrolloiterativo conocido como Proceso Uni-ficado o UP.

• Orientación al manejo del riesgoCada proyecto tiene asociado intrín-secamente un conjunto de riesgos querequieren un plan de manejo clara-mente establecido, documentado y

con una implementación eficaz. Deesta manera se pretende evitar posi-bles retrasos en los tiempos de entre-ga, problemas de calidad en el pro-ducto o en el peor de los casos, quepuedan afectar la culminación delproyecto. Estos procesos pueden sertan complejos y elaborados como laimportancia del proyecto lo requiera.

En las etapas iniciales se implemen-tan las funcionalidades con mayorexposición al riesgo y las de mayorcomplejidad, mejorando la posibilidadde éxito del proyecto.


Figura 2. Perfiles de riesgo.

Fuente: Principles of Managing Iterative Development v.2.0 Rational Software Cor-poration.

En la fase inicial del proyecto, el ni-vel de exposición al riesgo en ambosmodelos es casi igual, pero en las fa-ses siguientes es completamente di-ferente para cada modelo (Ver Figu-ra 2). Este comportamiento se debeal período de exploración de riesgosdel modelo en espiral, donde se iden-tifican los riesgos, se priorizan y sedefine un plan de manejo para miti-garlos. Se procede a la fase de elabo-ración donde se implementan aque-llos casos de uso que atacan los ries-gos de más alta prioridad, lo cual sedenomina período de resolución deriesgos. Al final de esta fase se debetener definida la arquitectura del sis-tema, así como la infraestructura enla que se soportará.

• Orientación al clienteCuando se inicia un proyecto de de-sarrollo de software se conoce la im-portancia de la participación delcliente para lograr su terminaciónexitosa, pero usualmente cometemosel error de olvidar esta norma bási-ca, lo que implica que la participacióndel cliente se restringe al inicio y fi-nalización del proyecto, lo que en lamayoría de los casos produce un altogrado de insatisfacción en el usuario,al no obtener el producto con las es-pecificaciones esperadas.

El cliente es quien realmente conoceel valor que aportará el producto queestá siendo desarrollado y puede de-finir las prioridades desde la perspec-tiva organizacional. Esto quiere de-


cir que es necesario contar con suparticipación en el proceso de plani-ficación de las fases y de las iteracio-nes. Posteriormente se requiere suparticipación en cada iteración paraproveer retroalimentación tempranaal equipo de desarrolladores, garan-tizando el cumplimiento de las expec-tativas que tiene, además de ofrecer-le una visibilidad permanente delestado del proyecto, asegurando sucompromiso para terminarlo exitosa-mente.

Se debe tener en cuenta que el clien-te no se interesa por los aspectos téc-nicos de alta complejidad y riesgo,razón por la cual se debe combinaresta práctica con una orientación almanejo del riesgo.

• Desarrollo evolutivoCuando se trabaja con una especifi-cación de requerimientos monolítica,se cae en el error de creer que se com-prende completamente el conceptodel producto sin haberlo validado conel cliente con algo más que documen-tos y modelos abstractos. Este proce-so inicia con un concepto poco clarodel producto a construir, y sólo se tie-ne claridad en la medida que se vayadesarrollando y verificando el produc-to con el cliente. Este tipo de proyec-tos se asemejan más al patrón que

siguen los proyectos de investigacióny desarrollo de nuevos productos.

Estas prácticas claves en el desarro-llo de software son implementadas enalgunos métodos tales como Evo2, elmodelo en espiral y el proceso unifi-cado (UP), siendo los dos últimos losque mayor trascendencia han tenidoy serán explicados a continuación.

MODELO EN ESPIRALEl modelo en espiral se centra en al-gunas prácticas fundamentales deldesarrollo de software, tales como laorientación al manejo de riesgos, laorientación al cliente y el desarrolloiterativo (Ver Figura 3). El modelo seorganiza en un conjunto de iteracio-nes que pueden considerarse a sí mis-mas como pequeños proyectos quesiguen el ciclo de vida completo. Lasprimeras iteraciones tienen como ob-jetivo identificar los riesgos del pro-yecto para determinar su viabilidad,y en caso de seguir adelante, definirun plan de manejo para mitigarlos oeliminarlos. Adicionalmente, el usua-rio participa activamente en la prio-rización de los casos de uso a desa-rrollar y en el proceso de pruebas, conlo cual se logra obtener una funcio-nalidad estable y operativa desde lasprimeras iteraciones del proyecto.

2. Evo, “Evolutionary Project Management”. Probablemente el primer método Iterativo e Incremental deDesarrollo de Software, publicado en 1976. Creado por Tom Gilb. Fuente: Agile & Iterative Development[Graig Larman].


Figura 3. Mapa conceptual del modelo en espiral.

Orientado al

Riesgos Plan de Manejo Procesos

PuedeImplementar

una

Estrategia

Entrega unconjunto

Productos

Planifica

Fuente: Barry Boehm, “A Spiral Model of Software Development and Enhancement”, ACMSIGSOFT Software Engineering Notes, August 1986.

El modelo en espiral tiene muchasventajas respecto a los modelos ante-riores por su orientación a la resolu-ción temprana de riesgos, por la defi-nición de la arquitectura del sistemaen sus fases iniciales y por su proce-so continuo de verificación de la cali-dad. En términos generales este mo-delo tiene un nivel alto de compleji-dad y requiere mucha destreza admi-nistrativa y experiencia por parte delgerente del proyecto y su grupo detrabajo para manejarlo adecuada-mente.

Este modelo es ideal para manejarproyectos que requieran la incorpo-

ración de nuevas tecnologías, o paradesarrollar productos completamen-te nuevos o con un nivel alto de ines-tabilidad de los requerimientos. Tí-picamente se maneja una iteracióninicial donde se define el alcance delproyecto, se identifican y priorizan losriesgos y se realiza el modelo de ca-sos de uso inicial para determinar quécasos de uso definirán la arquitectu-ra del sistema. Con la informaciónanterior se procede a definir el plande manejo de riesgos según su priori-dad, así como los casos de uso queserán implementados en las siguien-tes iteraciones (Ver Figura 4).


Figura 4. Modelo en espiral.

Fuente: Desarrollo y Gestión de Proyectos Informáticos. Steve McConnell, McGraw Hill.

Determinar objetivos,alternativas

y restricciones

Acordar unenfoque para

la próximaiteración

Revisión

Partición

Cod

ifica

ción

Planificarla siguiente

iteración

Plan derequerimientos,plan del ciclo

de vida

Plan dedesarrollo

Plan de integracióny prueba

Costo acumulado

Análisisde riesgos

Análisisde riesgos

Análisisde riesgos

Análisisde riesgo

Prototipo 1

Conceptode

funciona-miento

Validación derequerimientos

Validacióny verificación

del diseño

Prototipo 2

Simulaciones

Requeri-mientos

delsoftware

Prototipo 3

Modelos

Diseñodel

productosoftware

Prototipooperativo

Pruebas

Diseñodetallado

Pruebade

unidades

Integracióny prueba

Prueba deaceptación

Entregar

Identificary resolver riesgos

Evaluaralternativas

Desarrollar las entregasde la iteración y comprobar

que son correctas

ITERACIONESUna iteración es una secuencia deactividades dentro de un plan esta-blecido, con unos criterios claros deevaluación, que se organiza con elpropósito de entregar parte de la fun-cionalidad del producto. En las pri-meras iteraciones se desarrollan oimplementan los casos de uso que tie-nen mayor complejidad y que llevaninherente un alto nivel de riesgo quepuede afectar el éxito del proyecto. Deesta forma, con cada iteración que serealiza, los riesgos del proyecto se re-ducen acorde con el plan establecido,el cual está en permanente revisión

para monitorear la posible apariciónde nuevos riesgos y ajustarlo si esnecesario.

La selección de los casos de uso paracada iteración se hace teniendo encuenta cuál es el mínimo conjunto deellos que se requiere para implemen-tar la funcionalidad que mayor ries-go tenga. Se debe realizar este proce-so hasta que la lista de riesgos hayasido cubierta completamente.

Cada iteración puede tener uno o va-rios propósitos, lo cual determina laduración de la misma; a su vez se eje-cutan varios procesos que van desde


la especificación de requerimientoshasta las pruebas de unidad e inte-gración, lo cual se asimila a un ciclode vida en cascada. Adicionalmente,al final de cada iteración se debenevaluar los resultados del trabajo yse planea detalladamente la siguien-te iteración.

INCORPORANDO EL PROCESOUNIFICADO DE DESARROLLODE RATIONALLa concepción de un sistema de infor-mación va mucho más allá de levan-tar los requerimientos, elaborar unconjunto de modelos y comenzar a pro-gramar. Esta concepción limitada hapermitido que durante años no poda-mos hacer uso adecuado de los concep-tos y las herramientas con los que con-tamos. En este punto podemos consi-derar que la definición de la arquitec-tura del software se convierte en el ejeorientador que permite controlar eldesarrollo iterativo e incremental delsistema, a través de su ciclo de vida.Esta arquitectura se define en las pri-meras fases del proyecto, básicamen-te en la de elaboración, y se refina através de todo el proyecto.

El RUP se fundamenta en seis prác-ticas: el desarrollo iterativo, la admi-nistración de requerimientos, la ar-quitectura basada en componentes,en el modelamiento visual, en la ve-rificación continua de la calidad y laadministración del cambio. Estas seisprácticas orientan el modelo y conellas se pretende solucionar muchosde los problemas asociados al soft-ware. Adicionalmente hay muchosaspectos de diseño que son bien co-nocidos, pero que en realidad han sidomuy poco implementados en los pro-yectos de software; estos son: facili-

dad de uso, modularidad, encapsu-lamiento y facilidad de manteni-miento. Es necesario entonces defi-nir una arquitectura sólida basadaen componentes, para construir me-jores y más flexibles soluciones desoftware para las necesidades orga-nizacionales.

Los cambios en un proyecto no pue-den ser detenidos dado que la evolu-ción del entorno de cada organizaciónes continua, pero sí pueden ser ad-ministrados de manera que su impac-to pueda ser estimado para determi-nar si dicho cambio se incluye o no ysi el proyecto debe ser reajustado.Cada cambio en el proyecto debe te-ner especificado cuándo y cómo se vaa realizar, quién lo va a hacer y quéproductos se ven involucrados en esecambio. En ese punto es donde el con-trol de cambios y la trazabilidad delos componentes a través de los di-versos modelos adquieren una granimportancia.

Existen algunos aspectos que se de-ben tener en cuenta para desarrollarexitosamente un proyecto. A conti-nuación se enumeran algunos deellos:

1. Se debe tener definida claramen-te la metodología de trabajo decada fase del proceso del desarro-llo de software, en especial las fa-ses de administración de requeri-mientos y control de cambios, loscuales son los eslabones más dé-biles del proceso de desarrollo desoftware en nuestras organizacio-nes. La responsabilidad de defi-nir, documentar y velar que secumpla a cabalidad la metodolo-gía de trabajo es del grupo de in-geniería de procesos.


2. La participación activa de losusuarios y los acuerdos en los tiem-pos pactados, teniendo en cuentalos datos generados de los proce-sos de estimación y planificación,son responsabilidad del jefe delproyecto, pero deben ser elabora-dos con integrantes claves del equi-po del proyecto.

3. El Grupo SQA3 debe definir, docu-mentar y actualizar el proceso deaseguramiento de la calidad delsoftware, gestionar los recursos ne-cesarios para que sea operativodesde el comienzo del proyecto,entregar el plan de calidad y velarpor su cumplimiento a lo largo delciclo de vida del proyecto.

4. El proceso de incorporación y uti-lización de nuevas tecnologías esquizás uno de los aspectos más crí-

ticos dentro del proyecto y de ma-yores riesgos. La definición de unametodología de administración delcambio tecnológico, clara y muypráctica, facilitaría considerable-mente el trabajo realizado en lafase de elaboración, lo cual permi-tiría determinar la viabilidad de laincorporación de dicha tecnologíaen el proyecto.

Teniendo en cuenta los aspectos men-cionados previamente, Rational querecientemente fue comprada por IBM,elaboró un marco de referencia parael proceso de desarrollo de softwarebasado en el modelo en espiral. Estemétodo se conoce como RUP “Ratio-nal Unified Process”. Para una mejororganización, el RUP agrupa las ite-raciones en etapas y fases que facili-tan la administración del proyecto (VerFigura 5).

Figura 5. Mapa conceptual del Proceso Unificado de Rational

Fuente: Principles of Managing Iterative Development v.2.0 Rational Software Corporation

3. SQA: Grupo de Aseguramiento de la Calidad.

ProcesoUnificado

Basado en

Modeloen Espiral

Dividido en

Etapas

Estas son

Ingeniería

Compuesto por

Fases

Producción

Compuesto por

Fases

Estas son

Concepción Elaboración

Orientada a Organizada en Orientada a

Estas son

Construcción Transición

Organizada en Orientada a Organizada en Orientada a

Definiciónde Alcance

Reducciónde Riesgos IteracionesIteraciones Desarrollo de

la Funcionalidad IteracionesEntregas

del Producto


ETAPAS DEL PROCESOUNIFICADO

1. Etapa de ingenieríaEsta etapa agrupa las fases de con-cepción y de elaboración, lo que bá-sicamente le da por objetivos la con-ceptualización del sistema y el di-seño inicial de la solución del pro-blema.

Se inicia el proceso de administraciónde los requerimientos con la identifi-cación y especificación de casos deusos, así como el proceso de asegura-miento de la calidad a través de loscasos de prueba.

Se identifican los riesgos y se esta-blece su plan de manejo, se ajusta eseplan según la tabla de priorización deriesgos y la de casos de usos vs. ries-gos, para determinar en qué orden yen qué iteraciones se desarrollaránlos artefactos de software que son lasolución a los casos de uso.

Se identifican los recursos necesa-rios, tanto económicos como huma-nos, acordes con las necesidades delproyecto. Se da comienzo al procesode estimación y planificación iniciala un nivel macro para todo el pro-yecto y posteriormente se realiza unaestimación detallada de tiempos yrecursos de las fases de concepcióny elaboración.

1.1. Fase de concepciónEsta fase tiene como propósito defi-nir y acordar el alcance del proyec-to con los patrocinadores, identifi-car los riesgos asociados al proyec-to, proponer una visión muy gene-ral de la arquitectura de software yproducir el plan de las fases y el deiteraciones.

1.1.1 Planeación de las fases y de lasiteraciones

A partir del modelo de casos de uso yde la lista de riesgos, se puede deter-minar qué casos de uso deben imple-mentarse primero para atacar losriesgos de mayor exposición. Con baseen la información previa se realiza elproceso de planificación general y unplan de trabajo detallado para la si-guiente fase, así como el plan para lasiguiente iteración.

Se debe establecer una relación cla-ra y directa entre los casos de uso ylos casos de prueba para facilitar queel proceso de aseguramiento de lacalidad del software se ejecute ade-cuadamente. El plan de pruebas debeplanearse en esta fase, ejecutarsedesde la primera iteración de la fasede elaboración y refinarse sucesiva-mente durante el ciclo de vida delproyecto.

1.2. Fase de elaboraciónLos casos de uso seleccionados paradesarrollarse en esta fase permitendefinir la arquitectura del sistema, serealiza la especificación de los casosde uso seleccionados y el primer aná-lisis del dominio del problema, se di-seña la solución preliminar del pro-blema y comienza la ejecución delplan de manejo de riesgos, según lasprioridades definidas en él.

Al final de la fase se determina la via-bilidad de continuar el proyecto y sise decide proseguir, dado que la ma-yor parte de los riesgos han sido mi-tigados, se escriben los planes de tra-bajo de las etapas de construcción ytransición y se detalla el plan de tra-bajo de la primera iteración de la fasede construcción.


2. Etapa de producción

En esta etapa se realiza un procesode refinamiento de las estimacionesde tiempos y recursos para las fasesde construcción y transición, se de-fine un plan de mantenimiento paralos productos entregados en la eta-pa de ingeniería, se implementan loscasos de uso pendientes y se entre-ga el producto al cliente, garantizan-do la capacitación y el soporte ade-cuados.

2.1. Fase de construcciónEl propósito de esta fase es comple-tar la funcionalidad del sistema, paraello se deben clarificar los requeri-mientos pendientes, administrar elcambio de los artefactos construidos,ejecutar el plan de administración derecursos y mejoras en el proceso dedesarrollo para el proyecto.

2.2. Fase de transiciónEl propósito de esta fase es asegurarque el software esté disponible paralos usuarios finales, ajustar los erro-res y defectos encontrados, capacitara los usuarios y proveer el soportetécnico necesario. Se debe verificarque el producto cumpla con las espe-cificaciones entregadas por las perso-nas involucradas en el proyecto alinicio del mismo.

CONCLUSIONESEn este artículo se presenta una vi-sión general de algunos métodosorientados por las prácticas de desa-rrollo iterativo y manejo del riesgo.

Este tipo de métodos no han sido apli-cados en muchas de las empresas lo-cales, probablemente por su comple-jidad de administración, desaprove-chando sus considerables ventajas

respecto a los métodos tradicionales.Es necesario entonces desarrollarmecanismos de apropiación tecnoló-gica más eficaces, que permitan man-tener actualizadas nuestras prácticasorganizacionales.

Los marcos de referencia aquí men-cionados definen qué debe hacerse yen algunos casos cómo hacerlo. El tra-bajo del gerente de proyectos consis-te en identificar cuál marco de refe-rencia se ajusta a su organización yrealizar el proceso de apropiación dela metodología y asimilación de lasguías de trabajo al interior del equi-po del proyecto y del área de infor-mática.

BIBLIOGRAFÍACraig Larman. Agile and iterativedevelopment: a manager ’s guide.Addison Wesley, 2004.

Ivar Jacobson, Grady Booch y JamesRumbaugh. The Unified SoftwareDevelopment Process. Rational Soft-ware Corporation. Addison-Wesley,1999.

Steve McConnell. Desarrollo y Ges-tión de Proyectos Informáticos.McGraw Hill, 1996.

Rational Software Corporation. Prin-ciples of Managing Iterative Develo-pment v.2.0. 2001.

Project Management Institute PMI.A Guide to the Project ManagementBody of Knowledge PMBOK® Guide.2000 Edition.

Rational Software Corporation. RUPRational Unified Process®Version2002.05.00, 2002.

Sandra Victoria Hurtado Gil. Repre-sentación de la arquitectura de soft-ware usando UML. Revista Sistemas


& Telemática No. 1 - Enero-Junio2003. Universidad ICESI.

CURRÍCULORobin Alberto Castro Gil es Inge-

niero de la Universidad Icesi,realizó la especialización en

Gerencia de la Producción en laUniversidad Icesi. Actualmentees Jefe de la Oficina de Desarro-llo de Sistemas de la Universi-dad Icesi y presidente de la Aso-ciación de Usuarios de Oracle deColombia-ASUOC.


Realimentación como paradigma deintegración conceptual en educación


ABSTRACTFeedback is a key phenomena andconcept in Control theory and syste-mic thinking. Its importance and his-toric evolution in different areas ofendeavor are analized.

KEYWORDSSystemic thinking, Control Theory,Feedback.

RESUMENLas implicaciones y la evolución his-tórica del fenómeno de retroalimen-

tación, en la estructuración de la Teo-ría de Control, y en la ejecución delpensamiento sistémico en diferentesáreas del saber son analizadas.

PALABRAS CLAVESPensamiento sistémico, teoría de con-trol, retroalimentación.

Clasificación: B

Daniel Martín Vega [email protected]


INTRODUCCIÓNEn la solución de los múltiples pro-blemas en el mundo se utilizan enfo-ques interdisciplinarios, los cualesrequieren de fenómenos y herramien-tas integrativos, que estructuran laplasticidad funcional del profesionalmoderno, entrenado mediante la im-plementación de los nuevos desarro-llos curriculares de pensamiento crí-tico, integrativo y de aprendizaje ac-tivo.

El análisis del fenómeno de retroali-mentación, su implementación con-ceptual en el contexto de su existen-cia en el mundo biológico como baseestructural adaptativa en la sobrevi-vencia de los seres, su implementa-ción en la ejecución del pensamientosistémico en el desarrollo de los mo-delos empresariales y educativos, enun marco evolutivo histórico, estruc-turan la reflexión a ejecutar.

Los sistemas vivientes se caracteri-zan por una variedad de mecanismosde control y regulación, que involu-

cran múltiples sistemas de “retroali-mentación”, los cuales garantizan unestado estacionario del sistema, estetipo de mecanismos nunca se encuen-tra en el resto de la naturaleza “noviviente”. La capacidad de “autorre-gulación”, para mantener un sistemacomplejo viviente en estado estacio-nario es lo que se denomina homeos-tasis y/o retroalimentación.2

El pensamiento sistémico es una dis-ciplina para ver totalidades. Es unmarco para ver interrelaciones en vezde cosas, para ver patrones de cam-bio en lugar de “instantáneas” está-ticas. Sus herramientas y técnicasespecíficas se originan en dos ramifi-caciones: el concepto de “realimenta-ción” de la cibernética y la teoría del“servomecanismo” de la ingenieríaque se remonta al siglo XIX, con apli-caciones durante los últimos cuaren-ta años, en una amplia gama de sis-temas empresariales, urbanos, econó-micos, ecológicos y biológicos.1

En qué consiste el fenómeno de retroalimentación (Figura 1).

Figura 1. Un ejemplo sencillo de la vida cotidiana, ilustrativo del fenómenode retroalimentación.


En todo sanitario es preciso mante-ner en un volumen de agua su nivelapropiado sin rebosar el recipiente,para lograr esto debe definirse siem-pre un equilibrio entre el flujo de en-trada y salida de agua, el sistemaposee una estructura de control cons-tituida por una válvula con su vari-lla y flotador, los cuales cuando el flu-jo de entrada aumenta elevándosetransitoriamente el nivel de agua seaumenta el flujo de salida hasta igua-lar al de entrada, con el objeto de lle-gar a un nuevo estado estacionarioen el cual se minimiza la pertur-bación en el nivel de agua del reci-piente.

Esta situación, cuyo objeto es mante-ner el nivel de una variable constan-te en procesos de aporte y consumo,

se estructura en el entorno de siste-mas biológicos, empresariales y edu-cativos. La formalizamos mediante elanálisis de las Figuras 2 y 3.

El nivel de agua es nuestra variableregulada, la cual es incrementadatransitoriamente mediante una per-turbación continua en el tiempo (in-cremento del flujo de entrada, Figu-ra 2), generándose así una señal deerror (diferencia entre el valor desea-do de su nivel y el actual). El sistemade retroalimentación negativo, cons-tituido por la estructura de controldescrita minimiza el error, incremen-tando el eflujo, definiendo un nuevoestado estacionario, en el cual el apor-te (influjo) es igual al consumo (eflu-jo) y el nivel de agua retorna a unvalor cercano al de referencia.

Figura 2. Elementos dinámicos de una respuesta compensatoria.

En este contexto podemos describirel patrón general y propósito de lossistemas de control con retroalimen-tación, bien sean biológicos o diseña-dos por el hombre. En la Figura 3utilizamos la notación del “diagramade bloque”, un instrumento descrip-tivo en análisis de sistemas. En esta

notación cada proceso unitario (plan-ta por ejemplo) está representado porun bloque con una entrada yc y unasalida y. La salida (variable depen-diente) depende de la entrada (varia-ble independiente) de acuerdo conuna “ley de sistemas”, la cual puedeser expresada en términos verbales,


matemáticos o gráficos. Las interac-ciones entre estos “procesos unita-rios” pueden ser definidas por co-nexiones entre los bloques.

Utilizando esta nomenclatura pode-mos reconocer dos bloques principa-les o procesos unitarios en un sistemade control con retroalimentación: 1)Un sistema controlado (o planta), y 2)Un sistema controlador (controlador);ellos están organizados en un “circui-to cerrado” o de “retroalimentación”.

El objetivo de esta organización esmantener la salida de la planta (va-riable regulada, y) igual o al menoscercana a un valor deseado (yi) a pe-sar de perturbaciones (yd) las cualestratan de oponerse a este objetivo.Para lograr este propósito, la infor-mación del valor de y es medida y “re-troalimentada” al controlador dondees comparada a un valor de referen-cia yi generándose una señal de error,ye=yi-y

Figura 3. Diagrama de bloques de un sistema de retroalimentación negativa.

El propósito en un sistema de retroa-limentación negativa es minimizareste error. Para lograrlo el controla-dor transforma ye en una señal decontrol yc, la cual origina que la plan-ta cambie su salida en una direcciónapropiada para reducir ye. Por con-siguiente, cualquier desviación de ycon relación a yi es “automáticamen-te” corregida, bien sea totalmente(control integral), o parcialmente(control proporcional).

Si el sistema está diseñado para man-tener y cercana a un yi constante(punto de referencia), se le denominaregulador; si va a seguir un yi varia-

ble dinámicamente, se le denominaservomecanismo. Un ejemplo fami-liar de lo primero es el sistema decontrol de la temperatura de un cuar-to, y de lo último el sistema de con-trol de proyectiles teledirigidos.

En los sistemas de control físico he-chos por el hombre, todos los elemen-tos ilustrados en la Figura 3 y descri-tos anteriormente, pueden ser explí-citamente identificados. Sabemoscómo ajustar el punto de referenciaen un termostato, y el proceso de res-ta de y de yi para generar ye es eje-cutado por un componente físico es-pecífico, el “comparador” el cual po-


demos identificar. Incidentalmente,es esta resta (o inversión de signo al-rededor del circuito) la que estructu-ra la retroalimentación “negativa” ygarantiza que los ajustes en la varia-ble regulada se ejecuten en la direc-ción correcta.

En los sistemas de control biológicoses prácticamente imposible identifi-car un comparador. Podemos definircuantitativamente un punto de refe-rencia implícito, como valor operacio-nal normal del conjunto de paráme-tros del sistema, pero no sabemosdónde está y cómo ajustarlo operacio-nalmente. En forma análoga, se pue-de identificar una inversión de signo

alrededor del circuito de control, el“sine qua non” de la retroalimenta-ción negativa, el cual no es ejecutadopor un simple comparador, sino másbien por una relación particular deentrada-salida de algún componenteparticular, bien sea de la planta o delcontrolador, lo que destaca la comple-jidad en el diseño de sistemas de con-trol biológicos.3

Aunque hemos hecho énfasis en re-troalimentación negativa, ¿cuál es ladiferencia fundamental entre un sis-tema de retroalimentación negativay uno positivo?

Figura 4. Un ejemplo de retroalimentación positiva.


Sterman J.D.4 presenta la situaciónde un criadero de pollos en donde laestructura del sistema de retroali-mentación define una dinámica, enla cual un incremento en el númerode huevos puestos por las gallinasgenera un incremento en el númerode nacimientos de pollos en el siste-ma de reproducción (Figura 4).

Ilustrándose así el hecho fundamen-tal dinámico que mientras en un sis-tema de retroalimentación “positiva”se refuerza no obteniéndose un nue-vo estado estacionario, en el de re-troalimentación “negativa” existeautocorrección, hacia un nuevo esta-do estacionario, en presencia de unaperturbación.

Por consiguiente, los sistemas auto-máticos de control con realimentaciónse caracterizan por:

1. Su propósito es realizar en formaautomática una acción de gobier-no, manteniendo una variable re-gulada cercana a su punto de re-ferencia en estado estacionario,cuando es retroalimentación ne-gativa.

2. El sistema opera en circuito (lazo)cerrado.

3. El sistema incluye un proceso sen-sor de la variable regulada y unproceso comparador de medidacon su punto de referencia, comoelementos funcionalmente sepa-rables del resto.

Cuál ha sido la evolución histó-rica de la retroalimentaciónTodo ser vivo es un sistema autorre-gulado que debe su existencia, su es-

tabilidad y la mayor parte de su con-ducta a los mecanismos de realimen-tación que lleva implícitos. Conside-rando la universalidad del conceptoy el hecho de que la operación de rea-limentación se puede observar en unavariedad de fenómenos, por ejemplodesde los ciclos de población de losanimales hasta los altibajos que su-fre el mercado de valores, resulta cu-rioso que el estudio teórico del con-cepto de control por realimentaciónsucediese tan tarde en el desarrollode la ciencia y de la tecnología.

Hablar de sistemas de control auto-mático significa hablar de realimen-tación. En palabras de Norbert Wie-ner5 “realimentación es un método decontrolar un sistema reinsertando enél los resultados de su comportamien-to anterior”. Desde un punto de vistamás restrictivo diremos que un siste-ma de control realimentado o un sis-tema de control en lazo cerrado esaquel que tiende a mantener una re-lación prevista de una variable delsistema con otra, comparando funcio-nes de estas variables y utilizando sudiferencia como medio de control.

Así como se emplea la realimentaciónde forma inconsciente, podemos de-cir que las primeras evidencias de laactividad consciente del hombre en elcampo de control automático las te-nemos en los sistemas de regadíoempleados en Babilonia 2000 añosantes de Cristo.Los orígenes y líneasfundamentales del desarrollo de larealimentación se ilustran por el di-seño de tres dispositivos: 1) Los anti-guos relojes de agua. 2) Los termos-tatos. 3) Los mecanismos para con-trolar los molinos de viento.


Figura 5. Regulador de flotación del nivel de agua. I. Polzuvov (1765).

En la segunda mitad del siglo XVIII,la aplicación del concepto de reali-mentación en la tecnología se mani-fiesta como una verdadera explosión.¿Qué acontece realmente para quesuceda este fenómeno? Factores tec-nológicos no fueron probablementedecisivos; casi todos los dispositivosde regulación del siglo XVIII se podíanhaber construido ya en el Renaci-miento. El argumento es que progre-sos en otros campos de la tecnologíahabían creado la necesidad de dispo-sitivos reguladores e iniciado así unagran actividad inventiva por parte deingenieros más progresistas en Ingla-terra, Francia y Rusia; la “revoluciónindustrial” se manifiesta en una mul-

titud de inventos e innovaciones encampos tan diversos como la agricul-tura, el transporte, el comercio, etc.

Por ejemplo, se puede apuntar el pro-greso en el suministro doméstico deagua, que necesitaba reguladores deflotación (Figura 5).

Un desarrollo análogo tuvo lugar enel campo de la política económica. Elmercantilismo, sustentado por Col-bert, enseña que para una nación elcamino hacia la prosperidad es unaplanificación cuidadosa de su políti-ca económica, dirigida principalmen-te por políticos de gran competencia.En contraste con esto, el sistema eco-nómico del liberalismo, formulado en


1776 por Adam Smith en su capitalobra “Wealth of Nations” estaba ba-sado en el postulado de “dejar hacer”;si el Estado se abstiene de toda in-terferencia, la economía automática-mente alcanza el equilibrio en condi-ciones óptimas. En lugar de un con-trol centralizado, la función forzanteen este caso es el propio interés delos individuos participantes en la vidaeconómica. La teoría de Smith eraque las desviaciones de la economíade su estado óptimo automáticamen-te serían corregidas por el sistema demercado libre y la ley de oferta y de-manda. Esta concepción implica conclaridad una relación causal en lazocerrado que es en principio idénticaal lazo cerrado de la realimentación.

En la actualidad se considera que elconcepto de realimentación no estásolamente encuadrado en la estruc-tura de los sistemas de ingenieríasino que universalmente se le reco-noce como un concepto importante yunificador en el marco formal de laciencia. Realimentación es pues unconcepto abstracto que no está ads-crito a ningún medio físico en parti-cular. En tecnología se puede utilizaren sistemas de origen mecánico, eléc-trico, neumático, hidráulico o quími-co, pero su significación principal ymás profunda actual está en que sepuede aplicar en economía, sociología,educación, o biología; los métodosmatemáticos de los sistemas de con-trol son igualmente válidos en todasestas áreas del saber.

Caldera

Vapor

Válvula

Regulador

Máquina

Figura 6. Regulador centrífugo de Watt (1769).

El regulador de Watt (Figura 6) sepuede tomar como punto de partidapara trazar el desarrollo del controlautomático como disciplina científi-ca. La solución del problema de lafluctuación en la velocidad atrajo la

atención de un número importante decientíficos e ingenieros.

Finalmente fue resuelto por J.C.Maxwell6 quien inició así la teoría delos sistemas de control automático


con su trabajo “On governors”. Sucontribución estuvo en reconocer que“la conducta de un sistema de controlautomático en la vecindad de unaposición de equilibrio se podía aproxi-mar por una ecuación diferencial li-neal y por lo tanto su estabilidad sepodía discutir en términos de las raí-ces de una ecuación algebraica aso-ciada”. Maxwell planteó así el proble-ma general de investigar la estabili-dad de un sistema dinámico en fun-

ción de la localización de las raícesde su ecuación característica.

La importancia práctica crecientedel control automático durante elfinal del siglo XIX y comienzos delXX se pone de manifiesto por la con-cesión en 1912 del premio Nobel enFísica al sueco Dalen por su desa-rrollo de reguladores automáticosque se utilizan conjuntamente conlos acumuladores de gas para bali-zas luminosas.

Figura 7. Sistema de control por amplificador (1934) o por computador (1950).

El desarrollo del amplificador de rea-limentación (Figura 7) con el objetode hacer viable “la telefonía a distan-cia” se basó en el famoso trabajo clá-sico de H. Nyquist7 sobre la estabili-dad de amplificadores realimentados,con el cual se abrió una nueva era encontrol automático. Antes de 1932, elenfoque basado en las ecuaciones di-ferenciales había sido una gran he-rramienta del teórico de control; enla década que siguió a la contribuciónde Nyquist estas técnicas fueron casicompletamente reemplazadas pormétodos basados en la teoría de va-riable compleja los cuales fueron con-secuencia natural y directa de su nue-vo planteamiento.

La aplicación del criterio de estabili-dad de Nyquist no dependía de la dis-ponibilidad de un modelo del sistemaen la forma de una ecuación diferen-cial. Más aún, el contorno del lugarde Nyquist daba una indicación in-mediata de cómo se podía mejorar laconducta de un sistema realimenta-do que estaba muy poco amortiguadoo que incluso era inestable, modifi-cando de una manera apropiada sucaracterística de ganancia en lazoabierto, en función de la frecuencia.

La situación era pues que a finalesde los años treinta existían dos mé-todos independientes, bien desarro-llados, para atacar el problema desistemas realimentados:


1. “El dominio temporal” que utili-zaba ecuaciones diferenciales or-dinarias y que se aplicaba funda-mentalmente en procesos quími-cos, mecánicos, navales y aero-náuticos.

2. “El dominio frecuencial” que ha-cía uso de las representaciones deNyquist y Bode, de funciones detransferencia y que era patrimo-nio exclusivo del estudio de am-plificadores realimentados.

A comienzos de los años cincuenta, losmétodos de respuesta en frecuenciahabían copado el campo del controlaplicado en al análisis y diseño demecanismos de realimentación y desistemas de control automático. Laposición había cambiado completa-mente desde finales de los años vein-te cuando el predominio de los méto-dos en el dominio temporal era in-cuestionable.

La aparición del computador digital(Figura 7) fue un prerrequisito parael desarrollo del control óptimo ymultivariable. Era ahora razonableintentar estudios más profundos ycompletos en teoría de control auto-mático, de nuevo en el dominio tem-poral, ya que la potencia y la versati-lidad de esta máquina hacía factibleresolver los complejos algoritmos aque daba lugar.

Al mismo tiempo, el desarrollo decomputadoras de propósito especialofrecía la posibilidad de realizar es-quemas de control más ambiciosos.Por lo tanto fue un paso natural con-siderar el control simultáneo de unaserie de variables que interaccionancon diferentes tipos de objetivos delcontrolador, tal como la minimizacióndel consumo de combustible en los

vuelos espaciales. Dos figuras cientí-ficas, entre otras, definieron las ba-ses de este nuevo desarrollo en Teo-ría de Control Óptimo; en Rusia L.S.Pontryagin8 con la formulación ma-temática de su “principio máximo” yen los U.S.A R. Bellman9 soluciona elproblema de optimización dinámicadesarrollando los principios y algorit-mos de “programación dinámica”.

En la evolución conceptual y tecnoló-gica de la ciencia médica, la teoría decontrol y el principio de realimenta-ción han tenido una participacióntrascendental.3 N. Wiener se intere-só profundamente en las relacionesentre los problemas de ingeniería yfisiología. Escribió un libro crucialsobre cibernética.5 Su libro tuvo unefecto importante al propagar lasideas del control por retroalimenta-ción en general y de los métodos derespuesta en frecuencia, en particu-lar en los campos de la teoría de sis-temas estocásticos y de la fisiología.

El mantenimiento de una serie deparámetros físicoquímicos constantesen el ambiente que rodea una pobla-ción pluricelular, como base de lavida, definiéndose así el concepto de“homeostasis” fue estructurado porEmpédocles en la antigua Grecia,Claude Bernard, en Francia, 1859 yWalter Cannon en U.S.A 1932. Pos-teriormente el concepto de retroali-mentación fue aplicado en la regula-ción celular de la concentración demetabolitos por Monod J., ChangeuxJ., 1963. Los trabajos pioneros demodelaje teórico del regulador respi-ratorio por F.S. Grodins, en asocio conJ.S. Gray, 1950, 1954, J. Buell, R.Bellman, 1967 y S.M. Yamashiro,1977, marcaron un hito en la aplica-ción de la Teoría de Control Moderno


al estudio de la regulación por retroa-limentación negativa de variables fi-siológicas que garanticen la “homeos-tasis” en el ser vivo (Figura 8). Líneassimilares de trabajo científico y tec-nológico han sido desarrolladas porA.C. Guyton, 1955, y F.S. Grodins,

1959, F.S. Grodins, T. Sato, D. Vega,1974, en regulación circulatoria; porJ. Hardy, 1961, en regulación de latemperatura corpórea; por J. Houk,1967, en regulación del movimientomuscular; y por F.E. Yates, 1973, enendocrinología.

Figura 8. Componentes generales de un arco reflejo, en un sistema de re-troalimentación negativa fisiológico.

Cómo extrapolar el proceso derealimentación a una situacióneducativa

La ejecución del proceso de aprendi-zaje depende de la retroalimentación(Figura 9).4 Nosotros ejecutamos de-cisiones que modifican el mundo real,evaluamos las consecuencias de es-tas decisiones y por retroalimenta-ción informativa revisamos nuestroscriterios decisorios y nuestra com-prensión del mundo real. Sin embar-go, el circuito simple de realimenta-ción de información puede ser modu-

lado por modelos mentales del mun-do real (Figura 10).

El proceso de retroalimentación ana-lizado en la Figura 9 mimetiza unaspecto importante en el proceso deaprendizaje. La retroalimentación deinformación evaluativa de la situacióndel mundo real no es la única entra-da a nuestro criterio decisorio. Nues-tro patrón de criterios decisorios es elresultado de políticas de informaciónacerca del mundo real. Estas políti-cas son estructuradas por estrategiasde organización y normas culturales,


las cuales son definidas por nuestrosmodelos mentales. Si nuestros mode-los mentales no cambian, el círculode retroalimentación del aprendiza-

je es simple, un proceso por medio delcual nos entrenamos para lograr nues-tros objetivos, en el contexto de nues-tros modelos mentales existentes.

Figura 10. Modulación del circuito simple de aprendizaje, por modelos men-tales.

Figura 9. El aprendizaje es un proceso de realimentación.


Cuál es la importancia de la “rea-limentación” en la estructura-ción conceptual y aplicada enciencias administrativas

La optimización en la utilización derecursos en procesos administrativosrequiere del uso de la metodología delpensamiento sistémico, en el diseñode modelos curriculares de entrena-miento del recurso humano.

Peter M. Senge1 define el pensamien-to sistémico en este contexto en la si-guiente forma: “El pensamiento sis-témico es una disciplina para ver to-talidades. Es un marco para ver in-terrelaciones en vez de cosas, para verpatrones de cambio en vez de “instan-táneas” estáticas. Sus herramientasy técnicas específicas se originan endos ramificaciones: el concepto de“realimentación” de la cibernética yla teoría del “servomecanismo” de laingeniería que se remonta al sigloXIX.” En este contexto es preciso ilus-trar la trascendencia de la utilizaciónde procesos reforzadores y compen-sadores en el manejo de situacionesadministrativas.

En los procesos reforzadores, un cam-bio pequeño se alimenta de sí mismo.Todo movimiento es amplificado yproduce más movimiento en la mis-ma dirección. En la Figura 11 el pro-ceso de ventas es causado por clien-tes que hablan entre sí acerca de unproducto. Si el producto es bueno,más ventas significan más clientessatisfechos, lo cual implica más co-mentarios positivos. Esto provoca aúnmás ventas, más comentarios positi-vos, y así sucesivamente. Por otraparte, si el producto es defectuoso, elcírculo virtuoso se transforma encírculo vicioso; las ventas redundanen menos clientes satisfechos, menoscomentarios positivos y menores ven-tas, lo cual conduce a aún menos co-mentarios positivos y menos ventas.En un circuito de retroalimentaciónpositiva (reforzadora), el cual operaen el incremento, por ejemplo, de lacarrera armamentista (Figura 12) talcomo sucede en nuestro medio colom-biano, en el cual más violencia gene-ra más adquisición de armas, las cua-les producen más violencia, y así su-cesivamente.

Figura 11. Realimentación reforzadora. ¿Cómo crecen los cambios pequeños?


Figura 12. Realimentación reforzadora: generación de un crecimiento acele-rado.

Los procesos compensadores admi-nistrativos y los sistemas de controlde retroalimentación negativa fisio-lógicos presentan analogías funciona-les impresionantes. Por ejemplo, enla regulación de la temperatura cor-pórea deseada en hipotermia (Figu-ra 13), el organismo genera median-

te arcos reflejos (Figura 8) un aumen-to de la producción de calor y una dis-minución en sus pérdidas, hasta quese obtiene un nuevo estado estacio-nario de equilibrio dinámico entreaportes y pérdidas, restableciéndoseasí la temperatura corporal deseada.

Figura 13. Evolución dinámica del proceso de minimización de la brecha(error), en la temperatura corporal.


Figura 14. Dinámica de reducción de la brecha en un proceso compensadoradministrativo.

En una situación administrativa par-ticular, un gerente pretende reducirel agotamiento de los profesionales desu empresa en rápida expansión.

Escribía memorandos, abreviaba lashoras de trabajo (meta del directivo)(Figura 14) y cerraba las oficinas mástemprano para evitar que la gentetrabajara más de la cuenta.

Pero todos estos actos eran inconse-cuentes: la gente ignoraba los memo-randos, desobedecía los horarios másbreves y se llevaba trabajo a casa

cuando cerraban las oficinas. ¿Porqué? Porque una norma tácita de laorganización establecía que los ver-daderos héroes, las personas que seinteresaban de veras y progresabanen la organización, trabajaban lameta implícita de setenta horas se-manales. Esta meta se había estable-cido por la prodigiosa energía y lar-gas horas de trabajo del gerente.

CONCLUSIÓNUna reflexión sobre las implicacionesdel fenómeno y el concepto de retroa-


limentación se ha ejecutado comoderrotero ilustrativo de lo que debeser la metodología educativa del edu-cador moderno, el cual debe desarro-llar en el estudiante modelos menta-les de pensamiento sistémico, queorganicen información en el contextode la solución interdisciplinaria via-ble a un problema o pregunta inves-tigativa específica.

AgradecimientosQuiero expresar mis sinceros agrade-cimientos al señor Rector de la Uni-versidad ICESI por propiciar el am-biente académico y humano, genera-dor de esta publicación, contando conla asesoría de Luis Eduardo MúneraS. y Andrés López A. Similarmente alas fuentes continuas de mi inspira-ción, renovación intelectual y espiri-tual: mi esposa e hijos, mis discípu-los amados en ejercicio profesional yen proceso de formación en las áreasde Ciencias de la Salud, Ingeniería yAdministración.

BIBLIOGRAFÍA1. Senge Peter M. La Quinta Disci-

plina, 1993.

2. Mayr E. This is Biology, 1996.

3. Grodins F.S. Control Theory andBiological Systems, 1963.

4. Sterman J.D. Business Dynamics,2000.

5. Wiener N. Cybernetics. MIT Press1948.

6. Maxwell J.C. On governors.Proc.Roy.Soc. London, 1868.

7. Nyquist H. Regeneration Theory.Bell.Syst.Tech. J., 1932.

8. Pontryagin L.S. et al The Mathe-

matical Theory of Optimal Proces-ses, 1963.

9. Bellman R. Dynamic Program-ming. Princenton N.J., 1957.

10. Sato T.D. Vega, S.M. Yamashiroand F.S. Grodins. Parameter sen-sitivity analysis of a network mo-del of systemic circulatory mecha-nics. Annals of BME.2.1974

CURRÍCULODaniel Martín Vega Barvo. Reali-

zó sus estudios de Medicina yBiología en las Universidadesdel Valle y de los Andes dondeobtuvo su B.Sc en 1963. Poste-riormente, con RockefellerFoundation Fellow realizó susestudios de postgrado en Inge-niería Biomédica bajo la tuto-ría de F.S. Grodins en The Uni-versity of Southern Californiaobteniendo su M.Sc 1971, y suPh.D 1973. En 1985 como Na-tional Institutes of Health Fo-garty International ResearchFellow en la misma instituciónejecutó sus estudios depostdoctorado.Es miembro delas siguientes sociedades hono-ríficas de los U.S.A: ETA KA-PPA NU: Electrical Enginee-ring Honorary Society. SIGMAXI: National Research Honora-ry Society. ETA KAPPA NU: AllUniversity Honorary Society yha sido incluido en la enciclo-pedia “Who is Who in theWorld” 1986. Es Profesor Titu-lar Jubilado de la Universidaddel Valle y actualmente es Coor-dinador y docente de Fisiologíaen la Universidad Libre y en laFundación Universitaria SanMartín de esta ciudad.


Herramienta para el cálculo de invariantestopológicos


SUMMARYIn this article there is a description ofthe process that yielded a software toolwhich was designed with the purposeof calculating four specific topologicalinvariants, among which we count theBetti numbers, the dimension of thecomplex, the q-array and the Euler-Poincaré characteristic.

The meaning of all the obtained re-sults is viewed from Professor LuisEduardo Múnera’s perspective, whi-ch in turn proposes a formal mathe-matical definition of cohesion andcoupling, two important criteriawhen evaluating modularity of a soft-ware design. The article also descri-bes the tool itself, its functionality

and the importance it has to theprofessor’s project.

In order to portrait a full comprehen-sible description of both the processand the tool, an historical frameworkis established through a brief reviewof the evolution of the different ideasand concepts behind the project, andthe way and pace with which thesewere assimilated by the student teamthat were appointed to the task.

KEY WORDSModular design, algebraic topology,topological invariants calculations,Betti numbers, complex dimension,Euler/Poincaré characteristic, q-array, cohesion, coupling, Matlab.

Juan Pablo Bedoya [email protected]

Aura Lucía Pérez [email protected]

Javier Guillermo Valdés [email protected]


RESUMENEn este artículo se describe el proce-so de desarrollo de una herramientade software diseñada con el propósi-to de realizar los cálculos necesariospara obtener cuatro invariantes to-pológicos, que son los números deBetti, la dimensión del complejo sim-plicial, el vector de estructura, y lacaracterística Euler-Poincaré.

Los resultados de estos cálculos seinterpretan según una propuesta delprofesor Luis Eduardo Múnera, en laque se plantea una definición formalde cohesión y acoplamiento en inge-niería de software, criterios impor-tantes para evaluar la modularidadde un diseño. El artículo también des-cribe la herramienta en sí, su funcio-nalidad y el significado que tiene parael proyecto del mencionado docente.

Para lograr la descripción del proce-so y de la herramienta, se realiza unbreve recuento histórico que sirvecomo marco de referencia al lectorpara mostrar la evolución de las ideasy conceptos sobre los cuales se apoyael proyecto de investigación, y la ma-nera en la que estos fueron asimila-dos por el equipo de estudiantes queasumió la responsabilidad de llevar-lo a cabo.

PALABRAS CLAVESDiseño modular, topología algebrai-ca, cálculos de invariantes topológi-cos, números de Betti, dimensión delcomplejo simplicial, característicaEuler-Poincaré, vector de estructura,cohesión, acoplamiento, Matlab.

Clasificación: A


INTRODUCCIÓNEl profesor Luis Eduardo Múneraidentificó la falta de formalidad ma-temática que respaldaba las activida-des de ingeniería de software comoson análisis, diseño y desarrollo. Estacarencia llevó a que desarrollara unapropuesta para formalizar el diseñomodular en la ingeniería del softwarebasándose en algunos conceptos de latopología algebraica.1

Como proyecto de grado, los estu-diantes Juan Pablo Bedoya, AuraLucía Pérez y Javier Guillermo Val-dés decidieron realizar una pieza desoftware para calcular los invarian-tes topológicos de un complejo sim-plicial, herramienta que servirá deapoyo a la investigación del profesorMúnera.

Se determinó que la herramienta cal-cularía los siguientes invariantes to-pológicos:

• La dimensión del complejo simpli-cial.

• La característica Euler-Poincarédel complejo simplicial.

• El vector de números de Betti aso-ciado al complejo.

• El vector de estructura asociadoal complejo.

• La cohesión.

• El acoplamiento.

• Los agujeros del complejo.

La importancia de este programa ra-dica en la agilización de los cálculos

de los invariantes topológicos ante-riormente definidos, con el propósitode facilitar la investigación de quie-nes se apoyan en la topología alge-braica.

MARCO TEÓRICOCohesión, acoplamiento, modulari-dad son términos frecuentemente uti-lizados en sistemas de información eingeniería de software, tanto dentrodel Paradigma Estructurado como enel Paradigma Orientado a Objetos.Pero a pesar de su importancia no sonprecisados de manera formal.

El profesor Luis Eduardo Múnerarealizó una propuesta para definir ymedir la cohesión y el acoplamiento,mediante el uso de la Topología Alge-braica, una rama de la matemáticaque estudia las transformaciones con-tinuas.

Un complejo simplicial abstracto Ksobre un conjunto finito cuyos ele-mentos se llaman vértices V ={a0,...,an} es un subconjunto no vacíode partes de V (excluyendo el vacío)cuyos elementos son llamados símpli-ces con las siguientes propiedades:

(P1) Si σ ε Κ y τ σ entonces τ ε Κ.Decimos que σ y τ son símplices y queτ es una cara de σ.

(P2) Si σ y τ pertenecen a K, enton-ces σ ∩ τ o bien es vacía, o bien esuna cara común de σ y τ.

(P3) Si ai pertenece a V entonces{ai} pertenece a K.

1. Múnera Salazar, Luis Eduardo. Una aproximación topológica al diseño modular en ingeniería de soft-ware. S&T. Revista de la Facultad de Ingeniería. Universidad Icesi, No. 2. 2003. p.57-73

⊃


A un complejo simplicial K le pode-mos asociar arreglos numéricos queson invariantes topológicos (todos lospoliedros equivalentes topológica-mente poseen los mismos arreglos).

• Números de Betti: A un comple-jo simplicial K de dimensión m lepodemos asociar un arreglo

β = < βO, β1,...,βN >

en donde ßi es el correspondiente nú-mero de Betti para cada dimensióncon i desde 0 hasta m.

El criterio para calcular los númerosde Betti es el siguiente:

βP (K) = np - rango ∂p - rango ∂p+1

Los números de Betti para cada di-mensión señalan el máximo númerode ciclos no homólogos a cero (aguje-ros) y homológicamente indepen-dientes.

β0 = Q0, que se define como el núme-ro de componentes arco-conexas. β1es el número de “túneles” linealmen-te independientes (que llamaremos2-agujeros), β2 es el número de agu-jeros de dimensión 3 (que llamare-mos 3-agujeros) del complejo; en ge-neral, βi es el número de agujeros dedimensión i+1 (i+1-agujeros) delcomplejo.

• Vector de estructura: A un com-plejo simplicial K le podemos aso-ciar arreglos numéricos que soninvariantes topológicos (todos lospoliedros equivalentes topológica-mente poseen los mismos arre-

glos). El primero de ellos se cono-ce con el nombre de primer vectorde estructura del complejo y per-mite ver la conectividad internadel complejo (visión local) recu-rriendo a la noción de q-conecti-vidad. Esta noción y sus aplica-ciones en ciencias sociales fuerondesarrolladas por el matemáticoRonald Atkin.

Si K es un complejo finito no vacío dedimensión m, le podemos asociar elarreglo Q = <Q0, Q1,..., Qm > en don-de Qi es la cardinalidad de K/γi, , sien-do Qi ≥ 1, i = 0,1,.., m.

• Característica Euler Poinca-ré: Dado un complejo simplicialde dimensión m, sabemos que

- n0 = número de vértices (símplicesde dimensión 0)

- n1 = número de segmentos (símpli-ces de dimensión 1)

- n2 = número de triángulos (símpli-ces de dimensión 2)

- n3 = número de tetraedros (símpli-ces de dimensión 3)

. . .

- nm = número de símplices de dimen-sión m.

Los matemáticos Leonard Euler yRené Descartes descubrieron que n0- n1 + n2 = 2 para toda superficie po-liédrica (tetraedros, icosaedro, etc).

Henri Poincaré extendió este resul-tado para cualquier complejo:

X = (n0 - n1) + (n2 - n3) + (n4 - n5) + .. . + (nm-1 - nm)


en donde el número X se conoce conel nombre de características Euler-Poincaré.

• Dimensión: La dimensión de unsímplice es el número de sus vér-tices menos uno. La dimensión deK es el máximo de las dimensio-nes de todos sus símplices.

INFORMACIÓN GENERALDEL PROYECTO

RealizaciónEl proyecto comenzó a gestarse en elsegundo semestre del año 2001. En eseentonces, el profesor Luis EduardoMúnera presentó su investigación rea-lizada sobre la topología algebraica ysus aplicaciones en el diseño modularen ingeniería del software y su nece-sidad de agilizar los cálculos.

Durante los dos siguientes semestresse trabajó en el fundamento teórico,sobre todo en la manera de calcularlos agujeros de un complejo simplicial,y en la realización de los primeros al-goritmos que calcularían los invarian-tes topológicos del complejo simplicialdado. Para tales cálculos y, después decierta indagación sobre las herramien-tas de desarrollo disponibles, se eligióMatlab, en su versión 6.1, ya que sufuncionalidad permite un manejo po-tente de las matrices y además pro-porciona ciertos cálculos matemáticosque se necesitaban para lograr el ob-jetivo. Para el comienzo del segundosemestre de 2002, el proyecto habíafinalizado satisfactoriamente. Los re-sultados que arrojaba la herramientapermitieron efectuar ajustes a los al-goritmos planteados y hacer refina-mientos a la teoría.

Para utilizar los algoritmos desarro-llados en Matlab, se requería ciertoconocimiento de la herramienta, lo

cual generaba complicaciones a laspersonas que no lo tenían. Se planteóasí la necesidad de generar una inter-faz gráfica “amigable”. Se creó enton-ces la primera versión del programa,la cual se desarrolló con el entorno deprogramación de Visual Studio 6, conel lenguaje Visual Basic. Se escogióVisual Basic ya que Mathworks, lacasa de software dueña de Matlab,proveía una herramienta llamadaMatrix VB que pone a disposición delentorno de Visual Basic toda la fun-cionalidad de Matlab. El resultado fueuna interfaz de usuario que permitíaintroducir la información directamen-te en el programa, o introducir infor-mación en archivos con formatos deMatlab (extensión .MAT).

Algunas de las falencias de la prime-ra versión de la herramienta incluíanel hecho de que ésta no contó con lafuncionalidad del cálculo de agujeros.Esta funcionalidad es clave para losobjetivos del proyecto, en cuanto per-mite la localización precisa de las fa-llas en el diseño, representado en elcomplejo simplicial.

Durante el año 2003 se encontrarondetalles que refinaban aún más la pro-puesta, y los resultados obtenidos conel uso de la herramienta permitieronhacer cambios a la interpretación dela teoría y su relación con el objeto deestudio. Así, se terminó de ajustar elalgoritmo para el cálculo de agujeros.Dada la complejidad y extensión dedicho cálculo, se decidió no implemen-tarlo utilizando Matlab. Para el desa-rrollo de este algoritmo realmente nose necesitaba tanta potencia matemá-tica, como la ofrecida por Matlab, sinoun manejo más eficiente de los recur-sos del computador como la memoria.Con base en este criterio y para elsegundo semestre de 2003 se imple-


mentó el algoritmo del cálculo de agu-jeros. En esta ocasión se utilizó lanueva herramienta de Microsoft, Vi-sual Studio .NET, y específicamenteel lenguaje C#. También se empleó laherramienta COM Builder del entor-no Matlab, en su versión 6.5. Con elMatlab COM Builder se generó unobjeto COM que empaquetaba los al-goritmos desarrollados en Matlab ypermitía su uso en C#.

Surgió pues la última versión, la 2.0,que incluye el cálculo de agujeros, lasmejoras a los algoritmos, las nuevasdefiniciones formales de los concep-tos de cohesión y acoplamiento, y unacorrección a la implementación quese hizo de los números de Betti, queno se había logrado a cabalidad parael primer release.

ResultadosEl resultado fundamental del proyec-to es una herramienta de softwareque básicamente realiza dos tipos decálculos:

• Dado un complejo simplicial abs-tracto representado por su matrizde incidencia, la herramienta per-mite obtener cuatro invariantestopológicos asociados al complejo:

• Dimensión

• Característica Euler – Poincaré

• Vector de estructura

• Vector de números de Betti

Además permite identificar agujeros.

• Adicionalmente, la herramientapermite calcular la cohesión y elacoplamiento de un sistema repre-sentado por su complejo simplicial.

El programa está compuesto por cua-tro módulos: el que calcula los Inva-riantes topológicos, el que captura

las matrices de incidencia, el quecalcula los agujeros y el de control,encargado de la coordinación de losanteriores y punto de entrada alprograma.

El módulo encargado del cálculo delos invariantes topológicos, realiza elcálculo de los cuatro invariantes to-pológicos y de la cohesión y el acopla-miento. Para ello se apoya en doscomponentes COM, implementadosen Matlab y convertidos en dll gra-cias a la utilidad de Matlab MVCom-Builder. El primero, MVComUtil.dll,es el que encapsula las funcionalida-des de Matlab; el segundo,InvarTopo.dll, es el que contiene lafuncionalidad desarrollada por elequipo de estudiantes.

El módulo de cálculo de agujeros es elencargado de encontrar los agujerosdel complejo simplicial dado y de iden-tificarlos. Está compuesto por una cla-se llamada classCalculoAgujeros, lacual contiene todo el proceso de cálcu-lo de agujeros. Este módulo no se apo-ya en el componente de Matlab.

El algoritmo de Cálculo de Agujerosestá definido de la siguiente forma:

Entrada: la Matriz de Incidencia (MI)

Salida: {Hq+1} k-1 La familia de con-

juntos de agujeros en cada dimensión.

Proceso:

Aplicar el procedimiento de obtenciónde la matriz reducida, MR.

IF MR = 0 THEN {Hq+1} k-1 = Ø y FIN

Aplicar el procedimiento de obtenciónde las matrices de q-adyacencia

Aplicar el procedimiento de obtenciónde q-ciclos para cada matriz de q-ad-yacencia

q=O

q=0


Cál

culo

de

Inva

riant

esTo

poló

gico

s

Impl

emen

to

Com

pues

topo

rA

yuda

en

línea

.htm

l

“ext

ends

”

For

mad

o po

r

Impl

emen

to

Form

Inva

riant

esE

stá

iden

tific

ado

dent

ro d

e

Form

Prin

cipal

Form

Aguj

eros

Par

ticip

a en

lare

aliz

ació

n de

Des

pleg

arRe

sulta

dos

Mód

ulo

Con

trol

“ext

ends

”“e

xten

ds”

Cál

culo

de

Inva

riant

esTo

poló

gico

s

Com

pues

to p

or

Inva

rTop

o.dI

I

Inte

ract

úaco

n

“libr

ary”

MV

Com

Util

.dII

form

Abo

utP

artic

ipa

en la

real

izac

ión

de

Par

ticip

a en

lare

aliz

ació

n de

Ayu

das

Est

áid

entif

icad

ode

ntro

de

clas

sCál

culo

Agu

jero

s

Impl

emen

tos

Cál

culo

Inva

riant

es T

opol

ógic

os“u

ses”

Cál

culo

de

Coh

esió

ny

Aco

plam

ient

o

“use

s”“u

ses”

“use

s”

Capt

ura

de M

atriz

de In

ciden

cia

Impl

emen

tsIm

plem

ents

Cap

tura

Mat

riz d

eIn

cide

ncia

Par

ticip

a en

lare

aliz

ació

n de

Est

áId

entif

icad

ode

ntro

de

Par

ticip

a en

lare

aliz

ació

n de

clas

sMat

rizIn

cide

ncia

form

Cre

arM

atriz

Inci

denc

ia

Cál

culo

s de

Agu

jero

s

Cál

culo

de

Agu

jero

s

Parti

cipa

en la

real

izació

n de

Está

Iden

tifica

dode

ntro

de

AR

QU

ITE

CT

UR

A D

EL

PR

OG

RA

MA


Aplicar el procedimiento de obtenciónde q+1 agujeros para cada lista lq deq-ciclos, obteniéndose la familia

{Hq+1} k-1

IF existe un agujero A pertenecientea más de un conjunto de {Hq+1}

k-1

THEN lo dejamos en el conjunto condimensión más alta y lo eliminamosen los conjuntos con dimensiones másbajas.

Procedimiento de obtención de lamatriz reducidaEntrada: La matriz de incidencia MI.

Salida: La matriz reducida MR.

Proceso:

Sobre la matriz de incidencia reali-zamos tres tipos de operaciones dereducción:

Columnas con un solo 1, se convierteeste en 0

Filas cuyos unos estén incluidos enlos unos de otra fila, se convierten enceros.

Columnas cuyos unos estén incluidosen los unos de otra columna, se con-vierten en ceros.

IF la matriz resultante contiene sóloceros

THEN, no hay ciclos y por lo tanto nohay agujeros. Es decir, MR = 0.

ELSE, eliminamos las filas y las co-lumnas de la matriz que sólo contie-nen ceros, generándose la matriz re-ducida MR # 0

Procedimiento de obtención de matri-ces de q-adyacencia

Entrada: la matriz reducida (MR)

Salida: Las matrices de q-adyacencia(q = 0,1,2,...)

Proceso:

Calcular la transpuesta de la matrizreducida MR.

FOR q = 0 to k (k = Dimensión de MR)hacer

Obtener la matriz de q-adyacencia

Procedimiento de obtención de los q-ciclosEntrada: Una matriz de q-adyacen-cia

Salida: Una lista lq formada por losq-ciclos

Proceso:

1. Convertir la matriz de q-adyacen-cia en una matriz latina L

2. Hacer L1 = L

FOR i = 2 hasta k (Dimensión de L)HACER

Li = Li-1 x L1 (Producto Latino)

El producto latino es como sigue:

Sean A = [a1, a2, a3,...,a] ε Li-1 y B =[b1,b2] ε L1, los elementos a multipli-car:

IF A = O v B = O THEN AxB = O

ELSE

IF i< q + 3 THEN (AxB)0 =[a1,a2,a3,...,ai,b2]

IF (AxB)0 ε Diagonal de Li

THEN hacer (AxB) = 0

ELSE hacer (AxB) = (AxB)0

ELSE (AxB)0 = [a1,a2,a3,...,ai,b2]

IF (AxB)0 ε Diagonal de Li

q=0

q=0


THEN (AxB)0 es un q-ciclo de longi-tud i

Incluimos (AxB)0 en lq y hacemos

(AxB) = (AxB)0

ELSE

IF (aj = b2, ∋ aj = ak, ∋ j∋ k)

THEN (AxB) = 0

ELSE hacemos (AxB) = (AxB)0

3. De los q-ciclos de lq eliminamos alos semejantes (dos q-ciclos de igualdimensión y longitud son semejantessi contienen el mismo conjunto devértices).

Procedimiento de obtención de losq+1-agujeros

Entrada: Una lista lq de q-ciclos

Salida: Una lista de Hq+1 de q+1-agu-jeros

Proceso:

1. Para cada q-ciclo de lq hacemos:

IF q-ciclo no es un símplice de MR

THEN es un q+1-agujero y lo inclui-mos en Hq+1

2. En Hq+1 eliminamos los q+1-aguje-ros que contienen a otros.

El módulo de captura de la matriz deincidencia está compuesto por la for-ma formCrearMatrizIncidencia, quecontiene un Grid en el cual el usua-rio ingresa el Complejo Simplicial, ylo almacena en la clase classMatrizIncidencia.

Además, el programa contiene unaayuda en línea que describe detalla-damente el funcionamiento de todo elsoftware y una forma Acerca de.

CONCLUSIÓN1. El apoyo en los recursos tecnoló-

gicos para realizar procesamien-to de información, facilita y agili-za los procedimientos llevados acabo en la obtención de resulta-dos en las investigaciones.

2. Es importante conocer múltiplesopciones, en cuanto a metodolo-gías y herramientas de construc-ción de software, para que se fa-cilite el proceso y para que el soft-ware final sea más efectivo encuanto a rendimiento, interfaz deusuario, etc.

3. Es conveniente que en un proyec-to de desarrollo de una aplicaciónexistan personas con diferentesenfoques en el manejo de las ar-quitecturas, herramientas y me-todologías de diseño, desarrollo ydistribución de software, con el finde lograr un resultado acorde conlas necesidades del usuario final.

BIBLIOGRAFÍAMúnera Salazar, Luis Eduardo. Unaaproximación topológica al diseñomodular en ingeniería de software.S&T. Revista de la Facultad de Inge-niería. Universidad Icesi, No. 2. 2003.p.57-73

Matlab, [ayuda en línea].

Visual Studio .NET versión 2003,[ayuda en línea].

Referencia del API de C#, <http://msdn.microsoft.com>

Robohelp Office versión [ayuda en lí-nea].

Wise for Windows Installer versión5.0, [ayuda en línea].


CURRÍCULOSJuan Pablo Bedoya Giraldo. In-

geniero de Sistemas de la Uni-versidad Icesi. Realizó su prác-tica en La 14 S.A. como Analis-ta y Líder Técnico en la imple-mentación de un sistema de nó-mina basado en Oracle. Actual-mente se desempeña como In-geniero de Desarrollo en Sys-gold, una casa de software queprovee soluciones para disposi-tivos móviles.

Aura Lucía Pérez Escobar. Estu-diante de Ingeniería de Sistemasde la Universidad Icesi. Realizósu práctica en el LAAS (Toulo-use–Francia) como desarrollado-

ra en un proyecto de Simulacióny Optimización de Redes IP-Di-ffServ-MPLS. Actualmente sedesempeña como Analista/Pro-gramador Junior en la oficina deDesarrollo de Sistemas de laUniversidad Icesi.

Javier Guillermo Valdés Duque.Ingeniero de Sistemas de laUniversidad Icesi. Realizó supráctica en el Hotel PacíficoRoyal, en el departamento desistemas, desempeñando el car-go de asistente del director desistemas. Actualmente se en-cuentra adelantando un proyec-to empresarial propio, relacio-nado con el desarrollo de soft-ware.


Una aproximación a los indicadoresde gestión a través de la dinámica

de sistemas


Fernando Antonio Arenas [email protected]

ABSTRACTPerformance measures have becomea main topic within the organizatio-nal environment. Approaches to thissubject have been going from themerely operational to the inclusion ofperformance measures as part ofstrategic planning, as in the Balan-ced Scorecard approach, where mea-sures are linked with strategic objec-tives through causal relationships.This article intends to show, bymeans of an example model, the po-tential of system dynamics for esta-blishing causal relationships betweenmeasures, verifying the validity ofhypotheses implicit in these relatio-

nships, and showing the need for tra-de-offs between different objectives.

KEYWORDSPerformance measures, modeling,system dynamics.

RESUMENEl tema de los indicadores de gestiónse ha venido convirtiendo en priori-tario dentro del ámbito de las orga-nizaciones. Las aproximaciones altema van desde lo meramente instru-mental hasta la inclusión de los indi-cadores como parte del tema estraté-gico. Una de las metodologías que ligalos indicadores con el ejercicio estra-


tégico es la de Cuadro de Mando In-tegral (Balanced Scorecard) que su-giere enlazar los indicadores con losobjetivos estratégicos a través de re-laciones causales. En este artículo semuestra, a través de un modelo deejemplo, la potencialidad de la Diná-mica de Sistemas como herramientapara establecer las relaciones causa-

les entre indicadores, verificar la va-lidez de las hipótesis subyacentes adichas relaciones y mostrar la nece-sidad de establecer transaccionesentre el logro de los objetivos asocia-dos a diferentes indicadores.

PALABRAS CLAVES:Indicadores de gestión, modelación,dinámica de sistemas.

Clasificación: B


INTRODUCCIÓNLa necesidad de los gerentes de te-ner acceso a información confiable ysignificativa, que brinde soporte a latoma de decisiones, ha venido dandocada vez mayor relevancia al tema delos indicadores de gestión. Dicha re-levancia se ve reflejada en la crecien-te literatura disponible sobre el tema,parte de la cual está dedicada a laparte meramente instrumental deconstrucción de los indicadores (Bel-trán, 2000) o a su aplicación a untema organizacional específico, comoel de la cadena de suministro (Kee-bler y Durtsche, 1999), mientras quees cada vez mayor la literatura queincluye los indicadores como parte delejercicio estratégico considerando di-versas perspectivas (Hronec, 1993),ligando perspectivas y estrategia(Graham Brown, 1996; Kaplan y Nor-ton, 2000) o mostrando metodologíaso casos de aplicación dentro del ejer-cicio estratégico empresarial (Kaplany Norton, 2001; Niven, 2002). Lametodología de Cuadro de Mando In-tegral (Balanced Scorecard) sugeridapor Kaplan y Norton (2000) proponeestablecer varias perspectivas desdelas cuales se desarrollen los indica-dores (finanzas, cliente, procesos in-ternos, aprendizaje y crecimiento)como parte del despliegue de los ob-jetivos estratégicos; esto implica es-tablecer relaciones causales entre losdiversos indicadores con el fin de ha-cer explícita la forma en que el logrode cada uno de ellos contribuye al lo-gro de dichos objetivos. Kaplan y Nor-ton (2000, p. 163) enfatizan la nece-sidad de establecer relaciones causa-efecto entre indicadores, que puedanser validadas: Una estrategia es unconjunto de hipótesis sobre las rela-

ciones causa-efecto. Estas pueden ex-presarse con una secuencia de decla-raciones del tipo si/entonces. Un cua-dro de mando adecuadamente cons-truido debe contar la historia de launidad de negocios a través de unasecuencia de relaciones causa-efecto.El sistema de indicadores debe hacerque las relaciones (hipótesis) entre losobjetivos (e indicadores) en las diver-sas perspectivas sean explícitas a finde que puedan ser gestionadas y con-validadas. Debería identificar y ha-cer explícita la secuencia de hipótesissobre las relaciones de causa y efectoentre los indicadores y los resultadosy los inductores de la actuación deesos resultados.

Sin embargo, no proponen una meto-dología para establecer y validar re-laciones causa-efecto, o para estable-cer las relaciones entre inductores deactuación y resultados. Es aquí don-de la dinámica de sistemas tiene unalto potencial de contribución.

LA FRAGMENTACIÓNDE LOS INDICADORESLa fragmentación de los indicadoreshace parte de la aproximación reduc-cionista a la solución de problemas,prevaleciente en la mayoría de lasorganizaciones, y es una respuesta ala necesidad de manejar la compleji-dad inherente a la gestión de una or-ganización. Supuestamente, la tomade decisiones en los diversos nivelesde la organización se facilita asignan-do indicadores y objetivos a cada unode esos niveles. Así cada nivel asignaobjetivos e indicadores a cada subni-vel hasta llegar incluso al nivel ope-rativo de primera línea.

Al decidir cómo alcanzar un objetivo,quienes toman decisiones tienden a


ignorar, o a tratar como exógenos,aquellos aspectos de la situación que,desde su punto de vista, no están re-lacionados directamente con el obje-tivo (Simon 1957, p. 79):

Las escogencias individuales tienenlugar en un ambiente de “cosas da-das”, premisas que son aceptadas porel sujeto como base para su escogen-cia; un comportamiento es adaptati-vo sólo dentro de los límites estableci-dos por esas “cosas dadas”.

Esta tendencia a la fragmentación es,según el físico David Bohm (1998, p.27-28), una tendencia prevalecienteen nuestra sociedad ( incluyendo lasorganizaciones) que conlleva a per-cepciones erróneas de la realidad:

...es la totalidad lo que es real, y lafragmentación es la respuesta de estatotalidad a la acción del hombre,guiado por una percepción ilusoria ydeformado por un pensamiento frag-mentario. En otras palabras, es pre-cisamente porque la realidad es untodo por lo que el hombre, con su modofragmentario de acercarse a ella, en-contrará inevitablemente la corres-pondiente respuesta fragmentaria.

La suposición implícita en la frag-mentación de los objetivos e indica-dores es la de que consiguiendo cadasub-objetivo se posibilita a la organi-zación para conseguir los objetivosglobales. El trabajar sobre esta supo-sición, sin haber establecido y vali-dado relaciones de causa y efecto en-tre los sub-objetivos y los objetivosglobales resulta no sólo incorrectosino, como lo expresa Bohm (1998,p.43), peligroso:

Lo más necesario es que nos vayamosdando cada vez más cuenta del gran

peligro que significa seguir con unproceso fragmentario de pensamien-to. Esta conciencia le dará a la inves-tigación de cómo actúa en realidad elpensamiento, el sentido de urgencia yla energía que le van a hacer faltapara enfrentarse con la verdaderamagnitud de las dificultades con lasque la fragmentación se nos está opo-niendo.

COMPLEJIDAD,RACIONALIDAD LIMITADAY MODELOS MENTALESEl manejo de la complejidad inheren-te a la toma de decisiones en las or-ganizaciones mediante la fragmenta-ción de los objetivos e indicadores, sibien resulta sencillo en apariencia,resulta riesgoso en la práctica. Unode los mayores riesgos estriba en lasconsecuencias inesperadas de accio-nes bien intencionadas, como lo men-ciona el biólogo Lewis Thomas (1974,p. 90):

Usted no puede manipular una partede un sistema complejo desde afuera,sin el casi seguro riesgo de provocarefectos desastrosos, con los que ustedno contaba, en otras partes del siste-ma. Si usted quiere arreglar algo, estáobligado a entender el sistema com-pleto primero. Intervenir, sin este en-tendimiento, es una manera de cau-sar más problemas que aquellos quese pretenden arreglar.

Una hipótesis explicativa de la pro-pensión de las organizaciones a estetipo de comportamientos se encuen-tra en el “principio de racionalidadlimitada” de Simon (1957, p. 198), porel cual ganó el Premio Nobel de Eco-nomía en 1979:

La capacidad de la mente humanapara formular y resolver problemas


complejos es muy pequeña, compara-da con el tamaño del problema cuyasolución es requerida para un com-portamiento racional objetivo en elmundo real o aun para una aproxi-mación razonable a dicha racionali-dad objetiva.

Según este principio, debido a nues-tras numerosas limitaciones de aten-ción, tiempo, memoria y procesamien-to de información, nos formamos mo-delos mentales muy simples de situa-ciones complejas. Estos modelos con-sideran sólo algunas relaciones cau-sa-efecto de tipo lineal e ignoran lasrealimentaciones, las interconexionesmúltiples, las no-linealidades y lasdemoras entre causa y efecto, asícomo otros elementos de la compleji-dad dinámica.

ATENCIÓNEl proceso de medida es, sobre todo,un proceso de selección. En el caso delas organizaciones, este proceso deselección está relacionado con el ma-nejo de la atención. Ya que, como semencionó anteriormente, nuestra ca-pacidad de atención es limitada, losobjetivos e indicadores se encargande enfocarla. Esta búsqueda de enfo-que implica un equilibrio muy deli-cado entre un enfoque demasiadoamplio donde el esfuerzo puede dis-persarse y uno demasiado estrechoque genera un modelo mental igual-mente estrecho con los riesgos yamencionados en este documento. ElCuadro de Mando Integral constitu-ye, desde este punto de vista, un pasoadelante en la búsqueda de ese equi-librio, al procurar relacionar el enfo-que amplio de los objetivos estratégi-cos con los enfoques, menos amplios,de los niveles táctico y operativo.

DINÁMICA DE SISTEMAS

Relaciones causalesLa dinámica de sistemas emplea lasimbología expuesta en la Figura 1para describir las relaciones causa-efecto entre las variables. En el casoque ilustra la figura, la variable “In-ventario” influye sobre la variable“Costo de inventario”.

Figura 1. Relación causa-efecto.

Variables de nivel y flujoLas variables de nivel son aquellassusceptibles de acumulación, es de-cir, que pueden actuar como un “tan-que”. Dentro de esta categoría se en-cuentran variables como inventarios,población, base de clientes, númerode empleados y todas las variablesfinancieras incluidas en un balance.Estas son variables que se expresanen unidades (kilogramos, personas,clientes, empleados, pesos). Las va-riables de nivel caracterizan el esta-do de un sistema y, por lo tanto, sonlas más frecuentemente utilizadaspara la elaboración de indicadoresque sirvan como soporte a la toma dedecisiones. Son variables asociadas alo que Kaplan y Norton (2000) deno-minan “resultados” o “indicadoreshistóricos”.

Las variables de flujo son aquellasque constituyen corrientes de entra-da a, o de salida de, los “tanques”.Ejemplos de este tipo de variablesson, producción y despachos, naci-mientos y muertes, nuevos clientes yclientes que se pierden, contratacio-


nes y retiros, ingresos y egresos. Es-tas son variables que se expresan enunidades por unidad de tiempo y es-tán asociadas a lo que Kaplan y Nor-ton (2000) denominan como “induc-tores de actuación” o “indicadoresprevisionales”.

Adicionalmente, la dinámica de sis-temas hace uso de “variables auxilia-res” o “intermedias” que explican elcomportamiento de las variables deflujo. Estas variables son funcionesde las variables de nivel y de cons-tantes o variables exógenas.

La Figura 2 muestra un esquemadonde puede verse la notación em-pleada para cada tipo de variable. “In-ventario” es una variable de nivel ycomo tal se ubica dentro de un rec-tángulo. “Producción” es la corrientede entrada a “Inventario” y “Despa-chos” la corriente de salida, y se re-presentan como tuberías con válvu-la, mientras “Ciclo de Manufactura”,“Tiempo Mínimo de Procesamiento deOrden” y “Tasa Máxima de Despacho”son variables auxiliares.

Figura 2. Variables de nivel, de flujo, y auxiliares.

MODELO Y SIMULACIÓN

Estructura del modeloSe utilizará para la simulación elmodelo de “Estructura de Políticas deInventario y Producción” propuestopor Sterman (2000). La estructura delmodelo puede verse en la Figura 3.

El eje del modelo está constituido porlas variables de nivel “Inventario enProceso” e “Inventario” y las varia-bles de flujo “Tasa de Arranques deProducción”, “Producción” y “Despa-chos”. Las demás variables son auxi-liares.


Figura 3. Estructura del modelo de “Políticas de Inventario y Producción”.

A la estructura del modelo se hanagregado indicadores operativos, de

servicio y financieros. La estructurade estos indicadores se muestra en laFigura 4.

Figura 4. Estructura de los indicadores agregados al modelo “Política deProducción e Inventarios”.


Modelos mentales y simulación

Para efectuar las simulaciones supon-dremos que el gerente de Operacio-nes le comunica al director de Logís-tica que, con el fin de disminuir loscostos totales de la empresa, y porende incrementar sus utilidades,debe centrar sus esfuerzos en redu-cir el “Costo Acumulado de Inventa-rio”, equivalente al “Costo Semanalde Inventario” acumulado a la quin-cuagésima semana (un año), que esel horizonte de simulación. Dada estaprioridad, el director de Logística po-dría actuar sobre dos variables que,vamos a suponer, están bajo su con-trol, “Tiempo Mínimo de Procesa-miento de Orden” y “Cubrimiento deSeguridad”. Los modelos mentalesimplícitos en estas decisiones estándescritos en las Figuras 5 y 6. Se hanutilizado en estos esquemas lo que endinámica de sistemas se denominan

“diagramas causales” donde a la fle-cha que indica una relación causal seagrega una polaridad (signo + o sig-no -) que depende del sentido en quese mueve el efecto cuando la causa semueve en un sentido determinado; siel efecto se mueve en el mismo senti-do de la causa se asigna una polari-dad positiva (signo +), si el efecto semueve en sentido contrario al de lacausa se asigna una polaridad nega-tiva (signo -); por otra parte, dos lí-neas paralelas sobre la flecha de en-lace representarán una demora sig-nificativa entre causa y efecto. Asípues, el modelo mental del gerentede Operaciones (Figura 5) debe leer-se: “si disminuye el costo acumuladode inventario entonces los costos to-tales deberán disminuir (polaridadpositiva), y al disminuir los costostotales deberán aumentar las utilida-des (polaridad negativa).

Figura 5. Modelo mental del gerente de Operaciones.

El modelo mental del director de Lo-gística, descrito en el diagrama cau-sal de la Figura 6, deberá leerse: “Lasacciones para reducir el tiempo mí-nimo de procesamiento de orden re-ducirán este tiempo (polaridad nega-tiva) tras una demora significativa(líneas paralelas sobre la flecha). Este

mismo efecto puede lograrse median-te una reducción en el cubrimiento deseguridad (polaridad positiva). Unadisminución en el inventario provo-cará la disminución del costo sema-nal de inventario y, por ende, del cos-to acumulado de inventario (polari-dades positivas)”.


Figura 6. Modelo mental del director de Logística.

“Costo Acumulado de Inventario” alrealizar cuatro simulaciones. La si-mulación “base” se llevó a cabo en lascondiciones que podríamos denomi-nar normales o iniciales del modelo.En la simulación “TMPO1” se redujoel “Tiempo Mínimo de Procesamien-to de Orden” de dos semanas a unasemana. En la simulación “CS1” seredujo el “Cubrimiento de Seguridad”de dos semanas a una semana. En lasimulación “COMB1” se redujerontanto el “Tiempo Mínimo de Procesa-miento de Orden” como el “Cubri-miento de Seguridad” de dos sema-nas a una semana. Los resultadospara “Costo Acumulado de Inventa-rio” se resumen en la Tabla 1. Paratodas las simulaciones se ha estable-cido un incremento del 20% en lospedidos del cliente a partir de la quin-ta semana, con el fin de introduciruna perturbación en el sistema.

A partir del modelo mental descritoen la Figura 6, podríamos suponerque la decisión más factible sería lade disminuir el cubrimiento de segu-ridad ya que la disminución del tiem-po mínimo de procesamiento de or-den podría implicar la ejecución deproyectos de adquisición de maquina-ria y equipo, entrenamiento de per-sonal o implementación de sistemasde información, proyectos todos estosque necesitarían de un tiempo signi-ficativo (dentro del horizonte de cin-cuenta semanas) para su puesta enmarcha. Nótese que no se han inclui-do dentro del modelo mental del di-rector de Logística los costos ocasio-nados por la ejecución de estos pro-yectos, lo cual haría menos factibleaún la decisión de disminuir el tiem-po de procesamiento de orden.

La Figura 7 muestra en forma gráfi-ca los resultados para la variable


Figura 7. Gráfica de comportamiento de “Costo Acumulado de Inventario”para diferentes condiciones de simulación.

Tabla 1. Resultados para “Costo Acumulado de Inventario” en la quincua-gésima semana en diferentes condiciones de simulación.

Simulación Tiempo Mínimo de Cubrimiento de Costo Acumulado AhorroProcesam. Orden Seguridad de Inventario

base 2 2 10,760,000TMPO1 1 2 7,823,000 2,937,000CS1 2 1 8,432,000 2,328,000COMB1 1 1 5,425,000 5,335,000

Como puede verse en la Tabla 1, lareducción del cubrimiento de seguri-dad es la menos eficiente de las al-ternativas en cuanto a ahorro gene-rado en costos se refiere. Debe ano-tarse que los resultados que implicanuna reducción en el tiempo de proce-samiento de orden suponen una en-

trada en vigencia de esta reducciónantes de la quinta semana.

Otros indicadoresCabe aquí preguntarse: ¿Qué efectotendrían estas decisiones sobre otrosindicadores diferentes del “Costo Acu-mulado de Inventario”. Las Figuras


8 y 9, muestran el comportamientode los indicadores “Eficiencia de Pro-

ducción”, “Facturación Acumulada”,“Capital de Trabajo” y “Nivel de Ser-vicio”.

Figura 8. Gráficas para “Eficiencia de Producción” y “Facturación Acumula-da” en diferentes condiciones de simulación.

Figura 9. Gráficas para “Capital de Trabajo” y “Nivel de Servicio” en dife-rentes condiciones de simulación.

Puede observarse en la Figura 8 quesi bien la eficiencia de producción dis-minuye con el aumento de la deman-da a partir de la quinta semana, cual-quiera de las decisiones tomadas so-bre cubrimiento de seguridad o tiem-po de procesamiento de orden dismi-nuye aún más dicha eficiencia. Sedebe anotar que el comportamientode este indicador, que puede dar lu-gar a una percepción de ineficacia porparte del encargado de producción, no

depende, en este caso, de las decisio-nes de este último, sino de las deci-siones tomadas en otra parte del sis-tema.

De la Figura 8 puede deducirse tam-bién que una reducción en el cubri-miento de seguridad ocasiona no so-lamente una disminución en el costoacumulado de inventario sino tam-bién una reducción en la facturaciónacumulada. Por otra parte la factu-


ración no se ve afectada por una re-ducción en el tiempo de procesamien-to de orden.

La Figura 9 muestra que la disminu-ción en el cubrimiento de seguridadorigina los mejores resultados encuanto a necesidades de capital detrabajo (valoración de inventarios)pero los peores resultados en cuantoa nivel de servicio al cliente (despa-chos/pedidos cliente).

Al revisar todos estos resultados sur-gen las preguntas: ¿Cuál sería enton-ces la mejor decisión que hubiera po-dido tomar el director de Logística?¿Reducir el cubrimiento de seguri-dad? ¿Reducir el tiempo de procesa-miento de orden?¿Reducir ambos si-multáneamente? Si nos fijáramosúnicamente en el objetivo de reducirel costo acumulado de inventario, lamejor decisión hubiera sido reducirambos parámetros simultáneamente,pero los resultados obtenidos para losotros indicadores nos llevan a pregun-tas adicionales: ¿Cómo se compara elahorro en costos obtenido contra ladisminución en la Facturación? ¿Esimportante el tema de liquidez (capi-tal de trabajo) dentro de la situaciónespecífica? ¿Qué tan importante es elservicio al cliente? ¿Resulta “llevade-ro” un nivel de servicio cercano al 90%como el que se obtiene al reducir elcubrimiento de seguridad? Las res-puestas a estas preguntas depende-rán de los objetivos estratégicos de laorganización y de qué tan conscien-tes son aquellos que toman decisio-nes respecto a la alineación de losobjetivos que persiguen con los obje-tivos estratégicos, y a la validez delas relaciones causa-efecto que esta-blezcan entre inductores de actuacióny resultados. Un modelo mental am-

plio que incluya estos aspectos y ten-ga en cuenta la complejidad dinámi-ca presente en la situación, permiti-rá llevar a cabo transacciones entreobjetivos operativos que resulten enun adecuado, no necesariamente óp-timo, comportamiento de los resulta-dos en el mediano y largo plazo, equi-librando el habitual énfasis en la efi-cacia y la eficiencia con la relevanciaque debiera tener lo que Checklandy Scholes (1994) denominan efectivi-dad, es decir, la contribución de loslogros de hoy a la consecución de losobjetivos de largo plazo. La búsque-da de transacciones que logren solu-ciones adecuadas en lugar de solucio-nes óptimas es recalcada por Simon(1989):

Reconciliar puntos de vista alterna-tivos y estimaciones diferentes de losvalores se torna un poco más fácil siadoptamos un punto de vista satis-factorio: si buscamos soluciones losuficientemente buenas en lugar deinsistir en que sólo las mejores habránde tener resultado. Quizá sea posible,y a menudo lo es, encontrar vías deacción que toleren casi todos los inte-grantes de una organización o socie-dad, y que incluso agraden a muchos,siempre que no seamos perfeccionis-tas y no exijamos lo óptimo.

CONCLUSIONES

La dinámica de sistemas es una he-rramienta metodológica que contribu-ye a hacer explícitas las relacionescausa-efecto entre los indicadores lla-mados “inductores de actuación” y losindicadores de resultado. El hecho deestablecer un modelo matemáticopara estas relaciones, que sea suscep-tible de simulación, constituye unapoyo significativo para mitigar las


consecuencias de las limitaciones aso-ciadas con el principio de racionali-dad limitada sobre la calidad de lasdecisiones directivas en una organi-zación, y permite visualizar las tran-sacciones que deben llevarse a caboentre los diferentes objetivos con elfin de conseguir un desempeño ade-cuado, no necesariamente óptimopero sí suficientemente robusto y via-ble, en el logro de los objetivos estra-tégicos.

BIBLIOGRAFIABeltrán, Jesús M. (2000); Indicado-res de gestión, 3R Editores.

Bohm, David (1998); La totalidad yel orden implicados, Kairós.

Brown, Mark G. (1996); Keeping Sco-re. Quality Resources.

Checkland, Peter, Scholes, Jim(1994); La metodología de los siste-mas suaves en acción, Noriega Edito-res.

Kaplan, Robert S., Norton, David P.(2000); Cuadro de mando integral,Gestión 2000.

Kaplan, Robert S., Norton, David P.(2001); Cómo utilizar el cuadro demando integral, Gestión 2000.

Keebler, James S., Durtsche, DavidA. (1999); Keeping Score: Measuringthe Business Value of Logistics in theSupply Chain, Council of LogisticsManagement.

Niven, Paul R. (2002); Balanced Sco-recard Step by Step, John Wiley &Sons.

Simon, Herbert A. (1957); Adminis-trative Behavior: a Study of Decision-Making Processes in AdministrativeOrganizations, Macmillan.

Simon, Herbert A. (1989); Naturale-za y límites de la razón humana, Fon-do de Cultura Económica.

Sterman, John D., (2000); BusinessDynamics: Systems Thinking andModeling for a Complex World, IrwinMcGraw-Hill.

Thomas, Lewis (1974). The Lives of aCell: Notes of a Biology Watcher, Vi-king Press.

CURRÍCULOFernando Antonio Arenas Gue-

rrero. Ingeniero Químico, Uni-versidad Nacional – Bogotá.M.Sc. en Ingeniería Ambiental,Universidad Nacional – Bogo-tá. Especialización en Sistémi-ca, Universidad del Valle. Vein-te años de experiencia empre-sarial en compañías como Cro-ydon S.A., Productos Petroquí-micos S.A., Cabot ColombianaS. A. y Rubbermix S.A., desem-peñando la Gerencia de Inves-tigación y Desarrollo, Gerenciade Producción, Gerencia deOperaciones y Gerencia Técni-ca. Docente en pregrado y pos-grado en las UniversidadesICESI y Javeriana, en los cam-pos de Gestión del Cambio,Aprendizaje Organizacional,Pensamiento Sistémico, Ges-tión del Riesgo, Dinámica deSistemas y Simulación. Asesorde la Dirección de Crédito Pú-blico y Tesorería del Ministeriode Hacienda y del Banco de laRepública en el desarrollo e im-plementación de modelos ma-croeconómicos y financieros.


Aplicación práctica del diseño de pruebasde software a nivel de programación


Oscar Hernando Guzmán Corté[email protected]

ABSTRACTTests must be present in all softwarelife cycle phases, including require-ments, analysis and design, progra-mming, implementation and mainte-nance.

This article presents the design andexecution scheme of software test,specifically centered in programmingtests defined to Software Develop-ment department of Icesi University.The requirements tests scheme isshown in a basic form. The schemesof analysis and design tests, imple-mentations tests, and maintenancetests, are not shown because theyaren’t totally defined.

KEYWORDSProgramming test, requirementstest, test design.

RESUMENLas pruebas deben presentarse a lolargo de todo el ciclo de vida del de-sarrollo de software, pasando por re-querimientos, análisis y diseño, pro-gramación, puesta en marcha y man-tenimiento.

El siguiente artículo presenta el es-quema de diseño y ejecución de prue-bas de software, centrándose especí-ficamente en las pruebas de progra-mación, definidas para el departa-mento de Desarrollo de Sistemas de


la Universidad Icesi. El esquema depruebas de requerimientos se mues-tra de manera general, mientrasque del esquema de pruebas de aná-lisis y diseño, de puesta en marchay de mantenimiento no se presen-tan por no estar todavía totalmentedefinidas.

PALABRAS CLAVESPruebas de programación, pruebas derequerimientos, diseño de pruebas.

Clasificación: B


INTRODUCCIÓNEn el mundo de la computación tancambiante de hoy en día, y sobre todode gran evolución tecnológica, y envista de las exigencias que ha traídola globalización, se ha hecho necesa-rio desarrollar metodologías para ase-gurar la calidad de los productos desoftware y obtener un mejoramientocontinuo de todos los procesos rela-cionados con el desarrollo de soft-ware. Entre tantas metodologías, sepueden mencionar: STD (SoftwareTechnology Diagnostic), CMM (Capa-bility Maturity Model), Bootstrap,Trillium, y HealthCheck. Vale la penaaclarar que CMM es un esquema dediagnóstico y de evaluación de lamadurez del proceso de desarrollo desoftware, más que un esquema demejoramiento de procesos.

Todos estos mecanismos de evalua-ción y mejora en el desarrollo de soft-ware han permitido que las empre-sas implementen la metodología quemás se ajuste a sus necesidades y for-ma de trabajar. Desde este enfoque,el equipo de Desarrollo de Sistemasde la Universidad Icesi ha acopladoalgunos conceptos relevantes de

CMM y establecido estándares paradefinir su propio modelo de asegura-miento de la calidad de software; ano-tando que algunos elementos de di-cho modelo están en proceso de defi-nición, otros ya se están implemen-tando, y otros están pendientes deajustarlos a nuestras necesidades.

A continuación, se presenta el proce-so de diseño y ejecución de pruebasde software (básicamente pruebas deprogramación) que se ha definidopara el departamento de Desarrollode Sistemas de la Universidad Icesi.

1. ¿CÓMO LLEGARA LA DEFINICIÓNDEL ESQUEMA DE PRUEBASDE SOFTWARE?CMM, en términos generales, proveeuna guía de cómo obtener el controldel proceso de desarrollo y manteni-miento de software, de cómo evolu-cionar hacia una cultura de ingenie-ría de software. La Figura 1 muestrael esquema general de cinco nivelesde madurez del proceso de softwarepropuesto por CMM, y la Figura 2revela la estructura de cada nivel demadurez.

Figura 1. Niveles de madurez del proceso de software.


Como se ha mencionado anteriormen-te, se ha revisado el esquema pro-puesto por CMM para determiar elestado actual del proceso de desarro-llo de software, y establecer las ac-ciones a tomar en búsqueda de alcan-zar un mayor nivel de madurez endicho proceso.

Y, en lo concerniente específicamen-te al esquema del plan de asegura-miento de calidad de software, seidentificó para los tres primeros ni-veles lo siguiente:

• Nivel 1. Proceso Inicial:— Proceso ad hoc que puede ser

caótico.

— No hay procedimientos forma-lizados, estimados de costos yplaneación de proyectos.

— Las herramientas no estánbien integradas con el procesoni se aplican de manera uni-forme.

— El control de cambios no es es-tricto.

— La instalación y el manteni-miento del software presentanproblemas.

— No hay un mecanismo que ase-gure la utilización de procedi-mientos formales.

— Se debe establecer un plan for-mal de aseguramiento de cali-dad de software.

• Nivel 2. Proceso Repetible:

— Riesgos:

* Nuevas herramientas ymétodos podrían afectar elproceso.

Figura 2. Estructura de los niveles de madurez de CMM.


* Nuevo tipo de producto pue-de cambiar todo el proceso.

* Cambios organizacionalesgrandes.

— Establecer un grupo de proce-sos: Es el encargado de la de-finición del proceso de desarro-llo, la identificación de necesi-dades y oportunidades a nivelde tecnología, la asesoría aproyectos, informes gerencia-les quincenales sobre el esta-do y desempeño de los proce-sos. Si son de menos de cuatropersonas, es suficiente con uncomité conformado por profe-sionales con experiencia o con-sultores.

El propósito del grupo es elmejoramiento del proceso desoftware.

— Establecer una arquitecturadel proceso de desarrollo desoftware (ciclo de vida de de-sarrollo de software): Son lasactividades técnicas y admi-nistrativas requeridas para laejecución apropiada del proce-so de desarrollo. Como arqui-tectura se entiende tareas consus prerrequisitos, descripcio-nes funcionales, procedimien-tos de verificación y especifi-caciones que indican si una ta-rea se ha completado.

— Introducir una familia de mé-todos de ingeniería de soft-ware y tecnologías, tal comoinspecciones de código y dise-ño, métodos formales de dise-ño, sistemas de control de li-brerías y métodos de prueba,

prototipos, lenguajes de imple-mentación sofisticados, etc.

— Se debía establecer un progra-ma de SQA que asegurará que:

* Se utiliza una metodologíade desarrollo de softwareapropiada.

* Los proyectos utilizan es-tándares y procedimientos.

* Se llevan a cabo revisionesy auditorías independien-tes.

* Existe documentación parasoportar mantenimiento ymejoras.

* La documentación se pro-duce durante y no despuésdel desarrollo de software.

* Hay mecanismos para con-trolar cambios.

* Las pruebas hacen énfasisen las áreas de alto riesgo.

* Cada tarea de software secompleta a satisfacción,antes de continuar con lasiguiente.

* Las desviaciones con res-pecto a estándares y proce-dimientos se detectan lomás pronto posible.

* El trabajo de control de ca-lidad de software se traba-ja con respecto a unos es-tándares establecidos.

* El plan de aseguramientode calidad y el plan de de-sarrollo de software soncompatibles.


— Este nivel contempla cincoáreas claves: gestión de reque-rimientos, planeación del pro-yecto, seguimiento y supervi-sión del proyecto, asegura-miento de la calidad, gestiónde la configuración del soft-ware, y gestión de los subcon-

tratos de software. En la Ta-bla 1 se muestra el puntajeobtenido para las actividadesdefinidas del área clave deaseguramiento de calidad. Y,en la Tabla 2 se muestra laescala de puntajes utilizada.

0.0 1

0.0 2

0.0 3

0.0 4

0.0 5

Actividades Puntaje Prioridad

Un plan de SQA es preparado para el pro-yecto de software de acuerdo con los proce-dimientos existentes y documentados, y sesigue por parte de los integrantes del Equi-po de Desarrollo de Software.

Las actividades del grupo de SQA son rea-lizadas de acuerdo con el plan de SQA defi-nido.

El líder del proyecto revisa las actividadesdel GIS para verificar el cumplimiento delplan y los estándares.

Se debe presentar el informe de calidad delproyecto, teniendo en cuenta las desviacio-nes identificadas en las actividades o en losproductos de software.

El encargado de investigar SQA debe defi-nir, programar y coordinar revisiones pe-riódicas de las actividades, para garantizarel cumplimiento total del plan SQA.

Puntaje máximo 5.0

Puntaje total obtenido 0.0

Tabla 1. Puntajes y prioridades de las actividadesdel área clave de aseguramiento de calidad.

Tabla 2. Escala de puntajes

Puntaje Descripción

0.0 No se realiza0.5 Se realiza parcialmente1.0 Se realiza totalmente


• Nivel 3. Proceso definido:

Se requiere trabajar en los siguien-tes aspectos:

— Estándares de software.

— Inspecciones de software.

— Pruebas de software.

— Trabajo adicional en gestión deconfiguraciones.

— Definición del proceso de soft-ware.

— Conformación del grupo delproceso de ingeniería de soft-ware.

Debido a este análisis anterior, sedecidió crear el Equipo de Asegura-miento de Calidad de Software, elcual se encarga de todo el proceso desqa. En el Anexo 1 se presenta unalista de chequeo de aseguramiento decalidad. Dentro del proceso de sqa, semuestra en el siguiente punto, lo re-lacionado con el diseño y ejecución delas pruebas de software.

2. DISEÑO Y EJECUCIÓNDE PRUEBAS DE SOFTWAREUna definición que se puede dar depruebas es la siguiente: “Una activi-dad en la cual un sistema o uno desus componentes se ejecuta en cir-cunstancias previamente especifica-das, los resultados se observan y re-gistran, y se realiza una evaluaciónde algún aspecto”.

La prueba es un elemento crítico parala calidad del software. La importan-cia de los costos asociados a los erro-res promueven la definición y aplica-ción de un proceso de pruebas minu-ciosas y bien planificadas. Las prue-bas permiten validar y verificar elsoftware, entendiendo como valida-ción del software el proceso que de-termina si el software satisface losrequisitos, y verificación como el pro-ceso que determina si los productosde una fase satisfacen las condicio-nes de dicha fase.

Las estrategias de pruebas permitenenfocar el plan de pruebas; éste com-prende la visión global del proceso depruebas, y la definición de activida-des y roles involucrados en cada unade ellas.

Las pruebas que se han considerado,dentro del plan de pruebas, son lassiguientes:

• Pruebas de requerimientos.• Pruebas de análisis (pendiente).

• Pruebas de diseño (pendiente).

• Pruebas de unidad.

• Inspecciones.

• Pruebas de información no perió-dica.

La Figura 3 muestra, gráficamente,las pruebas de software consideradas.


Figura 3. Pruebas de software consideradas.

con la lista de chequeo general deldocumento y la lista de chequeo derequerimientos.

La corrección del contenido del docu-mento será responsabilidad del ana-lista y el usuario líder, quienes sonlos encargados de aprobar los reque-rimientos definidos en el documento.El diagrama del proceso de elicitaciónde requerimientos se muestra en laFigura 4, y el detalle del mismo en laTabla 3, que se presentan a continua-ción.

2.1 Pruebas de requerimientos

Los requerimientos de software de-ben tener una explicación clara, pre-cisa y completa del problema que fa-cilite el análisis de errores y la gene-ración de casos de prueba. Un asun-to de gran importancia es asegurarla corrección, coherencia y exactitudde los requisitos.

Durante el proceso de elicitación derequerimientos, una persona, desig-nada por el Equipo de Aseguramien-to de Calidad, revisará el documentode especificación de requerimientos,


Figura 4. Proceso de elicitación de requerimientos

Detalle

Se determina si los objetivos son claros,verificables y necesarios (entre otros).El resultado de esta revisión se consig-na en la lista de chequeo de objetivos.

Mediante un proceso iterativo se definela funcionalidad esperada del software,y se consigna usando el documento derequisitos del sistema.

Debe verificar el documento de requeri-mientos, usando la lista de chequeo ge-neral del documento de especificación derequerimientos LCH lista de chequeogeneral del documento de elicitación yanálisis de requerimientos.

Revisan cada requerimiento (consisten-cia, ambigüedad, etc.), usando para ellola lista de chequeo de requerimientos.

Encargado

Revisor SQA

Especificador derequerimientos

Revisor SQA

Revisor SQA

Recursos

Lista de chequeode objetivos

Requerimientosdel sistema

Lista de chequeogeneral del documentode elicitación y análisis

de requerimientos

Lista de chequeo derequerimientos.

Tabla 3. Detalle del proceso de elicitación de requerimientos.

INICIO

Solicitud

Obtener información sobredominio del problema

Preparar las reuniones

Actualiza sistemacon los objetivos

Actualiza sistemacon requisitos

Establecimientodocumento línea base

FIN

Define e identifica losobjetivos del sistema

Aprueba y firmael documento

DefinirRequisitosfuncionales

DefinirRequisitos nofuncionales

Verifica los requisitosSí No

Aprobación

Verificaciónde objetivos

Sí

No

Aprobación

Aprobación

Verificaciónde requerimientos

Sí No


2.2. Pruebas de unidad

El proceso de pruebas de unidad sedescribe en el siguiente diagrama de

la Figura 5, así como el detalle delmismo en la Tabla 4.

2.3. Inspecciones

¿Aprobado?

Programador Diseñador de pruebas Ejecutor de pruebas

Programación

Entrega pruebas de funcionalidad

Revisión estándares gráficos

Revisión funcionalidad

No

Sí

Entrega casos de prueba y/o formato inspecciones

Preparar casos de prueba

Diseñar Caja Blanca

No

Ejecutar Caja Negra

Ejecutar Caja Blanca

Inspecciones

Figura 5. Proceso de pruebas de unidad.

¿Crítico?


Det

alle

El e

ncar

gado

de

elab

orar

los

caso

s de

pru

eba

reci

be d

el a

nalis

-ta

el d

iseñ

o de

la fo

rma/

repo

rte

y un

a de

scri

pció

n de

la fu

ncio

-na

lidad

, usa

ndo

el f

orm

ato

de p

rueb

as d

e fu

ncio

nalid

ad. A

sím

ism

o, e

l dis

eñad

or d

e lo

s ca

sos

de p

rueb

a de

be r

ecib

ir la

s lis

-ta

s de

che

queo

de

prog

ram

ació

n ya

rev

isad

as p

or e

l ana

lista

/pr

ogra

mad

or (V

er A

nexo

s 4,

5, 6

, y 8

).

Si e

l mód

ulo

es n

uevo

, se

elab

ora

el á

rbol

de

clas

es e

quiv

alen

tes,

la ta

bla

de p

arti

cion

es y

un

lista

do d

e ca

sos

de p

rueb

a.

Si e

l mód

ulo

no e

s nu

evo,

deb

en r

evis

arse

los

docu

men

tos

deca

ja n

egra

par

a es

tabl

ecer

los

cam

bios

, que

pue

den

ser:

i.E

limin

ació

n de

ent

rada

s, lo

cua

l sig

nific

a qu

e se

deb

en r

e-vi

sar

todo

s lo

s ca

sos

de p

rueb

a qu

e in

cluy

an e

stas

ent

ra-

das

para

mod

ifica

rlos

apr

opia

dam

ente

.

Tam

bién

es

posi

ble

que

se e

limin

en a

lgun

os c

asos

de

prue

ba.

ii.In

clus

ión

de e

ntra

das,

lo c

ual s

igni

fica

revi

sar

los

caso

s de

prue

ba e

xist

ente

s y

adic

iona

r nu

evos

cas

os.

iii.

Elim

inac

ión/

Incl

usió

n de

sal

idas

: im

plic

a re

visa

r lo

s ca

sos

de p

rueb

a pa

ra e

stab

lece

r lo

s ca

mbi

os.

Cad

a ca

so d

e pr

ueba

deb

e de

jars

e do

cum

enta

do y

se

debe

in-

gres

ar e

sta

info

rmac

ión

en e

l sis

tem

a.Tab

la 4

. Det

alle

del

pro

ceso

de

pru

ebas

de

un

idad

1. P

rep

arac

ión

de

caso

s d

e p

rueb

a

Res

tric

cion

esE

ncar

gado

sR

ecur

sos

Form

ato

de p

rueb

as d

e ca

jane

gra

(Ver

Ane

xo 1

0)

Form

ato

de c

asos

de

prue

ba(V

er A

nexo

12)

Form

ato

de p

rueb

as d

efu

ncio

nalid

ad (V

er A

nexo

13)

.A

nalis

ta d

iseñ

ador

de c

asos

de

prue

ba.

Dis

eñad

or d

e ca

sos

de p

rueb

a.

Dis

eñad

or d

e ca

sos

de p

rueb

a.


Tab

la 4

. Det

alle

del

pro

ceso

de

pru

ebas

de

un

idad

2. R

evis

ión

de E

stán

dare

s gr

áfic

os

Det

alle

Rea

lizar

la re

visi

ón in

dica

da e

n la

list

a de

cheq

ueo

de e

stán

da-

res,

y d

ejar

con

sign

ados

los

resu

ltad

os y

la fe

cha

de la

rev

isió

nen

el s

iste

ma.

Res

tric

cion

es

List

a de

che

queo

de p

rese

ntac

ión

de fo

rmas

(Ver

Ane

xo 7

)

Enc

arga

dos

Ana

lista

Com

prob

ar q

ue s

e cu

mpl

a lo

est

able

cido

en

la li

sta

de c

hequ

eode

func

iona

lidad

de

form

as o

rep

orte

s, s

egún

cor

resp

onda

. De-

jar

docu

men

tado

el r

esul

tado

y la

fech

a de

rea

lizac

ión

de e

sta

acti

vida

d en

el s

iste

ma.

3. R

evis

ión

de fu

ncio

nali

dad

List

a de

che

queo

de

func

io-

nalid

ad d

e ap

licac

ione

s-fo

rmas

(Ver

Ane

xo 2

)

List

a de

che

queo

de

func

io-

nalid

ad d

e ap

licac

ione

s–re

port

es (V

er A

nexo

3)

Ana

lista

Rec

urso

s

El e

jecu

tor

debe

con

tar

con

el m

ódul

o de

sarr

olla

do y

ten

er t

o-do

s lo

s pe

rmis

os q

ue te

ndrí

a el

usu

ario

fina

l.A

dem

ás, d

ebe

cont

ar c

on lo

s ca

sos

de p

rueb

as d

iseñ

ados

.

Se d

eben

eje

cuta

r to

dos

los

caso

s de

pru

eba

y co

nsig

nar

los

re-

sult

ados

obt

enid

os e

n el

form

ato.

4. E

jecu

ción

de

prue

bas

de c

aja

negr

a

Eje

cuto

r de

pru

ebas

.

Form

ato

de r

esul

tado

s de

ejec

ució

n de

pru

ebas

(Ver

Ane

xo 1

1).

Eje

cuto

r de

prue

bas.


5. D

iseñ

o y

ejec

ució

n de

pru

ebas

de

caja

bla

nca

[opc

iona

l]

Tab

la 4

. Det

alle

del

pro

ceso

de

pru

ebas

de

un

idad

Dis

eñad

or d

e pr

ueba

s.

Rec

urso

sR

estr

icci

ones

Enc

arga

dos

Det

alle

s

Prep

arac

ión

de lo

s ca

sos

de p

rueb

a us

ando

la t

écni

ca d

el c

a-m

ino

bási

co. E

l ana

lista

pro

porc

iona

el c

ódig

o de

la fu

nció

n y

el c

álcu

lo d

e la

com

plej

idad

cic

lom

átic

a.

Se e

stab

lece

la li

sta

de c

asos

de

prue

ba y

se

docu

men

ta c

ada

uno.

Se e

jecu

tan

las

prue

bas

para

cad

a ca

so e

ncon

trad

o y

se c

on-

sign

an lo

s re

sult

ados

.

Dis

eñad

or d

e pr

ueba

s.

Eje

cuto

r de

pru

ebas

.

6. I

nspe

ccio

nes

[opc

iona

l]

Rea

lizar

la in

spec

ción

sig

uien

do la

list

a de

cheq

ueo

y an

otan

-do

los

erro

res

enco

ntra

dos

en e

l for

mat

o.

Rea

lizar

la r

euni

ón d

e in

spec

ción

, ori

enta

da p

or e

l mod

era-

dor.

El r

evis

or y

el m

oder

ador

exp

onen

los

erro

res

halla

dos.

El a

nalis

ta a

clar

a la

s du

das

o in

dica

si h

ubo

un e

rror

de

apre

-ci

ació

n

Se co

nsig

nan

los

resu

ltad

os co

nsol

idad

os d

e la

insp

ecci

ón y

se

entr

egan

al a

nalis

ta.

FOR

Ins

pecc

ione

s-R

egis

tro

dede

fect

os (V

er A

nexo

9).

Rev

isor

Mod

erad

orA

nalis

ta

Rev

isor

Mod

erad

or

Ana

lista

Mod

erad

or

Exc

epci

ones

Cua

ndo

el m

ódul

o se

a cr

ític

o, s

e ej

ecut

an la

s pr

ueba

s de

caj

a bl

anca

y la

s in

spec

cion

es


2.3 Inspecciones

El objetivo de las inspecciones es im-plementar un proceso formal de revi-sión detallada del producto por partede pares y un moderador, con el pro-

pósito de encontrar defectos en unaetapa muy temprana del desarrollodel producto. El diagrama de la Fi-gura 6 muestra el proceso de inspec-ciones. El detalle de dicho proceso seencuentra en la Tabla 5.

Figura 6. Proceso de inspecciones.

Programador

Preparar producto, listasde chequeo y material soporte.

Revisiónindividual

Moderador Revisor

Corrección dedefectos

Asignaciónde revisores

Reunión deInspección

Revisión Sí

¿Cambiogrande?

No

Aprobaciónde código


Tab

la 5

. Det

alle

del

pro

ceso

de

insp

ecci

ón

1. E

labo

rar

docu

men

tos

para

insp

ecci

ón

El

anal

ista

pre

para

los

sig

uien

tes

elem

ento

s pa

ra l

a in

spec

-ci

ón:

—có

digo

fue

nte

(líne

as n

umer

adas

o i

dent

ifica

ción

de

cada

sub-

mód

ulo)

.

—m

ater

ial d

e so

port

e, c

omo

desc

ripc

ión

de la

func

iona

lidad

.

—lis

ta d

e ch

eque

o pa

ra in

spec

cion

es.

Det

alle

Res

tric

cion

es

Form

ato

de in

spec

cion

es–

Reg

is-

tro

de d

efec

tos

(Ver

Ane

xo 9

).

Enc

arga

dos

Ana

lista

Rec

urso

s

2. A

sign

ació

n de

rev

isor

es

El m

oder

ador

asi

gna

dos

revi

sore

s pa

ra e

ste

mód

ulo,

con

expe

-ri

enci

a en

des

arro

llo d

e pr

ogra

mas

en

el le

ngua

je e

n el

cua

l se

elab

oró

el m

ódul

o a

eval

uar

o, s

i est

o no

es

posi

ble,

con

exp

e-ri

enci

a en

pro

gram

ació

n en

gen

eral

.

Una

vez

asi

gnad

os lo

s re

viso

res,

se

les

entr

ega

una

copi

a de

lm

ater

ial q

ue p

rese

ntó

el a

nalis

ta y

el f

orm

ato

para

con

sign

arlo

s re

sult

ados

de

la in

spec

ción

.

Se e

stab

lece

una

fech

a de

reu

nión

y s

e in

dica

est

a fe

cha

a lo

sre

viso

res

y al

ana

lista

.

Uno

de

los

revi

sore

s de

be d

ese

r de

un p

roye

cto

dife

rent

e al

del p

rodu

cto

insp

ecci

onad

o.

Se r

ealiz

a la

insp

ecci

ón s

igui

endo

la li

sta

de c

hequ

eo y

ano

tan-

do lo

s er

rore

s en

cont

rado

s en

el f

orm

ato.

3. R

evis

ión

indi

vidu

alFo

rmat

o de

insp

ecci

ones

.

Reg

istr

o de

def

ecto

s.

Mod

erad

or

Rev

isor

Mod

erad

or

Mod

erad

or

Mod

erad

or


Det

alle

Res

tric

cion

esE

ncar

gado

sR

ecur

sos

El m

oder

ador

ori

enta

est

a re

unió

n, h

acie

ndo

que

cada

revi

sor

(y é

l mis

mo)

exp

onga

n br

evem

ente

los

erro

res

enco

ntra

dos.

El a

nalis

ta a

clar

a du

das

o in

dica

si h

ay u

n er

ror

de a

prec

ia-

ción

por

par

te d

e lo

s re

viso

res,

per

o no

pue

de t

rata

r de

dar

expl

icac

ione

s so

bre

algú

n er

ror o

indi

car f

orm

as d

e co

rreg

irlo

.

El m

oder

ador

cons

igna

en

el fo

rmat

o lo

s re

sult

ados

cons

olid

a-do

s de

la in

spec

ción

y lo

s pa

sa a

l ana

lista

par

a qu

e lo

s co

rrija

.

4. R

euni

ón d

e In

spec

ción

Mod

erad

orR

evis

or

Mod

erad

or

Ana

lista

Exc

epci

ones

Si e

l mod

erad

or e

s nu

evo,

se

debe

exp

licar

en

qué

cons

iste

el p

roce

so d

e in

spec

cion

es.

Tab

la 5

. Det

alle

del

pro

ceso

de

insp

ecci

ón


2.4. Pruebas de información noperiódica

La Figura 7 muestra el diagrama del

proceso de pruebas de información noperiódica. El detalle del proceso seencuentra en la Tabla 6.

Usuario

Solicitud a travésde solicitudes

No

¿Correcto?

Sí

No

¿Correcta lainformacióngenerada?

Sí

Firma documentoCINP

Analista

Reunión para detallar el requerimientoy pactar conclusiones

Impresión formato “Control deInformación no periódica”

Generación deinformación

No

SíEnvío de

información

TerminaciónRequerimiento

Tester

Revisión Listasde Chequeo

¿Bien?

Figura 7. Proceso de pruebas de información no periódica.


Tab

la 6

. Det

alle

del

pro

ceso

de

pru

ebas

par

a in

form

ació

n n

o pe

riód

ica

Det

alle

Rec

urso

sR

estr

icci

ones

Enc

arga

dos

Usu

ario

Ingr

eso

de la

solic

itud

a tr

avés

del

sist

ema

de so

licitu

des.

Reun

ión

para

det

alla

r el r

eque

rimie

nto

y pa

ctar

conc

lusi

ones

.

Se im

prim

e el

form

ato

de co

ntro

l de

info

rmac

ión

no p

erió

dica

: (*1

).

El u

suar

io v

erifi

ca la

info

rmac

ión

en e

l for

mat

o.

Com

prob

ado

el fo

rmat

o, se

gen

era

la in

form

ació

n pe

dida

.

Revi

sión

de

las l

ista

s de

cheq

ueo.

(*2)

Apro

bada

la in

form

ació

n, se

env

ía a

l usu

ario

.

El u

suar

io co

rrob

ora

la in

form

ació

n ge

nera

da.(*

3)

Si la

info

rmac

ión

es co

rrec

ta, f

irma

el d

ocum

ento

CIN

P.

Fina

liza

el re

quer

imie

nto.

1. P

rueb

as e

insp

ecci

ones

par

a in

form

ació

n no

per

iódi

ca

Ana

lista

Usu

ario

Ana

lista

Usu

ario

Ana

lista

SQA

Ana

lista

Usu

ario

Usu

ario

Ana

lista

Exc

epci

ones

(*)

1.Si

el f

orm

ato

de c

ontr

ol d

e in

form

ació

n no

per

iódi

ca n

o es

cor

rect

o, s

e vu

elve

a r

ealiz

ar la

reu

nión

del

ana

lista

y e

l usu

ario

par

a de

talla

r el

requ

erim

ient

o.

2.Si

la r

evis

ión

de la

list

a de

che

queo

no

es a

prob

ada,

el a

nalis

ta v

uelv

e a

gene

rar

la in

form

ació

n.

3.Si

el u

suar

io n

o ap

rueb

a la

info

rmac

ión

gene

rada

, se

vuel

ve a

rea

lizar

la r

euni

ón d

el a

nalis

ta y

el u

suar

io p

ara

deta

llar

el r

eque

rim

ient

o y

el p

roce

so c

onti

núa

desd

e es

a et

apa.


3. AUTOEVALUACIÓN SOBREEL PROCESO DE PRUEBASLas encuestas y evaluaciones son unaherramienta de gran valor para me-dir la percepción y el conocimiento delas personas con respecto a algúntema en particular. Como parte de unproceso de concientización, evalua-ción y aprendizaje por parte de losprogramadores, se ha diseñado un

formato de autoevaluación que per-mite determinar, en alguna medida,el conocimiento que se tiene del pro-ceso de pruebas. Los resultados de laautoevaluación sirven de retroali-mentación dentro del proceso de prue-bas de software, y son utilizados paradireccionar las medidas que se ten-gan que tomar para solucionar losproblemas identificados (Ver Tabla 7).

Tabla 7. Formato de autoevaluación sobre el proceso de pruebas

Determine si las siguientes afirmaciones son verdaderas o falsas.En el caso de las falsas explique la razón

1. Deben realizarse inspecciones para todos los módulos nuevos.

2. Antes de codificar un módulo nuevo el usuario debe haber aprobadoel diseño gráfico (I/O) del mismo.

3. Al terminar un módulo, el analista debe revisar los estándares gráfi-cos y consignar los resultados de esta revisión en el sistema.

4. El analista, además de programar, está involucrado en las siguientesactividades de pruebas: revisiones de funcionalidad, revisiones de es-tándares gráficos y aprobación del diseño gráfico por parte del usua-rio.

5. Cuando se modifica un módulo debe realizarse de nuevo la prueba decaja negra completa (incluir todos los casos de prueba).

Complete las siguientes frases

1. En un proceso de inspecciones, el papel de un analista (diferente aquien realizó el módulo a inspeccionar), es:

2. Si otro analista le envía un nuevo módulo para que lo revise, usteddebe realizar las siguientes actividades:

3. Si al realizar pruebas de caja negra se encuentran errores, el analistadebe recibir los siguientes documentos:

Y los pasos a seguir son:

4. Las técnicas de caja blanca que se usarán, de acuerdo con el procesode pruebas del equipo, son:

5. Para que la persona encargada de las pruebas pueda elaborar los ca-sos de prueba usando la caja negra, el analista debe proporcionarle:

Y usando caja blanca:


Table 7. Formato de autoevaluación sobre el proceso de pruebas

Preguntas

1. Explique algunas de las actividades que realiza una persona de SQA.

2. Si usted es nombrado revisor en un proceso de inspección, ¿dóndedebe buscar información sobre este proceso? Si se requiere llenarun formato, ¿dónde debe buscarlo?

3. ¿Quién define cuándo un módulo es crítico? ¿Por qué es necesariosaber si un módulo es crítico?

4. ¿Cómo puede usted contribuir a mejorar este proceso?

Repaso final

1. Exponga, con un ejemplo, un caso donde no es necesario seguir todoel proceso de pruebas y explique por qué no lo considera conveniente.

2. Exponga, con un ejemplo, un caso de un módulo que se deba consi-derar como crítico.

3. Explique, con sus propias palabras, todo lo que tiene que hacer (re-lacionado con las pruebas) cuando se va a desarrollar un módulonuevo.

4. Explique qué cambia con respecto al punto anterior cuando se varealizar una modificación a un módulo existente.


Fecha: Analista:

ANEXOS

Anexo 1

Lista de chequeo de aseguramiento de calidad

¿Existe alguien en su organización res-ponsable por los procesos de pruebas?

¿Tiene y usa un estándar para el plande pruebas?

¿Tiene y usa un estándar para las prue-bas de unidad?

¿Tiene y usa un estándar para el repor-te de la ejecución de las pruebas?

¿La planeación y ejecución de pruebasse realiza en paralelo con el proceso dedesarrollo de software?

¿Se verifica que las especificaciones es-tén correctamente implementadas?

¿Se verifica que las expectativas delcliente sean satisfechas?

¿Los probadores verifican la precisión ycompletitud de productos internos talescomo el documento de requerimientos olos diseños?

¿Los probadores reportan los defectos alequipo de desarrollo de software para co-rrección?

¿Los probadores identifican la prioridadde los riesgos del negocio para el desa-rrollo del plan de pruebas?

¿Existen objetivos de pruebas mediblespara cada sistema de software que estásiendo probado?

¿Los objetivos están alineados con losriesgos del negocio?

Revisión de aseguramiento de calidad

Actividad Sí No No Informaciónaplica adicional


¿Se usan métricas para mejorar el pro-ceso de aseguramiento de la calidad?

¿Los probadores han definido pronós-ticos de defectos basándose en datosy experiencias previos?

¿Existe un proceso de mejoramientocontinuo para su proceso de pruebas?

¿Los tipos de defectos están identifi-cados?

¿Se registra, acumula y se usan losdatos de fallas para evaluar la efecti-vidad del proceso de pruebas y produ-cir un software libre de defectos?

¿Se usan métricas para planear y eva-luar el proceso de pruebas?

¿Tiene un proceso de entrenamientode probadores?

¿El uso de una herramienta automa-tizada de pruebas es parte significa-tiva de su proceso?




Revisión de estándares de presentación


¿Están claramente definidos los blo-ques de información (Frames)?

¿Tiene los encabezados de título y nom-bre de aplicación correctos?

¿Las etiquetas de los campos son cla-ras y representativas?

¿Los campos de despliegue están com-pletamente inhabilitados y del colorrespectivo?

¿Los campos de solamente despliegueestán claramente identificados?

¿Tiene los colores estándar?

¿Los campos fecha tienen el formatoDD-MON-RRRR y se puede ingresarlos datos como Ej: 12ago2001?

Cuando se tiene una forma con múlti-ples tabs, ¿se conoce cuál es el registropadre de los tabs?

¿La forma tiene la dimensión correcta?

¿Los Radio Groups tienen un frame quelos abarca?

¿Los campos están alineados en formacorrecta?

¿Los campos requieren y tienen Tooltip?

¿Los LOVs tienen el tamaño y la posi-ción adecuados (que no requieran sermovidos)?

¿Los LOV’s están heredados?

Anexo 2

Lista de chequeo de estándares de presentacióny funcionalidad de la aplicación para formas

Fecha:

Forma: Descripción:

Analista: Revisor:




¿Los barras de Scroll son blancas y deancho 15?

¿Están los RadioButtons azules y he-redan de la propiedadVA_RadioButtons?

¿Están habilitados los botones del tool-bar de manera adecuada y correspon-den con las teclas de función?

Revisión de funcionalidad


¿La forma realiza la función que senecesita?

¿La forma ha sido ingresada a SIABDcon todas las funciones, tablas y rolesasociados?

¿Los datos de la forma cambian en for-ma sincronizada?

¿Es rápido y fácil el manejo de la for-ma?

Cuando se cambia el valor de un campode entrada, ¿se modifica también elcampo de despliegue?

¿Los bloques hijos están coordinadoscon el bloque padre en consulta, borra-do y cuando se limpia la forma?

Los campos que hacen referencia a da-tos de otras tablas ¿tienen cada uno sulista de valores?

¿Las listas de valores son lentas pararecuperar la información?

¿El tiempo de respuesta es adecuado?


Revisión de funcionalidad


¿El orden de navegación de los camposes el correcto?

¿Los mensajes graves son manejadosadecuadamente?

¿Los campos Validate from LOV funcio-nan adecuadamente?

¿Si el reporte requiere mucho tiempo,esto le es notificado al usuario?

¿Está la forma documentada?

¿Si llama reportes, la extensión de losreportes es la correcta? (NO rdf, debeestar sin extensión).

Revisión del código y los datos que retorna


¿Se ha realizado el proceso de pruebaformal?

¿Está la mayor cantidad de código enla base de datos?

¿Se ha realizado el proceso de afina-miento Sql?

Comentarios adicionales


Revisión de estándares de presentación


¿El reporte tiene el nombre del siste-ma correcto?

¿El reporte tiene los encabezados de tí-tulo y nombre de aplicación correctos?

¿El reporte tiene la fecha de genera-ción?

¿El reporte tiene el número de páginay el total de páginas?

¿Están claramente definidos los blo-ques de información?

¿Las etiquetas de los campos son cla-ras y representativas?

¿El reporte tiene los colores estánda-res? Negro y tonos de grises.

¿Los campos fecha tienen el formatoDD-MON-YYYY?

¿Los campos están alineados en formacorrecta?

¿Se ha utilizado la indentación paramejorar la legibilidad del reporte?

¿El reporte tiene enumeradas las filas?

¿El reporte tiene subtotales y totalesde control?

¿El reporte tiene, en la parte superior,las condiciones de generación del lista-do?

¿El reporte tiene el visto bueno delusuario?

Anexo 3

Lista de chequeo de estándares de presentacióny funcionalidad de la aplicación para reportes

Fecha:

Reporte: Descripción:

Analista: Revisor:


Revisión del Código


¿Se ha hecho revisión por pares?

¿Se ha realizado el proceso de afina-miento sql?

¿Está la mayor cantidad de código en labase de datos?

¿El código cumple con los estándares?

¿Está el reporte registrado en SIABD?


Anexo 4

Lista de chequeo de estándares de tablas

Fecha:

Tabla: Descripción:

Analista:

Estándares de las tablas


¿El nombre de la tabla es correctosegún los estándares?

¿Tiene las descripciones de la co-lumna en la base de datos?

¿Tiene las llaves e índices adecua-dos?

¿La tabla ha sido recreada tenien-do en cuenta su uso?


Anexo 5

Lista de chequeo de estándares de funciones y procedimientos

Revisión de estándares


Fecha:

Func/Proc: Descripción:

Analista: Revisor:

¿El nombre cumple con los estándares?

¿El código cumple con los estándares?

¿Está la función/procedimiento docu-mentado?

¿Se ha realizado el proceso de afina-miento sql?

¿Se ha registrado en SIABD?

¿Se usan todas las variables, constan-tes y parámetros?

¿La asignación de valores a las varia-bles, constantes y parámetros tiene unpropósito?

¿Son correctas las validaciones de con-diciones?

Por ejemplo: código no alcanzable, ciclosinfinitos, división por cero, verificaciónde rangos, redondeos.

¿Faltan validaciones?

¿Se manejan todas las posibles excep-ciones?

¿Las variables que guardan datos decolumnas de tablas se han definido deacuerdo con esto?

Tabla.columna%type

Si se llaman otras funciones y/o proce-dimientos, ¿tienen el número de pará-metros y el tipo de datos adecuado?


Anexo 6

Lista de chequeo de estándares de programación-Código

Código en general

¿Está el código indentado a, por lo me-nos dos espacios?

¿Están ordenadas alfabéticamente lasconstantes, variables y cursores?

¿Están alineados a la izquierda lasconstantes, variables y cursores?

¿Están alineados a la izquierda la defi-nición del tipo de dato de las constan-tes, variables y cursores?

¿Está definida sola una constante, va-riable o cursor por línea?

Documentación

¿Está toda la documentación en una lí-nea diferente al código que se está do-cumentando?

¿Comprende la documentación de fun-ciones/procedimiento tres partes: unadescripción general de lo que hace lafunción o procedimiento, la descripciónde los parámetros de entrada y la des-cripción de los posibles valores y/o pa-rámetros de salida?

Parámetros

¿El nombre de los parámetros empiezacon la letra p minúscula y es significa-tivo?

Constantes

¿El nombre de las constantes empieza conla letra c minúscula y es significativo?

Elemento a revisar Sí No No Informaciónaplica adicional

Objeto

Fecha de revisión

Revisado por

Sí No

Aprobado


Variables

¿El nombre de las variables empiezacon la letra v minúscula y es signifi-cativo?

Cursores

¿El nombre de los cursores empiezacon las letras cur minúsculas y es sig-nificativo?

¿Están los nombres de los cursores ali-neados a la izquierda junto con la de-finición del tipo de dato de las cons-tantes y variables?

Instrucciones Select, Insert, Up-date y Delete

¿Están todas las instrucciones Select,Insert, Update y Delete escritas enminúsculas, a excepción de variablesque hagan referencia a campos de lasformas?

Instrucciones Select

¿Están las cláusulas Select, Into,From, Where, Order BY, Group BY yHaving escritas en líneas diferentes?

Instrucciones Insert¿Están las cláusulas Insert Into yValues escritas en líneas diferentes?

Instrucciones Update

¿Están las cláusulas Update, SET yWhere escritas en líneas diferentes?

¿Está cada columna que se actualiceen una línea diferente?

¿Están todas las columnas que se ac-tualicen alineadas a la izquierda?

Instrucciones Delete

¿Están las cláusulas Delete y Whereescritas en líneas diferentes?



Anexo 7

Lista de chequeo de estándares de presentación - Formas


Forma

Fecha de revisión

Revisado por

Sí No

Aprobado

Forma

¿Tiene la forma la descripción y su tí-tulo de acuerdo con los estándares?

¿Tiene la forma la dimensión correcta?

Cuando se tiene una forma con múlti-ples tabs, ¿se conoce cuál es el registropadre de los tabs?

Título del frame

¿Está el título en mayúscula inicial?

Si el frame es de un solo registro, ¿estásu título en singular?

Si el frame es multirregistro, ¿está sutítulo en plural?

¿Está localizado el título en la parte su-perior izquierda del frame?

Campos

¿Tiene el contenido del campo la alinea-ción adecuada, de acuerdo con su tipode dato?

Si existen varios campos organizadosverticalmente, ¿están alineados todos ala izquierda?

Etiquetas

Si la organización NO es tabular, ¿es-tán situadas las etiquetas a la izquier-da del campo al que pertenecen?

Si la organización SÍ es tabular, ¿estánsituadas las etiquetas en la parte supe-rior del campo al que pertenecen?


Etiquetas

Si la organización SÍ es tabular, ¿es-tán las etiquetas centradas?

¿Están las etiquetas en mayúscula ini-cial?

¿Están las etiquetas sin los dos pun-tos al final?

Si existen varios campos organizadosverticalmente, ¿están alineadas todaslas etiquetas a la derecha?

¿Están las etiquetas formadas de ma-nera que no utilicen abreviaturas niexpresiones de solicitud?

Radio Buttons y Check Box

¿Emplean mayúscula inicial?

En cuanto a su estructura, ¿empleanorientación en forma de columna?

En cuanto a su estructura, ¿empleanalineamiento a la izquierda?

¿Están organizadas las opciones en elorden esperado, de mayor a menor fre-cuencia de ocurrencia?

¿Están enmarcados dentro de unframe?

Listas de valores

¿Están organizados los descriptoresalineados a la izquierda en forma decolumna?

¿Están organizados los descriptores enorden alfabético o numérico, según seael caso?

¿Están los descriptores en mayúsculainicial?

¿El ancho es suficiente para evitar eluso de scroll horizontal?

¿Tienen las listas de valores la posi-ción adecuada, de forma que no requie-ran ser movidas?



Scroll

¿Están las barras de scroll vertical ubi-cadas a la derecha?

¿Están las barras de scroll vertical igua-les a la altura de sus campos asociados?

¿Están las barras de scroll horizontalubicadas en la parte inferior?

¿Están las barras de scroll horizontaliguales al ancho de sus campos asocia-dos?

¿Son las barras de scroll blancas?

Botones

Si están ubicados horizontalmente,¿están en la parte inferior de la pan-talla?

Si están ubicados verticalmente,¿están a la derecha de la pantalla?

Los botones organizados horizontal-mente, ¿tienen la misma altura?

Los botones organizados vertical-mente, ¿tienen el mismo ancho?

¿Está colocada la opción más fre-cuente a la izquierda o en el tope,según corresponda?

¿Usan los botones mayúscula ini-cial?

¿Incluye puntos suspensivos (...) sila acción despliega otra ventana?



Anexo 8

Lista de chequeo de programación - Formas


Forma

Fecha de revisión

Revisado por

Sí No

Aprobado

Nombres de los objetos

¿Cumplen los siguientes objetos conlos estándares?

Alert

Bloques

Canvas

Forma o reporte

Funciones y/o procedimientos

Gráficos

Librerías

Listas de valores

Object Group

Parámetros

Push Button

Radio Group

RecordGroup

Relación

Variables

Atributos visuales

Ventanas

Título del frame

¿Hereda el título del frame el atribu-to visual VA_TITULO?



Campos

¿Hereda el campo el atributo visualcorrespondiente?

¿Hereda el prompt del campo el atri-buto visual VA_ETIQUETA?

Si el campo pertenece a un bloquemultirregistros, ¿hereda el atributovisual VA_CURRENTRECORD?

Si el campo es tipo date, ¿tiene el for-mato DD-MON-RRRR?

Si el campo es numérico y representadinero, ¿lleva delante de él el signode pesos ($)?

Si el campo indica hora, ¿tiene el for-mato HH24:MI (hora militar)?

Si el campo es un porcentaje, ¿estáubicado el símbolo “%” después delnúmero?

¿Heredan los radio_buttons el atribu-to VisualVA_RADIO_BUTTON?

¿Heredan las listas de valores el atri-buto visual VA_LOV?

Scroll

¿Tienen las barras de scroll un anchode 15 puntos?

Canvas

¿Heredan los canvas el atributo visualVA_CANVAS?


Código Nombre Descripción

Anexo 9

Formato de registro de defectos - Inspecciones

10 Documentación Comentarios, mensajes

20 Sintaxis Ortografía de los comandos, puntuación,errores de tecleo, formato de las instrucciones

30 Manejo de versiones Manejo de cambios, librerías,control de versiones

40 Asignación Declaraciones, identificadores duplicados,alcance y límites de los mismos

50 Interfaces Llamadas y referencias a procedimientos, I/O, interfaz de usuario

60 Validación Mensajes de error, validaciones incorrectas

70 Datos Estructuras, contenidos, inicializaciones

80 Funciones Defectos de lógica, puntero, ciclos,recursividad, cálculo y funcionamiento

90 Sistema Configuración, memoria, tiempo de respuesta

100 Entorno Problemas de diseño, compilación,pruebas del ambiente de desarrollo

Listado de defectos encontrados

CódigoDefecto Localización Descripción del defecto encontrado

Objeto: Revisor:

Fecha: Inspección No.

Tabla de tipos estándar de defectos


Comentarios generales


Anexo 10

Formato de pruebas de caja negra – Partición equivalente

< > - Tabla de particiones

Campos Clases válidas Clases no válidas


1. .

2. .

3. .

4. .

5. .

6. .

7. .

8. .

9. .

10. .

11. .

12. .

13. .

14. .

15. .

16. .

17. .

18. .

19. .

20. .

21. .

22.

23. .

24. .

25. .

26. .

27. .

28. .

29. .

30. .

31. .

32. .

33. .

34. .

35. .

36. .

37. .

38. .

39. .

40. .

41. .

42. .

43. .

44. .

Árbol de clases equivalentes

< > – Casos de Prueba


Anexo 11

Formato de resultados, ejecución de pruebas

No. de ejecución:

Aprobado: Sí No

Ejecutor:

Forma:

Fecha:

Casos:1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40

41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60

61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80

81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100

Errores:

Caso:Observaciones: Entradas: Salidas:





Anexo 12

Formato de casos de pruebas

Descripción

Entradas

Salidas esperadas

Caso No. 1

Tipo de prueba:

Objeto: Complejidad:

Descripción:

Descripción

Entradas

Salidas esperadas

Caso No. 2


Anexo 13

Formato de pruebas de funcionalidad

Forma:

Analista:

Sistema:

Descripción/Observaciones/Reportes

Pantallas:

Ejecución: 1 2 3 4 5

Aprobado:

Tiene Sí Noscripts:

Diseño:

Ejecución:


CONCLUSIONES• Las acciones correspondientes a la

calidad de software que se estabanllevando a cabo eran acciones ais-ladas no contempladas en un planformal. Esto se daba, principal-mente, por el tamaño del departa-mento de Desarrollo de Sistemas,pues no se trata de una compañíadesarrolladora de software.

• El aseguramiento de calidad desoftware se podía trabajar, den-tro de cada una de las activida-des de desarrollo, de la siguientemanera:

— Realizando una revisión porpares para cada proyecto.

— Haciendo seguimiento formala los proyectos, no sólo entiempos y costos, sino en cum-plimiento con estándares ymetodología de desarrollo desoftware.

— Consolidando la metodologíade desarrollo de software enbusca de alcanzar niveles su-periores de madurez.

— Involucrando puntos de che-queo y pruebas de software.

— Desarrollando estándaresmuy concretos para programa-ción e interfase de usuario.

• Los objetivos básicos de las ins-pecciones son:

— Encontrar errores lo más tem-prano posible en el ciclo de de-sarrollo.

— Asegurar que todos los parti-cipantes están de acuerdo enla parte técnica del trabajo.

— Verificar que el trabajo cum-ple con los criterios preestable-cidos.

— Completar formalmente unatarea técnica.

— Suministrar información so-bre el producto y el proceso deinspección.

• Como beneficios secundariosde las inspecciones se desta-can:

— Asegurar que las personasasociadas estén familiarizadastécnicamente con el producto.

— Ayudar a crear un equipo téc-nico efectivo.

— Ayudar a utilizar los mejorestalentos de la organización.

— Ayudar a los participantes adesarrollar sus habilidadescomo revisores.

• Vale la pena hacer una distinciónentre los diferentes tipos de revi-siones que se pueden llevar a cabodurante el proceso de desarrollo,teniendo en cuenta que las inspec-ciones son tan sólo un tipo:

— Revisiones gerenciales: Bus-can asegurar el progreso, re-comendar acciones correctivasy asegurar el suministro ade-cuado de recursos.

— Revisiones técnicas: Evalúanel cumplimiento de especifica-ciones y planes y aseguran laintegridad de los cambios.

— Inspecciones de software: Bus-can detectar e identificar de-fectos y verificar resoluciones.

— “Walkthrough”: Buscan detec-tar defectos, examinar alter-nativas y ser un foro para elaprendizaje.


Todas las revisiones anteriores sepueden combinar durante las diver-

sas etapas del proyecto. La Tabla 8muestra un ejemplo de ello.

Tabla 8. Ejemplo de revisiones durante las etapas del proyecto

• Para toda prueba debe haber unplan que incluye:

— Objetivos para cada fase deprueba.

— Cronograma y responsabilida-des para cada actividad deprueba.

— Disponibilidad de herramien-tas, documentación y libreríasde prueba.

— Procedimientos y estándares aser utilizados para planear yllevar a cabo las pruebas y re-portar los resultados.

— Criterios para determinar sila prueba está completa,como también el éxito de cadaprueba.

• Después de tener el plan de prue-bas, se deben generar los casos deprueba, siguiendo cualquier técni-ca de prueba.

• Cada caso de prueba se debe eje-cutar y al final debe quedar un re-porte de las pruebas con la si-guiente información:

— Proyecto y programas que seestán probando, objetivo de laprueba y el plan de pruebas.

— Responsables y participantesde las pruebas.

— Casos de prueba.

— Herramientas especiales uti-lizadas.

— Configuraciones de hardwarey software utilizadas.

— Resultados de las pruebas.

— Identificación de los elementosque quedan en la librería depruebas.

— Firma de los responsables delas pruebas y certificación de

Etapa Inspecciones Walkthroughs Revisiones técnicas

Requerimientos Requerimientos Requerimientosdetallados iniciales

Planeación Planes de desarrollo

Desarrollo Diseño detallado Diseño del sistemaCodificación Diseño de alto nivel

Publicaciones Publicacionesen borrador

Publicaciones finales

Pruebas Implementaciónde pruebas


que se siguió el procedimientoapropiado.

• Como parte del reporte del proce-so de pruebas, es deseable clasifi-car los errores encontrados, con elfin de tomar correctivos en el pro-ceso de prueba o retroalimenta-ción para los desarrolladores.

• Las pruebas deben ser analizadasteniendo en cuenta:

— Los errores graves encontra-dos deben ser analizados engrupo, para hallar solucionesy maneras de que no vuelvana ocurrir.

— Analizar el tipo de error másfrecuente y revisar qué ocu-rren y cómo se pueden mejo-rar las inspecciones.

— Revisar la efectividad de laspruebas y reforzar aquellasque más errores detectan.

— Los métodos y herramientas deprueba a emplear pueden ser cual-quiera, siempre y cuando se utili-cen dentro de un plan de pruebas.

• Uno de los beneficios de las au-toevaluaciones es que los analis-

tas/programadores pueden suge-rir mejoras dentro de todo el pro-ceso de desarrollo de software,para así incrementar su calidad yproductividad en el trabajo.

BIBLIOGRAFÍA• The Capability Maturity Model.

Carnegie Mellon University -Software Engineering Institute.Addison-Wesley. 1994

• http://www.sei.cmu.edu/cmm/cmms/cmms.html

• http://www.sei.cmu.edu/cmmi/

CURRÍCULOOscar Hernando Guzmán Cortés.

Ingeniero de Sistemas de laUniversidad Icesi, grado cumlaude. Especialista en gerenciade Informática Organizacionalde la Universidad Icesi. Analis-ta senior del departamento deDesarrollo de Sistemas de laUniversidad Icesi. Profesor dela Universidad Icesi, en los cur-sos de Estructuras de datos yBases de datos.

& TELEMÁTICA - Universidad Icesi · WLAN en sus equipos; tal es el caso de Intel,1 que fabrica el...

Documents

Transcript of & TELEMÁTICA - Universidad Icesi · WLAN en sus equipos; tal es el caso de Intel,1 que fabrica el...