SG #09 (Mayo - Junio 2006) by Revista Software Guru

• Requerimientos • Service Level Agreements • Arquitectura de Software

Software Guru CONOCIMIENTO EN PRÁCTICA Año 02 No.03 • Mayo-Junio 2006 • www.softwareguru.com.mx

ESPECIAL

La Industria en cifras [ UML ]

Diagramas de estado

METODOLOGÍAS ÁGILES [ ENTREVISTA ]

Carlos Montes de Oca

CIMAT

Noticias • Eventos • Fundamentos • Reﬂexiones • Tecnología • Carrera

[ PROGRAMACIÓN ]

Spring

DIRECTORIO Edición Ejecutiva Pedro Galván

EDITORIAL

Coordinación Editorial Mara Ruvalcaba Edición y Producción Edgardo Domínguez Arte y Diseño Oscar Sámano, Dafne Ortega

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, habiendo 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écadas 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 adecuado 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 participar en este número. Mil gracias a Carlos Montes de Oca por compartir con nosotros su visión sobre la academia y la industria en que operamos. Por último, les recordamos que pueden enviar cualquier propuesta de contenido, o retroalimentación a editorial@softwareguru.com.mx. Gracias, y que disfruten este número. Equipo Editorial

MAY-JUN 2006

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 Colaboradores Luis 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ón Daniel Velázquez Ilustración de Portada Tollhaus Contacto info@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: 042004-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.

www.softwareguru.com.mx

contenido may-jun 2006

Año 2 número 03

EN PORTADA Métodos Ágiles

Lo ágil es lo de hoy. Conozcamos los principios de los métodos ágiles, así como los mitos y realidades asociados a ellos.

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

Entrevista

Prácticas 12

HERRAMIENTAS 14 Desarrollo Dirigido por Pruebas

ADMÓN de PROVEEDORES 32 Service 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 34 El ABC de un Taller de Requerimientos Mónica Vázquez nos guía a través de lo que se debe hacer para realizar un taller de requerimientos exitoso.

Columnas Tejiendo Nuestra Red por Hanna Oktaba

Mejora Continua por Luis Cuellar

Domingo Suárez nos explica algunas debilidades de JEE, y como sobreponerlas con Spring.

Cátedra y Más por Francisco Camargo

ARQUITECTURA Arquitectura de Software

Tendencias en Software por Luis Daniel Soto

PROGRAMACIÓN Desarrollo JEE Ágil con Spring

Luis Felipe Martínez nos habla sobre los orígenes y trascendencia de la arquitectura de software.

UML Diagramas de Estado Sergio Orozco nos enseña como modelar el estado de un objeto.

www.softwareguru.com.mx

Industria Mexicana de Software en Cifras

Carlos Montes de Oca

En Cada Número Noticias y Eventos Reportaje Fundamentos Infraestructura Carrera Reﬂexiones

04 06 46 50 48 54

MAY-JUN 2006

NOTICIAS

Noticias 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 manejaron 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 lecciones aprendidas, e hicieron diversas recomendaciones para las organizaciones involucradas o prontas a iniciar proyectos de este tipo. Entre las empresas patrocinadoras 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 iniciativas de este tipo. Adicionalmente, los proveedores también reflejaron una mayor madurez en cuanto a su oferta.

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 Integrated) del Instituto de Ingeniería de Software (SEI) tras realizar la evaluación formal en sus áreas de proyectos cerrados (soluciones) y fábrica de software, que se encuentra en Cuautitlán, Estado de México. Con esta evaluación, Azertia se convirtió en la segunda empresa en México en obtener este nivel de CMMI, lo cual pone de manifiesto la capacidad técnica, 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 perteneciente a Corporación IBV (BBVA e Iberdrola), 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

MAY-JUN 2006

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 capacidad 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 convertirnos 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

SigmaTao ya es CMMI 3 Otra empresa que recientemente logró su acreditación en el nivel 3 de CMMI es SigmaTao Factory, fábrica de software mexicana ubicada en Querétaro. Esta evaluación de reconocimiento internacional, se suma a las anteriormente obtenidas (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 Ingenieros 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. www.softwareguru.com.mx

Eventos 13 Mayo 2006

Debian Day

25 y 26 Mayo 2006

Centro Vacacional IMSS. Oaxtepec, Mor. es.debconf.org/debianday

Optimizando los servicios de TI con ITIL e ISO 20000 y Automatizando la administración de TI con ITSM

14 y 21 Mayo 2006

25 de Mayo - Ciudad de México, 26 de Mayo - Monterrey, NL Tel: (55) 5281 76 70 www.itera.com.mx

Centro Vacacional IMSS. Oaxtepec, Mor. debconf6.debconf.org

5 de Junio 2006

DebConf6

16 y 17 Mayo 2006

8va Conferencia Anual Information Security Hotel Camino Real, Ciudad de México Tel: (55) 5340 23 22 www.informationsecurity.com.mx

IDC IT Security & Business Continuity Conference 2006 Centro Banamex, Ciudad de México Tel: (55) 5661 – 3791 www.idc-eventos.com

9 de Junio

TCDS BPM Executive Day 2006 22-24 Mayo 2006

Congreso de Software Libre GULEV 2006 Museo del Transporte. Xalapa, Veracruz www.gulev.org.mx

Ciudad de México Tel: (55) 5639-3742 www.tcds.com.mx/mx/events/bpmxd06.html

27 y 28 de Junio 2006 25 Mayo 2006

IDC Service Oriented Architecture Seminar Hotel Presidente Intercontinental Monterrey, NL Tel: (55) 5661 – 3791 www.idc-eventos.com/soa06

Gartner 2nd Annual Outsourcing Summit Centro Banamex, Ciudad de México Tel: (55) 5584 9370 www.gartner.com/mx/outsourcing

diseñar, desarrollar y probar sistemas para automóviles. “Lo que estamos tratando de hacer aquí es vincular a tres sectores muy importantes para México, nada menos que la electrónica y automotriz, con la que yo considero la más estratégica, que es tecnologías de información y comunicaciones” mencionó Eduardo Ramírez, Director de Soluciones Tecnológicas, la empresa mexicana con la cual el ITESO firmó el convenio que originó este proyecto.

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 objetivo de este proyecto es establecer un centro donde concurran los sectores automotriz, electrónico y de software, para www.softwareguru.com.mx

El centro está ubicado dentro del edificio de Tecnologías de Información del ITESO, en un espacio de 425 metros cuadrados. Se creó con una inversión de cinco millones de pesos, de los cuales el 25 por ciento corrió a cargo del Gobierno federal, 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. MAY-JUN 2006

CLUSTERS

IT@Baja

Una Solución Integral Esta 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 vecino país del norte.

La principal estrategia de IT@baja es promover proyectos que permitan impulsar el crecimiento de las empresas ya instituidas, y la creación de nuevas, para fomentar una alta competitividad en el estado que lleve eventualmente a un grado de excelencia a los distintos proveedores de servicios y productos de TI, lo que consolidará al estado como una alternativa real para empresas norteamericanas en busca de soluciones integrales. Aprovechando la proximidad con los Estados Unidos, y el huso horario compartido con California, este Cluster ofrece gente y empresas que conocen perfectamente la cultura de negocios e incluso laboral de las compañías estadounidenses, 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 Funciones A finales del 2002, como resultado de un estudio para definir las competencias del estado de Baja California. se establecieron los esquemas, conformación y estrategia del Cluster necesarias 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, capacitación, certificación, vinculación, legal, fondeo, etc. • Promover la integración continua de las empresas de este ramo a través de los organismos 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

MAY-JUN 2006

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 subcontratación de desarrollo de software. • Vigilar la imparcialidad de asignación de oportunidades de negocio y proyectos internos 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 negocios, a través de centros de desarrollo de tecnologías de información.

Logros y Metas Dentro de los principales logros a la fecha, IT@baja ha promovido continuamente la interacció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ándares Abiertos. • Comisión Académica e Industria. • Modelo de Desarrollo CT Connect. • Comunidad .Net.

(UABC), con el que se pretende lograr un programa de extensión académica y conformar una plan de acción para el crecimiento de los egresados en las empresas vinculadas al Cluster. Entre las principales metas de IT@baja están: • Iniciar la promoción del Cluster a nivel regional, nacional e internacional. • Promover el soporte gubernamental a organizaciones. • Soporte y alineación de intereses con el sector 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 Empresas La asociación está constituida por distintos 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, administrativas, de recursos humanos, de comercio 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, Everest, G-H & T, BTS, RT Solutions, SmartBC, Cybercorp, Betta Global Systems, LIDASA, Aprovi, GM Consultores, , Tecnología Educativa, EYS, Condete, Infosyst S.C., Intelligence Learning, Imacor, Aster, Interfase Mircrosystems, Arkus, Gr Soluciones, Grupo Tress, Zentrum, Nexus, INTEGRA, Business Ware, Gr Soluciones Computacionales, Condete, Central Software y 4 Integradoras: INTUARE, SDS,iMedis e INTAN.

A la fecha, IT@Baja cuenta con 43 socios activos, 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 certificación de maestros universitarios en tecnología .NET y Java, además de impartir un taller de MoProSoft y un diplomado de Pruebas de Software. Se formalizó un convenio de colaboración con la Universidad Autónoma de Baja California

Asamblea en Mexicali, Marzo 2006

www.softwareguru.com.mx

COLUMNA

TEJIENDO NUESTRA RED

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

ara 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 retrospectiva 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 Cincuenta Se aplica al desarrollo de software el mismo proceso que al desarrollo de hardware, 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.

Sesentas El 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 proceso 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.

Setentas Se 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,

MAY-JUN 2006

acoplamiento débil y alta cohesión, entre otros. Se publica 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 travé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.

Ochentas Se 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 lenguajes de programación. Se crea el primer modelo de madurez 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, herramientas, reutilización, mejora de procesos, entre otros. • Lo que es bueno para el producto es bueno para el proceso, 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.

Noventas La concurrencia (paralelismo y distribución) adquiere mayor 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 orientado 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 iterativo 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. Software 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 softwww.softwareguru.com.mx

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 ambiciosos a menudo traen como consecuencia las especificaciones incompletas, que resultan en mucho re-trabajo.

Situación Actual Los temas nuevos son la agilidad en el desarrollo y el valor para el cliente. Se redacta el Manifiesto de Agilidad en respuesta al estilo promovido por CMM. Surgen nuevos dispositivos (PDAs, celulares) que involucran el ciclo: Aprendizaje-Seguridad-Mejorar su uso. Las cualidades prioritarias de sistemas son: Seguridad/Privacidad, Usabilidad y Confiabilidad. Se incrementa la propagación de software empaquetado COTS (Commercial-Off-The_Shelf ). Crece el entendimiento de las bondades del código abierto. El desarrollo dirigido por modelos (MDD, Model Driven Development) toma fuerza. Se integra el proceso de desarrollo 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 2020 Las tendencias que van a afectar, en el futuro próximo, la forma 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 economí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 contratació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/Masculina/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 www.softwareguru.com.mx

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 proveedores). 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 actividades de múltiples proveedores. Abundancia computacional. La Ley de Moore seguirá vigente 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 computacional, y finalmente, como integrar estos dispositivos a los SOS. Esto va a requerir de nuevos niveles de abstracción para la programación y nuevas herramientas con mayor poder basado en el uso del conocimiento. Autonomía computacional. Es una visión en la cual la Inteligencia 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 utiliza fenómenos moleculares o biológicos para resolver problemas computacionales. Mientras que la biología computacional tratará de mejorar las capacidades humanas, incorporando dispositivos al cuerpo humano.

Este resumen lo presenté recientemente en la reunió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

La Dra. Hanna Oktaba es profesora 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 fundadora de la AMCIS, de la cual actualmente 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 miembro de International Process Research Group (IPRC), organizado 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 COMPETISOFT, cuyo objetivo es la mejora de procesos para fomentar la competitividad de pequeña y mediana industria de software en Iberoamérica.

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

COLUMNA

MEJORA CONTINUA

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

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.

ace 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 metodologí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 consideraban 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 porque en realidad yo no veo a estas estrategias peleadas entre sí, sino que de alguna manera podrían ser complementarias.

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 Google, 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.

En Esta Esquina...

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 “Planning Game” hasta la programación en pares. Esto permite lograr consistencia en diferentes proyectos. Así que documentar el proceso me parece una excelente idea.

Antes de iniciar esta plática quiero dejar algo totalmente claro: en mi trabajo de día con día me he topado con un sinnúmero 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. Nuevamente, 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 seguidores de metodologías ágiles defienden el que cada quien haga lo que sea más eficiente para su proyecto. Esto me llevó a la pregunta, ¿qué son las metodologías ágiles y cómo se diferencian de la anarquía? Así que decidí investigar un

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 modelos como CMM no entran en esto en forma tan específica. Sin embargo, si esto es viable en el proyecto que estamos desarrollando, me parece definitivamente una excelente forma de actuar, yo diría que tomemos esto como práctica.

Tipo de comunicación. Posiblemente, el punto más controversial es que las metodología ágiles enfatizan la comunicació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 documentación para las decisiones que se llevan acabo en forma inmediata es la ejecución, pero en un mundo de negocios

CMM

Manifiesto Ágil

• Mejora continua de trabajo.

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

• Define, documenta y utiliza procesos.

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

• Compromiso de la alta dirección.

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

• Deben de existir procesos estables a tra-

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

vés de la organización.

en su capacidad para cumplir con el trabajo.

• Mide los procesos para ver si estas cum-

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

pliendo tus objetivos

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

• Controla los procesos de la organización

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

• Mejora los procesos en forma 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.

MAY-JUN 2006

www.softwareguru.com.mx

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 documentar y registrar solamente eso. Métricas. Otro punto fundamental en las diferencias es que CMM nos pide medir nuestros procesos, mientras que Ágil nos pide que continuamente mejoremos lo que hacemos, pero no nos pide medir nada para decidir qué mejorar. 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 racionales sobre lo que pueden mejorar. No hay una solución única, la organización debe tomar

una postura. Lo único es que cualquier decisión que tomemos debe de ser apoyada por otros procesos, esto quiere decir que si vamos a medir, debe de haber toda una infraestructura 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 entendimiento 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 cambio, implantarlas no es simple. De hecho, implantar el modelo ágil correctamente puede 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 viendo los diferentes modelos de desarrollo de software como una gran pelea que busca a el gran ganador, sino como un grupo de herramientas 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 ganador debe ser el cliente. Si quieres platicar más sobre el tema nos vemos en www.agentesdecambio.org o escríbeme a lcuellar@agentesdecambio.org —Luis Cuellar

PRODUCTOS

LO QUE VIENE

RedHat Adquiere JBoss

RedHat Aumenta el Alcance de su Oferta

Atlas

Licencia GoLive y Control Toolkit

Atlas, el framework de Microsoft para desarrollo de aplicaciones web “ricas”, ya se ve bastante maduro. De hecho, junto con el CTP (Community Technology Preview) 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 herramientas y componentes para que los desarrolladores puedan generar controles interactivos basados en tecnología Ajax, que se conecten fácilmente con componentes .Net del lado del servidor. El toolkit incluye el código fuente, documentació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

Dos de las empresas más importantes 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 dependiendo del desempeño de JBoss. Con esto queda demostrado el valor de las empresas open source. Con esto, Red Hat aumenta la profundidad de su “stack” de infraestructura de TI open source, lo cual lo pone más cerca de competir directamente con proveedores como Novell, y Microsoft.

PRODUCTOS

NetBeans Enterprise Pack

SQL Developer

Sun Microsystems anunció que abrirá como software libre, componentes 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.

De acuerdo con Oracle, ya es hora de que sus desarrolladores 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 utilizar para desarrollar aplicaciones, así como para migrar otras bases de datos hacia Oracle.

Herramientas Open Source para Desarrollo Empresarial

Algunas de las capacidades incluidas en el NetBeans Enterprise Pack serán: Modelado bidireccional UML. Con esto se pueden generar diagramas 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 aplicaciones compuestas que funcionen dentro de arquitecturas orientadas a servicios y orquesten procesos de negocio. Esta tecnología se obtuvo gracias a la adquisición de la empresa SeeBeyond.

Adiós a SQL Plus

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

Mayor información en www.netbeans.org

MAY-JUN 2006

www.softwareguru.com.mx

PRODUCTOS

HERRAMIENTAS

Desarrollo Guiado por Pruebas Automatización de Pruebas Unitarias Por Ariel Súcari

l desarrollo guiado por pruebas (test-driven development), o TDD, es una de las principales prácticas de Extreme Programming (XP), que propone una serie de pasos para probar antes de programar (test-first programming).

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

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 tiene el diseño más simple para la funcionalidad que acaba de agregarse.

Ventajas

Una vez que estos pasos son llevados a cabo, se realiza lo que motiva a la metodología: la ejecución de todas las pruebas automatizadas que se tienen construidas hasta el momento. Podemos visualizar gráficamente el párrafo anterior en el siguiente diagrama de actividad en UML.

• Requerimientos de última hora. ¿Cuántas veces un requerimiento introducido 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 afecte otras partes del sistema. • Se desarrollan 100% de las pruebas. Todas las pruebas se realizan 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 requerimientos 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 finalizar nuestro desarrollo habremos cubierto en 100% los requerimientos 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 interpretació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 interfaces 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ía Después de involucrarme un tiempo con la metodología de desarrollo guiado por pruebas y de disfrutar sus virtudes y sufrir sus defectos, he aprendido a resolver estas limitantes a través del

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 coordinado proyectos de la disciplina de pruebas en Inglaterra, Estados Unidos, Venezuela, Argentina y México durante los últimos 7 años.

MAY-JUN 2006

www.softwareguru.com.mx

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

Problema 1: Interfaces Gráficas La 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.

Problema 2: El éxito Depende de los Casos de Prueba Para evitar el problema de tener casos de prueba que no concuerden 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 IBMRational 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 procedimiento para generar los scripts está metodológicamente explicado y no da lugar a errores u omisiones. Algunos beneficios adicionales de capturar 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 pruebas para reducir el error humano.

Las herramientas que no cuenten con una tecnología semejante a la descrita, no lograrán reconocer la casilla de verificación y requerirá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. www.softwareguru.com.mx

Conclusión Más allá de las herramientas, es importante que se entienda el concepto que está detrás de todo esto. El principal objetivo es lograr que los casos de prueba automatizados, 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 importante, 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 objetivos propuestos.

MAY-JUN 2006

Industria Mexicana del Software Un estudio en cifras Por Dora Luz González

n julio de 2005 se aplicó una encuesta a 68 gerentes de empresas del sector de la Industria del Software de México para conocer el perfil general de éstas y analizar los factores críticos de éxito del sector. Dicha encuesta forma parte de un trabajo de investigación sobre el estudio de estrategias para generar ventajas competitivas en la industria del software, realizado en la Universidad Polité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 generalizables 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 representativos, y no necesariamente significa que sean generalizables. Localización Geográfica de las Empresas Participantes Las empresas participantes en el estudio se localizan 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 Durango, 2.9% en el Estado de México, 1.5% en Guanajuato, 2.9% en Jalisco, 2.9% en Michoacán, 2.9% en Morelos, 23.5% en Nuevo León y 2.9% en Querétaro. Esta concentració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éxico La 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

MAY-JUN 2006

www.softwareguru.com.mx

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 Empresas El estudio revela que el 85.29% de las empresas del sector de la Industria Mexicana 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 empleados)

Rango

Porcentaje

Micro Pequeña Mediana Grande

1 a 10 11 a 50 51 a 100 + de 101

54.41 30.88 5.88 8.82

Tabla 1. Tamaño de empresas

Número Promedio de Empleados por Tamaño de Empresa Al 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 introducido 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 Empresas La 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 empresas 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 bloques de antigüedad de empresas: emergentes, maduras y consolidadas (ver tabla 2). Antigüedad

Porcentaje

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

47.1

En miles de pesos mexicanos

Porcentaje

0 a 50 51 a 100 101 a 200 201 a 500 501 a 1,000 1001 a 3000 3001 a 6000 6001 a 12000 12001 a 30000 30,001 o más

3.0 4.5 3.0 7.6 12.1 19.7 7.6 16.7 9.1 16.7

Tabla 3. Estadísticos descriptivos de rango de ventas anuales.

El 85.29% de las empresas del sector son micro o pequeñas. Utilidades La mediana del rango de utilidades de las empresas participantes en el estudio, en los últimos dos años, se encuentra entre el 6 y el 10%. Rango de utilidades

Porcentaje

Pérdidas 0 al 5% 6 al 10% 11 al 15% 16 al 20% 21% o más

11.5 19.7 21.3 18.0 13.1 16.4

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

42.6 10.3

Tabla 2. Antigüedad.

Rango de Ventas Anuales De 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). www.softwareguru.com.mx

En los tres últimos años el sector de la Industria del Software de México ha registrado tasas de incremento más elevadas 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 participantes manifestaron no haber tenido crecimiento laboral, MAY-JUN 2006

ESPECIAL

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

País (2005) Filipinas Turquía Tailandia India Colombia China Brasil Emiratos Árabes Unidos Sudáfrica Singapur México Corea España Bélgica Nueva Zelanda Australia Canadá Japón Israel Suecia Finlandia Holanda Francia Irlanda Reino Unido Noruega Estados Unidos Alemania Hong Kong Suiza

Salario mensual promedio en USD $283 $438 $510 $570 $875 $899 $933 $1,508 $1,558 $1,616 $1,865 $2,183 $2,480 $2,714 $2,743 $3,159 $3,166 $3,166 $3,333 $3,408 $3,417 $3,483 $3,532 $3,532 $4,117 $4,178 $4,416 $4,634 $5,055 $5,480

Tabla 5. Comparativa del salario mensual medio de un programador de software en varios países.

MAY-JUN 2006

un 27.94% un crecimiento negativo (despidos), el 52.94% haber tenido un incremento en su plantilla laboral hasta de un 8% y un 2.94% indicó tener un crecimiento 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 crecimiento laboral tuvieron fueron las empresas micro (17.65%) y pequeñas (16.47%). Origen de los Ingresos Económicos En 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 desarrollo 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 mantenimiento de hardware. ¿Y los sueldos? En la tabla 5 se muestran los salarios mensuales medios de un programador —en categoría: Software Engineer / Developer / Programmer— para varios países donde se puede observar una gran variación en los niveles de remuneración de esta actividad, desde un salario mensual medio de USD $283 en Filipinas, 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% indicó que cubre mercados locales, 11.86% mercados regionales, 26.24% tiene cobertura nacional y 7.12% indica tener presencia 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 mercados 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 sirvieran como base para identificar y clasificar a los grupos con base a su orientación estratégica de negocio (costo y diferenciación),

se tomaron en cuenta las consideraciones teóricas de: Michael Porter, Gerry Johnson 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 servicios especializados. Como resultado final para la clasificación de las empresas en función de su orientación estraté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ón En 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 presentando 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 aquellas personas, empresas e instituciones públicas 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 PROSOFT, AMITI y AMCIS. Referencias 1. SE (2004), “Estudio del nivel de madurez 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 metropolitana” 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 Servicios Relacionados” Secretaría de Economía, México,Fase 1 / Criterio 2. www.softwareguru.com.mx

MAY-JUN 2006

ENTREVISTA

Dr. Carlos Montes de Oca Centro 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. ¿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 aspecto de ingeniería de software, o que requieran de capacidades especiales. Debo recalcar que el objetivo del CIMAT no es vender servicios y competir con empresas proveedoras de servicios y consultoría en ingeniería de software. 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 mismos 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 académicos pueden combinar un poco más la investigació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 Sistema 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 aplicar técnicas de ingeniería al desarrollo de software. 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 simplista pero siento que captura el feeling. A fin de cuentas, la gente es lo que le da sabor a la ingeniería de software. Mucha gente en el ám-

MAY-JUN 2006

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, porque si queremos detonar la industria de software, debemos desarrollar a la gente, a los profesionistas de software. Y éstos no necesitan 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 necesitamos desarrollar la capacidad para generar ingenieros de software que cuenten con los conocimientos técnicos necesarios, pero tambié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 trabajadores, pero por otro tendemos a ser indisciplinados. 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 cuando 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 ingeniería y la calidad en el software reditúan en dinero. Para lograr esto debemos recabar informació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 directivos en México están acostumbrados a una forma de dirigir de “látigo” o capataz. No confiamos en que nuestros ingenieros tengan la capacidad de proveer resultados de forma autónoma. Y probablemente esto sea cierto (que en general no se tenga esa capacidad), por eso es necesario generar esa masa crítica de buenos y verdaderos ingenieros de software. ¿Qué crees que debería saber un recién graduado de nivel licenciatura? Si pretendemos competir con la India, deberí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 capacitación. Esto es algo que no podemos hacer en México, dado que la industria no puede soportarlo. Así que los egresados deben salir listos para ser productivos en la industria. ¿Crees que la academia en México está haciendo 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 fundamental que los profesores participen en proyectos de la industria, y que los alumnos 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? Sewww.softwareguru.com.mx

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 software deberían tener al lado una fábrica de software o algo donde los alumnos puedan participar en proyectos reales. Porque la ingeniería de software es especial y requiere 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 grande 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écnicas 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 analogí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 escritorios y unas máquinas depreciadas. Como industria, debemos reconocer que estamos hechos de personas, y que éstas son nuestro principal activo. Así que debemos tenerlas bien “aceitadas” (a través de capacitación y motivación) para obtener su máximo rendimiento. www.softwareguru.com.mx

MAY-JUN 2006

EN PORTADA

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. Las necesidades de un cliente pueden sufrir cambios importantes del momento de contratación de un proyecto de software, al momento 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 deben: • 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.

MAY-JUN 2006

• Probar desde temprano y de manera continua, para encontrar defectos antes de que tengan 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 “Ágiles”. 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 reunieron 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 documentación abundante. • Colaboración con los clientes por encima de negociación de contratos.

• Respuesta al cambio por encima de seguimiento 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 reconocimiento 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 aplicació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. www.softwareguru.com.mx

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

Diferentes Sabores para Distintas Necesidades Existe 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.

eXtreme Programming (XP) www.extremeprogramming.org

XP es probablemente el método ágil que más atención ha recibido desde que fue dado a conocer en 1999 a través del libro “Extreme Programming 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 fundamental 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 edició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 posible medir el producto que se está desarrollando, 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 retroalimentación, es una herramienta poderosa. • Respeto. Los valores anteriores implican respeto. 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), inwww.softwareguru.com.mx

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

Scrum www.controlchaos.com

Scrum fue desarrollado durante los ochentas y noventas por Ken Schwaber, Jeff Sutherland y Mike Beedle. Este método se concentra en la administración de los proyectos de software, dividiendo el desarrollo en iteraciones 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 define actividades ni técnicas específicas para la construcción de software. En cambio, se concentra en las reglas de funcionamiento de un equipo de trabajo para poder producir sistemas flexibles en un ambiente de cambios. Dado que Scrum hace poco énfasis en las actividades de ingeniería, es común complementarlo con otros métodos fuertes en cuanto a prácticas de ingeniería, como lo es XP.

Crystal

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

para diferentes tipos de proyectos, y las organizaciones 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 cristales son caracterizados por su color y dureza. El tamaño del proyecto indica el método a utilizar —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 indica 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, procesos, o incluso herramientas, podríamos decir que Crystal está “centrado en personas” (people-centric). A pesar de su popularidad, no existe un sitio web que sirva como punto central para conocer más sobre Crystal. El sitio de Alistair Cockburn (alistair.cockburn.us) contiene referencias a algunos sitios y artículos, sin embargo la mejor fuente de conocimiento sobre Crystal es el libro titulado Crystal Clear, escrito por Cockburn y publicado por Addison Wesley en 2004. MAY-JUN 2006

EN PORTADA

Scrum

Caos Controlado Por 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”.

Historia

En 1995, Ken Schwaber, un metodólogo de software reconocido, decidió descubrir porqué las metodologías de desarrollo funcionaban tan mal cuando se intentaban seguir al pie de la letra. Con este fin, reunió a varios expertos 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 procesos: • El proceso definido, en el que todos los elementos y componentes son bien conocidos y controlados. Dado un conjunto de entradas, se obtiene un conjunto de salidas igual y consistente siempre. • El proceso empírico, por otro lado, espera lo inesperado. Como no se conoce el proceso con suficiente 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 actividad tan profundamente intelectual, y que necesita tanta creatividad, es un mal candidato al proceso definido. El desarrollo de software, entonces, no debería entenderse como una línea de montaje, sino como una serie de inspecciones constantes acompañadas de correcciones 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 proceso la auto-organización

Roles de Scrum

Hay 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 Scrum

El 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 trabajo, el dueño del scrum (scrum-master) y los patrocinadores del proyecto. En esta reunión, los patrocinadores exponen y aclaran los requerimientos 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 puede entregar al final del sprint – el alcance acumulado 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 semana. 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 Scrum

La 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 participar 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 quitarlos de en medio, fungiendo como un facilitador 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 resuelvan 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 mostrar 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 informarle con tiempo que no se va a lograr la meta, pero que es lo que sí es realmente factible. En el caso remoto de que los resultados sean de verdad terribles, es posible cancelar todo el sprint.

Sashimi

El 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 pedacito del todo que está listo para consumirse en cualquier momento. Cuando se planean las actividades 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 manual de usuario, por ejemplo.

La Presentación

Al 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 importante que el producto final del sprint tenga

Luis Guerrero es Arquitecto de Sistemas en el Sistema de Administración Tributario (SAT). Sus áreas de especialidad son procesos, ingeniería de software, seguridad 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.

MAY-JUN 2006

www.softwareguru.com.mx

Cada sprint dura un mes y se cierra con una presentación

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 mismo. 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 trabajo, 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. www.softwareguru.com.mx

Es muy difícil otorgarle al equipo de trabajo el control que requiere scrum. La técnica es aventurada, 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 Funciona

A continuación comparto una lista de las trampas más comunes de una implementación primeriza de scrum en una organización con métodos tradicionales, y que en mi experiencia 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 avance. Los participantes del equipo deben ver la junta scrum como una oportunidad para resolver sus problemas inmediatos. Una clara señal de que las juntas no están funcionando 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 situació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 necesarias en el sprint. Esto es, se viola el principio del sashimi, siempre tener un producto entregable para el usuario final. Es muy común que en los primeros sprints se olviden algunas actividades, típicamente las que se podrían clasificar de poco ágiles o poco sexy, como mantener los documentos o los manuales de usuario. Es normal, 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 desincentivar 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 funcionalidad en tiempo y en forma. Referencias • www.controlchaos.com • Ken Schwaber. Agile Project Management with Scrum. 2004, Microsoft Press MAY-JUN 2006

EN PORTADA

Mitos y Realidades Conociendo los Extremos Por John Gomez

Si bien las metodologías ágiles venían gestándose y aplicándose desde los años noventa, la formación de la Alianza Ágil y subsiguiente publicación del Manifiesto para Desarrollo de Software Ágil en febrero del 2001, marcaron una inflexión en el uso de procesos para desarrollo de software desatando una fuerte polémica entre promotores 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 resolver 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.

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.

MAY-JUN 2006

www.softwareguru.com.mx

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 agradecerle, XP nos cambió la vida, sin embargo, ahora tenemos algunos problemas con el testing. Kent Beck: Muchas gracias. ¿Quiere decir que no logran 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 criterio. 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 procesos 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 sabemos lo que usted quiere, incluso si usted no”. • Software funcional sobre documentación exhaustiva. Traducción: queremos pasar todo el tiempo codificando. ¡Los verdaderos programadores no escriben documentos! • Colaboración con el cliente sobre negociación de contratos. Traducción: “no perdamos tiempo discutiendo detalles, eso limita nuestra 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 discusió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 fracasado. Para otros, las metodologías ágiles eran sólo una excusa para desarrollar software sin planes, diseño ni documentación. Ambos www.softwareguru.com.mx

extremos son erróneos; por una parte, varias prácticas ágiles tienen nichos donde funcionan muy bien, pero hay otros ambientes donde pierden su efectividad o deben ser modificadas para lograr el objetivo. Sólo hay que imaginar realizar la reunión diaria de seguimiento que propone SCRUM, XP o Crystal en un proyecto con cincuenta personas. Tampoco es correcto que lo ágil se contraponga a la ingeniería de software. De hecho, muchas prácticas ágiles vienen de estudios realizados desde antes de la década de los sesentas. Varios de los autores de estas metodologías vienen de la comunidad de desarrollo orientado a objetos, donde se gestaron varios de los avances más importantes en arquitectura 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 Cascada

Después de conocer tantos equipos de proyecto aún me asombra como para muchos el único ciclo de vida conocido es el de cascada, donde se ejecutan secuencialmente las actividades 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 ágiles 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 cincuenta. 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 secuencial. 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 cambios a los requerimientos en etapas posteriores 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, reconociendo que el cambio es innegable y que por lo tanto

siempre habrá que volver atrás para refinar sucesivamente 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 mantenimiento 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 gestión de configuración e integración deben ser mucho más rigurosos en el desarrollo incremental. 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 arcaí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. Agilidad

La 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 interpretación de que en las metodologías ágiles se desincentivan las prácticas de ingeniería de software. Esto se complementa con la aparentemente declarada aversión a la documentació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 resultados se validan continuamente a la luz de lo construido. Según esto, el equipo dedica diariamente 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 puede 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 interpretaciones han llevado a que una compañía tenga un estándar de plan de proyecto de 20 secciones y 40 páginas y lo exija para todos sus proyectos sin importar si uno es de 60 horas hombre y otro de 6000. MAY-JUN 2006

EN PORTADA

Un equipo que se reune diario y sabe qué está haciendo cada quien, está mejor preparado para el cambio

También he visto como compañías exigen a sus equipos documentar el diseño usando TODOS los diagramas de UML, sin distinció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 extremas 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 requerimientos 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 entendimiento de esta forma?

“Predecible” versus “Adaptable”: ¿Planificamos o No?

Varios agilistas han coincidido en describir los procesos ágiles como “adaptables” en contraposición a los métodos tradicionales o “dirigidos por planes”. Hay malas interpretaciones sobre esto también. Los agilistas critican que se pretende planificar en excesivo detalle asumiendo que hay una capacidad de predicción que no es posible. Los tradicionalistas responden afirmando 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-

MAY-JUN 2006

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 propone esto como buena práctica. Por otro lado, es erróneo indicar que en los métodos ágiles no hay planificación. Todos incluyen 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 finalmente 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 tradicionales indicando que no pueden o no saben lidiar eficientemente con el cambio. Malas interpretaciones han llevado a equipos a establecer excesivos y rigurosos procesos de control de cambio. Pocos métodos tradicionales establecen que el cambio debe ser limitado. La incertidumbre en los requerimientos y por lo tanto la omnipresencia del cambio ha sido aceptada desde siempre.

El Factor Humano

Uno de los puntos más distintivos de las metodologí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 tradicionales 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 tradicionales 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 presente ha compartido de mejor forma el conocimiento y la experiencia y está más preparado para soportar un cambio en el equipo, que otro donde el análisis está perfectamente documentado, pero sólo una persona lo entiende.

La Necesidad del Balance

Son muchos temas más los que se han discutido a lo largo de esta polémica y que no alcanzamos 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 desastrosas. Antes podía decirse que estos nichos eran independientes y un equipo podía escoger entre 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 esquema 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, aumentaremos 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 experiencia para el equipo y la organización. Referencias 1. 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 Methods 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 www.softwareguru.com.mx

Una Plática con Jim Highsmith

Administración Ágil de Proyectos Jim Highsmith es miembro fundador de la alianza ágil, y uno de los “agilistas” más reconocidos internacionalmente. 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 impartir 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.

Las Fases de un Proyecto Ágil

Visualizar. Se genera una visión colectiva sobre el producto de software a desarrollar. Especular. Se establecen hipótesis sobre las especificaciones del producto, sabiendo que conforme el proyecto avance, estas especificaciones irán evolucionando. Explorar. Se implementan las especificaciones de forma iterativa. Adaptar. Se analizan los resultados de dichos experimentos y se realizan los ajustes necesarios para las siguientes iteraciones. Se evalúan cuatro aspectos: funcionalidad del producto, calidad técnica del producto, estatus del proyecto, 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.

Patrones para la Adopción de Ágil

En 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 control/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 durante un tiempo o para cierto tipo de proyectos. Sin embargo, cuando las organizaciones se enfrentan con proyectos más innovadores, donde 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 llamo “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 organizaciones cuyo negocio es el software, he www.softwareguru.com.mx

notado una tendencia de pasar directamente del caos al control adaptable. Para ellos, no tiene mucho sentido pasar por el control prescrito, 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 trabajando en algún proyecto novedoso, y decía “nosotros queremos usar Ágil”. Así que acercaban 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 organización. Actualmente estoy colaborando con una empresa en Boston donde estamos implantando Ágil para 500 ingenieros, en un periodo de tiempo bastante corto. Ese tipo de adopciones no sucedían hace un par de años.

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 Distribuidos

Existe 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 adicionales (wikis, instant messengers, videoconferencia, etc). Lo que hay que evitar es tratar de sustituir la colaboración y comunicación con documentació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, reorganizar. 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. MAY-JUN 2006

COLUMNA

CÁTEDRA Y MÁS

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

¿C

uál metodología de desarrollo utilizo? Una respuesta frecuente es: “ninguna”. Los ingenieros de software generalmente pensamos que desarrollar 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 manera estructurada y sistemática. Esto implica utilizar una metodologí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. El Dr. Francisco José Camargo Santacruz es profesor investigador de los Departamentos de Sistemas de Información y Ciencias Computacionales en el Tec de Monterrey, Campus Estado de México. Su área de especialidad es la Integración de Tecnología de Información en las Organizaciones. Francisco está certificado como IT Service Management (ITIL Foundation), ha sido consultor de diversas organizaciones en Colombia y México, tiene diversas publicaciones en revistas de circulación internacional y pertenece al Sistema Nacional de Investicagores (SNI).

Un rol fundamental para fomentar el uso de alguna metodología de desarrollo de software lo tiene la academia. Esto implica dos retos; el primero es convencer a los alumnos sobre la importancia 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 Estrategia Usualmente, cuando a un estudiante se le plantea una problemática de negocio, su primera reacción está en la solución técnica del mismo. Las primeras ideas que le vienen a la mente 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 brazo 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 entendimiento 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 predefinidos, 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 “Extreme Programming”, madurar los procesos a través de modelos como CMMI, etc. En fin, las opciones son diversas y los resultados también, de ahí la importancia de definir cuál es la metodología de desarrollo para la organización.

MAY-JUN 2006

Aplicación en Proyectos Reales La 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 pregunta “¿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 habilidades, el establecimiento de los alcances, la administració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écnica didáctica de Aprendizaje Basado en Proyectos (POL, Project Oriented Learning).

Conclusión El salón de clases ya no es más un espacio solamente teórico, los problemas reales de las organizaciones vienen a las instituciones académicas y el trabajo conjunto 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 contratar 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 estudiantes de manera formal (y con base en metodologías) como parte de su plan de estudios es una relación ganar-ganar para todos; los estudiantes adquieren experiencia, las organizaciones resuelven problemáticas de negocio y las universidades creamos vínculos estrechos 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 www.softwareguru.com.mx

www.softwareguru.com.mx

MAY-JUN 2006

PRÁCTICAS PROCESOS ADMINISTRACIÓN DE PROVEEDORES

SLAs Orientados a Requerimientos de Negocio PERSPECTIVA DEL PROVEEDOR 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-Proveedor de TI, y dimos algunos lineamientos básicos para que el cliente defina sus requerimientos en base en sus objetivos de negocio. De acuerdo a lo prometido (y lo prometido es deuda), en esta segunda parte les presento algunos lineamientos para la definición de SLAs, desde la perspectiva del proveedor. De acuerdo a lo que planteamos en el artículo 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 peligrosí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 objetivos 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 medida, Tercerización de Soporte e Infraestructura, y servicios de consultoría asociados, coexisten delicadamente en un ecosistema lleno de amenazas internas y externas, entre las que podemos citar la feroz competencia 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

MAY-JUN 2006

Por Axel Nissim S.

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 accidentales, sino producto de un proceso metódicamente calculado por nosotros los proveedores. 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, necesitamos 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 clientes, 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 propias métricas y mediciones respecto a nuestro desempeño en nuestros diferentes compromisos. • 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 mediciones, 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 nuestro desempeño, que con definir propuestas de valor inmediato para nuestros clientes. www.softwareguru.com.mx

Una vez que todos los puntos anteriores han sido implementados para una cantidad significativa de contratos y proyectos, viene el momento de redefinir nuestra estrategia con base en los datos obtenidos de los diferentes análisis efectuados. Para esto, seguiremos los siguientes puntos: 1. Partiendo de los diferentes Business Cases y tipos de proyecto, obtener los Cost Drivers que se han visto impactados significativamente a lo largo de nuestras relaciones con clientes. Estos serán nuestras variables objetivo, 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 promesas, los objetivos de alto nivel que nuestro cliente alcanzará. 3. Analizar las mediciones y métricas internas de nuestra organización, que nos permitirán conocer lo que habitualmente es vendido, las variables operativas del proyecto 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 negocios de nuestros clientes. 4. A partir de los diferentes escenarios pronosticados estadísticamente, calcular nuestras propias variables de negocio que nos permitirán conocer los diferentes puntos de equilibrio, retornos de inversión, así como márgenes aceptables de desviación respecto a lo planeado para cada uno de nuestros compromisos y proyectos. Esto eventualmente se transformará 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 marometas por parte de nuestro equipo de ventas.

Este es un punto distintivo que contribuirá fuertemente 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 impactadas. • Cost Drivers a ser impactados. • Especificación de Tiempos, Esfuerzos, Recursos 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 preventa 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 contratos correspondientes.

Conclusión El beneficio de presentar propuestas de este tipo a nuestros clientes es inmediato 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 dependa 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 objetivos de negocio. • Para la industria: alcanzar la madurez de servicios y productos. • Para las personas que trabajan en nuestras organizaciones: remuneración justa sin compromiso a la ética profesional.

PRÁCTICAS REQUERIMIENTOS

El ABC de un Taller de Requerimientos PLANEACIÓN Y LINEAMIENTOS

l 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 ampliamente 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.

Por Mónica Alegría Vázquez

• 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 desarrollo. • El facilitador del taller debe ser un ingeniero de requerimientos experimentado (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.

Una técnica recomendable para generar esto es el taller de requerimientos. Un taller de requerimientos nos permite 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 requerimientos exitoso.

A continuación les muestro un ejemplo de una agenda detallada para una primera 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.

Identificar Involucrados

Necesidades de Negocio

El primer paso consiste identificar y/o verificar quiénes son los patrocinadores, tomadores de decisión, y usuarios representativos. Una vez identificados, debemos asegurarnos 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.

Existen diferentes técnicas para desarrollar y capturar las necesidades del negocio. 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 participació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.

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

El moderador se abstendrá de intervenir en proposiciones de solución, simplemente 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 mismo grupo determinará la viabilidad de sus peticiones y tomará las decisiones pertinente de las implicaciones.

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 especialidad 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 instituciones gubernamentales.

MAY-JUN 2006

www.softwareguru.com.mx

Elementos de Apoyo Regresando a materia, para captar las necesidades de negocio tendremos que cumplir con este proceso básico:

Para alguien que inicia con los talleres, recomiendo dibujos, y posters mezclados con diagramas de flujo sencillos para una primera sesión. Los participantes también podrán aportar sus propios elementos visuales. Debemos tomar consciencia que nuestros participantes no tienen 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 Taller

Figura 1. Flujo para captar necesidades de negocio.

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:

Una vez aseguradas las necesidades de negocio, las cuales no pueden 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 almacenando el contenido en un documento que bautizaremos como “Resultados 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 absolutamente necesario que ustedes planeen sus talleres para obtener esta misma serie de entregables, pero es una buena referencia:

Elemento Visual

Usos

Limitaciones

Póster

Refleja y dibuja temas o conceptos, muestra agenda.

Describe un simple punto o concepto.

Lista

Pasos del proceso de lluvia de ideas, define expectativas, identifica una serie de ítems.

Difícil para comparar lote de ítems capturados.

Flujos, flechas

Causa y efecto, secuencia de una progresión.

Implica una secuencia que podría ser no correcta.

Matrices

Define elementos faltantes, facilita la comparación.

Puede comparar únicamente pocos elementos al mismo tiempo

Dibujos

Visión, historias, planes, conceptos de negocio.

Los dibujos por la calidad no pueden reflejar la idea.

Ideas, categorías, texto e imagines, jerarquías.

Complejo de leer

Mapa mental

www.softwareguru.com.mx

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.. MAY-JUN 2006

PRÁCTICAS PROGRAMACIÓN

Spring Framework DESARROLLO JEE AGIL

2EE (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 transaccional 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 JEE Toda 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últiples 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 overhead 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 Domingo Suárez

Una Alternativa Entre las alternativas disponibles para suplir las debilidades de JEE en persistencia, 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 Hibernate 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 tambié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 programar código sumamente acoplado. Sin embargo, esto si seguimos el principio de diseño que dice “programa hacia una interfaz, no hacia una implementació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.

Por otro lado, está el tema de los EJBs. Es común asociar de inmediato JEE con EJBs. Esto en cierta medida es correcto. pero JEE no es sólo EJBs. Muchos de nosotros hemos sufrido, perdó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 propone la utilización de Session Beans en sus dos modalidades: con estado y sin estado. En la mayoría de los casos, esto implica mezclar código de negocio con APIs de EJBs. Adicionalmente, 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.

} } 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; } }

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

MAY-JUN 2006

www.softwareguru.com.mx

En este ejemplo definimos dos interfaces. La primera, como su nombre 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, evitando 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 ClienteServiceImpl 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 mencioná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 inconveniente, 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 observan de nuevo, el código del servicio sólo contiene la lógica de negocio, 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 podemos 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.

PRÁCTICAS PROGRAMACIÓN

Mejor Usemos Spring Una 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 ApplicationContext en sí, es una factoría de beans, porque en base a cierta 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”

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 aplicaciones, 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. Asimismo nos proporciona una jerarquía de excepciones que encapsulan 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, Hibernate, 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 abstracciones que Spring nos provee con algunas de sus clases (TemplatesClasses, SupportClasses).

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

</beans>

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 queramos. Los invito a que se familiaricen con Spring, es un excelente framework. 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.

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 donde 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-

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

MAY-JUN 2006

www.softwareguru.com.mx

TENDENCIAS EN SOFTWARE

COLUMNA

¿Quién es el Desarrollador de Software en México?

os 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) profesor de negocios, c) estudiante en ingeniería, d) estudiante 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) aplicaciones de escritorio, c) aplicaciones de base de datos, d) aplicaciones móviles, e) aplicaciones web, f ) aplicaciones sobre plataformas empresariales, g) desarrollador de juegos, 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 desarrollo, e) documentador, f ) analista, g) otros roles

Figura 1. Edad de los desarrolladores.

Dimensionar a esta audiencia en México depende detalladamente 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 administrador de proyecto. Además de esto, encontramos demografías diversas. Los más recientes estudios de Microsoft en Mèxico arrojan algunos datos 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 javascript con 59% y Java con 41% (ver figura 2). • En México, 19% de los desarrolladores en los pasados 6 meses han utilizado productos y herramientas de código abierto. • 50% de los desarrollos usan base de datos de forma integrada. 80% de los desarrolladores han creado aplicaciones de 2 capas y 47% de 3 capas. • 61% de los desarrolladores en México han creado aplicaciones 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 educació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 descendente) en: Distrito Federal y Zona metropolitana, Nuevo León, Jalisco, Tamaulipas, Veracruz, Coahuila, Chihuahua, Puebla, Baja California, Sinaloa, Guanajuato, Sonora, Querétaro. www.softwareguru.com.mx

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

¿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á fundamental para la subsistencia – intégrese y participe activamente 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 fueron entrevistadas previamente, siempre personalice su currículo a cada posición. 3. Si tiene su empresa de software, desarrolle la madurez empresarial de su empresa o busque a su contraparte comercial y no tema incursionar en habilidades de ventas y mercadotecnia. Conozca a fondo los programas de apoyo a empresas de software de los grandes proveedores y del gobierno.

Luis Daniel Soto Maldonado es Director de Evangelización en Nuevas Tecnologías en Microsoft México. Entre sus funciones actuales están la administración de la relación con el Gobierno Mexicano para el desarrollo de la industria de software (ProSoft). Luis Daniel es jurado del “Gran Orden de Honor al Mérito Autoral” en software del INDAUTOR/SEP y fundador de diversas asociaciones de Tecnologías de Información (TI) relacionadas a inteligencia competitiva, administración del conocimiento y construcció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 exportación en 1989. blogs.msdn.com/ luisdans

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

PRÁCTICAS ARQUITECTURA

Arquitectura de Software Por Luis Felipe Fernández

Brooks, en un artículo de 1987 titulado “No Silver Bullet: Essence and Accidents of Software Engineering”, 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, manifiesta 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 Software Aunque 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, Dijkstra 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 software al mencionar que quizá luego se hable de “la escuela de arquitectura de software de Dijkstra”, y al mismo tiempo lamentar que la industria de ese tiempo preste muy poca atención a ésta. Durante la década de los setentas el concepto de arquitectura deambuló por el aire sin una semántica clara y carente 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 sobre 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 desarrollo 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 modernos de programación”[4] y “Los sistemas de gran escala requieren de abstracciones 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 primeros 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 relevantes, 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 trabajo 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 software, aparecen las estrategias orientadas a líneas de productos y se procura insertar la arquitectura de software dentro del ciclo de vida, obligando a redefinir 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, modelos de evaluación de arquitecturas de software y modelos orientados por la arquitectura entre algunos otros tópicos.

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 desarrollo 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 Universidad Politécnica de Catalunya, Barcelona, España; su trabajo de tesis gira entorno a arquitecturas de software. lfernand@uacj.mx

MAY-JUN 2006

www.softwareguru.com.mx

Definiciones, Definiciones, Definiciones... Martin Fowler, en su artículo “Who needs an Architect?”[13], deja salir su cinismo (segú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 escuche como algo importante”. Encontrar una definición aceptada universalmente no es tarea fácil, de hecho no existe. Por el contrario, 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 involucra 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-

www.softwareguru.com.mx

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 simplemente 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 interpretar estos diagramas y darles de alguna manera coherencia. Así podemos encontrar que las definiciones iniciales se refieren a componentes o elementos relacionados entre sí (estructura) primordialmente. Luego se le ha agregado que también las propiedades de los elementos son parte de la arquitectura; otros más se decantan por el conjunto de decisiones de diseño (sin marcar cómo podrí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 definición a la que se recurre más es la presentada por Bass, et al.[15]: “Una arquitectura de software de un programa o un sistema computacional es la estructura del sistema, la cual comprende elementos de software, las propiedades externamente 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 consenso. No es difícil encontrar que cada trabajo sobre arquitecturas, sobre todo los

MAY-JUN 2006

PRÁCTICAS PROCESOS

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 lector 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 Hacer Le 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 emparejarlas; seguramente tendrá algunas dificultades. Otro ejercicio puede ser pasear un poco por el Proceso Unificado de Racional (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 sentimiento dentro de la academia que estimula a pensar que los diagramas propuestos 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ón La arquitectura de software, con alrededor de 15 años de vida (si consideramos su nacimiento a partir de 1992), ha emergido como una disciplina de gran importancia dentro de la ingeniería de software. Una arquitectura adecuada 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 desarrollo de software: • Mejora la comprensión de sistemas grandes y complejos. • Permite una mejor comunicación entre los diferentes interesados (stakeholders) 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 Gerardo 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

Referencias 1. 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, Marzo de 1968. 3. David Parnas, “On the criteria for decomposing systems into modules” Communications of the ACM 15(12), pp. 1053-1058, December 1972 4. Mary Shaw, “Abstraction techniques in modern programming languages “ IEEE Software, pp. 10-26, October 1984. 5. Mary Shaw, “Large scale systems require higher level abstraction”, Proceedings of fifth international workshop on software specification and design. IEEE Computer Society, pp. 143-146, 1989. 6. Paul Clements, “Coming attractions in software architecture”, Technical report, CMU/SEI-96-TR-008, ESC-TR96-008, jan. 1996. 7. Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides, “Design Patterns: Elements of reusable objectoriented 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 descriptions 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, California University, Irvine 2000. 11. Software Engineering Standards Committee of the IEEE Computer Society, IEEE Recommended practice for architecture description of software-intensive systems, 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 architecture in practice, SEI Series in Software Engineering, Second Edition, Addison Wesley, 2nd printing, October 2003.

www.softwareguru.com.mx

UML

La Vida de un Objeto EL DIAGRAMA DE ESTADOS Por Sergio Orozco

omo ya he mencionado en ediciones anteriores y se lo repetimos a nuestros alumnos 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 proyectos donde el comportamiento del sistema depende en gran medida del estado en que se encuentran los objetos de negocio, los diagramas de estado son indispensables. Los diagramas de estado permiten visualizar los estados de un objeto —ya sea éste un documento, producto 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 Objetos Lo 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 centrarse en un proceso completo, mostrando los diversos objetos que colaboran, este diagrama 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 estados por cada objeto a analizar. Claro que no todos los objetos que identificamos merecen 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 Tipos Podemos 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 estado de un objeto se define por los datos que en ese momento están asociados al objeto

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 acciones 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 cielos 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. Ejemplificando 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 Transiciones No porque el objeto pueda tener ocho posibles 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 ejemplo, 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

a otro, lo podemos indicar con un evento, con una condición o con ambos. Un evento es algo que ocurre en el ambiente que afecta el comportamiento del objeto analizado 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 “Arrancando”. 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 objeto pase de un estado a otro, pero otra posible causa se debe al cumplimiento de una condición que afecta al objeto analizado. Puede ser el hecho de que los atributos del objeto analizado tomen cierto valor, o que haya pasado un lapso de tiempo. Ejemplo, si el monto acumulado 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 Cambios Así como hay situaciones que provocan el cambio de estado de un objeto, también hay situaciones que se dan como resultado de un cambio de estado. A estos efectos se les llama acciones. Aunque tanto las acciones como los eventos se muestran como verbos, las acciones son consecuencia del cambio y los eventos son causas del cambio.

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

MAY-JUN 2006

www.softwareguru.com.mx

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 alrededor de los paquetes que se envían. Razón mayor para utilizar diagramas de estados al desarrollar

Diagrama 1. Estados de un semáforo

Todo tiene un Principio y un Final Todo objeto tiene un principio, pues necesariamente 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 estados 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 maneras; en diferentes estados. El diagrama 2 representa los estados y transiciones de un préstamo. Procesar, aceptar, rechazar, 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.

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 necesitaban 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 retrasarse. Se desarrolló un diagrama de estados para la “Página del Periódico”. • Productos y servicios financieros. Una solicitud 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 estado de un producto o servicio son excelentes candidatos para modelarse con diagramas de estados. • Comportamiento de aparatos y dispositivos. 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áquina espera que alguien deposite una moneda para comenzar a funcionar. Cuando depositan una moneda la máquina cambia su comportamiento 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 seleccionar el producto lo entrega si lo depositado es suficiente para cubrir el precio, y regresa cambio si excede el precio; si no es suficiente, sigue esperando más monedas.

Diagrama 2. Estados de un préstamo.

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 producció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 www.softwareguru.com.mx

Conclusión Como podrán ver, los diagramas de estado son de gran utilidad. Estos diagramas tienen muchos más elementos de los que aquí se han explicado, pero aquí hemos explicado 20% de los elementos que ayudan a resolver 80% de los problemas.

MAY-JUN 2006

FUNDAMENTOS

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

En fechas recientes, palabras como “procesos”, “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 forma de definir un estándar es considerando cuál es la necesidad que éste pretende cubrir o satisfacer. Como en cualquier industria, existen una serie de procesos que son comunes a cualquier organización de TI, independientemente 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 procesos optimizados que han sido registrados y documentados como “mejores prácticas”.

mendaciones, nunca como guías rígidas o planes de trabajo. Si bien ITIL, como referencia independiente, propone terminología estándar para definir “qué hacer” y “qué no hacer” al adoptar una estrategia 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 deseosos de aportar sus experiencias e integraron el ITSMF (IT Service Management Forum), que actualmente cuenta con representaciones o capítulos a lo largo del mundo, incorporando organizaciones usuarias de los diferentes sectores e industrias.

ISO 2000: un Estándar para las Organizaciones

Estas 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 primera 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.

La 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 desarrolló 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 embargo, 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 alentada por los grupos de usuarios y firmas de consultoría, nació la necesidad de una referencia formal para las organizaciones, y con ella el desarrollo del estándar BS15000, que en 2005 evoluciona al estándar ISO 20000.

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

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

Surgimiento de ITIL

Servicios de TI. Ha sido desarrollado como referencia para que las organizaciones de TI logren satisfacer sus necesidades y para proveer entendimiento común sobre este tema. El estándar busca orientar a los proveedores de servicio para que implementen un modelo 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ítulo 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 procesos 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 mejora 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 proveedoras de servicios de TI. Ambas partes del estándar son totalmente compatibles y se soportan en el conjunto de mejores prácticas sugeridas por ITIL.

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

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 empresas 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

MAY-JUN 2006

www.softwareguru.com.mx

ganización del gobierno británico, responsable de coordinar los esfuerzos alrededor de ITIL), y el ITSMF. Considerando los esfuerzos realizados, la ISO adoptó el estándar 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 significa que la organización tenga que elegir uno de los dos, porque cumplen diferentes propósitos. Uno es un marco de trabajo, mientras 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 servicio requerida por el estándar ISO 20000. ISO 20000 plantea las características estándares que deben cubrir los procesos relacionados con la administración del servicio, y cuando se aplica una evaluación con respecto a su cumplimiento, prueba objetivamente qué mejores prácticas se han adoptado realmente en una organización. La interoperabilidad entre los dos estándares 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 controles de seguridad y cumplimiento de requerimientos del negocio.

Beneficios Entre 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 costo 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 administración del servicio.

Mapa de Implantación El 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

www.softwareguru.com.mx

MAY-JUN 2006

CARRERA

Comunidades en Todo México La Unión hace la Fuerza

Si eres un desarrollador de software que quiere mantenerse a la vanguardia, 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 desaprovechando una excelente herramienta de desarrollo profesional. 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 interesadas 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 sitio 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 ingresos pueden venir como patrocinios de las empresas proveedoras de tecnologí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 Roles Es 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 roles a considerar en una comunidad pueden ser: • Facilitador de la reunión. Es responsable de que la reunión avance y se apegue a la agenda. • Secretario. Responsable de documentar las minutas de la comunidad. La persona que desempeña este rol puede cambiar reunión con reunión. Lo importante 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 comunidad 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 participen como oradores, exponiendo los temas mencionados. • Administrador de sitio web. Mantiene el sitio web e infraestructura asociada.

MAY-JUN 2006

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 Adicionales Como 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á sucediendo alrededor de una tecnología o proveedor. Sin embargo, algunas comunidades aprovechan la oportunidad para establecer objetivos adicionales. Por ejemplo, en el caso particular de la comunidad Java México está el de generar 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.

Tips A 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 primer 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 patrocinadora de un mensaje promocional sobre sus productos 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 mesas 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. www.softwareguru.com.mx

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

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

Grupo de Usuarios Oracle México faguirre154@yahoo.com.mx

Cofradía Digital www.cofradia.org

Grupo de Usuarios Oracle Monterrey cluis@itesm.mx

Linux México www.linux.org.mx

Comunidad de Usuarios Progress Software www.cups.com.mx

Java User Groups java.sun.com/jugs

Comunidad Java México www.comunidadjava.org

MSDN en Español www.microsoft.com/spanish/msdn

Comunidad .Net de Tijuana www.tjnet.org

International .NET Association www.ineta.org/latam

Comunidad .Net de Puebla www.dotnetpuebla.com

TechNet México www.microsoft.com/mexico/technet

Comunidad .Net del DF groups.msn.com/Comunidad-NET-mx

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 intercambiar experiencias y algo más.

TechNet Coatzacoalcos groups.msn.com/Technetmexico-Coatzacoalcos-ITpros/ Debian México www.debianmexico.org Grupo de Usuarios Linux Tabasco www.gultab.org DB2 User Group México mx.groups.yahoo.com/group/ GUDB2MEXICO/join Tivoli User Group México www.tivoli-ug.org/groups.php?groupid=14 Mexico Websphere User Group etorres@mx1.ibm.com www.softwareguru.com.mx

Agradecemos a las siguientes personas por la información provista para generar este artículo: J. Gabriel Castillo Martínez, Director de la Comunidad IT Pro Coatzacoalcos; Enrique Montes, que coordina los grupos de usuarios en México para Java, Oracle, Progress y Sterling Commerce; Deble Kuri, Especialista de Comunicaciones en IBM. MAY-JUN 2006

INFRAESTRUCTURA

Recuperación de la Información Las Dos Caras de la Moneda Por Ariel García

Durante esta semana tuve una llamada del Editor en Jefe para preguntarme si conocía alguna compañí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. Hay numerosas herramientas de recuperación en el mercado. Estas herramientas tienen como principal finalidad recuperar el máximo de información posible ante un incidente determinado: el caso típico es el intento 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 susceptibles de que, al menos, intentemos la recuperació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 obtener mejores resultados en las averías lógicas que en las averías físicas. Así pues, los errores de usuario, los borrados intencionados 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 disco duro con los platos (head crash), las deformaciones por impacto o cambios bruscos de temperatura, o los daños en la electrónica y mecánica (la ruptura de un motor en un disco duro). La delicadeza de este tema surge en el momento que ignoramos los problemas de seguridad y confidencialidad de no contemplar medidas efectivas para prever las recuperaciones no deseadas. Existen muchos escenarios posibles y muy frecuentes, no sólo en el ámbito empresarial, sino en el doméstico. Cuando la recuperación es controlada y, sobre todo, efectuada con el único propósito de salvaguardar nuestra información para ser reutilizada, no hay problema. Pero esto

MAY-JUN 2006

no siempre es así. Al igual que nosotros, otros, sin consentimiento, pueden ser los ejecutores de procedimientos de recuperación no deseados. Para muchas empresas es una práctica comú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 todos ellos es posible ejecutar acciones de recuperación en busca de material restringido y confidencial. En entornos domésticos deben extremarse las precauciones, no sólo cuando queremos destruir equipos o deshacernos de una computadora que ha quedado inservible, sino cuando se compran y venden accesorios 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 consiguieron recuperar información de aproximadamente 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 relevante. Las recuperaciones incluyeron informació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 garantizar una destrucción de datos no reversible. Recuerde especialmente este punto; formatear 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 posible, 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 aplicación secuencial del US Department of Defense (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

www.softwareguru.com.mx

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

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 versiones 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 consola tipo UNIX con el comando dd, para conversión y copiado de archivos, mediante la secuencia “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” (distribuciones 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 seleccionarse 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 tenemos en toda la gama de dispositivos de almacenamiento que existen.

TECNOLOGÍA

Victorinox Swiss Memory / Swiss Beat MP3

Dell

XPS M1710 Diseñ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 impresionante 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 actuales 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 calentamiento que sufren, pero el diseño exterior de la M1710 no sólo protege los componentes del trato rudo, sino que contribuye a disipar el calor, para largas sesiones de juego sin problemas.

Logitech

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

MAY-JUN 2006

La tradicional compañía de navajas y accesorios para acampar se renueva y presenta un par de productos que combinan su clásico estilo y color con funcionalidad para los amantes de los gadgets. La Swiss Memory es la navaja que todos conocemos, con diversos aditamentos —tijeras, pinzas, lima, palillo dental, lámpara, pluma, etc.—, y lo más importante para los usuarios de computadoras: 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 reproductor integrado a una navaja con tijeras y lima. Almacena 1GB, cuenta con una pequeña pantalla que despliega los tags de los archivos —soporta MP3, WMA y WAV—, radio FM, seis modos predefinidos de equalización, grabadora de voz y un control remoto. Su salida de audio es de alta calidad y potencia, comparable incluso con la de un iPod.

ra, un receptor que se conecta a la entrada de auxiliar de cualquier estéreo casero con entradas 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 problemas. Este accesorio es opción para quienes tienen una enorme librería de canciones en su computadora y desean escucharla más libremente y en un aparato potente. www.softwareguru.com.mx

REFLEXIONES

J2EE Vs. .Net

Crónica de una Batalla

Por 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. 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 perfecto. No por nada este puntito está estrellando su tacita. Pronto todas las aplicaciones importantes sobre Web correrán en el puntito. J: ¡Cuernos! además, antes tendrían que lograr que el puntito 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 sistemas 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 aplicaciones 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 estándares, que se llama ECMA. En ella confiamos nuestra

MAY-JUN 2006

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 tecnologías, que van desde la plataforma para desarrollar aplicaciones J2EE, un modelo de aplicación estándar, una suite de verificación de compatibilidad y una aplicación de referencia. Además, la plataforma incluye el acceso a base de datos, uso de directorios 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 lenguajes de programación, con nuestro puntito tu no solamente puedes programar en C#, sino también en C/C++, Visual Basic, J#, Perl, Python, Fortran, Delphi, etc. ¿Cuántos lenguajes soporta su tacita? J: Pues... Java, Java, Java. Ahh! y se me olvidaba. También Java. N: Ja, Ja, Ja. ¿O sea que su tacita solamente tiene un solo sabor para el café? J: Pero no es cualquier sabor de café. Además, su C# se parece sospechosamente a nuestro Java. Y su CLR a nuestra “virtual machine”. N: Casualidades, meras casualidades. J: Sí, como las casualidades que se acabaron 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é puede hacer su puntito que nuestra tacita no pueda? N: Pues nuestro puntito proporciona una infraestructura sobre la cual los lenguajes de programación, las herramientas y los servicios simplifican el desarrollo de aplicaciones en un entorno 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 seguros, y tendrán que convencer a miles de programadores que hacen café con nuestra tacita. N: Verás que los convenceremos.

Días después se realizó el debate, 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 encomendarles el desarrollo de un artículo que expusiera de forma comparativa las características de ambas plataformas. En un número próximo de SG compartiremos dicho artículo. Mientras tanto, los invitamos a reflexionar al respecto.

www.softwareguru.com.mx

INDEX

DIRECTORIO

TENEMOS UN ESPACIO RESERVADO PARA TI

Anunciante

Pรกginas

Sitio

AMCIS Avantare Cutter Consortium Edutecsa e-Quallity Gartner IIDEA Solutions Imexsoft Itera Marx Milestone Microsoft Oracle Roca Sistemas SafeNet SG Conference

55 49 11 33 45 53 47 37 13 51 19 F2-1, 56-F3 F4 43 31 07

www.amcis.org.mx www.avantare.com www.cutter.com.mx www.edutecsa.com www.e-quallity.net www.gartner.com/mx/outsourcing www.iidea-solutions.com www.imexsoft.com.mx www.itera.com.mx www.marx.com www.milestone.com.mx www.microsoft.com/mexico www.oracle.com/global/mx www.rocasistemas.com.mx www.safenet-inc.com www.softwareguru.com.mx

Si deseas anunciarte contรกctanos en el (55) 5239 5502 o en ventas@softwareguru.com.mx

www.softwareguru.com.mx

MAY-JUN 2006

Aﾃｱo 02 No. 03

www.softwareguru.com.mx

SOFTWARE GURU CONOCIMIENTO EN PRﾃ，TICA

Mayo-Junio 2006