sg12 (noviembre-diciembre 2006)

Software Guru CONOCIMIENTO EN PRÁCTICA

www

.sof

twar

egur

u.co

m.m

xS

OFT

WA

RE

GU

RU

CO

NO

CIM

IEN

TO

EN

PR

ÁC

TIC

A

N

ovie

mbr

e-D

icie

mbr

e 20

06

Año 02 No.06 • Noviembre-Diciembre 2006 • www.softwareguru.com.mx

[ Tutorial ] VS Team SystemNoticias • Eventos • Fundamentos • UML • Infraestructura • Reflexiones

Año

02

No.

06

• Spring y JMS

• Confiabilidad del Software

• SOA y Gobernabilidad

México, $65.00

[ ENTREVISTA ]

Tim ListerGurú en Administración de Riesgos

ESPECIALCongreso SG'06

Arte, ciencia y algo más

Dirección EditorialPedro Galván

Dirección de OperacionesMara Ruvalcaba

Coordinación EditorialSusana Tamayo

Asesoría EditorialEdgardo Domínguez

Arte y DiseñoDafne Ortega, Oscar Sámano

Consejo Editorial Francisco Camargo, Ralf Eder, Raúl Trejo,

Guillermo Rodríguez, ITESM-CEM; Hanna Oktaba, UNAM-AMCIS;

Luis Cuellar, Softtek; Luis Vinicio León, e-Quallity - ITESO

ColaboradoresGustavo Bonansea, Abraham Castillo, Elena Ruelas, Aarón Moreno, Mariana

Pérez-Vargas, Gizela Oyervides, Esteban Herrera, Gabriel Vázquez, Jesús Ramos,

Gerardo Padilla, Luis Daniel Soto, Sergio Orozco, Emilio Osorio,

Pedro Torres, Marco A. Dorantes

FotografíaGabriel González

Ilustración de Portada Abelardo Ojeda

Ventas Claudia Perea

Marketing Natalia Sánchez

Circulación y Subscripciones Daniel Velázquez

[email protected]

SG Software Guru es una publicación bimestral editada por Brainworx S.A. de C.V., Malinche no. 6, Col. El Parque, C.P. 53398, Naucalpan, México. Prohibida la reproducción total o parcial del con-

tenido sin previo aviso por escrito de los editores. Todos los artículos son responsabilidad de sus propios autores y no necesariamente reflejan el

punto de vista de la editorial. Reserva de Derechos al Uso Exclusivo: 04-

2004-090212091400-102. Certificado de licitud de título: 12999. Certificado de licitud de con-

tenido:10572. ISSN: 1870-0888. Registro Postal: PP15-5106. Se imprimió en octubre de 2006 en El

Universal, Compañía Periodística Nacional.Distribuido por Sepomex.

directorio

Un año más está por terminar, pareciera que fue ayer cuando estábamos planeando el número de enero-febrero, cuando estába-mos organizando SG’06 y ultimando detalles una noche antes, después de desvelos, ten-siones y ajetreos. Pareciera que el tiempo se ha pasado volando, y sí, así es, hoy tenemos lista la edición número 12 que marca el final de este 2006 lleno de momentos importan-tísimos para nosotros, que nos han consoli-dado en el mercado y también solidificado el compromiso que tenemos con la comunidad de desarrollo de software no sólo en México, sino también en Latinoamérica.

En esta ocasión hemos dedicado el tema principal de este número a las pruebas de software, al “testing”, donde varios espe-cialistas en el tema comparten experiencias, ofrecen soluciones y valiosos consejos para aquellos que tienen la intensa labor de en-contrar errores, de romper y llegar hasta las últimas consecuencias.

Por otro lado, nuestra sección de prácticas está conformada por tres interesantes te-mas: la tercera parte de nuestra serie de SOA, en donde se habla de gobernabili-dad; un tutorial para aprovechar JMS con Spring; y por último una práctica de bajo costo para la administración de la calidad

de productos de software: ingeniería de la confiabilidad.

Les daremos un breve recorrido por lo más sobresaliente del primer SG’06 Conferencia y Expo. Donde tuvimos la oportunidad de convivir con muchos de ustedes, y platicar con auténticos gurús. Queremos agradecer a todas las perso-nas que hicieron posible este congreso y que hicieron un éxito de él: conferencis-tas, patrocinadores, voluntarios, la AM-CIS, Secretaría de Economía, pero sobre todo a los asistentes.

Finalmente, podríamos hacer una lista de propósitos de año nuevo, pero sabemos que es muy larga y comprometida, así es que sólo les podemos adelantar que 2007 viene lleno de sorpresas, de otro congreso, de mucha más información, de contenidos sustanciosos, y espera-mos, como siempre, seguir contando con ustedes, el aliciente para ser y hacer las cosas cada vez mejor. Felices fiestas y un año a prueba de errores.

Recuerden enviar sus propuestas y comen-tarios a [email protected]

Equipo Editorial

editorial

// CONTENIDO

02 NOV-DIC 2006 www.softwareguru.com.mx

Columnas

Tejiendo Nuestra Red 10por Hanna Oktaba

Mejora Continua 12por Luis Cuellar

Tendencias en Software 43por Luis Daniel Soto

Cátedra y Más 46por Raúl Trejo

Tierra Libre 48por Emilio Osorio

SG’06Reseña del congreso

18

EntrevistaTim Lister

22 En Cada Número

NOTICIAS y EVENTOS 04CLÚSTERS 06UML 44FUNDAMENTOS 50INFRAESTRUCTURA 52REFLEXIONES 56

Productos

LO QUE VIENE 14RadRails, Google Code Search, Berkeley DB, Linux Application Stacks

TUTORIAL 15Testing con Visual Studio Team System

Prácticas

ARQUITECTURA 34Arquitectura Orientada a ServiciosEn la tercera parte de esta serie, Gabriel Vázquez nos habla sobre modelos de gobierno, y centros de competencia para SOA.

PROGRAMACIÓN 36Aprovechando JMS con SpringJesús Ramos nos explica como aprovechar dos de las tecnologías más populares para desarrollo de aplicaciones empresariales, Spring y JMS.

ASEGURAMIENTO DE CALIDAD 40Ingeniería de la Confiabilidad del SWInvestigadores del CIMAT comparten con nosotros los secretos de esta área del desarrollo de software.

EN PORTADA

Prueba de softwareExploramos los antecedentes de la prueba de software, el estatus actual en la industria, los diferentes tipos de prueba, y damos un ejemplo sobre cómo aplicar pruebas de desempeño en aplicaciones web.

24 contenido nov-dic 2006

// CONTENIDO

03NOV-DIC 2006www.softwareguru.com.mx


Lanzamiento del CeDeTIE

El Tecnológico de Monterrey, Campus Estado de México, con-tinuando con su prestigio y sus principios de liderazgo e ini-ciativa, emprende el Centro de Desarrollo de Tecnologías de Información y Electrónica (CeDeTIE), con el objetivo de promo-ver la competitividad internacional de las empresas con base en el conocimiento, la innovación y el desarrollo tecnológico sostenible. Este espacio se yergue como un foro para la vincu-lación entre industria, universidades, asociaciones y gobierno, para lograr la meta de catapultar a México en diversos campos de la información y la electrónica. El pasado 13 de octubre se dieron cita participantes de este proyecto como CANIETI, IBM, Sun Microsystems, Brainup Systems, Dynaware; representan-tes de la Comunidad Económica Europea, Secretaría de Eco-nomía, AMITI, ANIEI; Microsoft, HP, Cisco e Intel, entre otros, para la ceremonia formal de arranque del CeDeTIE.

El Presidente Vicente Fox Entrega Fondos PROSOFT

En el marco del Encuentro Nacional PROSOFT 2006: “Impulsando la Economía Mexicana a través de las Tec-nologías de Información (TI)”, el presidente Vicente Fox entregó reconocimientos y fondos PROSOFT a empresas mexicanas de TI como Magnabyte y Softtek, destacadas por sus niveles de madurez de procesos. También entregó a Towa Software la primera línea de crédito especializada. Así mismo, hizo entrega de $41mdp a las empresas: ANA-DICSoft, SmartData Call, UNITEC Coahuila, Digital B2B, TEC de Monterrey, Praxis, y Getronics. “Hemos trabajado para que la industria de las tecnologías de información en nuestro país sea un jugador de clase mundial”, comentó el mandatario.

AMITI, CANIETI y Fundación México Digital, Desarrollan en Conjunto una Iniciativa que Permitirá Colocar a México Entre los Veinte Países más Competitivos del Mundo en el 2020

En un esfuerzo conjunto, los tres organismos proponen una serie de políticas públicas para implementar las tecnologías de la información y co-municación (TIC) en México, de manera que para el año 2020, la productividad de los mexicanos compita con los veinte países más productivos del mundo. La visión 2020 parte del principio de que el bienestar social y económico, requiere una plataforma que le permita articular y desa-rrollar políticas públicas que incentiven la competitividad y la innovación. La plataforma ideal, sin duda, son las tecnologías de la información y comunicación. El documento recomienda una serie de acciones concretas de políticas públicas tanto a corto como a largo plazo.

Para obtener mayor información sobre este proyecto, visita: www.amiti.org.mx

// NOTICIAS


6 al 8 Noviembre 2006SEPG LA 2006European Software Institute y Software Engineering InstituteHotel Gran Meliá WTC, Sau Paulo, BrasilInfo: www.esi.es/SEPGLA e-mail: [email protected]

10 Noviembre 2006Taller de Actualización CMMI v1.2AvantareCd. de MéxicoInfo: www.avantare.com Tel: (55) 5544 3321e-mail: [email protected]

27 Febrero 2007Tendencias 2007SelectCentro Banamex, Cd. de MéxicoInfo: www.select.com.mx Tel: (55) 5256 1426e-mail: [email protected]

27 Febrero al 2 Marzo 2007Linux World Conference & ExpoExpo Comm 2007Von Conference & ExpoExpo Móvil Centro Banamex, Cd. de MéxicoInfo: www.expocomm.com.mx Tel: (55) 1087-1650 ext. 1160e-mail: [email protected]

Vision Consulting logra nivel 3 de CMMI

Vision Consulting, empresa mexicana dedicada al desarrollo de soft-ware, logró el pasado mes de septiembre la evaluación exitosa (SCAM-PI A) de CMMI Nivel 3. Para esto, contó con la consultoría de Avantare, empresa especializada en brindar soluciones a las organizaciones que requieren mejorar y evaluar sus procesos de desarrollo de software.

El programa de mejora, se llevó a cabo definiendo los procesos de CMMI en base al trabajo que se había realizado en un proyecto preli-minar, en el que Vision Consulting intentaba obtener la certificación de ISO 9000-2000.

Algo que hay que recalcar sobre este caso, es que se trata de una acreditación 100% mexicana, ya que tanto la empresa evaluada (Vi-sion) como los consultores de mejora (Avantare), como el consultor evaluador (Miguel Serrano) son mexicanos. ¡Enhorabuena!

ImagenSoft se acredita en CMMI 2

El pasado 12 de octubre, la empresa sinaloense ImagenSoft recibió la acreditación CMMI 2 por parte de Andrés Rubristain, Lead Appraisal acreditado por el SEI, como corolario al proce-so de mejora que bajo la guía de consultores de Innevo, han llevado con éxito los últimos meses.

Jorge Orduño, director general de ImagenSoft, comentó: “Se nos decía que era muy difícil que una empresa pequeña como la nuestra, de apenas 20 empleados, pudiera imple-mentar una metodología tan exigente como el CMMI. Hoy, después de 15 meses de arduo trabajo, hemos alcanzado la meta”. Apoyada por FidSoftware y PROSOFT, la empresa ImagenSoft se convierte en la primera empresa sinaloense en lograr esta acreditación.

Innox: Software libre con CMMI Nivel 2

En una clara muestra de que el software libre y la madurez de procesos no están peleadas, la empresa jalisciense Innox, desa-rrolladora de software web a la medida con open source, recien-temente fue acreditada como CMMI Nivel 2. Esto, junto con su inclusión en el Centro del Software, están posicionando a Innox como un líder a nivel nacional en desarrollo de aplicaciones con open source. Gracias a los apoyos del CoecytJal, PROSOFT y la integradora Aportia, se logró esta meta encaminada a agilizar la obtención del nivel 4 utilizando la versión extrema del Software Engineering Institute, basada en PSP/TSP.

En el siguiente número: “Cómo hackear el nivel 2 sin crackearlo”

Empresas evaluadas en CMMI en México:

• IBM (AMS Mexico) Nivel 5 – Diciembre 2004• Innevo (Guadalajara) Nivel 2 – Noviembre 2005• QuarkSoft S.C. (Mexico DF) Nivel 3 – Noviembre 2005• Azertia, Tecnologías de la Información (México DF) Nivel 3 – Diciembre 2005• Sigma Tao (Querétaro) Nivel 3 – Marzo 2006• Hildebrando Software Factory (Aguascalientes) Nivel 4 – Junio 2006• Vision Consulting (México DF) Nivel 3 – Agosto 2006• Innox (Jalisco) Nivel 2 – Oct. 2006•ImagenSoft (Sinaloa) Nivel 2 – Octubre 2006

Para mayor información sobre empresas evaluadas en CMMI visita: seir.sei.cmu.edu/pars/pars_list.asp

// EVENTOS

¿Por qué Jalisco?Jalisco cuenta con una muy fuerte industria de manufactura electró-nica, formada por más de 500 empresas, y es responsable del 70% de las exportaciones del estado. Los dispositivos electrónicos que estas empresas desarrollan, requieren de software embebido, por lo cual, esta área se ha desarrollado fuertemente en esta región. De hecho, en el estado existen 31 casas de diseño de microelectrónica y desarrollo de firmware, y 24 de éstas son de origen jalisciense.

Cualquier región con una industria y economía pujante, requiere ser-vicios de software como desarrollo a la medida, y consultoría. Jalisco no es la excepción, y esto ha generado mercado para que las compa-ñías de servicios de software empresarial se multipliquen.

Por último, un área que se está impulsando muchísimo en el estado, porque es considerada como una gran oportunidad, es la de anima-ción digital y desarrollo de videojuegos.

Proyectos de InfraestructuraEn el mes de septiembre fue inaugurado en Guadalajara el denomina-do “Centro del Software”, un espacio que alberga a 33 empresas de software, y que cuenta con capacidad para 500 ingenieros. Este pro-yecto se inició hace dos años, y requirió una inversión de 61.5 millones de pesos, los cuales fueron aportados en conjunto por el gobierno fe-deral, estatal, e iniciativa privada. Además de ser un espacio conjunto que facilitará la comunicación y sinergia entre estas empresas, este centro también será un lugar para que los inversionistas y clientes puedan ver en conjunto el potencial de Jalisco en esta industria.

El Centro del Software, es apenas el primero de varios proyectos de infraestructura destinados a impulsar la industria de software. Tam-bién está en curso el proyecto “Tecnopolo” en la zona de Zapopan, así como el desarrollo de un parque tecnológico de 10 hectáreas en el Lago de Chapala,.

Impulso a la industria de software creativaSin duda alguna, en Jalisco se le está aportando fuertemente a la in-dustria de software que podríamos denominar “creativa”, y que está conformada por empresas de multimedia, animación digital y desarrollo de videojuegos. Prueba de este impulso fue la organización del Festival Creanimax en Guadalajara durante el pasado mes de octubre. El obje-tivo de este evento fue fomentar la creación y el crecimiento de más empresas que permitan a México establecer y fortalecer una industria de animación y videojuegos de clase mundial.

Creanimax logró reunir tanto a entusiastas como profesionistas nacionales e internacionales en el desarrollo, creación y diseño de animaciones y efectos especiales para las industrias del cine, edu-cación, construcción, publicidad, ingeniería, entre otras; así como a los desarrolladores de videojuegos para las industrias del entreteni-miento y la educación. Que se reunieron por primera vez en nuestro país no sólo para compartir experiencias sino también con el fin de crear una comunidad que se apoye entre sí, con vías a una industria nacional fructífera y reconocida.

Distintivos de JaliscoComo sabemos, Jalisco no es la única región de nuestro país donde hay esfuerzos en curso para desarrollar la industria de software. Sin embargo, una de las características que hemos notado en esta re-gión a diferencia de otras, son:•Sinergia y cooperación entre empresas, gobierno, y academia.•Unión y compromiso hacia un fin común •Interés por innovar y buscar nichos de alto valor agregado.

La industria de software de Jalisco en números•125 empresas en las áreas de desarrollo de software, software em-bebido, y animación digital y multimedia.•500 millones de dólares de facturación anual (1.5% del PIB estatal).•3 mil profesionistas de software.•5 empresas acreditadas en distintos niveles de CMM y CMMI, y 15 en proceso de evaluación.


/* CLUSTERS */

JaliscoCapital de TI de MéxicoDesde hace un par de décadas, Jalisco se ha ganado a pulso el reconocimiento como el cluster de la industria electrónica más importante del país, e incluso hoy en día, es reconocido a nivel mundial. En los últimos años, Jalisco también se ha puesto la meta de ser el líder nacional en la industria de software, posicionándose así, como la capital de Tecnologías de Información en México.

// INDUSTRIA

Oficinas del Centro del Software en Guadalajara


/* CLUSTERS */

Software Guru platicó con Juan Alberto León, director de este fideicomiso integrado por Secretaría de Desarrollo Económico de Sina-loa y empresas privadas.

Nos explicó que, debido a que FidSoftware es una de las primeras asociaciones de este tipo, constituidas en el país, entre sus logros, acumula:

•Un Centro de Atención Tecnológica de Sina-loa, para la elaboración de diagnósticos de la situación actual de una empresa, identifican-do los riesgos potenciales que tiene, propi-ciando la reconversión digital de la empresa.•Cuatro incubadoras de empresas de soft-ware, instaladas y operadas por las princi-pales universidades del estado, en las que están en proceso de incubación 8 empresas. Se pretende crear 20 empresas de software cada año.•Cuatro centros de desarrollo productivos, también instalados dentro de las universida-des, que desarrollan proyectos de software dirigidos por empresarios con la colabora-ción de alumnos, para conseguir egresados con experiencia práctica.•Un centro de excelencia en estándares abiertos de IBM, con 27 alumnos y 3 maes-tros egresados y entrenados por especia-listas de IBM. Con ellos se creó la primera empresa de base tecnológica en estándares abiertos (OPEN TI) la cual permitirá detonar el desarrollo de software en esta platafor-ma; y la atracción de mercados enfocados en esta tecnología. •Siete empresas del cluster trabajan desde hace dos años, en la adopción de las prácti-cas de CMMI, y otras más en MoProSoft.•Un centro especializado para la comerciali-zación y venta de los productos de software, mediante la instrumentación de un call cen-ter en telemarketing, en el que se trabaja para incrementar las ventas de dicho sector. •Un parque tecnológico educativo, para in-tegrar un grupo de empresas de software de clase mundial y en permanente vinculación con los alumnos.

•Un proyecto de exportación de software que incluye diez empresas; el cual preten-de desarrollar en los empresarios, las ha-bilidades para incursionar en los mercados internacionales. La meta es que cada una de estas empresas, tenga cuando menos un contrato de exportación.•Un Centro Thompson Prometric con 60 programadores certificados. El reto para este año es tener a 400 programadores cer-tificados en tecnologías emergentes.

Para ello, fue indispensable integrar en el proceso a las universidades, participando a la fecha: TECMilenio, Universidad de Oc-cidente, Universidad Autónoma de Sinaloa, Universidad Valle de Bravo, Tecnológico de Culiacán y el Instituto Tecnológico de Es-tudios Superiores de Monterrey, median-te el proyecto llamado CERTIFICATE, que consiste en actualizar las materias de las universidades con contenidos tecnológi-cos de vanguardia, incluyendo la aproba-ción de exámenes de certificación como requisito para acreditar asignaturas de la currícula. Las certificaciones abarcan UML, herramientas Microsoft y J2EE. Este trabajo ha redituado ya 200 alumnos y egresados certificados en diversas materias.

La meta para este año es capacitar a mil 300 jóvenes estudiantes, y elevar a rango obligatorio las certificaciones en todo el estado. Este programa de certificación in-cluye a los docentes.

A continuación un fragmento de la conversa-ción que tuvimos con Juan Alberto León:

¿Cómo participa PROSOFT en este proyecto?Definitivamente para la consecución de es-tos logros, PROSOFT ha sido fundamental en él, ya que sin este apoyo habríamos tardado más en conseguirlo.

¿Qué rol jugó FidSoftware en la apertura del centro de desarrollo de Neoris en Sinaloa? Impulsamos a Neoris para la apertura de la fábrica de software, con la mano de obra calificada que podría encontrar en la zona, y que existe lo suficiente para cubrir sus ne-cesidades. Los apoyamos en la presentación del proyecto a Prosoft.

¿Cuál fue el papel de FidSoftware en la reciente acreditación de ImagenSoft?Imagensoft es una de las once empresas que iniciaron el año pasado, el proceso de certificación en el modelo de calidad. Este año continuamos con siete empresas, y ellos son los primeros del grupo. Los hemos apo-yado a través de los recursos obtenidos de PROSOFT y el gobierno del estado, así como también en las negociaciones que se dieron con el proveedor de la capacitación

¿Qué se pretende con su próximo viaje a España?En este momento se apuntaron dos empre-sarios para presentarse en una expo en Ma-drid. Ya se iniciaron algunos contactos con empresarios españoles, para la presentación de productos hechos en Sinaloa. Creemos que es un mercado viable para los productos que nuestros empresarios producen, y bus-caremos ampliar el catálogo de esos produc-tos comercialmente viables.

¿Qué mensaje le envía a los lecto-res de Software Guru?Queremos dar a conocer al país el potencial que tiene Sinaloa en esta industria. Nuestra visión es que para el año 2010, nos convir-tamos en uno de los primeros estados en la producción de software.

FidSoftwareLa Nueva Historia de Éxito en SinaloaCon motivo de la reciente apertura de un centro de desarrollo de Neoris en Culiacán, y la acreditación nivel 2 CMMI de ImagenSoft, no podemos mas que voltear los ojos hacia Sinaloa, especialmente a la ciudad de Culiacán y a FidSoftware.

// INDUSTRIA

Lanzamiento de un nuevo gigante en desarrollo de software

Eidon ofrece SOFTWARE con RESULTADOS SOFTWARE que TRANSFORMA empresas

// PUBLIREPORTAJE

www.eidonsoftware.com

Automatización de Procesos (workflow)Atención a Clientes (CRM)Nómina Planeación de Recursos ERP / SAP Data WarehouseBusiness IntelligencePortales / E-commerce

E idon es la nueva empresa de Grupo Ideal, (empresa de infraestruc-tura de Grupo Carso), esta nueva competidora está destinada a ser

una de las gigantes en desarrollo de software para México y Latinoamé-rica. Surge de la fusión de fábricas de software localizadas en Tijuana (Zentrum), Querétaro (Sigma Tao), Distrito Federal (Blitz Software y As-pel Desarrollos) y Mérida (Aspel Soluciones).

Con 25 años de trayectoria en desarrollo de software, es la empresa que hoy en día hace 95% del desarrollo a la medida de Telmex. Sus solucio-nes, forman parte de la transformación tecnológica de una de las em-presas de comunicación más importantes, y eficientes en el mundo.

Domingo Castillo, Gerente de Operaciones de Red Telmex: “Rant Su-cor, aplicación desarrollada por Eidon, se ha convertido en una herra-mienta de uso crítico en nuestros procesos de centrales eficientes, en la administración del tráfico e ingeniería de la red. Telmex ha reducido por arriba de 20% las pérdidas por tráfico, causadas por sobrecargas en la red. Más de 25 millones de registros adicionales de tráfico son procesa-dos y analizados diariamente”.

Edgar Alfaro, Vicerrector externo de Planta, Telmex: “Gracias a los servi-cios de Eidon, el sistema Pisa Queja ha permitido a Telmex mejorar sig-nificativamente la calidad de su red de la línea de cobre. Ha disminuido 40% su número de quejas. Las reparaciones “en el mismo día” se han incrementado de 45% a 80% y, la carga de trabajo de los técnicos de campo se ha reducido 15%”.

Carlos Mendoza, Administrador de Acceso de Red, Telmex: “Con la implementación de la solución desarrollada por Eidon —PROESA—, en Telmex hemos reducido el tiempo de servicio de diagnóstico y repara-ción para el acceso a red en 50%”.

Eidon es una fábrica de software integrada por más de 2 mil profesionis-tas con experiencia comprobada en múltiples plataformas, lenguajes de programación, bases de datos, metodologías de desarrollo de sistemas y administración de proyectos, lo que ha permitido abordar cientos de proyectos de misión crítica para empresas, corporativos y gobierno.

Gracias a su modelo de desarrollo tipo fábrica de software, Eidon ofrece a sus clientes la gran ventaja de producir software mucho más rápido y con el más alto grado de confiabilidad. Lo anterior como resultado de la implementación de las metodologías de aseguramiento de calidad más eficientes a nivel mundial(CMM 5, CMMI 3, RUP, PMI e ISO 9000 – 2000), el uso de modelos técnicos y la reutilización de código.

Mas allá de tener un software documentado, Eidon ofrece una trans-formación modelada de alta fidelidad de los procesos y reglas del negocio, garantizando así máxima estabilidad y desempeño en el desarrollo de sistemas.

Los clientes Eidon se benefician al obtener:•Precisión en la estimación de necesidades y tiempos.•Máxima reducción de riesgos.•Estricto control de costos.•Disponibilidad inmediata de recursos a nivel internacional.

Los servicios que Eidon ofrece son:•Desarrollo a la medida.•Outsourcing de desarrollo de software.•Capacitación en desarrollo de software.•Pruebas de Software.

El tipo de soluciones que entrega:

POR ÁREA POR PROCESO DE NEGOCIO

Recursos Humanos Finanzas Manufactura Mercadotecnia Compras Operaciones Ventas

Mantiene alianzas tecnológicas con las empresas que son líder mundial en tecnología de sistemas, como Sun Microsystems, que reconoce a Eidon como Java Center of Excellence (existen 8 en el mundo), IBM, Microsoft, Oracle, SAP, GE, BEA Systems y Agi-lent. Gracias a estas alianzas, los clientes reciben la seguridad de contar con personal altamente calificado y certificado; innovación tecnológica, y acceso al soporte directo de los proveedores para atención de requerimientos.

Información:[email protected]: (55) 5325-2303

/* TEJIENDO NUESTRA RED*/

El 20 de septiembre de 2006 tuve el honor de inaugurar el primer evento de Soft-

ware Guru. A ustedes, que son sus lectores, no les tengo que explicar el papel tan impor-tante de divulgación y comunicación para la industria, y la academia, que la revista ha adquirido en apenas dos años. Aprecio enor-memente el esfuerzo tan profesional, lleno de ideas y búsqueda de mejoras del joven grupo editorial. La revista se volvió un elemento muy importante para la creación de una industria de software más madura. Su éxito hoy, y en el futuro, es el éxito de todos.

Y para los que no tuvieron oportunidad de disfrutar del evento, les preparé un resumen de mi plática dedicada principalmente a los resultados preliminares de los seis talleres de IPRC, de los cuales he venido platicando durante los últimos dos años. El reporte ofi-cial se publicará posiblemente a finales de este año, pero el SEI ya me permitió transmi-tir lo que desde mi punto de vista, sería inte-resante para nuestra industria y academia.

Después de muchas discusiones, el consor-cio IPRC llegó a identificar cinco temas cen-trales de la investigación para los próximos 10 años. Estos temas no son independientes, se relacionan entre sí (ver figura 1). Por cada tema, se identificaron varios sub-temas más específicos, los cuales llevaron a formular preguntas de investigación no resueltas.

Para los curiosos de “lo que no sabemos”, sobre los procesos para la industria de soft-ware, les preparé un breve extracto del do-cumento, mucho más completo, que está por publicarse:

Tema de investigación 1Relación entre los Procesos y la Calidad del Producto (Process/Product Quality Relationship)Es un tema que se centra principalmente en producto y su relación con el proceso. No se lo digan a nadie, pero todavía no hay “evidencias” objetivas de la relación direc-

ta entre el proceso y las cualidades del producto. Pero por favor, no lo malinter-preten, no se trata de concluir: “al diablo con el proceso”.

Los sub-temas y algunas de las preguntas de investigación ejemplo, con mi breve comen-tario en cursiva, son los siguientes:

•Captura y especificación de requisitos rela-cionados con la calidad del producto:¿Cómo facilitar la expresión precisa de sus necesidades a un cliente no experto? Tene-mos que poner algo de nuestra parte.•Establecimiento de las relaciones entre el producto y el proceso: ¿Existe una relación directa entre alguna cuali-dad del producto y el proceso utilizado? Ni ISO 9126 lo indica, tampoco MoProSoft o CMMI.•Modelado de la relación calidad del pro-ducto-proceso:¿Cómo modelar y predecir la relación entre una cualidad del producto y el proceso? A UML le falta algo.•Verificación y validación de las cualidades del producto:¿Cómo determinar criterios de aceptación de una cualidad del producto? Todavía no se vale certificar a los productos de software.•Sostenimiento y evolución de las cualida-des del producto:¿Cómo sostener las cualidades del producto durante su mantenimiento y evolución? ¿Lo han pensado al hacer el mantenimiento?

Tema de investigación 2Ingeniería de Procesos (Process Engineering)Es un tema que se centra centra principalmen-te en proceso y su relación con las cualidades del producto. La idea general es poder definir los procesos en función de necesidades del producto, usando componentes reutilizables de las prácticas y técnicas específicas.

•Especificación de procesos usando evidencia:¿Cómo alinear procesos con los objetivos del negocio? Véase MoProSoft.

¿Qué evidencias son necesarias para especi-ficar procesos? ¿Sepa?•Organización de procesos para su reuso ¿Cómo evaluar componentes de procesos: para poder confiar en ellos? Peor tantito.•Infraestructura para la ingeniería de procesos:¿Cómo ajustar procesos con efectividad y eficiencia predecibles? Saberlo valdrá oro.

Tema de investigación 3Implementación y Uso de Procesos (Process Deployment)Se centra principalmente en personas y su disposición para seguir procesos. Este tema, a mi juicio, es el meollo del asunto. Si las personas no están convencidas de que los procesos sirven para que su traba-jo sea más fácil y placentero, y que traigan beneficio para su negocio, nunca los van a seguir.

•Motivación para el Uso de Procesos:¿Cómo evaluar la motivación y la disposición del personal para adoptar procesos o cam-biarlos? Siempre habrá oposición, aunque sea por flojera.¿Cómo demostrar el retorno de inversión? Desgraciadamente no es a corto plazo.•Implementación de Procesos:¿Cómo expresar las necesidades para los procesos, con el objetivo de escoger los que pueden ser implementados efectivamente en la organización? Está difícil.¿Qué elementos de infraestructura se requie-ren? Depende de disponibilidad de recursos.•Gestión de Procesos:¿Cómo medir la amplitud y la profundidad de la adopción de procesos? Aquí está el gato encerrado.

Tema de investigación 4Administración de procesos de un proyecto (Managing Project Processes)Tema que se centra principalmente en pro-yectos, y la estructura organizacional de sus equipos. En un mundo globalizado ya no sorprenden equipos de trabajo dentro de la misma organización, ubicados físicamente


Resultados PreliminaresNoticias de Baja California, Chile y Brasil

La Dra. Hanna Oktaba es profesora de la UNAM a nivel licenciatura y posgrado. Sus áreas de interés son Ingeniería de Software, Tecnolo-gía Orientada a Objetos, Modelos de Procesos de Software y Mejora de Procesos. Es fundadora de la AMCIS. Actualmente es miembro de International Process Research Group (IPRC). También es Directora Técnica del proyecto COMPETISOFT.

// COLUMNA

en diversos sitios o federaciones de equi-pos de diversas empresas, culturas o zonas de tiempo. Estos equipos distribuidos, se pueden regir por una dirección y planea-ción centralizada, o pueden colaborar con base a unos acuerdos menos rígidos.

En este caso, las preguntas de investigación son comunes a los sub-temas y son los siguientes:

•Operación bajo Control Autónomo•Administración a través de la Cooperación Centralizada. •Acuerdos de la Colaboración Federativa:¿Cómo seleccionar el “mejor” proceso para mi proyecto?¿Cómo administrar el desarrollo entre va-rias locaciones?¿Cómo manejar diferentes culturas y zonas de tiempo?¿Cómo manejar trabajo conjunto de grupos con diferentes niveles de capacidades?¿Cómo deben de definirse las relaciones entre partes?

El tema 5Tendencias tecnológicas emergentes (Emerging Technological Trends)Más que un tema de investigación es un cúmulo de elementos que influyen y van a influir en el futuro de procesos de software.

Es un tema centrado principalmente en tec-nología, en un muy amplio sentido de la pa-labra, y en su impacto en los procesos.

Los sub-temas no nos sorprenden mucho:

•Evolución continua de requisitos. Conoci-miento incompleto sobre las tecnologías a usar y de los requisitos del cliente.•Integración de sistemas con base a compo-nentes heterogéneos.•Clientes que esperan el valor agregado.•Clientes que requieren crecientes niveles de calidad del producto.•Todos buscan el retorno de inversión rápido.•Todos buscan la seguridad.

Y los problemas que ya se vislumbran son:•Diversificación de las estructuras de negocios.•Cambio de tecnologías.•Complejidad de sistemas.•Regulaciones y estandarizaciones.•Globalización.

Espero que este pequeño resumen, les ayude a entender porqué todavía sabe-mos tan poco sobre cómo desarrollar software. ¿Sabemos que no sabemos (casi) nada?

—Hanna Oktaba

/* TEJIENDO NUESTRA RED*/

09SEP-OCT 2006www.softwareguru.com.mx

“Después de muchas discusiones el consorcio IPRC llegó a identificar cinco

temas centrales de la investigación para los próximos 10 años. Estos temas no son independientes, se relacionan

entre sí”.

Hace algunas semanas participé en una conferencia sobre calidad de software. Durante la sección de preguntas y respuestas, me llama-

ron la atención algunos comentarios sobre la dificultad de implementar CMM en organizaciones pequeñas. Parece ser, que se considera como un hecho en la industria, que el modelo CMM se creó para organizaciones grandes con proyectos altamente complejos, que el esfuerzo requerido sólo es factible que lo absorban organizaciones de gran tamaño y que se requiere de modelos más sencillos para mejorar la calidad y productividad de pequeñas y medianas empresas. En realidad, no estoy de acuerdo.

El porqué de las metodologíasUna metodología es una serie de procesos, procedimientos y herra-mientas, utilizadas para lograr un objetivo definido. La necesidad de una metodología se basa en tres objetivos principales: el primero es fungir como una lista de actividades con la cual debemos asegurar que el entregable esté correcto. Dicha lista refleja el conocimiento de personas dentro y fuera de la organización, y puede estar formada por actividades, procedimientos, artefactos, y otros elementos. El segundo objetivo tiene que ver con la comunicación entre grupos de trabajo. La metodología define qué es lo que debe hacer cada indi-viduo para lograr un resultado en conjunto, la metodología coordina y asegura que cada persona trabaja lo más eficientemente posible en un mismo objetivo. El tercer objetivo es el de medir para mejorar. Si todos hacen las cosas de la misma forma, puedo comparar la pro-ductividad entre diferentes equipos, y tratar aprender de los equipos con mejor desempeño para aplicar esas prácticas a otros proyectos.

Tomando estos tres objetivos como base, el punto que se hace evidente es que en realidad no importa el modelo que utilicemos, puede ser ISO9000, puede ser ITIL, CMM o hasta metodologías ágiles, el modelo no afecta la complejidad de la metodología, la complejidad de la metodología es afectada por: a) la complejidad de los proyectos que estamos trabajando, ya que entre más complejo es el proyecto, más elementos deben cuidarse en la lista de practicas a seguir. b) la cantidad de personas involucradas en el proyecto y c) la cantidad de información que se colecta para poder mejorar el proceso.

La complejidad de los proyectosLa complejidad de los proyectos afecta en forma proporcional a la com-plejidad de la metodología. Si el proyecto sólo requiere programar. So-lamente se requiere de una metodología de programación y pruebas unitarias. Si adicionalmente hacemos análisis, necesitamos una meto-dología que cubra el análisis, diseño, programación, etcétera. Además si en mi organización vendemos proyectos con diferentes tecnologías, y si vendemos desarrollos nuevos, así como mantenimientos y migracio-nes, nuestra metodología debe de cubrir procesos para cada una de las tecnologías, y cada una de los productos. Así es que ésta, crece expo-nencialmente en base a la cantidad de productos, tecnologías y fases

de ejecución que tengamos en nuestra organización. Por lo tanto, uno de los elementos que hace complicada la metodología, no es el modelo, sino la complejidad de las diferentes ofertas que manejamos.

El número de participantesLa complejidad de la metodología también es consecuencia de la com-plejidad de las relaciones de comunicación que existan en un proyecto. Cuando un proyecto es ejecutado por una sola persona, la metodolo-gía puede ser tan sencilla como una lista y un papel en blanco. Cuan-do el proyecto lo forma un equipo de trabajo compuesto por diversos roles que deben coordinarse entre sí, la metodología debe asegurar la comunicación entre las diferentes partes. Debe incluir elementos para controlar la configuración, y asegurar que se puedan incluir las diferentes versiones; también sería necesario generar listas de esca-lación, juntas de seguimiento, seccionar planes de trabajo y demás. Si adicionalmente el equipo se encuentra dividido entre geografías, e incluye a individuos externos como áreas de sourcing, o la dirección de la organización, entonces la metodología se complica aún más.

Cantidad de informaciónFinalmente, cuando la única métrica que debo generar es mi estimado y mis tiempos reales, con hacer un plan de trabajo es más que suficiente. Pero si además, requiero llevar registro de los defectos, llevar un control de los mismos generados por cada participante del proyecto, llevar una junta para revisar los tipos de defectos, minutas para la junta, controlar el re-trabajo, y demás. Si adicionalmente queremos medir los costos de entrenamiento, el tiempo de utilización de cada individuo, la cantidad de puntos funcionales que se produjeron contra los que se debieron producir. Se tienen que agregar procesos que midan el entrenamiento, los tiempos por actividad de cada individuo, se deben calcular los puntos funcionales al iniciar el proyecto, y cada vez que se agreguen nuevos requerimientos, se deben calcular los puntos funcionales generados. Así que entre más elementos midamos, más compleja se hace la metodología. Una forma de simplificarla, es generando un grupo de métricas sencillas.

ConclusiónEl modelo en sí, no hace compleja una metodología, son las personas que la generan, las que en ocasiones las hacen más complicadas de lo que pu-diesen ser. La implementación de un proceso en una compañía sencilla, debe de ser de igual manera: sencilla. El modelo que se debe seleccionar para una organización debe elegirse debido a la relevancia en la industria actual, a los modelos que requieren mis clientes, a lo que siento que nos puede beneficiar por las debilidades que tenemos como organización. La metodología es independiente del modelo que utilicemos, la realidad es que, sabiendo adaptar la metodología a las necesidades de mi organiza-ción, cualquier modelo es fácil de implementar.

—Luis Cuellar

Simple o Complejo La Clave Está en las Personas, No en los Modelos

/*MEJORA CONTINUA*/// COLUMNA

Luis R. Cuellar es Director de Calidad a nivel mundial de Softtek Information Services. Luis es reconocido por la American Society for Quality (ASQ) como Certified Quality Manager, Certified Software Engineer, y Six Sigma Black Belt. En los últimos cinco años ha estado a cargo de la definición e implantación de la estrategia para CMM5 y Six Sigma a través de las diferentes áreas del centro de desarrollo de Softtek.



/* LO QUE VIENE */

Posiblemente han oído hablar de Ruby on Rails, un framework para desarrollar apli-caciones web que ha cobrado gran popularidad en los últimos meses. Con esta po-pularidad, también ha llegado la necesidad de contar con un ambiente de desarrollo que facilite el desarrollo de aplicaciones con este framework. Tal necesidad es cubier-ta por RadRails, un IDE open source para Rails, que funciona sobre Eclipse.

La misión de este proyecto es “proveer a los desarrolladores de Rails una herramien-ta con todo lo que necesitan para desarrollar, probar e instalar sus aplicaciones”. El producto apenas está en su versión 0.7, pero aun así, cumple bastante bien su mi-sión, ya que provee muchas de las capacidades de los IDEs comerciales y más madu-ros. Desde un mismo ambiente, se pueden generar aplicaciones, generar y editar los elementos de la aplicación (modelos, vistas y controladores), administrar el servidor web, configurar las bases de datos, y visualizar la aplicación durante su ejecución.

Si estás interesado en comenzar a desarrollar aplicaciones sobre Ruby on Rails, y requieres de un IDE bueno, bonito, y libre, entonces RadRails es la opción.

Más información en www.radrails.org

Berkeley DB 4.5Mayor Desempeño y Disponibilidad

Oracle anunció la disponibilidad de la versión 4.5 de Berkeley DB, la base de datos no-relacional y embebible (embeddable), que adquirió en febrero de este año al comprar Sleepycat Software.

El nuevo control de versiones múltiples concurren-tes mejora sustancialmente el desempeño en sis-temas con alta concurrencia, ya que generan un “snapshot” para cada usuario, donde éste realiza sus operaciones, y el motor de base de datos se encarga de controlar los cambios concurrentes y distribuirlos hacia los snapshots.

La capacidad de non-stop upgrades permite realizar actualizaciones a la base de datos sin necesidad de detener el sistema. Esta es una capacidad deseable en sistemas embebidos de alta disponibilidad.

Por último, el framework de replicación provee un conjunto de funciones preconstruidas, que simplifi-can y agilizan el desarrollo de sistemas replicables de alta disponibilidad usando esta base de datos.

RadRailsUn IDE para Ruby on Rails

Linux Application StacksElige tu Sabor Favorito

En el último par de meses, dos de los principales proveedores de Linux empresarial: Red Hat y Novell, lanzaron su propio stack de aplicaciones para servidor.

A mediados de septiembre, Red Hat dio a conocer el Red Hat Application Stack, un paquete integrado que incluye Red Hat Linux Enterprise Server, JBoss Application Server, JBoss Hibernate, y la versión empresarial de MySQL o PostgreSQL. Esta combinación de sistema operativo, middleware y base de datos, está disponible por un precio que va de 2 mil hasta 9 mil dólares al año, dependiendo de la confi-guración de servidor, y soporte requerido.

Un mes más tarde, Novell lanzó el Integrated Stack for SUSE Linux Enterprise, el cual está basado sobre el nuevo SUSE Linux Enterprise Server 10, y agrega el WebSphe-re Application Server Community Edition como middleware, y DB2 Express-C, como base de datos. También se incluye el Likewise Management Suite de Centeris, que es una herramienta para administración de redes híbridas con servidores Windows y Linux. Novell le ha puesto un precio de 349 dólares.

Mientras que la oferta de Novell no es completamente open source, a diferencia de la de Red Hat, es cierto que, la diferencia de precio es significativa. Básicamente, lo que sucede, es que Red Hat está dirigiendo su stack a grandes empresas que requieren mejor soporte, mientras que Novell está apuntando hacia las empresas pequeñas y medianas que quieren dar el salto de Windows a Linux. En adición, No-vell no podía resistir dar un golpe a Red Hat, sobre todo, porque Novell fue de los principales afectados cuando Red Hat compró JBoss en abril de este año.

Búsqueda de CódigoUn Área con Posibilidades

Google lanzó Google Code Search, una herra-mienta para búsqueda de código fuente. Ade-más de buscar código en páginas web, esta herramienta también lo hace en archivos .zip, y repositorios como Subsersion y CVS.

Esto no es nada nuevo, ya que otras em-presas como Koders (www.koders.com), y Krugle (www.krugle.com) ofrecen este ser-vicio desde antes, y con mayores capacida-des. Por ejemplo, Koders provee un software que se puede agregar como plug-in en IDEs para buscar código, y que se puede configu-rar para que solamente busque dentro de la red de una empresa, facilitando así el poder encontrar programas desarrollados anterior-mente dentro de su empresa. Sin embargo, el principal mérito de Google Code Search, es que atraerá atención hacia el área de bús-queda de código, que todavía tiene mucho camino por recorrer, y que tiene posibilida-des muy interesantes.

// PRODUCTOS

Visual Studio 2005 Team System es la primera versión de este producto de Microsoft que cuenta con herramientas incorpo-

radas para cubrir todo el ciclo de vida de desarrollo de software. Entre estas funcionalidades podemos encontrar algunas especial-mente diseñadas para el testing de software; que antes debían ser cubiertas por productos de terceros.

El testing dentro del proceso de desarrollo de software es fundamen-tal para poder asegurar la calidad final del producto que estamos creando. Debido al alto grado de complejidad de los sistemas que desarrollamos todos los días y dado el dudoso grado de fiabilidad que tenemos los humanos para esta tarea, es matemáticamente imposible que saquemos “calentito del horno” un producto libre de errores. Entonces, basados en este principio ineludible, tendremos que probar y corregir, tantas veces como sea necesario hasta que el programa tenga un grado aceptable de calidad. Nótese que hemos dicho “grado aceptable de calidad” y no “sin errores” porque, y esto es válido para cualquier proceso productivo, el “cero defectos” es una meta un poco idílica.

Test Driven DevelopmentExisten algunos enfoques interesantes como el desarrollo dirigi-do por pruebas, o TDD (Test-driven Development), que nos lle-van a una nueva relación testing-desarrollo. Uno de los principios fundamentales de esta estrategia es que el desarrollador escribe primero los tests y luego el código. Uno de los aspectos inte-resantes de este enfoque es que el escribir primero las pruebas hace que el desarrollador tenga un acabado conocimiento de los requerimientos funcionales antes de comenzar a escribir la pri-mera línea de código.

A grandes rasgos, estos son los pasos que hay que seguir para apli-car el desarrollo dirigido por pruebas:

1. Agregar un test2. Ejecutar todos los test y ver que el nuevo falla (obviamente por-que la rutina que testea no ha sido descrita todavía)3. Escribir el código4. Ejecutar los test y corregir el código hasta que pasen los tests5. Hacer refactoring para mejorar el código, la ejecución de los test completos asegura que no “rompemos”nada durante este proceso

Luego de que el código es aceptado, porque pasó correctamente to-dos los tests, comienza la etapa de refactoring que permite optimi-zar, organizar y mejorar. La ejecución de todos los test asegura que no hemos “roto” nada durante este paso.

Testing con Visual StudioAhora veamos con un ejemplo simple las capacidades que posee Vi-sual Studio Team System (VSTS) para cubrir nuestras necesidades de testing. Supongamos que tenemos una clase Cálculo que posee algunos métodos para realizar cálculos matemáticos y queremos crear una serie de tests para verificar el correcto funcionamiento de éstos. VSTS incorpora un nuevo tipo de proyecto destinado a la labor de testing. En las figuras 1 y 2 podemos ver cómo agregar uno para nuestra clase Cálculo.

La clase Cálculo posee un método Factorial que realiza el cómputo del factorial de un número dado. El código del método factorial es el indicado en el ejemplo 1, esta es la primera aproximación, y contiene algunos errores (cualquier programador que mire atentamente el có-

/* TUTORIAL*/ // PRODUCTOS

Testing de SoftwareCon Visual Studio Team SystemPor Gustavo Bonansea

Figura 2. Creación de un proyecto para testing unitario

Gustavo Bonansea tiene más de 8 años de experiencia en el mercado argentino de TI. En los últimos tres, ha podido contribuir como Software Engineer en el éxito de Pectra BPM Studio Framework, producto merecedor en 2004 y 2005 del Excellence in Workflow Global Award. Su pasión por ir más allá de los límites de la tecnología la desarrolló en los años que fue miembro y coordinador de varios grupos de investigación en la Universidad, centrándose en tecnologías relacionadas a Business Intelligence, especialmente en técnicas estadísticas y de inteligencia artificial aplicadas a la minería de datos. Actualmente se desempeña como Director de Proyectos de la empresa Raona Argentina.


Figura 1. Creación de un proyecto de testing


/* TUTORIAL */

digo podrá darse cuenta). Para crear un método de test unitario para el mismo sólo es necesario realizar click derecho sobre el método y seleccionar la opción “Create Unit Test”.

public class Calculo

{

public long Factorial(int x)

{

if (x < 0)

{

throw new ArgumentOutOfRangeException”x”, x,

“El parámetro x no puede ser negativo”);

}

long factorial = 1;

for (int i = 1; i <= x; i++)

{

factorial *= i;

}

return x;

}

}

Figura 3. Creación de un test para el método

El método de test que hemos creado es el especificado en el ejem-plo 2. Éste método tiene un arreglo que contiene un conjunto de pares de prueba que es recorrido uno por uno para probar cada

caso particular. Posteriormente utilizamos el método Assert.AreE-qual() para comparar los valores esperados con los realmente ob-tenidos y comunicar a Visual Studio Team System de lo ocurrido con las pruebas.

Ejemplo 2. Código del método de prueba

Luego de la primera ejecución del test obtenemos un resultado negativo indicando que ha fallado para el par de prueba (0,1). como se ve en la figura 4.

/// <summary>

///Prueba del metodo Factorial

///</summary>

[TestMethod()]

[Owner(“Gustavo Bonansea”)]

[Description(“Prueba del metodo Factorial”)]

public void FactorialTest()

{

long[,] conjuntoPruebas = new long[8,2]

{

{0 , 1},

{1 , 1},

{2 , 2},

{3 , 6},

{4 , 24},

{8 , 40320},

{10, 3628800},

{20, 2432902008176640000}

};

long esperado;

long real;

int x;

for (int i = 0; i <= conjuntoPruebas.GetLength(0); i++ )

{

x = (int) conjuntoPruebas[i, 0];

esperado = conjuntoPruebas[i, 1];

real = calculoClass.Factorial(x);

Assert.AreEqual(esperado, real, string.Format(

“El método factorial ha fallado para el par de prueba ({0}, {1})”, x, esperado));

}

}

// PRODUCTOS

Ejemplo 1. Método Factorial primera versión


/* TUTORIAL */

Esto es debido a que la función está devolviendo el valor de x en vez de la variable factorial que es en la cual estamos acu-mulando el cálculo. Si corregimos este desperfecto el test será satisfactoriamente completado.

Code CoverageUna funcionalidad muy interesante que podemos utilizar es el “Code Coverage”, la cual analiza el código que ha sido efectivamente ejecu-tado, indicando qué porcentaje del código no ha sido cubierto por el conjunto de pruebas utilizado. En la figura 5 podemos observar que el código pintado de rojo no ha sido ejecutado nunca durante las pruebas, lo que indica que el conjunto de pruebas no es lo suficientemente am-plio para cubrir todas las posibilidades contempladas por la función.

Hemos visto con un breve ejemplo cómo crear y ejecutar un test unitario para una función y hemos revisado el resultado del Code Coverage del mismo para verificar el nivel de cobertura del test. Pero esto es solo una pequeña parte de las funcionalidades que nos brinda VSTS en su versión para Testers. Abajo nombraremos algunas características adicionales.

Test manualesNo todos los tests son automatizados, si necesitamos dentro de nuestro proyecto realizar pruebas manuales; VSTS incluye planti-llas para facilitar esta tarea y luego provee de asistencia durante la ejecución y registración de los resultados de las mismas.

Test genéricosVSTS utiliza este tipo de test para brindar la posibilidad de in-cluir herramientas externas de testing que no estén totalmente integradas con el IDE.

Test WebPermite automatizar el testing de sistemas basados en web, graban-do las acciones realizadas sobre una sesión de Internet Explorer en scripts que luego pueden ser editados. Permite el control de la si-mulación con respecto al tipo y cantidad de conexiones, el tipo de browser y la posibilidad de emular el tiempo de “pensamiento” del usuario, es decir que utiliza los tiempos reales que se tomaría un hu-mano para cada acción. Pueden definirse luego una serie de reglas de validación para corroborar la validez del valor de los controles en la respuesta a cada petición.

Test de cargaTiene por objetivo verificar la respuesta de un sistema ante su uso in-tensivo, para identificar problemas de performance y escalabilidad, e identificar posibles cuellos de botella.

Figura 4. Test fallido

Figura 5. Resultado del Code Coverage

“La funcionalidad de Code Coverage analiza el código que ha sido efectivamente

ejecutado, indicando qué porcentaje del código no ha sido cubierto”.


SG´06 Conferencia y ExpoUna Comunidad, una Experiencia


// ESPECIAL

Del 20 al 22 de septiembre pasado, tuvimos el placer de organizar en el World Trade Center de la Ciudad de México, “SG’06 Conferencia y Expo”; el primer congreso técnico sobre desa-rrollo de software enfocado a profesio-nales de TI en México y Latinoamérica. El propósito de este evento fue poner a los profesionistas locales en contacto con las tendencias y mejores prácticas internacionales en el campo.

// ESPECIAL

30 cartones de cerveza y 36 botellas de vino se consumieron en la noche

de casino

371 asistentes a conferencias, 437 a expo, y 104 expositores, para un

total de 912 personas en SG’06

El promedio de satisfacción general de los asistentes fue de 4.41 en una

escala del 1 al 5

Muchos de ustedes nos acompañaron, pero seguramente hubo otros que no con-taron con el tiempo o la oportunidad de asistir, por tal razón, queremos brindarles un breve panorama de esos tres días; y para los que anduvieron por ahí, recordar en conjunto lo que hizo de SG’06, una ver-dadera experiencia, no sólo para nosotros como organizadores, sino también para aquellos que nos siguieron hasta el final.

ConferenciasIngenio, claridad, vinculación, liderazgo, sabiduría, estrategia, vanguardia, técnica, y visión, son algunos de los conceptos que definieron tanto a los ponentes internacio-nales como a los nacionales, que durante los ciclos de conferencias se entregaron a la audiencia, y viceversa.

La encargada de abrir las conferencias magistrales fue Hanna Oktaba, quien com-partió los resultados del esfuerzo del In-ternational Process Research Consortium para investigar las tendencias en Inge-niería de Software hacia los próximos 15 años. Alistair Cockburn nos recordó que el desarrollo de software es una actividad en la que trabajamos seres humanos en equipo, para lograr un resultado conjunto, y nos hizo ver las implicaciones de esto; también hay que mencionar sus hipnóticos tenis rojos que causaron sensación. Dee-pak Alur abrió la mente de los asistentes hacia el tipo de aplicaciones que veremos en los siguientes años, gracias a la combi-nación de dos de las tendencias tecnoló-gicas más importantes del momento: Ajax y SOA. Mauro Regio dio inicio al segundo día de conferencias invitándonos a desa-rrollar y utilizar frameworks orientados a industrias verticales, ya que habilitan una productividad fantástica, y ofrecen gran-des ventajas competitivas a quienes los aplican. Tim Lister hizo todo lo posible por convencernos de que los proyectos con mala suerte no existen, y que siempre hay algo que se puede hacer para predecir los problemas; además, nos hizo ver el pare-

cido que hay entre desarrollar software y construir albercas. El cierre de las confe-rencias estuvo a cargo de Suzanne García, quien compartió una visión interesante so-bre el desarrollo de sistemas basados en otros sistemas, así como los retos que este nuevo paradigma conlleva.

En el caso de las sesiones paralelas, se lle-varon a cabo cuatro tracks: uno dirigido a desarrolladores, otro a gerentes de proce-sos, otro a administradores de proyecto, y uno más a directivos. Las sesiones fueron diversas, y brindaron opciones para todos los gustos y niveles de experiencia. Desde sesiones dirigidas a desarrolladores nova-tos, hasta aquellas dirigidas a experimen-tados consultores, o incluso para quienes planean iniciar su propia empresa. Se abordaron desde temas básicos y amiga-bles como fundamentos de requerimientos, hasta temas densos como el manejo de per-sistencia en EJB 3, o control estadístico de calidad para CMMI 5.

Los archivos de las presentaciones están disponibles en el sitio del congreso: www.softwareguru.com.mx/sg06 Pronto también compartiremos los videos de algunas sesiones.

TalleresLos talleres fueron sin duda uno de los puntos clave de diferenciación de SG’06 respecto a

otros congresos, ya que permitieron que las co-sas no sólo se quedaran en la plática, sino que los asistentes pudieran profundizar sus conoci-mientos durante sesiones de medio día. Más de 120 personas se encargaron de llenar todos los grupos que se abrieron, donde los asistentes tuvieron oportunidad de iniciarse en el uso de herramientas como Visual Studio Team System, NetBeans Enterprise Pack, Rational Software Architect, Magic eDeveloper, y Enterprise Archi-tect. Adicionalmente, hubo talleres enfocados no al uso de herramientas de software, sino a prácticas y recomendaciones para mejorar pro-cesos hacia modelos como CMMI.

Los asistentesUn congreso como SG’06 no sólo estuvo integrado por conferencistas y patrocina-dores, sino también por ustedes, la gente que desde el miércoles muy temprano se dio cita en el registro, dándole un toque muy especial al evento: pluralidad. Porque contamos con la presencia de profesionis-tas, empresarios, estudiantes, entusiastas y uno que otro curioso dispuesto a encon-trarle lógica a tanto cubo de colores.

Nos dio muchísimo gusto ver en SG’06 asistentes que venían representando tantos estados diferentes de la Repúbli-ca Mexicana, desde Baja California hasta Yucatán. Esto confirmó que en todos los estados de nuestro país hay necesidad y capacidad de desarrollar software.

También fue de gran importancia la parti-cipación de más de una decena de jóvenes voluntarios que fueron parte del staff SG, alivianándonos en diversas tareas. Exposi-tores, conferencistas, asistentes, técnicos, unidos al equipo de Software Guru, trabaja-mos en conjunto, hombro con hombro para lograr un ambiente de compañerismo que definitivamente flotó en el aire.


// ESPECIAL

23 fueron los estados de la república de donde asistió gente a SG’06


Conociendo genteUn aspecto clave de SG’06, fue proveer un tiempo y espacio para que los profesionistas del software de nuestro país se conocieran en-tre sí, compartieran experiencias, y sembraran la posibilidad de proyectos conjuntos. Fue de gran satisfacción ver como mucha gente de diferentes regiones del país tuvo oportunidad de conocerse, o reencontrarse durante SG’06. En nuestro caso particular, SG’06 nos dio la oportunidad de conocer en persona a muchos colaboradores de la revista, a quienes solo co-nocíamos a través del ciberespacio.

Las reuniones de comunidad fueron otra gran oportunidad para conocer gente con intere-ses similares. Las diferentes comunidades que partici paron (mejora de procesos, .Net, y Java), lograron aprovechar este espacio para conocer colegas y estudiar en conjunto.

Festejando juntosUn evento como SG’06 no podía quedarse sin una buena fiesta, así que el día 20 se llevó a cabo una noche de casino, donde los invitados bailaron, bebieron, cantaron, hicieron cual-quier tipo de desmanes, y por último, parti-ciparon en la subasta para llevarse atractivos premios como cámaras digitales, reproducto-res de DVD, discos duros externos, y cursos.

PatrocinadoresEl conjunto de patrocinadores de SG’06 se dis-tinguió por su diversidad, ya que había provee-dores de tecnología, consultoría, capacitación, y staffing. Sin embargo, el punto en común era el interés que todos tenían por estar en contacto con profesionistas del software, ya fueran como clientes, aliados, o hasta futuros empleados.

Las siguientes empresas apoyaron la reali-zación de SG’06 a través de su patrocinio:IBM, Microsoft, Sun Microsystems, IIDEA, Four Js, SAP, Itera, Citrix, Milestone Con-sulting, e-Quallity, Borland Software, Roca Sistemas, Softtek, Jackbe, Adecco, Grupo STI, Azertia, Safenet, 4D, GoldenGate, Al-pha Consultoria, Innevo, Avantare, Vision Consulting, y Embarcadero Technologies.

La Asociación Mexicana para la Calidad en la Ingeniería de Software (AMCIS) fue un colabo-rador estratégico en el desarrollo de SG’06, que apoyó en la organización del congreso y nos res-paldó en todo momento. Otros colaboradores incluyeron a CANIETI, AnadicSoft, Cutter Con-sortium, AMESOL, eSemanal, y Política Digital

SG’06 tampoco hubiera sido posible sin el apoyo del Gobierno Federal, quien financió parte del costo del evento a través de Fon-dos PROSOFT de la Secretaría de Economía. De hecho, gracias a esto pudimos descontar un 25% del costo de entrada original.

Todos los patrocinadores y empresas que cola-boraron en SG’06 coincidieron en que la indus-tria de TI en México vive un momento de gran importancia, ya que no sólo se está consoli-dando sino que también está creciendo. Poco a poco, nuestra industria de software de se está colocando bajo el reflector mundial. Esto debe ser un aliciente para todos nosotros.

Nos vemos en SG’07Definitivamente, SG’06 fue un even-to nutrido que unió, y en ciertos ca-sos particulares, afianzó relaciones sin importar el nivel de cada uno de los asistentes, porque ahí dentro, todos fuimos colegas en el mismo barco, y el objetivo fue compartir conocimiento y experiencia, mos-trar tendencias, y brindar oportu-nidades; convirtiéndose pues, en una verdadera y única experiencia para la comunidad.

A pesar de que este fue nuestro primer congreso, hemos recibido una excelente retroalimentación, incluso de aquellos que no tenían mucha fe. Esto nos da la pauta para seguir haciendo un buen trabajo y mejorar exponencialmente para la próxima edición de SG Conferencia y Expo en el 2007.

Los conferencistas mejor evaluados fueron: Tim Lister (4.72), Ernesto Elizalde (4.70),

y Rafael Funes (4.67)


Tim ListerAdministrando Riesgos con Pericia

Uno de los conferencistas magistrales del congreso SG’06 fue Tim Lister, Director del Consejo de Ne-gocios y TI de Cutter Consortium, donde dirige la práctica de Administración de Riesgos. Tim es uno de los consultores más reconocidos a nivel mundial en administración de riesgos, así que aprovechamos la oportunidad para platicar con él y compartir con ustedes esta entrevista.


¿Cuál es el estado actual de la práctica de administración de riesgos en el desarrollo de software?Los fundamentos teóricos de esta práctica fueron establecidos hace cerca de 20 años, con el trabajo de personas como Robert Charette y Barry Boehm. Sin embargo, la implantación de esto ha sido muy lenta. El porcentaje de organizaciones que hace una administración de ries-gos que podríamos llamar “decente”, es muy pequeño. Muchas orga-nizaciones no hacen nada de administración de riesgos, mientras que otras identifican los riesgos, y luego continúan como si nada. Identifi-car los riesgos es sólo el primer paso, lo que importa son las acciones que tomas para mitigar esos riesgos.

Creo que administrar riesgos es la función más importante de un administrador de proyectos. Porque si no estás administrando ries-gos, entonces, ¿qué estás administrando? La respuesta es: las cosas fáciles; las cosas que ya sabes que hay que hacer. Y lo único que necesitas para hacerlo, es gente capaz de hacer las actividades que le asignas. En cambio, al administrar riesgos, estás hablando de de-cisiones más difíciles, porque no sabes si es un problema que se pre-sentará o no, y realmente no puedes probar que estás en lo correcto cuando decides hacer algo.

¿Crees que esta práctica se encuentra más avanzada en algunas regiones del mundo?Lo que yo he visto, es que por lo general en Europa se hace una mejor administración de riesgos que en otras regiones del mundo. Una de las razones para esto, es que en Estados Unidos es común encontrar-se con la actitud del tipo cowboy: “Si pusimos un hombre en la luna, entonces por supuesto que podemos hacer este software. Y no me digas que hay riesgos, claro que los hay, la vida tiene riesgos. Si algo sucede, pues ya veremos cómo lidiar con ello en su momento”.

¿Qué podemos hacer para hablar con los clientes sobre riesgos?Lo que yo recomiendo al respecto es que, en lugar de hablar de ries-gos, se hable sobre supuestos y dependencias. Por ejemplo, “esta-mos asumiendo que esto es así, pero en caso de no ser así, tenemos que considerar formas alternativas de resolverlo”, o también puede ser algo como “dependemos de que este otro grupo realice dichas actividades en determinados tiempos, pero si no lo hacen, entonces estaremos en problemas”. Es curioso, pero la mayoría de los clientes no se molestan si les hablas sobre los supuestos y dependencias en los que basas un proyecto. Pero en cambio, si dices “tenemos estos 14 riesgos”, entonces dicen: “eso es tu problema, para eso te contraté”.

¿Consideras que la edad o experiencia de una persona tiene influencia en su conciencia de los riesgos?Creo que sí tiene un poco de influencia. Cuando inicias tu carrera en el software, tarde o temprano te toca participar en un proyecto donde todos dieron su mejor esfuerzo, pero el proyecto fue un fracaso. Y esto fue porque no se administraron los riesgos correctamente. Yo estoy convencido de que los eventos que causan problemas a los proyec-tos, siempre son predecibles. En mis más de 30 años como consultor, nunca me he encontrado con un proyecto con mala suerte, donde de pronto salió un rayo del cielo azul y lo arruinó. En resumen, no creo que necesites tener 20 ó 30 años de experiencia para estar conscien-te de los riesgos, pero sí ayuda haber estado tal vez unos 5 años en proyectos, para darte cuenta de que las cosas malas pueden suceder. De hecho, siempre suceden, y hay que lidiar con ellas antes de que se conviertan en problemas que pongan en riesgo el éxito del proyecto.

En nuestra industria se da mucho el caso de buenos desarrolladores que se hacen gerentes de proyectos para mejorar su sueldo, ¿cuál es tu opinión al respecto?Desgraciadamente, es común que en las organizaciones tengan mayor compensación y prestigio los administradores que el personal técnico. Es muy difícil encontrar a un buen desarrollador que también sea un buen administrador de proyectos. Son roles muy diferentes, que requie-ren habilidades muy diferentes. Cuando eres un desarrollador, no tienes que quedar bien con nadie. Estas construyendo código a tu estándar de calidad, haces las cosas como tú crees que están bien, lidias con cosas absolutas. En cambio, cuando eres un gerente, todo es compromiso. Nunca tienes los recursos que quisieras ni el tiempo que quisieras. Tie-nes que lidiar con todas estas personas, y algunas de ellas ni siquiera te agradan. Básicamente, eres un político.

Creo que en las organizaciones donde el negocio central es hacer soft-ware (ya sea comercial o para terceros), se entiende cada vez más y más, que el personal técnico es igual o hasta más importante que los gerentes, y se crean caminos para que esta gente sea compensada ade-cuadamente. Por ejemplo, uno de mis clientes tiene un rol que se llama “Consultor Interno”, y de hecho hay una persona que tiene el título de Consultor Interno Senior, y este hombre es un genio. Su labor es resol-ver los problemas técnicos. Y no tiene a nadie asignado a su cargo, pero tiene el mismo sueldo que los altos gerentes en esa empresa.

Otro caso que se da a menudo, es el del buen desarrollador que intenta ser gerente, pero ya que está ahí, se da cuenta que no le gusta –y por lo tanto, no es bueno, ya que por definición no haces bien un trabajo que no te gusta–, pero desgraciadamente no hay una forma aceptable de que esta persona pueda regresar a su rol anterior. Así que tiene que cambiar de empresa, para poder regresar a un rol técnico. Ojalá y en las organizaciones hubiera alguna forma de que estas personas pudieran “probar” ser gerentes, algo así como un periodo de prueba, en el que si las cosas no salen bien, o a la persona no le gusta, entonces pudiera regresar a su rol anterior, y no habría resentimientos.

¿Cómo se desarrolla profesionalmente un gerente de proyectos? ¿Qué, y cómo debe ir aprendiendo durante su carrera?Bueno, pues está el PMBoK, pero eso sólo son los fundamentos. El conocimiento importante de la administración de proyectos está en la práctica. Es la escuela de los golpes, aprendes por experiencia, al ser golpeado por el mundo.

Por otro lado, la vida del gerente de proyectos es solitaria, ¿alguna vez han pensado en eso? Por ejemplo, en los equipos siempre hay varios desarrolladores, y platican sobre lo que están haciendo, y cuando uno se atora en algo, es posible que los demás lo ayuden. En cambio, en los proyectos sólo hay un gerente de proyectos, y no tiene nadie con quien compartir sus dudas, o que lo pueda asesorar. Puede haber otros gerentes en la organización, pero ellos tienen las manos llenas con sus proyectos, y no conocen o entienden tu proyecto, así que en el mejor de los casos puedes hablar con ellos y tendrán simpatía por ti, pero real-mente no pueden ayudarte.

Así que la mejor forma, de hacerse mejor, es con la experiencia. Empie-zas con proyectos pequeños y sencillos, y vas avanzando hacia proyec-tos más grandes y complejos. La buena noticia es que la dinámica del mundo hace que siempre haya proyectos interesantes y retadores, y eso es lo que motiva a un buen gerente de proyectos.

// ENTREVISTA


Pasado, Presente y FuturoPor Luis Vinicio León, Abraham Castillo, Elena Ruelas y Aarón Moreno

Datos del PasadoLa prueba de software, es una práctica que se lleva a cabo de manera informal desde que se desarrolla software. A finales de los 60, se reunieron en Garmisch, Alemania, personalidades de la industria y la acade-mia de distintas partes del mundo, para describir la problemática que se planteaba como una “crisis del software”. Fue en esa reunión que se acuñó el término “Ingeniería de Software”.

Distintos enfoques se han planteado desde entonces para abatir problemas relaciona-dos con la calidad del software: enfoques que hacen énfasis en la gente –como el Total Quality Management for Software–, argumentando que son las personas entre-nadas y motivadas las que logran produc-tos de calidad; enfoques que se centran en los procesos –como CMMI –, con la conjetura de que con procesos de calidad se generarán productos de calidad; enfo-ques que se centran en la sistematización rigurosa del proceso de desarrollo de soft-ware –como los Métodos Formales–, con la visión de que se puede automatizar (casi todo) el proceso de desarrollo, con ayuda de lenguajes formales, generando bug-free software by construction. La prueba de software es un enfoque alternativo y complementario a éstos.

Los trabajos de G. Myers a finales de los años 70, representan un parteaguas en la disciplina de la prueba de software, en ellos se arranca de la premisa de que práctica-mente cualquier programa desarrollado, de

manera convencional, tiene anomalías, y se establece como meta de la prueba, la detec-ción de la mayor cantidad de anomalías lo más críticas posible, lo antes posible. Myers fue también de los primeros en enfatizar que la organización que desarrolla el software no debiera ser la misma que lo prueba. Desde entonces, se han desarrollado una buena cantidad de técnicas y herramientas.

En México la prueba de software se enseña-ba en muy pocas universidades, y cuando ocurría, eran más bien cursos aislados. Los bancos fueron de los primeros en aplicar esta disciplina para elevar la calidad del software que desarrollaban y utilizaban, pues el tipo de transacciones lo justificaba. Para la inmen-sa mayoría del resto de la industria nacional del software, esta disciplina pasó práctica-mente inadvertida... hasta hace poco.

Presente La industria del software ha venido fortale-ciéndose y creciendo en los últimos años, en muy buena medida por los incentivos del gobierno, pero también por una tendencia hacia la exportación de algunas empresas de software mexicanas.

Una excelente forma de darse cuenta del estatus de esta práctica en nuestro país, es a través de diagnósticos. En el los últimos años, en nuestra empresa (e-Quallity) he-mos tenido oportunidad de realizar diagnós-ticos sobre prueba de software a distintas organizaciones en nuestro país, de distintos tamaños cada una. Para realizar dichos diag-nósticos, utilizamos un modelo de calidad

que desarrollamos internamente, y que bau-tizamos como TAM (Test Aptitude Model).

Este modelo define 13 áreas relacionadas con prueba de software. Integra elementos de modelos de calidad de software genéricos como CMMI, y lo complementa con elemen-tos de otros modelos de calidad especializa-dos en pruebas de software, como TPI (Test Process Improvement) y TMM (Test Maturity Model), así como con aportaciones de nues-tra experiencia adquirida en proyectos.

La Figura 1 ilustra los porcentajes de cober-tura a través de las 13 áreas del modelo, para tres organizaciones que evaluamos reciente-mente. (Ver figura 1)

En general, las áreas más fuertes en las or-ganizaciones de prueba resultaron estar relacionadas con la estructura organi-zacional: el ambiente de trabajo en la organización (Atmósfera), y la posición que ocupa el equipo de prueba en la organización (Es-tructura Funcional). Consideramos que las áreas de opor-tunidad más críticas se concentraron en cuestio-nes metodológicas y de proceso: qué técnicas usar, cuándo y cómo (Metodo-logía y Distribución y Téc-nicas de Prueba); así como el control, contabilización, y comunicación de los artefactos y

En la columna “Prueba de Software” que se publicó en SG de mayo 2005 a marzo 2006, ofrecimos una panorámica de la disciplina de la prueba de software que incluía aspectos técnicos, organizacionales y de infraestructura. Conside-rando algunos elementos de esa publicación, ofreceremos aquí, nuestra visión del desarrollo de la prueba de software en el tiempo, que toma en cuenta, por un lado la dinámica internacional, y por otro, el desarrollo nacional.


resultados de prueba (Defectos, Testware, Métricas y Distribución de Información).

Desde una perspectiva más amplia, una conclusión que hemos obtenido de dichos diagnósticos, así como de la consultoría que realizamos, es que ya existen en el país organizaciones de prueba de muy buen ni-vel, y que hay un número considerable de organizaciones con nivel bajo, pero que están invirtiendo sistemáticamente para mejorar significativamente.

El crecimiento reciente en el consumo de la prueba de software, puede coincidir con el au-mento en la cantidad de empresas que están trabajando hacia modelos como CMMI, pero que se dan cuenta que estos esfuerzos, no les brindan mejoras significativas en el corto plazo en la calidad de sus productos, y por ello, ven

en la prueba, una herramienta con la cual pue-den abatir riesgos, y reducir tanto costos como time to market en periodos cortos, obteniendo una buena relación costo-beneficio.

Hasta hace algún tiempo, podía observarse que los testers tenían una tendencia a en-fatizar el uso de herramientas de automati-zación, en la labor de la prueba (en buena medida por su desconocimiento de aspectos metodológicos). Hoy, hay cierta conciencia de que si bien en algunos casos la incorpora-ción de una herramienta al proceso de prue-ba permite hacer el proceso más eficiente, el extrapolar este fenómeno a cualquier he-rramienta, en cualquier proceso, de cualquier organización, es un error.

Una buena parte de la comunidad de prue-ba de software en el país, sabe que la adop-ción de herramientas en una organización de pruebas requiere de un análisis cuidado-so del entorno, y de la situación actual de la organización de prueba en cuestión, des-de factores tan elementales como el pre-supuesto, hasta aspectos tan elaborados como la visión, proyección de la organiza-ción de prueba en cuanto a giro, metodolo-gías, y especialización.

Hoy existe también cierta conciencia en las organizaciones de software de que, para obtener el mayor beneficio de esta acti-vidad, es necesario por un lado mantener capacitados a los testers y ofrecerles un plan de carrera adecuado, de manera que permanezcan en la organización; y por otro, situar adecuadamente en el organigrama el departamento de prueba, de manera que tenga autoridad suficiente para que su voz sea escuchada y sus productos utilizados (que no ocurra que el equipo de prueba esté relegado, y que su coordinador reporte a un administrador de proyecto, quien reporta a un gerente de producto, quien reporta a un gerente de tecnología, quien reporta a un director de desarrollo, quien reporta al di-rector general).

Por otro lado, en nuestro país, actualmente son pocas las universidades que abordan la prueba de software, pero es creciente tanto la calidad como la cantidad de los mismos; esto permitirá en el mediano plazo contar con un número

significativo de testers junior.

Figura 1. Cobertura por área de prueba en distintos diagnósticos


“Para obtener el mayor beneficio de esta actividad es

necesario mantener capacitados a los testers”.

Escenarios futurosEstos son algunos de los aspectos que percibimos en el futuro próximo en cuan-to a la prueba de software:

•Un cambio significativo en términos de calidad y cantidad, comienza a gestarse en las universidades, para poder atender la demanda de testers, que serán requeri-dos cada vez más.

•La creciente especialización por áreas de aplicación que se observa en el mer-cado del software, está exigiendo que las organizaciones de prueba también se es-pecialicen de la misma manera.

•Las empresas de prueba de software más maduras, están comenzando a introducir componentes innovadores y, a generar su propia tecnología (no otro robot, ni otra herramienta más de administración de anomalías, sino componentes de mucho mayor valor agregado).

Los sistemas de sistemas, las nuevas ar-quitecturas y los nuevos paradigmas sig-nificarán un gran reto para los testers; la orientación a servicios y la necesidad de probar un sistema que interactuará con otros sobre los cuales no se tiene ningún control, dispararán nuevas y mejores técni-cas y modelos para la prueba de software.

Métodos formalesDentro de las nuevas tendencias en prue-ba de software, vale la pena explicar más

a fondo los métodos formales. En tiempos recientes hemos visto cómo se han veni-do desarrollando metodologías basadas en lo que llaman métodos formales, para llevar a cabo la verificación de sistemas de hardware y software. Un método for-mal, es aquel que tiene un fundamento matemático para realizar la especificación y validación de un sistema. La verificación formal, busca probar el funcionamiento del modelo, con el objetivo de garantizar que el modelo no tiene errores o diver-gencias respecto a la especificación. La justificación de estas técnicas, proviene del hecho de que la prueba puede confir-mar la presencia de errores en un siste-ma, pero no la ausencia de ellos.

Con ese tipo de herramientas, podemos especificar los requisitos de software en un lenguaje formal, y mediante técnicas matemáticas, realizar refinamientos suce-sivos, con el objetivo de obtener un diseño que satisface el modelo, y que es, imple-mentable en un lenguaje de programación. Con estos refinamientos, agregamos el detalle suficiente para que la herramienta puede generar el código que implementa el modelo en el lenguaje de programación que elijamos; se dice que el sistema así obtenido es bug-free by construction.

Debido a la complejidad que representa el solo hecho de realizar el modelado y la especificación en algún lenguaje formal y, a la carencia de una oferta atractiva de herramientas comerciales de este tipo,

hasta la fecha hemos visto que las téc-nicas de esta clase, sólo se utilizan para validar sistemas de misión crítica. Una herramienta para el desarrollo basado en métodos formales es B-ToolKit. Que ya ha sido utilizada en algunos sistemas críti-cos que están operando, como la línea 14 del metro de París.

Consideramos que las dificultades que conlleva el dominio de las herramientas matemáticas necesarias, para utilizar este tipo de metodologías, no permitirá que se utilicen masivamente en el corto plazo y para cualquier aplicación; sin em-bargo, debido a sus enormes bondades y, a su aplicación en mercados interesantes, seguiremos realizando investigación en esta área.

Referencias•Luis Vinicio León-Carrillo. “La Prueba de Software”. SG Año 1 números 3-6, y Año 2 números 2-3.•Luis Vinicio León-Carrillo. The Impact of Software Testing in small Settings. Capítulo del libro “Soft-ware Processes in small Enterpri-ses”, por H. Oktaba y M. Piatini; por publicarse.•G. Myers. The art of software tes-ting. John Wiley & Sons; 1972•Formal methods. vl.fmnet.info

Luis Vinicio León Carrillo es Director General de e-Quallity, empresa especializada en prueba de software. Es profesor-investigador del Departamento de Electrónica, Sistema e Informática del I.T.E.S.O.; es candidato a doctor por la Technische Universität Clausthal (Alemania) con un tema relacionado con la prueba de software. Es co-fundador del Capítulo Guadalajara de la AMCIS, del cual es actualmente Presidente.

Aarón Moreno Monroy es Director de Operaciones de e-Quallity, empresa especializada en prueba de software. Es profesor de tiempo parcial en el I.T.E.S.O. Es candidato a maestro por el CINVESTAV campus Guadalajara en temas relacionados con verificación formal.

Elena Ruelas Minor es actualmente Administradora de Proyectos de prueba y consultora en e-Quallity. Es ISC por el ITESO. En su trayectoria como tester ha actuado como líder de proyectos de prueba y como tester senior de caja negra. Como consultora, ha aplicando el modelo TAM para diagnosticar áreas de prueba de distintas empresas del país y para diseñar planes de mejora.


El cambio no es instantáneo, pero una mañana te despiertas y lo sabes. Ves el mundo desde otra perspectiva.

La manija de la regadera se patina entre tus manos, como todos los días, pero esta mañana ya eres consciente de eso.

Subes al auto, y necesitas voltear a ver el con-trol, para quitar la alarma, pues el botón para activarla “se siente” de la misma forma que el botón para desactivarla. La camioneta tiene un control más “amigable”.

Ya rumbo a la oficina, el amarillo brillante de un anuncio sobre un edificio distrae tu atención, y después de un instante, vuelves la vista al camino; la combinación de colores te resulta, por lo menos, inapropiada, y eso te desanima a probar el licor que el chillante anuncio promociona.

Entras a la oficina, y al dejar la puerta de entra-da, te pareció que la manija esta debajo de la altura perfecta. ¿Consideraron a alguien para definir esa altura? ¿A quién?

El tiempo transcurre y todo sigue casi normal. El sol está alcanzando el cenit y ya estás atando varios cabos; piensas diferente, percibes dife-rente, te sientes diferente... eres diferente.

Tu colega y amigo, el que conoces desde hace tiempo, te pide que revises un documento que está por entregar; no es la primera vez que lo hace, pero es la primera vez que lo percibes; lo que tu amigo agradece es que le corrijas

algunas faltas de ortografía, cuestiones de re-dacción, pero también contenido... no es difícil para ti. Le devuelves el documento al cabo de unos minutos, y lo haces no sólo porque es tu amigo, sino porque te gusta hacerlo; además, sabes bien que suele equivocar los acentos en las graves, y abusa del “por lo tanto”.

¿Estos cambios serán temporales?, no lo sa-bes, pero no te inquieta, te sientes bien, qui-zá un poco más “perceptivo”, como te dijo tu esposa cuando le hiciste un comentario sobre su falda.

Piensas: “soy un buen desarrollador, tengo mu-cha experiencia en más de una plataforma y he participado en distintos proyectos de diversos tipos. Soy bueno en lo que hago. ¿Qué desen-cadenó este cambio? ¿Por qué me doy cuenta de cosas hoy que ayer no percibía?”

Ya camino a casa, notas que esa máquina de refrescos no tiene al lado un bote de ba-sura como el resto. ¿Quién pondrá ese bote que falta?

Llegas a casa y reflexionas, ¿Qué me ha pasa-do? Te sientes bien, relajado, pero, tienes en la mente muchas más preguntas que de costumbre;

ahora tu ojo es mas crítico. ¿Por qué ahora me pongo a pensar en el fundamento que debería tener el entrevistado del programa de las nueve?

Generas varias conjeturas: ¿Qué fue lo que me pasó? ¿Por qué a tantas cosas le encuentro “detallitos”? ¿Por qué se me ocurren mejores formas de hacer las cosas? ¿Por qué de repente pienso en lo que hay detrás de algún hecho, alguna afirmación, algún suceso? ¿Por qué me gusta cada vez menos asumir o suponer algo, y necesito cada vez más, una confir-mación, una evidencia?

Sobre la mesa del comedor, abres el vie-jo libro de Myers, vuelves a hojearlo y haces lo mismo con artículos de Kaner Black... de unos brincas a otros: Craig, Beizer, Jorgensen; cada vez hay menos eslabones sueltos.

Tu mente recorre rápidamente todos y cada uno de esos detalles que entretu-vieron tu mente, y que antes no perci-bías; estás muy cerca de darte cuenta.

Ya en la obscuridad, atas el último de los ca-bos; ya no eres el mismo. Tu transformación comenzó hace algún tiempo; hoy terminó una fase. Has cambiado. Has evolucionado: eres un Software Tester.

MetamorfosisPor Abraham Castillo

Abraham Castillo es actualmente senior tester de caja blanca en e-Quallity; es instructor en ese tema en los cursos impartidos por e-Quallity. Es ISC por el ITESO. Trabajó como desarrollador por más de 10 años y desde hace más de 5 años ha estado involucrado en proyectos de calidad y prueba de software.


Ahora tener cero defectos, y cumplir con todos los requerimientos y especifi-caciones, no basta para decir que el soft-ware tiene calidad, es necesario cumplir y exceder las expectativas del cliente, ha-cer más de lo que él espera para que real-mente haya una reacción de satisfacción y adopción.

El objetivo de hacer pruebas –más que encontrar la mayor cantidad de defec-tos– debe de ser mejorar en lo más posible la calidad y satisfacción del usuario final, afrontar esta situación con un enfoque constructivo, no destructivo. Un segundo objetivo, debe de ser también, crear indi-cadores acerca de la calidad del producto, para que los tomadores de decisiones en base a esto, puedan decidir si liberar o no un producto a tiempo, o si es necesario esperar y seguir mejorando el software,

hasta que cumpla con los estándares esta-blecidos. Por otro lado, el proceso de tes-ting debe de generar evidencia de que las pruebas se han hecho correctamente, exis-ten compañías que debido a fallas críticas en su software –que representan grandes cantidades de dinero para sus clientes–, han sido demandadas, y han tenido que presentar en la corte casos de prueba para comprobar que, realmente sí ejecutaron las pruebas debidas de manera responsa-ble, durante el tiempo del desarrollo.

Es por esto que es vital involucrar la par-te de Testing durante todo el ciclo de vida de desarrollo de software y no sólo al fi-nal, como en muchos casos se hace. Hoy en día, en la mayoría de las empresas, no existe un departamento de testing como tal, algunas veces, es el mismo desarrolla-dor, que al finalizar su parte del código, si

le queda tiempo, hace un par de pruebas por aquí y por allá, sólo para asegurarse de que lo que hizo, funciona, dejando a un lado otro tipos de pruebas que también son importantes. Son pocas las Universi-dades a nivel mundial que tienen en sus planes de carrera, materias relacionadas con testing, únicamente vemos en las cla-ses de Ingeniería de Software un apartado acerca del Aseguramiento de Calidad, pero esta disciplina se cubre de una manera muy limitada.

Si queremos alcanzar niveles altos de calidad para competir con nuestro software a nivel internacional, es necesario que el equipo de testing esté integrado desde el principio, representando al usuario final, evaluando requerimientos y empezando a probar el software desde la especificación, aunque no tenga en sus manos el producto final.

Software Testing Como una Disciplina Formal de la IngenieríaCómo Empezar a Hacer Pruebas HoyPor Gizela Oyervides

Pero, ¿cuál es la mentalidad de un tes-ter?, ¿un desarrollador puede ser un buen tester?. Esta es una pregunta in-teresante, un tester, necesita tener una curiosidad especial que lo lleve a querer intentar distintos escenarios al hacer sus pruebas, debe de ser una persona que quiera representar al usuario final, que se ponga en sus zapatos y que realmente intente utilizar el software de la manera que éste lo haría. Debe ser una persona estructurada, pero a la vez, con un pen-samiento lateral, que le permita ver más allá de lo que las personas normales ven; y al mismo tiempo debe tener la capaci-dad de orientar las pruebas de manera ordenada. Generalmente, se recomienda que el tester sea alguien que no haya de-sarrollado el software, para que el cono-cimiento de la arquitectura y algoritmos no afecte la manera en que prueba las cosas. Se tiene la imagen de que un buen tester es alguien que le gusta destruir y descomponer cosas; puede ser verdad, pero al mismo tiempo, debe de ser al-guien preocupado y comprometido con la calidad, como comentamos al principio.

Ya que tengo al equipo indicado de tes-ting, ¿cómo debo de empezar?, ¿cómo estructurar las pruebas de mi software? Pensemos en un microondas que pare-ce ser un aparato electrodoméstico muy sencillo, ¿qué pruebas le podemos ha-cer? Bueno, es necesario ver que caliente la comida, pero hay mucho más que eso, es necesario probar que haga las cosas para las cuales fue hecho, calentar, una de ellas; pero que también sirvan sus funciones para descongelar; que a la vez que calienta pollo, caliente bien la carne, que si calienta bien un plato pe-queño de comida, también caliente bien un kilo; que con el tiempo específico, no queme las palomitas. ¿Qué pasa si al mi-croondas lo utilizan al aire libre, donde le puede caer agua?, ¿funciona igual si lo utilizan en una cocina pequeña que si lo utilizan todo el día en un restaurante?, ¿qué pasa si mientras funciona, se va la luz?, ¿qué pasa con el reloj incluido en el micro, funciona bien?, ¿los distintos soni-dos que tiene, suenan cuando deben de sonar?, ¿qué pasa si me lo llevo a Ingla-terra donde el voltaje que utilizan es dis-tinto al de México? Existen un sin número

de pruebas que le podemos hacer a un microondas, podemos utilizar esta analo-gía y transportarla al software.

Una manera sencilla de explicar cómo se pueden organizar las pruebas, es a tra-vés de una pirámide, donde si las partes de arriba no van bien, no vale la pena seguir probando y hay que pedir que se arreglen los defectos antes de continuar. (Ver figura 1)

La punta de la pirámide es ver la funcio-nalidad básica: ¿el software hace lo que debe de hacer? Si es una calculadora, ¿hace las operaciones básicas? La si-guientes pruebas son las de funcionalidad extendida, ¿además de sumar, restar, mul-tiplicar y dividir, también puedes obtener raíz cuadrada?, ¿qué tal porcentajes? Tam-bién hay que probar casos extremos, si la calculadora maneja enteros, ¿qué pasa si le pongo un número entero mayor al que puede desplegar?, ¿qué pasa si hago operaciones con números decimales?, ¿qué pasa si hago operaciones con cero? Por otro lado, el performance también es importante, ¿la calculadora se tarda más tiempo en dar el resultado que hacer yo la operación en la mente? Hoy en día tam-bién vale la pena evaluar si el software es fácil de usar, ¿necesito leer cien páginas de instructivo para saber usarlo?, ¿es in-tuitivo?, ¿cuántos clicks tengo que dar para llegar a un resultado? Las pruebas de seguridad no hay que olvidarlas, ¿pueden

otras personas ver lo que estoy haciendo con mi software? Los sistemas de misión crítica necesitan correr los 365 días del año las 24 horas del día, ¿puedo confiar en que el sistema estará corriendo todo el tiempo?, ¿es de uso rudo?, ¿qué pasa si lo someto a condiciones de estrés? Estas pruebas son las de confiabilidad y estrés. Compatibilidad, ¿cómo trabaja mi apli-cación sobre X sistema operativo? Y qué pasa si quiero exportar esa calculadora, ¿la puedo vender en Japón?, ¿cumple con los estándares de calidad japoneses?

Es importante involucrar testing desde el inicio del ciclo de desarrollo para cumplir con estándares de calidad a nivel mundial, es recomendable que la mentalidad de un tester esté orientada al cliente y al mismo tiempo que esté comprometido con la ca-lidad. Existen distintos tipos de pruebas y todo depende de la magnitud del software que se esté construyendo, lo que se debe de buscar no es cero defectos, sino cumplir y exceder con las expectativas del usuario final del software.


“Es vital involucrar la parte de Testing

durante todo el ciclo de vida de desarrollo,

y no sólo al final”.

Figura 1. Pirámide para organizar las pruebas

Gizela Oyervides actualmente se desarrolla en el área de divulgación tecnológica en promoción de las plataformas de desarrollo de Microsoft. Ha sido Tablet PC Ingeniero de Pruebas de Software, Ingeniero de pruebas y diseño de software Intern en las oficinas de Microsoft en Redmond, Washigton. Así mismo se ha desempeñado como administra-dora del Laboratorio de Microsoft en el ITESM.


¿Qué tan bien se desempeña tu sis-tema? Desafortunadamente, muchas em-presas liberan sus sistemas sin saber la respuesta. El desempeño es un aspecto fundamental en una aplicación, ya que si ésta no responde en el debido tiempo, se pueden perder clientes, o dañar la imagen ante los usuarios.

Terminología y conceptosPara comenzar, es necesario introducir al-gunos términos y conceptos básicos; para ello, recurriremos a un ejemplo de la vida real: un supermercado.

En un supermercado hay clientes caminando entre los pasillos, que compran productos, y pagan en las cajas. Los supermercados gene-ralmente tienen más clientes que empleados, ya que, a cada cliente, le toma tiempo selec-cionar los productos, y por tal razón no nece-sitamos un cajero por cada cliente.

En el mundo del software, las peticiones a la aplicación representan a esos clientes, y ésta utiliza recursos (hardware y software) para manejar esas peticiones.

Carga es el término que representa a to-dos los usuarios de la aplicación en un determinado momento sin importar su actividad. Nos importa el número total de usuarios, no sólo los que están haciendo peticiones, ya que todos los usuarios con-sumen recursos. En un supermercado, los clientes ocupan un espacio físico, mientras que en una aplicación ocupan memoria u otro tipo de mecanismo para almacenar el estado de un cliente.

Después de que el super-mercado abre, el trá-fico de clientes no permanece cons-tante durante el día, sino que tiene horas pico. Una carga de picos se refiere al número máximo de clientes dentro de un período de tiempo. Este número no es un promedio. Al planear una prue-ba de desempeño, encontrar la carga pico y probar la aplicación contra esta carga es lo más importante.

El rendimiento de procesamiento, o throughput, mide la cantidad de peticiones servidas por unidad de tiempo. En el caso del supermercado, suponiendo que cobrar-le a cada cliente toma un minuto, y que hay cinco cajeros, el rendimiento será de cinco clientes por minuto. Esta métrica se caracteriza por tener un límite superior, es decir, no importa cuantos clientes visiten el supermercado, el número máximo de clien-tes atendidos en un intervalo de tiempo permanecerá constante. Así mismo, si una aplicación recibe 50 peticiones por segun-do, pero su rendimiento máximo es de 30, algunas peticiones tendrán que encolarse. Este límite típicamente representa un cue-llo de botella en la aplicación.

El tiempo de respuesta de una aplicación se refiere al tiempo desde que el usuario inicia una petición hasta que el resultado es visua-lizado. Hay veces en que en el supermerca-do hay que esperar en la cola hasta que una caja este disponible. Este tiempo de espera se suma al tiempo requerido para realizar la compra. Por lo tanto, si el cliente espero cuatro minutos, más el minuto que requirió la transacción, el tiempo de respuesta sería de cinco minutos. Entender el tiempo de respuesta de una aplicación requiere enten-der la relación entre carga, rendimiento de procesamiento, y el mismo tiempo de res-puesta. La aplicación alcanza su rendimien-to máximo con cierta cantidad de usuarios. Más allá de ésta (punto de saturación), el rendimiento permanece constante.

Sin embargo, el tiempo de respuesta empie-za a aumentar. La carga adicional espera a que los recursos saturados se liberen antes de que los pueda utilizar. Entender cuantos usuarios simultáneos soporta la aplicación y cuanto aumentan los tiempos de respues-ta en los momentos de mayor tráfico son las principales motivaciones para realizar una prueba de desempeño.

Así que, ¿qué podemos hacer para mejorar el desempeño de la aplicación? Básicamen-te, se pueden hacer dos cosas: optimizar o escalar la aplicación. La optimización se enfoca en modificar la aplicación para que consuma menos recursos, o para minimi-zar los cuellos de botella. Las técnicas de escalamiento, por otra parte, se enfocan en añadir recursos, por ejemplo, aumentando

Pruebas de DesempeñoLa Clave Para una Buena Aplicación


el número de servidores que hospedan la aplicación. En el escalamiento vertical se añaden más recursos al servidor, como CPU o memoria (el equivalente a añadir más caje-ros en el supermercado), mientras que en el escalamiento horizontal, se añaden servido-res para formar un cluster (el equivalente a añadir sucursales del supermercado).

Perfiles de aplicacionesUna pregunta importante antes de planear una prueba de desempeño es: ¿Qué es lo que la aplicación necesita hacer bien? Obvia-mente, los requerimientos de varios tipos de aplicaciones son diferentes, y en esa misma forma deben ser sus pruebas de desempe-ño. Por ejemplo, una aplicación financiera por lo general maneja grandes volúmenes de usuarios e información confidencial y actualizada en tiempo real. Así que en este tipo de aplicaciones no se puede sacar gran provecho de caches de datos. Otra conside-ración importante es la seguridad. Los meca-nismos de cifrado de datos, y otras medidas de seguridad como firewalls tienen un gran impacto en el desempeño. También es nece-sario registrar la actividad de los usuarios en bitácoras para auditoría o por regulaciones gubernamentales, lo cual impacta el proce-samiento en la aplicación.

Por otro lado, las aplicaciones tipo e-Com-merce son usadas por los clientes para ver

y comprar productos, y usar servicios como estado del envío o cancelaciones. Aunque puede haber una gran cantidad de usuarios concurrentes, solo un pequeño porcentaje realiza una compra. Sin embargo, se debe manejar muy bien la memoria para evitar un consumo excesivo.En este caso, hay que asegurar las partes de la aplicación donde se realicen transacciones (particularmente con SSL), aunque éstas normalmente represen-tan una pequeña fracción del tráfico total.

Por último, en el caso de aplicaciones de administración de información interna en una empresa, un día típico para el usuario puede incluir revisar el estatus del inven-tario, registrar nuevos productos, o con-sultar reportes generados en el momento. Por lo general, se conoce la cantidad de usuarios. Las páginas no contienen mu-chos gráficos pesados, ya que son ayudas de navegación, más que contenido. Los usuarios de estas aplicaciones están dis-puestos a aceptar un tiempo de respuesta más lento que los usuarios de otro tipo de aplicaciones, sin embargo, no por eso el desempeño pierde importancia.

Scripts de pruebaLos scripts dirigen la prueba de rendimien-to ya que simulan una serie de peticiones que el usuario realiza cuando utiliza la apli-cación. Para desarrollarlos se necesita en-

tender el comportamiento de los usuarios. Representar de manera precisa a los usua-rios en los scripts de la prueba tiene gran influencia en el rendimiento y carga de la misma prueba y sus resultados.

Durante la prueba, el mismo script es eje-cutado varias veces simulando múltiples usuarios. Para simular las diferentes op-ciones presentadas por la aplicación, se utiliza un conjunto de scripts. Éstos for-man un escenario de prueba.

Típicamente, se utiliza una herramienta para grabar las actividades de un usuario y generar el script automáticamente (inclu-yendo URLs de visita, tiempos de espera entre peticiones, cookies, etcétera).

Las siguientes recomendaciones se deben tomar en cuenta para desarrollar scripts:•Desarrollar scripts pequeños. Esto resulta en mayor flexibilidad para definir escena-rios de pruebas (en vez de escribir un script grande que abarque varias actividades) ya que los scripts pequeños permiten asignar diferente importancia a diferentes activida-des y facilitan el mantenimiento.•Escribir scripts atómicos. Por ejemplo, no hay que incluir en cada script las fun-ciones de login y logout, sino separar-los y hacer referencia a ellos desde los demás scripts. Esto permite elaborar escenarios complejos para los usuarios virtuales, como el siguiente: Login – Con-sulta – Ver Detalle – Imprimir Reporte – Modificar – Logout.•Permitir datos dinámicos. Durante la prueba, varios usuarios virtuales ejecutan el mismo script. Ya que no podemos cons-truir un script diferente por cada usuario que se simule, tenemos que paremetrizar el script para que represente varios usua-rios. Por ejemplo, en un script de Login se puede variar el nombre de usuario. Los parámetros requieren suficiente variación para reproducir exitosamente la actividad de los usuarios.


Ejemplos de datos dinámicos comunes son los siguientes:• Identificador (de usuarios, registros, pro-ductos, etc).• Datos ingresados por el usuario.• Parámetros de búsqueda.• Cantidades.• Fechas y horas.

Lo importante es generar una cantidad razonable de datos o selecciones diná-micas y no caer en la trampa de que los usuarios interactuarán con la aplicación justo como los diseñadores lo planearon. Un ejemplo claro, es la función de logout. Los usuarios no saben como salir (logout) de la aplicación, no importa que tan gran-de sea el botón para hacerlo. Por esto, no se puede depender de que los usuarios salgan correctamente del sistema, y se deben desarrollar los scripts tomándolo en cuenta.

Planeación de la pruebaAntes de empezar las pruebas de desem-peño, es necesario realizar las pruebas de funcionalidad e integración para asegura-se de que la aplicación funciona correcta-mente. El comportamiento errático puede exhibir mejor o peor desempeño que la versión correcta.

Comenzamos definiendo objetivos claros de desempeño para la aplicación. Ésta puede contener una infinidad de cuellos de botella, y si no hay objetivos claros, nunca sabremos cuando hemos llegado a un nivel aceptable de desempeño.

Decir que un caso de uso debe completar-se en “alrededor” de cinco segundos no es muy útil. Se debe enunciar un valor exacto que permita verificar el desempeño de la aplicación. Los objetivos deben ser flexibles también, en el sentido en que puede haber variación entre ejecuciones. Por ejemplo, ¿es aceptable que el caso de uso se ejecute en tiempo el 90% de las veces? ¿Es acep-table que el tiempo de respuesta sea de 5 segundos (cuando se espera sea de 3) una de cada 10 veces?

A continuación procedemos a estimar los datos necesarios para empezar la prueba. Asumiendo que la aplicación recibirá 1,000 peticiones por día (un período de ocho ho-ras), tenemos que:1,000 peticiones por día / 8 horas por día = 125 peticiones/hora

Esto nos da una distribución uniforme sin considerar los picos, así que, asumiendo un pico de cinco veces el promedio tenemos:125 peticiones/hora * 5 = 625 peticiones/hora

Convertido a segundos:625 peticiones/hora / 60 min. por hora / 60 seg. por min. = 0.17 peticiones/seg.

A continuación, asumiendo:•1,000 usuarios por día y 30% de ellos utiliza la aplicación durante la hora pico.•La visita promedio de un usuario dura 10 minutos.•El usuario utiliza en promedio 5 páginas por visita.•Cada sesión por usuario requiere 20 KB de memoria.•El tiempo de inactividad para eliminar la se-sión es de 15 minutos.Podemos sacar los siguientes cálculos:1,000 usuarios * 30% de usuarios pico = 300 usua-rios pico/hora (0.0833 por seg)

La cantidad de usuarios concurrentes la obte-nemos multiplicando los usuarios por segun-do, por la duración promedio de cada sesión (10 minutos).0.0833 * 10 * 60 seg. por min. = 50

Dado que cada usuario visita en promedio 5 páginas en un periodo de 10 minutos, y te-nemos 50 usuarios concurrentes, podemos estimar cuantas páginas debemos procesar por segundo:(50 usuarios * 5 pág.) / (10 min. * 60 seg) = 0.416 pág. por seg. (redondeamos a .42).

Si cada página contiene 10 elementos, las pe-ticiones al servidor (por cada elemento y sin tomar en cuenta caches) son:((1 petición inicial) + (10 peticiones de elementos)) * 0.42 pág./seg. = 4.62 peticiones/seg.

En cuanto a los requerimientos de memoria para soportar a los usuarios:0.0833 usuarios/seg. * (10 min. por usuario activo + 15 de inactividad) * 60 seg. por min. = 124.95 usuarios (aprox. 125)

125 usuarios * 20KB/usuario = 2.4 MB

Proceso y análisis El éxito de la prueba depende de la recolec-ción y análisis de datos y los cambios para mejorar el desempeño de la aplicación. El pri-mer paso es ejecutar una prueba de desem-peño simulando algunos usuarios y tal vez en un solo servidor. Durante la prueba hay que recolectar datos acerca de los clientes, los servidores y otros componentes usados.

Después, hay que análizar esos datos an-tes de seguir con la siguiente prueba. Sin embargo, se recomienda ejecutar la misma prueba dos o tres veces sin hacer cambios y comparar los resultados. ¿Las pruebas produjeron más o menos los mismos re-sultados? Si la respuesta es afirmativa, se

puede proceder a las optimizaciones. En caso contrario (si la variación es mas del 10%), hay que corregir esto antes de conti-nuar. Algunas posibles causas pueden ser:•Probar en un ambiente compartido. •Ejecuciones cortas. Hay que darle su-ficiente tiempo a la prueba, es decir, “calentar motores”.•Crecimiento en la base de datos. La apli-cación probablemente creo y/o actualizo muchos registros durante la prueba y esto hace que se degrade el desempeño. En este caso, hay que considerar scripts que limpien la base entre ejecuciones, o averiguar si este comportamiento será normal en producción.

Después de analizar los datos y posible-mente identificar cuellos de botella, es tiempo de optimizar. Idealmente, se debe hacer solo un cambio, ejecutar la prueba de nuevo y analizar los datos antes de ha-cer otro ajuste o seguir con otra prueba. Esto ayuda a medir de forma aislada, el impacto del cambio en la aplicación.

Teniendo en cuenta todo lo anterior, las pruebas de desempeño se deben con-ducir en los siguientes puntos del ciclo de desarrollo:•Pruebas unitarias. Estas deben ser realiza-das por cada desarrollador antes de liberar sus componentes y significa que éstos de-ben ser analizados en cuanto a memoria y código, por lo general con al menos 10 usuarios, solo para validar los tiempos de respuesta objetivo.•Pruebas de integración de la aplicación. Esta prueba genera una carga con el número de usuarios proyectados que se espera que la aplicación soporte en producción.•Pruebas de producción. Aquí se prueba en un ambiente lo más similar al que va a estar trabajando la aplicación en producción.

DatosLa prueba de desempeño es tan buena como los datos que produce. Los siguientes datos son aquellos que siempre se deben recolec-tar en la prueba de desempeño:•Utilización del CPU. Este dato se debe medir en todos los sistemas involucrados en la prueba para distinguir posibles cue-llos de botella.•Datos de la Red. Aquí se puede utilizar el comando netstat. La medición se debe tomar antes y después de la prueba y la diferencia es la cantidad de tráfico que ésta generó. •Monitoreo de las bitácoras. Éstos re-flejan los problemas ocasionados por la carga o sistemas de soporte. El nivel de registro, debe estar en niveles aceptables. Demasiada información es difícil de ma-nejar y además impacta negativamente al desempeño.


•Monitoreo de Servidores. Algunos servidores cuentan con herramientas que permiten monitorear sus recursos internos, pero también hay que tomar en cuenta que algunas impactan el des-empeño, por lo que hay que utilizarlas con moderación.

Problemas comunesEntre los problemas más comunes que se descubren en las pruebas de des-empeño están:•Baja utilización de los recursos. Los clientes generan baja utilización del CPU y el tiempo de respuesta aumenta al tiempo que se agregan usuarios, mien-tras que el rendimiento permanece igual. La causa principal es un recurso saturado en el sistema (la red, la base de datos, un sistema de soporte, etc.)•Insuficiente capacidad en la red. Este problema es frecuente en aplicaciones que regresan una respuesta más grande que la anticipada en el diseño. Hay dos soluciones, aumentar la capacidad de la red o reducir la cantidad de datos que se transfiere por la red.•Recursos insuficientes. La mayoría de las ocasiones esto se debe a la base de datos o una aplicación de soporte. Una solución podría ser solucionar los problemas de des-empeño de ese recurso (agregando CPUs, índices, etc.). Otra, es incrementar el núme-ro de conexiones o accesos a ese recurso.•Alta utilización del CPU. Un CPU satu-rado no necesariamente significa que el servidor no puede soportar carga adicio-nal. Los usuarios sólo conocen el tiempo de respuesta. Un servidor saturado puede continuar soportando una intensa carga mientras el tiempo de respuesta perma-nezca aceptable (si la cola permanece lo suficientemente corta). Además, es útil distinguir entre la utilización del CPU y el tiempo en que el CPU espera a algún recur-so saturado. •Balanceo de carga desigual. Esto su-cede en algunos clusters donde uno o más servidores reciben una cantidad desproporcionada de tráfico con res-pecto a los demás. Aquí se requiere configurar el balanceador de carga a un algoritmo óptimo.

Planeación de capacidadLa planeación de capacidad nos dice que tanto hardware y software se necesitan para el correcto desempeño de la apli-cación basándose en los resultados de las pruebas de desempeño. También nos proporciona un plan de crecimiento y actualización sobre un periodo definido de tiempo.

Esta planeación siempre se debe basar en los picos, para que se puedan soportar. Este ejercicio combina los objetivos de la prueba con los resultados para determi-nar la combinación y número apropiado de servidores. Enfocándose en los datos de escalabilidad y utilización de CPU, se construye los planes de capacidad ini-cial. Después, ya que la aplicación este funcionando, se compara el desempeño real con el de los planes. Si se encuentran diferencias, hay que ajustar los planes de capacidad.

También se tiene que decidir cuanto se quie-re de colchón, en caso de que haya una equi-vocación al proyectar la carga o para permitir un crecimiento en el futuro.Idealmente, hay que tratar de clasificar la aplicación en una de las siguientes categorías:•Extremadamente debajo de su capaci-dad. La aplicación puede soportar más de 50% de capacidad adicional. En este caso, se puede considerar reducir recur-sos de hardware o servidores y/o para evitar costos de licencias.•Debajo de su capacidad. La aplicación pue-de soportar fácilmente más de 25% de capa-cidad adicional. En este caso, se puede estar tranquilo en cuanto a que la aplicación cum-plirá sus objetivos, y no hay razón para quitar recursos a la aplicación.

•Cerca de su capacidad. La aplicación cumple los objetivos de desempeño, pero menos de 25% arriba de su capacidad adi-cional. En este caso, se necesita platicar con el cliente para determinar posibles cambios futuros que puedan impactar en el desempeño y en base a esto, ver si se justifica añadir recursos.•Sobre su capacidad. La aplicación no cumple con los objetivos de desempeño, y hay que evaluar si vale la pena optimi-zarla o escalarla.•Extremadamente sobre su capacidad. La aplicación se satura con la carga espe-rada. Se necesita optimizar seriamente la aplicación y posiblemente agregar más hardware para satisfacer la demanda.

ConclusionesLas pruebas de desempeño son una actividad importante del de-sarrollo de sistemas. Desafor-tunadamente, su uso no es muy extendido. Por medio de una ana-logía, vimos que básicamente los mismos problemas encontrados en el mundo real, también evitan que las aplicaciones de software alcance su máximo potencial en cuanto a desempeño. Finalmente, cabe recalcar que una prueba de desempeño es un proceso itera-tivo. Se prueba, recolectan datos, se verifican, analizan y se optimi-za. Este proceso ocurre repetida-mente hasta que se alcancen los objetivos de todos los escenarios de prueba.


Arquitectura Orientada a ServiciosPARTE 3: ESTANDARIzACIóN, gOBERNABILIDAD y METODOLOgíAS

Por Gabriel Vázquez

/* ARQUITECTURA */

En los artículos anteriores hemos hablado de las diferentes capas de una arquitec-

tura SOA. Que resuelven necesidades espe-cíficas en las empresas para la integración de aplicaciones, automatización de procesos, orquestación de servicios, nuevas aplicacio-nes; sin embargo, pensar SOA como habilitar las aplicaciones con servicios estándares no es suficiente, y surgen las preguntas: ¿Por dónde empiezo? ¿Cuál es la mejor forma de hacerlo? ¿Cómo me ayudan mis prácticas ac-tuales de desarrollo? ¿Cómo impacta SOA en mi empresa? En este último artículo, vamos a hablar de modelos de gobierno, metodo-logías y centros de competencia para crear nuestra arquitectura SOA en mi empresa y responder estas preguntas.

A continuación, presentaremos las mejores prácticas para la implementación exitosa de una arquitectura SOA que se han detectado en la industria. Hay que recordar que cada empresa debe tomar en cuenta su situación actual, para adecuarlos a sus necesidades:•Crear la arquitectura SOA a partir de los ob-jetivos de la empresa.•Crear estándares corporativos.•Desarrollar la arquitectura con capas bien definidas.•Fomentar el reuso de componentes y crea-ción de patrones.•Modelo de Gobierno de las arquitecturas SOA•Tomar como punto de partida la situación actual de la empresa.•Desarrollo de metodologías.

•Entender la semántica de la información y sus fuentes, así como el funcionamiento de la empresa a través de procesos.

Crear la arquitectura SOA a partir de los objetivos de la empresaLas arquitecturas SOA se convierten en el sistema nervioso empresarial, es decir, se encuentran fuertemente atados a las activi-dades y procesos que se realizan a lo largo de las empresas e instituciones. Crear una arquitectura SOA no debe ser un proyecto por sí mismo, más bien, requiere un aná-lisis de los objetivos de la empresa y de la situación actual, para determinar el grado de agilidad, eficiencia y niveles de servicio requeridos. La arquitectura SOA, debe pro-porcionar elementos que permitan medir el desempeño de estos objetivos de negocio, de cada artefacto construido, por ejemplo, si se automatiza un proceso en una herramien-ta BPM, se deberán incluir indicadores de rendimiento del proceso, como su duración y uso de recursos.

Crear estándares corporativosXML es el estándar tecnológico fundamental en la creación de arquitecturas SOA. Actual-mente es muy adoptado en la industria por su versatilidad, flexibilidad e independencia tecnológica, constituyendo la piedra angu-lar de estándares técnicos muy importantes como son XSD, XSLT, SOAP, UDDI y WSDL; en el caso de los procesos tenemos estándares como XPDL, BPEL, ASAP y SWAP. Adicional-mente a los estándares técnicos es necesario definir los estándares corporativos basados en modelos de integración, metadatos, tipos de servicios web, seguridad, orquestación de servicios, y gestión de procesos. En el mer-cado ya se encuentra software que funciona como un repositorio corporativo basado en estos estándares, para llevar un control de cada uno de los artefactos, y fometar el reuso de componentes. Es muy recomendable estu-

diarlos desde el principio, para conocer con detalle cómo colaboran en nuestro beneficio.

Desarrollar la arquitectura con capas bien definidasEl desarrollo de una arquitectura orientada a servicios, debe orientarse a capas con funciona-lidad bien definida, un buen inicio son las que hemos descrito en los articulos anteriores. Esto permitirá crear una arquitectura sólida, estan-darizada, que cumpla con las necesidades de la empresa, cabe mencionar que, no es necesario contar con cada una de ellas, pero sí conside-rarla para adoptar una estrategia evolutiva. Esto último, se traduce en la escalabilidad, compleji-dad y capacidad de procesamiento.

Fomentar el reuso de componentes y creación de patronesUn factor importante a considerar en las ar-quitecturas SOA, es el reuso tanto de cono-cimiento como elementos tecnológicos. Es decir, en estos ecosistema tecnológicos, cada día se crean nuevos elementos y si no se lleva un control adecuado, se pueden perder los beneficios transformándose en un caos. Por esto, es necesario fomentar el reuso de cada uno de ellos, para obtener un mejor retorno de la inversión y nueva funcionalidad con un menor esfuerzo. La definición de los nuevos elementos debe ser ordenada, estandarizada y fielmente documentada. Esto último es de gran importancia, si recordamos que la funcio-nalidad de la arquitectura de servicios se con-vierte en la espina dorsal de las empresas.

El primer factor para fomentar el reuso, es a través de un repositorio donde se co-loquen los elementos de una arquitectura SOA con servicios como versionado, análi-sis de impacto, identificación de servicios implementados, reportes de uso, y direc-torio de servicios. La segunda, es a través de la creación de patrones de diseño, que permita resolver de manera estructurada y estándar las diferentes situaciones

Gabriel Rolando Vázquez Pérez, tiene más de diez años de experiencia en Consultoría de la Tecnología de Información en ambientes multiplataformas. Actualmente es arquitecto de arquitecturas SOA y vocero de CrossVision. Se ha desempeñado en el área de consultoría y preventa en las industrias de telecomunicaciones, financiera, sector público, transporte y manufactura. Dentro de Software AG ha desempeñado varios cargos durante su trayectoria tanto a nivel nacional como internacional en las áreas de soporte técnico, preventa, consultoría de estrategia y negocio.

// PRÁCTICAS


Modelo de gobierno de las arquitecturas SOALa agilidad para el cambio en las empresas a su entorno de competencia, es una cua-lidad que se construye y les proporciona solidez. Anteriormente, la tecnología por sí misma era estratégica y venía acompañada de grandes inversiones en hardware y soft-ware con innovaciones incorporadas. Esto ha cambiado. Hoy, la estrategia se centra en la flexibilidad que pueda proporcionar la tecnología en beneficio de la empresa, para permitir una adaptación rápida al cambio, alto grado de colaboración en su beneficio, y reuso de la inversión existente. Construir una arquitectura SOA no es sencillo, requie-re de un enfoque sistémico, tanto técnico como de negocio, basado en una planeación estratégica evolutiva que permita alinear la empresa hacia a un solo fin.

Para alcanzar esta alineación, es necesario un nuevo enfoque basado en un modelo de gobierno para SOA. El modelo de Gobierno SOA se enfoca para resolver, gestionar, y unificar los esfuerzos mediante un comité multidisciplinario, con prácticas de colabo-ración entre los diferentes actores de las em-presas. Estas prácticas incluyen esquemas de toma de decisiones, seguimiento de la toma de decisiones, detección temprana de nuevos requerimientos de negocio y tecno-logía; creación de estándares corporativos, análisis de impacto, interdependencias, me-todologías y políticas. El modelo de gobier-no puede contar con miembros permanentes o temporales, dependiendo de los objetivos que se estén resolviendo.

Tomar como punto de partida la situación actual de la empresaEs importante asegurarse que la conformación de la arquitectura orientada a servicios se base en la situación de las empresas, con la finali-dad de asegurar su compatibilidad y grado de colaboración con la infraestructura existente. En las empresas, cada situación es única y de-manda funcionalidad específica. Es por esto que, si la tecnología que se va a utilizar no se prueba en ambientes reales, se corre el riesgo de crear una arquitectura inflexible, cara, sin control, y dependiente de algún proveedor.

Aunque la tecnología y los estándares ya se encuentran maduros para proveer el valor, las empresas deben evaluar la situación ac-tual de su infraestructura, y decidir sobre la adopción de los estándares encaminados por un lado al reuso de la funcionalidad actual, y proteger la inversión. No es aconsejable adaptar la empresa a la arquitectura SOA.

Entender la semántica de la infor-mación y sus fuentes, así como el funcionamiento de la empresa a través de procesosEs indispensable establecer modelos de la información con que se cuenta en las apli-caciones, y los procesos de negocio que se realizan.Al elaborar la semántica bajo un modelo de entidades de negocio en las empresas, se incluye la descripción de los datos en términos de negocio que sean de utilidad para el entendimiento de la in-formación en los sistemas y cómo pueden colaborar entre ellos. Con esto en mente, se desarrollan los servicios orientados a proporcionar la funcionalidad que deberá compartirse entre ellos.

En el caso de los procesos, estos deman-dan información de los diferentes sistemas, recursos que necesitan métricas de desem-peño, institucionalización de los procesos, definición de interfases, y monitoreo de los mismos, para contar con un método de eva-luación que permita tener una mejora conti-nua en la empresa o institución, y conocer el desempeño a través de ellos.

Desarrollo de metodologíasCuando se habla de arquitecturas orienta-das a servicios, no podemos evitar hablar de mejorar los procesos de negocio actuales que rigen a las empresas, por lo que hacerlo de una manera ordenara es crucial. Sin em-bargo, cabe destacar que las iniciativas de arquitecturas SOA deben surgir de objetivos de negocio, que permitan reconocer el bene-ficio que se va a obtener del esfuerzo que se realizará. Toda iniciativa SOA, debe basarse en una metodología que permita obtener re-sultados esperados, y lograr homogeneidad en el funcionamiento, y permitir el equilibrio entre los elementos clave: en el mercado

existen metodologías de desarrollo muy pro-badas que se pueden adaptar para su uso, como lo es el Proceso Unificado, Programa-ción Extrema, Métrica 3, etcétera. También se puede incorporar las mejores prácticas derivadas de modelos de referencia como CMMI, ITIL y COBIT.

Las metodologías se tienen que desarrollar específicamente para las necesidades actua-les con base en la infraestructura con que se cuenta. El desarrollo de las metodologías proporciona estructura y orden para abor-dar la creación de los elementos de SOA, así como el manejo del cambio, diseño de servi-cios, congruencia, y poder incorporar ayuda de manera más efectiva.

Uno de los errores comunes en el uso de tecnologías, es la falta de adecuación a las realidades de la empresa, no hay que olvidar que la finalidad de la metodología, es con-vertirse en una herramienta para...•Establecer políticas.•Procesos y recursos planeados.•Asignar responsabilidades.•Entrenar a la gente.•Apoyo de la dirección.•Monitoreo y control.

ConclusionesLas arquitecturas SOA se derivan de los objetivos de negocio que tienen las empresas y se convierten en su espina dorsal, por lo que es impor-tante planear su creación. Un factor de éxito muy importante es tomar en cuenta la situación actual de la em-presa, para crear aquellos elementos SOA que la conformarán. También, dada su alta orientación al negocio, es necesario su control mediante un modelo de gobierno que incluya tan-to la parte de negocio como técnica y que alinie todos los esfuerzos bajo un solo fin. La estandarización técnica y de negocio, acompañada de los obje-tivos de negocio es muy importante para tener éxito y el mejor beneficio posible para las empresas.

Muchos desarrolladores han elegido Spring como reemplazo de J2EE para sus proyectos. Mientras que este enfoque es funcio-

nal, y por tanto válido, cabe destacar que esa no es la intención inicial del framework, y que tal premisa forma parte del sumario Ten Com-mon Misconceptions About Spring, escrito por Steve Anglin. Spring hace maravillas con el enfoque antes mencionado sí-y sólo sí- el domi-nio de problema que atiende el desarrollo está perfectamente acotado dentro de los componentes más usados de J2EE; específicamente la combinación capa de negocio con Stateless Session Beans y capa de web con Servlets, JSPs, ambos, o algún framework de web.

Lo que Spring no haceSpring evoluciona constantemente gracias a que es un proyecto por, y para la comunidad de desarrollo de software. Sin embargo, aún existen algunas brechas tecnológicas que salen a la luz al implemen-tar diseños que se satisfagan con componentes J2EE menos "famo-sos" como JCA, o JMS. Un ejemplo es la propagación de contextos transaccionales remotos, donde el uso de EJBs se vuelve imprescin-dible. Otro es el Java Message Service, para el cual Spring no provee un reemplazo out-of-the-box.

JMS + SpringSegún el roadmap de Spring2, éste tendrá un soporte bastante robusto y poderoso para todo lo que concierne a JMS. Dichas características son parte de varios trabajos que han realizado contribuyentes de Spring, como LogicBlaze. Para aquellos que no quieren esperar al release final, hay simples recetas de cocina que pueden usar para crear algunos com-ponentes ligeros como Message-Driven POJOs (MDPs), o Queue/Topic Senders. A continuación se muestra como hacer cada uno.

Message-Driven PojosSu definición es auto-explicativa. A continuación se muestra un MDP sencillo:

Obviamente, cada una de estas propiedades tiene sus getters y setters, para hacer posible la inyección de algunas de ellas. La primera propiedad es un javax.jms.Destination de tipo Queue. Es el elemento JMS sobre el cual este MDP va a estar escuchando por mensajes. Esta propiedad puede ser descrita en un application context, como se muestra a continuación:

De esta manera podremos inyectarla a nuestra clase en el applica-tion context, como se verá mas tarde.

El QueueConnectionFactory es un objeto JNDI "proxeado" median-te un JndiObjectFactoryBean de Spring en un applicationContext, como se muestra a continuación.

El MessageManager es el componente responsable por el procesamiento de la información contenida en el mensaje. Este diseño provee separación total de código de extracción y manejo de mensajes, y código de negocio de procesamiento de la información contenida en él. La implementación de este componente es total responsabilidad del programador.

Las propiedades QueueConnection y QueueReceiver se obtienen de métodos del QueueConnectionFactory, por lo cual se inicializan en un método init. Éstos recursos se liberan al destruirse este MDP, me-diante el método destroy. A continuación muestro los listados tanto para el init() como para el destroy().

/* PROGRAMACIÓN */

Aprovechando JMSCon Spring 1.2.x’Por Jesús Ramos

Jesús Ramos es egresado del ITESM Campus Monterrey, y se especializa en desarrollo de sistemas financieros en plataforma J2EE y Adobe Flex. Creó el sistema de tesore-ría para Ixe Banco, así como la capa de servicios del portal financiero IxeNet. Actualmente es Ingeniero de Software en Bursatec S.A., donde creó el sistema de administración de seguridad para S.D. Indeval S.A., y donde co-fundó el grupo de usuarios SpringHispano.org.

public class MessageListenerPojo implements

MessageListener {

private Queue destination = null;

private QueueConnectionFactory connection

Factory = null;

private MessageManager manager = null;

private QueueConnection connection = null;

private QueueReceiver queueReceiver = null;

}



<bean id=”destination” class=”org.springframework.jndi.JndiObjectFactoryBean” lazy-init=”true”>

<description>Queue for listening to messages.</description>

<property name=”jndiName”>

<value>jms/MessageQueue</value>

</property>

</bean>



<bean id=”connectionFactory” class=”org.springfra-

mework.jndi.JndiObjectFactoryBean” lazy-init=”true”>

<description>ConnectionFactory for JMS

Serverconnections</description>

<property name=”jndiName”>

<value>jms/ConnectionFactory</value>

</property>

</bean>

// PRÁCTICAS

Método init():

Método destroy():

Estos métodos se ejecutan una sola vez, mediante el mecanismo de init/destroy de Spring. La manera de especificar a Spring que el MDP debe inicializarse con init(), y destruirse con destroy(), es estable-ciendo las propiedades init-method y destroy-method al describir el MDP en un application context, como se muestra a continuación:

Observen ahora la interfaz javax.jms.MessageListener. Dicha interfaz firma el método onMessage, que es responsable de ‘despertar’ el MDP cuando llega un mensaje, inyectada en la pro-piedad ‘destination’. A continuación se muestra la implementa-ción de este método:

El método onMessage(), como dijimos anteriormente, sólo extrae la in-formación del mensaje. En este caso, estamos extrayendo un mensaje de tipo objeto (usualmente un JavaBean). Noten cómo el método no efectúa ninguna llamada sobre el objeto que extrajimos del mensaje, delegando dicha lógica al manager. Obviamente, este MDP depende de que los recursos J2EE que se están inyectando, existan en el árbol JNDI del application server. Es posible crear MDPs sin que éstos vivan en un app server. Tal enfoque está fuera del alcance de este tutorial.

Spring Queue / Topic SendersPara que un MDP "despierte" y pueda consumir los mensajes que lle-gan a la cola que está escuchando, se requiere que algún componen-te envíe un mensaje a una cola, o un tópico, respectivamente. Spring ofrece mayores facilidades para la tarea del envío de mensajes a los destinos JMS, que los que ofrece para recibirlos y responder a ellos.

La clase que utilizaremos para acceder a los servicios JMS es org.springframework.jms.core.JmsTemplate. Cabe destacar que se basa en la versión 1.1+ del API de JMS, donde no es importante si el destino es una cola o un tópico. Para los application servers cuya implementa-ción de JMS se base en la versión 1.0.2, se utiliza la clase JmsTempla-te102, que está en el mismo paquete.

Siguiendo con las prácticas propuestas por Spring, nuestro MessageSen-der deberá ser construido usando el par Interfaz / Implementación. La interfaz firmará un método send, que recibirá como argumento el objeto a enviar. Tipificaremos el parámetro con la interfaz java.io.Serializable:

abstract void send(Serializable obj);

La implementación de esta interfaz llamada MessageSenderImpl, tendrá dos propiedades, cada una con su getter y setter. Una de ellas será de tipo JmsTemplate, y es la clase que nos ayudará con el envío de mensa-jes. La otra variable miembro será de tipo javax.jms.Destination, que es la interfaz que implementan las colas y los tópicos JMS. Esto nos dará la flexibilidad de poder modificar el destino de los mensajes de una cola a un tópico, sin tener que cambiar nuestro código.


public void init() throws JMSException {

conn = connectionFactory.createQueueConnection();

QueueSession session = null;

conn.setClientID(“MY_CLIENT”);

conn.start();

session = conn.createQueueSession(false, Session.AUTO_ACKNOWLEDGE);

queueReceiver = session.createReceiver(destination);

queueReceiver.setMessageListener(this);

}

public void destroy() throws JMSException {

queueReceiver.setMessageListener(null);

queueReceiver.close();

queueReceiver = null;

connection.close();

connection = null;

}

<bean id=”messageListener” init-method=”init” destroy-method=”destroy”

class=”org.springhispano.recetario.MessageListenerPojo” >

<property name=”connectionFactory”>

<ref local=”connectionFactory” />

</property>

<property name=”destination”>

<ref local=”speiDestination” />

</property>

<property name=”messageManager”>

<ref local=”speiMessageManager” />

</property>

</bean>

public void onMessage(Message msg) {

try {

if (msg.getJMSRedelivered()) {

LOG.error(“Mensaje reentregado. "+ "No se procesará:“ + msg);

}

else {

LOG.debug(“Mensaje nuevo. Se procesará “ + msg);

Object o = ((ObjectMessage) message).getObject();

manager.processMessage(o);

}

msg.acknowledge();

} catch (JMSException jme) { LOG.error(jme);

}

“Según el roadmap de Spring2, éste tendrá un soporte bastante robusto y poderoso para todo lo

que concierne a JMS”.

A continuación implementamos el método send, de la manera que se muestra a continuación:

Este método utiliza el JmsTemplate para enviar el mensaje. A su vez, éste recibe como argumentos la cola o tópico destino del mensaje, y una implementación de org.springframework.jms.core.MessageCreator, que se provee como clase anónima. Dicha interfaz la provee Spring a manera de call-back. El MessageCreator obtendrá la sesión JMS desde el JmsTemplate. La bondad de usar esta interfaz es que no tenemos que preocuparnos por posibles JMSExceptions que ocurran durante la construcción del mensaje en session.createObjectMessage(), dado que Spring las manejará y las convertirá en excepciones no-verifica-das, justo como trata el resto de las excepciones de infraestructura.

Ahora sólo nos queda describir nuestro MessageSender en el appli-cation context de Spring, con el siguiente listado:

Examinemos la primera propiedad. Si queremos hacer que nuestro MessageSender envíe mensajes que sean consumidos por nuestro MDP, basta con inyectarle el mismo destino JMS. La segunda propie-dad es la más importante para nuestro MessageSender. El JmsTempla-te se describe en el application context con el siguiente listado:

En este sencillo bean se está inyectando otro del tipo javax.jms.Connec-tionFactory. Justo como la propiedad ‘destination’ de nuestro Messa-geSenderImpl, la propiedad connectionFactory puede ser la misma que la descrita en la primera sección del tutorial, si acaso se desea producir men-sajes para el MDP que construimos en la primera sección del tutorial.

¿Qué sigue?El aprovechamiento de lo presentado aquí, obedece a las mismas reglas de diseño donde sea evidente la implementación del patrón ServiceActi-vator; por ejemplo en la capa de integración de algún sistema, donde se deba tener comunicación con otras plataformas de manera asíncrona.

Lo que hemos implementado en este tutorial tiene la ventaja de ser ligero (como la mayoría de lo que se construye con Spring, o al me-nos esa es una de las intenciones del framework) y fácil de construir. Otra ventaja es la centralización de la configuración de consumido-res y productores de mensajes en un solo modelo, en contraste a los Message-Driven Beans, los cuales son configurados por dos deploy-ment descriptors con gramática distinta, por lo que se tienen dos puntos de configuración que mantener.

Por otro lado, la desventaja más grande de este enfoque es que las sesiones obtenidas del JmsTemplate de Spring no son transactadas; ni aún cuando el ConnectionFactory sea de tipo XA (es decir, que par-ticipe en transacciones distribuídas). Esta es un área de oportunidad para el framework, que se atiende y se resuelve en su versión 2.

Mayor información en www.springframework.org.


/* PROGRAMACIÓN */

public void send(final Serializable serializable) {

jmsTemplate.send(destination, new MessageCreator() {

public Message createMessage(Session session) throws JMSException {

Message msg = session.createObjectMessage(serializable);

return msg;

}

} );

}

ConclusiónComo podemos ver, Spring es un complemento per-fecto para la plataforma J2EE, y no un reemplazo, como muchos lo consideran. Si bien es cierto que usar todo el stack de J2EE para aplicaciones peque-ñas es como utilizar C4 para volar una puerta em-parejada, también es cierto que Spring queda corto para muchos requerimientos de aplicaciones em-presariales gigantes; sobre todo aquellas con una gruesa capa de integración. Spring y J2EE deben per-tenecer a un enfoque híbrido al momento de escoger tecnologías de desarrollo empresarial, y así, alejar-nos de concepciones puristas que, a la larga, limita-rán la calidad y variedad de soluciones que podemos entregar a nuestros clientes. Ambos son como el pay de queso y la mermelada de zarzamora: separados saben bien... juntos saben mejor :P

<bean id=”messageSender” class=”org.springhispano.recetario.MessageSenderImpl”>

<property name=”destination”>

<ref local=”destination” />

</property>

<property name=”jmsTemplate”>

<ref local=”jmsTemplate” />

</property>

</bean>

<bean id=”jmsTemplate” class=”org.springframework.jms.core.JmsTemplate”>

<property name=”connectionFactory”>

<ref local=”connectionFactory” />

</property>

</bean>

public class MessageSenderImpl implements MessageSender {

private JmsTemplate jmsTemplate = null;

private Destination destination = null;

public void setDestination(Destination destination) {

this.destination = destination;

}

public void setJmsTemplate(JmsTemplate jmsTemplate) {

this.jmsTemplate = jmsTemplate;

}

// PRÁCTICAS

/* ASEGURAMIENTO DE CALIDAD */


Las organizaciones que desarrollan productos basados en software requieren de prácticas efectivas que permitan mejorar la calidad

del producto. La Ingeniería de la Confiabilidad de Software es una práctica cuantitativa que puede ser implementada en organizaciones de cualquier tamaño bajo distintos modelos de desarrollo.

Las organizaciones desarrolladoras de productos basados en soft-ware destinan grandes cantidades de recursos para mejorar la cali-dad de sus productos. Una parte de dichos recursos se utiliza para la adopción de mejores prácticas. Sin embargo, la dificultad de la adopción de dichas practicas no sólo reside en el costo y el tiempo requerido para institucionalizarlas, sino en cómo medir su impacto en la calidad del software, así como demostrar el retorno de dicha inversión. El grupo de Confiabilidad de Software y Sistemas (SoSYR) del Centro de Investigación en Matemáticas A.C., lleva a cabo investi-gación sobre prácticas industriales de bajo costo, con un alto impac-to en la calidad de los productos de software y que sean aplicables a organizaciones de distintos tamaños.

En este artículo se introduce a la Ingeniería de la Confiabilidad de Soft-ware (ICS). La ICS es una práctica de bajo costo, independiente del modelo de desarrollo y de la plataforma tecnológica que permite ca-racterizar y controlar de manera cuantitativa la calidad del producto.

La calidad, las fallas y la confiabilidad de SoftwareLa calidad es un atributo percibido por los usuarios o clientes de cualquier producto o servicio. En el caso de productos basados en software, la percepción de la calidad está en función de las fallas que el cliente percibe del mismo durante su operación.

La confiabilidad es un atributo que mide el grado en que un produc-to opera sin fallas bajo condiciones establecidas por un periodo de tiempo determinado. La confiabilidad es un atributo cuantitativo que ha sido ampliamente analizado, estudiado y usado en otras indus-trias para caracterizar la calidad de los productos o servicios. En su concepción más general, la confiabilidad es un atributo que mide el grado en que un producto opera sin fallas bajo condiciones estable-cidas por un periodo de tiempo determinado.

Una falla es la manifestación percibida por el cliente de que algo no funciona correctamente e impacta su percepción de la calidad. Un de-fecto es el problema en el producto de software que genera una falla.

¿Qué es la Ingeniería de Confiabilidad de Software?La ICS es una práctica que permite planear y guiar el proceso de la prueba del software de manera cuantitativa. La ICS no es algo nuevo. Se origina en los años 70 con los trabajos de J. D. Musa, A. Iannino, y K. Okumoto[1]. Su efectividad ha hecho que muchas empresas incor-poren esta práctica en sus proyectos, tales como AT&T, Alcatel, HP, IBM, Lockheed-Martin, Microsoft, Motorola, entre otras. El impacto de dicha práctica se ha visto en la aprobación de un estándar de la AIAA (en 1993) así como sus correspondientes versiones en los es-tándares de IEEE. Cabe mencionar que se han documento más de 60 artículos reportando los resultados de la aplicación de la ICS en distintos proyectos[2].

Dos elementos caracterizan la ICS: (1) el uso esperado relativo de las funcionalidades del sistema y (2) los requerimientos de calidad definidos por el cliente, que incluyen la confiabilidad, la fecha de li-beración y costo del ciclo de vida del proyecto.

El primer elemento (1) se centra en caracterizar de manera cuan-titativa el uso esperado del sistema mediante la definición del llamado perfil de operación del sistema. Esta caracterización cuantitativa permite optimizar el uso de los recursos en las fun-ciones que tengan un mayor impacto y mayor uso esperado dentro del sistema.

El perfil de operación de un sistema es la caracterización cuantitati-va del uso que se espera de las funcionalidades principales del sis-tema. Por lo general se usan probabilidades para cuantificar dicho uso esperado.

El segundo elemento (2) se refiere al enfoque al cliente mediante el establecimiento de objetivos cuantitativos asociados a la calidad del producto (representados con base a las fallas del producto). La satisfacción de dichos objetivos permite establecer un balance entre los costos del producto, así como la satisfacción de las necesidades del cliente.

¿Por qué usar la ICS?La ICS es independiente de la tecnología y de la plataforma de desa-rrollo. No requiere ningún cambio en arquitectura, diseño, o código, sino que puede sugerir los cambios que serían útiles. También, la ICS

Ingeniería de la Confiabilidad de Software Una Práctica de bajo costo para la administración de la calidad de productos de softwarePor Gerardo Padilla Zárate, Enrique Villa Diharce y Carlos Montes de Oca VázquezCentro de Investigación en Matemáticas A.C.

Gerardo Padilla Zárate es consultor en temas de Ingeniería de Software enfocados en la prueba de software, confiabilidad del software, calidad de la infor-mación, así como modelado y construcción de componentes de software. Actualmente es candidato a Doctor en Ciencias de la Computación por parte del Centro de Investigación en Matemáticas y forma parte del Grupo de Ingeniería de Software, así como del Grupo de Confiabilidad de Sistemas y Software

// PRÁCTICAS


está altamente orientada al cliente y está altamente correlacionada con los niveles 4 y 5 del Modelo Integrado de Madurez de las Capaci-dades (CMM-I) del Instituto de Ingeniería de Software. Su alta orien-tación al cliente se debe a la naturaleza de la información requerida en el proceso de la ICS, lo que implica tener un contacto frecuente y cercano con los clientes. Esta interacción mejora la satisfacción del cliente y reduce riesgos de manera similar a lo propuesto en los mé-todos ágiles de desarrollo.

La alta correlación con los niveles de madurez 4 y 5 de CMM-I se debe a que dicha práctica satisface varios objetivos relacionados con la medición para la optimización del proceso de desarrollo. La ICS es una buena opción para alcanzar dicho objetivo. Comparado con las ventajas, el costo de aplicar la ICS es bajo de acuerdo a la experiencia de John D. Musa[3]. Hay un costo de inversión de no más de 3 días equivalentes del personal por persona en una or-ganización, que incluye un entrenamiento de dos días para cada uno y la planeación con un número mucho más pequeño. Los gas-tos reflejados en el proyecto varían típicamente a partir 0.1 a 3.0 por ciento de costo total del proyecto[3]. Cabe mencionar que el componente más grande del costo es el asociado al desarrollo del perfil de operación.

El proceso de la ingeniería de confiabilidad de softwareEl proceso de la ICS puede verse como un conjunto de actividades adicionales y complementarias a las ya realizadas dentro de cualquier proceso de desarrollo. Seis actividades definen el marco de trabajo de la ICS que son mostradas en la Figura 1 y descritas a continuación.

1. Definir el Producto. Puede verse como un complemento del Análi-sis de Requerimientos y Diseño Arquitectónico. En esta actividad se define quiénes son los clientes, usuarios, proveedores y otros siste-mas relacionados.

2. Desarrollar el Perfil de Operación. Se define el conjunto completo de operaciones (i.e., tareas o funcionalidades lógicas principales del sistema) con su correspondiente probabilidad de ocurrencia o uso esperado. En esta etapa, la administración de los recursos toma un nivel cuantitativo basado en la importancia de cada operación del sistema. La Tabla 1 muestra un ejemplo par-cial de un perfil de operación para un producto para la navegación en el Web.

Figura 1. Proceso de la ICS[2]

Tabla 1. Ejemplo de un Perfil de Operación

3. Definir la Confiabilidad Adecuada. Se define lo que se considera como “falla” para el producto en desarrollo así como los medios para identificarla. Esta definición es crítica para el proceso y debe ser cons-tante durante todo el ciclo de vida. La Tabla 2 muestra un ejemplo de clases de severidades de fallas y ejemplos de cada tipo de falla.

Tabla 2. Clases de Severidades de Fallas

Enrique Villa Diharce es investigador en el Departamento de Estadística y miembro de los grupos de Estadística Industrial y Confiabilidad en Software y Sistemas del CIMAT. Además, es instructor de cursos de licenciatura, maestría y doctorado, así como de cursos de capacitación de alto nivel en la industria, donde ha brindado asesoría a empresas como PEMEX, IMP, CFE, Mabe, e IG entre otras. Enrique recibió el grado de Doctor en Ciencias con especialidad en Probabilidad y Estadística del CIMAT en 1999.

Operación

Acceso al Web

Búsquedas en la Web

Navegación en la Web

...

Total

Frecuencia (Probabilidad de uso)

0.12

0.30

0.40

...

1.00

Clase de Severidad

de Falla

1

2

3

4

Ejemplo

- No existe acceso al Web

- Acceso intermitente al Web

- No aparecen controles en

las paginas

- Encuadre incorrecto de

imágenes

Impacto en la Capacidad del

Sistema

- Interrupción básica del servicio

- Degradación básica del servicio

- Inconveniencia, la corrección

no se puede posponer

- Efectos menores tolerables

“El perfil de operación de un sistema, es la caracterización

cuantitativa del uso que se espera, de las funcionalidades principales del sistema. Por lo general, se usan

probabilidades para cuantificar dicho uso esperado”.


En la segunda parte de esta actividad se definen las medidas de re-ferencia con la que se cuantificarán las intensidades de falla, tales como el número de fallas por tiempo o número de fallas por unidad natural. Las unidades naturales representan la cantidad de proceso o trabajo realizado por el sistema (e.g., transacciones, páginas im-presas, llamadas a funciones, accesos, etcétera).

En la tercera parte de la actividad se fijan las Intensidades de Falla Obje-tivo (IFO) para cada sistema asociado al producto. Las IFOs representan la calidad del producto en desarrollo y son definidas por el cliente.

En la cuarta parte se seleccionan las mejores estrategias de apoyo a la confiabilidad de software que ayuden a alcanzar los IFOs respectivos al menor costo. Las estrategias de apoyo a la confiabilidad de software son aquellas actividades y mecanismos dentro del proceso de desa-rrollo que reducen las intensidades de falla y afectan positivamente los costos y el tiempo de desarrollo. Ejemplos de dichas estrategias incluyen mecanismos de tolerancia a fallos, inspecciones, revisiones, distintos tipos de pruebas, etc.

La ICS proporciona pautas y cierta información cuantitativa para la deter-minación de la mezcla de estrategias. Sin embargo, los proyectos pueden mejorarse usando la información que es particular a su ambiente y al do-minio propio del producto.

4. Preparar las Pruebas. Se definen los casos de prueba y los méto-dos de prueba a partir de la información de los perfiles operacionales y las estrategias de apoyo a la confiabilidad de software. Esta actividad puede integrarse con el proceso de pruebas del modelo de desarrollo que se tenga. Lo importante en esta etapa es la decisión de qué cosas se van a probar y qué datos se usaran en los casos de prueba.

5. Ejecutar las Pruebas. Se asignan los tiempos para las pruebas entre los sistemas, los tipos de prueba (i.e., características, carga y regresión) así como su ejecución.

6. Guiar las Pruebas. Se procesa la información obtenida en la ejecu-ción de las pruebas para varios propósitos. El primero es monitorear el crecimiento de la confiabilidad del sistema (o la reducción de las inten-sidades de falla) mientras se van reparando los defectos encontrados que generaron las fallas. Otro propósito es el de poder determinar si es necesario seguir probando; finalmente, el tercero es el de dirigir la fase del liberación del producto. La Figura 2 muestra una grafica típica usada para monitorear la reducción de las intensidades de falla.

Figura 2. Gráfica para controlar las actividades de Prueba[3].

Algo muy importante dentro del proceso de ICS es la recolección de datos de campo (i.e., información sobre el uso y las fallas encontradas en la operación real del sistema). El proceso de ICS no está comple-to cuando se libera el producto dado que la información que usamos puede ser imprecisa. El recolectar dicha información permitirá evaluar con mayor detalle la satisfacción del cliente y la calidad del producto.

En esta breve descripción del proceso de la ICS se han omitido de-talles relacionados con aspectos cuantitativos. Existen modelos estadísticos que permiten determinar el momento para detener las actividades de prueba basados en la información que se tiene de las fallas encontradas, objetivos de intensidades de falla y del número de casos de prueba ejecutados. Recomendamos al lector revisar [3, 4] para una mayor información.

ConclusiónPodemos decir que la efectividad que presenta la ICS reside en una idea ya mencionada por Tom de Marco: “No puedes controlar lo que no puedes medir.”. La bondad de la ICS reside en llevar dicha idea a elementos concretos con beneficios específicos:• La construcción del perfil de operación mejora el análisis de reque-rimientos dado que el proceso de cuantificar las probabilidades de uso de las operaciones del producto exige un proceso adicional de reflexión y trabajo con el cliente. • La definición de lo que se considera como “falla” para el producto involucra discutir con el cliente y usuarios los criterios de calidad del producto. Esta idea establece las bases para medir la calidad del pro-ducto reduciendo riesgos.• La determinación de qué estrategias de apoyo a la confiabilidad del software son usadas para la calidad deseada del producto provee de un medio cuantitativo para optimizar los recursos del proyecto. • El monitoreo cuantitativo de los resultados de las pruebas y del cre-cimiento de la confiabilidad permite administrar mejor el proyecto.

La ICS representa una práctica que puede ser usada con resulta-dos positivos. Las micro y pequeñas industrias pueden incorporar dicha práctica dentro de sus procesos no sólo para mejorar la ca-lidad de sus productos sino para sentar las bases que permitan definir el marco de medición de sus procesos en busca de niveles 4 y 5 de CMM-I.

/* ASEGURAMIENTO DE CALIDAD */

Carlos Montes de Oca Vázquez se desempeña como profesor e investigador en el Departamento de Ciencias de la Computación en el CIMAT, donde es coordinador del grupo de Ingeniería de Software y miembro del grupo de Confiabilidad en Software y Sistemas. Además, tiene una amplia y reconocida trayectoria en áreas relacionadas con el enfoque de procesos, modelos de calidad, vinculación y transición de tecnologías a la industria. Recibió el grado de Doctor en Ciencias Computacionales de la Louisiana State University en 1999.

Referencias1. Musa, J., Iannino, Okumoto; Software Reliability: Measurement, Pre-diction, Application, ISBN 0-07-044093-X, McGraw-Hill, 1987. 2. User Experiences with Software Reliability Engineering. Available at: http://members.aol.com/JohnDMusa/users.htm3. Musa, J., Software Reliability Engineering: More Reliable Software Faster and Cheaper, AuthorHouse, 2nd ed., 2004. 4. Lyu, M. (Editor), Handbook of Software Reliability Engineering, ISBN 0-07-039400-8, McGraw-Hill, 1996.

// PRÁCTICAS


E l software se encuentra en su infancia. Algunas áreas han tenido gran aten-

ción por varios años, como sus procesos de construcción –ampliamente discutidos en Software Guru–. Otras áreas han tenido una intensidad media en aumento, como es Ajax. Y también hemos visto un avan-ce de técnicas que pretenden sacarnos de los tiempos “oscuros” en que vivimos, por ejemplo cuando al acceder a una página bancaria o de reservaciones, ella misma declara terminada la interacción con un: “la página ha expirado”.

Por otro lado, otras áreas se encuentran fran-camente rezagadas, aún cuando son de im-portancia estratégica, como es la capacidad de instrumentación de una aplicación dentro de un ambiente distribuido. Para conocer más sobre esto, les recomiendo el docu-mento Understanding DSM and its Practical Application in 2006 to 2008[1]

Otra dimensión de la madurez del soft-ware, son los modelos de entrega emer-gentes; como los pagados por publicidad, donde las empresas que hacen el software obtienen sus ingresos en base a la publi-cidad que hacen a sus patrocinadores, en lugar de obtenerlo directamente de los usuarios, como un costo de licencia de uso de software.

Otro modelo emergente y de gran importan-cia, es el llamado SaaS (Software as a Ser-vice), que consiste en pagar por el software como un utility, o sea, conforme se va usan-do. Dicho modelo está cobrando auge por su simplicidad y operaciones mínimas. Incluye diversos modelos como procesos de negocio (CRM), transacciones comerciales (eBay) o ambientes colaborativos (MySpace). IDC es-

tima que este mercado será de 10.7 billones de dólares para el 2009, y que 49% de nue-vas empresas de tecnología, piensan utilizar dicho mecanismo. Recientemente se realizó el SaaSCon[2] donde varios proveedores mostraron sus estrategias, e incluso los chinos anunciaron su primera “Incubadora SaaS” en el parque de software Suzhou.

Diseño de aplicaciones SaaSEntre los retos claves para construir soft-ware de acuerdo a este modelo, tenemos los siguientes:•Seguridad. Existencia de datos privados por cliente, seguridad por rol, evitar spoofing.•Interfaz de usuario. Manteniendo la nave-gación congruente entre módulos.•Arquitectura específica. Operaciones de mantenimiento en batch nocturno, SOA.•Alta personalización. Para ser ajustada por fabricantes de software empaquetado y clientes finales, realizada de preferencia con metadatos.•Licenciamiento. La plataforma debe permi-tir a los usuarios finales, tener periodos de gracia, 60 días o similar, sin costo alguno, o en producción sin costos de arranque.

Estos parecen ser criterios muy parecidos a los que nos encontramos a fines de los noventas durante el boom de Internet. En ese entonces no entendíamos la profundi-dad, la plataforma tecnológica y modelos de negocio que serían habilitados por este tipo de entrega, pero ahora las cosas son un poco más claras.

Un nuevo campo de batallaComo era de esperarse, cada proveedor no sólo de plataforma, sino de servicios vía Internet, asegura ser el líder para entregar SaaS. Algunos que me vienen a la mente son

Oracle (Peoplesoft), SAP, y Progress. Dado que SaaS también se considera una versión de Business Process Outsourcing (BPO), sin la necesidad de administración del aplicati-vo, entonces seguramente pronto veremos entrar a este mercado jugadores que provie-nen del mundo de la consultoría.

Microsoft recientemente liberó una solución prototipo para SaaS[3], junto con recomen-daciones de arquitectura que vale la pena explorar por ser algo muy concreto.

Desde hace algunos años, Francisco de Ur-quijo, del CINVESTAV, anticipó en diversas pláticas, que SaaS es primariamente un ries-go para la industria completa de software, ya que muy pocos proveedores pueden atender al mercado mundial de pymes sin necesidad de un gran ecosistema. Esta es una posibili-dad estremecedora pero posible.

Nada está firmemente escrito. Estemos abiertos y preparados para separar los mi-tos de las realidades. Parece ser que el mo-mento oportuno de montar esta oleada, por fin ha llegado.

Referencias y mayor información

1.microsoft.com/windowsserversys-tem/dsi/smds_wp.mspx2. www.saascon.com3. www.microsft.com/saas4.www.saascon.com/live/48/events/48SFO06A/conference/CC973712

—Luis Daniel Soto

Software como Servicio Un Nuevo Inicio

Luis Daniel Soto es Director de Evangelización en nuevas tecnologías en Microsoft México. Entre sus funciones actuales están la administración de la relación con el Gobierno Mexicano para el desarrollo de la industria de software (ProSoft). Es jurado del “Gran Orden del Honor al Mérito Autoral” en software del INDAUTOR/SEP y fundador de diversas asociaciones de TI. Ganó el primer lugar en el concurso nacional para software de exportación en 1989. blogs.msdn.com/luisdans.

// COLUMNA/* TENDENCIAS EN SW */

Los ComponentesTodos son ReempLazabLes, poCos ReuTiLizabLesPor Sergio Orozco

La mayoría soñamos con desarrollar nuestros propios componentes reuti-

lizables, y desarrollar aplicaciones cada vez más eficientes, en menos tiempo. Pocos lo logran, pero la gran mayoría se queda muy lejos de tan grandiosa meta.Por fortuna, hay empresas que se han en-focado en realizar dicho trabajo por no-sotros; y contamos con gran cantidad de librerías de código y componentes que po-demos aprovechar para no partir de cero en nuestros proyectos. Gracias a esto, el desarrollo de aplicaciones se vuelve cada día más eficaz; sobre todo para quienes saben buscar y aprovechar dichos compo-nentes, así como las librerías que existen en el mercado.

Los más sofisticados emplean cada nue-va versión que surge de los mencionados componentes; sacándole todo el jugo en beneficio de un desarrollo más sobresa-liente y de calidad. Hoy en día, el desarro-llador más inteligente no necesariamente es el que conoce a la perfección un lengua-je de programación, sino el que es capaz de producir una mejor aplicación, y con más calidad. Esto no implica únicamente un conocimiento a fondo del lenguaje de programación, sino de las librerías que puede reutilizar para reducir al máximo la cantidad de nuevo código a escribir. El de-sarrollador moderno, requiere contar con la habilidad de estructurar adecuadamen-te las aplicaciones, mediante la integración de componentes propios y de terceros.

El componente según UMLPero, a todo esto, ¿qué es un componen-te? De acuerdo a la especificación de UML, un componente: “es una parte modular de un sistema que encapsula su contenido

y que es reemplazable en su entorno. Un componente define su comportamiento en términos de sus interfases, proporcionadas y requeridas...” El icono de UML para un componente, es un rectángulo con dos “pa-titas”. Este icono fue pensado para dar la idea de una clavija, o algo “conectable”.

Figura 1. Representación visual de un componente

A menos que se trate de un sistema pe-queño y aislado –de esos que cada vez hay menos–, seguramente tendrás que representar tu sistema con dos o más com-ponentes, por lo que el diagrama de com-ponentes se vuelve un artefacto necesario para modelar tus sistemas.

Las nuevas tecnologías y la mayoría de las arquitecturas modernas, requieren del uso de componentes para estructurar y distri-buir la aplicación. Necesitamos decidir en dónde ubicaremos los servicios de usuario, de negocio de datos o cualquier otro tipo de servicio específico; y sin el concepto de com-ponentes esto resultaría imposible.

Componentes y objetosCuando hablamos de componentes, esta-mos llevando el concepto de objetos a un nivel más alto. La orientación a objetos puede hacer maravillas por nuestros desa-

rrollos, una vez que aprendemos a explotar al máximo este paradigma. Pero, el reuso, mantenibilidad y flexibilidad de nuestros sistemas a un mayor nivel, lo conseguire-mos en el momento en que aprendamos a definir adecuadamente los componentes de nuestros sistemas. Ya sea que nosotros los construyamos o que reutilicemos com-ponentes ya existentes.

Reemplazable = menor costoLa definición de la especificación de la OMG nos habla acerca de que un componente es reemplazable. Vale la pena detenerse un momento a analizarlo.

De acuerdo a algunos estudios –y no es necesario ser genio para darse cuenta–, un costo importante de los sistemas viene a la hora del mantenimiento. El sistema empieza a crecer y, el costo por cada línea de código adicional va siendo cada vez más alto. Crear un software nuevo es más económico que mantener un software existente. Ya sea para corregirlo, modificarlo o para agregarle nue-va funcionalidad.

Aquí es donde entra el concepto de “re-emplazabilidad” de los componentes. Si diseñamos adecuadamente nuestro sis-tema, por medio de componentes que encapsulan de forma modular el compor-tamiento de nuestro sistema, y las reglas de negocio, entonces podremos modificar el sistema cuando cambien esas reglas de negocio a un costo mucho menor. Esto siempre y cuando seamos capaces de identificar el componente donde tienen que realizarse dichos cambios. Si logra-mos respetar las interfases de dicho com-ponente, a pesar de los cambios internos requeridos en el componente, tendremos


Sergio Orozco es director general e instructor senior certificado por la OMG en Milestone Consulting (UML Value Added Training Center), empresa especializada en capacitación práctica y consultoría en UML, CMMI y orientación a objetos. Milestone Consulting es la primer empresa mexicana miembro de la OMG. [email protected] www.milestone.com.mx

// UML

un mantenimiento sumamente eficiente de la aplicación, y muy transparente, en muchos casos, para la mayoría de los in-volucrados en el desarrollo.

Las interfases Pero, ¿qué es esto de las interfases? La interfase representa la declaración de un conjunto de funciones y obligaciones que alguien más lleva a cabo. En el diagrama de componentes la interfase representa

aquello que un componente es capaz de hacer por alguien más (interfase propor-cionada) o aquellos servicios que posi-blemente requiera utilizar un componente y que son proporcionados por otro com-ponente (interfase requerida). Podemos representar la interfase como una clase estereotipada, o iconográficamente como un círculo ligado al componente (a este icono se le acostumbra llamar "lollipop", por su parecido a una paleta).

Figura 2. El componente Ventas expone sus servi-

cios a través de la interfase IVenta y requiere de una

interfase IDetalleCliente

Un componente proporciona funciona-lidad específica dentro del sistema. Por ejemplo, podríamos tener un componen-te que se encarga de aplicar las reglas de negocio para realizar una venta (calcular total, calcular IVA, agregar un producto a la venta, cancelar la venta, etcétera). Esa funcionalidad, cuando usamos un lengua-je orientado a objetos, está implementa-da en un conjunto de clases agrupadas dentro del componente.

No todas las operaciones de las clases agru-padas en el componente, son “visibles” o “utilizables” por otros componentes. Sólo aquellas que decidamos exponer. Esas fun-ciones se exponen precisamente, a través de las interfases. Es por eso que decimos que la interfase contiene un conjunto de declaraciones de operaciones públicas: las que expone el componente.

Figura 3. La interfase de un componente se puede

ver como círculo o como una clase estereotipada

con una relación de realización desde el componen-

te que la expone

Cuando queremos indicar en un solo diagrama, que la interfase expuesta por un componente es la misma requerida por otro componente, pode-mos mostrarlo por medio de un ensamble.

Figura 4. El componente Orden requiere utilizar la

Interfase CodigoUnidad que expone el componente

Producto y la Interfase DetalleCliente que expone el

componente Cliente

Al igual que otros artefactos que hemos mos-trado, se ha hecho de forma simplificada y para las situaciones más comunes, de la misma for-ma en esta ocasión se explica el concepto de componente e interfase para la situación más común en que se utiliza. Pues, nuestra inten-ción, en varios de estos artículos, consiste en ayudar a la persona que comienza a trabajar con estos artefactos y no nos gustaría confun-dirlo con demasiados conceptos.

Para quien conoce ya el tema, recomenda-mos usar referencias más completas, como sería la especificación de UML en la OMG o participar en un curso especializado en UML, o esperar artículos futuros donde ahondemos en el tema.


“El desarrollador moderno, requiere contar con la habilidad de estructurar

adecuadamente las aplicaciones, mediante la integración de

componentes propios y de terceros”.

Las interfasesAlgunos de los beneficios de trabajar partiendo de un modelo de componen-tes para construir nuestro sistema:1. Mayor productividad, si logra-mos identificar componentes ya existentes que podamos reutilizar o si construimos componentes que podamos reutilizar en el futuro.2. Reducción del tiempo de entre-ga, ya sea porque reutilizamos com-ponentes o porque partimos de un plan donde podemos paralelizar ma-yor cantidad de trabajo. Varias per-sonas pueden trabajar en diferentes componentes al mismo tiempo.3. Mayor calidad, pues un compo-nente es más fácil de programar y probar que una aplicación comple-ta. Si los componentes están bien planeados para formar la aplicación completa, la calidad de los compo-nentes se verá reflejada en la aplica-ción final. Además, si un componente fue creado y utilizado anteriormente, significa que ya fue probado en situa-ciones reales, por lo que es muy pro-bable que ha madurado.4. Menores costos, tanto por el reu-so, como por la facilidad para darle mantenimiento a la aplicación, me-diante el mantenimiento a componen-tes específicos donde se identifican los cambios a realizar.

En anteriores columnas, hemos planteado la necesidad que tie-nen las pequeñas y medianas empresas, de adoptar metodolo-

gías de desarrollo de software para lograr productos de calidad. En estas columnas hemos comentado también, sobre las dificultades que enfrentan las empresas para poder implantar de manera efec-tiva, estas metodologías, ya sea por el factor económico o por los recursos humanos, o de tiempo, que la correcta implantación de la metodología representa. Uno de los rubros en los que los se hace evi-dente esta dificultad, es el área de pruebas de software. De hecho, sé por experiencia que, en la mayoría de las pequeñas empresas, las pruebas se limitan a comprobar la correcta compilación del código y el mínimo de funcionalidad, generalmente en un esquema de code and fix, en donde el código se corrige conforme los errores aparecen, de manera más o menos incierta. En particular, las pruebas son en-tendidas dentro del marco de pruebas de ejecución de código, per-diendo las ventajas de pruebas de no ejecución, sobre los distintos entregables en las etapas del ciclo de desarrollo de software. Se rea-lizan pruebas sobre módulos del sistema, y pruebas sobre el sistema final, orientadas a la detección de errores de ejecución. Sin embargo, las pruebas son una parte importante de todas las metodologías de calidad de software, y los desarrolladores, deberían invertir un míni-mo de esfuerzo en realizarlas durante todo el ciclo de vida de desa-rrollo. De nuevo, esto implica la disciplina para implantar un modelo de ingeniería de software y, adoptar su metodología.

En mi opinión, aún con un modelo reducido de calidad de software, es po-sible introducir un flujo de trabajo de pruebas que sea efectivo y eficiente. Para ello, el desarrollador debería considerar los siguientes puntos:

1. Las pruebas deben estar basadas en la especificación de requerimientos. Todos los modelos de calidad de software coinciden, de uno u otro modo, en que la correcta especificación de requerimientos, es de impor-tancia para que el proceso de desarrollo sea lo más fluido y eficiente po-sible. El levantamiento y especificación de requerimientos, es una tarea complicada a la que en ocasiones no se presta la debida atención. Sin embargo, es posible obtener un buen levantamiento de requerimientos, usando por ejemplo, metodologías ágiles o prototipos. El prototipo o documento de requerimiento inicial, es el primer entregable sobre el que se pueden realizar pruebas. Un prototipo puede servir para reali-zar la validación del sistema, antes del desarrollo del mismo, evitando costosos errores posteriores por la falta de comprensión de los reque-rimientos. Así mismo, una revisión del documento de requerimientos, realizada en conjunto por el líder de proyecto y el usuario o dueño del sistema, permite detectar fallas u omisiones en la descripción del siste-ma a desarrollar. Una revisión de requerimientos, junto con la presenta-ción de uno o dos prototipos, puede realizarse en un par de semanas, y ahorrar tiempo en el desarrollo posterior del proyecto.

2. Las pruebas deben realizarse por un equipo diferente al equipo de programación. Esto, por supuesto, es lo que indican la mayoría de metodologías de calidad, en el entendido de que es muy difícil que un desarrollador per-ciba sus propios errores. Después de todo, muchos desarrolladores co-nocen la experiencia de estar por horas buscando la causa de un error, para que este sea señalado sin dificultad por el compañero de equipo que llega en ese momento. Es claro que la realización de pruebas por equipos distintos, puede ser imposible en empresas pequeñas. En este caso, se puede recurrir a la “revisión por pares” (peer revision) en la que el código es revisado por un segundo programador. Los desarrolladores pueden intercambiar los roles de programador y revisor, a ratos desa-rrollando su propio código, a ratos revisando el código de un colega, logrando de este modo mayor eficiencia en ambas tareas.

3. Es posible realizar pruebas estáticas tan pronto existen entregables del proyecto. Es muy importante, romper lo más pronto posible el paradigma de que sólo el código puede probarse. Los diagramas de flujos de da-tos, diagramas de procesos, diagramas de clases, o cualquier otra herramienta de análisis, puede ser probada, ya sea contra las espe-cificaciones o para verificar su funcionalidad específica. Estas prue-bas no toman más de una hora, y pueden ser parte de las tareas a realizar en las juntas del equipo de desarrollo. Del mismo modo, pueden realizarse con bastante antelación, pruebas de usabilidad sobre prototipos e interfaces. Estas pruebas permiten conocer qué tan fácil será que el usuario final adopte, y utilice el sistema; y tam-bién pueden detectar flujos de datos faltantes en la especificación.

4. Es posible generar una batería mínima de casos de prueba. La correcta selección de casos de prueba, es un tema de importancia en toda la bibliografía sobre verificación y validación de software. Las pruebas estáticas realizadas sobre documentos de análisis, au-nadas a una sólida especificación de requerimientos (utilizando, por ejemplo, casos de usos) permiten la identificación de un conjunto de casos de prueba básicos. Usando metodologías sencillas de pruebas de software, como el método de particiones equivalentes, es posi-ble obtener los casos de prueba adicionales para verificar la correcta funcionalidad de un producto software. Estos casos de prueba se convierten así, en parte de la documentación del sistema.

Quizá estos cuatro puntos son una versión muy reducida de una meto-dología de pruebas formales. Pero representan una gran diferencia con respecto a un enfoque code and fix, para proyectos medianos de soft-ware, y pueden ser el fundamento para la implantación de estándares de prueba más sólidos. Invito a los lectores a comprobarlo.

—Raúl Trejo


La Integración de las PruebasEn los Modelos de Calidad

/* CÁTEDRA Y MÁS */// COLUMNA

El Dr. Raúl A. Trejo es profesor investigador del Departamento de Sistemas de Información en el Tecnológico de Monterrey, Campus Estado de México. Sus áreas de especialidad incluyen Ingeniería de Software, Representación del Conocimiento y Algoritmos Computa-cionales. El Dr. Trejo ha presentado ponencias en diferentes foros nacionales e internacionales. Es miembro fundador de la Asociación de Sistemas de Información de América Latina y el Caribe y coordinador del Centro de Innovación Microsoft en Tecnología de 64 bits.


Hasta hace pocos años, usar software libre en México era algo pare-cido a ser un radical comunista. Hoy, afortunadamente esto ha cam-

biado. Cada vez más y más organizaciones utilizan software libre (SL) para obtener ventajas competitivas. No me refiero a empresas cuyo negocio central es desarrollar software, ya que éstas, entendieron las ventajas del SL hace tiempo. Me refiero a las organizaciones que tienen áreas internas de TI, y que poco a poco empiezan a darse cuenta de que el principal valor del SL, no está en la reducción de costos, sino en qué las habilita a ser más ágiles, y concentrarse en el valor de la tecnología para el negocio. Estas empresas han logrado establecer un uso pragmático del software libre.

En todas aquellas organizaciones que han hecho un uso eficaz del SL, existen algunos principios comunes que les han permitido desa-rrollar una estrategia de software libre pragmática, me permito aquí plasmar algunos de estos principios que he observado en campo, con la intención de iniciar una conversación sobre las propias expe-riencias de ustedes lectores, en estos temas.

Iniciar con una visión realistaLa mejor manera de garantizar el éxito del SL en una organización, es plantear expectativas realistas desde un inicio. Los modelos de adqui-sición, financiamiento y soporte en SL son muy diferentes al software propietario. Es indispensable que la organización entienda, que al usar software libre está tomando el compromiso de utilizar el ahorro en el costo de licencias, para poder financiar la flexibilidad e independencia, que estas soluciones proveerán al largo plazo. El trabajo adicional que representa que la organización misma, sea su propia “primera línea de soporte”, debe de ser contemplado desde un inicio.

Foco en el valor de negocioUn error común es ubicar el ahorro de costos en licencias, como el único valor de negocio para el software libre. Por ejemplo, a pesar de la gran cantidad de dinero en licencias que una organización podría lograr al cam-biar hacia Open Office, es muy poco probable que el saldo en términos de valor para el negocio sea positivo, después de considerar el pánico orga-nizacional y los costos de entrenamiento y migración. Un ejemplo de una organización que entiende cómo generar valor de negocio, a través del software libre, es el de una pequeña institución financiera que, para poder hacer frente a competidores mas grandes, necesita poder abrir sucursales rápidamente, sin un costo creciente en infraestructura de TI, y que por ello decide migrar su software de operaciones hacia SL.

Garantizar éxitos iniciales Como todo proceso de cambio organizacional, es indispensable usar una estrategia por fases para introducir el software libre. Una vez identificado un valor concreto para el negocio, se debe lograr que

éste valor sea realmente entregado a la organización, para que se pueda medir el beneficio y entonces se apoyen proyectos más gran-des. Algunas veces, el mayor beneficio de SL no será el mas fácil de implementar en una primera fase, como por ejemplo, en el caso de migrar de una base de datos propietaria hacia uno abierta. En los casos de infraestructura, es más recomendable comenzar con ser-vidores web, o de correo electrónico, que son menos complicados y con menos dependencias hacia el resto de la infraestructura.

Desarrollar capacidades internasComo ya mencioné, los ahorros generados en costos de licen-cias, pueden utilizarse para el propósito de desarrollar capacida-des internas, sobre todo en los primeros proyectos de adopción de SL. Una buena estrategia es buscar ayuda del fabricante del software, para talleres en sitio adaptados a las necesidades es-pecificas del proyecto. Esta es una forma de entrenamiento, que resulta mucho más efectiva que enviar al personal a cursos ex-ternos genéricos. Otra buena manera de empezar, es invertir en obtener capacitación en línea, que normalmente tiene un costo mucho menor que la capacitación presencial, y puede ser un buen complemento al apoyo de un consultor especializado que ayude a iniciar los proyectos.

Integrarse en las comunidadesPor último, no hay que menospreciar la importancia de pertenecer a los grupos de usuarios o comunidades de usuarios. El intercambio de conocimientos que se da en estos círculos es un valor agregado muy importante. El poder obtener experiencias prácticas de otros miembros que se encuentran en el mismo proceso de adopción, re-sulta a veces mucho más valioso que el soporte de los fabricantes. Así mismo, participar activamente en las comunidades, le permite a las organizaciones validar a muy bajo costo las propuestas de solu-ción que desarrollen internamente, o que sean implementadas por consultores externos. En México, desafortunadamente aún no tene-mos muy desarrollada la cultura de comunidad, pero la Comunidad Java México, es un buen ejemplo de un esfuerzo de esta naturaleza.

Concluyendo, un uso pragmático del software libre puede constituir una verdadera ventaja competitiva para la organización, si ésta com-prende que requiere un compromiso tecnológico, al menos del mis-mo nivel, que las soluciones propietarias; que la reducción de costos no es una verdadera ventaja competitiva sino que hay que trabajar en identificar y cuidar el verdadero valor de negocio a lo largo del ciclo de vida de la solución, eso es lo que más importa.

— Emilio Osorio

Software Libre Pragmático Ganando Ventaja Competitiva

/*TIERRA LIBRE*/// COLUMNA

Emilio Osorio colabora actualmente como Consultor Asociado para Sun Microsystems México. Ha trabajado en desarrollos basados en Java desde 1996 y actualmente se dedica a ayudar a equipos de desarrollo a aprovechar las ventajas del Software Libre y los métodos ágiles en sus organizaciones. Ferviente entusiasta de la aplicación social de la tecnología, a ultimas fechas esta involucrado con Organizaciones de la Sociedad Civil. Emilio estaré encantado de recibir sus comentarios y quejas en http://tecnonirvana.org/ y en [email protected]

El modelo IDEAL, se creó inicial-mente como un modelo de ciclo de vida, para la mejora de proce-sos basado en el SW-CMM, pero su aplicación se ha ampliado.

Está compuesto de cinco fases que permiten administrar y establecer las bases para una estrategia de mejora a largo plazo:1. Iniciar ----------------Initiating2. Diagnosticar---------Diagnosing3. Establecer------------Establishing4. Ejecutar---------------Acting5. Aprender-------------Learning

En este artículo veremos la fase de diagnos-ticar que contempla a las evaluaciones del programa de mejora, cuyo objetivo es carac-terizar el estado actual de la organización (identificando las oportunidades de mejora) y el estado futuro, tomando como base al-gún modelo de referencia.

Podemos decir que un diagnóstico es: “dime qué haces, cómo lo haces, y verificaré lo qué haces, cómo dices que lo haces”. Para rea-lizar un diagnóstico existen diferentes tipos de evaluaciones:

Externas (evaluations)Impuestas por un interesado externo (ejemplo: cliente, gobierno, contratista). El alcance es de-terminado por dicho interesado externo, y él, es el dueño de los resultados de la evaluación. Internas (assessments)Realizada por un equipo evaluador confor-mado por personas externas e internas, para satisfacer el interés propio de la empresa, que determina el alcance de la evaluación, y es due-ña de los resultados de ésta. Sirve para que la organización pueda medirse, y tome decisio-nes con respecto a su programa de mejora.

El SEI utiliza el término appraisal, como som-brilla para referirse tanto a las evaluaciones externas, como a las internas.

Ahora revisaremos las diferencias entre CBA-IPI (CMM-Based Appraisal for Internal Process Improvement) y SCAMPI (Standard CMMI Appraisal Method for Process Improvement). Esta comparación se basa en la versión 1.2 de CBA-IPI, y la versión 1.1 de SCAMPI. Vale la pena aclarar que en el presente artículo, siem-pre que nos referimos a SCAMPI, es acotado a la representación escalonada de CMMI.

•El método CBA-IPI es para el modelo SW-CMM y está alineado al CAF (CMM Appraisal Framework), mientras que el SCAMPI es para el modelo CMMI y está alineado al ARC (Appraisal Requeriments for CMMI ).

•CBA-IPI está diseñado para evaluaciones de tipo externo. SCAMPI en cambio, es un méto-do híbrido, el cual considera ambos tipos de evaluaciones, de tal forma que es útil para evaluaciones internas y/o de proveedores.

•SCAMPI tiene un alcance más amplio que el CBA-IPI al poder evaluar múltiples funcio-nes de la organización relacionadas con las disciplinas del modelo. Es decir, es un sólo método para evaluaciones de varias discipli-nas (software, sistemas, etcétera).

•SCAMPI, a diferencia del CBA-IPI incre-menta el foco en la revisión documental y reduce la interacción persona a persona de las entrevistas. El CBA-IPI se basaba en el modo de descubrimiento, o como colo-quialmente decimos: “culpable hasta que no demuestres lo contrario”. SCAMPI cam-bia este concepto, de descubrimiento a ve-rificación, es decir, “inocente hasta que no demuestres lo contrario”.

•SCAMPI se basa en la investigación enfo-cada, lo que implica que las entrevistas que se realizan deben estar determinadas por la evidencia recolectada a través de los docu-mentos y de las presentaciones proporcio-nadas por los proyectos.

•SCAMPI a diferencia del CBA-IPI, requiere la ejecución de al menos un readiness re-view, antes de iniciar las actividades de la fase conocida como “on-site”. Durante el readiness review el equipo evaluador debe generar las preguntas para las entrevis-tas, teniendo la claridad de qué prácticas están siendo utilizadas. El equipo deberá preguntar hasta quedar satisfecho de la información obtenida, para comprobar la implantación de la práctica, o bien, si la práctica se cubrió con la evidencia obtenida y no hay duda de su implantación. Es enton-ces cuando el equipo decidirá, no realizar preguntas sobre ésta durante las sesiones de entrevista. En cambio en el CBA-IPI se tenían una serie de preguntas predefinidas (que se ajustaban con el equipo evaluador) para cubrir todas las prácticas durante las entrevistas, ya que las afirmaciones obteni-das durante ésta, se consideraban como la fuente principal de información.

• En SCAMPI, cada proyecto que esté bajo la muestra de la evaluación debe generar sus PIIDs (Process Implementation Indicator Des-criptor) recopilando la evidencia para cada práctica (artefactos directos e indirectos). Esta diferencia con respecto al CBA-IPI es im-portante ya que cada proyecto es conocedor de su información y proporciona la documen-tación al equipo evaluador para su análisis.

•Con respecto al equipo evaluador, también hay diferencias, ya que en el CBA-IPI el mé-todo requería que en el equipo evaluador


SCAMPI y CBA-IPIDiferencias Entre Métodos de Evaluación Por M. en A. Mariana Pérez-Vargas Obregón

Mariana Pérez-Vargas es socia fundadora y Directora de General de AVANTARE. Cuenta con más de 12 años de experiencia en el área de calidad y mejora de procesos de software. Actualmente brinda consultoría y asesoría a diferentes organizaciones brindando los elementos para desarrollar un programa de mejora.Es Lead Assessor autorizada por el SEI para evaluaciones CBA-IPI y candidata a Lead Appraiser para realizar evaluaciones SCAMPI

// FUNDAMENTOS


se integrara al menos una persona de la or-ganización, y en SCAMPI esto no es necesa-rio. Adicionalmente, para cada miembro del equipo evaluador de SCAMPI, es requisito obligatorio haber tomado el curso oficial del SEI: Introduction to CMMI, en cambio, para el CBA-IPI, el curso de introducción al modelo podía ser el oficial, o bien, uno equivalente.

•En SCAMPI, para que una meta se considere satisfecha (satisfied), cada práctica debe ob-servarse en la mayoría de los proyectos, lo cual reduce la flexibilidad que existía en el CBA-IPI. Sin embargo, la organización puede optar por el enfoque continuo para elegir las prácticas y áreas a mejorar.

•Otra diferencia entre ambos métodos es el procedimiento para la calificación (rating) de las prácticas. En SCAMPI, se requiere para cada una de las prácticas (específicas y genéricas) evaluadas, un documento que sustente la misma a tra-vés de un artefacto directo (sustentado por uno indirecto y/o una afirmación), y una cobertura del 50% de afirmaciones, o bien, un renglón-una columna para las entrevistas (face to face), mientras que el CBA-IPI requeriría entrevistas para todas las prácticas, la documentación consti-tuía una segunda fuente de verificación: los documentos, y no existía el concepto de artefacto directo e indirecto.

•En SCAMPI, las prácticas evaluadas para cada área de proceso se califican de acuerdo a su implantación, como fully, largely, par-tially o not implemented. En cambio, para en el CBA-IPI sólo se calificaban como imple-mented o not implemented.

Para finalizar, hablando técnicamente, SCAMPI es un método de evaluación más riguroso y robusto que el CBA-IPI. Existen muchos mitos sobre su uso, pero en la actualidad se está utilizando de manera amplia en todo el mundo (incluyendo a organizaciones pequeñas), y está prepa-rado para realizar evaluaciones con mo-delos diferentes al CMMI.

“SCAMPI es un método de evaluación más riguroso y robusto

que el CBA-IPI”.

El primer estándar 802.11b fue creado en 1998 con una transmisión de datos de 11 Mbps similar a la red Ethernet, la cual con-taba con 10 Mbps de transmisión. Poste-riormente, en 1999, surgió el 802.11a con una frecuencia portadora de entre 5.1 y 5.8 GHz. a 54 Mbps que solamente se ma-nejó con amplitud dentro de los Estados Unidos. Más adelante, existirían desde los estándares 802.11d hasta 802.11f tan-to para dominios reguladores como para Protocolos de Puntos de Acceso (IAPP, por sus siglas en inglés).

Estándares InalámbricosExisten tres tipos de estándares WLAN que compiten en el mercado de las redes y te-lecomunicaciones y que, frecuentemente, han sido confundidos por el usuario final al momento de seleccionar un producto que contenga estos protocolos, y bien vale la pena mencionarlos:

1. HomeRF - Estándar para uso doméstico desarrollado por un grupo de compañías, en-tre ellas, Siemens y Motorola principalmente que, dejó de existir en enero de 2003 con la creación del protocolo 802.11b. Utilizaba la banda de frecuencia 2.4 Ghz cuyo rendi-miento de procesamiento de voz y datos (10

Mbps) a comparación de las redes Wi-Fi (11 Mbps) era más lento.

2. Bluetooth – Fue el Grupo de Interés de Bluetooth (BIG por sus siglas en inglés), con-formado por empresas como Aguere, Ericc-son, IBM, Intel, Microsoft, Motorota, Nokia y Toshiba creado en 1999; los que impulsaron este estándar para su integración en PDA s, cámaras digitales, impresoras portátiles y teléfonos celulares utilizando la Red de Area Personal (PAN por sus siglas en inglés) por su corta distancia de hasta 10 metros cuyo nombre técnico es el 802.15.1 dentro de los estándares regulados por la IEEE.

3. 802.11 – Para los hogares, estableci-mientos en la vía pública y empresas que utilizan protocolo SMB y sonda espacial satelital SOHO.

Es importante mencionar que, solamente el estándar 802.11 soporta la banda ancha, debido a su buen desempeño en la transmi-sión de datos a 54 Mbps en los equipos que incluyen los estándares 11g y 11a, además de un mayor rango y velocidad de adaptación en el mercado. Actualmente, existe el están-dar 802.11n que, además de manejar datos e imágenes; también utiliza en tiempo real

audio y vídeo con tecnología MIMO (Multi-ple Input Multiple Output, por sus siglas en inglés) utilizando varias ondas de radio para transmitir varios paquetes de datos por di-versos canales.

Empresas establecidas en México como Cisco System, Linksys, 3Com y 2Wire, entre otras; que manejan productos para redes alámbricas e inalámbricas; ya están traba-jando con el estándar 802.11n pero, cabe mencionar, que en el mercado aún se ma-neja y vende el protocolo 11g, debido a que el primero todavía tiene un costo elevado para el usuario final.

La tecnología Wi-Fi, cuyo nombre surge de un grupo de comercio industrial llamado Wi-Fi Alliance; cubre a todos aquellos pro-ductos que están basados en los estánda-res 802.11 del IEEE. Lo nombraron así, con el objetivo de facilitar la recordación.

Desde su creación, las velocidades que se manejan han sido variadas. Sin embargo, por regla general, se ha establecido la ve-locidad de 11 Mbps en distintos estándares, pero en el caso del protocolo 11b, se mane-jan velocidades de 1, 2, 5.5 y 11 Mbps con una amplitud de radio frecuencia inicial de


En 1991 surgió el primer estándar inalámbrico con el No. 802.11, que regularía las redes de área local inalámbricas (WLAN, por sus siglas en inglés). Gracias al interés de varias empresas de telecomunicaciones que crearon el Proyecto de Autorización Requerida (PAR), propiciado por el Instituto de Ingenieros Eléctricos y Electrónicos (IEEE) con el objeto de transmitir datos en secuencia directa y saltos o espectros de frecuencia con un ancho de banda estándar de 2.4 GHz incluyendo rayos infrarrojos que, finalmente, desaparecería en los últimos estándares

Redes InalámbricasEl acceso a una tecnología moderna Por LSCA Pedro Torres-Ruiz

Pedro Torres-Ruíz, Licenciado en Sistemas de Computación Administrativa, es líder de proyecto, en proyectos de Sistemas y Sitios Web para usuarios finales y empresas, desde 2001. Así como consultor de sistemas e Internet también a usuarios finales y empresas. Es miembro de la comunidad española Freelance.com y de la comunidad Web-masters México. Además, ofrece conferencias en temas de informática e ingeniería de sistemas, en congresos nacionales e internacionales [email protected]

// INFRAESTRUCTURA


2.4 GHZ, manejando distintos canales de entre 11 y 14 dependiendo del proveedor de tarjetas inalámbricas, ya sea para equi-pos de cómputo, estaciones de trabajo y/o puentes musicales que están incluidos en el último protocolo.

Es importante señalar que las redes pri-vadas virtuales (VPN por sus siglas en in-glés) son un alternativa segura para los estándares Wi-Fi, particularmente en la capa física del modelo OSI (Open System Interconection) al momento de conectar-se a Internet, integrando simultáneamen-te para su mayor seguridad con el manejo de cifrado de información WEP que, puede ser estático o dinámico y con una mayor interoperatividad. Sin embargo, dentro de ésta, tanto en software como en hard-ware, hay limitación en su desempeño de trabajo, por no permitir mayor cobertura de área. En relación al manejo de voz y datos, el último estándar publicado ya maneja protocolos Ipx y AppleTalk que los anteriores no contenían.

ConclusionesHoy en día, las tecnologías WLAN son la innovación para las aplicaciones vía re-mota inalámbrica pero, es importante tomar en cuenta la selección de equipos y componentes de cómputo hasta el di-seño e implementación del mismo, antes de instalar una red inalámbrica segura, eficaz y eficiente que, sin lugar a dudas, tendrá ataques cibernéticos en cualquier

momento, pero elementos como firewall, antivirus y la actualización constante del sistema operativo que se tenga, la harán más segura y confiable en su utilización. Esto se menciona, con el propósito de se-ñalar que no solamente las redes alámbri-cas son inseguras, sino que también las inalámbricas, debido a que se tiene una conexión directa y constante con el Inter-net exento de seguridad.

Finalmente, la tendencia de las redes inalámbricas con el protocolo 802.11N es entrar al mundo interactivo de multime-dia, con mayor capacidad de manejo de grandes volúmenes de información, a tra-vés de señales satelitales que, serán ob-jeto de estudio para una mayor calidad, eficacia, eficiencia y seguridad mediante dispositivos de red inalámbrica.

Bibliografía1. Neil Reid y Ron Seide. Manual de Redes Inalámbricas 802.11 (Wi-Fi). McGraw Hill Interamericana Editores, S. A.México, 2003.

2. Institute of Electrical and Electronics Engineers www.ieee.org

“El estándar 802.11 soporta la banda ancha, debido a su buen desempeño en la transmisión de datos a 54 Mbps en los equipos que incluyen

los estándares 11g y 11a”.


Sony Ericsson

MBW-100Al más puro estilo agente 007, aparece en el mercado un reloj Bluetooth, diseñado en conjunto con Fossil, líder en la industria re-lojera. El MBW-100 ofrece una nueva manera de usar el teléfono celular, sin siquiera tener que sacarlo del bolsillo. Su pantalla OLED, ubicada en la parte baja de la carátula cuenta con identificador de llamadas, y con un botón es posible rechazarlas o aceptarlas. Además brinda control sobre música y los mensajes de texto. Es un reloj análogo en acero inoxi-dable, carátula color plata; hipoalergénico, cristal mineral antirayaduras y resiste al agua hasta por 30 metros.

/* GADGETS */// TECNOLOGÍA

Western Digital

Dual-option Media CenterCon capacidad desde 120GB hasta 320GB, es el único pe-riférico de almacenamiento que incorporan un disco duro externo, un lector de tarjetas de memoria 8 en 1, hub USB 2.0 y sistema de respaldo. Cuenta con un sistema dual que da la posibilidad de respaldar los datos automática-mente o a tu solicitud con solo oprimir un botón. Además abarca varias unidades de disco, es una herramientas muy útil para respaldo de documentos e imagines impor-tantes, descarga de fotos y video de tarjetas de medios y almacenamiento adicional para la computadora. Es comptatible con PC y Mac.

ITTUSB

USB TurntableLos fanáticos de los acetatos que continúan guardando su colección como un tesoro, seguro disfrutarán de esta tor-namesa, que se conecta directamente a la computadora a través de un puerto USB, para traer de regreso la música que pensaste jamás volver a escuchar en su formato origi-nal. Acepta discos de 33 y 45 revoluciones. Dale plug & play al viejo baúl de los recuerdos .

SafeNet y BlackBerry

Smart Card 330 - Smart Card ReaderSe trata de una combinación que agrega una capa adicional de seguridad para los usuarios de BlackBerry, sobre todo para las organizaciones que deben cumplir con los requisitos más altos de conformidad de seguridad. Dicha mancuerna, permitirá la autentificación de usuarios, evitando así el robo de identidad e información. Hoy en día las organizaciones reconocen su necesidad por una seguridad más robusta en computadoras portá-tiles, de escritorio y otros dispositivos inalamábricos, incluidos entre ellos, BlackBerry, que es de los más utilizados hoy en día.

Robosapien V2Es una fusión altamente desarrollada de robótica, tecnología

y personalidad, combinando movimiento fluido biomecánico con mul-ti sensores y personalidad humanoide interactiva. Está diseñado por Mark Tilder (el padre del original Robosapien). Se trata en realidad de la segunda generación corregida y aumentada que ahora tiene compor-

tamiento propio. Dentro de sus características destacan: agilidad, actitud, multi niveles de interacción con el medio ambiente, con humanos y objetos (vista, sonido, sensores de movimiento), movimientos corporales de humanoide, que incluyen agachar-

se, sentarse, levantarse, recostarse, saludar... es más, sabe hasta artes marciales. Además responde al sonido y al color.

// TECNOLOGÍA

INDEX

Anunciante Páginas Sitio

AMCIS 55 www.amcis.org.mxAvantare 11 www.avantare.comEidon Software 09 www.eidonsoftware.come-Quallity 07 www.e-quallity.netGrupo STI 21 www.gsti.com.mxImexsoft 51 www.imexsoft.com.mxIngressio 53 www.ingressio.comLinuxWorld 49 www.linuxworldexpo.com.mxMicrosoft F2-01 www.microsoft.com/mexicoMilestone Consulting F4 www.milestone.com.mxRoca Sistemas 13 www.rocasistemas.com.mxSafeNet 39 www.safenet-inc.comSelect / Tendencias F3 www.select.com.mx

TENEMOS UN ESPACIO RESERVADO PARA TISi deseas anunciarte contáctanosen el (55) 5239 5502 o en [email protected]

DIRECTORIO

www.softwareguru.com.mx NOV-DIC 2006 55

Los diferentes métodos de diseño de programas a lo largo de la histo-ria, han enfatizado elementos que resultan ser aspectos esenciales

de la actividad, y son útiles sin importar el paso del tiempo. Hay elemen-tos de forma (como algunos diagramas) que ya no serán útiles, pero si te enfocas en eso, ya te fuiste por otro lado, perdiéndote el punto importan-te: mantén frescos los conceptos para que te asistan en cada decisión de diseño. Desde esta perspectiva, la opinión de que los métodos de genera-ciones pasadas ya son obsoletos y no vale la pena dominarlos, me parece –por decir lo menos– absurda. Igualmente absurdo me parece equiparar la actividad de diseño y programación, a simplemente conocer la sintaxis de algún lenguaje de programación, o las cualidades de una tecnología.

Métodos formales.- Describir y razonar matemáticamente tus pro-gramas por medio de lógica aplicada, es un complemento útil en el diseño de programas correctos; es probable que el rigor matemático requerido en métodos formales, no sea adecuado para todo el ciclo de desarrollo en los proyectos comunes, pero ha resultado muy va-lioso en la especificación del diseño en combinación con la técnica de diseño, conducido por aserciones[1], así como en la actividad de validación y verificación. Lo valioso del estilo de pensamiento invo-lucrado en estas técnicas, es la capacidad de identificar propiedades en los problemas y soluciones observados, diferenciando las esen-ciales de las accidentales.

La generación estructurada.- Un número considerable de conceptos y técnicas fueron apalancados en esta generación, iniciando con la programación estructurada, seguida del diseño y análisis estructu-rado –desde entonces, la vanguardia está donde están los detalles de la programación–. Edsger Wybe Dijkstra nos explicó separación de aspectos[2], un rasgo del pensamiento ordenado para la resolu-ción efectiva de problemas, donde el enfoque mental se expande y se contrae por demanda, para considerar en profundidad un asunto en particular, aislándolo del resto, conciliando múltiples líneas de pensamiento simultáneo. Niklaus Wirth nos explicó refinamiento gradual o escalonado[3], donde cada paso contiene la expresión esencial y completa de la solución en un cierto nivel de abstracción, la cual será cernida de los elementos menos concretos en la siguien-te refinación, eligiendo el siguiente nodo en el árbol de decisiones de diseño, por medio de una minuciosa deliberación.

La generación orientada a objetos.- la agrupación más general de métodos de diseño en esta generación son dos escuelas: el elabora-cionismo y el traduccionismo, está de más decir que dominar ambas es muy útil para el oficio de diseño y programación, pues nos deja en una mejor posición para elegir la técnica más adecuada para cada

tipo de problema. Una de las ganancias de explorar estas familias de métodos de diseño, es la habilidad de designar un mejor balan-ce entre los tres aspectos fundamentales de los objetos: identidad, estado y conducta; la carencia de dicha habilidad es muy común y se puede notar en la omisión del aspecto de identidad y conducta de los objetos, provocando que las vistas estáticas de los diseños sean únicamente representaciones entidad-relación. ¿Dónde es-tán los objetos ahí? La reflexión que viene de la práctica de diseño usando estos conceptos y otros —como encapsulado, herencia, po-limorfismo— enfatiza de una manera sutil que los límites entre los conceptos análisis, diseño y programación son difusos, y ya no se consideran etapas secuenciales sino que, simplemente son activi-dades que suceden concurrentemente durante el ciclo de vida del software. La opinión de varios maestros practicantes del oficio, es que la aportación más importante del paradigma es: la administra-ción de dependencias[4] como fundamento para el diseño evolutivo de software a gran escala.

La generación ágil.- Un siguiente paso a partir del estado de con-ciencia que te deja la práctica de los métodos de diseño de las ge-neraciones antes mencionadas, es intentar el diseño de programas correctos con un estilo más cooperativo, más orientado a las per-sonas que a la tecnología, más como desde hace muchos años lo describen autores como Gerald M. Weinberg[5]. El énfasis en la co-municación con el usuario y entre los otros miembros del grupo de desarrollo, así como la atención permanente al diseño del software y su continua evolución, me parecen de las aportaciones más valio-sas de los métodos ágiles, no porque presenten algo novedoso, sino porque presentan descripciones asequibles —a diferencia de meras prescripciones— para llevar a cabo las buenas prácticas.


Programas CorrectosParte 2. Las buenas ideas no caducanPor Marco Antonio Dorantes

Referencias1. Test Driven Developmentwww.objectmentor.com/writeUps/TestDrivenDevelopment2. On the role of scientific thought. Edsger Wybe Dijkstrawww.cs.utexas.edu/users/EWD/transcriptions/EWD04xx/EWD447.html3. Program Development by Stepwise Refinement. Nicklaus Wirthwww.acm.org/classics/dec95/4. Designing Object Oriented C++ Applications Using The Booch Method. Robert C. Martin

Marco A. Dorantes es un consultor en el diseño y formulación de software desde 1987, oficio que lo llevó a la investigación aplicada en el campo de los métodos sistemáticos para diseño de software. Ha realizado diversas contribuciones públicas en la comunidad mundial de programación, tanto en foros técnicos como en software, por ejemplo AutoTest for .Net y CppUnit for C++Builder disponibles desde www.xprogramming.com. Publica un diario electrónico en blogs.msdn.com/marcod

// REFLEXIONES

www

.sof

twar

egur

u.co

m.m

xS

OFT

WA

RE

GU

RU

CO

NO

CIM

IEN

TO

EN

PR

ÁC

TIC

A

N

ovie

mbr

e-D

icie

mbr

e 20

06

Año

02

No.

06

sg12 (noviembre-diciembre 2006)

Documents

software soa

software guru conocimiento

pruebas de software

luis daniel soto

jms confiabilidad

edicin nmero

directorioun ao ms est

amcis luis cuellar