Software Guru CONOCIMIENTO EN PRÁCTICA

w

ww

.sof

twar

egur

u.co

m.m

xS

OFT

WA

RE

GU

RU

CO

NO

CIM

IEN

TO

EN

PR

ÁC

TIC

A

May

o-J

unio

200

6

Año 02 No.03 • Mayo-Junio 2006 • www.softwareguru.com.mx

[ PROGRAMACIÓN ]Spring

Noticias • Eventos • Fundamentos • Reflexiones • Tecnología • Carrera

Año

02

No.

03

• Requerimientos

• Service Level Agreements

• Arquitectura de Software

METODOLOGÍAS ÁGILES[ ENTREVISTA ]Carlos Montes de OcaCIMAT

ESPECIALLa Industria en cifras

[ UML ]

Diagramas de estado

02 MAY-JUN 2006 www.softwareguru.com.mx 03MAY-JUN 2006www.softwareguru.com.mx

DIRECTORIO

Edición EjecutivaPedro Galván

Coordinación EditorialMara Ruvalcaba

Edición y ProducciónEdgardo Domínguez

Arte y DiseñoOscar Sámano, Dafne Ortega

Consejo Editorial Francisco Camargo, Guillermo Rodríguez, Ralf Eder y Raúl Trejo, ITESM CEM; Hanna Oktaba, UNAM-AMCIS; Luis Cuellar, Softtek.; Luis Vinicio León, e-Quallity - ITESO

ColaboradoresLuis Daniel Soto, Ariel García, Paulina Olivares, Ariel Súcari, Dora Luz González, Luis Guerrero, John Gómez, Mónica Vázquez, Axel Nissim, Domingo Suárez, Luis Felipe Fernández, Sergio Orozco, Eugenio Torres.

Ventas Claudia Perea

Marketing Natalia Sánchez

DistribuciónDaniel Velázquez

Ilustración de PortadaTollhaus

Contactoinfo@softwareguru.com.mx+52 55 5239 5502

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 contenido 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 contenido:10572. ISSN: 1870-0888. Registro Postal: PP15-5106. Se imprimió en abril de 2006 en Litográfica Roma. Distribuido por Sepomex.

Existen muchas cosas que llaman la atención sobre las metodologías ágiles. Lo primero, es que al parecer ya no es necesario referirse a ellas como “metodologías ágiles”, sino que ya se utiliza el término “Ágil” (con mayúscula y en singular) para referirse a este conjunto de métodos y la filosofía que representan. Bueno, habien-do aclarado ese punto, hagámonos la pregunta del millón:

“¿De qué se trata Ágil?”

Algunos conocedores podrían decir que Ágil se refiere a una forma innovadora de desarrollar software, basada en prácticas como el desarrollo iterativo, entregas continuas, programar antes de probar, involucrar al cliente y que contrasta con la forma tradicional de desarrollar software, en cuanto a que es mucho más flexible y adaptable, por lo que se adecúa mejor a proyectos innovadores.

Esta sería una respuesta válida. Sin embargo, a nuestro juicio no menciona la esencia de Ágil. Y es que la esencia de Ágil es la gente. Así es, después de déca-das de dedicarnos a generar tecnologías, herramientas, modelos y procesos que soporten el desarrollo de software, nos estamos dando cuenta que la base del desarrollo de software, son las personas. ¡Ja, de haberlo sabido antes, hubiera estudiado psicología!

Hay muchísimo que podemos aprender de las metodologías ágiles. Pero en lugar de perdernos en asuntos como si se debe programar en pares o no, o si es ade-cuado generar builds cada dos horas, debemos estar conscientes de que todas las prácticas de Ágil existen por una simple y sencilla razón que acostumbramos olvidar: el software es desarrollado por personas.

Agradecemos el entusiasmo de todos los colaboradores que se interesaron en par-ticipar en este número. Mil gracias a Carlos Montes de Oca por compartir con no-sotros su visión sobre la academia y la industria en que operamos. Por último, les recordamos que pueden enviar cualquier propuesta de contenido, o retroalimenta-ción a editorial@softwareguru.com.mx. Gracias, y que disfruten este número.

Equipo Editorial

A >

EDITORIAL

02 MAY-JUN 2006 www.softwareguru.com.mx 03MAY-JUN 2006www.softwareguru.com.mx

contenido may-jun 2006 Año 2 número 03

Productos

LO QUE VIENE 12Microsoft Atlas, NetBeans Enterprise Pack, Oracle SQL Developer

HERRAMIENTAS 14Desarrollo Dirigido por Pruebas

Prácticas

ADMÓN de PROVEEDORES 32Service Level Agreements, Parte 2.En la segunda parte de esta serie, Axel Nissim comparte lineamientos y recomendaciones para desarrollar acuerdos de nivel de servicio, desde la perspectiva del proveedor.

REQUERIMIENTOS 34El ABC de un Taller de RequerimientosMónica Vázquez nos guía a través de lo que se debe hacer para realizar un taller de requerimien-tos exitoso.

PROGRAMACIÓN 36Desarrollo JEE Ágil con Spring Domingo Suárez nos explica algunas debilidades de JEE, y como sobreponerlas con Spring.

ARQUITECTURA 40Arquitectura de SoftwareLuis Felipe Martínez nos habla sobre los orígenes y trascendencia de la arquitectura de software.

UML 45Diagramas de EstadoSergio Orozco nos enseña como modelar el estado de un objeto.

Columnas

Tejiendo Nuestra Red 08por Hanna Oktaba

Mejora Continua 10por Luis Cuellar

Cátedra y Más 30por Francisco Camargo

Tendencias en Software 39por Luis Daniel Soto

En Cada Número

Noticias y Eventos 04Reportaje 06Fundamentos 46Carrera 48Infraestructura 50Reflexiones 54

EN PORTADAMétodos ÁgilesLo ágil es lo de hoy. Conozcamos los prin-cipios de los métodos ágiles, así como los mitos y realidades asociados a ellos.

22

Entrevista 20 Carlos Montes de Oca

Industria Mexicana 16de Software en Cifras

04 www.softwareguru.com.mxMAY-JUN 2006

NOTICIAS

Noticias

Azertia México obtiene el nivel 3 CMMI

En diciembre pasado, Azertia México logró la acreditación en el nivel 3 de CMMI (Capability Maturity Model Inte-grated) del Instituto de Ingeniería de Software (SEI) tras realizar la evalua-ción formal en sus áreas de proyectos cerrados (soluciones) y fábrica de soft-ware, que se encuentra en Cuautitlán, Estado de México.

Con esta evaluación, Azertia se convir-tió en la segunda empresa en México en obtener este nivel de CMMI, lo cual pone de manifiesto la capacidad técni-ca, de gestión y de calidad que posee en el desarrollo y mantenimiento de aplicaciones de software, tanto en la línea de proyectos cerrados como en la fábrica de software.

Azertia es una compañía multinacional originaria de España y pertenecien-te a Corporación IBV (BBVA e Iber-drola), dedicada a ofrecer servicios de TI. Cuenta con centros de trabajo en diversas localidades de España y Latinoamérica.

Mayor información en www.azertia.com.mx

Magnabyte alcanza nivel 2 de norma mexicana basada en MoProSoft

Después de un proceso de implantación del modelo MoProSoft y un seguimiento interno, Magnabyte se convirtió en la primera empresa dictaminada por NYCE bajo el nivel 2 de la norma mexicana aplicable para la verificación de procesos de Tecnologías de Información NMX-I-059/02. Dicha norma está basada en el modelo MoProSoft, que busca llevar a las empresas mexicanas a alcanzar niveles internaciones en capa-cidad de procesos, y mide el nivel de madurez de 9 procesos que corresponden a las capas de Alta Dirección, Gestión y Operación.

“El participar en este modelo resultaba indispensable para nosotros, ya que creemos firmemente en la capacidad que existe en México de crear software de alta calidad así como en el Programa para el Desarrollo de la Industria del Software (ProSoft) de la Secretaría de Economía, el cual se alinea a nuestros objetivos de negocio, como con-vertirnos en una empresa líder latinoamericana en la industria de software, desarrollar soluciones de alta competitividad y generar empleos para profesionistas mexicanos”, indicó Oscar Flores, Director General de Magnabyte.

Mayor información en www.magnabyte.com.mx

Gartner Enterprise Integration Summit

El pasado 5 y 6 de abril, Gartner realizó en la Ciudad de México su Enterprise Integration Summit, donde se mane-jaron temas sobre de Integración de Aplicaciones, Servicios Web, SOA y BPM. Los analistas de Gartner compartieron su análisis del mercado, las principales tendencias, y lec-ciones aprendidas, e hicieron diversas recomendaciones para las organizaciones involucradas o prontas a iniciar proyectos de este tipo. Entre las empresas patrocinado-ras estuvieron Sterling Commerce, IBM, Oracle, Microsoft, Software AG, Axxis, y otras más.

En comparación con la cumbre de Gartner del año anterior relacionada con los mismos temas, este año percibimos que los asistentes ya tenían una mucho mejor idea de temas como BPM y SOA, y en varios casos ya tenían en curso inicia-tivas de este tipo. Adicionalmente, los proveedores también reflejaron una mayor madurez en cuanto a su oferta.

SigmaTao ya es CMMI 3

Otra empresa que recientemente logró su acreditación en el nivel 3 de CMMI es Sigma-Tao Factory, fábrica de software mexicana ubicada en Querétaro.

Esta evaluación de reconocimiento internacional, se suma a las anteriormente obteni-das (CMM-5 y Java Center of Excellence) y ubica a Sigma Tao en el mercado mexicano como parte del selecto grupo que ha obtenido este grado de evaluación, a la vez que confirma su compromiso con la calidad y excelencia en sus productos, así como en los procesos de ingeniería software que los generan. SigmaTao tiene actualmente 540 In-genieros altamente capacitados y que proveen servicios a las más grandes empresas e instituciones del pais. SigmaTao es parte de EIDON Software, corporativo que incluye a Zentrum (Cmm-3), Blitz (Cmm-3) y ASPEL (Cmm-2) teniendo en total más de 1,700 profesionales dedicados al desarrollo de soluciones de software de alta calidad.

05www.softwareguru.com.mx MAY-JUN 2006

Eventos

13 Mayo 2006Debian DayCentro Vacacional IMSS. Oaxtepec, Mor.es.debconf.org/debianday

14 y 21 Mayo 2006DebConf6Centro Vacacional IMSS. Oaxtepec, Mor.debconf6.debconf.org

16 y 17 Mayo 20068va Conferencia Anual Information Security Hotel Camino Real, Ciudad de MéxicoTel: (55) 5340 23 22www.informationsecurity.com.mx

22-24 Mayo 2006Congreso de Software Libre GULEV 2006Museo del Transporte. Xalapa, Veracruzwww.gulev.org.mx

25 Mayo 2006IDC Service Oriented Architecture SeminarHotel Presidente Intercontinental Monterrey, NLTel: (55) 5661 – 3791www.idc-eventos.com/soa06

25 y 26 Mayo 2006Optimizando los servicios de TI con ITIL e ISO 20000 y Automatizando la administra-ción de TI con ITSM25 de Mayo - Ciudad de México, 26 de Mayo - Monterrey, NLTel: (55) 5281 76 70www.itera.com.mx

5 de Junio 2006IDC IT Security & Business Continuity Con-ference 2006 Centro Banamex, Ciudad de MéxicoTel: (55) 5661 – 3791www.idc-eventos.com

9 de JunioTCDS BPM Executive Day 2006Ciudad de MéxicoTel: (55) 5639-3742www.tcds.com.mx/mx/events/bpmxd06.html

27 y 28 de Junio 2006Gartner 2nd Annual Outsourcing SummitCentro Banamex, Ciudad de MéxicoTel: (55) 5584 9370www.gartner.com/mx/outsourcing

Fox inauguró el Centro de Tecnología Electrónica Vehicular del ITESO El pasado 9 de marzo el presidente de México, Vicente Fox inauguró en el ITESO, Universidad Jesuita de Guadalajara, el Centro de Tecnología Electrónica Vehicular (CTEV). El obje-tivo de este proyecto es establecer un centro donde concu-rran los sectores automotriz, electrónico y de software, para

diseñar, desarrollar y probar sistemas para automóviles.

“Lo que estamos tratando de hacer aquí es vincular a tres sectores muy impor-tantes para México, nada menos que la electrónica y automotriz, con la que yo considero la más estratégica, que es tec-nologías de información y comunicacio-nes” mencionó Eduardo Ramírez, Director de Soluciones Tecnológicas, la empresa mexicana con la cual el ITESO firmó el convenio que originó este proyecto.

El centro está ubicado dentro del edificio de Tecnologías de Información del ITESO, en un espacio de 425 metros cuadra-dos. Se creó con una inversión de cinco millones de pesos, de los cuales el 25 por ciento corrió a cargo del Gobierno fe-deral, a través del fondo ProSoft, otro 25 por ciento lo aportó el Gobierno Estatal, a través del Consejo Estatal de Ciencia y Tecnología de Jalisco (Coecytjal), y el 50 por ciento restante fue aportado por el ITESO y Soluciones Tecnológicas.

La principal estrategia de IT@baja es promo-ver proyectos que permitan impulsar el cre-cimiento de las empresas ya instituidas, y la creación de nuevas, para fomentar una alta competitividad en el estado que lleve even-tualmente a un grado de excelencia a los dis-tintos proveedores de servicios y productos de TI, lo que consolidará al estado como una alternativa real para empresas norteamerica-nas en busca de soluciones integrales.

Aprovechando la proximidad con los Estados Unidos, y el huso horario compartido con Ca-lifornia, este Cluster ofrece gente y empresas que conocen perfectamente la cultura de nego-cios e incluso laboral de las compañías estado-unidenses, además de que dominan el idioma inglés, lo que representa una ventaja definitiva para ganar la preferencia de las empresas que buscan una alternativa viable en término de costos y valor agregado, sin sacrificar calidad.

Antecedentes y FuncionesA finales del 2002, como resultado de un es-tudio para definir las competencias del estado de Baja California. se establecieron los esque-mas, conformación y estrategia del Cluster ne-cesarias para dirigir el desarrollo del sector de tecnologías de información en este estado. En una etapa inicial, se optó por concentrarse en el desarrollo de software y promoción de las aplicaciones existentes en el estado.

Entre las funciones de IT@Baja están:• Ejecutar las estrategias de promoción, ca-pacitación, certificación, vinculación, legal, fondeo, etc.• Promover la integración continua de las em-presas de este ramo a través de los organis-mos que las representan. • Promover proyectos de subcontratación de desarrollo de software.• Buscar el entrenamiento y capacitación continua de sus integrantes.• Estandarizar la aplicación de metodologías

entre sus integrantes.• Vinculación con organismos similares en México y otras regiones, principalmente en el Estado de California, en donde existe una demanda muy importante de subcontrata-ción de desarrollo de software.• Vigilar la imparcialidad de asignación de oportunidades de negocio y proyectos inter-nos mediante el código de ética y estatutos del cluster.• Conceder el uso de la marca a empresas que tengan la certificación de calidad.• Proveer un espacio físico para reuniones estratégicas.• Promover la innovación e incubación de ne-gocios, a través de centros de desarrollo de tecnologías de información.

Logros y MetasDentro de los principales logros a la fecha, IT@baja ha promovido continuamente la in-teracción de las compañías integrantes del Cluster, conformando varias asociaciones, programas y comunidades. He aquí algunos ejemplos:• Asociación de Profesionales de IT.• Centro de Excelencia Tecnológica en Están-dares Abiertos.• Comisión Académica e Industria.• Modelo de Desarrollo CT Connect.• Comunidad .Net.

A la fecha, IT@Baja cuenta con 43 socios ac-tivos, que reunen una facturación superior a los 28 millones de dólares en 2005. Esto representa más del 60% de la facturación de las empresas de software en Baja California.

Dentro de los planes de vinculación académica, se creó un programa de capacitación y certifica-ción de maestros universitarios en tecnología .NET y Java, además de impartir un taller de MoProSoft y un diplomado de Pruebas de Soft-ware. Se formalizó un convenio de colaboración con la Universidad Autónoma de Baja California

(UABC), con el que se pretende lograr un pro-grama de extensión académica y conformar una plan de acción para el crecimiento de los egre-sados en las empresas vinculadas al Cluster.

Entre las principales metas de IT@baja están:• Iniciar la promoción del Cluster a nivel regio-nal, nacional e internacional.• Promover el soporte gubernamental a organizaciones.• Soporte y alineación de intereses con el sec-tor académico.• Incrementar la membresía.• Desarrollar comisiones internas.• Desarrollar talleres internos y externos.• Atraer socios de clase mundial.• Actualizar y promover proyectos y programas a partir de iniciativas de sus integrantes.• Atraer nuevas inversiones y fondos hacia el desarrollo de TI en el Estado.

Las EmpresasLa asociación está constituida por distin-tos representantes que tienen algún tipo de relación con el sector de tecnologías de información de Baja California; empresas de desarrollo de soluciones a la medida, proveedores de soluciones contables, ad-ministrativas, de recursos humanos, de co-mercio exterior, ERPs, etc., proveedores de software a la medida y de infraestructura tecnológica.

Los integrantes hasta la fecha son: Grupo Red, Nettss, Prisma Computación, Grupo SyS, Coordenada, SITSA, Telecomm, Ever-est, G-H & T, BTS, RT Solutions, SmartBC, Cybercorp, Betta Global Systems, LIDA-SA, Aprovi, GM Consultores, , Tecnología Educativa, EYS, Condete, Infosyst S.C., Intelligence Learning, Imacor, Aster, Inter-fase Mircrosystems, Arkus, Gr Soluciones, Grupo Tress, Zentrum, Nexus, INTEGRA, Business Ware, Gr Soluciones Computacio-nales, Condete, Central Software y 4 Inte-gradoras: INTUARE, SDS,iMedis e INTAN.

06 MAY-JUN 2006 www.softwareguru.com.mx

CLUSTERS

IT@BajaUna Solución IntegralEsta asociación civil sin fin de lucro, formada hace cinco años y constituida en la segunda mitad del 2004, busca explotar las ventajas de su ubicación geográfica y constituir al estado de Baja California en un Cluster líder en México en el desarrollo de empresas de TI, para fomentar la exportación de servicios, principalmente al ve-cino país del norte.

Asamblea en Mexicali, Marzo 2006

Para cuando lean esta columna, probablemente ya se habrá llevado a cabo la International Conference on Software Engineering (ICSE’06) en Shanghai, donde Barry Boehm participará como conferencista, y

en su plática presentará su visión de la perspectiva histórica y el futuro de la Ingeniería de Software. Así que conociendo la importancia de este personaje y el impacto de sus opiniones, les comparto un pequeño resumen del artículo que Boehm desarrolló para esta ocasión y que nos hizo llegar a los miembros del IPRC (International Process Research Consortium).

El autor empieza por darnos su definición de la Ingeniería de Software:“... es la aplicación de la ciencia y las matemáticas a la construcción del software de tal forma que sus propiedades lo hacen útil para las personas.”

Lo que me llama la atención en esta definición es el énfasis en las propiedades de software útiles para el cliente. Esto nos habla de calidad del software, pero no desde una perspectiva de actividades —como otras definiciones—, sino del valor generado para el cliente. Posteriormente, el artículo hace una retrospec-tiva sobre la ingeniería de software desde los años cincuenta hasta la época actual, y termina con predicciones para el próximo par de décadas. Veamos entonces los puntos más significativos:

Años CincuentaSe aplica al desarrollo de software el mismo proceso que al desarrollo de hard-ware, tipo cascada rigurosa. Las lecciones aprendidas fueron las siguientes:Buenos principios• No ignorar matemáticas, ciencias de la computación, sociales, económicas y administrativas.• Usar el método científico para aprender a través de la experiencia.• No comprometerse demasiado antes de entender la complejidad de un proyecto Evitar• Seguir demasiado rigurosamente el proceso de desarrollo secuencial.

SesentasEl desarrollo de software es artesanal. Las propiedades de software, tales como: fácil de modificar, fácil de copiar, no se gasta, es invisible, fomentaron el proce-so de desarrollo tipo “codifica y corrige” (code and fix). Se inició la cultura del hacker en el buen sentido de la palabra, es decir experto en programación, y la del vaquero (cowboy) que hace desarrollos heroicos de última hora.Buenos principios• Atreverse a hacer prototipos novedosos, no limitarse a repetir lo que ya se conoce.• Respetar que el software es diferente. No se puede incrementar la velocidad de su desarrollo de manera infinita. Evitar• Programación al estilo vaquero. Parches de último minuto o trabajo de última noche pueden traer graves consecuencias.

SetentasSe identifican las diferentes fases del desarrollo: requerimientos, análisis, diseño, codificación y pruebas. Se introduce la programación estructurada y métodos formales para especificar software. Se identifican principios de diseño, como modularidad, encapsulación, abstracción de tipos de datos,

08 www.softwareguru.com.mxwww.softwareguru.com.mxMAY-JUN 2006

acoplamiento débil y alta cohesión, entre otros. Se pu-blica el modelo de cascada y se definen los conceptos de verificación y validación.Buenos principios• Eliminación temprana de defectos y su prevención a tra-vés del análisis de causa.• Determinación temprana del propósito de sistema para tener una visión compartida con el cliente.Evitar• Desarrollo descendente (top-down) a toda costa. Los requerimientos emergentes y los cambios lo hacen poco realista, para la mayoría de los casos.

OchentasSe busca la productividad y escalabilidad de sistemas y equipos de desarrollo. La Orientación a Objetos renace con fuerza a través de las múltiples propuestas de lengua-jes de programación. Se crea el primer modelo de madu-rez de capacidades de procesos (SW-CMM) y los primeros estándares. Nace el concepto de Fábricas de Software y se generan las primeras herramientas para incrementar la productividad a través de la programación por el usuario, tales como 4GLs.Buenos principios• Hay muchos caminos para incrementar la productividad que incluyen la selección del personal, capacitación, herra-mientas, reutilización, mejora de procesos, entre otros.• Lo que es bueno para el producto es bueno para el proce-so, por ejemplo: arquitectura, composición y adaptación.Evitar• Pensar que existe una solución mágica (silver bullet) que aplica a toda clase de problemas.

NoventasLa concurrencia (paralelismo y distribución) adquiere ma-yor importancia con respecto a procesos secuenciales. La Orientación a Objetos se extiende a las fases de análisis y diseño. Se acuerda un lenguaje de modelado (UML) y se genera el primer proceso comercial de desarrollo orienta-do a objetos (RUP). Los diseñadores y los arquitectos de software empiezan a recaudar las mejores experiencias a través de patrones de diseño y de arquitectura. Se define el Modelo Espiral para el desarrollo basado en el análisis de riesgos y su vertiente conocida como desarrollo iterati-vo e incremental. El Software Libre toma fuerza y se crean los primeros ejemplos exitosos. La usabilidad de sistemas se convierte en el foco de atención e investigación. Soft-ware empieza a ocupar la posición crítica en el mercado competitivo y en la sociedad (web).Buenos principios• El tiempo es dinero. La gente invierte en software esperando retorno de inversión, mientras más rápido se desarrolle el soft-

CO

LUM

NA

Historia y Futuro de la Ingeniería de SoftwareVisión de Barry Boehm

TEJIENDO NUESTRA RED

La Dra. Hanna Oktaba es profe-sora de la UNAM a nivel licenciatura y posgrado. Sus áreas de interés principales son Ingeniería de Software, Tecnología Orientada a Objetos, Modelos de Procesos de Software y Mejora de Procesos. Es fun-dadora de la AMCIS, de la cual actual-mente es Secretaria. Estuvo a cargo de los proyectos MoProSoft, EvalProSoft y Pruebas Controladas, base de la actual Norma Mexicana para la Industria de Software. Actualmente es miem-bro de International Process Research Group (IPRC), orga-nizado por Software Engineering Institute (SEI), cuyo objetivo es definir las líneas de investigación en el área de procesos para los próximos diez años. También es Directora Técnica del proyecto COMPE-TISOFT, cuyo objetivo es la mejora de pro-cesos para fomentar la competitividad de pequeña y mediana industria de software en Iberoamérica.

09www.softwareguru.com.mx MAY-JUN 2006

TEJIENDO NUESTRA RED

ware, más rápido se recupera la inversión, pero eso pasa sólo en el caso cuando la calidad de software es satisfactoria.• El software tiene que ser útil para la gente, es la parte crucial de la definición de Ingeniería.Evitar• Hacer las cosas demasiado rápido. Los hitos muy ambi-ciosos a menudo traen como consecuencia las especifica-ciones incompletas, que resultan en mucho re-trabajo.

Situación ActualLos temas nuevos son la agilidad en el desarrollo y el va-lor para el cliente. Se redacta el Manifiesto de Agilidad en respuesta al estilo promovido por CMM. Surgen nue-vos dispositivos (PDAs, celulares) que involucran el ciclo: Aprendizaje-Seguridad-Mejorar su uso. Las cualidades prioritarias de sistemas son: Seguridad/Privacidad, Usa-bilidad y Confiabilidad. Se incrementa la propagación de software empaquetado COTS (Commercial-Off-The_Shelf ). Crece el entendimiento de las bondades del código abier-to. El desarrollo dirigido por modelos (MDD, Model Driven Development) toma fuerza. Se integra el proceso de desa-rrollo de software con el de sistemas.Buenos principios• Cuando los cambios son frecuentes la adaptabilidad del proceso debe ser más importante que la repetición.• Primero hay que considerar y satisfacer los asuntos que son de valor para el cliente.Evitar• Enamorarse de tus propios lemas. Decir al cliente “no lo vas a necesitar”, no siempre es cierto.

Prospectiva para las Décadas de 2010 y 2020Las tendencias que van a afectar, en el futuro próximo, la for-ma de desarrollar software son las siguientes:Globalización. La conectividad global proporcionada por el Internet y las comunicaciones de banda ancha causará la evolución de las principales economías hacia redes de eco-nomías. En consecuencia, se requerirá de nuevos procesos de desarrollo para la colaboración global exitosa. Los retos claves serán: la colaboración multicultural, lograr las visiones compartidas y la confianza, definir mecanismos de contrata-ción, incentivos, entregas y la sincronización de cambios, que aprovechen múltiples zonas horarias. Algunos problemas relacionados con diferencias culturales fueron identificados en un estudio sobre la adopción de procesos. Por ejemplo, SW-CMM que proviene de la cultura Individualista/Mascu-lina/Corto plazo tuvo muy baja aceptación en la cultura de Tailandia que es Colectiva/Feminista/Largo plazo.

Sistemas de sistemas. La habilidad de las organizaciones de competir, adaptarse y sobrevivir en el mercado y en la

sociedad globalizada va a depender, en gran medida, su habilidad para integrar sistemas de software en sistemas de sistemas (Systems Of Systems - SOS). Un SOS integra múltiples sistemas desarrollados independientemente y se caracteriza por su gran tamaño (>10 millones de SLOCs, > 30 tipos de interfaces externas diferentes, > 20 provee-dores). Los retos para el desarrollo de SOS son: lograr acuerdos a tiempo con diversos involucrados, resolver rápido los conflictos en los requerimientos y coordinar ac-tividades de múltiples proveedores.

Abundancia computacional. La Ley de Moore seguirá vi-gente al menos durante los próximos veinte años. Con esto, vamos a tener una abundancia de aparatos peque-ños pero con gran poder de procesamiento. La Ingeniería de Software tendrá que enfrentarse con los problemas de cómo manejar el desarrollo para esta abundancia compu-tacional, y finalmente, como integrar estos dispositivos a los SOS. Esto va a requerir de nuevos niveles de abstrac-ción para la programación y nuevas herramientas con ma-yor poder basado en el uso del conocimiento.

Autonomía computacional. Es una visión en la cual la In-teligencia Artificial alcanza plenamente sus objetivos. Las máquinas se vuelven autónomas, evalúan las situaciones y determinan la mejor opción para actuar.

Combinación de biología y computación. Aquí habrá una influencia mutua. La computación basada en biología uti-liza fenómenos moleculares o biológicos para resolver problemas computacionales. Mientras que la biología computacional tratará de mejorar las capacidades huma-nas, incorporando dispositivos al cuerpo humano.

Este resumen lo presenté recientemente en la re-unión mensual de la AMCIS, y el comentario final de una de las asistentes fue: “Qué pena que todavía no hemos salido de los sesentas”. Es verdad que en muchas organizaciones todavía prevalece la cultura del vaquero; pero también veo muchos esfuerzos que están cambiando este panorama. No debemos parar en el camino.

—Hanna Oktaba

Referencia• B. Boehm, “A View of 20th and 21st Century Software Engineering, International Conference on Software Engi-neering (ICSE’06), 20-28 Mayo de 2006, Shanghai, China, Copyright 2006 ACM 1-59593-085-X/06/0005.

Hace algunos meses asistí a un curso de metodologías ágiles que se impartió en la CANIETI en Monterrey. De ninguna manera me considero un experto en me-

todologías ágiles, y el curso en realidad era bastante básico. Una de las partes que llamó mi atención fue la mención de una aparente guerra entre los seguidores de metodologías ágiles y los seguidores de modelos como CMM o ISO 9000. De hecho, el comentario surgió para explicar el nacimiento de Ágil como respuesta por parte de aquellos que considera-ban los modelos de calidad como demasiados burocráticos. En base a esto, decidí investigar un poco más y me topé, al hablar con gente dentro de la organización y algunos clientes que enfatizan este tipo de metodologías, que efectivamente se nota cierto recelo al mencionar CMM y la documentación que se requiere en un proyecto. Todo esto me sorprende por-que en realidad yo no veo a estas estrategias peleadas entre sí, sino que de alguna manera podrían ser complementarias.

En Esta Esquina...Antes de iniciar esta plática quiero dejar algo totalmente cla-ro: en mi trabajo de día con día me he topado con un sinnúme-ro de compañías que básicamente exponen que le dan total autoridad y libertad al individuo, confían en la gente y todos los días se les asignan nuevas tareas, las cuales esperan se resuelvan en forma continua; no tienen nada documentado y por ende son fieles seguidores de metodologías ágiles. Nue-vamente, bajo la premisa de que no me puedo considerar un experto en el tema, esto me parece más como caos total que como una nueva forma de hacer las cosas.

Es muy fácil escudarse en manejar metodologías ágiles cuando no se está haciendo nada, ya que en sí los segui-dores de metodologías ágiles defienden el que cada quien haga lo que sea más eficiente para su proyecto. Esto me lle-vó a la pregunta, ¿qué son las metodologías ágiles y cómo se diferencian de la anarquía? Así que decidí investigar un

poco más sobre las premisas específicas de lo que hace ágil a una metodología. A través de una rápida búsqueda en Go-ogle, fui a dar a la página del denominado “Manifiesto Ágil”, el cual establece las bases de las metodologías ágiles. La tabla 1 lista los principios en que se basan unos y otros.

A grandes rasgos, podemos notar las siguientes diferencias:Desarrollo incremental y entregas continuas. Los agilistas defienden un desarrollo incremental y la constante entrega de valor. Esto me parece una excelente idea y no veo que esté en contra de CMM o ISO 9000. CMM habla sobre controlar los requerimientos, más no menciona nada sobre el tiempo en que se debe de recibir, por lo tanto podemos decir que mode-los como CMM no entran en esto en forma tan específica. Sin embargo, si esto es viable en el proyecto que estamos desa-rrollando, me parece definitivamente una excelente forma de actuar, yo diría que tomemos esto como práctica.

Documentación. CMM enfatiza la documentación, aunque más bien se refiere a la documentación del proceso, y no tanto del proyecto. Creo que tanto en metodologías ágiles como no ágiles debe de ser claro cómo se llevarán a cabo los proyectos y las prácticas que se aplican, desde el “Plan-ning Game” hasta la programación en pares. Esto permite lograr consistencia en diferentes proyectos. Así que docu-mentar el proceso me parece una excelente idea.

Tipo de comunicación. Posiblemente, el punto más contro-versial es que las metodología ágiles enfatizan la comunica-ción cara a cara, y la comunicación entre desarrolladores y usuarios, mientras que CMM enfatiza la documentación de acuerdos. Desde mi punto de vista, podemos unir las dos ideas; creo que la mejor forma de comunicar y ponernos de acuerdo es cara a cara, y muchas veces, la mejor docu-mentación para las decisiones que se llevan acabo en forma inmediata es la ejecución, pero en un mundo de negocios

CO

LUM

NA

10 www.softwareguru.com.mx

Los Modelos Ágiles y no Tan Ágiles Ágil vs. CMM

MEJORA CONTINUA

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.

MAY-JUN 2006

CMM• Mejora continua de trabajo.

• Define, documenta y utiliza procesos.

• Compromiso de la alta dirección.

• Deben de existir procesos estables a tra-

vés de la organización.

• Mide los procesos para ver si estas cum-

pliendo tus objetivos

• Controla los procesos de la organización

• Mejora los procesos en forma continua

Manifiesto Ágil• Satisfacer al cliente mediante tempranas y continuas entregas de software que le aporten valor.

• Aceptar cambios de requerimientos. Utilizarlos para generar ventaja competitiva para el cliente.

• Trabajar en conjunto entre las gente de negocios y desarrollo.

• Formar equipos de individuos motivados, darles el ambiente y soporte que requieren, y confiar

en su capacidad para cumplir con el trabajo.

• La mejor forma de comunicación entre el equipo de trabajo es conversación cara a cara.

• El software que funciona es la mejor forma de medir el progreso.

• Se debe seguir un ritmo de trabajo que se pueda sostener de manera continua

• La atención continua a la excelencia técnica y el buen diseño fortalecen la agilidad.

• La simplicidad es esencial.

• Las mejores arquitecturas, requerimientos y diseño surgen de equipos auto organizados.

• Frecuentemente y de manera regular, el equipo reflexiona sobre como puede ser más efectivo,

y ajusta su comportamiento para lograrlo.

y seres humanos siempre hay riesgos, y las personas olvidan acuerdos, y a veces surgen rencores en base a estos olvidos por lo que tenemos que definir qué deberíamos de do-cumentar y registrar solamente eso.

Métricas. Otro punto fundamental en las dife-rencias es que CMM nos pide medir nuestros procesos, mientras que Ágil nos pide que con-tinuamente mejoremos lo que hacemos, pero no nos pide medir nada para decidir qué me-jorar. Aquí, si no tenemos salida, tenemos que tomar una decisión. Por un lado, las métricas a nivel organizacional nos ayudan para entender mejor nuestro trabajo y aprender rápidamente de nuestros errores, pero al hacer esto podría verse como falta de confianza en nuestra gente y en su capacidad para tomar decisiones racio-nales sobre lo que pueden mejorar. No hay una solución única, la organización debe tomar

una postura. Lo único es que cualquier deci-sión que tomemos debe de ser apoyada por otros procesos, esto quiere decir que si vamos a medir, debe de haber toda una infraestructu-ra de seguimiento, análisis y mejora a través de las métricas. Si no vamos a medir, debe de haber una serie de estructuras que ayuden a entrenar y transmitir el conocimiento en forma continua para así todos tener el mismo enten-dimiento de lo que es mejorar.

Y el Ganador es: ¡El Cliente!¿A donde vamos con todo esto? A final de cuentas, las ideas del manifiesto ágil son bastante interesantes; pero como todo cam-bio, implantarlas no es simple. De hecho, implantar el modelo ágil correctamente pue-de ser tan complicado como implantar ITIL, CMM o cualquier otro modelo de calidad. La organización debe tomar una decisión de ha-

cia donde quiere moverse, para hacerlo en forma enfocada y directa y lograr el mayor beneficio hacia sus clientes.

La realidad es que no deberíamos estar vien-do los diferentes modelos de desarrollo de software como una gran pelea que busca a el gran ganador, sino como un grupo de herra-mientas con conceptos e ideas importantes que debemos de unir y extraer aquello que haga que crezcamos como organización y que a final de cuentas nos ayude a llevar el mejor producto al mercado. Al final, el gana-dor debe ser el cliente.

Si quieres platicar más sobre el tema nos ve-mos en www.agentesdecambio.org o escríbe-me a lcuellar@agentesdecambio.org

—Luis Cuellar

PR

OD

UC

TO

S

PRODUCTOS

SQL DeveloperAdiós a SQL Plus

De acuerdo con Oracle, ya es hora de que sus desarro-lladores de base de datos tengan su propio IDE. Con ese propósito, la compañía liberó en marzo la versión 1.0 del SQL Developer, un ambiente gráfico para la interacción con bases de datos Oracle. Entre otras capacidades, SQL Developer permite analizar el desempeño y estructura de una base de datos desde un ambiente gráfico. Dado que está construido sobre JDeveloper, también se puede uti-lizar para desarrollar aplicaciones, así como para migrar otras bases de datos hacia Oracle.

Oracle SQL Developer se puede descargar gratuitamente en otn.oracle.com

LO QUE VIENE

NetBeans Enterprise PackHerramientas Open Source para Desarrollo Empresarial

Sun Microsystems anunció que abrirá como software libre, componen-tes clave del Java Studio Enterprise para el desarrollo de aplicaciones empresariales. Estos componentes estarán incluidos en el NetBeans Enterprise Pack, que funcionará sobre la versión 5.5 de NetBeans.

Algunas de las capacidades incluidas en el NetBeans Enterprise Pack serán:Modelado bidireccional UML. Con esto se pueden generar diagra-mas UML que automáticamente se mantengan en sincronía con los cambios en el código fuente, y viceversa.Herramientas XML. Infraestructura para el manejo de XML y editores visuales para archivos XML.SOA y orquestación de procesos. Herramientas para desarrollar apli-caciones compuestas que funcionen dentro de arquitecturas orien-tadas a servicios y orquesten procesos de negocio. Esta tecnología se obtuvo gracias a la adquisición de la empresa SeeBeyond.

Mayor información en www.netbeans.org

Atlas, el framework de Microsoft para desarrollo de aplicaciones web “ricas”, ya se ve bastante maduro. De hecho, junto con el CTP (Community Technology Pre-view) de marzo, se anunció la disponibilidad de una licencia GoLive para Atlas. Esta licencia permite operar Atlas en sitios de producción de forma gratuita.

Adicionalmente, en abril se liberó el “Atlas Control Toolkit”, que incluye herra-mientas y componentes para que los desarrolladores puedan generar controles interactivos basados en tecnología Ajax, que se conecten fácilmente con compo-nentes .Net del lado del servidor. El toolkit incluye el código fuente, documenta-ción y ejemplos. Microsoft anunció que el código del toolkit será liberado como un proyecto de código compartido, para que la comunidad de desarrolladores pueda contribuir con mejoras y extensiones.

Mayor información en atlas.asp.net

AtlasLicencia GoLive y Control Toolkit

RedHat Adquiere JBossRedHat Aumenta el Alcance de su Oferta

Dos de las empresas más importan-tes en el open source quedaron unidas cuando Red Hat acordó comprar JBoss. Se espera que el acuerdo sea aprobado y se finalice en las próximas semanas. Algo que llamó la atención, es el precio acordado, de $350 millones de dólares; mas $70 millones adicionales depen-diendo del desempeño de JBoss. Con esto queda demostrado el valor de las empresas open source.

Con esto, Red Hat aumenta la profundi-dad de su “stack” de infraestructura de TI open source, lo cual lo pone más cerca de competir directamente con proveedo-res como Novell, y Microsoft.

12 www.softwareguru.com.mxMAY-JUN 2006

PR

OD

UC

TO

S

Desarrollo Guiado por PruebasAutomatización de Pruebas UnitariasPor Ariel Súcari

E l desarrollo guiado por pruebas (test-driven development), o TDD, es una de las principales prácticas de Extreme Program-ming (XP), que propone una serie de pasos para probar antes

de programar (test-first programming).

El proceso a realizarse es el siguiente:• Se crea un caso de prueba que verifica una pequeña funcionalidad del sistema.• Se ejecuta el caso de prueba, y deberá tener un resultado NO exitoso, ya que la funcionalidad que intenta probar aún no está construida.• Una vez que se observa el fallo, se desarrolla únicamente el código que hará que la prueba sea exitosa.• Por último, se hace un refactoring del código para asegurar que se tie-ne el diseño más simple para la funcionalidad que acaba de agregarse.

Una vez que estos pasos son llevados a cabo, se realiza lo que mo-tiva a la metodología: la ejecución de todas las pruebas automatiza-das que se tienen construidas hasta el momento.

Podemos visualizar gráficamente el párrafo anterior en el siguiente diagrama de actividad en UML.

Luego de esta breve explicación que sólo intenta inducir a los desconocedores e introducir a los entendidos, se pueden vislum-brar cuáles podrían ser las ventajas y las desventajas de utilizar dicha metodología.

Ventajas• Requerimientos de última hora. ¿Cuántas veces un requerimiento in-troducido a último momento le causó defectos en producción debido a un error en el análisis de impacto? ¿En cuál de las siguientes situaciones preferiría estar si necesita cambiar un sistema en producción?a) Cualquiera sea el cambio que usted realice su forma de trabajo le permite probar su impacto en todo el sistema en minutos.b) Alcanza a realizar los cambios pero no tiene tiempo para probar, entonces debe liberar y cruzar los dedos para que funcione y no afec-te otras partes del sistema.

• Se desarrollan 100% de las pruebas. Todas las pruebas se rea-lizan de manera automática y no existe el escenario en que no se puede completar la creación de los casos de prueba debido a que no se escribe una línea de código que no corresponda a un caso de prueba automatizado.

• Cobertura de requerimientos al 100%. Debido a que los reque-rimientos son expresados en forma de casos de prueba y dichos casos son ejecutados automáticamente, cada vez que se agrega una funcionalidad al sistema, estamos seguros de que al finali-zar nuestro desarrollo habremos cubierto en 100% los requeri-mientos del mismo, debido a que ninguno de nuestros casos de prueba ha fallado.

Desventajas• El éxito depende de los casos de prueba. Si se hizo una inter-pretación incorrecta de un requerimiento, se escribirá un caso de prueba que no satisfaga a los deseos del usuario, por lo tanto el producto final será incorrecto.

• Interfaces gráficas. Si se hace el intento de probar las interfa-ces gráficas y estas cambian, debemos perder tiempo en adaptar nuestras pruebas automatizadas. Esto podría causar que en cada versión se invierta tanto tiempo en reescribir las pruebas que se opte por no hacerlo. Complementando la MetodologíaDespués de involucrarme un tiempo con la metodología de de-sarrollo guiado por pruebas y de disfrutar sus virtudes y sufrir sus defectos, he aprendido a resolver estas limitantes a través del

HERRAMIENTAS

Ariel Súcari es consultor de It Era especializado en pruebas de software. Graduado de la Universidad CAECE en Buenos Aires, Argentina. Ha participado y coor-dinado proyectos de la disciplina de pruebas en Inglaterra, Estados Unidos, Venezuela, Argentina y México durante los últimos 7 años.

14 www.softwareguru.com.mxMAY-JUN 2006

HERRAMIENTAS

uso de un par de herramientas de IBM-Rational. A continuación les comparto más al respecto.

Problema 1: Interfaces GráficasLa herramienta Functional Tester de IBM-Rational cuenta con una tecnología llamada ScriptAssure la cual utiliza algoritmos configurables para localizar a los objetos durante la ejecución de las pruebas, aunque éstos hayan cambiado desde la creación del caso de prueba inicial. Es así que Functional Tester actualiza de manera inteligente la forma en que reconoce a los objetos en Java, aplicaciones Web y .NET sin intervención humana, por lo que no requiere que se actualicen los scripts cada vez que cambia la aplicación.

Las herramientas que no cuenten con una tecnología semejante a la descrita, no lograrán reconocer la casilla de verificación y reque-rirán que el desarrollador reprograme sus pruebas. Si esto ocurre en una simple ventana de login como la del ejemplo, ¿qué sucederá con aplicaciones complejas como en las que usted trabaja? Será tanto el trabajo de mantenimiento de los scripts de prueba que sus programadores dejarán de ser productivos.

Otras virtudes que encontré en esta herramienta y que afirmaron mi decisión de adoptarla son:• Los scripts de prueba se pueden programar en Visual Basic .Net y Java.• Tiene herramientas de depuración incluidas en el ambiente de desarrollo tanto para VB .Net como para Java.• Incluye la posibilidad de incluir pruebas manejadas por datos• Soporta la introducción de expresiones regulares para el manejo de patrones.• Tiene un agregado para soportar aplicaciones para terminales 3270 y 5250.• Soporta pruebas automatizadas para ambientes Siebel 7.7.

Problema 2: El éxito Depende de los Casos de PruebaPara evitar el problema de tener casos de prueba que no concuer-den con los requerimientos, lo que podemos hacer es que sean los mismos analistas de negocio quienes desarrollen los casos de prueba. Para esto, no necesitan tener conocimientos técnicos ni desarrollar scripts. Simplemente utilizan otra herramienta de IBM-Rational denominada Manual Tester, y en ella definen fácilmente los casos de prueba.

Para especificar un caso de prueba, simplemente se define la serie de pasos a seguir, y se especifican valores de entrada, así como el resultado(s) esperado. Posteriormente, los desarrolladores se basan

en estos casos de prueba capturados en el Manual Tester, para generar los scripts para pruebas automatizadas. Este pro-cedimiento para generar los scripts está metodológicamente explicado y no da lugar a errores u omisiones.

Algunos beneficios adicionales de cap-turar los casos de prueba con el Manual Tester son:• Proporciona la posibilidad de colocar imágenes para complementar los pasos y contribuir a eliminar ambigüedad.• Permite la reutilización de patrones de prueba en diferentes pruebas.• Incluye ingreso y verificación de datos asistido durante la ejecución de las prue-bas para reducir el error humano.

ConclusiónMás allá de las herramientas, es importante que se entien-da el concepto que está detrás de todo esto. El principal objetivo es lograr que los casos de prueba automatiza-dos, que son la clave del éxito del desarrollo dirigido por pruebas, no partan de una mala interpretación de los requerimientos. El segundo y, no mucho menos impor-tante, es encontrar la manera de que los programadores no dejen de ser productivos por tener que escribir casos de prueba automatizados para cada funcionalidad antes de desarrollar. Este artículo resalta estas dos cuestiones y dando un ejemplo de cómo resolverlas con un par de herramientas en particular. Pero no es necesario que se limiten a éstas. Los invito a que exploren las diferentes herramientas para pruebas automatizadas disponibles en el mercado, y tal como yo lo hice arriben a la solución técnica que más les acomode, sin perder de vista los ob-jetivos propuestos.

15www.softwareguru.com.mx MAY-JUN 2006

Industria Mexicana del SoftwareUn estudio en cifrasPor Dora Luz González

En julio de 2005 se aplicó una encuesta a 68 gerentes de empresas del sector de

la Industria del Software de México para co-nocer el perfil general de éstas y analizar los factores críticos de éxito del sector. Dicha encuesta forma parte de un trabajo de inves-tigación sobre el estudio de estrategias para generar ventajas competitivas en la industria del software, realizado en la Universidad Po-litécnica de Valencia, España, en el programa doctoral “Integración de las Tecnologías de la Información en las Organizaciones”.

Antes de describir el perfil de las empresas desarrolladoras de software en México, es im-

portante destacar que los diversos análisis que hasta la fecha se han realizado con respecto al panorama de este sector no resultan aún ge-neralizables a toda la industria, ya que cada estudio analiza sólo un subconjunto del total de empresas, por lo tanto se hace la aclaración que lo aquí se presenta son datos representa-tivos, y no necesariamente significa que sean generalizables.

Localización Geográfica de las Empresas ParticipantesLas empresas participantes en el estudio se lo-calizan en 11 de los 32 estados de la República Mexicana, presentando la siguiente distribu-

ción: 2.9% Chihuahua, 1.5% en Coahuila, 44.1% en el Distrito Federal, 11.8% en Du-rango, 2.9% en el Estado de México, 1.5% en Guanajuato, 2.9% en Jalisco, 2.9% en Mi-choacán, 2.9% en Morelos, 23.5% en Nuevo León y 2.9% en Querétaro. Esta concentra-ción es similar a la de otros estudios realizados para este sector en México [1, 2].

Número de Empresas Desarrolladoras de Software en MéxicoLa respuesta a esta pregunta no tiene una cifra exacta. De acuerdo con estimaciones realizadas por ESANE consultores [2] sobre del número total de empleados y empresas de la Industria

Dora Luz González Bañales es profesora del Departamento de Sistemas y Computación del Instituto Tecnológico de Durango. Actualmente se encuentra realizando su proyecto de tesis doctoral en la Universidad Politécnica de Valencia (España), en el área de análisis de estrategias competitivas en el sector de la Industria del Software de México. dogonbaa@doctor.upv.es

16 www.softwareguru.com.mxMAY-JUN 2006

del Software en México, el número aproximado de empresas de la industria mexicana del software podría ser del orden de 1,500 empresas.

Tamaño de las EmpresasEl estudio revela que el 85.29% de las empresas del sector de la Industria Mexi-cana del Software son de tamaño micro (54.41%) y pequeño (30.88%), el 5.8% mediana, y tan sólo el 8.82% son de tamaño grande (con un número de empleados mayor a 100).

Tamaño (número de Rango Porcentajeempleados)

Micro 1 a 10 54.41Pequeña 11 a 50 30.88Mediana 51 a 100 5.88Grande + de 101 8.82

Tabla 1. Tamaño de empresas

Número Promedio de Empleados por Tamaño de EmpresaAl analizar el número promedio de empleados por tamaño de empresa, las microempresas presentan un promedio de 6 empleados, las pequeñas 23 y las medianas 76. Para el caso de las empresas grandes, se reflejó un sesgo in-troducido por la presencia en el estudio de una empresa de tamaño grande e intensiva en el número de personal (3,200 empleados), por lo que se estimó un valor medio corregido de empleados cuyo valor fue de 229 empleados.

Antigüedad de las EmpresasLa Industria Mexicana del Software es una industria que se caracteriza por ser joven (47% de las empresas son menores de 7 años). La antigüedad media de las empresas que participaron en el estudio es cercana a los 9 años. Las em-presas más antiguas se encuentran en el mercado desde hace 25 años (creadas partir del año 1980) y las más jóvenes son menores a un año (creadas en el año 2005).

Tomando en cuenta el tiempo de permanencia en el mercado se identificaron tres blo-ques de antigüedad de empresas: emergentes, maduras y consolidadas (ver tabla 2).

Antigüedad Porcentaje

Emergentes 47.1(entre 0 y 7 años) Maduras 42.6(entre 8 y 15 años)Consolidadas 10.3(más de 16 años)

Tabla 2. Antigüedad.

Rango de Ventas AnualesDe acuerdo a los datos obtenidos en la encuesta, la mediana del rango de ventas anuales de las empresas participantes se encuentra entre 3 y 6 millones de pesos mexicanos (Tabla 3).

En miles de Porcentajepesos mexicanos

0 a 50 3.051 a 100 4.5101 a 200 3.0201 a 500 7.6501 a 1,000 12.11001 a 3000 19.73001 a 6000 7.66001 a 12000 16.712001 a 30000 9.130,001 o más 16.7

Tabla 3. Estadísticos descriptivos de rango de

ventas anuales.

Utilidades La mediana del rango de utilidades de las empresas par-ticipantes en el estudio, en los últimos dos años, se en-cuentra entre el 6 y el 10%.

Rango de utilidades Porcentaje

Pérdidas 11.50 al 5% 19.76 al 10% 21.311 al 15% 18.016 al 20% 13.121% o más 16.4

Tabla 4. Estadísticos rango de utilidades en los dos últimos años.

En los tres últimos años el sector de la Industria del Soft-ware de México ha registrado tasas de incremento más ele-vadas que el ritmo de la economía nacional. En el 2004, tuvo un crecimiento del 7%, mientras que en el 2005 este rebasó el 10% (ver “Reportaje”, SG Marzo-Abril 2006).

Crecimiento Laboral. En lo que respecta al análisis de los datos correspondientes al crecimiento laboral, se obtuvo como resultado medio la generación de 3 nuevos empleos por año (recordando que el 85.29% de las empresas de este sector son de tamaño micro y pequeño). El 16.18% de las 68 empresas partici-pantes manifestaron no haber tenido crecimiento laboral,

El 85.29% de las em-presas del sector son micro o pequeñas.

17www.softwareguru.com.mx MAY-JUN 2006

ESPECIAL

un 27.94% un crecimiento negativo (des-pidos), el 52.94% haber tenido un incre-mento en su plantilla laboral hasta de un 8% y un 2.94% indicó tener un crecimien-to laboral superior al 20%.

Analizando el índice de crecimiento laboral en función del tamaño de empresas, el estudio reveló que las empresas que mayor crecimien-to laboral tuvieron fueron las empresas micro (17.65%) y pequeñas (16.47%).

Origen de los Ingresos EconómicosEn lo referente al origen de los ingresos económicos de la empresa, se presenta en primer lugar una predominancia hacia el desarrollo de software hecho a la medida (40.44%), en segundo lugar están el desa-rrollo de software empaquetado (16.85%) y las actividades de consultoría (14.65%). Las actividades reportadas como “otras” se refieren básicamente a venta, renta y man-tenimiento de hardware.

¿Y los sueldos?En la tabla 5 se muestran los salarios mensua-les medios de un programador —en categoría: Software Engineer / Developer / Program-mer— para varios países donde se puede ob-servar una gran variación en los niveles de remuneración de esta actividad, desde un sa-lario mensual medio de USD $283 en Filipi-nas, hasta un salario mensual medio de USD $5,480 en Suiza, y para el caso de México es de USD $1,865.

¿Qué Tipo de Mercado se Cubre?Del análisis correspondiente al mercado que cubren las empresas del sector, 54.78% in-dicó que cubre mercados locales, 11.86% mercados regionales, 26.24% tiene cober-tura nacional y 7.12% indica tener presen-cia internacional.

Agrupando por el tamaño de empresa y por la composición de mercado que se cubre, se observa que la predominancia a cubrir mer-cados locales puede deberse en parte, a que la mayoría de las empresas participantes se concentran en empresas de tamaño micro, pequeña y mediana (91.17%)

¿Y la Orientación Estratégica?Para la selección de las variables que sirvie-ran como base para identificar y clasificar a los grupos con base a su orientación estra-tégica de negocio (costo y diferenciación),

se tomaron en cuenta las consideraciones teóricas de: Michael Porter, Gerry John-son y Arthur Thomson. Para la muestra del estudio, las variables consideradas para el análisis orientación estratégica fueron: porcentaje de gasto en diseño de nuevos productos, porcentaje de gastos en mejoras en procesos, número de patentes, personal dedicado a actividades de investigación y desarrollo, porcentaje de ventas dedicado a marketing y porcentaje de productos o ser-vicios especializados.

Como resultado final para la clasificación de las empresas en función de su orientación es-tratégica se identificaron dos grupos: uno con 30 empresas para el grupo de estrategia por costos, y otro con 38 empresas para el grupo de estrategia por diferenciación (se aplicó la técnica estadística de análisis cluster).

ConclusiónEn este escrito se ha presentado información obtenida a través de un estudio exploratorio aplicado al sector de la Industria del Software de México en Julio de 2005. Se han presentan-do los datos más significativos de este sector como lo son: antigüedad, ventas, promedio de utilidades, tamaño de empresa, orientación de negocio, generación de nuevos empleos, nivel de sueldos, mercado que se cubre y el origen de los ingresos económicos. Se espera que los datos aquí vertidos puedan servir como marco de referencia e información para todas aque-llas personas, empresas e instituciones públi-cas y privadas que estén inmersas o tengan un interés particular en este sector.

Agradecimiento especial a cada uno de los 68 gerentes de las empresas participantes en el estudio, a los representantes de PRO-SOFT, AMITI y AMCIS.

Referencias1. SE (2004), “Estudio del nivel de madu-rez y capacidad de procesos de la industria de tecnologías de información en el área metropolitana de Monterrey, Nuevo León y el Distrito Federal y su área metropoli-tana” Secretaría de Economía del Gobierno Mexicano.2. ESANE, Consultores S. C. y Secretaría de Economía, México (2004), “Perfil de la Industria Mexicana del Software y Servi-cios Relacionados” Secretaría de Economía, México,Fase 1 / Criterio 2.

Tabla 5. Comparativa del salario mensual medio de

un programador de software en varios países.

País Salario mensual (2005) promedio en USDFilipinas $283Turquía $438Tailandia $510India $570Colombia $875China $899Brasil $933Emiratos Árabes Unidos $1,508Sudáfrica $1,558Singapur $1,616México $1,865Corea $2,183España $2,480Bélgica $2,714Nueva Zelanda $2,743Australia $3,159Canadá $3,166Japón $3,166Israel $3,333Suecia $3,408Finlandia $3,417Holanda $3,483Francia $3,532Irlanda $3,532Reino Unido $4,117Noruega $4,178Estados Unidos $4,416Alemania $4,634Hong Kong $5,055Suiza $5,480

La mediana del rango de utilidades para las em-presas de este sector en los últimos dos años se encuentra entre el 6 y el 10%

18 www.softwareguru.com.mxMAY-JUN 2006

MAY-JUN 2006MAY-JUN 2006

ENTREVISTA

¿Qué hace el CIMAT?El CIMAT tiene tres objetivos: investigación, formación de recursos humanos y vinculación con empresas. En el caso de la vinculación, el CIMAT provee asesoría a organizaciones que estén interesadas en conocer sobre algún as-pecto de ingeniería de software, o que requie-ran de capacidades especiales. Debo recalcar que el objetivo del CIMAT no es vender servi-cios y competir con empresas proveedoras de servicios y consultoría en ingeniería de soft-ware. En cambio, el papel del CIMAT es apoyar al desarrollo de éstas. Por ejemplo, formar un Lead Appraiser de CMMI es muy caro y la mayoría de las empresas nacionales no puede costearlo. Así que lo que hicimos es nosotros generar a un Lead Appraiser mexicano (Miguel Serrano), y entonces que él empiece a hacer evaluaciones integrando a otros evaluadores mexicanos, que así desarrollarán experiencia e irán reuniendo los requisitos para ellos mis-mos convertirse en Lead Appraisers.

¿Cómo es diferente el rol de un académico en México comparado con otros países?Siento que el modelo en México no facilita mucho las cosas para los académicos. Por ejemplo, en otros países, como EUA, los aca-démicos pueden combinar un poco más la in-vestigación con la vinculación con empresas. En México, la única forma de que te vaya bien como académico, es que pertenezcas al Siste-ma Nacional de Investigadores (SNI). Y al SNI lo único que le importa son las publicaciones, lo demás no cuenta. Siento que este modelo aprisiona un poco al académico en México.

¿Qué es ingeniería de software?La definición de la IEEE tiene que ver con apli-car técnicas de ingeniería al desarrollo de soft-ware. A mi me gusta la forma en como Parnas la explica, que es “todo lo que tenga que ver con realizar proyectos de software grandes y con mucha gente”. Es una definición simplis-ta pero siento que captura el feeling. A fin de cuentas, la gente es lo que le da sabor a la in-geniería de software. Mucha gente en el ám-

bito científico cree que hacer investigación en ingeniería de software es hacer fórmulas para reuso, o fórmulas para demostrar la validez de un algoritmo; pero no. La mayoría de los problemas en el desarrollo de software son problemas relacionados con la gente.

Esto es muy importante en nuestro país, por-que si queremos detonar la industria de soft-ware, debemos desarrollar a la gente, a los profesionistas de software. Y éstos no nece-sitan nada más saber programar; necesitan muchos otros conocimientos y habilidades. Si analizas las áreas de conocimiento del cuerpo de conocimiento de ingeniería de software (SWEBoK), te das cuenta que no hay ninguna universidad en México que lo cubra todo, ni profesores para poder impartirlo. Así que ne-cesitamos desarrollar la capacidad para gene-rar ingenieros de software que cuenten con los conocimientos técnicos necesarios, pero tam-bién con habilidades interpersonales como liderazgo, comunicación, ética.

¿Qué tanto afectan los rasgos socioculturales en la forma de desarrollar software?Tienen cierta influencia, pero nada que no se pueda cambiar. Como mexicanos tenemos nuestra forma de hacer las cosas. Por un lado, somos muy creativos y muy trabajado-res, pero por otro tendemos a ser indisciplina-dos. Sin embargo, esto se puede revertir por medio de educación. Somos indisciplinados porque no nos han enseñado la ventaja de la ingeniería. Por ejemplo, a nuestros alumnos de la maestría en ingeniería de software les enseñamos a aplicar técnicas de PSP, y cuan-do salen de la maestría nos dicen “somos gente diferente, yo ya no regreso a hacer el software como lo hacía antes”. Una vez que palpan el beneficio de hacer las cosas bien, la gente sale cambiada y con un gran ímpetu de cambiar el mundo. Es muy emotivo ver a los recién egresados que dicen “es que esto lo tiene que saber todo el mundo”. Tenemos el reto de generar una masa crítica de gente con esta concepción del desarrollo de software.

Ya mencionaste cómo podemos cambiar la mentalidad de los profesionistas, pero, ¿qué hacemos con los directivos?Los directivos necesitan ver que la ingenie-ría y la calidad en el software reditúan en dinero. Para lograr esto debemos recabar in-formación de proyectos, y entonces es muy sencillo mostrar el retorno de inversión de hacer las cosas bien.

También tenemos el problema de que los di-rectivos en México están acostumbrados a una forma de dirigir de “látigo” o capataz. No con-fiamos en que nuestros ingenieros tengan la capacidad de proveer resultados de forma au-tónoma. Y probablemente esto sea cierto (que en general no se tenga esa capacidad), por eso es necesario generar esa masa crítica de bue-nos y verdaderos ingenieros de software.

¿Qué crees que debería saber un recién gra-duado de nivel licenciatura?Si pretendemos competir con la India, debe-ría salir sabiendo todo lo que dice el SWEBoK y dominar alguna plataforma. En otros países, estos conocimientos se adquieren hasta que los profesionistas están en las empresas. Por ejemplo, las empresas en India dedican en promedio 10% de sus ingresos a la capacita-ción. Esto es algo que no podemos hacer en México, dado que la industria no puede so-portarlo. Así que los egresados deben salir listos para ser productivos en la industria.

¿Crees que la academia en México está hacien-do su trabajo?Creo que se está quedando corta. Tiene que ver con muchos factores. Por un lado, no hay buenos profesores porque no son bien pagados. Por otro, la academia está muy desconectada de la industria. Es fun-damental que los profesores participen en proyectos de la industria, y que los alum-nos tengan prácticas profesionales. ¿Tú te imaginas que una persona que jamás ha agarrado un bisturí en su vida, enseñara a sus alumnos cómo hacer una cirugía? Se-

Dr. Carlos Montes de OcaCentro de Investigación en Matemáticas (CIMAT)

Como sabemos, la academia juega un rol fundamental en el desarrollo de la industria de software. Una de las instituciones académicas de mayor prestigio y especialización en ingeniería de software es el CIMAT, en Guanajuato. Carlos Montes de Oca es uno de los gurús en el Departamento de Ciencias Computacionales del CIMAT, y en esta ocasión comparte con nosotros su visión sobre la ingeniería de software, la importancia de ésta, y los retos que enfrenta la academia en el desarrollo de la industria de software en México.

20 www.softwareguru.com.mxMAY-JUN 2006

ría terrible. Pero esto es lo que estamos haciendo. Ahora, ¿tú concibes una carrera de medicina sin un hospital al lado? Pues no, ¿verdad? En el software debería de ser igual. Las escuelas de ingeniería de soft-ware deberían tener al lado una fábrica de software o algo donde los alumnos pue-dan participar en proyectos reales. Porque la ingeniería de software es especial y re-quiere de práctica y tutelaje.

¿Realmente hay una oportunidad para México en la industria de software mundial?La verdad, yo creo que la oportunidad gran-de ya se nos pasó. Si las cosas estaban difí-ciles con India, con China va a estar mucho peor. Son muchísimos, tienen tarifas mucho menores, y la India les está transfiriendo todo el conocimiento en calidad.

México sigue teniendo la buena oportunidad de que está pegado a Estados Unidos. Ese es el nicho que nos queda, pero tenemos que aprovecharlo y ponernos las pilas, porque hasta ése se nos puede ir. Para desarrollar buenos profesionistas, necesitamos un ciclo de cuatro años, y todavía no lo empezamos. Así que de aquí a cuatro años, no vamos a estar listos. Necesitamos apurarnos.

¿Alguna recomendación para los lectores de SG?Primero, que conozcan y apliquen las técni-cas de ingeniería de software. Segundo, que se metan de lleno en procesos y calidad. Cuando nos caiga el veinte que la forma más eficiente y efectiva de hacer las cosas es hacerlas bien la primera vez, le vamos a dar un gran giro a la industria. Por último, que entiendan la importancia de la gente. Con este fin voy a hacer una última analo-gía: el dueño de una fábrica de coches sale a las 6 de la tarde, y ahí tiene su fábrica, con su valor intacto; puede venderla y recuperar su inversión. En cambio, el dueño de una fá-brica de software, a las 8 de la noche que sus empleados ya se fueron a su casa, está descapitalizado. Lo único que tiene son es-critorios y unas máquinas depreciadas.

Como industria, debemos reconocer que estamos hechos de personas, y que éstas son nuestro principal activo. Así que debe-mos tenerlas bien “aceitadas” (a través de capacitación y motivación) para obtener su máximo rendimiento.

21www.softwareguru.com.mx MAY-JUN 2006

EN PORTADA

Las necesidades de un cliente pueden sufrir cambios importantes del momento de contra-tación de un proyecto de software, al momen-to de su entrega; y es mucho más importante satisfacer estas últimas que las primeras. Esto requiere procesos de software diferentes, que en lugar de rechazar los cambios, sean capaces de incorporarlos. Dichos procesos también de-ben:• Producir versiones ejecutables del software en pocas semanas, con el fin de quedar bien con el cliente y obtener retroalimentación en cuanto al producto.• Inventar soluciones sencillas, de tal forma que el impacto de los cambios se minimice.• Mejorar la calidad del diseño de manera continua, haciendo que la siguiente iteración requiera menos esfuerzo que la actual.

• Probar desde temprano y de manera conti-nua, para encontrar defectos antes de que ten-gan un alto impacto.En los últimos años hemos visto surgir métodos que capturan y fomentan dichas prácticas, y en su conjunto son conocidos como métodos “Ági-les”. Algunos de estos cuentan con más de una década de existencia. Sin embargo, fue en el año 2001, cuando varios de sus creadores se reunie-ron para formar la “Alianza Ágil” y dar a conocer el “Manifiesto Ágil”, que define los valores en que se basan dichos métodos:• Individuos e interacciones por encima de procesos y herramientas.• Software funcional por encima de documen-tación abundante.• Colaboración con los clientes por encima de negociación de contratos.

• Respuesta al cambio por encima de segui-miento a planes.

De acuerdo con Jim Highsmith y Alistair Cockburn, ambos miembros fundadores de dicha alianza, lo nuevo de estos métodos no son las prácticas que utilizan, sino su recono-cimiento de la gente como principal factor de éxito de los proyectos. Adicionalmente, Cockburn define estos métodos como el uso de reglas “ligeras pero suficientes” y la aplica-ción de técnicas orientadas a las personas y su comunicación.

En las páginas siguientes conoceremos más sobre los métodos ágiles y su aplicación, y aprenderemos a distinguir entre los mitos y realidades asociados a estos.

Sin duda alguna, ser “ágil” es lo de hoy. Con esto, nos referimos a la capacidad para proveer respuestas rápidas y ser adaptables al cambio. Ambas cualidades siempre habían sido deseables, pero en el entorno de negocios actual son indispensables. Este requerimiento de agilidad en las empresas, gobiernos, y cualquier otra organización, provoca que el software (que a fin de cuentas es el motor del mundo actual) también deba ser desarrollado de manera ágil.

22 www.softwareguru.com.mxMAY-JUN 2006

eXtreme Programming (XP)www.extremeprogramming.orgXP es probablemente el método ágil que más atención ha recibido desde que fue dado a co-nocer en 1999 a través del libro “Extreme Pro-gramming Explained” de Kent Beck. XP está formado por valores, principios y prácticas. Las prácticas son actividades concretas que un equipo puede realizar día a día, mientras que los valores representan el conocimiento fun-damental que sustenta dichas prácticas. Tanto los valores como las prácticas son necesarios, pero hay un gran espacio entre ambos. Esta brecha es cubierta por los principios. La edi-ción actual de XP (2004) define cinco valores, catorce principios, trece prácticas primarias y once prácticas adicionales.

Los cinco valores son:• Comunicación. La comunicación entre miembros del equipo y con clientes, se debe maximizar.• Simplicidad. Usar la solución más sencilla que pueda funcionar.• Retroalimentación. Siempre debe ser posi-ble medir el producto que se está desarrollan-do, y conocer qué le falta para satisfacer los requerimientos.• Coraje. Es necesario armarse de valor para incorporar cambios durante un proyecto. El coraje por sí sólo es peligroso, pero sustentado con comunicación, simplicidad y retroalimen-tación, es una herramienta poderosa.• Respeto. Los valores anteriores implican res-peto. Ninguna metodología puede funcionar mientras los miembros del equipo no se tengan respeto entre sí, ni al trabajo que realizan.

Entre las prácticas más significativas de XP están el diseño incremental, programación en pares (dos personas en una computadora), in-

tegración continua (cada dos horas), y test-first programming (antes de desarrollar código nue-vo, debes crear las pruebas que van a verificar este código).

Scrumwww.controlchaos.com Scrum fue desarrollado durante los ochentas y noventas por Ken Schwaber, Jeff Suther-land y Mike Beedle. Este método se concen-tra en la administración de los proyectos de software, dividiendo el desarrollo en itera-ciones de 30 días (denominadas “sprints”), y monitoreando/controlando el proyecto a través de juntas diarias. De hecho, “scrum” se refiere a la jugada en el rugby donde los jugadores trabajan en equipo para obtener posesión del balón.

Scrum aplica ideas de la teoría de control de procesos industriales con el objetivo de lograr adaptabilidad y productividad. Scrum no de-fine actividades ni técnicas específicas para la construcción de software. En cambio, se con-centra en las reglas de funcionamiento de un equipo de trabajo para poder producir siste-mas flexibles en un ambiente de cambios.

Dado que Scrum hace poco énfasis en las acti-vidades de ingeniería, es común complemen-tarlo con otros métodos fuertes en cuanto a prácticas de ingeniería, como lo es XP.

CrystalCrystal es una familia de métodos que com-parten principios en común. Estos princi-pios comunes, o “código genético” (como lo llama su creador Alistair Cockburn), se enfocan en las entregas frecuentes, la comu-nicación cercana y la mejora a través de la reflexión. Existen diferentes métodos Crystal

para diferentes tipos de proyectos, y las or-ganizaciones pueden personalizar un proceso específico para cada proyecto.

El nombre Crystal surge de la caracterización de los proyectos de software de acuerdo a su tamaño e importancia (criticality) del producto a desarrollar, de la misma forma que los crista-les son caracterizados por su color y dureza. El tamaño del proyecto indica el método a utili-zar —Crystal Clear es para equipos pequeños (menos de 8 personas), seguido por Yellow (10 a 20), Orange (20 a 50), y así sucesivamente hasta Violet—, mientras que la importancia in-dica la dureza con que se debe aplicar, esta va de cuarzo (quartz) hasta diamante (diamond).

Las prioridades que comparten todos los mé-todos de Crystal son:• Seguridad en el desenlace del proyecto.• Eficiencia en el desarrollo.• Habitabilidad de las reglas (el equipo se siente cómodo con ellas).

El énfasis de las metodologías Crystal está en la comunicación y la cooperación entre las personas. De hecho, a diferencia de otros métodos que se centran en arquitectura, pro-cesos, o incluso herramientas, podríamos de-cir que Crystal está “centrado en personas” (people-centric).

A pesar de su popularidad, no existe un sitio web que sirva como punto central para co-nocer más sobre Crystal. El sitio de Alistair Cockburn (alistair.cockburn.us) contiene re-ferencias a algunos sitios y artículos, sin em-bargo la mejor fuente de conocimiento sobre Crystal es el libro titulado Crystal Clear, es-crito por Cockburn y publicado por Addison Wesley en 2004.

Diferentes Sabores para Distintas NecesidadesExiste una gran variedad de métodos ágiles. Aunque todos se basan en el manifiesto ágil y sus principios, cada uno cuenta con enfoques y prácticas particulares. Este artículo brinda un panorama sobre algunos de los métodos más significativos.

Ninguna metodología puede funcionar mien-tras los miembros del equipo no se tengan respeto entre sí, ni al trabajo que realizan.

23www.softwareguru.com.mx MAY-JUN 2006

ScrumCaos ControladoPor Luis Guerrero

Scrum es un proceso ágil de administración de proyectos. Por su naturaleza es iterativo y pretende tener un producto listo al final de cada iteración. Toma su nombre de una jugada de rugby, y que Ken Schwaber, uno de los padres del método, describe como “caos controlado”.

Luis Guerrero es Arquitecto de Sistemas en el Sistema de Administración Tributario (SAT). Sus áreas de especialidad son procesos, ingeniería de software, seguri-dad y métodos ágiles. Durante su trayectoria profesional ha trabajado en México, las Antillas y Centroamérica, en proyectos empresariales y para el gobierno federal.

HistoriaEn 1995, Ken Schwaber, un metodólogo de software reconocido, decidió descubrir por-qué las metodologías de desarrollo funciona-ban tan mal cuando se intentaban seguir al pie de la letra. Con este fin, reunió a varios ex-pertos de teoría de procesos de DuPont, y les presentó diversas metodologías. La respuesta de los expertos fue reveladora e inesperada. La industria de desarrollo de sistemas está usando el modelo de control de procesos equivocado. Existen dos aproximaciones al control de pro-cesos: • El proceso definido, en el que todos los ele-mentos y componentes son bien conocidos y controlados. Dado un conjunto de entradas, se obtiene un conjunto de salidas igual y con-sistente siempre.• El proceso empírico, por otro lado, espera lo in-esperado. Como no se conoce el proceso con su-ficiente detalle, y producen resultados inesperados e irrepetibles, la única manera de controlarlos es a través de inspecciones constantes y minúsculas correcciones aplicadas con frecuencia.

El desarrollo de software, siendo una activi-dad tan profundamente intelectual, y que necesita tanta creatividad, es un mal candida-to al proceso definido. El desarrollo de soft-ware, entonces, no debería entenderse como una línea de montaje, sino como una serie de inspecciones constantes acompañadas de co-rrecciones inmediatas. Schwaber llama a esta forma de trabajar el proceso caórdico, y nota que espontáneamente, los equipos de trabajo se coordinan con muy poca intervención de entidades externas. Schwaber llama a este pro-ceso la auto-organización

Roles de ScrumHay cuatro roles para los participantes de un proyecto que se administre con scrum:• Dueño del producto. Es quien determina las prioridades. Debe ser una sola persona.• Dueño del scrum. Administra y facilita la

ejecución del proceso.• Equipo de trabajo. Son los encargados de entregar resultados al final del sprint.• Interesados. Asesoran y observan el proceso. Tienen interés en el resultado final.

El ScrumEl método es iterativo en su naturaleza. Cada iteración, o sprint, dura un mes calendario. Este inicia con una reunión entre el equipo de tra-bajo, el dueño del scrum (scrum-master) y los patrocinadores del proyecto. En esta reunión, los patrocinadores exponen y aclaran los reque-rimientos del proyecto, y también se encargan de priorizarlos. Este es el alcance acumulado del producto (product backlog). Posteriormente el equipo de trabajo decide qué funcionalidad pue-de entregar al final del sprint – el alcance acumu-lado del sprint (sprint backlog).

Es de gran importancia que los patrocinadores del proyecto respeten el alcance, y no alteren o interfieran con el equipo de trabajo durante el sprint. Aquí se hace una estimación inicial del trabajo necesario para entregar la pila del sprint. También es indispensable no violar el principio ágil de trabajar únicamente 40 horas a la sema-na. Después de esta reunión, el equipo es libre de organizarse como considere conveniente. Cada día, el equipo de trabajo se reúne con el dueño del scrum en la junta scrum.

La Junta ScrumLa junta scrum debe ser breve, no más de 15 minutos al día. Si no se puede mantener en esos niveles, entonces hay muchas personas. Será necesario identificar quién debe partici-par en esa reunión. En esta reunión, se le toma el pulso diario al proyecto. El dueño del scrum detecta qué problemas existen, y busca quitar-los de en medio, fungiendo como un facilita-dor más que como un líder de proyecto.

El objetivo principal de la junta scrum es que los participantes del sprint hablen entre ellos

y descubran qué necesidades tienen, las re-suelvan en el momento, y si no es posible, buscar los foros adecuados posteriormente. En esta reunión se hacen estimaciones del trabajo restante de cada participante. Estas estimaciones se recogen y tabulan en las grá-ficas de consumo. Estas gráficas deben mos-trar que el trabajo pendiente para entregar la funcionalidad acordada debe disminuir con el paso del tiempo, de otra manera, lo que demuestran es que el equipo fue demasiado optimista y ahora se está enfrentando con la realidad. El maestro del scrum puede tomar la decisión de acordar una disminución del alcance con el dueño del producto, o infor-marle con tiempo que no se va a lograr la meta, pero que es lo que sí es realmente fac-tible. En el caso remoto de que los resultados sean de verdad terribles, es posible cancelar todo el sprint.

SashimiEl sashimi es un plato japonés en el que se presentan finas rodajas de pescado apoyadas parcialmente sobre la anterior. En el contexto de scrum, y de los métodos ágiles en general, cada rebanada se entiende como un pedaci-to del todo que está listo para consumirse en cualquier momento. Cuando se planean las ac-tividades del scrum, los productos resultantes deben estar listos para consumo del usuario. Eso quiere decir que no sólo debemos contar con el sistema de software. También debe estar lista la documentación, el instalador, y el ma-nual de usuario, por ejemplo.

La PresentaciónAl final del sprint se hace una presentación con el dueño del producto. En esta reunión se evalúa el resultado del sprint, y se revisa el alcance acumulado del producto, y con base al producto que el usuario final tiene ahora, se revaloran los requerimientos, para escoger un nuevo alcance para el próximo sprint. Es im-portante que el producto final del sprint tenga

EN PORTADA

24 www.softwareguru.com.mxMAY-JUN 2006

MAY-JUN 2006

la calidad necesaria para que el cliente pueda usarlo por sí mismo. Esto le permitirá tener un mejor entendimiento sobre a dónde quiere dirigir el desarrollo de su producto. Además de que le permitirá ver un progreso real sobre su proyecto, en un corto tiempo. Idealmente, la reunión de presentación al final del sprint debiera fungir como la junta de planeación del próximo sprint.

Pero... ¿En Realidad Funciona?La premisa básica de scrum, y en gran medida de los métodos ágiles, es que si el colaborador está comprometido con el equipo de trabajo, y el jefe confía en ellos, entonces el equipo invierte el tiempo en producir algo, en lugar de estar justificando el avance o falta del mis-mo. Esto reduce la necesidad de reuniones y reportes de situación. Básicamente, se parece mucho a las tareas universitarias, en las que el profesor dice qué hay que hacer y cuando hay que entregarlo. Al principio, todos los involucrados, y en especial el equipo de tra-bajo, se sentirán extraños, pues no hay una estructura centralizada de control. Pero en el momento en que el equipo se organiza, la falta de control central se vuelve la principal ventaja del método.

Es muy difícil otorgarle al equipo de trabajo el control que requiere scrum. La técnica es aven-turada, y existe un riesgo de toparse con límites reales, que puedan llegar a cancelar el proyecto. Una falla puede tener mucho impacto en los miembros del equipo de trabajo por los niveles de envolvimiento personal con el proyecto.

Lo Que No FuncionaA continuación comparto una lista de las trampas más comunes de una implementa-ción primeriza de scrum en una organización con métodos tradicionales, y que en mi ex-periencia son señales claras de que no se está trabajando de acuerdo al principio inicial de scrum de autorregulación.• La junta scrum no es un reporte de avan-ce. Los participantes del equipo deben ver la junta scrum como una oportunidad para re-solver sus problemas inmediatos. Una clara señal de que las juntas no están funcionan-do como deberían es que los integrantes del equipo miran al dueño del scrum y le relatan sus actividades, como en un reporte de situa-ción, en lugar de hablar entre ellos o solicitar la intervención del dueño del scrum en algún asunto relacionado con las áreas periféricas de la organización.

• No se contemplan todas las actividades ne-cesarias en el sprint. Esto es, se viola el principio del sashimi, siempre tener un producto entrega-ble para el usuario final. Es muy común que en los primeros sprints se olviden algunas activi-dades, típicamente las que se podrían clasificar de poco ágiles o poco sexy, como mantener los documentos o los manuales de usuario. Es nor-mal, pero también es importante que se corrija el rumbo una vez detectado esto. Una actividad no puede considerarse completa sin estos productos adicionales. El dueño del scrum debiera desin-centivar que un miembro del equipo cambie de actividad antes de terminarla por completo.• Interferir con el equipo de trabajo durante el scrum. Es muy tentador para el dueño del producto acercarse al equipo para solicitar un pequeño cambio. Y es también muy fácil para el equipo aceptarlo – al fin y al cabo, estamos siendo ágiles, ¿o no? El dueño del scrum debe combatir estas intervenciones para mantener al equipo centrado en entregar la funcionali-dad en tiempo y en forma.

Referencias• www.controlchaos.com • Ken Schwaber. Agile Project Management with Scrum. 2004, Microsoft Press

Cada sprint dura un mes y se

cierra con una presentación

25www.softwareguru.com.mx MAY-JUN 2006

EN PORTADA

John Gómez es PMP y se desempeña como Consultor Senior para mejora de procesos en Practia Consulting Chile. Tiene más de 15 años de experiencia en proyectos de desarrollo de software asumiendo roles de programador, diseñador, arquitecto y jefe de proyecto. Desde el año 2002 colabora con la implementación de prácticas ágiles en proyectos de desarrollo y ha dirigido proyectos de mejora basados únicamente en metodologías ágiles. John ha sido relator de charlas sobre metodologías ágiles en varias oportunidades incluyendo las ediciones de SEPG LA de 2005 y 2006.

Mitos y RealidadesConociendo los ExtremosPor John Gomez

Si bien las metodologías ágiles ve-nían gestándose y aplicándose des-de los años noventa, la formación de la Alianza Ágil y subsiguiente publicación del Manifiesto para Desarrollo de Software Ágil en fe-brero del 2001, marcaron una in-flexión en el uso de procesos para desarrollo de software desatando una fuerte polémica entre promo-tores y detractores de lo “ágil”.

Las malas interpretaciones de uno y otro lado marcaron el tono de la discusión que cada vez se hizo más radical. Sería pretencioso querer resol-ver en este artículo toda esta polémica; el objetivo es ilustrar algunos de los principales puntos en disputa, aclarando los conceptos erróneamente interpretados sin tomar partido por ninguno de los dos bandos.

26 www.softwareguru.com.mxMAY-JUN 2006

Ni “Silver Bullet” ni “Licencia para Hackear”Kent Beck, creador de Extreme Programming (XP), comenta que tuvo esta conversación con un practicante:Agradecido practicante: Sr. Beck, tengo que agra-decerle, XP nos cambió la vida, sin embargo, ahora tenemos algunos problemas con el testing.Kent Beck: Muchas gracias. ¿Quiere decir que no lo-gran codificar las pruebas antes de los programas?AP: Bueno, en realidad no codificamos pruebas...KB: Entiendo, ¿entonces logran realizar integración frecuente generando una nueva versión funcional al menos una vez al día?AP: Mmm, en realidad no...KB: ¿Pero funcionan la programación en pares, las historias de usuario o el refactoring?AP: Mmm, no...KB: Entonces, ¿cómo es que hacen XP?AP: Ah, bueno, dejamos de documentar...

Beck ejemplificaba de esta forma exagerada lo que estaba dándose en la realidad: las nuevas metodologías fueron acogidas por muchos practicantes con gran entusiasmo y poco crite-rio. Además, a partir de un par de experiencias exitosas muchos se dedicaron a criticar con desprecio la llamada ingeniería “tradicional”.

Del otro bando también surgieron posiciones radicales. Steven Rakitin envió a los editores de IEEE Computer una carta con la siguiente interpretación escéptica del Manifiesto:• Individuos y sus interacciones sobre pro-cesos y herramientas. Traducción: hablar con la gente nos da la flexibilidad de hacer lo que nosotros queramos de la forma en que queramos. Por supuesto, se da por sentado que nosotros sabe-mos lo que usted quiere, incluso si usted no”.• Software funcional sobre documentación exhaustiva. Traducción: queremos pasar todo el tiempo codificando. ¡Los verdaderos progra-madores no escriben documentos!• Colaboración con el cliente sobre negociación de contratos. Traducción: “no per-damos tiempo discutiendo detalles, eso limita nues-tra capacidad de pasar todo el tiempo codificando. Ya veremos qué pasa cuando entreguemos algo”.• Responder al cambio sobre seguimiento de un plan. Traducción: “seguir un plan significa que deebemos pensar en el problema y cómo vamos realmente a resolverlo. ¿Por qué gastar tiempo en eso cuando podríamos estar codificando?”.

Estos extremos reflejan lo álgido de la discu-sión. Para algunos las metodologías ágiles eran la nueva “bala de plata” que venía a triunfar donde la ingeniería “tradicional” había fraca-sado. Para otros, las metodologías ágiles eran sólo una excusa para desarrollar software sin planes, diseño ni documentación. Ambos

extremos son erróneos; por una parte, varias prácticas ágiles tienen nichos donde fun-cionan muy bien, pero hay otros ambientes donde pierden su efectividad o deben ser mo-dificadas para lograr el objetivo. Sólo hay que imaginar realizar la reunión diaria de segui-miento que propone SCRUM, XP o Crystal en un proyecto con cincuenta personas.

Tampoco es correcto que lo ágil se contra-ponga a la ingeniería de software. De hecho, muchas prácticas ágiles vienen de estudios realizados desde antes de la década de los se-sentas. Varios de los autores de estas metodo-logías vienen de la comunidad de desarrollo orientado a objetos, donde se gestaron varios de los avances más importantes en arquitec-tura y diseño de software. Este y otros puntos se tocarán en mayor detalle empezando por uno de los más discutidos: el ciclo de vida de desarrollo.

El Mito de la CascadaDespués de conocer tantos equipos de pro-yecto aún me asombra como para muchos el único ciclo de vida conocido es el de cascada, donde se ejecutan secuencialmente las activi-dades de análisis, diseño, construcción, etc.

RUP y las metodologías ágiles han contribuido a generar más visibilidad sobre los ciclos de vida iterativos e incrementales, pero se han dado algunas confusiones. Primero, erróneamente muchos practicantes de las metodologías ági-les creen que los ciclos de vida incrementales son exclusivos de estas o que son propuestos por ellas. Esto dista mucho de la realidad: hay evidencias de la definición y uso de ciclos de vida incrementales incluso en los años cincuen-ta. Un ejemplo es el ciclo de vida evolutivo en espiral de Boehm [Boehm86].

Otro gran error cometido tanto por agilistas como por tradicionalistas, es asumir que el ciclo de vida en cascada es absolutamente se-cuencial. He conocido ingenieros que están convencidos de que es posible realizar todo el trabajo de requerimientos antes de iniciar el diseño de modo que dicha etapa se “cierre” y no haya necesidad de volver atrás. Creer en esto es negar que se vayan a presentar cam-bios a los requerimientos en etapas posterio-res del desarrollo lo cual es querer tapar el sol con las manos.

El ciclo de vida en cascada secuencial data de 1957 [Benington57], sin embargo el ciclo de vida en cascada conocido hoy es la versión de Royce [Royce70]. En esta propuesta, el ciclo de vida en cascada tiene una visión incremental, reconocien-do que el cambio es innegable y que por lo tanto

siempre habrá que volver atrás para refinar sucesi-vamente los resultados de cada etapa de acuerdo con los cambios que se presentan.

La elección del ciclo de vida debe realizarse según las condiciones del proyecto. ¿Qué tan práctico es planear iteraciones para un mante-nimiento donde trabajan dos personas por un par de días? También pasa que es mucho más sencillo planificar un proyecto con ciclo de vida en cascada; además, los procesos de ges-tión de configuración e integración deben ser mucho más rigurosos en el desarrollo incre-mental. Por otro lado, sería suicida proponer un desarrollo en cascada en un proyecto con alta incertidumbre donde los requerimientos son vagos o muy susceptibles de cambio.

En resumen, ni cascada significa fracaso o ar-caísmo, ni incremental significa éxito o ágil, cada equipo debe decidir cuál es el ciclo más conveniente para su proyecto. Ingeniería vs. AgilidadLa rigurosidad y disciplina en las prácticas de ingeniería también se ha discutido mucho. El discurso de los “agilistas” de erradicar el ciclo en cascada y por lo tanto las grandes etapas de análisis y diseño antes de construir cualquier parte del producto ha llevado a la mala inter-pretación de que en las metodologías ágiles se desincentivan las prácticas de ingeniería de software. Esto se complementa con la aparen-temente declarada aversión a la documenta-ción presente en las metodologías ágiles.

En realidad las metodologías ágiles proponen reducir las actividades tipo “big up-front”. Por ejemplo, cuando el equipo tiene que dedicarse días enteros a actividades de diseño antes de codificar. En cambio se propone que el diseño sea una actividad permanente cuyos resulta-dos se validan continuamente a la luz de lo construido. Según esto, el equipo dedica dia-riamente una parte de su tiempo a actividades de diseño, el cual evoluciona en paralelo con la construcción. Esto se complementa con otras prácticas: la integración frecuente presente en la mayoría de las metodologías ágiles sólo pue-de sostenerse con el respaldo de un adecuado trabajo de diseño.

Otro tema es la documentación. Muchos practicantes de los métodos tradicionales han implementado sus procesos con dependencia extrema de los documentos. Malas interpreta-ciones han llevado a que una compañía tenga un estándar de plan de proyecto de 20 sec-ciones y 40 páginas y lo exija para todos sus proyectos sin importar si uno es de 60 horas hombre y otro de 6000.

27www.softwareguru.com.mx MAY-JUN 2006

También he visto como compañías exigen a sus equipos documentar el diseño usando TODOS los diagramas de UML, sin distin-ción de cuáles son realmente útiles para cada proyecto o situación.

El otro extremo también se presenta debido a una mala interpretación. Críticos de las metodologías ágiles y muchos de sus practicantes han creído que no hay valor en documentar. Si bien varios autores han asumido posiciones relativamente ex-tremas sobre el asunto, en general hay consenso en que cada equipo debe determinar la cantidad y forma de documentación requerida, sea que se use el generador de reportes de la herramienta de modelado, o una foto de la pizarra de la sesión de diseño. Además, deben tomarse en cuenta los requerimientos del cliente y condiciones debidas a regulaciones o estándares. Cumplir con los re-querimientos de documentación no significa que el equipo deje de ser “ágil”.

Finalmente, la documentación no reemplaza la comunicación. Más de una vez he visto como la información de requerimientos se comparte en un equipo enviando el documento de casos de uso por e-mail: ¿es posible que se logre en-tendimiento de esta forma?

“Predecible” versus “Adaptable”: ¿Planificamos o No?Varios agilistas han coincidido en describir los procesos ágiles como “adaptables” en contrapo-sición a los métodos tradicionales o “dirigidos por planes”. Hay malas interpretaciones sobre esto también. Los agilistas critican que se pre-tende planificar en excesivo detalle asumiendo que hay una capacidad de predicción que no es posible. Los tradicionalistas responden afir-mando que no hay planificación en lo “ágil”. He visto líderes de proyecto que pasan semanas desarrollando un plan de trabajo, estableciendo en el cronograma actividades de 1 ó 2 horas de duración que se van a iniciar en 6 meses más. Son pocos los proyectos de software que se pue-

den predecir con ese nivel de precisión, y por lo tanto lo más probable es que esas actividades se redefinan y el esfuerzo en planificación sea un desperdicio. Ningún método tradicional pro-pone esto como buena práctica.

Por otro lado, es erróneo indicar que en los métodos ágiles no hay planificación. Todos in-cluyen prácticas específicas al respecto donde lo que está variando es la estrategia empleada y las técnicas utilizadas. En los métodos ágiles puede haber varios niveles de planificación: un plan de “releases” de alto nivel, un plan de iteraciones con un poco más de detalle y final-mente un plan de iteración donde aparecen las actividades concretas. También es erróneo pensar que estas técnicas son exclusivas de las metodologías ágiles. Esta planificación por ventanas o “Rolling Wave Planning” es una técnica recomendada por el PMBOK.

La connotación de predecible versus adaptable también está asociada a críticas a los métodos tra-dicionales indicando que no pueden o no saben lidiar eficientemente con el cambio. Malas in-terpretaciones han llevado a equipos a establecer excesivos y rigurosos procesos de control de cam-bio. Pocos métodos tradicionales establecen que el cambio debe ser limitado. La incertidumbre en los requerimientos y por lo tanto la omnipresen-cia del cambio ha sido aceptada desde siempre.

El Factor HumanoUno de los puntos más distintivos de las meto-dologías ágiles fue su reconocimiento explícito de que la gente y sus interacciones eran el factor más importante de éxito en los proyectos de software. Sobre esto también ha habido confusiones. Para empezar, se ha creído que los métodos tradiciona-les no sólo desvalorizan el rol de las personas sino que además contienen intrínsecamente la visión de que los procesos pueden reemplazarlas.

He conocido gerentes que creen que con base en sus procesos pueden tomar un “programador X” y reemplazarlo por “programador Y” como si fueran piezas de maquinaria, pero eso es una pésima interpretación. Los conceptos sobre los que se fundamenta el manejo de las personas en los métodos ágiles vienen de muchos años atrás. Además, varios autores de metodologías tradicio-nales han declarado la importancia de las personas sobre los procesos. Lo que hay que reconocer es que las metodologías ágiles sí contienen de modo más explícito prácticas que favorecen esta visión y fortalecen el desarrollo del equipo a través de la comunicación y colaboración.

Otra crítica común a los métodos ágiles es que crean una enorme dependencia en las personas debido a la ausencia de procesos formales y do-

cumentación. Lo que yo he observado en los proyectos es lo contrario: un equipo que se re-úne diariamente y sabe qué está haciendo cada uno de sus miembros y donde la planificación o el diseño se realiza con todo el equipo pre-sente ha compartido de mejor forma el cono-cimiento y la experiencia y está más preparado para soportar un cambio en el equipo, que otro donde el análisis está perfectamente documen-tado, pero sólo una persona lo entiende.

La Necesidad del BalanceSon muchos temas más los que se han discuti-do a lo largo de esta polémica y que no alcan-zamos a ver aquí: pruebas, manejo de riesgos o si CMMI puede ser implantado con prácticas ágiles, son algunos de ellos.

Probablemente la polémica continuará por algún tiempo más. Hoy, sin embargo, cada vez más practicantes han visto la necesidad de encontrar un balance. Las prácticas ágiles y las más tradicionales han demostrado tener nichos en los cuales se comportan bien y favorecen el éxito. También se ha probado que cuando dejan ese nicho las experiencias pueden ser desastro-sas. Antes podía decirse que estos nichos eran independientes y un equipo podía escoger en-tre ir ágil o tradicional. Lo que sucede cada vez con mayor frecuencia en el vertiginoso mundo que vivimos, es que estos nichos se entrecruzan frecuentemente, y por lo tanto ningún esque-ma resulta completo o favorable por sí sólo.

No hay que quedarse en ningún extremo. Eso puede llevarnos a ignorar los objetivos del proyecto y conducirnos ciegamente al fracaso. Por el contrario, reconociendo el valor que una mezcla adecuada puede generar, aumentare-mos notablemente la probabilidad de éxito de nuestros proyectos no sólo en los parámetros usuales de plazo, alcance y costo, sino también en el desarrollo del conocimiento y experien-cia para el equipo y la organización.

Referencias1. Barry Boehm. “A Spiral Model of Software Development and Enhancement”. Proceedings of the Second International Software Process Workshop, Marzo 1985. 2. H.D. Benington, “Production of Large Computer Programs,” Proceedings of the ONR Symposium on Advanced Program Me-thods for Digital Computers, 1956.3. E.V. Berard, “Misconceptions of the Agile Zealots”, The Object Agency, 2003.4. F. P. Brooks, Jr., “No Silver Bullet: Essence and Accidents of Software Engineering,” IEEE Computer, Vol. 20, No. 4, Abril 1987.5. Martin Fowler, “Is Design Dead?”, www.martinfowler.com

Un equipo que se reune diario y

sabe qué está haciendo cada quien, está mejor preparado para el cambio

EN PORTADA

28 www.softwareguru.com.mxMAY-JUN 2006

MAY-JUN 2006

Patrones para la Adopción de ÁgilEn general, yo veo que las organizaciones de TI pasan por tres etapas de madurez en su forma de administrar proyectos de software. Empiezan en un estatus de caos, o ausencia de control. Al darse cuenta de este problema, deciden adoptar metodologías con alto grado de definición, documentación y puntos de con-trol/autorización. Es lo que yo llamo “control prescrito” y básicamente consiste en generar un plan y adherirse a él. Esta estrategia ayuda a tener las cosas bajo control, y funciona duran-te un tiempo o para cierto tipo de proyectos. Sin embargo, cuando las organizaciones se en-frentan con proyectos más innovadores, don-de se utilizan nuevas tecnologías, o donde los requerimientos van cambiando conforme se va aprendiendo sobre el negocio, la estrategia de control prescrito tiende a fracasar. Es entonces que las organizaciones entienden la necesidad de administrar estos proyectos de una forma más flexible y adaptable, llegando a lo que lla-mo “control adaptable”.

Estas son las etapas que típicamente veo en grandes organizaciones de TI. En el caso de organizaciones más pequeñas, sobre todo or-ganizaciones cuyo negocio es el software, he

notado una tendencia de pasar directamente del caos al control adaptable. Para ellos, no tiene mucho sentido pasar por el control pres-crito, ya que no se adecua a sus necesidades. De hecho, el tipo de organizaciones donde más se está usando Ágil, son empresas cuyo negocio principal es el software. En cambio, las áreas de sistemas en empresas de otro giro, van a un ritmo de adopción más lento.

Debo decirles que en el último año y medio he notado un cambio muy importante en la postura de las organizaciones hacia Ágil. Anteriormente, lo que sucedía es que dentro de una organización de TI encontrarías a un grupo rebelde, que probablemente estaba tra-bajando en algún proyecto novedoso, y decía “nosotros queremos usar Ágil”. Así que acer-caban a gente como yo, y los asesorábamos para adoptar Ágil en su equipo. En cambio, lo que me ha estado sucediendo más y más en los últimos 18 meses, es que son los CIOs y CTOs los que están interesados en adoptar Ágil, y quieren hacerlo en toda su organiza-ción. Actualmente estoy colaborando con una empresa en Boston donde estamos implantan-do Ágil para 500 ingenieros, en un periodo de tiempo bastante corto. Ese tipo de adopciones no sucedían hace un par de años.

Las Fases de un Proyecto ÁgilVisualizar. Se genera una visión colectiva so-bre el producto de software a desarrollar.Especular. Se establecen hipótesis sobre las especificaciones del producto, sabiendo que conforme el proyecto avance, estas especifica-ciones irán evolucionando.Explorar. Se implementan las especificacio-nes de forma iterativa.Adaptar. Se analizan los resultados de dichos experimentos y se realizan los ajustes necesa-rios para las siguientes iteraciones. Se evalúan cuatro aspectos: funcionalidad del producto, calidad técnica del producto, estatus del pro-yecto, y desempeño del equipo.Cerrar. El cierre de cada iteración sirve para dar un pequeño break y tomar fuerza para la siguiente.

Como pueden ver, estas fases asemejan más un proceso de investigación científica, que un proceso de gestión de la producción (la forma tradicional de administrar proyectos).

Equipos DistribuidosExiste la noción esuivocada de que Ágil no se puede aplicar con equipos distribuidos geográ-ficamente. Los equipos distribuidos son más complicados, pero esto aplica tanto para Ágil como para tradicional. Todas las organizaciones donde yo estoy implantando Ágil actualmente tienen equipos distribuidos.Así que sí es posible, sólo hay que apoyarse en herramientas adiciona-les (wikis, instant messengers, videoconferencia, etc). Lo que hay que evitar es tratar de sustituir la colaboración y comunicación con documen-tación. Así que en lugar de buscar documentar todo e intercambiar documentos de un lado a otro, es preferible intercambiar miembros de equipos durante un periodo de tiempo.

Nuevas HabilidadesÁgil requiere que los desarrolladores sean mejores testers. Ahora decimos que el ciclo para un desarrollador es rojo, verde, reorga-nizar. Esto se refiere a escribir una prueba unitaria (rojo), escribir el código que la hace funcionar (verde) y reorganizar (refactor) el código para optimizarlo.

Una Plática con Jim HighsmithAdministración Ágil de ProyectosJim Highsmith es miembro fundador de la alianza ágil, y uno de los “agilistas” más reconocidos internacio-nalmente. Sus libros “Agile Software Development Ecosystems” y “Agile Project Management” son lecturas fundamentales para el entendimiento y adopción de Ágil. Recientemente, Jim estuvo en México para impar-tir un taller organizado por Cutter Consortium. Aprovechando la ocasión, platicamos con él para conocer más sobre su visión de la administración de proyectos ágil.

29www.softwareguru.com.mx MAY-JUN 2006

¿Cuál metodología de desarrollo utilizo? Una res-puesta frecuente es: “ninguna”. Los ingenieros de software generalmente pensamos que de-

sarrollar es un arte, pero la realidad es que el impacto actual que los sistemas de información tienen en las organizaciones requiere que el desarrollo de los mismos se realice de una ma-nera estructurada y sistemática. Esto implica utilizar una meto-dología formal de desarrollo. ¿Cuál metodología? Hay muchas en el mercado, bien probadas y ampliamente utilizadas. La respuesta la tiene cada equipo de desarrollo de acuerdo a sus necesidades, ambiente de trabajo, y arquitectura tecnológica con que la organización cuente, entre otros factores. Un rol fundamental para fomentar el uso de alguna metodolo-gía de desarrollo de software lo tiene la academia. Esto implica dos retos; el primero es convencer a los alumnos sobre la im-portancia del uso de metodologías para desarrollar software, y el segundo es enseñarlos a aplicar éstas en proyectos reales.

Enseñar a Pensar en el Problema y la EstrategiaUsualmente, cuando a un estudiante se le plantea una pro-blemática de negocio, su primera reacción está en la solución técnica del mismo. Las primeras ideas que le vienen a la men-te son: en qué lenguaje desarrollo, cuál estructura de datos soportará el proyecto, en qué sistema operativo correrá. Esto es el equivalente a cuando un arquitecto inicia a construir sin planos, sin una visión de las necesidades de sus clientes, sin una maqueta de su proyecto.

El planteamiento inicial debe ser de reflexión, de pedirles que por un momento dejen el teclado que traen bajo el bra-zo y busquen entender la problemática que tienen al frente: ¿qué requiere el cliente? ¿Cómo impacta a la organización? ¿Cuál estrategia apoya? ¿Cómo encaja en la arquitectura tecnológica? ¿Cuáles son los requerimientos de seguridad? ¿Qué prioridad se le asigna al proyecto? En fin, un entendi-miento que permita dimensionar el proyecto y establecer la visión y alcance de éste, para finalmente determinar su factibilidad y estrategia para la ejecución.

A partir de ahí se inicia el ciclo de desarrollo de software, con las diferentes actividades de la ingeniería de software como análisis, diseño, desarrollo, pruebas e implantación, con todo lo que ello implica: establecer roles, utilizar documentos pre-definidos, técnicas que permitan acelerar el análisis y diseño como “Joint Application Design”, elaboración de prototipos rápidos, acelerar el desarrollo con esquemas del tipo “Extre-me Programming”, madurar los procesos a través de modelos como CMMI, etc. En fin, las opciones son diversas y los resulta-dos también, de ahí la importancia de definir cuál es la meto-dología de desarrollo para la organización.

Aplicación en Proyectos RealesLa experiencia de trabajar proyectos de desarrollo de software con estudiantes para diversas empresas, desde PyMEs hasta grandes corporativos, es posible gracias al establecimiento y uso de una metodología, tanto para el planteamiento del proyecto como para el desarrollo del mismo. Las respuestas de las organizaciones a la pre-gunta “¿Cuál metodología quiere que utilicemos?”, son diversas, desde el típico “cualquiera” o “la que ustedes decidan”, hasta aquellas empresas que especifican cuál es la metodología, entrenan a los alumnos en la misma y facilitan los documentos y herramientas de soporte. El esquema genérico utilizado para estos proyectos por parte de los estudiantes es:• Dimensionamiento del proyecto.• Elaboración de un plan de trabajo.• Ejecución y control del plan de trabajo.• Juntas de revisión y avances.• Evaluación y presentación final de resultados.

Esto implica que los alumnos desarrollen, entre otras ha-bilidades, el establecimiento de los alcances, la adminis-tración de proyectos, el liderazgo, el trabajo colaborativo, la coordinación de acciones, la resolución de conflictos y el uso de una metodología particular —en nuestro caso nos basamos en el Microsoft Solutions Framework (MSF) y el Rational Unified Process (RUP)—. El fundamento teórico utilizado en este tipo de experiencia académica es la téc-nica didáctica de Aprendizaje Basado en Proyectos (POL, Project Oriented Learning).

ConclusiónEl salón de clases ya no es más un espacio solamen-te teórico, los problemas reales de las organizaciones vienen a las instituciones académicas y el trabajo con-junto para acelerar la incorporación de los estudiantes egresados al ámbito laboral es vital para nuestro país. Debemos resolver el problema que genera la postura (o necesidad) de las empresas de “solamente contra-tar gente con experiencia”, sin dar oportunidad a los recién graduados de adquirir la misma. Por esto, la experiencia de realizar proyectos en empresas con es-tudiantes de manera formal (y con base en metodolo-gías) como parte de su plan de estudios es una relación ganar-ganar para todos; los estudiantes adquieren ex-periencia, las organizaciones resuelven problemáticas de negocio y las universidades creamos vínculos estre-chos con la realidad nacional e internacional.

Los invito a reflexionar, y ustedes, ¿Cuál metodología de desarrollo utilizan en su organización? —Francisco José Camargo Santacruz

CO

LUM

NA

30 MAY-JUN 2006 www.softwareguru.com.mx

Aprendizaje Basado en ProyectosReduciendo la Brecha Entre la Teoría y la Práctica

CÁTEDRA Y MÁS

El Dr. Francisco José Camargo Santacruz es profesor investiga-dor de los Departa-mentos de Sistemas de Información y Ciencias Computa-cionales en el Tec de Monterrey, Campus Estado de México. Su área de especialidad es la Integración de Tecnología de Informa-ción en las Organiza-ciones. Francisco está certificado como IT Service Management (ITIL Foundation), ha sido consultor de di-versas organizaciones en Colombia y México, tiene diversas publica-ciones en revistas de circulación interna-cional y pertenece al Sistema Nacional de Investicagores (SNI).

www.softwareguru.com.mxwww.softwareguru.com.mx MAY-JUN 2006 31

PRÁCTICAS

PROCESOS

32 MAY-JUN 2006 www.softwareguru.com.mx

PRÁCTICAS

ADMINISTRACIÓN DE PROVEEDORES

SLAs Orientados a Requerimientos de NegocioPERSPECTIVA DEL PROVEEDOR

Por Axel Nissim S.

En el número de Enero-Febrero 2006 de este año se publicó un artículo sobre el papel que tienen los SLA (Service Level Agreement) en la definición de las relaciones Cliente-Pro-veedor de TI, y dimos algunos lineamientos básicos para que el cliente defina sus re-querimientos en base en sus objetivos de negocio. De acuerdo a lo prometido (y lo prometido es deuda), en esta segunda par-te les presento algunos lineamientos para la definición de SLAs, desde la perspectiva del proveedor.

De acuerdo a lo que planteamos en el artícu-lo anterior, puede parecer que la definición de un acuerdo de niveles de servicio, con un cliente que sabe definirlo con base en sus objetivos de negocio, es un asunto peligro-sísimo. Por otro lado, las más de las veces nos encontraremos con clientes que aún se conforman con definir los SLA únicamente a partir de métricas simples de desempeño de los procesos, sistemas o infraestructura tercerizada como servicio.

El hecho de que la mayoría de los clientes aún no conozcan la manera más efectiva de pedir lo que quieren, asegurando sus obje-tivos de negocios, no implica que nosotros, proveedores, debamos hacernos de la vista gorda y únicamente acceder a los SLAs que obviamente son ventajosos para nosotros y no implican un mayor esfuerzo de reflexión por parte de nuestro cliente.

Resulta ser, amigos proveedores, que las industrias de Outsourcing de Procesos de Negocio, Desarrollo de Sistemas a la medi-da, Tercerización de Soporte e Infraestruc-tura, y servicios de consultoría asociados, coexisten delicadamente en un ecosistema lleno de amenazas internas y externas, en-tre las que podemos citar la feroz competen-cia proveniente de India, China y Europa del Este, así como una constante consolidación de las empresas grandes, y el hecho de que actualmente todos parecemos estar en una

carrera contra el tiempo por implementar modelos de calidad. Por si fuera poco, además hay gente como yo, que proponemos estrategias agresivas a los clientes para tomar las riendas de sus relaciones con los proveedores. Todo esto lo explico para hacerlos ver que en este ecosistema feroz se vuelve cada vez más importante ofrecer una ventaja competitiva más allá del precio por unidad de trabajo, la calidad garantizada por un modelo, o hasta el idioma que hablan nuestros recursos humanos.

¿La conclusión? Necesitamos crear ofertas de valor que impacten directamente en el negocio de nuestro cliente con resultados tangibles, dramáticos y sobre todo... que no parezcan acci-dentales, sino producto de un proceso metódicamente calculado por nosotros los proveedo-res. Así que además de implementar modelos que nos permitan mejorar nuestros procesos, disminuir nuestros costos operativos y hablar el mismo idioma que nuestro cliente, necesita-mos resolver problemas de negocio y no sólo desarrollar servicios y productos susceptibles de ser vendidos con una hoja de especificaciones técnicas, o la promesa de atender 200 usuarios por minuto, o el mantener soporte técnico con 99% de fiabilidad.

El papel de nosotros los proveedores es primordialmente hacer negocios agregando valor a la operación de nuestros clientes, sea el que sea su negocio, y para hacer esto les propongo los siguientes lineamientos:

Antes de poder proponer SLAs orientados a requerimientos de negocios para nuestros clien-tes, necesitamos:• Conocer a fondo el mercado en el que se desenvuelve nuestro cliente.• Identificar las variables de negocio que son susceptibles de optimización por medio de la contratación de nuestros servicios.• Clasificar exhaustivamente hasta donde resulte práctico los diferentes tipos de proyectos y compromisos que resolvemos con nuestra oferta de negocios.• Identificar los Cost Drivers del negocio de nuestro cliente.• Construir un Business Case que abarque desde el estudio previo hasta la finalización de la relación para cada contrato ganado.• Establecer y mantener la infraestructura de análisis necesaria para obtener nuestras pro-pias métricas y mediciones respecto a nuestro desempeño en nuestros diferentes compro-misos.• Medir el desempeño de los Cost Drivers del negocio de nuestro cliente antes, durante y después de la realización de nuestros compromisos.• Llevar a cabo pronósticos estadísticos con los datos salidos de nuestro análisis de medi-ciones, integrando además las variables de negocios y Cost Drivers asociados a cada tipo diferente de proyecto.

Muchos de estos puntos son mencionados ya en varios de los modelos de mejora de procesos existentes. Sin embargo, muy pocas veces su interpretación —aún aquella hecha por un profesional de la calidad—, nos da claves acerca de la ventaja directa que podemos tener con nuestros clientes a partir del esfuerzo hecho en la implementación de tal o cual modelo. Generalmente, aunque no siempre, los objetivos inmediatos de los modelos de mejora tienen que ver más con la reducción del número de defectos, la eliminación de esfuerzos redundantes y la capacidad de estandarizar y controlar nues-tro desempeño, que con definir propuestas de valor inmediato para nuestros clientes.

ADMINISTRACIÓN DE PROVEEDORES

SLAs Orientados a Requerimientos de NegocioPERSPECTIVA DEL PROVEEDOR

Por Axel Nissim S.

Una vez que todos los puntos anteriores han sido implementados para una cantidad sig-nificativa de contratos y proyectos, viene el momento de redefinir nuestra estrategia con base en los datos obtenidos de los diferen-tes análisis efectuados. Para esto, seguire-mos los siguientes puntos:

1. Partiendo de los diferentes Business Cases y tipos de proyecto, obtener los Cost Drivers que se han visto impactados significativa-mente a lo largo de nuestras relaciones con clientes. Estos serán nuestras variables obje-tivo, aquellas cosas que representan metas concretas para nuestro cliente.

2. Obtener las variables de negocio que nuestros clientes han podido mejorar a partir de la optimización de los Cost Drivers identificados. Estas serán nuestras prome-sas, los objetivos de alto nivel que nuestro cliente alcanzará.

3. Analizar las mediciones y métricas inter-nas de nuestra organización, que nos per-mitirán conocer lo que habitualmente es vendido, las variables operativas del pro-yecto o compromiso. Estas serán nuestro parámetro interno, así como nuestra meta técnica. No hay que olvidar que sólo son eso, metas técnicas, que no tienen ningún valor si no alcanzamos los objetivos de ne-gocios de nuestros clientes.

4. A partir de los diferentes escenarios pronos-ticados estadísticamente, calcular nuestras propias variables de negocio que nos permi-tirán conocer los diferentes puntos de equili-brio, retornos de inversión, así como márgenes aceptables de desviación respecto a lo planea-do para cada uno de nuestros compromisos y proyectos. Esto eventualmente se transforma-rá en los criterios internos de aceptación, así como en los parámetros de las cláusulas de escape en el SLA.

Una vez que nos encontremos con el cliente cara a cara, y si hemos cumplido cabalmente con estos puntos mínimos, nos encontraremos armados para presentar una oferta de valor con un impacto sobre el negocio de nuestro cliente, que además podrá ser justificada paso a paso sin necesidad de recurrir a contorsiones y ma-rometas por parte de nuestro equipo de ventas.

Este es un punto distintivo que contribuirá fuer-temente a que ganemos más contratos.

Al momento de definir ya en concreto los SLAs, será conveniente que lleguemos con una propuesta previamente integrada que contenga al menos los siguientes puntos:• Descripción del Tipo de Servicio o Producto.• Descripción del Servicio o Producto.• Variables de Negocio del cliente a ser im-pactadas.• Cost Drivers a ser impactados.• Especificación de Tiempos, Esfuerzos, Re-cursos necesarios y Calidades esperadas.• Criterios de Aceptación de la o las soluciones.• Especificación de Clausulas de Escape.

Este borrador de SLA será despedazado por nuestro cliente, si es que conoce su propio negocio (y leyó el artículo anterior respecto a este tema), sin embargo habremos ganado bastante de su confianza en el proceso de pre-venta y venta, y nos será posible entender su problema aún antes de comenzar el verdadero análisis una vez firmado el SLA y los otros con-tratos correspondientes.

ConclusiónEl beneficio de presentar propuestas de este tipo a nuestros clientes es in-mediato y dramático, dado que aún en servicios considerados hoy en día como commodities, nos será posible obtener una ventaja competitiva que no depen-da de bajar los precios, ni de incurrir en prácticas poco éticas de administración de recursos humanos, o tantas de las otras situaciones complicadísimas que contribuyen a que nuestro ecosistema de servicios y productos IT no termine de madurar.

Otros beneficios que se generan de esto, son: • Para nosotros: ventaja competitiva. • Para nuestro cliente: alcanzar los ob-jetivos de negocio.• Para la industria: alcanzar la madurez de servicios y productos.• Para las personas que trabajan en nuestras organizaciones: remunera-ción justa sin compromiso a la ética profesional.

MAY-JUN 2006 www.softwareguru.com.mx

PRÁCTICAS

34 MAY-JUN 2006 www.softwareguru.com.mx

Mónica Vázquez es ingeniero de software con un doctorado en tecnologías de la información especializada en metodologías de desarrollo. Su área de espe-cialidad son los requerimientos de software, y está certificada como Master en Requerimientos de Rational. Mónica cuenta con casos de éxito publicados en la implantación de metodologías de desarrollo, y ha tenido gran éxito aplicando su tan personalizado estilo de talleres en diversas compañías privadas e institucio-nes gubernamentales.

Al iniciar cualquier proyecto de software, es necesario definir y capturar las necesidades que debe resolver el sistema a desarrollar, así como las características

que debe reunir para conseguirlo. Una técnica utilizada am-pliamente es capturar esto en casos de uso. Sin embargo, lanzarnos directamente a desarrollar casos de uso puede ser una práctica equivocada. Antes de hacer esto, debemos encontrar y aterrizar de manera correcta:• Necesidades de negocio o sistema.• Reglas de negocio.• Visión del producto.• Requerimientos (usuario, sistema, hardware, etc.).• Casos de uso.• Casos de prueba.

Una técnica recomendable para generar esto es el taller de requerimientos. Un taller de requerimientos nos permi-te conocer las necesidades de los diferentes involucrados (stakeholders) y tomadores de decisiones, reduciendo así el tiempo de levantamiento de información en 50%, con el beneficio adicional de obtener un mayor compromiso por parte de los usuarios. En este artículo muestro los pasos que se deben llevar a cabo para desarrollar un taller de re-querimientos exitoso.

Identificar InvolucradosEl primer paso consiste identificar y/o verificar quiénes son los patrocinadores, tomadores de decisión, y usuarios representativos. Una vez identificados, debemos asegu-rarnos que se encuentren dentro del plan de comunicación del proyecto, para asegurar el compromiso y comenzar con el flujo natural de retroalimentación. Claro que esto se debe hacer respetando el marco metodológico que se esté aplicando. Como breviario cultural, les recuerdo que el líder de requerimientos debe reflejar las actividades posteriormente expuestas en el plan inicial del proyecto.

PlaneaciónLo que prosigue es la planeación del taller, para lo cual se recomienda cumplir los siguientes lineamientos:

• Asegurar que en la primera sesión el sponsor del proyecto esté presente.• Conjuntar a los principales stakeholders en la primera sesión.• Asegurar la participación de los usuarios principales durante todas las sesiones.• El Project manager del proyecto no asiste a los talleres, ni el equipo de de-sarrollo.• El facilitador del taller debe ser un ingeniero de requerimientos experimen-tado (líder de requerimientos en el proyecto) puede contar con la ayuda de máximo dos analistas, dependiendo del número de participantes.• El número de asistentes no debe rebasar las 15 personas.

La agenda de la primera sesión debe cubrir las necesidades de negocio y los requerimientos generales.

A continuación les muestro un ejemplo de una agenda detallada para una pri-mera sesión, con una duración de 4 horas:10 minutos - Presentación, logística evento.5 minutos - Reglas de grupo.1.30 hrs - Detección de necesidades.15 minutos - Receso.15 minutos - Retroalimentación de lo encontrado.45 mintos - Reducción de ideas.15 minutos - Receso.30 minutos - Detección funcionalidad general.15 mintos - Cierre primera sesión.

Necesidades de NegocioExisten diferentes técnicas para desarrollar y capturar las necesidades del ne-gocio. Una de estas es la lluvia de ideas, o brainstorming dentro del grupo. Sin embargo, para que sea exitosa se requiere de un moderador experimentado, ya que de otra forma la sesión puede salirse de control, o no generar la participa-ción necesaria. Para emplear esta técnica, se organiza al grupo en forma circular, nunca de auditorio, ya que se simula una mesa redonda donde los participantes expondrán la necesidades que ellos consideran que debe satisfacer el sistema.

El moderador se abstendrá de intervenir en proposiciones de solución, simple-mente mide tiempos y traduce la información que se está dando a lo que se tiene planeado durante las sesiones. Para la utilización de la lluvia de ideas la principal regla es “dejar que la imaginación fluya con toda libertad”. Ya el mis-mo grupo determinará la viabilidad de sus peticiones y tomará las decisiones pertinente de las implicaciones.

El ABC de un Taller de RequerimientosPLANEACIÓN Y LINEAMIENTOS

Por Mónica Alegría Vázquez

REQUERIMIENTOS

www.softwareguru.com.mx MAY-JUN 2006 35

El ABC de un Taller de Requerimientos

www.softwareguru.com.mx

Elementos de ApoyoRegresando a materia, para captar las necesidades de negocio ten-dremos que cumplir con este proceso básico:

Es recomendable manejar diferentes elementos visuales como apoyo durante nuestras sesiones. A continuación listo algunos elementos que pueden utilizarse como apoyo, indicando sus usos y limitantes:

Para alguien que inicia con los talleres, recomiendo dibujos, y pos-ters mezclados con diagramas de flujo sencillos para una primera sesión. Los participantes también podrán aportar sus propios ele-mentos visuales.

Debemos tomar consciencia que nuestros participantes no tie-nen la obligación de saber y entender qué es un diagrama de caso de uso, un actor, etc. Por esta razón, durante la ejecución del taller todo se debe exponer de manera que sea entendible para cualquiera y se determine de manera general “qué debe hacerse”. El “cómo” es la parte técnica que no forma parte de un taller de requerimientos.

Resultados del TallerUna vez aseguradas las necesidades de negocio, las cuales no pue-den resultar en un número exagerado, tendremos que parar y hacer una retroalimentación con nuestro grupo utilizando la reducción de ideas. Es recomendable representar las necesidades de negocio de manera jerárquica, para que a partir de éstas pueda irse definiendo la funcionalidad requerida por el nuevo sistema. Las ideas finales deben irse reflejando de manera visual para el auditorio e ir almace-nando el contenido en un documento que bautizaremos como “Re-sultados del Taller”.

El siguiente diagrama muestra un ejemplo del flujo de entregables que se podría generar a través de una serie de talleres. No es absolu-

tamente necesario que ustedes planeen sus talleres para obtener esta misma serie de en-tregables, pero es una buena referencia:

En otro artículo les mostraré un ejemplo de un documento de resultados de taller, y veremos cuales son los siguientes pasos.

Hasta la próxima lección..

Elemento Visual Usos Limitaciones

Póster Refleja y dibuja temas Describe un simple punto o concepto. o conceptos, muestra agenda.

Lista Pasos del proceso de Difícil para comparar lote de ítems lluvia de ideas, define capturados. expectativas, identifica una serie de ítems.

Flujos, flechas Causa y efecto, Implica una secuencia que podría secuencia de una ser no correcta. progresión.

Matrices Define elementos Puede comparar únicamente pocos faltantes, facilita la elementos al mismo tiempo comparación.

Dibujos Visión, historias, Los dibujos por la calidad no pueden planes, conceptos de reflejar la idea. negocio. Mapa mental Ideas, categorías, Complejo de leer texto e imagines, jerarquías.

Figura 1. Flujo para captar necesidades de negocio.

MAY-JUN 2006 www.softwareguru.com.mx

PRÁCTICAS

Domingo Suárez se desempeña como Gerente de Sistemas de Vigilancia en Bursatec. Es egresado de IPN-UPIICSA, lugar donde fundó el grupo de usuarios JavaUp.org. Así mismo es cofundador del Grupo de usuarios SpringHispano.org. Desarrolla software usando en su mayoría software libre y metodologías ágiles. domix@springhispano.org

J2EE (que recientemente cambió su nombre a JEE) es una plataforma madura y soportada por las principales empresas de tecnología. Desarrollar

aplicaciones empresariales usando las especificaciones JEE asegura en gran medida: escalabilidad, manejo tran-saccional robusto, e independencia de plataforma tanto de hardware como de sistema operativo. Sin embargo, JEE también tiene ciertas debilidades, las cuales se pueden evitar a través de la utilización del framework Spring.

Debilidades de JEEToda esa robustez que JEE nos provee, también genera un costo tanto en complejidad como en desempeño. Una aplicación JEE diseñada de acuerdo a los lineamientos de los Java BluePrints, requiere la utilización de numerosos y complejos patrones de diseño. Adicionalmente, las múlti-ples capas generadas pueden impactar el desempeño de las aplicaciones. Un ejemplo de esto es la aplicación de referencia “Java Pet Store”, que cuenta con un gran over-head y como resultado ofrece un desempeño degradado.

Mi intención no es eliminar el uso de patrones, si no más bien ser pragmático, aprovechar la robustez de JEE sin hacerlo tan complicado, y poder aplicar métodos ágiles como TestDriven Development (TDD). En fin, mi intención es usar otros enfoques de desarrollo.

Por otro lado, está el tema de los EJBs. Es común asociar de in-mediato JEE con EJBs. Esto en cierta medida es correcto. pero JEE no es sólo EJBs. Muchos de nosotros hemos sufrido, per-dón, usado Entity Beans en algún proyecto, lo que después de la pesadilla nos lleva a buscar alternativas. Los Entity Beans, por ser orientados a componentes, no se prestan a modelar relaciones entre ellos de manera adecuada desde el punto de vista de negocio. Para manejar la lógica de negocio, JEE pro-pone la utilización de Session Beans en sus dos modalidades: con estado y sin estado. En la mayoría de los casos, esto im-plica mezclar código de negocio con APIs de EJBs. Adicional-mente, es complicado probar este código antes de que el EJB “viva” en un EJB Container. Se requiere utilizar herramientas adicionales como simuladores de contenedores.

Una AlternativaEntre las alternativas disponibles para suplir las debilidades de JEE en persisten-cia, están Hibernate, iBatis, JDO, entre otros, incluso JDBC directo. Hibernate es un framework que permite modelar el dominio de la aplicación y mapear ese modelo de objetos Java a tablas de una base de datos relacional. Las clases Java que Hi-bernate necesita para hacer esto, son sencillamente clases planas Java, conocidas como POJOs (Plain Old Java Objects).

Y entonces, ¿por qué no usar POJOs para programar la lógica de negocio tam-bién? ¿Por que no usarlos para acceder otras fuentes de información, como directorios LDAP? Esto simplificaría el desarrollo e incluso permitiría probar el código desde la línea de comandos, facilitando esta labor y permitiendo que la cobertura de las pruebas sea mayor, lo que en el futuro evita sorpresas con el usuario.

El inconveniente con utilizar POJOs para todo es que nos puede incitar a progra-mar código sumamente acoplado. Sin embargo, esto si seguimos el principio de diseño que dice “programa hacia una interfaz, no hacia una implementa-ción”. Esto significa que debemos generar dependencias hacia interfaces en lugar de hacia clases concretas. Por ejemplo:

public interface DAO {

Cliente getClienteById(String id);

}

public class DaoImpl implements Dao {

public Cliente getClienteById(String id) {

// Código necesario para obtener los datos del cliente.

}

}

public interface ClienteService {

boolean isClienteMoroso(String idCliente);

}

public class ClienteServiceImpl implements ClienteService {

private Dao dao;

public Dao getDao() { return this.dao }

public void setDao(Dao dao) { this.dao = dao }

public boolean isClienteMoroso(String idCliente) {

Cliente cliente = this.getDao.getClienteById(idCliente);

return cliente.getSaldo > 0;

}

}

Spring FrameworkDESARROLLO JEE AGIL

Por Domingo Suárez

PROGRAMACIÓN

36

Spring FrameworkDESARROLLO JEE AGIL

Por Domingo Suárez

En este ejemplo definimos dos interfaces. La primera, como su nom-bre lo indica, sigue el patrón de diseño DAO (Data Access Object). Este patrón se utiliza para encapsular lógica de acceso a datos, evi-tando así mezclarla con la lógica de negocio. La clase DaoImpl es una implementación de la interfaz Dao, así que contiene en el código necesario para acceder los datos, dependiendo de la tecnología que se esté utilizando.

La segunda interfaz (ClienteService) define un servicio de negocio, en este caso para saber si un cliente es moroso. La clase Clien-teServiceImpl implementa esa interfaz y, como pueden observar, contiene una micro-lógica de negocio para determinar si un cliente es moroso. Observen que esta clase usa un DAO para acceder a la base de datos, solo que en vez de hacer la referencia a una clase concreta, se referencia a la interfaz. De esta manera se desacoplan las implementaciones.

Así que podemos tener múltiples DAOs y cada uno puede usar un mecanismo diferente para acceder la base de datos. Como mencio-nábamos anteriormente, uno podría utilizar Hibernate, otro JDBC, e incluso otro pudiera basarse en archivos de texto plano en caso de no

haber una base de datos relacional. Este mecanismo se puede aplicar no sólo a las dependencias que tengan los servicios de negocio con DAOs, sino también de dependencias de servicios entre sí.

Con el uso de interfaces hemos resuelto el asunto del acoplamiento y la dependencia a clases concretas. Sin embargo, surge un nuevo incon-veniente, y es que ahora requerimos de algún mecanismo para que los servicios de negocio puedan obtener la referencia a la clase concreta que implemente la interfaz DAO y así poder acceder a los datos. Si ob-servan de nuevo, el código del servicio sólo contiene la lógica de nego-cio, no contiene código que “inicialice” o cree una instancia del DAO que necesita. Para resolver esto típicamente se usa el patrón de diseño Factory en sus múltiples variaciones. Pero al hacer esto, de nuevo pode-mos mezclar código de la lógica de negocio con código que bien puede ser de infraestructura de la aplicación. Adicionalmente, el patrón Factory por su naturaleza implica un cuello de botella, ya que el acceso a este debe de ser de manera sincronizada para evitar “colisiones” con otros hilos de la aplicación. Otro inconveniente de utilizar este patrón es que entonces es necesario crear una factoría para casi todo; es decir, una factoría para DAOs, otra para servicios, y así para todos aquellos objetos cuya instancia necesitemos definir.

38 MAY-JUN 2006 www.softwareguru.com.mx

PRÁCTICAS

PROGRAMACIÓN

Mejor Usemos SpringUna alternativa a la problemática mencionada, y el principal interés de este artículo es hablarles del framework de desarrollo JSE/JEE Spring. Y es que aunque en este articulo empecé a hablar de desarrollo JEE, Spring es aplicable a desarrollos JSE, sin ningún problema.

Spring básicamente nos provee de un contenedor de objetos. En sentido un poco mas contextual, es un contenedor de beans. Como todo contenedor, el de Spring se encarga del ciclo de vida del bean, de su creación y en algunas implementaciones de su destrucción. Este contenedor es conocido como un Application Context. El Appli-cationContext en sí, es una factoría de beans, porque en base a cier-ta definición, el contenedor se encarga de la creación de los beans.

Antes de seguir hablándoles del Application Context, quiero hablarles de un principio elemental en el cual Spring se basa. Este principio que es considerado un patrón de diseño por muchos, se llama Inversion Of Control (IoC) o Dependency Injection (DI). Martin Fowler explica de manera muy concisa la diferencia entre ambos conceptos, yo prefiero identificar a la “magia” de Spring como DependencyInjection.

¿Cómo Funciona la Inyección de Dependencias?En Spring la DI funciona de una manera muy simple. En un archivo de texto plano se escriben etiquetas XML de definición de los beans que vivirán en el ApplicationContext. En este archivo, además de la definición de los beans, se definen las dependencias de los beans. Esto le permite a Spring hacer las instancias de los beans e inyectar las dependencias para que al momento de usarlos, no obtengamos un bonito NullPointerException.

Veamos el ejemplo de la definición de un bean en XML:

<?xml version=”1.0” encoding=”UTF8”?>

<!DOCTYPE beans PUBLIC “-//SPRING//DTD BEAN//EN”

“http://www.springframework.org/dtd/spring-beans.dtd”>

<beans>

<bean id=”dao”

class=”org.springhispano.persistence.dao.impl.DaoImpl”>

</bean>

<bean id=”clienteService”

class=”org.springhispano.services.impl.ClienteServiceImpl”>

<property name=”dao”>

<ref local=”dao” />

</property>

</bean>

</beans>

Con la anterior definición, Spring creará en su contenedor dos beans, uno para la clase de implementación del DAO y otro para el servicio de negocio. A la clase del servicio de negocio le inyectará la referencia del DAO concreto. Esto lo logra invocando el método setter de la propiedad DAO en el bean clienteServicio. Aquí es don-de la inyección de dependencias trabaja; en nuestra aplicación le delegamos a Spring la creación de los objetos, o dicho de una ma-

nera más correcta, invertimos el control de la creación de objetos a Spring. Con esto se hace innecesario la programación de factorías de objetos y sobre todo la inclusión de código de infraestructura en las clases que programemos.

Algunas de las principales características de Spring, son: • Contenedor IoC. Es el encargado de la configuración y manejo de los beans que viven en el contenedor. Es el corazón de Spring.• Soporte para Programación Orientada a Aspectos (AOP). Spring provee un mecanismo basado en Proxies para implementar AOP en nuestras apli-caciones, aunque también podemos usar el poder de AspectJ.• Acceso a datos simplificado. Spring brinda un enfoque consistente para acceso a datos, ya sea JDBC o a través de algunos frameworks para acceso a datos, como Hibernate, iBatis, JDO, TopLink, etc. Asi-mismo nos proporciona una jerarquía de excepciones que encapsu-lan las excepciones lanzadas por los diversos frameworks de acceso a datos, lo que permite en algún momento poder intercambiar de framework sin afectar el código ya escrito.• Manejo transaccional. Spring provee una abstracción para trabajar con recursos transaccionales, ya sea JTA, transacciones JDBC, Hiberna-te, o algún otro API. • Modulo Web: Spring provee un framework MVC basado en peticiones (request based).

Entre los beneficios que podemos obtener con su utilización están:• Mejor diseño orientado a objetos en las aplicaciones.• Mayor enfoque en el desarrollo de la lógica de negocio.• Menor código de infraestructura necesario.• Facilidad para realizar pruebas unitarias del código.• Independencia del servidor de aplicaciones.• No es necesario usar APIs de Spring para ponerlo a funcionar. Aunque en algunos casos seria una lastima si no usáramos las abs-tracciones que Spring nos provee con algunas de sus clases (Templa-tesClasses, SupportClasses).

Aunque Spring provee funcionalidad para manejar las diversas capas de una aplicación (front end, lógica de negocio, acceso a datos), no es necesario usarlo para todo. Spring nos brinda la flexibilidad de utilizarlo solamente en la capa o capas que que-ramos.Los invito a que se familiaricen con Spring, es un excelente fra-mework. Aprovecho para invitar a los interesados y a los usuarios de Spring a que visiten el Spring User Group (SUG) springhispano.org, que tiene como finalidad ayudar de manera desinteresada a la adopción de Spring, así como el intercambio de experiencias y dar a conocer en dónde se está utilizando Spring.

Referencias• Martin Fowler. Inversion of Control Containers and the Depen-dency Injection pattern. www.martinfowler.com/articles/injection.html• Rod Johnson, Juerger Holler, et. al. Java Development with the Spring Framework. Wiley Publishing, Inc., 2005

www.softwareguru.com.mx MAY-JUN 2006 39

PROGRAMACIÓN

Luis Daniel Soto Maldonado es Direc-tor 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). Luis Daniel es jurado del “Gran Or-den de Honor al Mérito Autoral” en software del INDAUTOR/SEP y fundador de diversas asociaciones de Tec-nologías de Informa-ción (TI) relacionadas a inteligencia competiti-va, administración del conocimiento y cons-trucción de software. Luis Daniel Soto es Ingeniero en Sistemas de la Fundación Arturo Rosenblueth y ganó el primer lugar en el concurso nacional para software de ex-portación en 1989. blogs.msdn.com/luisdans

CO

LUM

NA¿Quién es el Desarrollador de Software

en México?

TENDENCIAS EN SOFTWARE

Los perfiles de gente de TI, y en particular de software, son muchos y continúan aumentando. Por lo menos, podemos identificar los siguientes segmentos:

• Desarrollador no profesional: a) por hobby, b) power user.• Desarrollador académico: a) entrenador técnico, b) pro-fesor de negocios, c) estudiante en ingeniería, d) estudian-te en ciencias de la computación, e) otros estudiantes.• Diseñador: a) Productor, b) creador de interfaz, c) dise-ñador interactivo, d) diseñador web, e) diseñador gráfico.• Desarrollador: a) aplicaciones departamentales, b) apli-caciones de escritorio, c) aplicaciones de base de datos, d) aplicaciones móviles, e) aplicaciones web, f ) aplicaciones sobre plataformas empresariales, g) desarrollador de jue-gos, h) desarrollador para Microsoft Office System, (k) otros.• Ciclo de vida del software: a) arquitecto, b) pruebas y calidad, c) administrador de proyecto, d) líder de desarro-llo, e) documentador, f ) analista, g) otros roles

Dimensionar a esta audiencia en México depende deta-lladamente de los sub-segmentos que se desean incluir. El reto es entablar un diálogo efectivo dadas las variadas necesidades de la audiencia. El programador de Visual Basic difícilmente tiene los mismos temas de interés que el desarrollador C++, y mucho menos que el administra-dor de proyecto.

Además de esto, encontramos demografías diversas. Los más recientes estudios de Microsoft en Mèxico arrojan algunos da-tos concretos:• Cerca de la mitad (48%) tiene entre 30 y 39 años de edad, y una tercera parte (33%) es menor de 30 años (ver figura 1).• 87% de desarrolladores son hombres y 13% mujeres.• El lenguaje de programación con mayor penetración entre los desarrolladores es Visual Basic con 71%, seguido por ja-vascript con 59% y Java con 41% (ver figura 2).• En México, 19% de los desarrolladores en los pasados 6 me-ses han utilizado productos y herramientas de código abierto.• 50% de los desarrollos usan base de datos de forma integra-da. 80% de los desarrolladores han creado aplicaciones de 2 capas y 47% de 3 capas.• 61% de los desarrolladores en México han creado aplicacio-nes que se entregan vía web (la mayoría en Intranets).• 24% construyen aplicaciones para dispositivos electrónicos portátiles.• C/C++ continua siendo el lenguaje más utilizado para la edu-cación con 39%, lo siguen: Java (26%), Visual Basic (25%), Basic (13%), C# (10%), Pascal (9%), Javascript y PHP (7%), y COBOL (6%).• El 80% de los desarrolladores se encuentran (en orden des-cendente) en: Distrito Federal y Zona metropolitana, Nuevo León, Jalisco, Tamaulipas, Veracruz, Coahuila, Chihuahua, Pue-bla, Baja California, Sinaloa, Guanajuato, Sonora, Querétaro.

¿Esta información concuerda con lo que usted ha visto?

Conclusiones¿Es usted un desarrollador? ¿Está en búsqueda de mejores oportunidades? Algunas recomendaciones:1. No tema a la actualización permanente, búsquela, será fun-damental para la subsistencia – intégrese y participe activa-mente en comunidades.2. Si esta desempleado o desea una mejor oportunidad, “haga la tarea”, investigue a fondo la empresa, necesidades del área y del entrevistador, pregunte por personas que fue-ron entrevistadas previamente, siempre personalice su currí-culo a cada posición.3. Si tiene su empresa de software, desarrolle la madurez em-presarial de su empresa o busque a su contraparte comercial y no tema incursionar en habilidades de ventas y mercadotec-nia. Conozca a fondo los programas de apoyo a empresas de software de los grandes proveedores y del gobierno.

Lecturas y recursos adicionales• Jornadas Profesionales - www.software.net.mx/desarrolladores/jornadas • Ineta - www.ineta.org/latam • Delta Asesores - www.deltaasesores.com

Figura 1. Edad de los desarrolladores.

Figura 2. Lenguajes de programación utilizados (respuestas múltiples).

40 MAY-JUN 2006 www.softwareguru.com.mx

PRÁCTICAS

Luis Felipe Fernández Martínez es profesor investigador del departamento de eléctrica y computación del Instituto de Ingeniería y Tecnología de la Universidad Autónoma de Ciudad Juárez. Durante el 2003 estuvo como investigador invitado del grupo de ingeniería de software del CIMAT y colaboró en la creación y desa-rrollo de la Maestría en Ingeniería de Software. Actualmente colabora en proyectos de investigación con el mismo grupo y es candidato a doctor por la Universi-dad Politécnica de Catalunya, Barcelona, España; su trabajo de tesis gira entorno a arquitecturas de software. lfernand@uacj.mx

E Brooks, en un artículo de 1987 titulado “No Silver Bullet: Essence and Accidents of Software Engi-neering”, compara a los proyectos de software

con el hombre lobo: de ser algo familiar, de pronto se convierten en una pesadilla. En dicho escrito, el autor resalta algunas —para ese tiempo— potenciales “balas de plata”, que eliminarían este terror. Entre ellas, mani-fiesta la importancia que tienen los buenos diseñadores en el desarrollo de software. Los diseñadores de los que escribió Brooks, bien pueden ser los arquitectos de hoy.

Una Breve Historia de la Arquitectura de SoftwareAunque el término “arquitectura de software”, tal y como lo concebimos ahora, aparece en 1992 con el trabajo de Perry y Wolf[1], sus antecedentes se remontan al menos hasta finales de la década de los sesenta. En 1968, Dijks-tra habla de una estructuración correcta de los sistemas de software, aunque no la llama arquitectura como tal[2]. Posteriormente, en 1969, P. I. Sharp, comentando las ideas de Dijkstra, ya usa el término arquitectura de soft-ware al mencionar que quizá luego se hable de “la escuela de arquitectura de software de Dijkstra”, y al mismo tiem-po lamentar que la industria de ese tiempo preste muy poca atención a ésta.

Durante la década de los setentas el concepto de arquitec-tura deambuló por el aire sin una semántica clara y caren-te de una expresión pragmática. En esta misma década, el diseño estructurado dio pie a la independencia entre el diseño y la implementación. Los trabajos de Parnas so-bre técnicas de modularización en decisiones de diseño y familias de programas[3], fueron, sin duda, aportaciones esenciales y permanentes.

Las decisiones “tempranas” de diseño, argüía Parnas, probablemente permanecerían invariantes en el desarro-llo de la solución; estas ideas se convierten luego en lo que hoy se conocen como decisiones arquitectónicas.

Rompiendo esquemas y acaparando la atención en la

década de los ochentas, aparece el paradigma de la orientación a objetos. En esta década aparecen dos trabajos importantes de Mary Shaw, que retoman las abstracciones de alto nivel: “Técnicas de abstracción en lenguajes moder-nos de programación”[4] y “Los sistemas de gran escala requieren de abstrac-ciones de alto nivel”[5].

Hacia finales de los ochenta y principios de los noventa, comienza a gestarse de manera más clara la idea de que las aplicaciones tienen una morfología, una estructura. El trabajo de Perry y Wolf[1] de 1992 es el punto de partida para lo que hoy conocemos como arquitectura de software. Por un lado, son los pri-meros que proponen un modelo para la arquitectura de software; este modelo contempla a la arquitectura formada por tres componentes: elementos, forma y razón. Los elementos pueden ser de procesamiento, datos o conexión; la forma se define de acuerdo a las propiedades de, y a las relaciones entre los elementos; la razón se contempla en términos de restricciones del sistema, que se derivan de los requerimientos del sistema.

Perry y Wolf profetizaron que: “la década de los noventas, creemos, será la década de la arquitectura de software”, lo cual se convirtió en realidad. A lo largo de esa década, salieron a la luz varios trabajos con propuestas relevan-tes, entre ellas, la programación basada en componentes[6], el surgimiento de los patrones y estilos[7], el modelo de 4+1 vistas[8], y lenguajes de descripción de arquitecturas (ADLs)[9] entre otras.

En la segunda mitad de los noventa aparecen los primeros libros de texto dedicados a la arquitectura de software. El año 2000 cierra esta década con dos trabajos clave: el modelo REST propuesto en la tesis de Roy Fielding que pone la atención en Internet y los modelos orientados a servicios[10]; y el tra-bajo de la IEEE, que genera una versión definitiva de la recomendación IEEE std 1471-2000[11].

También en este año se abren nuevas perspectivas para la arquitectura de soft-ware, aparecen las estrategias orientadas a líneas de productos y se procura insertar la arquitectura de software dentro del ciclo de vida, obligando a rede-finir las metodologías referentes a él en términos de arquitectura[12].

Actualmente hay una cierta efervescencia alrededor de desarrollos centrados en arquitectura, métodos de análisis y diseño de arquitecturas (dentro del ciclo de vida), análisis de arquitecturas de software basados en escenarios, mode-los de evaluación de arquitecturas de software y modelos orientados por la arquitectura entre algunos otros tópicos.

Arquitectura de SoftwarePor Luis Felipe Fernández

ARQUITECTURA

www.softwareguru.com.mx MAY-JUN 2006 41

Arquitectura de SoftwarePor Luis Felipe Fernández

Definiciones, Definiciones, Definiciones...Martin Fowler, en su artículo “Who needs an Architect?”[13], deja salir su cinismo (se-gún él mismo lo expresa), y como primer intento, define arquitectura como: “una palabra que utilizamos cuando queremos hablar del diseño y queremos que se escu-che como algo importante”. Encontrar una definición aceptada universalmente no es tarea fácil, de hecho no existe. Por el con-trario, se puede literalmente nadar en un mar de definiciones[14]. Lo que existe es un consenso intuitivo de qué es arquitectura de software. Este consenso intuitivo invo-lucra generalmente un diagrama: círculos o cuadros unidos por alguna línea, alguna identificación de estos elementos y poca cosa más. La interpretación recae en for-

ma importante en quién la ve (y la puede entender) o la diseña, y seguramente fuera de este círculo lo que provoca es simple-mente confusión.

La construcción de una definición textual de arquitectura de software se basa y se ha basado en la mayoría de los casos en inter-pretar estos diagramas y darles de alguna manera coherencia. Así podemos encontrar que las definiciones iniciales se refieren a componentes o elementos relacionados en-tre sí (estructura) primordialmente. Luego se le ha agregado que también las propiedades de los elementos son parte de la arquitectu-ra; otros más se decantan por el conjunto de decisiones de diseño (sin marcar cómo po-drían mostrarse en un diagrama), y algunos más aterrizan la definición como aquellos

aspectos que son inmutables en un sistema de software o difíciles de cambiar. Una defi-nición a la que se recurre más es la presenta-da por Bass, et al.[15]:“Una arquitectura de software de un pro-grama o un sistema computacional es la estructura del sistema, la cual comprende elementos de software, las propiedades ex-ternamente visibles de esos elementos, y las relaciones entre ellos”.

El principal problema con las definiciones que se han dado (cientos) es que aunque tratan de ubicar una idea clara de lo que es arquitectura de software, terminan por ajustarse al entorno en cuestión y sólo establecen para ese momento un consen-so. No es difícil encontrar que cada tra-bajo sobre arquitecturas, sobre todo los

42 MAY-JUN 2006 www.softwareguru.com.mx

PRÁCTICAS

PROCESOS

Referencias1. Dewayne E. Perry y Alexander Wolf. “Foundations for the study of software architecture”, ACM SIGSOFT Software Engineering Notes, 17(4), pp. 40-52, Octubre de 1992.2. Edsger Dijkstra. “Go-To statement considered harmful”. ACM Communications of the ACM, 11(3), pp. 147-148, Mar-zo de 1968.3. David Parnas, “On the criteria for decomposing syste-ms into modules” Communications of the ACM 15(12), pp. 1053-1058, December 19724. Mary Shaw, “Abstraction techniques in modern pro-gramming languages “ IEEE Software, pp. 10-26, Octo-ber 1984.5. Mary Shaw, “Large scale systems require higher level abstraction”, Proceedings of fifth international workshop on software specification and design. IEEE Computer So-ciety, pp. 143-146, 1989.6. Paul Clements, “Coming attractions in software archi-tecture”, Technical report, CMU/SEI-96-TR-008, ESC-TR-96-008, jan. 1996.7. Erich Gamma, Richard Helm, Ralph Johnson, John Vlis-sides, “Design Patterns: Elements of reusable object-oriented software. Reading, Addison-Wesley, 1995.8. Philippe Krutchen, “The 4+1 view model architecture”, IEEE Software 12(6), pp. 42-50, nov. 1995.9. Paul Clements, “A survey of architecture descrip-tions languages” Proceedings of the International Workshop on Software Specification and Design, Germany, 1996.10. Roy Thomas Fielding, “Architecture styles and design of network-based software architectures” PhD Thesis, Ca-lifornia University, Irvine 2000.11. Software Engineering Standards Committee of the IEEE Computer Society, IEEE Recommended practice for architecture description of software-intensive syste-ms, IEEE Std 1471-2000, Approved 21 September 2000, IEEE-SA Standards Board, Print: ISBN 0-7381-2518-0 SH94869, PDF: ISBN 0-7381-2519-9 SS94869, available at (http://standards.ieee.org/).12. “The open group architectural framework” Versión 8, document number I911, dec. 2002.13. M. Fowler, “Who needs an Architect?”, IEEE Software, pp 11-13, Septiembre-Octubre 2003.14. http://www.sei.cmu.edu/architecture/definitions.html#new_visitors.15. L., Bass, P., Clements, R., Kazman, Software archi-tecture in practice, SEI Series in Software Enginee-ring, Second Edition, Addison Wesley, 2nd printing, October 2003.

académicos, inician por adaptar o formular lo que para su contexto se entenderá por arquitectura de software.

Evidentemente esta debilidad alrededor de una definición formalmente aceptada no ha impedido que existan trabajos tanto prácticos como acadé-micos, y por lo tanto, un desarrollo sustancial en la disciplina. Quizá el lec-tor tenga la sensación de que entonces no hay problema. En parte sí, antes de la postulación de la ley de la gravedad las manzanas seguían cayendo igual; pero una vez formulada, el panorama se vio muy diferente.

A Futuro... Trabajo Básico por HacerLe propongo al lector un par de ejercicios. Examine cualquier diagrama que se ostente como representación de una arquitectura, luego intente tomar la definición mencionada anteriormente o cualquier otra y busque emparejar-las; seguramente tendrá algunas dificultades.

Otro ejercicio puede ser pasear un poco por el Proceso Unificado de Racio-nal (RUP) que pregona ser un proceso orientado por casos de uso y centrado en la arquitectura; de nuevo, ajustar la definición de arquitectura de software empelada en ese momento (por el autor que escribe o diserta sobre RUP) con algunos de los artefactos que se proponen en este proceso no es una tarea sencilla... igual, encontrará dificultades. Para empezar, existe un cierto senti-miento dentro de la academia que estimula a pensar que los diagramas pro-puestos por UML no son precisamente una representación arquitectónica.

Como se puede apreciar, no todo es un lecho de rosas. La bala de plata aún está en construcción (aunque sería iluso pensar que algún día se terminará de construir) y la arquitectura de software es tan sólo un elemento importante.

ConclusiónLa arquitectura de software, con alrededor de 15 años de vida (si conside-ramos su nacimiento a partir de 1992), ha emergido como una disciplina de gran importancia dentro de la ingeniería de software. Una arquitectura ade-cuada es pieza clave para lograr tanto los requerimientos funcionales como no funcionales de un sistema. Por otro lado, una arquitectura no adecuada puede ser catastrófica.

La arquitectura también juega un papel importante en otros aspectos del de-sarrollo de software: • Mejora la comprensión de sistemas grandes y complejos.• Permite una mejor comunicación entre los diferentes interesados (stakehol-ders) en el sistema.• Mejora las posibilidades de reuso.• Proporciona planos para la construcción.• Toma en cuenta la posible evolución del sistema.

Durante la revisión de este artículo, Cuauhtémoc Lemus y Ge-rardo Padilla (CIMAT), a quien agradezco su tiempo, plantearon una pregunta importante e interesante: ¿cuál es el estatus de la arquitectura de software en las instituciones de educación y en la industria de software mexicanas? Por lo pronto no hay respuesta, pero por allí andaremos.

MAY-JUN 2006 www.softwareguru.com.mx

UML

analizado. En otras palabras, a los valores de uno o más de sus atributos. Por ejemplo, una persona que tenga edad de 8 años está en el estado “niñez”, si la edad es 14, está en “adolescencia”, y así respectivamente. Como se podrán imaginar, el atributo más simple que podría definir el estado de un objeto sería un atributo llamado “estado” o “estatus”.b. Estado Determinado por las Acciones del Objeto. La segunda situación que determina el estado del objeto analizado son las accio-nes realizadas por el mismo en un momento determinado. Por ejemplo, un reproductor de MP3 cuando toca la música está en estado de “tocando”; un avión que va surcando los cie-los está “volando”.c. Estado Pasivo o En Espera. El estado más simple es aquel en el que el objeto analizado simplemente espera a que algo ocurra en el entorno para pasar a un nuevo estado. Ejem-plificando nuevamente con el reproductor de MP3, está en “pausa” hasta que el usuario le indique que continúe reproduciendo la música o se detenga totalmente.

Cambios de Estados: Las TransicionesNo porque el objeto pueda tener ocho po-sibles estados significa que puede pasar a cualquiera de ellos en cualquier momento. Uno de los valores que ofrece este diagrama es precisamente que establece las reglas para que el objeto, estando en un estado determinado, pueda pasar a otro. Por ejem-plo, si el semáforo está en verde no debe de poder pasar a rojo, sino únicamente a amarillo. Estos cambios y restricciones se muestran con una flecha, que es el símbolo para las transiciones entre estados.

¿Por Qué Cambia un Objeto?Si queremos indicar la causa por la cual se puede dar una transición de un estado

La Vida de un Objeto EL DIAGRAMA DE ESTADOSPor Sergio Orozco

Sergio Orozco es director general e instructor senior certificado por la OMG en Milestone Consulting. Primer empresa mexicana miembro de la OMG, especializada en la capacitación práctica y consultoría en UML, CMM y orientación a objetos. info@milestone.com.mx www.milestone.com.mx

Como ya he mencionado en ediciones ante-riores y se lo repetimos a nuestros alum-

nos constantemente, no todos los proyectos requieren utilizar todos los artefactos de UML. Uno de los artefactos que no veremos en todos los proyectos, es el diagrama de estados. Sin embargo, esto no le resta importancia. En pro-yectos donde el comportamiento del sistema depende en gran medida del estado en que se encuentran los objetos de negocio, los diagra-mas de estado son indispensables. Los diagra-mas de estado permiten visualizar los estados de un objeto —ya sea éste un documento, pro-ducto o persona—, los eventos ante los cuales reacciona y los efectos o acciones que realiza al cambiar de estado o mientras se encuentra en un estado.

Centrado en los ObjetosLo que convierte a estos diagramas en algo especial y que lo liga con el paradigma de orientación a objetos, es que en lugar de cen-trarse en un proceso completo, mostrando los diversos objetos que colaboran, este diagra-ma se centra únicamente en lo que afecta a un objeto específico; por ejemplo el paquete, el adeudo, el semáforo o el préstamo.

Es decir, se desarrolla un diagrama de es-tados por cada objeto a analizar. Claro que no todos los objetos que identificamos me-recen ser analizados tan a fondo como para crearles uno de estos diagramas. Recuerda que no queremos tener proyectos llenos de artefactos que no aportan valor, así que hay que ser muy selectivos.

Estados y sus Diferentes TiposPodemos ubicar los estados de un objeto de acuerdo a tres posibles situaciones:a. Estado Determinado por los Atributos. La primera situación que determina el esta-do de un objeto se define por los datos que en ese momento están asociados al objeto

44 MAY-JUN 2006 www.softwareguru.com.mx

a otro, lo podemos indicar con un evento, con una condición o con ambos. Un even-to es algo que ocurre en el ambiente que afecta el comportamiento del objeto anali-zado ocasionando que cambie a un nuevo estado. Si una computadora está apagada y se oprime el botón de “Encendido”, la computadora pasa a un estado de “Arran-cando”. Pulsar el botón de encendido es el evento que ocasionó este cambio. La mayoría de las veces vamos a encontrar a estos elementos como verbos, pues es algo que ocurre y que afecta el comportamiento del objeto.

Un evento es una posible causa de que un ob-jeto pase de un estado a otro, pero otra posible causa se debe al cumplimiento de una condi-ción que afecta al objeto analizado. Puede ser el hecho de que los atributos del objeto anali-zado tomen cierto valor, o que haya pasado un lapso de tiempo. Ejemplo, si el monto acumu-lado en la máquina dispensadora es igual al precio del producto deseado, entonces pasa a un nuevo estado donde permite seleccionar el producto a despachar. La comparación del monto acumulado en un momento en la má-quina, contra el precio del producto deseado puede considerarse como una condición de guardia. Estas condiciones se muestran entre corchetes como expresiones booleanas junto a las transiciones.

Hay Causas, pero También Consecuencias de los CambiosAsí como hay situaciones que provocan el cambio de estado de un objeto, también hay situaciones que se dan como resulta-do de un cambio de estado. A estos efec-tos se les llama acciones. Aunque tanto las acciones como los eventos se mues-tran como verbos, las acciones son con-secuencia del cambio y los eventos son causas del cambio.

www.softwareguru.com.mx MAY-JUN 2006 45www.softwareguru.com.mx

Todo tiene un Principio y un FinalTodo objeto tiene un principio, pues necesaria-mente debe de nacer en algún estado. Dicho estado se representa con un círculo relleno. Por otro lado, un objeto puede tener de cero a N es-tados finales, los cuales se representan por un círculo relleno, dentro de otro círculo hueco. El estado final es el último estado en el que queda un objeto antes de desaparecer, o cuando deja de tener más comportamiento. Los objetos que se mantienen siempre activos regresan una y otra vez a estados anteriores, por eso no tienen un estado final. En cambio hay objetos que pueden terminar su vida de diferentes ma-neras; en diferentes estados. El diagrama 2 representa los estados y transi-ciones de un préstamo. Procesar, aceptar, re-chazar, depositar son eventos que ocasionan cambios de estado. [monto = adeudo] es una condición de guardia. Los primeros son verbos y el segundo es una expresión booleana.

Estos son algunos ejemplos de sistemas donde los diagramas de estado son de gran utilidad.• Seguimiento a un pedido. Necesitamos saber si el pedido ya fue autorizado, si está en pro-ducción, si fue cancelado o en qué estado se encuentra dentro del proceso.• Rastreo de paquetes. Para las empresas de mensajería es un requisito casi indispensable ofrecer a los clientes la posibilidad de rastrear sus paquetes a través de Internet. Y en realidad

el sistema de rastreo para los clientes es sólo la punta del iceberg, pues una empresa de este tipo requiere una logística complicada alrede-dor de los paquetes que se envían. Ra-zón mayor para uti-lizar diagramas de estados al desarrollar

este tipo de sistemas.• Flujos editoriales. Alguna vez participé en un sistema de monitoreo de un periódico, y los participantes en el flujo del negocio necesita-ban saber con oportunidad el estado en que se encontraba cada una de las páginas del perió-dico, pues la impresión del mismo no podía re-trasarse. Se desarrolló un diagrama de estados para la “Página del Periódico”.• Productos y servicios financieros. Una so-licitud de préstamo también sigue un flujo donde diferentes entidades realizan acciones relacionadas con el préstamo. Alguien tiene que validarlo, otro tiene que autorizarlo, otro más lo deposita, también podrían rechazarlo. Este tipo de flujos que giran alrededor del es-tado de un producto o servicio son excelentes candidatos para modelarse con diagramas de estados.• Comportamiento de aparatos y dispositi-vos. Los dispositivos mecánicos y electrónicos son objetos cuyo comportamiento también es conveniente modelar. Un ejemplo sería una máquina dispensadora de golosinas. La máqui-na espera que alguien deposite una moneda para comenzar a funcionar. Cuando depositan una moneda la máquina cambia su comporta-miento y entra a un estado donde espera que seleccione el usuario algún producto o que siga agregando monedas según sea el caso. Al se-leccionar el producto lo entrega si lo deposita-do es suficiente para cubrir el precio, y regresa cambio si excede el precio; si no es suficien-te, sigue esperando más monedas.

ConclusiónComo podrán ver, los diagramas de es-tado son de gran utilidad. Estos diagra-mas tienen muchos más elementos de los que aquí se han explicado, pero aquí hemos explicado 20% de los ele-mentos que ayudan a resolver 80% de los problemas.

Diagrama 1. Estados de un semáforo

Diagrama 2. Estados de un préstamo.

46 MAY-JUN 2006 www.softwareguru.com.mx

FUN

DA

ME

NTO

S

Administración de Servicios de TIEntendiendo ITIL e ISO 20000Por Eugenio Torres

Eugenio Torres Gutiérrez es socio de Inteli México, empresa dedicada a la consultoría y educación en Administración de Servicios de TI, donde asesora empre-sas de clase mundial en asuntos relacionados con la Administración de Servicios de TI, Administración del Riesgo y Administración de la Seguridad. Eugenio cuenta con la acreditación como Black Belt de Six Sigma, y entrenamiento en el nivel Master de ITIL.www.inteli.com.mx

En fechas recientes, palabras como “pro-cesos”, “mejores prácticas”, “estándares”, etc., han dominado las pláticas del personal de sistemas, que ávidos de trabajar de mejor forma y buscando la experiencia generada por otras organizaciones de TI, se han dado a la búsqueda de encontrar una guía que le dé orden a su forma de trabajo.

Tomando en cuenta lo anterior, la mejor for-ma de definir un estándar es considerando cuál es la necesidad que éste pretende cu-brir o satisfacer. Como en cualquier indus-tria, existen una serie de procesos que son comunes a cualquier organización de TI, in-dependientemente de a qué se dedique la organización a la cual pertenece; algunos ejemplos de estos procesos son el soporte a los usuarios de los sistemas, la gestión de la operación diaria de los equipos y sistemas, el control del presupuesto, etc. Todos estos “procesos”, ya han sido evaluados y redise-ñados por mucha gente, generando proce-sos optimizados que han sido registrados y documentados como “mejores prácticas”.

Surgimiento de ITILEstas mejores prácticas para las áreas de TI tuvieron como origen formal un proyecto de estandarización ejecutado por el gobierno del Reino Unido en la década de 1980, con el objetivo de establecer modelos comunes de trabajo para las áreas de TI de las diferentes organizaciones del gobierno de ese país. Ese esfuerzo culminó con la publicación de la pri-mera versión de ITIL (Information Technology Infrastructure Library), la cual poco a poco fue adoptada además por la iniciativa privada, hasta convertirse en un estándar de facto de la industria de TI alrededor del mundo.

Se debe recordar que las mejores prácti-cas, deben ser interpretadas como reco-

mendaciones, nunca como guías rígidas o planes de trabajo. Si bien ITIL, como referencia independiente, propone termi-nología estándar para definir “qué hacer” y “qué no hacer” al adoptar una estrate-gia de administración de servicios de TI, o IT Service Management (ITSM), no define los procesos de negocios, por lo que se adapta a las necesidades individuales de cada organización.

Como consecuencia de la creciente adopción de ITIL, surgieron grupos de usuarios deseo-sos de aportar sus experiencias e integraron el ITSMF (IT Service Management Forum), que actualmente cuenta con representa-ciones o capítulos a lo largo del mundo, in-corporando organizaciones usuarias de los diferentes sectores e industrias.

ISO 2000: un Estándar para las OrganizacionesLa mayoría de las organizaciones de TI que deciden adoptar mejores prácticas, desean tener un punto de referencia para comparar sus esfuerzos y posiblemente certificarse. Como parte del esquema que se desarro-lló alrededor de ITIL se planteó una ruta de certificación para los individuos, a fin de garantizar que estuvieran preparados para implementar las recomendaciones. Sin em-bargo, no existía una estándar internacional contra el cual las organizaciones pudieran evaluar su implementación. Así es que ante el incremento de la adopción de ITIL, y alen-tada por los grupos de usuarios y firmas de consultoría, nació la necesidad de una refe-rencia formal para las organizaciones, y con ella el desarrollo del estándar BS15000, que en 2005 evoluciona al estándar ISO 20000.

ISO/IEC 20000 es el primer estándar con co-bertura mundial para la Administración de

Servicios de TI. Ha sido desarrollado como referencia para que las organizaciones de TI logren satisfacer sus necesidades y para pro-veer entendimiento común sobre este tema.

El estándar busca orientar a los proveedores de servicio para que implementen un mode-lo de mejora de la calidad en el servicio que entregan a sus clientes internos y externos. Cubre los aspectos relacionados a la gestión de los servicios, considerados como la causa de 80% del gasto total en TI en la mayoría de las organizaciones.

ISO 20000 consta de dos partes, bajo el títu-lo general de Administración del Servicio de Tecnología de Información:1. Especificaciones 2. Código de Prácticas

La parte 1 especifica los requerimientos para administrar los servicios de TI; promueve la adopción de un enfoque integrado de pro-cesos para proporcionar de manera efectiva los servicios de TI a los usuarios y clientes finales en función de sus requerimientos; y así identificar oportunidades para la mejo-ra continua para asegurar que los procesos sean efectivos y eficientes.

La parte 2 es una guía de recomendaciones para los auditores de las organizaciones pro-veedoras de servicios de TI. Ambas partes del estándar son totalmente compatibles y se soportan en el conjunto de mejores prác-ticas sugeridas por ITIL.

Relación entre BS 15000, ISO 20000 e ITILEntre 2004 y 2005, BS 15000 e ITIL se ali-nearon como consecuencia de un convenio entre el BSI (British Standard Institution), la OGC (Office of Government Commerce; or-

www.softwareguru.com.mx MAY-JUN 2006 47www.softwareguru.com.mx

ganización del gobierno británico, respon-sable de coordinar los esfuerzos alrededor de ITIL), y el ITSMF. Considerando los es-fuerzos realizados, la ISO adoptó el están-dar BS 15000 y a finales de 2005 publicó el ISO 20000 como el primer estándar global para la Administración de Servicio.

La alineación del ISO 20000 e ITIL no signifi-ca que la organización tenga que elegir uno de los dos, porque cumplen diferentes pro-pósitos. Uno es un marco de trabajo, mien-tras que el otro es un estándar. O sea que ITIL define las mejores prácticas que, sí son adoptadas, ayudarán a una organización a lograr la calidad de la administración del ser-vicio requerida por el estándar ISO 20000.

ISO 20000 plantea las características están-dares que deben cubrir los procesos relacio-nados con la administración del servicio, y cuando se aplica una evaluación con respec-to a su cumplimiento, prueba objetivamente qué mejores prácticas se han adoptado real-mente en una organización.

La interoperabilidad entre los dos estánda-res incrementa considerablemente el éxito de los proyectos, con el diseño de procesos

orientados a la infraestructura basados en ITIL y construidos para mantener los contro-les de seguridad y cumplimiento de requeri-mientos del negocio.

BeneficiosEntre los beneficios que una organización alcanzaría al esforzarse por cumplir con ISO 20000, se pueden mencionar: • Alineación de la estrategia del negocio y los servicios de TI.• Contar con un marco para los programas de mejora del servicio.• Demostración del valor del servicio de TI.• Servicios confiables, consistentes y con cos-to efectivo, dando una ventaja competitiva.• Mejora la reputación y percepción general de los Sistemas de Información.• Mejores relaciones entre los departamentos dando claridad respecto a “quién hace qué” y los objetivos comunes.• Un marco para la automatización de la admi-nistración del servicio.

Mapa de ImplantaciónEl camino natural que se recomienda seguir a las organizaciones que buscan certificarse en ISO 20000 está basado en el ciclo PDCA, el cual se aprecia en la figura 1.

Figura1. Mapa de Implantación

48 MAY-JUN 2006 www.softwareguru.com.mx

CA

RR

ER

A

Comunidades en Todo MéxicoLa Unión hace la Fuerza

Las comunidades o grupos de usuarios relacionados con tecnología han existido desde hace mucho tiempo y no son nada nuevo. Sin embargo, en los últimos años éstas han cobrado bastante fuerza, especialmente a nivel regional. Esto en gran parte se debe a que a las empresas proveedoras de tecnología por fin les está "cayendo el veinte" de que mucha de su fortaleza (o debilidad), reside en la cantidad y calidad de profesionistas que utilizan sus productos y son capaces de desarrollar soluciones con ellos.

Típicamente, el objetivo ce un grupo de usuarios es reunir personas inte-resadas en una tecnología, con el fin de compartir conocimiento, conocer colegas, y posiblemente participar de manera conjunta en proyectos.

Los grupos de usuarios acostumbran reunirse periódicamente de manera presencial, y complementar esta comunicación a través de medios en línea como foros, wikis y chats. Cada comunidad típicamente cuenta con un si-tio web, que sirve como medio para difundir el contenido de las reuniones (notas, presentaciones), calendario de reuniones, referencias a recursos y herramientas que son útiles a los miembros, etc.; además es buena idea que exista un lugar para que los miembros proporcionen retroalimentación sobre los expositores, temas y contenido.

Existen diversas formas de financiar la operación de una comunidad. Los in-gresos pueden venir como patrocinios de las empresas proveedoras de tec-nología, cuotas de membresía, donaciones voluntarias, e incluso en algunos casos los miembros de la comunidad realizan proyectos por los que cobran.

Estructura del Grupo y RolesEs buena idea que cada grupo de usuarios tenga una mesa directiva, cuyos miembros decidan la dirección y objetivos del grupo, además de ser los que "se muevan" para conseguir patrocinios, conferencistas y proyectos. Otros ro-les a considerar en una comunidad pueden ser:• Facilitador de la reunión. Es responsable de que la reunión avance y se ape-gue a la agenda. • Secretario. Responsable de documentar las minutas de la comunidad. La per-sona que desempeña este rol puede cambiar reunión con reunión. Lo impor-tante en todo caso será publicar las notas de la reunión en el foro o sitio de la comunidad para que estén disponibles a los que no pudieron asistir. • Tesorero. Este rol es opcional y depende del tipo de actividades que la comu-nidad desee realizar. • Coordinador de expositores y lista de temas. Es el responsable de generar la agenda de cada reunión, considerando los temas de mayor interés para los miembros; también es responsable de convocar a los miembros para que par-ticipen como oradores, exponiendo los temas mencionados. • Administrador de sitio web. Mantiene el sitio web e infraestructura asociada.

Dependiendo de los acuerdos a los que llegue el grupo las personas en estos roles puede cambiar frecuentemente o permanecer por determinado tiempo, en cualquiera de los casos lo mejor es que estas responsabilidades se roten entre los miembros de la comunidad.

Propósitos AdicionalesComo ya se mencionó, en general el propósito de las comunidades es desarrollar conocimientos técnicos, conocer colegas y estar enterados sobre lo que está suce-diendo alrededor de una tecnología o proveedor. Sin em-bargo, algunas comunidades aprovechan la oportunidad para establecer objetivos adicionales. Por ejemplo, en el caso particular de la comunidad Java México está el de ge-nerar una versión en español del Java Tutorial, así como formar parte del Java Community Process, para participar en la definición y desarrollo de nuevas tecnologías.

TipsA continuación compartimos algunas de las buenas prácticas que hemos visto a través de las reuniones de diferentes grupos de usuarios:• Tener en línea una agenda de las próximas reuniones y temas que se van a manejar en cada una.• Permitir que los miembros sugieran los temas que se deben manejar (hacer encuestas en línea)• Publicar en línea el material de las presentaciones de las reuniones anteriores.• Tratar de que las reuniones siempre se lleven a cabo en el mismo lugar, a la misma hora, y el mismo día (ej: el pri-mer martes de cada mes). • Rifar material como libros y promocionales (solamente participan quienes llenen una encuesta de evaluación)• Dar un espacio (10-15 min.) para que una empresa pa-trocinadora de un mensaje promocional sobre sus pro-ductos y servicios. A cambio de esto, se puede obtener que dicha empresa ponga dinero para comida y refrescos (o cerveza, claro).• Además de las presentaciones técnicas, organizar me-sas redondas para que la gente se organice en pequeños grupos y discuta sobre algún tema. Esto permite que se conozcan mejor entre sí. Una vez más, la cerveza es de gran ayuda para que las ideas y la conversación fluyan de manera adecuada.

Si eres un desarrollador de software que quiere mantenerse a la vanguar-dia, estar enterado de las más recientes noticias, y conocer personas con los mismos intereses, entonces más te vale pertenecer al menos a una comunidad o grupo de usuarios. De lo contrario, estarás desaprovechan-do una excelente herramienta de desarrollo profesional.

www.softwareguru.com.mx MAY-JUN 2006 49www.softwareguru.com.mx

A continuación listamos a algunas de las principales comunidades y grupos de usua-rios de TI en México.

Grupo de Usuarios Oracle Méxicofaguirre154@yahoo.com.mx

Grupo de Usuarios Oracle Monterreycluis@itesm.mx

Comunidad de Usuarios Progress Softwarewww.cups.com.mx

Comunidad Java Méxicowww.comunidadjava.org

Comunidad .Net de Tijuanawww.tjnet.org

Comunidad .Net de Pueblawww.dotnetpuebla.com

Comunidad .Net del DFgroups.msn.com/Comunidad-NET-mx

TechNet Coatzacoalcosgroups.msn.com/Technetmexico-Coatza-coalcos-ITpros/

Debian Méxicowww.debianmexico.org

Grupo de Usuarios Linux Tabascowww.gultab.org

DB2 User Group Méxicomx.groups.yahoo.com/group/GUDB2MEXICO/join

Tivoli User Group Méxicowww.tivoli-ug.org/groups.php?groupid=14

Mexico Websphere User Groupetorres@mx1.ibm.com

Algunos sitios que pueden ser de utilidad para localizar otras comunidades tecnológi-cas en nuestra región, son:

Cofradía Digitalwww.cofradia.org

Linux Méxicowww.linux.org.mx

Java User Groupsjava.sun.com/jugs

MSDN en Españolwww.microsoft.com/spanish/msdn

International .NET Associationwww.ineta.org/latam

TechNet Méxicowww.microsoft.com/mexico/technet

Así que si todavía no participas en un grupo de usuarios, no esperes más. Encuentra el grupo en tu localidad relacionado con las tecnologías que te interesan, y acércate. O si no encuentras ninguno, fórmalo. Verás que rápidamente encontrarás gente con los mismos intereses con la que podrás inter-cambiar experiencias y algo más.

Agradecemos a las siguientes personas por la información pro-vista para generar este artículo: J. Gabriel Castillo Martínez, Direc-tor de la Comunidad IT Pro Coat-zacoalcos; Enrique Montes, que coordina los grupos de usuarios en México para Java, Oracle, Pro-gress y Sterling Commerce; Deble Kuri, Especialista de Comunicacio-nes en IBM.

50 MAY-JUN 2006 www.softwareguru.com.mx

Hay numerosas herramientas de recupe-ración en el mercado. Estas herramientas tienen como principal finalidad recuperar el máximo de información posible ante un in-cidente determinado: el caso típico es el in-tento de recuperar información de un disco duro con averías lógicas y/o físicas. No sólo es posible recuperar datos de discos duros. También es posible recuperar información de otros medios, como memorias flash de todo tipo. Los medios de almacenamiento ópticos y magneto-ópticos también son sus-ceptibles de que, al menos, intentemos la re-cuperación y la probabilidad de recupéralos es tan factible como la de un disco duro, una Compact Flash, Smart Media, tarjetas SD y xD o una memoria USB.

En términos de efectividad, es frecuente ob-tener mejores resultados en las averías lógi-cas que en las averías físicas. Así pues, los errores de usuario, los borrados intenciona-dos y el sabotaje y/o la acción del malware destructivo pueden ser considerados como averías lógicas. Un ejemplo de avería física puede ser la colisión de las cabezas del dis-co duro con los platos (head crash), las de-formaciones por impacto o cambios bruscos de temperatura, o los daños en la electróni-ca y mecánica (la ruptura de un motor en un disco duro).

La delicadeza de este tema surge en el mo-mento que ignoramos los problemas de se-guridad y confidencialidad de no contemplar medidas efectivas para prever las recupera-ciones no deseadas. Existen muchos esce-narios posibles y muy frecuentes, no sólo en el ámbito empresarial, sino en el doméstico. Cuando la recuperación es controlada y, so-bre todo, efectuada con el único propósito de salvaguardar nuestra información para ser reutilizada, no hay problema. Pero esto

no siempre es así. Al igual que nosotros, otros, sin consentimiento, pueden ser los ejecutores de procedimientos de recupera-ción no deseados.

Para muchas empresas es una práctica co-mún arrojar sus computadoras obsoletas, así como CDs, DVDs y otros medios, a los contenedores de basura. Estos muchas veces están situados en la vía pública, lo que favorece técnicas poco ortodoxas de espionaje como el “dumpster diving” o buceo en la basura. Este básicamente consiste en escrutar los deshechos para recuperar no sólo papel, también equipos de almacenamiento como discos duros, DVDs, CDs cintas streamer, etc. Sobre to-dos ellos es posible ejecutar acciones de recuperación en busca de material restrin-gido y confidencial.

En entornos domésticos deben extremarse las precauciones, no sólo cuando quere-mos destruir equipos o deshacernos de una computadora que ha quedado inservible, sino cuando se compran y venden acceso-rios en sitios web. Según los datos de un estudio del MIT (Instituto de Tecnología de Massachussets), efectuado por un grupo de estudiantes que adquirieron 158 discos duros de sitios de subasta online y venta de segunda mano, los datos no pudieron ser más alarmantes. Los estudiantes con-siguieron recuperar información de aproxi-madamente 68 discos. La información recuperada estaba en una proporción del orden del 70% de datos confidenciales y sensibles, por 30% de información no rele-vante. Las recuperaciones incluyeron infor-mación de la empresa, correo electrónico, pornografía, información bancaria y datos personales diversos. De los 158 discos analizados, sólo 12 habían sido sometidos

a procesos de borrado seguro. La mayoría de los discos estaban formateados, pero eso no es condición suficiente para garanti-zar una destrucción de datos no reversible. Recuerde especialmente este punto; for-matear no le da garantías de ningún tipo de que los datos que hubiera en el disco sean irrecuperables.

La destrucción segura dependerá de si el medio es reescribible o no. Cuando no es po-sible, caso de DVDs, CDs y otros medios no regrabables, deberíamos, en ausencia de un proveedor de destrucción, recurrir a técnicas más cotidianas como romper los discos en varios fragmentos. Cuando los soportes son regrabables, debemos plantearnos el uso de herramientas de borrado seguro.

El borrado de un medio regrabable puede ser muy rápido e inseguro, o más lento y seguro. Desde los métodos como “Super Fast Zero Write” que consistente en la escritura de un valor fijo “0x00” en cada tercer sector, hasta métodos de alta seguridad, como la aplica-ción secuencial del US Department of De-fense (DoD 5220.22-M) + Método Gutman, que consiste en 35 pasadas con iteraciones de Mersenne, para agilizar los procesos de borrado seguro mediante la generación de números pseudo aleatorios. Otro método de alta seguridad es el estándar de la OTAN, de 7 pasadas.

El borrado seguro es fácilmente aplicable con herramientas software. Para el caso más común, el borrado del disco duro, existen soluciones muy sencillas de utilizar, como, por ejemplo, Darik Boot and Nuke (DBAN), que permite no sólo el borrado rápido, sino la aplicación de técnicas más seguras, como el estándar canadiense RCMP TSSIT OPS-II, el citado DoD 5220-22.M y el más seguro de

INFRAESTRUCTURA

Durante esta semana tuve una llamada del Editor en Jefe para preguntarme si conocía alguna com-pañía que se dedicara a la recuperación de información. Un amigo suyo necesitaba urgentemente recuperar su declaración de impuestos anual de su disco duro dañado. Afortunadamente conocía a dicho proveedor y con suerte esta persona podrá recuperar su información. Esto me pareció un tema interesante para el artículo de este mes y aún más la delicadeza oculta que existe en el poder de recuperar la información.

Recuperación de la InformaciónLas Dos Caras de la MonedaPor Ariel García

los métodos actuales, el Método Gutman. Este sencillo programa permite igualmente el borrado tipo “PRNG Stream” y la versión rápida del mismo, “Fast PRNG”, conocido como “Mersenne Twister”. DBAN es gratuito, opera bajo Linux y permite borrar sistemas de archivos FAT, VFAT, y NTFS para plataformas Windows, y ReiserFS, EXT, y UFS en entornos derivados de UNIX.

Esta pequeña herramienta fue incluida en el paquete de herramientas de seguridad de la Nuclear Security Administration de los EEUU, y es una herramienta muy frecuente en distribuciones forenses y de recuperación. Pese a que su última actualización data de mediados de 2005, es una herramienta fiable y recomendable. DBAN se ofrece en versio-nes para disco flexible y CD/DVD. Basta con grabar la imagen en el medio seleccionado y encender la computadora cuyo disco queremos borrar con DBAN en la unidad floppy o CD/DVD, según corresponda.

Otros métodos de borrado interesantes y rápidos pueden ser la ejecución en una conso-la tipo UNIX con el comando dd, para conversión y copiado de archivos, mediante la se-cuencia “dd if=/dev/urandom of=/dev/hda”. Este comando debe aplicarse varias veces para incrementar la seguridad del borrado, y su velocidad dependerá de la calidad de los discos duros, siendo conveniente la activación de la caché de escritura. Los usuarios que no posean equipos UNIX pueden ejecutar este comando desde un “livecd” (distribucio-nes que arrancan desde el CD/DVD sin necesidad de instalación), como Knoppix o Slax (versión de Slackware).

En Solaris, la utilidad format permite la escritura del disco con varios patrones, lo que imposibilita la recuperación de datos indeseada. Para sistemas de este tipo debe se-leccionarse la opción “purge”, que se encuentra en la opción de análisis de superficie dentro de la herramienta format.

Igualmente es recomendable disponer de herramientas de borrado seguro no sólo de discos duros y medios completos, sino de archivos. Para tal efecto, los usuarios Windows pueden emplear la herramienta gratuita East-Tec Eraser, que además borra historial de actividad en la navegación, archivos temporales, espacio sin usar en los discos y una larga lista de fuentes de datos potencialmente confidenciales y/o sensibles. East-Tec Eraser es gratuito y ofrecido según GNU/GPL. Los usuarios de sistemas UNIX pueden encontrar repositorios como Sourceforge o Freshmeat e infinidad de herramientas de este tipo, o bien optar por el empleo de scripts de eliminación de historiales generados por ellos mismos.

En resumen es importante tener todas las precauciones necesarias, tanto para la casa y/o oficina para el respaldo y recuperación de la información crítica que tene-mos en toda la gama de dispositivos de almacenamiento que existen.

La delicadeza de este tema surge en el momento que ignoramos los problemas de seguridad y confidencialidad.

Logitech

Wireless Music SystemEntre la amplia oferta de dispositivos para re-producir archivos digitales de audio y transferir su señal a un aparato más potente, la solución propuesta por Logitech destaca por su simpli-cidad y elegencia. El Wireless Music System se compone de un transmisor montable en una base que se conecta por USB a la computado-

ra, un receptor que se conecta a la entrada de auxiliar de cualquier estéreo casero con entra-das RCA; y un control remoto de siete botones. La interfaz para la computadora requiere de un poco de tiempo para instalarse correctamente y elegir los players que se utilizan, pero con un poco de paciencia todo funciona sin proble-mas. Este accesorio es opción para quienes tienen una enorme librería de canciones en su computadora y desean escucharla más libre-mente y en un aparato potente.

52 MAY-JUN 2006 www.softwareguru.com.mx

TECNOLOGÍA

Dell

XPS M1710Diseñada específicamente para los videojugadores más exigentes, la línea XPS de Dell ofrece las más altas prestaciones, y ahora se presenta el mismo concepto, pero en una impresionan-te portátil que supera fácilmente a cualquier modelo de escritorio de otras marcas. La M1710 combina el poder del nuevo procesador Intel Core Duo con la velocidad de la tarjeta gráfica GeForce Go 7900 GTX —que integra 512MB de memoria dedicada—, para lograr lo que pocas laptops pueden: brindar los requerimientos necesarios para disfrutar los videojuegos actua-les al máximo de su calidad.

Con el soporte para el Shader Model 3.0 de DirectX 9, los más complejos efectos de iluminación, sombreado y partículas se despliegan sin problemas en la enorme pantalla de 17 pulgadas, perfecta, además, para ver películas e incluso para aplicaciones de diseño gráfico. Windows XP Media Center Edition y Dell Media Direct, son ideales para controlar todo tipo de archivos multimedia y de entretenimiento, sin complicaciones y con una respuesta inmediata.

Una de las complicaciones de las computadoras de alto rendimiento es el extremo calen-tamiento que sufren, pero el diseño exterior de la M1710 no sólo protege los componen-tes del trato rudo, sino que contribuye a disipar el calor, para largas sesiones de juego sin problemas.

Victorinox

Swiss Memory / Swiss Beat MP3

La tradicional compañía de navajas y acce-sorios para acampar se renueva y presenta un par de productos que combinan su clási-co estilo y color con funcionalidad para los amantes de los gadgets. La Swiss Memory es la navaja que todos conocemos, con di-versos aditamentos —tijeras, pinzas, lima, palillo dental, lámpara, pluma, etc.—, y lo más importante para los usuarios de com-putadoras: una útil memoria flash USB 2.0, con capacidad para almacenar hasta 2.0GB de archivos de todo tipo. Está disponible en varios modelos con distintas capacidades, accesorios y precios.

Por otro lado, el Swiss Beat es un reproduc-tor integrado a una navaja con tijeras y lima. Almacena 1GB, cuenta con una pequeña pan-talla que despliega los tags de los archivos —soporta MP3, WMA y WAV—, radio FM, seis modos predefinidos de equalización, graba-dora de voz y un control remoto. Su salida de audio es de alta calidad y potencia, compara-ble incluso con la de un iPod.

54 MAY-JUN 2006 www.softwareguru.com.mx

alma... quiero decir, a C#.J: Ahí está, dotNet no es el estándar, el estándar es el lenguaje. Para que vean, J2EE si es un estándar. Nuestra tacita no es solamente un producto, sino un conjunto de soluciones y tec-nologías, que van desde la plataforma para desarrollar aplicaciones J2EE, un modelo de aplicación estándar, una suite de verificación de compatibili-dad y una aplicación de referencia. Además, la plataforma incluye el acceso a base de datos, uso de di-rectorios distribuidos, componentes distribuidos, aplicaciones Web, y... N: Ya, ya, ya. Tanto rollo para decir que su tacita utiliza o soporta JDBC, JNDI, RMI/CORBA, JSP, Servlets, EJBs, JMS, JMX, JTA, etc. J: Pues sí. Estas tecnologías son de sobra conocidas por los verdaderos programadores. No nos van a decir que con su Visual Studio .NET, ASP.NET, ADO.NET, las BCL y el CLR van a hacer lo mismo.N: Claro que sí. Pero hablemos de len-guajes de programación, con nuestro puntito tu no solamente puedes pro-gramar en C#, sino también en C/C++, Visual Basic, J#, Perl, Python, Fortran, Delphi, etc. ¿Cuántos lenguajes so-porta su tacita?J: Pues... Java, Java, Java. Ahh! y se me olvidaba. También Java.N: Ja, Ja, Ja. ¿O sea que su tacita sola-mente tiene un solo sabor para el café?J: Pero no es cualquier sabor de café. Además, su C# se parece sospecho-samente a nuestro Java. Y su CLR a nuestra “virtual machine”.N: Casualidades, meras casualidades. J: Sí, como las casualidades que se aca-baron comiendo a Netscape, Winamp y casi desaparecen al MacOS.

N: Es la supremacía del más fuerte, la ley de la jungla, la ...J: Cálmate tú Tarzán, ya sólo falta que le pongan una veladora a su puntito. A ver, díganos finalmente, ¿qué pue-de hacer su puntito que nuestra taci-ta no pueda? N: Pues nuestro puntito proporciona una infraestructura sobre la cual los lenguajes de programación, las herra-mientas y los servicios simplifican el desarrollo de aplicaciones en un en-torno de ejecución distribuido (léase en red). J: Ándale pues, dijimos algo que no hiciera nuestra tacita, no la definición de la Wikipedia. Pues eso lo puede hacer J2EE también. N: Sí, pero .NET lo hace de una forma más natural y mejor. J: Pues no estamos totalmente segu-ros, y tendrán que convencer a miles de programadores que hacen café con nuestra tacita. N: Verás que los convenceremos.

dotNetianos.- ¿Qué pasó Javanians? ¿Ya están listos para colgar las “clases”?Javanians.- Cómo creen. Si su puntito está en pañales. Por lo menos espérense a que pueda decir Hola mundo...N: Sí como no... sólo que este puntito trae torta bajo el brazo, y se llama web services. Algo que su tacita tuvo que agregar al café. Recuerden que los parchecitos cuestan.J: Sí pues, miren que el papá de su puntito nos lo ha ense-ñado. Quién sabe cuantos “service packs” vamos a tener que instalar antes de poder usar a su puntito... N: ¡Ninguno!, papi Gates se aseguró de que estuviera per-fecto. No por nada este puntito está estrellando su tacita. Pronto todas las aplicaciones importantes sobre Web co-rrerán en el puntito.J: ¡Cuernos! además, antes tendrían que lograr que el pun-tito fuera multiplataforma, algo que nuestra tacita tiene dominado desde hace mucho tiempo. N: ¡Ja!, están atrasados de noticias, nuestro puntito ya funciona sobre el pingüinito. J: Ah, de veras... se me olvidaba el chango.N: Se llama Mono, y lo respetan, que mucho trabajo le costó al papi Icaza echarse el ECMA para desarrollarlo.J: De todas formas, el chango está incompleto y lo saben. Además, el pingüino y las ventanas no son todos los siste-mas operativos. ¿Qué me dicen de la manzanita?D: ¿No te digo? Si Mono también se ejecuta en la manzanita. J: Je, sí pues, pero no totalmente. No todas las aplicacio-nes hechas en el puntito se ejecutan en la manzanita. Eso de publicar estándares incompletos ya lo había hecho el Sr. Gates. Quieran o no, dependen de las decisiones que vengan desde Redmond. D: ¿Y a poco su tacita es libre y soberana? No me van a decir que el solecito la suelta tan fácilmente...J: Pues para que veas. Nuestra tacita es apoyada por IBM, Apple, Bea, Oracle, HP y otros. N: ¡Ahh! Si a esas vamos, a nuestro puntito también lo impulsan algunos de los suyos, como IBM y HP, y otros no menos importantes, como Intel, Fujitsu y algunos más cuyo nombre no puedo recordar.J: Ese problema de memoria también lo deben tener tus patrocinadores, mira que olvidar que pactan con el diablo, a ver qué angelito los ayuda...N: No es un angelito, es una asociación europea de es-tándares, que se llama ECMA. En ella confiamos nuestra

RE

FLE

XIO

NE

S

J2EE Vs. .NetCrónica de una BatallaPor Esmeralda Pita, Alberto González, Enlai Pensado, Yuriy Kotsarenko, Luis Riojas

Un profesor de arquitectura de software en el Tec de Monterrey Campus Cuernavaca recientemente organizó un debate de grupo entre sus alumnos. ¿El tema? La guerra entre plataformas de desarrollo empresarial: .Net vs. J2EE. Días previos al debate se realizó una charla de ensayo, que a continuación reproducimos.

Días después se realizó el deba-te, y como se podrán imaginar, no se llegó a ningún acuerdo. El profesor, viendo cansados y exasperados a sus alumnos (al parecer, tanto unos como otros estaban que echaban fuego por los ojos), optó por enco-mendarles el desarrollo de un artículo que expusiera de forma comparativa las caracte-rísticas de ambas plataformas. En un número próximo de SG compartiremos dicho artículo. Mientras tanto, los invitamos a reflexionar al respecto.

INDEX

Anunciante Páginas SitioAMCIS 55 www.amcis.org.mxAvantare 49 www.avantare.comCutter Consortium 11 www.cutter.com.mxEdutecsa 33 www.edutecsa.come-Quallity 45 www.e-quallity.netGartner 53 www.gartner.com/mx/outsourcingIIDEA Solutions 47 www.iidea-solutions.comImexsoft 37 www.imexsoft.com.mxItera 13 www.itera.com.mxMarx 51 www.marx.comMilestone 19 www.milestone.com.mxMicrosoft F2-1, 56-F3 www.microsoft.com/mexicoOracle F4 www.oracle.com/global/mxRoca Sistemas 43 www.rocasistemas.com.mxSafeNet 31 www.safenet-inc.comSG Conference 07 www.softwareguru.com.mx

TENEMOS UN ESPACIO RESERVADO PARA TISi deseas anunciarte contáctanosen el (55) 5239 5502 o en ventas@softwareguru.com.mx

DIRECTORIO

www.softwareguru.com.mx MAY-JUN 2006 55

w

ww

.sof

twar

egur

u.co

m.m

xS

OFT

WA

RE

GU

RU

CO

NO

CIM

IEN

TO

EN

PR

ÁC

TIC

A

May

o-J

unio

200

6A

ño 0

2 N

o. 0

3

METODOLOGÍAS ÁGILES