SG21 (Agosto-Octubre 2008) by Revista Software Guru

• Peer Reviews • Documentación de Arquitecturas • Seguridad en Aplicaciones Web

Software Guru CONOCIMIENTO EN PRÁCTICA No.21 • Agosto - Octubre 2008 • www.sg.com.mx

[ ENTREVISTA ]

Christian Lemaître Guru fundador de las Ciencias de la Computación en México

Industria del Software en México

México. $65 MXN

I SSN 1 8 7 0 - 0 8 8 8

21 9 771870 088009

Noticias • Eventos • Fundamentos • UML • PM Corner • Tecnología • Biblioteca

[ Tutorial ] Silverlight

// CONTENIDO

directorio Dirección Editorial Pedro Galván Dirección de Operaciones Mara Ruvalcaba Coordinación Editorial Sonia Sánchez

Editorial

Arte y Diseño Grisel Otero Fotografía Gabriel González Consejo Editorial Jorge Valdés - PMI; Luis Cuellar - Softtek; Francisco Camargo, Luis D. Soto - Microsoft; Hanna Oktaba - UNAM; Ralf Eder, Raúl Trejo, Guillermo Rodríguez - ITESM CEM; Emilio Osorio - Sistemas Humanos; Luis Vinicio León - e-Quallity. Colaboradores Christian Lemaître, Alejandra Herrera, Martín Álvarez, Luis García, Carlos Ortega, Omar Gómez, Erick Frausto, Rafael Bernal, Gunnar Wolf, Germán Domínguez, Marco Dorantes, Guillermo Morales, Edith Martínez, Beatriz Velázquez, Andrés Simón Bujaidar, Miguel Armas, Héctor Obregón, Germán Domínguez.

Sí, aun seguimos ¡vivos!. Después de meses habitando la oficina, comiendo pizza y bebiendo agua (¡somos muy saludables!), los días 21 a 24 de junio se realizó el congreso SG’08 Conferencia y Expo, en esta ocasión en conjunto con PMTOUR México 2008. Estamos muy contentos de que hubo personas que asistieron por tercera ocasión, nos da mucho gusto saber que gente nueva asistió al congreso y quedó muy satisfecha con lo ahí mostrado. Aunque cambiaron algunas cosas (como el tiempo de duración de los tutoriales), todo salió muy bien. ¿Quieren saber más?, en el interior de la revista encontrarán la reseña más completa. Nada de esto hubiera sido posible sin el esfuerzo y trabajo del equipo que forma a

SG, y a todos ustedes porque además de asistir, nos han hecho un elemento más en sus preferencias. Retomando nuestras actividades cotidianas, ahora toca el turno a este número 21, en el que encontrarán los comentarios de los expertos en el desarrollo de la Industria de Software en nuestro país. Es interesante saber cómo vamos creciendo en este aspecto y lo que podemos hacer para mejorarlo. Además encontrarán la última parte del tutorial de Ruby on Rails y la continuación del artículo sobre documentación de sistemas, así como cada una de las columnas que ya conocen. Gracias todos por su preferencia y por hacer que SG’08 Conferencia y Expo haya sido un éxito. » Equipo Editorial

AGO-OCT 2008

Ventas Claudia Perea, Natalia Sánchez Marketing y RP Dafne Vidal Circulación y Suscripciones Daniel Velázquez, Edgar Dorantes Administración Araceli Torres Contacto info@softwareguru.com.mx +52 55 5239 5502 SG Software Guru es una publicación trimestral editada por Brainworx S.A. de C.V., Malinche no. 6, Col. El Parque, C.P. 53398, Naucalpan, México. Queda prohibida la reproducción total o parcial del contenido sin previo aviso por escrito de los editores. Todos los artículos son responsabilidad de sus propios autores y no necesariamente reflejan el punto de vista de la editorial. Reserva de Derechos al Uso Exclusivo: 04-2004-090212091400-102. Certificado de licitud de título: 12999. Certificado de licitud de contenido:10572. ISSN: 1870-0888. Registro Postal: PP15-5106. Se imprimió en julio de 2008 en Roma Color, S.A. de C.V. Distribuido por Sepomex.

www.sg.com.mx

contenido ago-oct 2008

EN PORTADA Industria del Software en México

Presentamos un compendio de diferentes perspectivas sobre nuestra industria.

Especial

Reseña de SG’08.

Productos LO QUE VIENE 10 JBoss en EC2, Probe 8.0, ADO.NET Entity Framework y TBB 2.1. 12

TUTORIAL Silverligth.

Herramientas 14 Control de acceso basado en roles.

Prácticas

Columnas Tejiendo Nuestra Red por Hanna Oktaba

Mejora Continua por Luis Cuellar

Columna Invitada por Héctor Obregón

Prueba de Software por Luis Vinicio León

Tendencias en Software por Luis Daniel Soto

ASEGURAMIENTO DE CALIDAD Revisiones entre colegas

Un vistazo a los roles, tipos y fases de las revisiones entre colegas, así como sus beneficios.

PROGRAMACIÓN Ruby y Rails

Última parte de este tutorial introductorio al lenguaje de Programación Ruby y el framework Rails.

ARQUITECTURA Más allá del manual de usuario

En Cada Número Noticias y Eventos

GADGETS

FUNDAMENTOS

COMUNIDADES

INFRAESTRUCTURA

Segunda parte sobre la documentación que debe considerar el arquitecto de software.

SEGURIDAD Aplicaciones Web seguras ¿mito o realidad?

Conozcamos los diferentes tipos de vulnerabilidades exstentes en este rubro de las TI.

UML Reconociendo los Diagramas

Entrevista

PM CORNER Mejores estimaciones para el desarrollo de software

Christian Lemaître

Mostramos las reglas básicas para reconocer un buen diagrama de secuencia.

Conozcamos la técnica llamada Poker de Planeación. www.sg.com.mx

AGO-OCT 2008

// NOTICIAS

Sun Tech Days México 2008 Del 21 al 23 de mayo el tour Sun Tech Days se hizo presente en la ciudad de México festejando su décimo anversario. El evento de 3 días reunió a más de mil entusiastas de las tecnologías de Sun, tales como Java, Solaris y Net Beans. Este año se hizo notar el empuje que Sun le está dando a NetBeans, de hecho en palabras de algunos asistentes el evento consistió en “NetBeans, NetBeans y más NetBeans”, y es que en la gran mayoría de las sesiones se demostraba cómo utilizar esta herramienta en diferentes ámbitos, desde el desarrollo y depuración de aplicaciones para dispositivos móviles hasta el modelado y orquestación de web services.

Congreso Internacional ANADIC 2008 La Asociación Nacional de Distribuidores de Información y Comunicaciones (ANADIC) realizó su octavo Congreso Internacional 2008, el cual se celebró en la ciudad de México del 12 al 16 de julio. El congreso contó con la participación de más de mil socios, y una agenda conformada por talleres, conferencias, paneles, expo y actividades recreativas. Durante la inauguración, Francisco Wilson presidente de la asociación, habló sobre el papel fundamental que el canal desempeña en el mejoramiento de la industria. Durante el congreso se presentaron diferentes logros como: Ciudades Inteligentes, Centros Autorizados de Servicio (CAS), y ANADICSoft, proyecto que a través de la iniciativa “México va por TI”, colocará las aplicaciones desarrolladas por los asociados en las microempresas del país, con el apoyo de los gobiernos federal y local, y con el compromiso y aportación de los asociados.

Encuentro Nacional PROSOFT 2.0 Bajo el lema “Consolidando la calidad de nuestra industria de TI”, apoyando la misión de convertir a México en una potencia desarrolladora de software, se llevó a cabo el Encuentro Nacional Prosoft 2.0, del 27 al 28 de mayo, en la ciudad de México. Eduardo Sojo, Secretario de Economía, aseguró que el gobierno es un gran impulsor de la industria de TI, y comentó que para consolidar este apoyo se requiere de un trabajo conjunto entre todos los sectores del país: público, privado, gobierno federal, estatal, e instituciones educativas. De acuerdo a Rocío Ruiz, Subsecretaria de Industria y Comercio de la SE, el encuentro permitió reflexionar sobre las acciones que todos los sectores hemos emprendido en pro de nuestra industria de TI, la cual hemos observado se ha ido convirtiendo en un motor de nuestra economía.

AGO-OCT 2008

www.sg.com.mx

// EVENTOs

14 al 15 de Agosto 2008

1 al 3 de Octubre 2008

5ª Reunión Regional CIAPEM

ANIEI XXI Congreso Nacional y VII Congreso Internacional de Informática y Computación

Pachuca, Hidalgo Info: www. ciapem.hidalgo.gob.mx

ITESM Monterrey, Nuevo León Info: www.aniei.org.mx

3 al 5 de Septiembre 2008

CIISA 2008

1 al 3 de Octubre 2008

Cutter Summit América Latina

Hotel Hilton, Guadalajara, Jalisco Info: www.ciisa.gda.itesm.mx

Hotel JW Marriott, Cd. de México Info: www.cutter.com.mx

8 de Septiembre 2008

IDC 4ª Cumbre de Gobierno y Tecnología Centro Banamex, Cd. de México Info: www.idc-eventos.com/cumbregobierno08.html

9 al 11 de Octubre 2008

Creanimax 2008

Expo Guadalajara, Guadalajara, Jalisco Info: www.creanimax.com

23 al 26 de Septiembre 2008

XXXII Reunión Nacional del CIAPEM Mundo Imperial, Acapulco, Guerrero Info: www.guerrero.gob.mx/ciapem2008

50 Años de la Computación en México Con el objetivo de conmemorar el aniversario de los 50 años de la computación en México, se están realizando diferentes eventos de carácter nacional e institucional, con la misión de integrar y lograr una celebración que promueva el conocimiento actual y las perspectivas tecnológicas, reconociendo el esfuerzo y trayectoria de todos los actores de la historia durante estas cinco décadas. Se invita a participar a todos los universitarios, la industria, asociaciones, cámaras, gobierno, instituciones educativas y en general a la comunidad de interesados en las tecnologías de información y comunicaciones. Mayor información en: computo50.unam.mx

www.sg.com.mx

Gartner Future of IT Centro Banamex, Cd. de México Info: www.gartner.com/it/summits/mex30ls

Directores TI 2008

Concurso e-Quallity 2008

Enfocados en la problemática de ¿cómo cerrar la brecha entre el perfil de los egresados y las necesidades en el sector productivo?, se reunieron Directores de Informática y Computación en la XVII Reunión Nacional organizada por la ANIEI, los días 11 al 13 de junio en Cancún, Quintana Roo. Por medio de mesas de discusión interactivas se analizó la situación actual de las instituciones, se identificaron las necesidades de la sociedad, se generaron propuestas de cómo mejorar la calidad de los egresados, y finalmente se acordaron actividades que permitirán definir el rumbo de la educación y formación de profesionales en el área de TI en México.

Por segundo año consecutivo este concurso convocó a la comunidad nacional desarrolladora de software a enviar productos pequeños terminados, para encontrar los de menor densidad de defectos. Aplicando pruebas exploratorias se detectó una primera capa de errores; utilizando esa información y su Modelo Predictivo, e-Quallity generó una estimación de las fallas todavía presentes; el costo de detectarlos, y su comparación contra la media de calidad de los productos probados. La premiación se realizó durante el congreso SG’08. Los ganadores: 1o SAB- Sistema de Administración de Bóveda versión 1.0 (Tbanc); 2o TEP- Teclado en Pantalla ver 2008.3 (Compucaja); 3o DSM versión 3 (Proeza TI)

Empresas recientemente evaluadas en CMMI:

Empresa Hildebrado Software Factory Vision Software Factory T-Systems Imagen Soft Telepro Coppel

29 al 31 de Octubre 2008

Evaluación CMMI Nivel 5 CMMI Nivel 2 CMMI Nivel 2 CMMI Nivel 3 CMMI Nivel 3 CMMI Nivel 2

Fecha septiembre 2007 diciembre 2007 marzo 2008 abril 2008 mayo 2008 julio 2008

Lead Appraiser Giuseppe Magnani Miguel Serrano Mariana Pérez-Vargas Cecilia Scauso Mariana Pérez-Vargas Cecilia Scauso

Apoyado por Avantare Avantare Avantare Innevo Avantare Innevo AGO-OCT 2008

// COLUMNA

/*TEJIENDO NUESTRA RED*/

Entre Lima y Berlín Noticias de COMPETISOFT y de ISO/IEC WG24 La Dra. Hanna Oktaba es profesora de la UNAM a nivel licenciatura y posgrado. Sus áreas de interés son Ingeniería de Software, Tecnología Orientada a Objetos, Modelos de Procesos de Software y Mejora de Procesos. Actualmente es miembro de International Process Research Group (IPRC). También es Directora Técnica del proyecto COMPETISOFT.

finales de abril de 2008 tuvimos la reunión del proyecto COMPETISOFT en Lima, Perú. Asistieron 24 personas de diferentes países como: España, Colombia, Argentina, Chile, Uruguay, Ecuador, República Dominicana, Perú y México. El objetivo era revisar resultados de pruebas controladas de implementación de procesos de perfil básico (Administración de Proyectos Específicos y Desarrollo y Mantenimiento) en empresas de estos países. Se siguió un proceso de mejora ágil PmCompetisoft diseñado, con base en una propuesta colombiana, por Francisco Pino. Los colegas académicos y sus alumnos fungieron como consultores de las empresas. El diagnóstico inicial arrojó los mismos resultados, que en pruebas controladas en México, es decir las empresas tienen prácticas muy precarias. La generalización de esta situación ayudó a ser más sinceros en el intercambio de las experiencias. A pesar de trabajar en países distintos, las pequeñas empresas repiten el mismo patrón, sacan buenos productos gracias a los individuos, pero no comparten ni transmiten el conocimiento para que se aproveche en la organización. Lo interesante de PmCompetisoft es que trabaja en ciclos de mejora de 4 meses lo que ayuda a las empresas tener un resultado visible a corto plazo. El denominador común de las pruebas fue que, a pesar de no tener ninguna promesa de “certificación”, las empresas expresaron su interés de continuar con el esfuerzo de mejora de procesos. También fue elogiada la versión coloreada por niveles de capacidad de procesos. En particular, lo marcado de amarillo ayuda a centrarse en cosas básicas para la adopción del modelo.

del proceso de Desarrollo para poder atender principalmente los mantenimientos rápidos no planificados. Con respecto a otros procesos se han propuesto las mejoras en algunos detalles y nombres pero no en la estructura. Se puede decir que el modelo sobrevivió la prueba de revisión de hispano parlantes. Como efecto lateral de este proyecto se ha publicado en octubre de 2007 un artículo en la popular revista IEEE Computer, titulado “Software Process Improvement: The Competisoft Project”, (H. Oktaba, F. García, M. Piattini, F. Ruiz, F. J. Pino, C. Alquicira). También, acaba de salir en abril de 2008 el libro editado por H. Oktaba y M. Piattini, titulado“Software Process Improvement for Small and Medium Enterprises: Techniques and Case Studies”, de la editorial IGI Global. En este libro encontrarán por supuesto un artículo sobre MoProSoft, pero también otros cuatro capítulos escritos por autores mexicanos, entre ellos está el de Luis Vinicio León Carrillo mi colega de la columna vecina en SG. En mayo de 2008, Ana Vázquez y su servidora atendimos en Berlín la siguiente reunión del grupo WG24 del ISO/IEC JTC1 SC7 (perdón por tantos iniciales), en otras palabras, del grupo en el cual se trata de incorporar los elementos del modelo de procesos MoProSoft de la norma mexicana MX-I-059-NYCE en el estándar internacional ISO/IEC TR 29110.

En esta ocasión teníamos que revisar los comentarios recibidos de diversos países al primer borrador del estándar (working draft). El trabajo duró 5 días y fue bastante intenso porque se tenía que decidir por cada comentario si se aprobaba, si se aceptaba en principio o se rechazaba. En los dos últimos casos se tenía que definir qué se iba a hacer en concreto o por qué se rechaza. Revisamos los comentarios a las cinco partes del documento. Afortunadamente, la parte 5.1 del estándar, la cual contiene la aportación mexicana, tuvo solo comentarios que servirán para mejorar su presentación y explicación, sin modificar el contenido a fondo. Ahora nos toca generar la nueva versión de las cinco partes incorporando los comentarios y presentarlos nuevamente a la revisión internacional en calidad del Comeetee Draft. Lima me sorprendió por ser una ciudad moderna y limpia (por lo menos la parte que me tocó conocer) y que en Berlín todo mundo anda en bicicleta y no solo los fines de semana. De regreso aterricé en el evento de Prosoft del 27 y 28 de mayo. Hay muchas cosas que muestran los cambios favorables que están sucediendo en nuestra industria de software. La bolita de nieve echada a andar hace pocos años empieza a crecer. Seguiremos acompañando su paso. » Hanna Oktaba

No son muy significativos los cambios propuestos al modelo de procesos como resultado de más de dos años de revisar y experimentar MoProSoft en los países iberoamericanos. La más interesante propuesta es la de separar el proceso de Mantenimiento

AGO-OCT 2008

www.sg.com.mx

AGO-OCT 2008

// COLUMNA

/*MEJORA CONTINUA*/

Logrando Metas La Importancia de Identificar los Problemas 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 CMMI5 y Six Sigma a través de las diferentes áreas del centro de desarrollo de Softtek.

El problema está en no ver cuál es el problema

¿Qué es primero el problema o la solución?

ace algunos días apoyé en una reunión para mejorar el proceso de administración de requerimientos en un proyecto. Dentro de la discusión participaban varias personas, una de ellas decía: “El problema es que tenemos que generar una forma automática de administrar los requerimientos”. Otro decía: “Lo que pasa es, que el cliente no sabe lo que quiere y cambia mucho los requerimientos”. Finalmente una persona más decía: “Yo creo que estamos bien, sólo tenemos que hablar con el cliente para que administre sus requerimientos”. Después de un rato de que esto siguiera adelante, empecé a preguntarme si realmente alguien sabía ¿cuál era el problema que se quería resolver?, ¿para qué necesitamos digitalizar?, ¿por qué es un problema que se cambien los requerimientos? o ¿por qué es importante que se administren estos?

Otra limitante en esta definición, se debe al hecho que nuestra cultura se enfoca principalmente a resultados y tiene fuertemente arraigada la idea de valorar a la gente que trae a la mesa soluciones. Todos los libros de administración y liderazgo, enfatizan la importancia de dar soluciones en lugar de problemas. Esto es bastante lógico, yo mismo espero que la gente que trabaja conmigo esté siempre buscando soluciones a los problemas que enfrentamos. Pero creo que en algunos casos, estamos llevando la situación más allá de lo debido, estamos brincando por completo la fase de identificar el problema y estamos saltando directamente a encontrar soluciones. En la frase “tenemos que digitalizar el proceso de requerimientos” el objetivo es ser más eficientes en la recepción de estos, el digitalizar se consideraría más bien una forma de resolver el problema.

Cientos de veces grupos de personas se unen a discutir la forma de solucionar algún problema, sólo para que la mayoría termine frustrado, con la sensación de que no fue escuchado o que la decisión final no arreglará nada. Terminan discutiendo lo que cada quien cree que es la respuesta para lo que cada quien cree que es un problema y como es de imaginarse, los resultados no siempre son los más adecuados.

Adicionalmente en el punto anterior existe otra complejidad, qué sucede si yo ya revisé todos los elementos para hacer más eficiente la administración de los requerimientos y ya concluí que la única forma de arreglar ese punto es a través de digitalizar el proceso. ¿No sería entonces válido decir que el problema es digitalizar el proceso e iniciar desde ahí en lugar de volver a analizar esa parte? La respuesta es un definitivo “Sí”. Pero las confusiones surgen cuando el grupo no concuerda con el problema o no entiende las causas que los llevaron a donde se encuentran. Por lo tanto es imprescindible que al presentar la propuesta sea como la solución a un análisis previo y el grupo este de acuerdo con esta premisa. De esta manera no puede haber malos entendidos.

¿Cómo hacemos más eficiente una reunión de resolución de problemas? y ¿cómo aseguramos que aplicamos nuestros recursos al problema adecuado?

¿Cuál es nuestro problema? Según Wikipedia se define como problema: “Un obstáculo el cual hace difícil lograr una meta, objetivo deseado o propósito. Se refiere a una situación, condición o asunto que no se ha resuelto. En un sentido amplio un problema existe cuando un individuo se da cuenta de una diferencia significativa entre lo que actualmente es y lo que es deseado”. La parte clave desde mi punto de vista en esta definición es: una meta, objetivo o propósito. Dependiendo del contexto de la reunión, la frase: “el cliente no sabe lo que quiere y cambia mucho los requerimientos”, no es un problema, dado que normalmente no tenemos un objetivo sobre el número de requerimientos máximos que puede tener un cliente, sólo lo sería si en nuestro proceso establecemos un número máximo de requerimientos que estamos dispuestos a aceptar y el cliente está de acuerdo con esa definición o si el objetivo de la reunión es: ¿Cómo controlamos las posibilidades que tiene el cliente de atrasar el proyecto?. Esta diferencia entre cual es el objetivo de la reunión y algunas veces el objetivo de cada individuo dentro de la reunión, es uno de los elementos que hacen verdaderamente complejo el definir claramente un problema.

AGO-OCT 2008

El problema es la mitad de la solución

En conclusión encontrarse en una reunión donde se discute un problema deben de considerarse los siguientes puntos. 1. Al inicio de toda junta de resolución de problemas debe de quedar muy claro qué es lo que se pretende resolver y por qué se pretende resolver. 2. Cada vez que escuchemos una frase planteada como un problema nos debemos de preguntar ¿por qué? Es importante hacer esta pregunta por lo menos hasta llegar al punto que realmente represente una diferencia entre una situación real y una meta deseada. 3. Finalmente a la presentación de un problema siempre utiliza las palabras mágicas: ¿cuál es el problema?, ¿qué lo provoca?, ¿dónde está?, ¿quién lo genera?, ¿cuándo surge?; estas preguntas darán mucho mejor idea de lo que se quiere resolver. Como responsable de cambiar a la organización a ser mejor, es sumamente importante tener claro el problema a resolver. De tomar una acción, normalmente los recursos son limitados y el avance es mayor cuando está claro hacia donde se va. » Luis R. Cuellar www.sg.com.mx

www.sg.com.mx

AGO-OCT 2008

// PRODUCTOS

/* LO QUE VIENE*/

JBoss disponible en EC2

ADO.NET Entity Framework

Mapeo objeto-relacional para .NET

Servidores de aplicación desde la nube

Una de las noticias más significativas de las últimas semanas en el ámbito del cómputo en la nube, o cloud computing, es el hecho de que Red Hat ya ofrece el servidor de aplicaciones JBoss a través de Amazon Elastic Compute Cloud (EC2). Técnicamente, no hay nada nuevo. Después de todo, un usuario puede entrar a EC2 e instalar lo que quiera dentro de su máquina virtual. Sin embargo, aquí lo notable es que ya estamos hablando de una oferta comercial de clase empresarial. Este esquema le permite a Red Hat distribuir su software (y cobrar por él) a través de un nuevo canal, sin necesidad de tener que atender directamente a los clientes. Por su parte, Amazon agrega una oferta de clase empresarial que le anota muchos puntos en su búsqueda de posicionamiento como una opción real para los corporativos.

Uno de los aspectos de mayor importancia en cualquier plataforma moderna para desarrollar aplicaciones empresariales, es cómo resuelve el mapeo entre los objetos de negocio y los datos de una base de datos relacional. En el caso de la plataforma .NET, a pesar de que cuenta con algunos mecanismos (como el objeto DataSet) que ayudan un poco a resolver este problema, hasta ahora no existe una solución completa de ORM (object-relational mapping). El ADO.NET Entity Framework viene a llenar ese hueco, y será el primer framework ORM que Microsoft introduce para la plataforma .NET. El ADO.NET Entity Framework forma parte del service pack 1 del .NET Framework 3.5, el cual ya se encuentra disponible como beta y cuya versión final se espera sea liberada antes de que termine el año.

Veremos que tal responde el mercado a esto, y cómo es que los demás proveedores de software empresarial se van subiendo a la nube.

Thread Building Blocks 2.1 Threads a prueba de tontos

JProbe 8.0

Profiling de código Java

Quest Software anunció la disponibilidad de JProbe 8.0, la versión más reciente de su legendaria herramienta de “profiling” de código Java. Esta nueva versión ahora se ofrece como un plug-in de Eclipse, lo cual facilita significativamente su uso. JProbe 8.0 permite a los usuarios de Eclipse rápidamente identificar y resolver problemas de memoria y cobertura de código en sus aplicaciones Java, fomentando así el desarrollo de aplicaciones de alta calidad. En los próximos meses, Quest le agregará a este plug-in capacidades de análisis de desempeño, para que los usuarios puedan investigar cuellos de botella en sus aplicaciones desde el mismo ambiente de Eclipse.

AGO-OCT 2008

Intel liberó la versión 2.1 de Thread Building Blocks (TBB), que es una librería de C++ para facilitar la implementación de threads en las aplicaciones, mejorando así su desempeño en procesadores multi-core. Una de las principales fortalezas de la versión 2.1 de TBB es el nuevo mecanismo de correspondencia entre tareas y threads (task-to-thread affinity) que provee grandes mejoras de desempeño. TBB 2.1 es software libre licenciado como GPLv2 y está disponible para plataformas Windows, Linux, Solaris y Mac OS X. En el caso de los desarrolladores de .NET, también pueden aprovechar el nuevo plug in de TBB para Visual Studio.

www.sg.com.mx

AGO-OCT 2008

// PRODUCTOS

/*TUTORIAL*/

Desarrollo de Aplicaciones con Silverlight Parte 1. Introducción Por Guillermo Morales

Silverlight es la tecnología recientemente propuesta por Microsoft para desarrollar aplicaciones web de alto impacto visual. El objetivo de esta serie de artículos es encaminarlos a cómo crear su primera aplicación con Silverlight.

Los archivos de una aplicación Silverlight Todo lo que podemos hacer hoy en día con Silverlight 1.0, se puede crear mediante cualquier editor de texto. En nuestro caso, usaremos al famoso Notepad. Pensemos que tenemos una página llamada Default.html en donde queremos crear nuestra primera aplicación de Silverlight. Entonces, los archivos que necesitamos crear son: • Default.html - Esta será la clásica página web a donde navegaremos. Invoca al plugin de Silverlight. • Silverlight.js - Un archivo con las instrucciones en javascript para validar que el browser tenga el plugin de Silverlight. Este archivo viene incluido en el SDK de Silverlight y está listo para usarse, por lo que no es necesario modificarlo. • Archivo *.xaml - Este archivo contiene las instrucciones en lenguaje XAML (eXtensible Application Markup Language) que definen los elementos de la interfaz de usuario (UI) de nuestra aplicación.

Veamos ahora el contenido inicial de cada archivo. Listado 1. Default.html <html> <head> <title>Primer Ejemplo Silverlight</title> <script type=”text/javascript” src=”Silverlight.js”> </script> <script type=”text/javascript” src=”crearSilverlight.js”> </script> </head> <body>  <div id=”miHostdelPlugin”> </div> <script type=”text/javascript”> // Obtener el DIV host del plug in. var hostdelplugin = document.getElementById( “miHostdelPlugin”); // Creación del plugin crearPluginSilverlight(); //Llamada a la función del archivo de abajo </script> </body> </html>

Este archivo contiene la función que invocamos desde el html, lo que hace es indicarle al navegador que hay que invocar al método createObject del objeto Silverlight para poder crear un plugin de acuerdo a ciertos parámetros. Listado 3. mixaml.xaml

Como se dan cuenta, esta página es muy sencilla. Carga un par de archivos de javascript e invoca una función para cargar nuestro componente de Silverlight. Como ya se indicó, el archivo Silverlight.js ya viene incluido en el SDK de Silverlight y no se modifica, así que solo necesitamos ponerlo en un directorio de donde podamos cargarlo. Listado 2. crearSilverlight.js

• Archivo *.js - Contendrá el código javascript necesario para invocar el plugin de Silverlight e indicarle el XAML que debe cargar.

hostdelplugin, // Variable que apunta al DIV host. “miHostdelPlugin”, // El ID de la etiqueta DIV host. { width:’300’, // Ancho del plugin en pixeles height:’300’, // Alto del plug in en pixeles inplaceInstallPrompt:false, // Indica si pregunta si se // instala el plugin si no es la // versión correcta background:’#D6D6D6’, // Color Background del plugin isWindowless:’false’, // Determina si el plug in se // muestra en modo sin ventana framerate:’24’, // Número de cuadros por segundo version:’1.0’ // Versión Silverlight a usar. }, { onError:null, // Manejador de función cuando hay error onLoad:null // Manejador de función carga del plug in }); }

function crearPluginSilverlight() { Silverlight.createObject( “mixaml.xaml”,

// El XAML a pintar.

Como habíamos indicado, el archivo xaml define la parte visual. Por lo pronto, lo único que tenemos definido es un canvas vacío, el cual vamos a utilizar para desplegar elementos visuales. Si se echa a andar la página web, obtenemos la siguiente pantalla por el momento:

Guillermo Morales colabora actualmente en InterSoftware, empresa dedicada a la capacitación especializada en desarrollo de software. Con un perfil técnico, se ha desenvuelto en varias áreas del proceso de desarrollo de aplicaciones, desde la implementación, hasta la administración de proyectos. Es cofundador de la comunidad de desarrollo en México www.developersdotnet.com en donde, frecuentemente se reúne con otros expertos de desarrollo de aplicaciones para la difusión de tecnologías nuevas.

AGO-OCT 2008

www.sg.com.mx

“El archivo XAML define los elementos de la interfaz de usuario (UI) de nuestra aplicación”.

Figura 1. Canvas en blanco

Figura 2. Canvas con elementos visuales

El color del fondo del plugin debe ser el indicado de acuerdo a los parámetros que dimos en nuestra función. Ahora crearemos el contenido visual de nuestra aplicación.

¡Perfecto! Has creado tu primera aplicación Silverlight. En la siguiente entrega de esta serie estaremos viendo como poder responder a eventos del mouse y lanzar alguna animación.

Modificando el archivo XAML Como ya vimos, nuestro archivo mixaml.xml contiene el XAML para definir el contenido visual. Todo se pinta dentro de un lienzo sobre el cual se puede pintar y posicionar elementos. De esta manera, si modificamos nuestro archivo mixaml.xaml para que quede como el listado 4, obtendremos un despliegue como el de la figura 2. Listado 4. mixaml.xml invocando elementos visuales <Canvas xmlns=”http://schemas.microsoft.com/client/2007” xmlns:x=”http://schemas.microsoft.com/winfx/2006/ xaml”> <Rectangle Canvas.Top=”30” Canvas.Left=”30” Fill=”Blue” Height=”100” Width=”100” /> <Rectangle Canvas.Top=”80” Canvas.Left=”80” Fill=”Red” Height=”100” Width=”100” /> <Ellipse Canvas.Top=”130” Canvas.Left=”130” Fill=”Green” Height=”100” Width=”100” /> </Canvas>

www.sg.com.mx

Conclusión El desarrollo con Silverlight está basado en una serie de archivos que contienen indicaciones para: • Creación del Plugin de Silverlight (archivo crearSilverlight.js) • La declaración de los elementos visuales a crear (mixaml.xaml) • La página web que hostea al plug in (default.html) • El código de validación de la existencia del plug in, este archivo es parte del SDK de Silverlight y generalmente no deberíamos de modificarlo (Silverlight.js).

Referencias [developersdotnet.com]

AGO-OCT 2008

//PRODUCTOS

/*HERRAMIENTAS*/

Control de Acceso Basado en Roles Factores a Considerar en Una Solución Por Equipo Editorial

Prácticamente todas las aplicaciones empresariales requieren contar con capacidades de control de acceso. Es decir, restringir las operaciones que puede realizar un usuario. Uno de los esquemas más comunes es el control de acceso basado en roles, también conocido como RBAC por sus siglas en inglés (Role Based Access Control).

roles y permisos. Debe ser sencilla de usar, de forma que gente no técnica pueda realizar estas tareas.

Es muy común que en nuestras aplicaciones implementemos nosotros mismos el control de acceso como parte de su desarrollo. Sin embargo, también existen productos listos para usarse que resuelven este problema. En este artículo explicamos las principales características que debe cumplir un buen sistema de control de acceso basado en roles.

Es altamente recomendable que los detalles para el control de acceso a aplicación no estén definidos dentro del código de la aplicación misma, sino que se realicen a través de un componente externo que interactúe con un repositorio de permisos, tal como se indica aquí. Esto permite tener independencia entre el código de la aplicación y el control de acceso, lo cual es deseable ya que así no necesitamos modificar la aplicación y lanzar una nueva versión cada que tengamos que hacer un cambio en la política de accesos. Otra ventaja es que no necesitamos a personas que entiendan el código de la aplicación, para poder hacer ajustes en el control de acceso.

Funcionalidad Un sistema RBAC debe proveer como mínimo tres diferentes grupos de funcionalidad: autenticación, autorización y auditoria. • Autenticación. Capacidad de validar la identidad de un usuario. Típicamente se realiza por medio de nombres de usuario y contraseña. • Autorización. Es la definición de qué es lo que un usuario específico puede hacer dentro de una aplicación, es decir a qué información y operaciones tiene acceso. • Auditoría. Se refiere a la capacidad de mantener un registro de las transacciones sensitivas de una aplicación. La auditoria permite saber quién hizo qué, cuando lo hizo, y quién le dio los permisos necesarios a ese usuario.

Componentes • Repositorio. Se requiere de un lugar seguro para almacenar los usuarios, contraseñas, roles y permisos. • Interfaz entre aplicación y repositorio. Este es el componente intermedio que sirve de interfaz entre una aplicación y el repositorio de seguridad. • Consola de administración. La consola que permite administrar las cuentas de usuario,

AGO-OCT 2008

• Documentación. Un elemento comúnmente olvidado, que sin embargo es necesario para tener un proceso de seguridad confiable y que no dependa de personas específicas.

Factores a considerar al diseñar un sistema RBAC Estos son algunos de los principales factores a considerar al diseñar o escoger un sistema RBAC. • Repositorio centralizado. Considera si es que necesitas centralizar el manejo de permisos de varias aplicaciones en un solo repositorio. Incluso podrías requerir que los roles se puedan compartir entre varias aplicaciones. • Single sign-on. Single sign-on se refiere a la capacidad de que los usuarios se autentiquen una sola vez al inicio de una sesión y posteriormente puedan utilizar varias aplicaciones sin necesidad de estarse autenticando para cada una. • Soporte a diversas tecnologías. La mayoría de los ambientes corporativos cuentan con múltiples plataformas aplicativas, así como tipos de cliente (desktop, web, móvil). Desarrolla o escoge un sistema RBAC que funcione adecuadamente con las diferentes plataformas tecnológicas que se utilizan en tu organización.

• Granularidad. La forma más básica de control de acceso consiste en restringir el acceso a pantallas o menús. Sin embargo, frecuentemente se requiere de una mayor granularidad, como podría ser tener control a nivel de cada campo de información, o que un listado contenga datos diferentes para usuarios dependiendo del rol que tengan, o que un proceso de negocio tenga diferentes pasos dependiendo del perfil del usuario.

Opciones en el Mercado La mayoría de las organizaciones optan por desarrollar su propia solución para control de acceso. Sin embargo, difícilmente toman en cuenta todos los aspectos que hemos mencionado en este artículo y por lo tanto terminan con soluciones que no resuelven todas las necesidades y que además son difíciles de mantener. En el otro extremo se encuentran las plataformas empresariales para manejo de identidades y acceso. Gartner identifica como líderes en esta categoría a proveedores como IBM, CA, Oracle y Sun. Estas plataformas brindan poder y flexibilidad, pero a costa de complejidad y en la mayoría de los casos requieren in Como un punto medio entre las soluciones desarrolladas internamente, y las plataformas empresariales, tenemos herramientas comerciales dirigidas a asegurar aplicaciones individuales, de forma sencilla y no intrusiva. Entre las opciones más notables de este segmento está Visual Guard, de la empresa francesa Novalys. Esta herramienta ofrece un muy buen balance entre el poder de sus capacidades, y su facilidad de implementación. La limitante es que solo está disponible para plataformas .Net y PowerBuilder, pero si desarrollas aplicaciones sobre estas tecnologías, bien vale la pena echarle un vistazo.

Referencias: [ Gartner Magic Quadrant for Web Access Management, 2H07 ] [ Novalys Whitepaper: Role Based Access Control for .NET applications ] [ visual-guard.com ] www.sg.com.mx

www.sg.com.mx

AGO-OCT 2008

n la xpo e ia y E MTOUR c n e r e P nf ’08 Co onjunto con Capítulo so SG c I e r n M g e P n por ntes, alizó el co cabo vento se re organizado a los asiste ofta ó v s s r lle le io se ión, e oyecto or valo esarrollo de de o de jun n esta ocas cción de Pr rindar may d li 4 p e 2 d m l a s a e b E Del 21 de México. reso de Dir ración fue conferencia pectro más nió a más a u bo ng es d Ciuda 2008, el co e esta cola ron asistir vieron un congreso re otras 400 u ie d l t o d d E o y u ic p g. ás e tiv s, xpo Méx El obje ismo precio e proyecto r networkin ncias, adem nte a la e n . o ic x e e d u e c m r m n a e a Mé n f r h la ió u n a o c s en co istieron s ad, p e por o de direc on quiene s u id e q n t u a n . y sc iste com e as ware tentes colega de 400 as rsonas qu niones de 00 asis 8 pe e d l y reu tota

AGO-OCT 2008

www.sg.com.mx

Keynotes

Las conferencias magistrales de software corrieron a cargo de Jon “maddog” Hall, Terry Quatrani, y John Crupi. Maddog, como de costumbre inspiró a la audiencia y les hizo ver diferentes opciones de cómo hacer dinero con software libre. Terry, quien fue la más laureada del congreso, se enfocó en compartir ideas prácticas sobre modelado ágil de software. Su plática bien pudo haberse titulado “Cómo modelar sistemas de software de forma que sea útil y sin que llegue a convertirse en una pesadilla”. Por último, John, quien nos había quedado a deber su participación desde SG ’06, nos dio una muestra clara de cómo se pueden aplicar mashups en las empresas, y la audiencia no pudo hacer más que quedarse boquiabierta ante las cosas que vio durante esta presentación.

Sesiones paralelas

Como de costumbre, las sesiones paralelas corrieron a cargo de profesionistas locales, buscando así dar una muestra de lo que realmente sucede en las organizaciones de nuestro país. En esta ocasión se llevaron a cabo cinco tracks paralelos, algunos con temas de dirección de proyectos y otros con temas de desarrollo de software. Esto resultó en más de 35 sesiones paralelas en dos días, con lo que se logró cubrir una amplia variedad de temas. De las sesiones paralelas, la mejor evaluada fue la de Héctor Obregón

www.sg.com.mx

titulada “De 0 a 300 a 0 en 6 años”, con una calificación de 4.63 en escala del 1 al 5, seguida por “CMMI para Adquisiciones” de Carlos Pérez (4.60) y “CMMI Ágil” de Ernesto Elizalde (4.55). Agradecemos a todos los conferencistas, que son quienes hacen realidad este congreso.

Tutoriales Posiblemente, el aspecto en el que más trabajamos para mejorar este año fue el de los tutoriales, ya que estábamos concientes de que había sido el aspecto más irregular en años anteriores. Así que para este año hicimos varios ajustes, tales como realizar los tutoriales el fin de semana previo a las conferencias, e invitar exclusivamente a empresas de servicios educativos con un record demostrado. El resultado fue favorable, ya que logramos una muy alta satisfacción de los asistentes. Agradecemos a todas las empresas que participaron impartiendo tutoriales, y hacemos un reconocimiento especial a Activ, cuyo tutorial “Desarrollo de Rich Internet Applications con Flex” fue el mejor evaluado de los tutoriales relacionados con desarrollo de software.

Evento social En esta ocasión el evento social consistió en una fiesta donde los asistentes se juntaron en grupos para jugar el videojuego rock band. Esta dinámica brindó diversión y convivencia (y conbebencia también) entre los

asistentes. Finalizamos con un concurso entre bandas, y los ganadores fueron el grupo denominado “Los Twitteros Rabiosos”, integrado por personas de la empresa Intellekt.

¿Qué sigue?

SG ’08 marcó la tercera edición de este congreso. A lo largo de estos años hemos experimentado diferentes opciones de temas, actividades y formatos para lograr brindar a los profesionistas de software de nuestro país un congreso de clase mundial. La retroalimentación de los asistentes nos indica que esta misión se ha cumplido, y que SG Conferencia y Expo es el mejor congreso de software de Latinoamérica. Sin embargo, lo que no hemos logrado es ofrecer tarifas accesibles para la mayoría de los profesionistas de nuestra región. Esta situación se complica aun más en el contexto de la gran cantidad de eventos gratuitos que se realizan en la Ciudad de México. Es así que actualmente estamos estudiando alternativas para poder seguir ofreciendo este congreso con un alto nivel de calidad, pero en un precio y formato accesible. En cuanto tengamos noticias al respecto, se las haremos llegar. Mientras tanto, agradecemos a Secretaría de Economía por su apoyo mediante PROSOFT, así como a todos los patrocinadores, conferencistas, voluntarios y asistentes que han hecho posible este congreso durante tres años.

AGO-OCT 2008

// ENTREVISTA

Christian Lemaître y León nació en la ciudad de México, cursó la licenciatura en Física en la Universidad Nacional Autónoma de México y el doctorado en Informática de la Universidad de Paris VI. Ha realizado labores de docencia, investigación, desarrollo de innovaciones tecnológicas y consultoría. Fundador de varias organizaciones científicas de computación de México y del extranjero entre las que destacan la Sociedad Mexicana de Inteligencia Artificial (SMIA), la Sociedad Mexicana de Ciencia de la Computación (SMCC), La Organización Iberoamericana de Inteligencia Artificial, (IBERAMIA) y la International Foundation for Multiagent Systems (IFMAS). Fue igualmente miembro fundador del Laboratorio Nacional de Informática Avanzada (LANIA A.C.), y Director Académico del mismo de 1997 a 2002.

Gu ru fun da do rd el as Ci en cia sd el aC om pu tac ión en Mé xic o

CChh rriiss ttiiaa nn LL eem maa îîttrr ee

Desde octubre 2005 se desempeña como Jefe del Departamento de Tecnologías de la Información de la División de Ciencias de la Comunicación y Diseño de la UAM-Cuajimalpa

AGO-OCT 2008

www.sg.com.mx

Existen entre 50 y 70 mil egresados sin empleo, ¿a qué se debe esto? Creo que uno de los problemas es la facilidad para crear carreras y maestrías. Tengo entendido que alrededor del 12% de la matrícula universitaria son estudiantes de carreras relacionada con TI. Eso es muchísima gente, mucho más de la que podemos sustentar con un alto nivel de calidad. Sé que la ANIEI está trabajando para mejorar esto, pero es un reto significativo y están luchando contra corriente.

¿Qué opinas sobre las certificaciones? Yo entiendo el énfasis que se le está dando en la industria a las certificaciones. Si estamos generando a nivel nacional tanto egresado que tiene un título pero cuyas competencias no cubren los requerimientos básicos, o están en duda, entonces desgraciadamente sí tenemos que recurrir a los proveedores o empresas terceras para que validen esto. Sin embargo, esto no es muy eficiente a nivel nacional, ya que estamos multiplicando las acreditaciones y quitándole peso al trabajo de las universidades.

responsabilidad social de la universidad es sacar muchachos con una preparación sólida en los fundamentos, y capaces de seguir la evolución de la computación. Es decir, debemos generar gente que luego va a crecer. El problema es que en muchos casos esa no es la visión del empleador. A él lo que le interesa es contar con alguien que le resuelva un problema en específico, y le tiene sin cuidado el crecimiento de la persona. Esto es un error, porque si las empresas quieren crecer entonces necesitan gente capaz de crecer.

¿Qué otros elementos, además de los técnicos, deben ofrecer las universidades para atraer a los alumnos en este tipo de carreras? El gran problema que tiene la computación, principalmente aquí en México es su éxito comercial, porque lo primero que se ve es la parte física de la computadora, las novedades, las últimas aplicaciones que pueden ejecutarse en ella, opacando la parte de atrás, el esfuerzo que se hace para sacar esas novedades y lo que vendrá durante los siguientes años.

Por dar un ejemplo, yo creo que un ingeniero recién egresado que tiene buenos fundamentos de base de datos, y tiene experiencia con una base de datos que puede ser de software libre, entonces el día de mañana que en su trabajo necesite aprender Oracle, va a tener las bases para hacerlo. Y si la empresa donde está necesita acelerar ese proceso y hacerlo un experto, entonces va a tener que capacitarlo y certificarlo. Eso es válido y comprensible, especialmente en un campo que evoluciona tanto como el nuestro.

Hoy en día, los alumnos pueden hacer toda la carrera de computación con su computaora casera sin ningún problema. Esto es bueno, ya que en todo caso lo centra en lo que realmente debe aprender. Es así que temas como los algoritmos o las estructuras de datostoman mayor importancia que el simple uso de la máquina.

¿Hay que generar gente pensante o certificada?

El problema es de base y muy serio; nuestro nivel educativo tiene mucho que ver en este aspecto. Nos cansamos de escuchar los resultados que tienen los alumnos en los examenes reflejando un problema serio. No se les está inculcando “el gusanito” de buscar las cosas. Pese a eso, siempre existirán los jóvenes que tienen esa curiosidad por ver más allá del caparazón a una computadora.

Creo que este es un falso dilema. Quienes pretenden tener a jóvenes que al salir de la escuela estén certificados en tecnologías y versiones específicas, no están planteando bien el problema. La universidad no tiene porque estar haciendo eso, y más en un área con el ritmo de cambio de la computación. Sí estoy de acuerdo en que debemos enseñar a los jóvenes a utilizar las herramientas del momento, pero no creo que debamos orientarnos hacia las certificaciones ni basar cursos en el temario de una certificación. La www.sg.com.mx

¿En la universidad ya es muy tarde para revertir la mentalidad de consumo y fomentar la creación e investigación?

Debido al dinamismo del área siempre existirán nuevas oportunidades, pero es desgastante ver cómo pasan los trenes.

¿Cómo es tu perspectiva de la industria del cómputo actualmente en México? Creo que se están comenzando a hacer cosas interesantes, como por ejemplo en Guadalajara, que desde años atrás fue un punto de concentración en las áreas de la electrónica. Con altas y bajas, ha habido una cierta continuidad en esta zona, y esto es algo que hace falta en el país; darle seguimiento a todo lo que se realiza para que poco a poco se consoliden cosas y los proyectos.

¿En qué nicho(s) del mercado interncional de TI debería enfocarse México? No estoy seguro, creo que eso deberá ser el resultado de algo previo. Creo que primero debemos enfocarnos en resolver problemas locales. Sentarnos a resolver lo que tenemos cerca. La India estuvo 15 años generando capacidad, y luego se abrió. Los problemas nacionales requieren de muchísimo esfuerzo, y yo creo que eso será un detonador importantísimo. Por ejemplo, si requerimos sistemas para mejorar la producción en los campos agrícolas, este puede ser un terreno interesante y con potencial para las empresas locales, que posteriormente pueden ofrecer esto a nivel internacional.

¿Qué tendencias de TI consideras de mayor relevancia hacia los próximos años? La interacción es una palabra clave, el cómputo obicuo, las redes inalámbricas. Se están multiplicando las posibilidades de interacción entre los sistemas y las personas, Descubriéndose las posibilidades de la red en términos abstractos. Tanto a nivel social (conectividad social) como individual (con un aparato); la interactividad es una de las grandes áreas que involucran una evolución de servicios, las comunicaciones apenas están comenzando a ver su triple play :)

Algunas palabras para nuestros lectores En particular la computación, sigue siendo una área absolutamente fascinante y que vale la pena meterse de lleno, infinitamente maleable. No necesita una infraestructura de plantas sofisticadas para poder experimentar con ella. Puede ser muy divertida y al mismo tiempo múy útil. AGO-OCT 2008

o iccoo x c i é i x x é M é M nM eeenn I I cía I T T T e e o. Gar e c d F d d is a u i a L uuussstttrrriia d d n I n I d a dddeeelllaa In s s o o t t e e RR etos están e s e R qu e anos e Bas Mexic conomía d s o l n una E do co a a í d i c u a ¡C do H n a z i n Orga gica! ó l o n Tec

AGO-OCT 2008

www.sg.com.mx

“Las áreas de mejora pueden incluir las habilidades personales

Lo cierto es que si en México tenemos la oportunidad de encontrar una fuente de ingresos robusta en la industria de servicios TIC’s, esto requiere que nos organicemos antes de que ésta ventana se cierre frente a nuestros ojos.

En este artículo quiero hablarle del siguiente escalón que necesitamos construir para llevar la oferta mexicana hacia un nivel favorable ante los mercados globales. Se trata de ir más allá de la práctica y de incorporar a nuestras organizaciones habilidades competitivas que tienen que ver con aspectos de negocio, de comunicación organizacional y comercial.

» Una vista al panorama actual y retos identificados Ya hemos visto que la oferta mexicana en cuanto a tecnología y sus atributos es suficientemente competitiva como para encontrar un lugar entre las mejores propuestas del mundo. Esta oferta de calidad y conocimientos especializados debe complementarse con habilidades de negocio y de comunicación organizacional, los resultados a su vez sembrarán crecimiento continúo y sostenido.

Estos resultados pueden ser por ejemplo, el lograr que alguna empresa mexicana sea considerada por primera vez como un proveedor para contratos mayores a los mil millones de dólares, tal como los más de 20 que han firmado en los últimos 3 años empresas como: Cognizant, HCL Technologies, Infosys, Patni, Satyam, Tata Consultancy Services (TCS), Wipro, CPM, EPAM, Luxoft, y por supuesto las empresas de costumbre como son IBM, EDS, Perot Systems, CSC y Accenture entre otras. Un contrato de ese tamaño es capaz de dar trabajo a 2,000 personas durante cinco años, por ello lo estratégico de los mismos. Un paso será saltear los retos que se enfrentan en nuestra industria, que han impedido que las empresas mexicanas crezcan más allá de los 5,000 empleados, ya sea por dificultad de localizar suficiente talento o por la curva de aprendizaje ante de promoción y capitalización de las oportunidades en los mercados globales. Una característica de nuestro país es también la disparidad de demanda y oferta entre las regiones y estados, esto hablando del mercado interno que es la principal fuente de ingresos de nuestro sector. Por ejemplo, ante demanda estadounidense, una de las estrategias que han seguido empresas mexicanas es la de proveer a través de sub-contratación. Una estrategia razonable dados nuestros niveles de penetración a los mercados globales y de competitividad en aspectos no-tecnológicos.

www.sg.com.mx

de comunicación”

Y sabemos que a largo plazo una sola estrategia no es suficiente, ya que México es un país grande y sofisticado que es capaz de crear los diversos caminos que requiere, por ejemplo el crear los mecanismos para lograr la incursión directa en el mercado, la búsqueda de los contratos mayores y la proveeduría hacia proyectos públicos (Gobierno).

» Construyendo los bloques competitivos por pasos

Los “bloques básicos para el triunfo” son los elementos que forman una empresa, por ejemplo: administración, ventas, calidad, producción, etcétera. Las empresas, durante su evolución, los adoptan por etapas y siguen hasta que llegan a la cima, una empresa como Cemex cuenta con todos los bloques básicos para el triunfo y es líder mundial en diversas prácticas, Neoris, sigue sus pasos de cerca, por otro lado una nueva empresa contará con menos bloques de triunfo. Ahora en términos de industria, veamos que en nuestro país hay avances destacados en materia de calidad –definitivamente un bloque básico para el triunfo- y recientemente en materia de especialización que ha impulsado México con programas como MoProsoft y ahora Mexico First, ambos parte de la heróica Secretaría de Economía. Ahora bien, además del fondo Prosoft y las diferentes estrategias que ha lanzado, existen apoyos menos promocionados, también en Secretará de Economía existen los fondos PyMes, recursos que quisieran muchos países del mundo ya que los famosos grants o prestamos a fondo perdido son una cosa del pasado. Después tendríamos que preguntarnos si la tarea esta hecha en cuanto a los medios para llegar hacia los mercados globales, para estos también están las bases sentadas, existen programas de promoción de la imagen, como MexicoIT, que claramente debe mejorar y cumplir las expectativas que se tienen del mismo y programas de aceleración hacia Estados Unidos como TechBa. Vale la pena mencionar las acciones orquestadas durante ya más de 4 años por la Secretaría de Economía, en particular por el Prosoft, donde se distingue el esfuerzo contínuo de Rocío Ruíz, Sergio Carrera, Ivette García y muchas otras personas que han dejado su huella en los esfuerzos de ese grupo como Jesús Orta y muchas otras personas en la República Mexicana.

AGO-OCT 2008

No serĂĄ una escalera de mĂĄrmol o un elevador capaz de hacer la tarea por nosotros, pero ahĂ estĂĄn las bases. En pocas palabras en MĂŠxico si no aprovechamos los recursos y posibilidades que hoy existen estaremos desperdiciando una ventada de oportunidad Ăşnica, ya que en temas de calidad, fondeo, promociĂłn y aceleraciĂłn, los profesionales mexicanos si tienen opciones.

Si pensamos que esta necesidad de mejorar surge exclusivamente de la oportunidad, debemos recordar que el entorno global tambiĂŠn esta en nuestra casa, en nuestro paĂs cuando llegan las empresas mundiales a establecerse con nosotros y a obligarnos a ser mejores y mĂĄs. Entonces no solo debemos mejorar para exportar sino para competir con las empresas de clase mundial que ya estĂĄn tocando las puertas de nuestros clientes.

De esta forma las empresas y los profesionales mexicanos estamos obligados a entablar esta carrera de mejora continua, que como vemos ahora nos llevarĂĄ fuera de la fronteras de nuestra tarea diaria, seremos tecnĂłlogos, humanistas, estrategas, vendedores y si, mercadĂłlogos.

Âť ÂżCuĂĄl es entonces el siguiente escalĂłn para capitalizar la oportunidad de MĂŠxico?

Sin duda son los de adoptar prĂĄcticas y aprovechar oportunidades de negocio asĂ como continuar con la promociĂłn y cambio de imagen. .BZPS /FDFTJEBE

.nYJDP )BDJB PSHBOJ[BDJPOFT 5* EF DMBTF NVOEJBM

$POPDFS FM NFSDBEP FMFHJS FM DBNJOP

1SPNPDJwO Z DBNCJP EF JNBHFO

.FEJPT Z SFDVSTPT QBSB FYQPSUBS 1SPEVDUP Z 4FSWJDJP EF DBMJEBE

&OUSFOBNJFOUP FO DPNVOJDBDJwO

$BQJUBMJ[BS 'VODJPOBS FO FM SFDVSTPT Z FOUPSOP PQPSUVOJEBEFT

&KFDVDJwO EF NFOTBKFT FNQSFTBSJBMFT

1SgDUJDBT DPNFSDJBMFT Z EF TFSWJDJP

1SPTPGU

5FDICB

$PSF CVTJOFTT 5FDOPMPHrBT EF *OGPSNBDJwO

$PNQFUJWF -BUJO "NFSJDB

28 22

"QSPWFDIBS WFOUBKBT EJTQPOJCMFT

Ă&#x2021;SFBT EF FOGPRVF EF .nYJDP

1SgDUJDBT Z PQPSUVOJEBEFT EF OFHPDJP

AGO-OCT 2008

.BZPS "WBODF

Âť Los pasos para integrar las capacidades de clase mundial

El primer paso es realizar un diagnĂłstico de su empresa que le permita medir sus competencias a nivel persona, departamento y organizaciĂłn. Este diagnĂłstico le deberĂĄ mostrar las ĂĄreas de trabajo especĂficas, por ejemplo tal vez su empresa sea muy afortunada y cuente con personal altamente capaz en comunicaciĂłn en varios idiomas, tan bĂĄsico como es, tal vez no sea este el caso. Siguiendo con la idea de â&#x20AC;&#x153;escalones bĂĄsicos para el triunfoâ&#x20AC;? cada empresa y cada persona seguirĂĄn un plan distinto, propio a sus creencias, deseos y situaciĂłn actual. DespuĂŠs de realizar un diagnĂłstico, las ĂĄreas de mejora pueden incluir las habilidades personales de comunicaciĂłn. Pocas cosas son tan decepcionantes y vergonzosas como ver a un ejecutivo mexicano realizar una pobre www.sg.com.mx

presentación ante ejecutivos de alto nivel y echar todo por la borda, más allá de la imagen de su empresa también la de la industria nacional, por ello debemos creer en el entrenamiento, la preparación y la práctica, y no lo hacemos. Nuestros ejecutivos deben aprender, y practicar sus habilidades mediáticas, desde las formas de presentarse en una reunión, hasta la ejecución de presentaciones ejecutivas. En estos tres años en promoción de la industria mexicana, solamente he visto cuatro presentadores aptos de más de 30 presentaciones y por otro lado he presenciado ejecutivos mexicanos echar por la borda esfuerzos de meses para ponerlos a ellos ante un foro de clase mundial. Lo más lamentable es que esto es fácil de arreglar. A continuación vienen áreas de usos y costumbres durante la promoción de servicios, son actitudes sencillas para los mexicanos con nuestra cercanía cultural y nuestra distinguida aptitud de calidad humana pronto podemos adoptarlas y dominarlas. Por ejemplo manejo del tiempo durante las reuniones, tiempos de respuesta para regresar con una propuesta, documentación de las propuestas. En lo positivo nuestra manera de formar lazos personales y de calidez son ventajas refrescantes para la cultura de negocios Estadounidense.

Esto en cuanto a las capacidades de comunicación y usos y costumbres del mercado meta, las capacidades estratégicas de una empresa incluyen el saber elegir los mercados de oportunidad, por ejemplo, abrir una oficina en Houston, en lugar de Silicon Valley o el precio en el que debe colocar sus servicios. Más de una empresa mexicana realiza sus primeros esfuerzos sin conocer cuales son los mayores mercados para su oferta comercial, solo porque, tal y como el inmigrante ilegal, conocemos a alguien en tal o cual ciudad. Un error común de la empresa mexicana que incursiona hacia mercados globales es el ignorar los diferentes recursos que existen tanto en México como en el caso de Estados Unidos especialmente diseñados para ayudarles a triunfar y vender más. Igual de común y grave es la carencia de presupuestos y el compromiso de permanencia necesario. Pocas empresas diseñan un plan de entrada al mercado estadounidense coordinado, fondeando, sustentado y que conozca y capitalice los apoyos ya mencionados. Pocas empresas siguen los pasos para establecerse como entidades legales en el mercado meta y mucho menos aprovechar las bondades propias para las nuevas empresas.

Conclusión

orno global para La oportunidad en el ent s continúa presenlas empresas mexicana bargo difícilmente te, y es enorme, sin em ndo se esta transmu el s, nos esperará má as de base tecnoformando hacia economí ico país compiún lógica y México no es el . rfil pe su r tiendo por cambia logías de informaLas empresas de tecno sus líderes, tal vez de ción son un reflejo mación orientafor y es dad por las capaci ctas, no importa, das hacia las ciencias exa e la receta para qu es lo que es relevante mpos no es sufitriunfar en los viejos tie y el futuro. ciente para el presente egar capacidades Los retos requieren el agr ras empresas, habique completarán a nuest rategia de mercalidades de planeación, est iones y ejecutizac ani org dos, comunicación tumbres, estamos va, y dominio de usos y cos evos bloques básiobligados a incorporar nu ras empresas. est nu cos para el triunfo en las empresas gloEl premio, es sumarse a h tigers” por ello wt bales llamadas “fast gro es el nivel de fieál ¿Cu al una pregunta fin organización? reza competitiva de su

Luis García, es Director de Competive Latinoamérica. Trabajó para empresas como IDC y Softtek, y ha dirigido proyectos de estrategia a nivel nacional, ha sido orador en eventos en México, Colombia, Brasil y en United Nations Plaza, presentando el caso de México como Nación. Exprtador de Tecnologías de Información. Puede contactarlo en lgarcia@competive.com

www.sg.com.mx

AGO-OCT 2008

29 23

o lo llo o r l l r o a o esssaarrr e D e D D e e e d d era sss d a a a n a Herr r n n a d a n c a i ja c Ale eeexxxiic M M s s a M a s a s a e a s ppprrreesa a M idd eeedddiid m M M l a l LLaasssEEEm m aarree aaa la w re tw Lea f o ddeeSSSooffttwa idad v i t i t e d p om

eC d o l e od

Un M

30 24

AGO-OCT 2008

www.sg.com.mx

En las últimas décadas, la industria de desarrollo de software a la

medida en el mercado nacional y en el internacional, se ha movido dentro de un esquema perverso de precios bajos en el que las empresas con menor poder de negociación tienden a ser las más castigadas, hasta el grado de desaparecer. Los retos que enfrentan los empresarios mexicanos en esta industria son variados y atienden a diferentes factores, entre otros: • El crecimiento de soluciones estandarizadas o empaquetadas cuyos principales iconos son las empresas transnacionales. • Los altos costos que implica el desarrollo de soluciones de software para industrias o negocios en los que hay poca o nula experiencia. • La escasez de recursos humanos especializados o con un perfil multicultural, para el caso de las empresas exportadoras. Los criterios para el acceso a créditos tanto en la banca comercial como en la banca de desarrollo, al no contar con activos tangibles que representen una garantía ya que su principal activo es capital intelectual Por otro lado, según el Sector Competitiveness Analysis of the Software and Computer Services Industry realizado por el Departamento de Industria y Comercio de Gran Bretaña (2004), el 25.1% del mercado mundial se encuentra repartido entre doce grandes firmas estadounidenses que han extendido sus operaciones y oficinas en diversos países de manera estratégica, en donde el capital humano es abundante y de bajo costo, la infraestructura y normativa en el uso de telecomunicaciones se adecúa a sus procesos de servicio, existe un mercado en donde la demanda es atractiva o las políticas públicas para la atracción de inversión extranjera son flexibles. En la actualidad, Prosoft se ha ocupado de facilitar el camino para competir a partir de la intensa participación del sector empresarial. Sin embargo, entre las tareas pendientes se encontraba la identificación de las fuentes de competitividad propias de las empresas mexicanas de desarrollo de software a la medida que permitieran visualizar las brechas que existen entre las empresas más exitosas y las que no lo son.

Es por ello que como parte del Programa de Doctorado en Ciencias de la Administración de la Facultad de Contaduría de la UNAM, se realizó el proyecto de investigación “Las fuentes de competitividad de las empresas mexicanas de desarrollo de software a la medida”, con el objetivo de encontrar todos aquellos elementos que pueden incrementar la competitividad de estas empresas con las capacidades propias del entorno mexicano. Así, para estructurar el modelo de calidad, reunimos a más de 25 expertos, entre empresarios, consultores de empresa, académicos, representantes del sector gobierno y clientes. La estrategia de investigación se conformó de técnicas de entrevistas, aplicación de cuestionarios y grupos de discusión. Además, los resultados obtenidos se presentaron en distintos foros nacionales e internacionales en donde fueron evaluados por expertos de diversos países. Después de obtener el modelo final y como resultado de todo el proceso de investigación, fue posible diseñar una herramienta de diagnóstico y un índice de competitividad que permitiría visualizar el nivel de apego de las empresas al modelo mismo. La herramienta de diagnóstico fue probada a nivel exploratorio con cinco empresas mexicanas: una de las más exitosas del país y otras cuatro con menor nivel de desarrollo.

» Empresa competidora vs. empresa competitiva

Durante el proceso de investigación identificamos que era necesario definir lo que significa una empresa competitiva y los elementos que la hacen diferente de una empresa competidora, ya que ambos conceptos son básicos para entender la competitividad de las empresas del estudio. Entonces, después de recopilar información de otras investigaciones y artículos y contando con la colaboración del grupo de expertos que participaron en este proyecto, obtuvimos los siguientes elementos que definen a una empresa mexicana de desarrollo de software competitiva:

Estrategia de Negocios

Orientación al Cliente

· Tiene liderazgo empresarial, plan estratégico, visión e indicadores de clase mundial.

· Ofrece valor agregado y efectivo a sus clientes.

· Crece a un ritmo mayor que el mercado.

· Orienta la tecnología al negocio de sus clientes.

· Toma riesgos controlados.

· Seriedad.

· Identifica y gana oportunidades de mercado.

· Puntualidad.

· Tiene presencia en gremios profesionales.

· Cumple compromisos y acuerdos.

· Da seguimiento a nuevas estrategias.

· Altamente enfocada al cliente.

· Busca la excelencia.

· Una ética de trabajo muy fuerte.

· Es permanentemente insatisfecha.

· Sus clientes están muy satisfechos con sus servicios.

· Quiere ser la mejor en un nicho.

· Es socio tecnológico de sus clientes a largo plazo.

· Excede las expectativas del cliente.

· Aporta recursos para lograr ser la mejor. · Incrementa la meta. · Especializada. · Se actualiza en temas de mercado. www.sg.com.mx

AGO-OCT 2008

25 31

Financiera · Es rentable. · Solidez financiera, debe demostrar que no desaparecerá de un día a otro. · Precios atractivos.

Recursos Humanos · Tiene personal experimentado. · Equipo humano estratégico, directivo y gerencial de muy buen nivel. · Personal bilingüe. · Tiene recursos humano motivados y capacitados.

Producción · Proceso estable de control operativo. · Mantiene estándares para todos sus procesos. · Calidad en sus procesos. · Sus productos y servicios son de muy alta calidad.

Gestión Tecnológica · Busca la innovación de productos y servicios.

Por otra parte, una empresa mexicana de desarrollo de software competidora tiene diferencias significativas en comparación con una competitiva ya que su objetivo principal se centra en el uso de estrategias de sobrevivencia y tiene las siguientes características: · No maneja la diferenciación · Basa su oferta en costos y precios bajos · No cuenta con las características enunciadas para una empresa competitiva · Compite y no crece · Es una empresa más · No tiene plan de negocio · No tiene estrategia de calidad · No tiene estrategia de crecimiento · Su único interés es vender · Quizá no permanezca mucho tiempo en el mercado · No tiene calidad · Sobre vende, esto es que realiza ventas de servicios que exceden su capacidad instalada · Sus clientes no están satisfechos con sus servicios · No tiene control de sus operaciones o su administración con un pobre seguimiento de resultados

26 32

AGO-OCT 2008

· Desarrollo a distancia. · Certificaciones en las tecnologías y plataformas que utiliza.

· Es incapaz de identificar áreas de oportunidad y corregirlas · Establece su éxito solo con el número de contratos ganados Una vez definidos estos conceptos, entonces nos enfocamos en identificar todos los elementos que componen la competitividad de este tipo de empresas hasta llegar a conformar el modelo que presentamos a continuación.

» El modelo

El modelo de competitividad se presenta en la figura 1, el cual quedó integrado por el sector externo que está conformado por grupos de influencia en la toma de decisiones de las empresas y el sector interno, representado por todas las fuentes de competitividad que puede desarrollar la empresa con sus propios recursos. Los grupos de influencia tienen relación directa con la definición de la estrategia corporativa y colaboran en el diseño de estrategias, políticas públicas www.sg.com.mx

$MJFOUFT

1SPWFFEPSFT

(PCJFSOP

$PNQFUJEPSFT

4FDUPS FYUFSOP

1SPEVDDJwO EF 4PGUXBSF

'JOBO[BT

1SPZFDUPT "ERVJTJDJPOFT

(FTUJwO 5FDOPMwHJDB

.FSDBEPUFDOJB 7FOUBT Z 4FSWJDJP B $MJFOUFT

* % *OHFOJFSrB Z %JTFvP

3FDVSTPT )VNBOPT

"ENJOJTUSBDJwO Z 0SHBOJ[BDJwO $PSQPSBUJWB

&TUSBUFHJB EF /FHPDJPT

&TUSBUFHJB $PSQPSBUJWB

$BMJEBE FO FM TFSWJDJP

$BMJEBE EF MPT QSPEVDUPT

*OGSBFTUSVDUVSB 4JTUFNBT JOUFSOPT BVUPNBUJ[BEPT Z BENwO EF MB JOGPSNBDJwO 'VFOUFT EF $PNQFUJUJWJEBE 3FMBDJwO EF *OGMVFODJB

$PNQPOFOUFT EFM .PEFMP

Figura 1. Modelo de competitividad

y la conformaciĂłn de la visiĂłn empresarial, lo que se explica de la siguiente manera: El gobierno participa en el desarrollo de las empresas a travĂŠs de lineamientos de polĂtica industrial, fiscal, econĂłmica, comercial, etcĂŠtera, que determinan esquemas de apoyo en las diferentes etapas de madurez de las organizaciones o bien, si son ineficientes, implican un esfuerzo mayor de la empresa por mantenerse en la competencia. Incluso los gobiernos extranjeros juegan un papel importante en la definiciĂłn de barreras para la entrada a sus mercados o bien, en la definiciĂłn de esquemas para el intercambio tecnolĂłgico o la bĂşsqueda de bajos costos provenientes de otras naciones.

'PSUBMF[BT $PNQFUJUJWBT

Con base en el perfil de los clientes locales y extranjeros se diseĂąa el portafolio de servicios y los niveles de exigencia para su negociaciĂłn; la satisfacciĂłn de estos clientes representa el reto permanente de cada una de las ĂĄreas operativas de la organizaciĂłn. Los competidores estimulan el ritmo de crecimiento de la empresa y la renovaciĂłn de nuevas formas de trabajo, nuevos productos y servicios y nuevas estrategias para sobresalir en la competencia nacional e internacional. Los proveedores por su parte, abren oportunidades de financiamiento y de alianzas para complementar competencias e infraestructura; en este grupo participan las instituciones de educaciĂłn superior, la industria de la electrĂłnica, telecomunicaciones, consumibles, entre otras. El sector interno quedĂł estructurado en un primer nivel por la estrategia corporativa, la infraestructura con la que cuenta para la administraciĂłn de su informaciĂłn y lo relacionado directamente con la producciĂłn de software; al siguiente nivel le denominamos subestrategias y al tercero, fuentes de competitividad

La estrategia corporativa comprende la estrategia de negocios, lo relacionado con los recursos humanos, la administraciĂłn y la organizaciĂłn corporativa, la estrategia de mercadotecnia, ventas y servicio a clientes, investigaciĂłn y desarrollo, ingenierĂa y diseĂąo, ademĂĄs de la gestiĂłn tecnolĂłgica, adquisiciones y finanzas. La infraestructura estĂĄ definida por la arquitectura tecnolĂłgica interna de las empresas que permite la administraciĂłn y el manejo de la informaciĂłn operativa de manera automatizada y sistemĂĄtica para la toma de decisiones. La producciĂłn de software se conforma por las funciones relacionadas con la ejecuciĂłn de proyectos y las acciones y elementos que permiten evaluar la calidad del servicio y el producto. La producciĂłn de software basa su operaciĂłn no solo en la elaboraciĂłn de programas para computadoras, sino que su desempeĂąo depende en gran medida de la armonĂa de todos los elementos del sector interno de la empresa.

Alejandra Herrara, es Maestra y Doctora en AdministraciĂłn por la Universidad Nacional AutĂłnoma de MĂŠxico y cursĂł la MaestrĂa en EconomĂa Internacional por el Instituto PolitĂŠcnico Nacional. Es consultora eÂ investigadora en temas de gestiĂłn tecnolĂłgica y de negocios. Ha sido ponente en diversos foros nacionales e internacionales relacionados con nuevas tecnologĂas. Se desempeĂąa como acadĂŠmica en la MaestrĂa en Negocios Internacionales de la misma Universidad en el programa sobre competitividad e innovaciĂłn tecnolĂłgica.

www.sg.com.mx

AGO-OCT 2008

33 27

P ///PPPSSSPP P P P S S T S T l T l aaal nn o i o i n c c a o a i N N c ivvaa a IInniicicciiaiaatttiiva N z In adure El

oa Camin

bien sabido que para desarrollar software de calidad de manera consistente se requiere contar con una alta madurez de procesos. A nivel internacional, el modelo de madurez de procesos más popular es el modelo CMMI. Sin embargo, este modelo es complejo para implementar en empresas pequeñas. En México también tenemos la Norma Mexicana basada en MoProsoft, pero ésta se centra en los procesos de las empresas, más no en los de las personas. La estrategia para incrementar la madurez de la industria de software en México, debe de contemplar no solamente los procesos de las empresas sino, incluir el mejoramiento del elemento básico que da sustento a la industria: las personas. Precisamente en las personas se enfoca el Personal Software Process (PSP) y Team Software Process (TSP), creados por el Dr. Watts Humphrey del Software Engineering Institute (SEI). Es así que la Secretaría de Economía ha dado marcha a la Iniciativa Nacional TSP/PSP, la cual se está trabajando directamente con el SEI y el Dr. Humphrey. El objetivo de esta iniciativa es crear en México la infraestructura humana que permita la introducción y expansión acelerada del uso de TSP, para que la industria de desarrollo de software en México alcance un desempeño superior al de su competencia internacional. Los elementos que se conjuntan y que nos hacen creer en esta oportunidad son los siguientes: • La gran mayoría de las empresas que desarrollan software en México son menores a 50 empleados. • El modelo que utilizan nuestros competidores (CMMI) es complejo y apropiado para organizaciones grandes. • El TSP/PSP, cuando se implementa correctamente, ha probado ser más eficaz que el CMMI Nivel 5.

AGO-OCT 2008

• Con el uso de TSP/PSP las empresas en México podrían tomar ventaja y adelantarse en la incorporación de estos procesos de calidad en menor tiempo y obteniendo mejores resultados. México ya ocupa el primer lugar mundial de personas certificadas en PSP, lo que nos da ventaja sobre nuestros competidores. El SEI busca impulsar significativamente TSP/PSP y está en busca de un socio que le ayude a cumplir este objetivo. México, como país ha demostrado ser un aliado que permitirá continuar con la evolución de dichos modelos.

» Visión

u Velázq

la M

»¿Por qué TSP/PSP?

Beatriz

competitivo que permita acelerar la incorporación del uso de TSP/PSP en México. Si bien, la Secretaría de Economía a través del Prosoft está fondeando el desarrollo de la certificación para TSP organizacional en el SEI, ésta tendrá un reconocimiento mundial. Así al mantener el sello del SEI México, será el primer jugador (first mover) en este esfuerzo, obteniendo ventajas sobre quienes le sigan.

» Relación CMMI-TSP

Por lo regular se necesita de 18 a 24 meses para lograr un nivel en CMMI, lo que se traduce en seis años para alcanzar un nivel 4 y ocho años para alcanzar un nivel 5. Sin embargo, incorporar TSP/PSP acelera el cumplimiento de las prácticas de CMMI de una forma más generalizada en la organización, y recorta significativamente el tiempo necesario para alcanzar cada nivel. Esto sucede porque los integrantes del equipo de trabajo conocen y aplican PSP en sus procesos personales, lo cual acelera la implementación de prácticas organizacionales.

Con la implementación de este proyecto México logrará: • Posicionarse como el país con mejor calidad y valor agregado de manera ágil, adelantándonos a las capacidades de nuestros competidores. • Contar con un método avalado por el SEI que permitirá demostrar objetivamente la calidad de los proyectos desarrollados por las empresas que usan el TSP. • Que la calidad de los desarroConclusión llos con talento mexicano sean ar y rebasar a los Si México quiere alcanz mejores que aquellos con niveles ollo de software, arr países líderes en des o que de rede alta madurez de CMMI. Esto tod mé un se requiere de mejores que los permitirá hacer desarrollos en sultados inmediatos y competidores. los menor tiempo y mejor calidad, lo métodos que utilizan /PSP es ese TSP e qu que se transforma en una ventaja es a Nuestra apuest momento donde de costo. método. Estamos en un los pioneros de podemos convertirnos en r la corta vencha ove » Acciones inmediatas este método y apr emos antes que Las metas para alcanzar a corto tana de tiempo que ten adopten. Si haplazo con la Iniciativa Nacional nuestros competidores lo podrá cumplir se o, TSP/PSP son: cemos bien todo est dijo en junio y hre mp Hu S. • La definición de la primera verlo que Watts ndo volteará a sión del método de evaluación ordel 2006: “En 5 años el mu ieron?” hic le ganizacional del uso del TSP. México y dirá ¿Cómo • La definición del método de mejora acelerada a través del TSP+CMMI. /PSP, • Los estudios de impacto del TSP, n sobre la iniciativa TSP Para mayor informació Velázquez Soto triz para ajustar su uso y prácticas. Bea a tar tac con favor de ia.gob.mx. • Desarrollar una infraestructura de bvelazquez@econom instructores y coaches a un costo

www.sg.com.mx

ST IR ST IR M oF iccoF ĂŠxic MĂŠx ST R I F o MĂŠxi

AndrĂŠs SimĂłn Bujaidar

Clasificando el talento mexica

#10

Concientes de la importancia del ta-

lento humano en el crecimiento de la industria de TI, la SecretarĂa de EconomĂa en conjunto con el Banco Mundial idearon y fondearĂĄn la creaciĂłn y operaciĂłn de MexicoFIRST (Federal Institute for Remote Services and Technologies). Esta acciĂłn pondrĂĄ a nuestro paĂs al nivel de los paĂses lĂderes en materia de TI de alto valor agregado, ya que el alcance de esta iniciativa con carĂĄcter nacional, promoverĂĄ y facilitarĂĄ la capacitaciĂłn y certificaciĂłn de nuestro talento mexicano para llevar a cabo actividades de TI y Business Process Outsourcing (BPO). Asimismo, facilitarĂĄ y reducirĂĄ los costos de reclutamiento de personal de las empresas. A nivel mundial la industria de TI y BPO ha presentado un aumento sostenido en los Ăşltimos aĂąos, las proyecciones nos indican que para 2013 la demanda conjunta en TI y BPO rondarĂĄ los 150 billones de dĂłlares, lo cual representa una enorme oportunidad. Para insertarnos en dicho mercado, la industria de TI en MĂŠxico deberĂĄ crecer a tasas aceleradas para lo cual requerirĂĄ de 150 mil nuevos profesionales certificados en competencias de reconocimiento internacional (50 mil en temas de TI y 100 mil de BPO). Para hacer frente a este reto, la SecretarĂa de EconomĂa a travĂŠs del PROSOFT invertirĂĄ 40 MUSD en los prĂłximos 5 aĂąos para sumarlos a las inversiones estatales y privadas y alcanzar asĂ nuestra meta. MexicoFIRST es una iniciativa de la industria nacional alineada a las mejores prĂĄcticas mundiales teniendo como socios fundadores a la ANIEI y CANIETI. Su misiĂłn es proveer a nuestra industria de las certificaciones necesarias para que nuestro talento en las ĂĄreas de TI y BPO sea reconocido globalmente, vinculando las necesidades de la industria con el trabajo de la academia. www.sg.com.mx

Business Service Management

â&#x20AC;&#x153;Multiswitchingâ&#x20AC;? â&#x20AC;&#x153;Distributed Computingâ&#x20AC;?

Automated Services

Datamining

BPML (4) SOX (1) ORACLE

DiseĂąo de procesos de negocio

SAP

Âˇ Conocimientos funcionales (admin., finanzas, contabilidad) Âˇ Habilidades de ventas Âˇ â&#x20AC;&#x153;Soft Skills para BPO (7)â&#x20AC;?

SOA (2) TSP/PSP SAPF, SAPL XML (5) (Funcional) RFID (3) SAP BPML (4) CORACLE Semiconductores, .NET C, C++ MEMs Maya, JAVA ProTools, Flash (Multimedia) Dreamweaver

â&#x20AC;&#x153;Personal Medicineâ&#x20AC;? WAP (6)

Multimedia

GPS

*OHMnT 1SPKFDU .BOBHFNFOU Figura 1

Â˛4PGU 4LJMMT )BCJMJEBEFT JOUFSQFSTPOBMFT DPNVOJDBDJwO MJEFSB[HP OFHPDJBDJwO FUD Âł

Para lograr cristalizar su visiĂłn se sustentarĂĄ en una misiĂłn que toca tres importantes lĂneas de acciĂłn: â&#x20AC;˘ Otorgar al sector de TI el direccionamiento y las tendencias a nivel global, con el fin de prever y estar siempre a la vanguardia. â&#x20AC;˘ Promover la capacitaciĂłn y certificaciĂłn en competencias de TI y soft skills generales, asĂ mismo promover a todo este capital humano ya certificado para ofrecer sus servicios en este sector. â&#x20AC;˘ Proporcionar el acceso a la capacitaciĂłn y certificaciĂłn personal y empresarial a travĂŠs del establecimiento de alianzas y generaciĂłn de economĂas de escala.

Âť CatĂĄlogo de Certificaciones

Los esfuerzos de MexicoFIRST estĂĄn alineados a cubrir los requerimientos tanto inmediatos como futuros en materia de recursos humanos, para lo que se ha generado un catĂĄlogo de certificaciones progresivo. El objetivo serĂĄ ir elevando el conocimiento en materia de TI y BPO con el fin de buscar niveles superiores de especializaciĂłn. La figura 1 muestra la estructura de este catĂĄlogo progresivo. El modelo de capacidades previsto para los primeros aĂąos de operaciĂłn estĂĄ sustentado por el dominio del idioma inglĂŠs, la administraciĂłn de proyectos y los â&#x20AC;&#x153;soft skillsâ&#x20AC;?. Los tres niveles de especializaciĂłn tĂŠcnica representados por los semicĂrculos concĂŠntricos, nos indican el camino que habrĂĄ de seguir la certificaciĂłn en el paĂs para poder ir avanzando en

la especializaciĂłn y adquirir la capacidad de atender a la creciente demanda internacional. Este modelo nos permitirĂĄ incrementar la especializaciĂłn mediante la adiciĂłn de nuevos niveles y competencias, los cuales se irĂĄn construyendo con una mezcla de revisiones prospectivas y reactivas para seguir ofreciendo recursos certificados en las nuevas ĂĄreas tecnolĂłgicas de vanguardia pensando en ofrecer a la industria nacional y global los servicios y productos que satisfagan sus necesidades de talento, conocimiento y servicio.

Âť Metas

La primera meta de MexicoFIRST es certificar a 6 mil personas al tĂŠrmino de 2008. A partir del prĂłximo aĂąo buscarĂĄ certificar al menos a 12 mil personas de forma anual, lo cual representarĂĄ una inversiĂłn conjunta de mĂĄs de mil millones de pesos en los primeros cinco aĂąos de operaciĂłn. El alcance nacional y la sinergia que generarĂĄ MexicoFIRST con el PROSOFT, los gobiernos estatales y la industria, aunado a una lista de alianzas estratĂŠgicas con las firmas propietarias de los modelos, estĂĄndares y lenguajes le permitirĂĄ acceder a economĂas de escala para brindar servicios de insuperable calidad con una ventaja significativa en el costo. iniciativa n sobre la Ăłn informaciĂł ndrĂŠs Sim or A ay a m r a ta ac Par .mx. vor de cont ob fa .g T, ia S IR om econ MexicoF bujaidar@ Bujaidar as

AGO-OCT 2008

teee??? t t n n n e e e m l m m eeeaaall RR s s R o o s m m e uuueeerrreemo Q Q é é u u Q Q ¿¿Q ¿Qué e un ento d

Rafael

Bernal

País

cimi El Cre

México es un país muy complicado. No nos

tenemos confianza entre nosotros mismos y nuestras ideologías y preferencias partidistas van por encima del bien nacional; preferimos que algo no se haga a que lo haga el contrario, aún si sabemos que es bueno, útil o necesario. Esto nos ha llevado a una inacción de proporciones alarmantes y a una costumbre muy dañina, que es planear ad infinitum para posponer, o de plano no tomar, decisiones. Y así vamos por la vida, anclados a un pasado glorioso que nos dicta nuestro quehacer, mientras otros simplemente ven hacia el futuro y progresan. El problema en estos tiempos es que todos los países nos están rebasando y nosotros seguimos metidos en nuestro profundo laberinto de ideologías, en lugar de enfocarnos a lo que es bastante evidente que puede sacarnos del atascadero, que es crear una base de industria mexicana globalmente competitiva. Tal vez la excepción hoy sea el programa Prosoft de la Secretaría de Economía, que fue desarrollado en conjunto por la propia industria, el Gobierno y la Academia. Afortunadamente ningún partido político ha visto al software con malos ojos, tal vez por que ninguno de nuestros próceres tuvo nada que decir sobre él. Es más, nos tocó ser testigos de que al construirse el edificio para empresas de software en Vallejo a finales del sexenio pasado, tanto en las ceremonias de la primera piedra, —en plena campaña presidencial—como en la inauguración, —con Reforma tomado—se dieron un cordial abrazo el Jefe de Gobierno y el Secretario de Economía, ambos apostando por la industria de software mexicana sobre los problemas políticos partidistas.

Sin embargo, aunque el horizonte parece lleno de esperanza, vamos demasiado lento, o todos los demás van muy rápido. Y es que sin importar la ideología política de cada país, ellos ven primero por lo que les conviene y se dedican a tomar medidas pragmáticas para lograrlo. Un día Deng Xiaoping dijo que era glorioso ser rico, y todo China se volcó a lograrlo. Gran idea, especialmente comparada con la idea que parecemos tener sobre proteger la pobreza en lugar de fomentar la riqueza; parece que es más fácil ayudar al pobre a seguirlo siendo, que crear las condiciones que generen riqueza.

» La excelencia en el estudio

Como ejemplo de esta situación que sufrimos, hago un pequeño comentario sobre la educación. Un día me dijo una maestra de primaria que no era posible exigir la tarea a un niño que no desayunó; le respondí que con esa filosofía probablemente este niño no iba a desayunar toda su vida. Nuestros gobiernos se han dedicado a cubrir con sus alas protectoras a la ciudadanía, especialmente si son pobres, dejándolos en su ignorancia, en lugar de demandar la excelencia en el estudio y luego en la vida. Para cualquier país inteligente que cree realmente en la educación de calidad, ésta es la única actividad donde el elitismo es totalmente aceptado: al niño o niña que tiene el cerebro se le dan todas las facilidades para que obtenga la mejor educación posible, viéndolo/la realmente como el futuro del país. Al que no, se le da solamente el mejor nivel de educación que pueda absorber. En cambio, en México alegamos que la educación universitaria debe ser para todos, y así tenemos que la mejor institución educativa del país debe aceptar muchachos que escasamente saben leer porque “recibir una educación universitaria es su derecho como mexicanos”, cuando el principio debería de ser “recibir una educación al límite de su capacidad es su derecho como mexicanos”. En el primer mundo, China, Cuba,

Rafael Bernal, se dedica desde 1997 a promover una industria mexicana de software competitiva. Su experiencia de 35 años en software incluye CIO en Procter & Gamble México, fundador de Heurística en 1982, entrepreneur en Silicon Valley y actualmente Presidente de Prosoftware, A. C., desarrolladora del clúster de empresas de software del Distrito Federal. Rafael considera que la riqueza de un país está en su gente.

AGO-OCT 2008

www.sg.com.mx

los países asiáticos y los de Europa Oriental, la educación masiva sin requisitos no existe; los que estudian son los que se lo ganan y lo saben desde la primaria, y por eso nos rebasan con mucho. A ellos se les exige mucho y se les trata como adultos, a nosotros se nos da poco y se nos trata como niños. Pero regresando a nuestra industria de software, aunque aún vamos increíblemente lentos –recuerdo que hace 11 años, cuando todo este movimiento empezó, consideré que en unos dos o tres años estaríamos en camino a ser un país de software, ya que era tan obvio el negocio-país para México— parece que avanzamos y estamos empezando a ver un punto de inflexión ascendente en la curva de la industria, que debería ser exponencial, como lo ha sido en India o Irlanda. Analizando hoy lo que ha pasado en esos 11 años y el estado de nuestra industria, considero que lo que hace falta ahora es la infraestructura para fomentar el crecimiento, la que se encuentra en los parques de software. La razón es que la gran mayoría de nuestras empresas, que de hecho son muchas, son demasiado pequeñas para poder competir, no importa qué tanta calidad logren tener. En un mercado de servicios, el tamaño es crucial.

Hoy un parque de software es algo que interesa a muchas entidades. Se han experimentado varias formas de financiamiento, pero considero que la ideal es la ya probada en varias partes del mundo: el gobierno interesado dona el terreno, una empresa que tenga los conocimientos apropiados construye y promueve, y las empresas de tecnología que se instalan ahí tienen las ventajas de un precio menor al del mercado (a cambio del terreno que donó el gobierno), un ambiente adecuado para la sinergia y las asociaciones, así como para la enseñanza accesible de conocimientos para las mismas empresas y sus empleados, y un lugar donde la gente pueda crecer profesional, intelectual y hasta personalmente.

» Logrando entes productivos

Si realmente queremos desarrollar esta industria, los gobiernos tienen que estar convencidos, no sólo de dientes para afuera, sino con su bolsillo y sus propios proyectos, hasta ahora internos, de desarrollo de software. La entidad que realmente quiera será ganadora indudablemente. La que entre tibiamente, se quedará en el camino. Una buena pla-

neación a mediano y largo plazo y una visión verdaderamente de estado harán milagros por la economía de aquellos estados que de veras quieran. Ya estamos viendo que existen estados importadores y estados exportadores de talento, y esto sólo se debe a que algunos tienen ideas y modelos mejores que otros. Nosotros en Prosoftware, una asociación creada para construir el primer clúster de software en el DF, promovemos que las empresas que se sumen a nuestra asociación lo hagan para crecer y ser mejores; los que no tengan estas metas, no podrán ser asociados. Queremos cambiar el esquema de dádivas improductivas por el de ayuda para lograr entes productivos para la sociedad. Queremos demostrar que habemos muchos que sí queremos y que podemos sacudirnos el paternalismo tradicional y usar la reciente libertad de que gozamos para construir una industria productiva para el país.

» Parques tecnológicos

Los parques tecnológicos, en particular los de software, pueden permitir que varias empresas pequeñas se conozcan y promover el que existan motivadores para que logren juntarse en una empresa mayor que tenga la capacidad de atraer clientes e inversionistas. Una empresa de veinte personas apenas podrá llevar alguna metodología de calidad y no logrará tomar clientes interesantes ni mantener al día a su gente o contratar a la gente más capaz a causa su tamaño. Pero si se juntan varias empresas, logrando unos 200 – 250 empleados, esta nueva empresa ya estará en capacidad de buscar mercados más interesantes, de tener capacidad para dar el entrenamiento continuo indispensable a todos sus empleados y de crecer. Todo esto además la puede hacer interesante a los ojos de inversionistas que puedan aportar el capital necesario para un crecimiento mucho más rápido. Recordemos que la demanda por servicios de software es tal que toda la industria India sigue creciendo a más del 20% anual y su tasa promedio anual durante los últimos 20 años es cercana al 30%.

www.sg.com.mx

AGO-OCT 2008

o noo nn a a a m m m u u u H H aalll H iitita p p t a a C C p l ooodddeeell Ca t t e e R R l l EE Ret El

Pedro

Galván

tino s e d l E

nos

nza a c l a ha

ualquiera que participe en la industria de software en México estará de acuerdo en que el reto más grande que enfrentamos es el del capital humano. Hay una gran cantidad de proyectos que están detenidos o se están enviando a otros países porque no contamos con la gente necesaria.

» Algunas cifras a considerar

De acuerdo a las estimaciones de SG, en México existen cerca de 60 mil profesionistas de software activos –con esto me refiero a personas cuya principal actividad laboral es desarrollar o mantener software. Por otro lado, la cifra no oficial que se maneja en la industria de TI es que hay un déficit de 50 mil profesionistas de TI, de los cuales alrededor de 20 mil son específicamente de software. La cifra es alta, pero no se me hace descabellada, ya que tan solo en el último mes platiqué con tres empresas diferentes que necesitaban a mil ingenieros de software cada una. Entonces, si tenemos 60 mil profesionistas de software y nos hacen falta otros 20 mil, estamos hablando de un reto considerable. Ante esto, lo primero que nos preguntamos es cuántos egresados estamos generando. De acuerdo con datos del Anuario Prosoft 2007, anualmente se gradúan 60 mil profesionistas de carreras relacionadas a TI. Esa es una cantidad alentadora, el problema está en que el porcentaje de graduados que cuenta con los conocimientos necesarios para desempeñarse profesionalmente como desarrollador de software es de entre un 10% y 15%. Eso significa que en el mejor de los casos estamos generando 10 mil profesionistas de software al año, lo cual no es suficiente.

» Hemos generado demanda pero …

PROSOFT ha potenciado significativamente a la industria, pero no hemos logrado satisfacer la demanda de gente que hemos generado (ya tengo espacio en el parque tecnológico, tengo infraestructura, conseguí clientes, ¿y ahora donde está la gente para hacer los proyectos?). Un factor que agudiza el problema es que la mayoría de las empresas de nuestra industria son pequeñas y no tienen capacidad para desarrollar personal, ellos necesitan gente que pueda rendir inmediatamente. Y por otro lado, aquellas que tienen capacidad para desarrollar a la gente no están muy dispuestas a hacerlo por el alto porcentaje de rotación de personal (pirateo).

» El riesgo de las certificaciones

Los actores de la industria están muy conscientes del reto de capital humano que enfrentamos, y es por ello que la iniciativa fuerte de este año es la de MexicoFIRST. Creo que este programa reúne buenas prácticas que van a mejorar el funcionamiento de la capacitación y certificación en México. Ayuda a dar enfoque, generar economías de escala, y simplificar los procesos para las organizaciones que contratan servicios para capacitación y certificación. Sin embargo, no debemos perder de vista que las certificaciones solo son el betún del pastel. Previo a lograr una certificación debemos cumplir con los conocimientos fundamentales que requiere un ingeniero de software.

AGO-OCT 2008

www.sg.com.mx

“Primero debemos asegurarnos de establecer los fundamentos y posteriormente enfocarnos en herramientas específicas ”

Las certificaciones facilitan significativamente la venta de servicios de “staffing” para el extranjero. Sin embargo, todos estamos de acuerdo en que ese es un mercado de bajo valor donde solo se compite por tarifa, y esa es una guerra que no nos interesa. Así que si la estrategia es proveer servicios de alto valor agregado, deberíamos preocuparnos primero por generar gente capaz de entender problemas y resolverlos de forma innovadora. Esto no significa que estoy en contra de las certificaciones. Creo que son un elemento importante y hay que impulsarlas, especialmente porque son algo medible. Pero tampoco debemos caer en la ilusión de que son una varita mágica que de pronto va a convertir en “empleable” a alguien que no tiene las bases adecuadas (el mono vestido de seda mono se queda).

» Énfasis en fundamentos

Parecer ser que estamos dando por hecho que nuestros estudiantes y profesionistas de software ya cuentan con los fundamentos de esta disciplina, y solo es cosa de capacitarlos/certificarlos en inglés y métodos/tecnologías específicas. Sin embargo, la retroalimentación que continuamente recibo de los consultores que hacen implantaciones de modelos de calidad de software en nuestro país es que la mayoría del tiempo/esfuerzo de una implantación se va en la capacitación de fundamentos. Es decir, cosas como qué es un requerimiento y qué elementos tiene, qué significa diseñar un sistema de software y qué tipo de decisiones involucra, qué es la gestión de la configuración y por qué es importante. Ante esto, creo que primero debemos asegurarnos de establecer esos fundamentos, y posteriormente enfocarnos en herramientas y tecnologías específicas. De no ser así, solo le estamos poniendo betún a miles de pasteles que no están bien horneados.

» El rol de las instituciones educativas

Las instituciones educativas están conscientes de este problema y están en la mejor disposición de realizar los ajustes necesarios para resolverlo. La ANIEI (Asociación Nacional de Instituciones de Educación en Tecnologías de la Información) generó el modelo paracurricular, que es su propuesta para dotar a los estudiantes con los conocimientos y competencias que requiere la industria. El reto que enfrentan actualmente es el de implementar dicho modelo de forma rápida. Digamos que es difícil transformar a 600 instituciones educativas cuando sólo se cuenta con los ratos libres entre clases. La nota positiva es que el BID recientemente aprobó una cantidad significativa de dinero para fondear el proyecto de implantación de este modelo.

www.sg.com.mx

» Generando experiencia

Otro gran problema que enfrentamos es el ciclo vicioso de la experiencia. Las empresas no contratan recién graduados porque no tienen experiencia y estos nunca generan experiencia porque no los contratan, pasan los años y terminan poniendo un Internet café o dedicándose a otra cosa. Aquí no hay una solución única, sino la suma de muchos pequeños esfuerzos. Una de las herramientas con las que contamos y debemos aprovechar mejor son los periodos de prácticas profesionales que se dan en la mayoría de las universidades hacia el final de la carrera. Hay que armar y gestionar bien estos programas para que brinden experiencia realmente útil a los participantes. Por otro lado, las empresas deben apostarle más a estos recién graduados. Ciertamente ayudaría contar con mayores incentivos para quienes emplean gente por primera vez, además de mayor protección contra el pirateo de gente, pero aun así las empresas también deben poner su parte y pensar en que al entrenar a un ingeniero de software, aunque este se vaya a otra empresa, le está haciendo bien a la industria en general y ese beneficio le va a regresar a la empresa de una u otra forma.

» Nada sirve sin la participación de las personas

A pesar de todo esto, no debemos pasar por alto que aunque definamos los mejores modelos de competencias y consigamos todos los recursos para implementarlos, si los estudiantes y profesionistas no le entran a este esfuerzo, todo va a ser inútil. Desde mi punto de vista, la gran mayoría de los estudiantes y profesionistas de nuestra industria se encuentran en su área de confort. Hay miles de personas que trabajan en el área de sistemas de su empresa y que consideran que con saber más o menos como funciona el ERP en su empresa (o cómo está estructurado su warehouse), ya con eso la hacen. Hay otros miles de estudiantes que piensan que con graduarse ya tienen trabajo seguro. Ellos piensan que simplemente por tener un título de Ing. en Sistemas ya merecen ser gerentes de sistemas en un banco, y si no entonces es culpa de la universidad o del gobierno. Es triste ver que países como Argentina o Colombia, que tienen muchísimo menos habitantes que México, tienen más participantes que nosotros en programas de certificación gratuitos, como el de desarrollador cinco estrellas de Microsoft (tan solo por dar un ejemplo). Le hemos entrado a una competencia global. El gobierno tiene esto muy claro, las empresas también, pero al parecer las personas todavía no. Y mientras no logremos cambiar esta actitud, ningun programa de formación va a servir.

AGO-OCT 2008

// COLUMNA invitada

Lecciones Aprendidas de la Quiebra de Air-Go Technologies Cuando el ego nos alcanza Por Héctor Obregón

e 1996 a 2002 tuve la oportunidad de participar como fundador y Director General de una empresa de servicios de desarrollo de software en México. Esta empresa inicialmente se llamó InterSoftware y más adelante Air-Go en su último año y medio de vida. En ella perseguimos el sueño de crear la mejor empresa de su tipo en México. Durante varios años creímos que lo lograríamos y después, en un periodo de tiempo muy corto, fallamos por completo resultando finalmente en la desaparición del negocio. InterSoftware/Air-Go pasó de 5 colaboradores en 1996 a más de 300 en el año 2001. Para el 2002 había desaparecido como entidad funcional. Nuestra empresa fue de las primeras en México en el desarrollo de aplicaciones para dispositivos móviles (1998), búsqueda formal de certificación CMM (1998), implementación de un modelo de fábricas de software de bajo costo (1999), obtención de fondeo institucional de capital de riesgo (1999), exportación de servicios de desarrollo de software a Estados Unidos (2000), y crecimiento mediante la consolidación con competidores (2001). Aunque nuestra visión puede haber sido la correcta en varios aspectos, quizá se adelantó un poco a su tiempo y, mucho más importante, nuestra ejecución fue incompetente. En este artículo comparto mis experiencias personales a través del proceso del fracaso de esta empresa así como las que considero son las principales lecciones que espero haber aprendido durante el proceso.

Las causas del fracaso Tuvimos mucho éxito en un periodo corto de tiempo y con relativa facilidad. Desafortunadamente, en mi caso personal eso me condujo a una actitud de soberbia que me cegó a la posibilidad de visualizar los problemas que se avecinaban con el tiempo suficiente para actuar y prevenirlos. Varios de mis colaboradores y socios se acercaron

AGO-OCT 2008

conmigo para alertarme sobre esto pero esta soberbia me impidió escucharlos. Una tremenda frase que jamás olvidaré refleja la actitud que tenía en 1999. Poco después de haber acordado la primera ronda de financiamiento institucional para la empresa por un monto de un millón de dólares, le comenté a mi socio co-fundador de la empresa: “Ya no es posible que fallemos después de esto.”. Varios años después, inmerso en la crisis del negocio, otro de mis socios, un empresario exitoso radicado en Estados Unidos me comentaría que mantiene en su oficina un enorme poster de PanAm Airlines (ahora desaparecida) para nunca olvidar que, sin importar el tamaño o el éxito alcanzados, la posibilidad de perderlo todo siempre estará vigente. El éxito aparente también nos había colocado a mí y a algunos de mis colaboradores dentro de nuestra zona de confort. Nuestros ingresos personales eran más que suficientes para llevar una vida cómoda y estaban totalmente desconectados de la rentabilidad y la generación de valor de la empresa. Aún cuando como socios deberíamos haber estado más preocupados por el desempeño financiero del negocio, la realidad de nuestro día a día era demasiado cómoda. Sin duda otra de nuestras fallas fue el intentar hacer demasiadas cosas al mismo tiempo. En un periodo muy reducido de tiempo expandimos nuestras operaciones a Guanajuato, Monterrey y, mucho más difícil, Estados Unidos. Todo esto sin tener experiencia previa sobre las implicaciones de administrar un crecimiento acelerado. Alcanzamos a nuestro nivel de incompetencia rápidamente. Acabamos haciendo muchas cosas mal en lugar de pocas bien. Lo más grave fue que estas operaciones distrajeron la atención de la dirección del negocio principal que probablemente hubiera podido salir adelante con más atención.

Mi ego en ese momento influyó también en algunos conflictos con mis socios. Llegue a estar más preocupado por mi posición interna y externa como Director General que por la salud del negocio. Fue fácil distraerme con juegos de poder donde ya no se trataba de lo mejor para el negocio sino de lo más placentero para el propio orgullo. En particular este problema se hizo manifiesto en nuestro intento fallido de fusión con otra de las empresas líderes del mercado en ese momento: Kiven. Mi conflicto con su Director General, fue el factor determinante para el fracaso de esta operación que probablemente, bien ejecutada, hubiera resultado de gran beneficio para ambas empresas. Tomamos riesgos extremos en la operación financiera de la empresa. La supervivencia y el muy acelerado crecimiento durante 4 años no nos sensibilizaron al nivel de riesgo que adquirimos. Adicionalmente en el periodo 1996-2000 era muy fácil para una empresa innovadora en el sector de IT obtener fondos y financiamiento debido al entusiasmo general en los mercados sobre las posibilidades de este tipo de empresas. Este entorno reforzó la precepción que teníamos de ser prácticamente infalibles.

La experiencia del fracaso La postura personal de orgullo que condujo a mi empresa a fracasar se enfrentó con la dura realidad en aún menos tiempo del que había tomado el “éxito”. Cuando disminuyó el ritmo de crecimiento de la compañía hacia fines del año 2000 debido a la combinación de una desaceleración de la economía y del tamaño que habíamos alcanzado ya, en cuestión de un trimestre se hicieron sentir en el flujo de efectivo los problemas de rentabilidad sistémicos que el negocio tenía. Durante años la acelerada tasa de crecimiento en ventas (de alrededor de 100% anual) permitía financiar la operación de la empresa aun cuando su rentabilidad real fuera entre mediocre e inexistente.

www.sg.com.mx

“Debemos respetar a cualquier socio potencial de tal manera que sus aportaciones sean genuinamente efectivas, para el desarrollo del negocio”.

Pocas cosas son más difíciles que enfrentarse a dificultades de flujo de efectivo de corto plazo en la operación del negocio. Rápidamente nuestras líneas de financiamiento estaban saturadas y nos enfrentamos a problemas para solventar los costos de operación más indispensables como la nómina de nuestro personal. Simultáneamente la “luna de miel” con los inversionistas institucionales terminaba y nos enfrascamos en discusiones sobre cómo solucionar el problema sin llegar a acuerdos a la velocidad que la situación demandaba. Los clientes se percataron de nuestros problemas y, naturalmente, perdieron la confianza en nosotros como proveedores lo que aceleró nuestra caída. Provocando que los inversionistas institucionales perdieran la posibilidad de creer en mí y se negaran a proporcionar fondos adicionales para “darle la vuelta” al problema. Aún cuando nuestros colaboradores hicieron un importante esfuerzo por seguir operando, aun ante la falta de pago, naturalmente esto nos llevó a un desgaste finalmente insalvable. Para fines del 2001, la única opción que me quedaba para evitar el cierre inmediato de la empresa era aceptar mi remoción como Director General para tomar las funciones de ventas. Fue muy poco y demasiado tarde. Consideraba, y sigo considerando, a mis principales colaboradores como mis amigos. El afecto hacia y desde ellos dificultó enormemente contar con la claridad suficiente para tomar las decisiones adecuadas. En cuestión de meses pasé de una posición de orgullo desmedido al otro extremo emocional. Me sentí la persona más incompetente y estúpida del mundo. Las malas noticias adicionales, por pequeñas que fueran, me provocaban crisis de pánico. Resultaba casi imposible levantarse a trabajar todos los días y la magnitud del problema me sobrepasó tanto personal como profesionalmente.

www.sg.com.mx

Superar el vacío Ahora, varios años después, no puedo más que sentirme afortunado de haber superado ese momento extraordinariamente doloroso y difícil. Hay una serie de elementos que fueron clave para poder salir adelante. Sin duda lo más importante fue el que, aún durante el punto más álgido, conté con el apoyo de varias personas que siguieron creyendo en mí. Esta confianza fue el salvavidas que en ese momento me permitió no ahogarme. Puedo mencionar a Mauricio Mingramm, mi actual socio en emlink, a Marcos Achar, Director General de Comex (que continúa siendo nuestro cliente) , a mi tío Raúl Obregón, y a un compacto equipo de colaboradores que continuaron creyendo en mí a pesar de todos los errores que cometí. A todos ellos les estaré agradecido el resto de mi vida por su apoyo y confianza. Durante este trance descubrí el significado de la fe. No soy un hombre religioso. Sin embargo, jamás había estado en una situación donde tuviera que simplemente creer que iba a salir adelante sin tener la más remota idea de cómo lo lograría ni ningún fundamento lógico para creer que fuera posible. Creer genuinamente en algo sin ningún fundamento racional es para mí el significado más claro de la fe. Fue necesario procesar emocionalmente el fracaso y asumirlo. Esto no me fue posible hacerlo rápidamente. Se requiere un espacio de tiempo para poder procesar el duelo. Sin temor a exagerar, me parece que el dolor de ese momento haya sido similar al de la pérdida de un ser querido. No es posible salir adelante de un dolor de este tipo sin darle oportunidad de seguir su curso. Necesité aprender a mirar siempre hacia el futuro y rápidamente dar vuelta a las páginas del fracaso. La tentación del enojo y de aferrarse al éxito anteriormente logrado era

fuerte y creo que me hubiera hecho perder más tiempo y dedicarle energía a persecuciones sin sentido. En la medida de lo posible, busque enfrentar la situación con la máxima franqueza posible con los distintos afectados por el cierre de la empresa. Había que darle malas noticias a muchas personas. A los colaboradores, socios, acreedores, clientes y proveedores. Todos se vieron afectados negativamente por los errores que cometimos. En la gran mayoría de los casos, el trato franco con ellos evitó problemas muchos mayores. Los casos donde no me fue posible hacerlo o no dediqué el tiempo necesario fueron los que se complicaron después convirtiéndose, por ejemplo, en serios dolores de cabeza legales. Sin embargo, creo que no es posible satisfacer a todos los afectados. Hay que entender esto y prepararse para asumir las consecuencias.

10 lecciones aprendidas Las siguientes lecciones de aprendizaje personal no pretenden ser una receta general para quien se encuentre en una situación similar. No son resultado de un amplio estudio de casos. Simplemente son un breve resumen de lo más significativo de lo vivido personalmente a lo largo de la experiencia relatada y de la posterior búsqueda de construir una nueva empresa, emLink. 1. La gente vale la pena Mencioné que el afecto con y desde mis colaboradores dificultó la toma de algunas decisiones importantes. Sin embargo, no me imagino ni me interesa la construcción de una relación de trabajo sin afecto. Estoy absolutamente convencido de que la construcción de un afecto es indispensable para lograr una motivación de conjunto y un liderazgo efectivo. Así que, en lugar de renunciar a este me parece que lo mejor es incorporarlo dentro de una ética de trabajo y claridad en la definición y evaluación de objetivos profesionales.

AGO-OCT 2008

// COLUMNA invitada

“Los clientes se percataron de nuestros problemas y, naturalmente, perdieron la confianza en nosotros como proveedores, lo que aceleró nuestra caída”.

Esto permite a las dos partes involucradas en una relación de trabajo contar con un marco de evaluación objetivo sobre los resultados del trabajo conjunto. 2.Ten un sueño Después del fracaso vivido, pasé una temporada abandonando mis sueños, enfocado exclusivamente a la rentabilidad de corto plazo y la estabilidad del nuevo negocio para evitar a toda costa una repetición de la experiencia anterior. Ahora me parece que sin un sueño no es posible construir una misión efectiva, atraer y retener a los colaboradores talentosos que cualquier empresa que desee ser exitosa requiere. 3. Busca socios que compartan tus valores Los conflictos que con mayor facilidad pueden destruir a una empresa, son entre los socios de esta. Entrar en una sociedad de negocios implica evaluar claramente nuestro entendimiento. Vale la pena incorporar desde un inicio la posibilidad de la separación. Como en un matrimonio dónde la posibilidad real del divorcio nos motiva a construir la relación todos los días. Un socio debe compartir valores e idealmente complementarnos en habilidades, capacidades y puntos de vista. Debemos respetar a cualquier potencial socio de tal manera que sus aportaciones sean genuinamente efectivas para el desarrollo del negocio. 4. Se un Nazi con tu disciplina financiera Para las empresas generar utilidades es equivalente a comer para el ser humano. Si un negocio no es rentable tendremos asegurada la imposibilidad de alcanzar los sueños y la visión que hemos trazado para este. Por lo tanto, vale la pena ejercer una férrea dis-

ciplina en este aspecto. Es necesaria para el bien de todas las entidades relacionadas con una empresa: socios, colaboradores, clientes, proveedores y acreedores. Una empresa que no es rentable acaba fallando con la comunidad con que se relaciona. 5. Que mantener el foco sea la doctrina Siempre que emprendamos una nueva iniciativa hay que evaluar con honestidad si realmente tendremos la capacidad de ejecutarla y llevarla a término. Es fácil caer en la tentación de hacer más de lo que realmente tenemos capacidad de ejecutar. Una cosa a la vez. O, cuando mucho, tantas como podamos ejecutar efectivamente. 6. Ten paciencia La velocidad de ejecución siempre es menor a la velocidad de la imaginación. Es necesario tener paciencia para ver que aquello que imaginamos se convierta en realidad. Hay que ser enconadamente persistentes y entender que cualquier proceso de cambio que involucre la participación de un equipo de trabajo llevará tiempo. Los sueños si son alcanzables, más no sin esfuerzo, tenacidad y paciencia. 7. Sin riesgo no hay (casi) crecimiento Toda empresa implica un riesgo. Sin importar cuantas lecciones creamos haber aprendido, si queremos crecer y alcanzar nuestro sueño como organización, habremos de asumir riesgos que nos pueden llevar al fracaso. Es inevitable esta relación. Sin embargo, podemos buscar calcular el riesgo de tal forma que nos podamos permitir siempre la posibilidad de fallar en alguna iniciativa individual sin que esto conduzca al fracaso total de la empresa.

8. 1% inspiración, 99% ejecución El mundo está lleno de grandes ideas. ¿Cuánta gente no conocemos que celebra que “se le ocurrió primero” o “ya lo veía venir”? La diferencia entre un espectador y un protagonista en mi opinión, no son las ideas, es la capacidad de ejecutar sobre sus ideas y llevarlas al resultado final deseado. Los planes en nuestra mente siempre serán posibles. La realidad es otra cosa. 9. Para emprender hay que ser un poco bipolar Es necesario mantener un optimismo (casi) irracional sobre el futuro. Mantener el entusiasmo y la convicción de que el sueño que hemos trazado como objetivo es en verdad alcanzable en todo momento. Transmitir ese entusiasmo a todo nuestro entorno. Al mismo tiempo, se necesita un pesimismo (un tanto) irracional para la toma de decisiones financieras. ¿Realmente es necesario este gasto?, ¿podríamos vivir sin él?, ¿podemos ejecutar esta inversión? Planea para el mejor escenario, ejecuta previendo siempre el peor escenario. Recuerda que siempre se puede poner peor. 10. No se te olvide por qué estás aquí Más allá de cualquier consejo práctico de negocios, evalúa contantemente por qué haces lo que haces. ¿Contribuye el ser empresario a tu felicidad? Es fácil perderse en el día a día y un día darse cuenta de que el sueño se ha ido o de que la rutina nos ha absorbido. De vez en cuando vale la pena hacer una pausa en el camino para evaluar por qué somos empresarios. Cada uno tendrá que encontrar su propia respuesta.

Héctor Obregón (http://msdnfan.blogspot.com) es Director General de emLink desde 2002 (www.emlink.com.mx), Microsoft MSDN Regional Director y Microsoft MVP para Windows Embedded. De 1996 a 2002 fue Director General de Air-Go Technologies (antes InterSoftware).

AGO-OCT 2008

www.sg.com.mx

AGO-OCT 2008

// PRÁCTICAS

/*ASEGURAMIENTO DE CALIDAD*/

Revisiones entre Colegas Una Práctica de las Mejores Por Edith Martínez

Las revisiones entre colegas (peer reviews) están descritas dentro del proceso de verificación de CMMI, y tienen como objetivo asegurar que los productos de trabajo seleccionados cumplan con los requerimientos especificados. Estas revisiones son un mecanismo de verificación eficaz para prevenir y eliminar defectos, además de identificar oportunidades de mejora. Estas revisiones típicamente son aplicadas por compañeros de trabajo, muchas veces integrantes del proyecto que tienen un interés en el artefacto bajo revisión. Los revisores son conocidos como colegas, ya que tienen roles o actividades similares a los del autor del producto. La aplicación de las revisiones entre colegas tiene diversos beneficios: • Promueve la generación de productos completos y correctos. • Ayuda a establecer un estándar de excelencia. • Promueve el seguimiento del estilo y reglas de construcción en los proyectos. • Provee múltiples vistas en las revisiones. • Permite obtener mediciones para mejorar el proceso y administrar la calidad de los productos.

Algunas definiciones

Formalmente, una revisión es una técnica para encontrar y eliminar defectos de productos de trabajo, tan temprano como sea posible y de manera efectiva. Un defecto es: • Cualquier ocurrencia en un producto de trabajo que determine que esté incompleto, incorrecto o con faltantes. • Cuando no se satisface un requerimiento. • Una inconsistencia o violación a estándares. Se recomienda el uso de listas de verificación, o checklists, que fungen como base para la revisión de artefactos. Un checklist es: • Una lista de elementos en forma de preguntas y/o características. • Resume los problemas técnicos potenciales para una revisión. • Son utilizados durante la etapa de preparación y de ejecución de revisiones. Hay diferentes tipos de checklists o bien se pueden revisar diferentes características como: que el producto esté correcto o completo, que siga reglas de estilo, construcción, etcétera.

Roles participantes Estos son los roles que típicamente participan en la revisión: • Moderador. Es quien se asegura que se envíen los productos a los involucrados, que la revisión se conduzca correctamente, se revise al producto y no a la persona, se compartan las observaciones y se hagan las modificaciones pertinentes. • Autor. Elabora o desarrolla el producto que se revisará. Durante las revisiones provee las explicaciones necesarias sobre el producto en revisión. • Revisores. Son los expertos o colegas que se preparan para la revisión, encuentran defectos y retroalimentan acerca de las observaciones. • Tomador de notas. Es quien completa las formas con los hallazgos encontrados, observaciones realizadas, registra los tiempos y clasifica los hallazgos. • Lector. Participa realizando lecturas relacionadas al producto revisado, en caso de ser requerido. Es importante hacer notar que no es requerida una persona para ejecutar cada rol, por el contrario una persona puede realizar dos o más roles de acuerdo a las necesidades, cuidando que nadie sea juez y parte para asegurar la objetividad. Durante la revisión es importante enfocar las observaciones solo hacia el producto y no al autor, así como asegurarse que se levanten defectos y no soluciones, pues las últimas pueden tomar más tiempo del esperado y afectar en el lapso de las revisiones.

Tipos de revisiones

Existe variedad en los tipos de revisiones, cada uno con características diferentes y con diferentes propósitos. Algunos de estos tipos se describen a continuación: Inspecciones de software • Es la forma de revisión más estricta. • Revisiones a profundidad. • Criterio de salida para cada fase. • Dirigida por el líder revisor y asistida por participantes. • Se obtienen métricas (Producto y proceso). Walkthroughs • Medio para llegar a consenso. • Útiles para aprendizaje informal. • Dirigidas por el autor. • No hay métricas.

Edith Alhelí Martínez Mata es Consultor especializado en Aseguramiento de la Calidad, en Avantare Consultores. Sus áreas de especialidad son las Inspecciones de Software y Procesos de Soporte basados en CMMI y SW-CMM. Edith es Licenciada en Informática por el Instituto Tecnológico de Aguascalientes (ITA), y ha participado como consultora en varios proyectos para la implementación de CMMI así como en evaluaciones SCAMPI.

AGO-OCT 2008

www.sg.com.mx

Revisiones técnicas • Busca consenso. • Útiles como capacitación. • Se expone el producto y se busca aprobación. • Útiles para productos complejos o de nueva tecnología. • Se requiere experiencia técnica. • Métricas no son obligatorias Revisiones cruzadas • Determinan el estatus del producto. • Carga extra requerida es mínima. • Revisiones en pares. • Facilita el intercambio de información. • Típicamente utilizadas para diseño y codificación. • Se recolectan algunas métricas.

Fases de la inspección de software

La realización de una inspección de software requiere de varias fases que se detallan a continuación: Planeación. • Planear inspección en el calendario del proyecto. • Identificar qué productos revisar y los tipos de productos. • Asignar responsables (autor y moderadores). Preparación • Validar que el producto esté listo. • Asignar revisores, y resto de los roles. • Verificar checklists listos y distribuir el material para revisión. Sesión de inspección • Revisar el producto. • Registrar y clasificar hallazgos. • Clasificar defectos. • Clarificar dudas puntualmente. Reporteo • Dar a conocer los resultados, hallazgos y métricas. Seguimiento • Asegurarse que se llevan a cabo las correcciones. • Registrar el cierre de los defectos. • Levantar métricas.

Costo y beneficios

El costo de implementar esta práctica en realidad no es muy alto, ya que es una actividad que se ejecuta naturalmente por los equipos de trabajo. La ejecución de una revisión se lleva un máximo de 4 horas, considerando los tiempos de preparación y ejecución, y nos da resultados cualitativos y cuantitativos al momento. www.sg.com.mx

Entre los principales beneficios que proveen las revisiones entre colegas están: • Acortamiento de tiempos. • Reducción de costos. • Mejora en capacidad de predicción. • Mayor satisfacción del cliente. • Mayor entusiasmo en el personal. • Retorno de inversión atractivo. De forma cuantitativa, las expectativas de ahorro pueden esperarse en: • 60% al 80% de los defectos eliminados antes de la ejecución de las pruebas • Reducciones en la escala del tiempo de hasta el 25% • Reducción hasta en 5 veces de los costos de pruebas La revisión entre colegas es una práctica que por sí sola genera un retorno de inversión visible, ya que ayuda a incrementar la calidad y reducir costos.

Preguntas comunes

¿Quién decide qué debe ser revisado? El líder técnico o de proyectos. ¿Qué revisar? Productos de alto impacto, productos asociados a riesgos, y productos asociados a objetivos de calidad. ¿Cuándo planear las revisiones? De acuerdo al tipo de revisión, en el plan y al inicio del proyecto o fases.

Recomendaciones

Algunos principios importantes de las inspecciones de software: • Limitar las inspecciones a periodos de alta concentración (2 horas). • Revisar productos, no personas. • Identificar defectos, no soluciones. Algunos riesgos comunes que pueden dificultar la implantación de la práctica o limitar los beneficios de ésta, y que por lo tanto deben tenerse en cuenta para manejarlos adecuadamente: • Los participantes no entienden el proceso de revisión. • Los revisores critican al autor y no al producto. • Falta de planeación de las revisiones. • Las juntas se enfocan a la solución de problemas de estilo. • Falta de preparación y/o los revisores no son los adecuados. • Proceso no compatible con las características de la organización. Y entonces ¿qué esperamos para llevar a cabo prácticas de revisiones entre colegas?

AGO-OCT 2008

// PRÁCTICAS

/*PROGRAMACIÓN*/

Aprendiendo Ruby y Rails Parte 4. El Framework Rails Por Carlos Ortega

El presente artículo es el cuarto y último de la serie que tiene la intensión de introducir al lector los principales elementos del lenguaje de programación Ruby y del framework Ruby on Rails. En esta ocasión se tratarán los temas del controlador y las vistas.

El Controlador Contrario a lo que podría indicar el nombre del patrón: MVC, en Rails se aconseja desarrollar primero el controlador antes que la vista. Para lograr esto, Rails echa mano de una clase especial llamada ApplicationController, a través de los siguientes pasos:

a) generar una clase derivada de ApplicationController y b) manipular con esta clase, a nuestra clase que representa el modelo para lograr el acceso a la base de datos. Manteniendo la misma filosofía de generación automática de capas, el comado generate permite uitlizar el parametro controller para acceder a la clase ApplicationController, para invocarlo abriremos una sesión en linea de comandos, nos posicionaremos en el directorio railsass e introduciremos: path/trabajo/railsass>ruby script/generate controller Usuario

Ahora bien, los constructores de Rails han diseñado el framework de tal manera que los métodos que se definan dentro de esta clase coincidan con las acciones que se generen en las vistas, es decir, si se desea que se realice un evento específico dentro de las vistas, el código que representa ese evento podrá estar contenido dentro del nombre del método o función que definamos dentro del controlador. Por ejemplo, supongamos que dentro la vista new.rhtml invocamos al evento agregrar un nuevo Usuario esto, mediante la liga <%= link_to “Agregar un nuevo Usuario”, {:action => ‘new’}%>

Entonces si deseáramos que al activar esta liga se ejecute un código determinado X, tendremos que definirlo dentro un método o función del controlador cuyo nombre coincida con el nombre de la acción, en este caso new. El siguiente diagrama intenta ilustrar mejor este mecanismo. <h1> Agregar un Nuevo Usuario </h1> </br> .... ..... <%a= link_to ”Agregar un Nuevo Usuario”, {action=>’new’}%> ..... .....

class UsuarioController < ApplicationController def metodo1 ... end def metodo2 ... end def new # CODIGO QUE # DESEAMOS QUE SE EJECUTE end ... end

new.rhtml

usuario_controller.rb

Una vez entendido este concepto podemos proceder a incorporar la parte que manejará al modelo actualizando al controlador: class UsuarioController < ApplicationController

Además de haber creado automáticamente el archivo con el nombre usuario_controller.rb destinado a contener la clase controladora, también se habrá creado un directorio usuario debajo del directorio views que contendrá los archivos RHTML que manejarán las vistas, un archivo usuario_controller_test.rb para realizar pruebas funcionales y archivo usuario_helper.rb dentro del directorio helper que podrá utilizarse para albergar clases adicionales de soporte que puedan requerirse. Al abrir el archivo usuario_controller.rb que se encuentra dentro del directorio app/controllers ,podemos observar que en este se encuentra la clase UsuarioController la cual es derivada de ApplicationController: class UsuarioController < ApplicationController end

AGO-OCT 2008

#---Mostrar la lista de Todos los Usuarios---# def list @usuarios = Usuario.find( :all ) end #--- Crear un nuevo Usuario en Memoria ---# def new @usuario = Usuario.new end #---Creamos Un Nuevo Usuario ---# def create @usuario = Usuario.new( params[:usuario] ) if @usuario.save redirect_to :action => ‘list’ else render :action => ‘new’ end end

www.sg.com.mx

“En Rails se aconseja desarrollar primero el controlador antes que la vista”.

#---Mostrar el detalle de Un Usuario---# def show @usuarios = Usuario.find( params[:id] ) end end

La siguiente étapa es la construcción de las vistas.

Como se puede apreciar a excepción del método show que muestra la lista de todos los Usuarios, hemos creado varios métodos que corresponderían a la funciones CRUD de un objeto de negocio Usuario. Por otra parte es interesante observar como es que a su vez estos métodos manipulan al Usuario, es decir, dentro de ellos se invocan las diferentes funciones de ActiveRecord, de ahí que el método find de Usuario acepte como parámetro un objeto específico, como una variable de entorno (params[:id) o un símbolo (:all) que representa la condición para regresar todos los objetos Usuario. Por otra parte, la invocación de método redirect_to resulta en la una nueva llamada a la acción y el refrescado de la página web correpondiente. Para simplificar nuestra revisión en este momento nos concentraremos solo en un objeto, no tocaremos las relaciones (behaviours) entre otros tipos de objetos de negocio.

<h1> Usuarios del Sistema </h1> </br> .... ..... <%a= link_to ”Listar Usuario”, {action=>’list’}%> ..... ..... list.rhtml <h1> Agregar un Nuevo Usuario </h1> </br> .... ..... <%a= link_to ”Agregar un Nuevo Usuario”, {action=>’new’}%> ..... .....

La(s) Vista(s) Como se explicó en la sección anterior, el controlador atiende peticiones de las vistas a través de sus métodos. El nombre de estos métodos coinciden con las acciones a invocarse en las vistas. Ahora bien, de la misma manera que acontece en otras partes del framework, la convención que los diseñadores de Rails han empleado para definir las vistas, es hacer coincidir el nombre de los archivos que contengan a las vistas, con el nombre de los métodos que representarán a las acciones a invocarse dentro de los controladores. Por ejemplo, en nuestro caso UsuarioController tiene los métodos list, new y show, por ende generaremos los archivos list.rhtml, new.rhtml, show.rhtml que serán los que invocaran a estos métodos y se definen dentro del directorio app/views/usuario, sin embargo a diferencia de lo que sucede con el controlador y el modelo, el comando generate no tiene un parámetro específico para generar los archivos .rhtml que contendrán a las vistas, por esta razón es necesario crearlos a mano. El siguiente diagrama trata de ilustrar este mecanismo.

class UsuarioController < ApplicationController def list # CODIGO PARA MOSTRAR TODOS LOS USUARIOS

end def new # CODIGO PARA CREAR UN NUEVO USUARIO

end

new.html <h1> Detalle de un Usuario </h1> </br> .... ..... <%a= link_to ”Mostrar Usuario”, {action=>’show’}%> ..... ..... show.rhtml <h1> Borrar un Usuario </h1> </br> .... ..... <%a= link_to ”Borrar un Usuario”, {action=>’delete’}%> ..... .....

def show # CODIGO PARA MOSTRAR EL DETALLE DE UN USUARIO

end def delete # CODIGO PARA BORRAR UN USUARIO EXISTENTE

end ... end usuario_controller.rb

delete.rhtml

www.sg.com.mx

AGO-OCT 2008

// PRÁCTICAS

/*PROGRAMACIÓN*/

Un comentario al margen es que existe un mecanismo llamado scaffolding que permite la generación automática de todas las vistas y un formato homogéneo de las mismas. Sin embargo en esta ocasión no explicaremos este mecanismo con el fin de que el lector conozca y maneje los elementos básicos para manipular vistas.

Finalmente reinicializaremos nuestro webserver WEBRick (si es que este se encuentra apagado). ruby script/server webrick

Y arrancaremos el web browser de nuestra preferencia apuntándolo a la siguiente dirección:

A continuación se muestra un ejemplo del código de las vistas, en este caso sería de la vista list.rhtml. <html> <head> <h3> Historia 15 - USUARIOS - Nuevo </h3> </head> <body> <h1>Agregar un Nuevo Usuario</h1> <%= start_form_tag :action => ‘create’ %> <p><label for=”usuario_nombre”>Nombre</label><br/> <%= text_field ‘usuario’, ‘nombre’ %></p> <p><label for=”usuario_apellido”>Apellido</label><br/> <%= text_field ‘usuario’, ‘apellido’ %></p> <p><label for=”usuario_tipo”>Tipo</label><br/> <%= text_field ‘usuario’, ‘tipo’ %></p> <p><label for=”usuario_permisos”>Permisos</label><br/> <%= text_field ‘usuario’, ‘permisos’ %></p> <%= submit_tag “Create” %> <%= end_form_tag %>

http://localhost:3000/usuario/list

La 1ra. vez deberá aparecer una página parecida a la siguiente:

Al darle click a la liga “Agregar Nuevo Usuario” se desplegará en pantalla una forma. Introduzcamos un par de usuarios de ejemplo:

Nombre: Liliana Apellido: Allen Tipo: 1 Permisos: rwx rwx rwx

Formatos de los archivos de vistas Al analizar el código RHTML observamos que en estos estan presentes instrucciones HTML y lo que aparenta ser codigo Ruby; en efecto lo es.

Nombre: Sebastian Apellido: Coe Tipo: 2 Permisos: rrr rxx rwx

Recordemos la arquitectura de Rails: La parte de las vistas esta contenida en archivos .rhtml que son interpetados por el programa ERb, el cual a su vez intepreta, ejecuta y substituye las instrucciones de Ruby y convierte su salida en HTML la cual es entregada al webserver que finalmente devuelve al browser para su interpretación.

Y demos click en el boton “Create” al final de la introducción de los datos de cada usuario

<%= link_to ‘Back’, {:action => ‘list’} %> </html>

Observemos también que en la vistas, se puede llamar directamente a los objetos de negocio que representan el modelo, esto, sin necesidad de incluir ninguna librería, mas importante aún es recordar que el controlador el responsable de crear este tipo de objetos. Para nuestro caso: @usuario. Otro punto interesante es el código inmerso dentro de las etiquetas <%= start_form_tag %> … <%= end_form_tag%>, este es una instrucción preconstruida en Ruby que es interpretada por ERb la cual permite el desarrollo de formas complejas en HTML de una forma rápida y sencilla.

Podemos percatarnos que una vez que finalizamos la introducción de cada usuario mediante el botón “Create” la aplicación nos regresa a la página donde se enlistan todos los usuarios. Esto se debe justamente al código que incrustamos dentro del controlador: if @usuario.save redirect_to :action => ‘list’

El cual le indica a Rails que en caso de haber guardado exitosamente al usuario, el control se redireccione a la acción list. Probemos ahora la liga “Back”; la página desplegada deberá ser similar a la siguiente:

Carlos Ortega es consultor en metodologías y prácticas ágiles (XP, TDD, Refactoring, Pair Programming), cuenta con certificaciones en RUP, OOAD, UML, etcétera. Es Certified ATAM Evaluator y Certified Professional Software Architect ambos avalados por el SEI. Ha colaborado en numerosos proyectos para diversas organizaciones como Banco de México, Elektra, Banco Azteca, Fandelli, Oracle, IMSS, Heinson, Accenture, EDS. Actualmente colabora con Software Ágil, empresa dedicada al tutelaje e implementación de metodologías ágiles (SCRUM, XP, Crystal).

AGO-OCT 2008

www.sg.com.mx

“Las construcciones de Rails han diseñado el framework de tal manera que los métodos que se definan dentro de esta clase coincidan con las acciones que se generan en las vistas”.

Pudimos comprobar diferentes capacidades que los hacen ser uno de los lenguajes y frameworks más poderosos para desarrollar aplicaciones web de forma extremadamente rápida. Adicionalmente el hecho de ser abiertos, libres y correr en múltiples plataformas los distingue como una de las tecnologías más atrayente de la actualidad. Por último, demos click a alguna de las ligas que presenta el nombre de los usuarios, la página web desplegará el detalle de los datos que introducimos anteriormente:

La versión básica de nuestra aplicación ¡ya corre! Un punto adicional que vale la pena comentar es que a pesar de que el código RHTML hace sencilla la construcción de vistas, es muy posible que en futuras versiones de Rails este deje de utilizarse debido a que en últimas fechas se han creado nuevos mecanismos que simplifican la manipulación de vistas de manera dramática.

Conclusión A través de estos 4 artículos tuvimos la oportunidad de revisar el lenguaje Ruby y el framework Rails.

www.sg.com.mx

Esta última entrega finalizó nuestra revisión básica incluyendo el desarrollo de los controladores y las vistas. Existen temas más avanzados que complementan los mecanismos necesarios para generar una aplicación Rails a nivel empresarial. Temas como el manejo de relaciones entre diferentes objetos de negocio, routers, Ajax, andamios, seguridad y distribución, quedan para una revisión posterior. Sin embargo los elementos hasta aquí presentados permitirán al lector tener las bases mínimas para comenzar a desarrollar y adentrarse en esta novedosa tecnología.

Referencias [ Thomas David, Fowler Chad, Hunt Andy. “Programming Ruby”. 2nd Edition. The Pragmatic Bookshelf. 2005 ] [ Thomas David, Heinemeier Hanson David, et al. “Agile Web Development with Rails”. 2nd Edition. The Pragmatic Bookshelf. 2006 ] [ Black, David A. “Ruby for Rails”. Manning Publications Co. 2006 ] [ ruby-lang.org/en ] [ rubyonrails.org ] [ mysql.com] [ haml.hamptoncatlin.com ] AGO-OCT 2008

// PRÁCTICAS

/*ARQUITECTURA*/

Más Allá del Manual de Usuario Parte 2. Documentando la Arquitectura de Software Por Omar Gómez

En el número anterior vimos la propuesta de SEI que define tres categorías denomidas tipos de vista. Para concluir con esta propuesta en la figura 1 se muestran los principales conceptos de este enfoque. 5JQP EF WJTUB

1FSTPOB *OWPMVDSBEB FO FM 1SPZFDUP

1..x

satisface los intereses

4JTUFNB 4PGUXBSF

tiene 1..

7JTUB

&TUJMP "SRVJUFDUwOJDP

"SRVJUFDUVSB

cumple 1..x

es descrita 1

• Identificación e información general. En esta práctica se lleva lo relacionado al control de versiones del documento, fecha, histórico de revisiones, estado, contexto del sistema, declaración del alcance, entre otros más. • Identificación del personal involucrado y sus intereses. Se describen los diversos tipos de personas involucradas en el proyecto. Tales como, administradores, diseñadores, desarrolladores, usuarios, patrocinadores. A su vez, se incluye la diversidad de intereses que la arquitectura debe satisfacer.

se obtiene

(VrB EF &TUJMPT

Si se desea que la documentación de la arquitectura cumpla con el estándar, se deben seguir las siguientes prácticas:

1..x

1BRVFUF EF 7JTUB 1..x

1..x

%PDVNFOUP EF MB "SRVJUFDUVSB

4FDDJwO

Figura 1. Relación de conceptos de la propuesta “vistas y más allá de éstas” del SEI.

Por su parte, el IEEE Software propone el estándar IEEE 1471 que define un conjunto de recomendaciones centradas básicamente en 2 ideas, un marco conceptual para describir arquitecturas, y un conjunto de prácticas a seguir. La descripción de la arquitectura se organiza en un conjunto de vistas, cada vista modela una parte del sistema y satisface uno o más intereses de las personas involucradas. Los distintos intereses se deben considerar durante la construcción del sistema; si alguno de ellos no es considerado en al menos una de las vistas se dice que la descripción de la arquitectura está incompleta. Cada vista se documenta de acuerdo a un punto de vista (elemento que pude ser reutilizado) determinado, definiendo las notaciones, técnicas y reglas para construir e interpretarla, a su vez, este determina cómo el contenido de una vista satisface uno o más intereses de las personas involucradas. En este marco conceptual, una vista es la instancia de un punto de vista dado. Un conjunto (biblioteca) de puntos de vista es análogo a la guía de estilos que propone el SEI. En la figura 2 se muestra un extracto del marco conceptual del estándar IEEE 1471.

• Puntos de vista. Cada de uno de estos debe contener un nombre, personal involucrado, intereses que satisface, lenguaje o técnicas de modelado utilizados durante la construcción de la vista, algún método analítico para analizar de manera cualitativa o cuantitativa los atributos de calidad que satisface el punto de vista, y su justificación. • Vistas. Cada vista debe tener un identificador, una breve introducción y la representación del sistema con respecto a un punto de vista en particular. • Consistencia entre vistas. Registra las inconsistencias entre las vistas, así como algún tipo de procedimiento que indique la consistencia entre ellas. • Justificación. Se debe incluir la justificación del tipo de arquitectura seleccionada, y de los puntos de vista utilizados. Actualmente, el IEEE e ISO están revisando en conjunto este estándar con el objetivo de tener una versión actualizada en el siguiente año para someterla a votación. Estos dos últimos enfoques tienen varias similitudes entre sí. Por ejemplo, ambos se centran en las personas involucradas y en sus diversos intereses, ninguno de estos prescribe un número fijo de vistas, los dos enfoques hacen uso de la reutilización de artefactos; uno através de la guía de estilos y el otro por medio de una biblioteca de puntos de vista, en ambos la arquitectura debe estar justificada y los dos enfoques recomiendan el uso de análisis cualitativos o cuantitativos.

Omar Salvador Gómez Gómez obtuvo el grado de Maestro en Ingeniería de Software, en el Centro de Investigación en Matemáticas (CIMAT). Actualmente se encuentra trabajando como estudiante de postgrado en el área de Ingeniería del Software Empírica en la Facultad de Informática de la Universidad Politécnica de Madrid. Es miembro del IEEE Computer Society. Puedes contactarlo en ogomez@ieee.org

AGO-OCT 2008

www.sg.com.mx

"SRVJUFDUVSB

4JTUFNB EF 4PGUXBSF

tiene 1 tiene

descrita por

1..x

1FSTPOB JOWPMVDSBEB FO FM QSPZFDUP 1..x es importante para

%FTDSJQDJwO EF MB "SRVJUFDUVSB identifica 1..x

es considerado 1..x

1..x selecciona

1VOUP EF WJTUB

5FNB EF *OUFSnT

está organizada por 1..x

7JTUB conforma

usado para satisfacer 1..x

puede tener 0..1

#JCMJPUFDB EF 1VOUPT EF 7JTUB

Figura 2. Extracto del marco conceptual del estándar IEEE 1471.

Una de las diferencias entre los dos enfoques es la siguiente. En el enfoque del SEI primero se selecciona un conjunto posible de vistas con respecto a las estructuras que están presentes en el sistema a construir, después se validan de acuerdo a un consenso de intereses por parte del personal involucrado, posteriormente se documentan. Por otra parte, el IEEE primero determina los intereses del personal involucrado, después en base a estos se selecciona un conjunto de puntos de vista que los satisfaga, por último se documenta cada una de las vistas basándose en los puntos de vista seleccionados.

Conclusión Uno de los principales beneficios de realizar esta práctica, es el poder efectuar evaluaciones sobre la arquitectura documentada, con el fin de determinar si se están cumpliendo o no los intereses del personal involucrado. Para finalizar, algunos de los puntos que se deben considerar al momento de documentar un arquitectura son: • Documentar la arquitectura tomando en cuenta las necesidades e intereses de cada persona que forma parte del proyecto. • Acompañar la documentación de las vistas con un modelo analítico que ayude a predecir el comportamiento de los atributos de calidad. • UML no es el único lenguaje para documentar la arquitectura. Existen diferentes notaciones y lenguajes para este propósito, por ejemplo, lenguajes para descripción de arquitecturas (ADLs) que describen aspectos particulares de esta. • Mantener una relación consistente entre las vistas. • Elaborar plantillas de estilos para promover la reutilización de artefactos dentro de la organización. www.sg.com.mx

• Mantener actualizada la matriz de trazabilidad entre los requisitos y los elementos de la arquitectura. • Tener bajo una línea base el documento de la arquitectura.

Referencias [ Philippe Kruchten. “The 4+1 View Model of Architecture”. IEEE Software., Los Alamitos, CA, USA, Volume 12, Number 6, págs. 42-50. IEEE Computer Society Press, 1995 ] [ Dilip Soni; Robert L. Nord & Christine Hofmeister. “Software architecture in industrial applications”. ICSE ‘95: Proceedings of the 17th international conference on Software Engineering, New York, NY, USA. págs. 196-207, ACM, 1995 ] [ Paul Clements; Felix Bachmann; Len Bass; David Garlan; James Ivers; Reed Little; Robert Nord & Judith Stafford. “Documenting Software Architectures: Views and Beyond”. Addison Wesley Professional. 2002 ] [ IEEE Architecture Working Group. “IEEE Standard 1471-2000, Recommended practice for Architectural Description of SoftwareIntensive Systems”. págs 1-23. IEEE, 2000 ] [ Mary Shaw & David Garlan. “Software Architecture: Perspectives on an Emerging Discipline”. Abril. Prentice Hall. 1996 ] [ Mark Klein; Rick Kazman & Robert Nord. “Attribute-Based Architectural Styles”.Software Engineering Institute. Technical Report CMU/SEI-99-TR-22. Carnegie Mellon University. 1999 ] [ Software Engineering Institute, SEI. “Views and Beyond Architecture Documentation Template” ] [ sei.cmu.edu/architecture/arch_doc.html ] [ Rich Hilliard. “ISO/IEC 42010/IEEE 1471: Architectural Description” ] [ sei.cmu.edu/architecture/IEEE_1471.html ] [ Omar Gómez. “Evaluando la Arquitectura de Software, métodos de evaluación”. Revista Software Gurú. Año 03 No. 02. 2007 ] AGO-OCT 2008

// PRÁCTICAS

/*SEGURIDAD*/

Aplicaciones Web Seguras. ¿Mito o Realidad? El mito de la seguridad en aplicaciones Web Por Germán Domínguez

La seguridad en las aplicaciones Web de las organizaciones es, hoy en día, una prioridad importante. Y es que éstas aplicaciones contienen y manejan información invaluable para la operación y el comercio de las empresas, por lo mismo, la seguridad se vuelve imprescindible, ya que muchas de estas aplicaciones manejan números de tarjetas de crédito, listas de clientes de las empresas, inventarios físicos, documentos de propiedad intelectual, etcétera; bienes por los que un hacker estaría dispuesto a hacer lo posible para obtenerlos. La mayor parte de los presupuestos de seguridad en las compañías están dedicados a la infraestructura de la red y de acuerdo con estudios realizados, más del 60% de los ataques en seguridad de la información no están dirigidos ahí, sino a la capa de aplicaciones Web; otro estudio demuestra que más del 70% de estas aplicaciones, son vulnerables a ataques informáticos y para el 2010 el 80% de las organizaciones experimentará un incidente de seguridad. A pesar de esto y de las inversiones en materia de seguridad, seguimos leyendo noticias que sitios de empresas, medios de comunicación, entidades gubernamentales, organizaciones políticas y civiles, entre otras, son presas de ataques a la seguridad de sus sitios web. Las organizaciones invierten recursos, principalmente, en la seguridad informática, en seguridad perimetral con la instalación de Firewalls, en Sistemas de Detección de Intrusos (IDP), Sistemas de Prevención de Intrusiones (IPS) y Firewalls de Aplicaciones, todo apoyado en Sistemas de Administración de Eventos e Incidentes (SIEM). Todos estos controles de seguridad bloquean ataques muy bien identificados, sin embargo,

todos ellos descuidan la seguridad en las aplicaciones y la información que en ella se contienen, de tal manera que la seguridad se deja única y exclusivamente a la programación realizada. Sin embargo aquellas fallas de seguridad no contempladas o conocidas, quedan vulnerables a usuarios malintencionados, empleados enojados o en el peor de los casos, a un hacker. Los ataques a las aplicaciones no siempre son malintencionados, un usuario por error puede lograr tener acceso a información a segmentos del aplicativo que no estaban destinados para su perfil de usuario. Adicional a esto, ha habido un incremento de sitios que proporcionan herramientas para la exploración y explotación de vulnerabilidades en sitios Web, lo que ha permitido el crecimiento de la población de usuarios malintencionados. Una de las mejores prácticas para mantener seguras las aplicaciones es “nunca asumir que la información ingresada por el usuario será confiable”, esto evita que la aplicación acepte información o datos que no están permitidos y que podrían convertirse en datos potencialmente peligrosos para la seguridad de la misma.

La realidad de la seguridad Tipos de vulnerabilidades Según la organización Web Application Security Consortium (WASC), las aplicaciones son vulnerables a diferentes tipos y categorías de ataques y los clasifica en 6 grandes rubros: • Autenticación, el objetivo de estos ataques es la validación de la identidad de los usuarios con la intención de engañar al proceso de autenticación del sitio web. • Autorización, este tipo de ataques buscan obtener acceso a recursos o información a los que el usuario no tiene derecho o permiso de utilización.

• Ataques en la parte cliente, resultan de la relación de confianza que existe por parte del usuario final en el sitio Web, en esta relación el usuario confía que la información proporcionada por el sitio Web será verdadera y espera no recibir ningún tipo de ataque por parte de la aplicación. • Ejecución de comandos, en esta categoría caen las vulnerabilidades que permiten al usuario ejecutar comandos remotos en el sitio. • Revelación de información como objetivo obtener información específica del sitio, tales como el sistema operativo del servidor, la marca y versión del servidor de aplicaciones web, etcétera. Y con esta información poder utilizar o explotar vulnerabilidades conocidas de dichos productos. • Ataques lógicos, son aquellos que burlan la lógica programada de las aplicaciones y perjudican la aplicación, los usuarios o la información contenida. Estas grandes categorías nos permiten tener una idea del universo de posibilidades para un ataque a un sitio Web. En este artículo nos enfocaremos en los que se ubican como los primeros lugares, según la clasificación hecha por el Open Web Application Security Project (OWASP), una de las organizaciones independientes más importantes en Seguridad de la Información: 1. Cross Site Scripting se refiere a aquellos ataques que permiten al hacker obtener información confidencial del usuario (como cuentas y contraseñas), llevar a cabo ataques de phishing y hasta llegar a tomar el control del navegador del usuario final. Está es la vulnerabilidad más común y agresiva de las aplicaciones web; en las clasificaciones antes mencionadas pertenece a ataques en la parte del cliente y autenticación. Esta vulnerabilidad es exitosa mediante la inserción de código HMTL o JavaScript en el navegador del usuario, usualmente estos

Germán Domínguez es Licenciado en Informática Administrativa de UNITEC con más de 13 años de experiencia en el desarrollo de aplicaciones de negocio y aplicaciones Web. Ahora pertenece al equipo de IT de IBM de México, especialista para la marca de software Rational, y puede ser contactado en germand@mx1.ibm.com

AGO-OCT 2008

www.sg.com.mx

ataques son encontrados en comunidades virtuales, foros de discusión, salas de chat y hasta en el mismo sitio web que se pretende afectar. Todas las plataformas son susceptibles a estos ataques. Lamentablemente, estas agresiones son dirigidas directamente al usuario final, por lo que la inserción de código en el navegador no puede ser controlada por nuestros sistemas de seguridad. 2. Inyección defectuosa, este tipo de vulnerabilidades tienen lugar cuando un usuario malicioso ejecuta comandos no previstos en la aplicación Web mediante el envío de datos especialmente diseñados para tal fin utilizando como interprete de estos comandos al sitio, estas instrucciones permiten al atacante leer, crear o borrar información. Algunos tipos de instrucciones que se inyectan en las aplicaciones son tipo SQL, LDAP, XML o comandos de sistema operativo. En casos extremos, este tipo de ataques permiten al intruso tomar el control total del sistema, incluidas aplicaciones, datos, sistema operativo y hasta intrusión en los demás equipos en la red de la organización. Todas las plataformas son susceptibles a cualquiera de estos tipos de ataque, ya sea C#, .Net, PHP, C, Perl, Ruby on Rails y hasta aplicaciones Java y lo peor de todo es que no importa que tan segura sea la configuración de red, si la aplicación no es segura, la información que contiene está en riesgo.

Tomar cartas en el asunto Las aplicaciones deben ser protegidas contra cualquier problema de seguridad, es decir, los ataques a las mismas se deben de detectar y evitar desde su concepción, para ir delante de los hackers existen dos caminos: el fortalecimiento de los estándares de programación y las pruebas sobre aplicaciones. Robustecer los estándares de seguridad programados en las aplicaciones permite evitar la recodificación, reduce los costos de mantenimiento y las situaciones críticas cuando algún evento de seguridad se presenta. En algunos casos la utilización de frameworks, permiten reducir la posibilidad de un ataque Cross-Scripting y para evitar situaciones de inyección de código SQL, es posible mediante la utilización de sentencias preparadas www.sg.com.mx

en aplicaciones que ayudan a mitigar este riesgo. Este tipo de acciones reduce la posibilidad de algún ataque a la aplicación, pero siempre una buena práctica de seguridad es la realización de pruebas para verificar y comprobar nuestras mejoras en el diseño y programación. En la etapa de pruebas, de igual manera existen dos maneras de ser realizadas, manualmente o mediante una herramienta que automatice estas pruebas. La primera significa dedicar tiempo en la creación de los casos de prueba, instrucción y documentación del equipo de pruebas para conocer las vulnerabilidades existentes. Actualmente, con la mayor adopción de aplicaciones Web 2.0, las variables en la ecuación de seguridad de aplicaciones crece aún más. La automatización de las pruebas reduce tiempos de realización de las pruebas y simplifica los casos, adicionalmente es importante contar con una herramienta que emule el comportamiento malicioso del hacker y contenga una base de datos actualizada con las fallas comunes que se conocen en el mundo de la Seguridad de la Información. La herramienta en el mercado que facilita estas actividades es Rational AppScan que, adicionalmente a las características antes mencionadas, contiene una base de conocimientos que permite sugerir correcciones y mejores prácticas a los errores y omisiones que se hayan encontrado al momento de la ejecución del proceso de revisión del sitio.

La prioridad es la seguridad La seguridad y garantía de la información que reside en las aplicaciones Web no es un tema que se deje a la ligera, requiere de toda la atención ya que existe todo un ejército de personas que están dispuestas a tomarse el tiempo de encontrar en las fallas al sitio que escojan y de esa forma poner en riesgo a las empresas, independientemente de su tamaño. Tomar las medidas precautorias es garantía de que ni las organizaciones ni los usuarios sufrirán de algún tipo de pérdida económica, robo de identidad o desprestigio frente a clientes e inversionistas.

Referencias [ webappsec.org/projects/threat/ ] [ owasp.org/index.php/Top_10_2007 ] AGO-OCT 2008

// UML

RECONOCIENDO LOS DIAGRAMAS Buen Comportamiento con Diagramas de Secuencia Por Miguel Ángel Armas Alemán

Una de las principales preguntas al analizar y diseñar software con UML es ¿cómo se hace o reconoce un buen diagrama? Conocer la notación es apenas el inicio del camino, la mejor analogía la encontramos en la literatura, saber leer y escribir no garantiza que podamos escribir obras como Shakespeare o Quevedo, de la misma forma el conocer UML no garantiza que tengamos la capacidad de hacer un buen análisis o diseño. En otros artículos se han mostrado las reglas básicas para elaborar un diagrama de secuencia, en esta ocasión nos ocuparemos de los principios mínimos para hacer el diseño de un caso de uso en un diagrama de secuencia de UML.

Intención del diagrama de secuencia El diagrama de secuencia nos permite diseñar el comportamiento del software. Sirve, entre otras cosas, para diseñar casos de uso, generalmente se hace al menos uno por cada caso de uso, se diseña tomando en cuenta los resultados del análisis, por lo que los artefactos que se necesitan para elaborarlo son los mostrados en la figura 1. &TQFDJGJDBDJwO B EFUBMMF EFM $6

1SPUPUJQP EF JOUFSGB[ HSgGJDB

%JTFvBS VO $6

%JBHSBNB EF TFDVFODJBT

%JBHSBNB EF DMBTFT .PEFMP DPODFQUVBM

Figura 1. Entradas y salidas del diseño de un caso de uso.

El diagrama de secuencia es un diagrama de comportamiento y modela lo que sucede internamente en el software cuando, por ejemplo, los usuarios aprietan botones y teclas, ahí debemos definir con qué objetos de frontera (GUI, servicios web, etcétera) in-

AGO-OCT 2008

teractúa el actor y qué objetos de negocio se ven involucrados para atender los eventos generados, todo esto apegado al guión especificado en el texto del análisis.

sentido modelar una y otra vez en cada caso de uso cuáles son los objetos involucrados en las tareas repetitivas como esta, pueden omitirse por un sentido práctico.

Este tipo de diagrama puede verse como una traducción del texto del análisis en términos de objetos y métodos con todas las consideraciones técnicas de la arquitectura. Hacer un buen diseño no es cuestión de complejidad, es decir, el mejor diagrama de secuencia no es el que tenga más objetos y mensajes, pero hay tres principios básicos que debe cumplir un buen diagrama de secuencia:

Una parte importante de la identificación de los objetos consiste en nombrarlos y asignarlos a la clase a la que pertenecen, esto evita que los programadores dupliquen objetos y clases que ya existen.

1. Identificar a los objetos involucrados 2. Definir la responsabilidad de cada objeto 3. Mostrar el ciclo de vida de cada objeto El diagrama de secuencia modela el comportamiento de un caso de uso desde la perspectiva del diseño, por lo que el comportamiento de una aplicación de escritorio para 25 usuarios es distinto al de una aplicación web para 700 usuarios, esta particular interacción entre los objetos de la aplicación debe quedar plasmada en el diagrama aplicando los principios mencionados.

Identificar a los objetos involucrados La primera parte de traducir el texto del análisis a objetos y métodos consiste en identificar qué objetos están involucrados, el texto del análisis menciona normalmente sólo a los objetos de negocio; mismos que posiblemente tengamos ya incluidos en el modelo conceptual. Es responsabilidad del diseñador identificar e incluir el resto de los objetos que participan en el caso de uso y que no son de negocio, como ventanas, formas, servicios web, persistencia, seguridad, etcétera. Tampoco se trata de modelar todos y cada uno de los objetos, solo los más importantes para la ejecución del caso de uso, no tiene

La identificación de los objetos involucrados usualmente se hace en paralelo con la asignación de responsabilidades de cada objeto, el cual es el siguiente punto.

Definir la responsabilidad de cada objeto Este es el aspecto más importante de un diagrama de secuencia, la mejor forma de asignarle responsabilidad a un objeto es usando los Patrones de Diseño y los Patrones Generales de Asignación de Responsabilidades (GRASP por sus siglas en inglés). Pero, otro aspecto importante que no abarcan los sistemas de patrones anteriores, es lo que tiene que ver con el negocio del sistema que se diseña. En el caso de uso Prestar Libro, ¿qué objetos de negocio están involucrados?, ¿cuántas ventanas se necesitan?, ¿cuáles son los objetos de persistencia necesarios?, ¿qué objeto lleva el control del CU? Estas preguntas se deben resolver al diseñar cada caso de uso. Una de las técnicas más utilizadas para definir las responsabilidades de los objetos es clasificar cada objeto de acuerdo al patrón Modelo-Vista-Control (MVC) como frontera, control o entidad. Los objetos de frontera son los que interactúan con el actor, mostrando información o recibiendo peticiones. Estos objetos representan ventanas, páginas web y servicios web entre otros. www.sg.com.mx

Los objetos de control son los que reciben mensajes de los objetos frontera y deciden quĂŠ curso de acciones tomar, enviando mensaje a todos los objetos involucrados en atender la peticiĂłn del usuario. En una de las variantes del patrĂłn MVC se modela un objeto de control para cada caso de uso, el cual tiene los pasos necesarios para ejecutarlo. Los objetos entidad son los que ya se han identificado como clases en el modelo conceptual, aunque se podrĂan identificar nuevos conceptos de negocio en el diseĂąo. TambiĂŠn se pueden modelar los objetos de una capa de persistencia como objetos entidad.

'SPOUFSB

$POUSPM

#JCMJPUFDBSJP

GSN3FH1SFTUBNP

DUSM$63FHJTUSBS1SFTUBNP

DSFEFODJBM

MFDUPS

WBMJEBS-FDUPS OVN$SFE

OVN$SFE7BMJEP WBMJEBS OVN$SFE CPPM DSFE7JHFOUF WJHFOUF CPPM MFDUPS&MFHJCMF1SFTUBNP FMFHJCMF1SFTUBNP OVN$SFE CPPM HFU%BUPT

NPTUSBS MFDUPS

Figura 3. Responsabilidad de los objetos.

Datos. En un diagrama de secuencia debe modelarse con mensajes de creaciĂłn (- - - >) en quĂŠ momento se necesita crear un objeto, al encontrar una X en la lĂnea de vida de un objeto, sabemos que es elegible para recolecciĂłn de basura.

lar y no cuando estamos programando, por ejemplo, si Ăşnicamente diseĂąamos con un diagrama de clases, corremos el riesgo de que cuando estemos programando el caso de uso Pagar Multa y nos demos cuenta de que el objeto credencial se comporta similar en el caso de uso Prestar Libro, tengamos que hacer refactoring sobre el cĂłdigo de ambos casos de uso, y definitivamente es mĂĄs rĂĄpido y barato modificar diagramas que cĂłdigo. Otra ventaja estĂĄ en la posibilidad de desarrollar una arquitectura consistente para todo el sistema. Si sĂłlo diseĂąamos utilizando diagramas de clases, cada programador puede codificar sus casos de uso con un estilo muy particular y distinto al de los demĂĄs, que dependerĂĄ mĂĄs de la calidad de la especificaciĂłn del caso de uso y la habilidad de cada programador.

&OUJEBE

Figura 2. Estereotipos de los objetos en el patrĂłn MVC.

En los objetos de negocio es donde el diseĂąador debe aplicar su pericia para definir la responsabilidad de cada objeto, por ejemplo, si hay que validar que una credencial estĂŠ vigente, no es responsabilidad del objeto ventana, si no de un objeto credencial, verificar que el lector no tenga mĂĄs de tres prĂŠstamos vigentes y ninguna multa sin pagar, lo debe hacer el objeto lector y no la ventana de prĂŠstamos. Estas responsabilidades las podemos ver en la figura 3.

Los objetos que no reciben un mensaje de creaciĂłn se asume que ya existen antes de comenzar el caso de uso y el sĂmbolo del objeto estĂĄ hasta arriba en el diagrama de secuencias, como puede observarse en la figura 4.

#JCMJPUFDBSJP

GSN3FH1SFTUBNP

DUSM$63FHJTUSBS1SFTUBNP

Pero, como le solemos explicar a nuestros alumnos en nuestros cursos, la proporciĂłn de casos de uso a los cuales conviene diseĂąarles sus diagramas de secuencia depende de la situaciĂłn del proyecto y sus tiempos. Debido a que en la mayorĂa de los casos no contamos con tantos recursos ni tiempo como para poder desarrollarlos todos.

WBMJEBS-FDUPS OVN$SFE

ConclusiĂłn

OFX $SFEFODJBM DSFEFODJBM OVN$SFE7BMJEP WBMJEBS OVN$SFE CPPM DSFE7JHFOUF WJHFOUF CPPM

Para definir las responsabilidades en un diagrama de secuencia se deben identificar que objetos de frontera intercambian mensajes con el actor y que objetos de control solicitan a los objetos de entidad ejecutar las operaciones de negocio necesarias para realizar el caso de uso.

Figura 4. SĂmbolo del objeto.

Mostrar el ciclo de vida de cada objeto

Ventajas de diseĂąar con un diagrama de secuencia

Saber quĂŠ objetos ya existen y cuĂĄles son los que deben crearse durante la ejecuciĂłn de un caso de uso es importante para evitar que en cada caso de uso se reserve memoria a diestra y siniestra y se dupliquen objetos haciendo viajes innecesarios a la Base de

Elaborar un diagrama de secuencia para cada caso de uso representa un esfuerzo importante dentro del proyecto, pero nos permite detectar comportamiento comĂşn en varios casos de uso, identificando tempranamente a los objetos y clases reutilizables al mode-

OFX -FDUPS

MFDUPS MFDUPS&MFHJCMF1SFTUBNP FMFHJCMF1SFTUBNP OVN$SFE CPPM HFU%BUPT

NPTUSBS MFDUPS

Un buen diagrama de secuencia debe dejar claro cuĂĄles son los objetos involucrados, cĂłmo colaboran dichos objetos para realizar el caso de uso, y quĂŠ objetos se crean durante el caso de uso y cuĂĄles existĂan previamente. No es necesario indicar el algoritmo para validar el nĂşmero de una credencial o la sintaxis de una direcciĂłn de email, eso le corresponde al programador, pero si es imprescindible indicar quĂŠ objeto es el responsable de validar y ademĂĄs a quĂŠ clase pertenece. No olvides que, siempre que te sea posible, es sano apoyarte en gente con mayor experiencia en las buenas prĂĄcticas. Al final tu usuario te lo agradecerĂĄ al beneficiarse con la calidad de tus sistemas.

Mike Armas es consultor e instructor senior certificado por la OMG en Milestone Consulting.

www.sg.com.mx

AGO-OCT 2008

// PM CORNER

MEJORES ESTIMACIONES PARA EL DESARROLLO DE SOFTWARE El Poker de la Planeación Por Marco Dorantes

En la actualidad la teoría y la práctica del diseño de software es todavía una mezcla sui géneris entre arte-artesanía y cienciaingeniería donde la precisión matemática es tan relevante como el atractivo emocional. El lado técnico del diseño de software se asimila mejor familiarizándose con el proceso creativo de obras que provienen exclusivamente de la lógica y cuyas propiedades por ende no están definidas en el campo de la física (con excepción quizá de la medida del desorden observado en las dependencias en, desde y hacia dicho software). El diseñador de software desarrolla y ejerce su talento desde su fuero interno en donde encuentra la materia prima del software mismo sujeto de diseño: la lógica, como los principios de la inferencia lícita y los criterios de la demostración válida que investigan y clasifican la estructura de las declaraciones y de los argumentos. Las propiedades de la materia prima de un producto cualquiera moldean las posibilidades de lo que puede llegar a convertirse y la manera en que alcanza su función. Por lo tanto, el conocimiento detallado de las propiedades de la materia prima y de los bloques prefabricados es esencial para un buen diseño; donde los bloques prefabricados aquí son el software previamente escrito y disponible para ser reutilizado. Siendo la lógica —la lógica simbólica en particular— parte de la materia prima en diseño de software entonces para un empleo adecuado de la misma es ineludible el dominio del lenguaje, sea este natural como el español o el inglés o sea artificial como Microsoft Visual C#, para lograr consistencia, validez y completitud en el software diseñado. No es sorpresa entonces que la actividad de dise-

ño de software ofrezca mejores resultados cuando se realiza en un ambiente cooperativo donde los diseñadores emplean todo tipo de lenguaje y sus formas de expresión hablada o escrita para crear software de calidad. La importancia de la comunicación efectiva es imponente en diseño de software tan sólo seguida de la importancia de inventiva. Sin embargo, es paradójico descubrir que existe una imposibilidad intrínseca en la comunicación humana que nos libera de intentar una comunicación perfecta. Así, el desarrollo de software se convierte en un juego cooperativo de comunicación e invención con el cual cada proyecto no intentará lograr comunicación perfecta sino administrar la falta de completez en nuestra comunicación.

Calculando un proyecto de desarrollo de software La responsabilidad del cálculo de las variables económicas típicas de un esfuerzo serio para llevar a cabo X está en función del conocimiento y experiencia de quienes hacen dicho cálculo. Ese conocimiento incluye no solamente las expectativas sobre X sino también sus propiedades intrínsecas, es decir su naturaleza. Tom DeMarco y Timothy Lister nos explican cómo la actividad del desarrollo de software es inherentemente diferente a la actividad de producción o manufactura. Ellos mencionan algunos efectos fatales que causa la mentalidad de producción o manufactura cuando se aplica al desarrollo de software y, sin embargo, cuán frecuente es el caso de grupos gerenciales que permiten moldear su pensamiento por una filosofía de administración enteramente derivada de los ambientes de producción o manufactura. Por brevedad, aquí presentaré —desde

la perspectiva del cálculo de proyectos de desarrollo— sólo dos de las conclusiones de DeMarco y Lister: El planteamiento en producción o manufactura tiende a evitar que los individuos se pongan a pensar en el trabajo, a su vez, se inclina por empujar el esfuerzo hacia un enfoque ciento por ciento dedicado a la ejecución y a la conclusión de tareas bajo la excusa de que hay poco tiempo, como si hubiese alguna vez trabajo por hacer sin la presión del tiempo. Un planteamiento que considera la naturaleza del desarrollo de software incluye tiempo suficiente para pensar en, por ejemplo, ¿debiéramos siquiera realizar esta tarea? y pensarlo en repetidas ocasiones. Un proyecto o un ambiente donde la reflexión —acerca del contexto y rumbo del esfuerzo— es alentada tienen mayor oportunidad de ofrecer predicciones más confiables. Después de todo ¿qué es un estimado?. Desde un punto de vista formal un estimado es una predicción basada en una valoración probabilística siempre sujeta a ser ajustada. El proyecto de alta prioridad que debe ofrecer los mejores beneficios económicos a todas las partes es precisamente el proyecto que no puede darse el lujo de privarse de dicho ambiente donde los individuos son estimulados a realizar reflexiones frecuentes. El trabajo intelectual es diferente al trabajo mecánico y los errores provisionales —no permanentes— son una parte natural y sana de este tipo de trabajo. Los errores de esta clase proveen más oportunidades para el aprendizaje y mantener un ambiente donde no se permiten dichos errores sólo provoca que la gente adopte una actitud defensiva y de no intentar nada nuevo que tenga una ligera probabilidad de resultar mal. Dicho

Marco Dorantes es consultor en el diseño y formulación de software desde 1987. Ha realizado diversas contribuciones públicas en la comunidad mundial de programación, tanto en foros técnicos como en software disponibles en www.xprogramming.com Publica un diario electrónico en blogs.msdn.com/marcod

AGO-OCT 2008

www.sg.com.mx

ambiente se provoca cuando se pretende automatizar el proceso intelectual tal como se automatiza un proceso mecánico —al estar este completamente entendido— o cuando se imponen metodologías rígidas que impiden a los individuos tomar cualquiera de las decisiones estratégicas por miedo a que se equivoquen. Por otro lado, un planteamiento más cercano a la realidad del desarrollo de software estimularía a los individuos a cometer este tipo de errores y ser felicitados cuando los cometan pues es, en parte, por lo que reciben su sueldo. Desde esta perspectiva introduzco a continuación una estrategia que puede ser llamada estimación iterativa.

Estimación iterativa La idea básica es que cualquiera que publique un estimado es susceptible de mejorar dicha habilidad y así publicar estimados cada vez más útiles. Dicho con otras palabras, se sabe que algunos estimados son intrínsecamente propensos a estar del todo equivocados y tienen que ser rechazados, no ajustados, pues la actividad de estimación incluye tales callejones sin salida y el esfuerzo perdido puede mantenerse pequeño y ser considerado un error provisional. La estimación iterativa puede ser percibida por algunos como una complicación política pues les parece difícil justificar el re-trabajo y prefieren creer que les irá mejor usando el estimado equivocado aún cuando podría costar mucho más al final de cuentas. La estimación iterativa es una técnica heurística, es decir, una técnica de indagación y descubrimiento; una manera de buscar la solución a un problema mediante métodos no rigurosos, por tanteo ó reglas empíricas. La estimación iterativa considera al menos cinco causas por las que las estimaciones son deficientes: 1. Escasez de destreza para estimar 2. Predisposición o imparcialidad no considerada en la estimación 3. Poco entendimiento del significado de un estimado 4. Uso inadecuado de políticas que obstaculizan una buena estimación 5. Escasez de métricas de estimación para referencia No debiera suceder una sola vez al inicio de un proyecto pues su mayor valor se obtiene al repetirla por cada agrupación de alcance funcional detallado en que haya sido dividiwww.sg.com.mx

do el proyecto. Una técnica para ejecutar la estimación iterativa se llama poker de planeación. La granularidad del alcance funcional determina dos niveles de planeación: de grano grueso, y de grano fino. El nivel de planeación de grano grueso abarca funciones generales de alto nivel y representa ciclos usualmente en la escala de meses. El nivel de grano fino abarca funciones detalladas que son implementables en ciclos típicamente en la escala de semanas. Los ciclos de desarrollo de grano fino inician con la ejecución del poker de planeación y terminan con una versión interina de la solución en desarrollo que incluye la implementación de las funciones estimadas en el poker de planeación inicial. Los ciclos de desarrollo de grano grueso simplemente son agrupadores de ciclos de grano fino y terminan con la liberación de una versión pública de la solución en desarrollo.

¿Cómo mejorar tus estimaciones? La variedad de técnicas existentes para desarrollar una estimación pueden ser de ayuda siempre y cuando se decida analizar su utilidad en el debido contexto, depende de usted estimado lector. A continuación resumo brevemente la técnica de poker de planeación para su consideración cuando le pregunten ¿cuándo... ó cuánto...?, y que también le pueden servir para valorar la calidad de la respuesta cuando sea usted quien hace la pregunta. La técnica puede tener aplicación general, pero en realidad están orientados para proyectos de desarrollo de soluciones de software, además se asume que los puntos esenciales para mejorar el ¿qué desarrollar? ya han sido debidamente considerados en forma de una especificación funcional. El poker de planeación incluye como participantes a todo el personal técnico posible del grupo de proyecto incluyendo desarrolladores, arquitectos, testers, DBAs, etcétera. Al inicio del poker de planeación se le ofrece a cada estimador un mazo de cartas donde cada carta tiene escrito un valor estimado válido: 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 16, 20, y 40. Los números deberán ser suficientemente grandes para verse desde el otro extremo de una mesa. Los números representan el tamaño funcional relativo de lo que se va a estimar y lo importante es que se mantenga consistencia entre los tamaños relativos, es decir, una función con tamaño 2 debe representar el doble de funcionalidad de una función con tamaño 1.

Los roles son el moderador, el dueño del producto y los estimadores. El dueño del producto es similar al rol gerente de producto en MSF. Por cada función, caso de uso o característica a ser estimada el moderador lee en voz alta la descripción. El dueño del producto contesta cualquier pregunta que tengan al respecto los estimadores. Después de ser contestadas todas las preguntas para esa función, cada estimador selecciona una carta en forma privada y que represente su tamaño funcional estimado. Las cartas permanecen privadas hasta que todos los estimadores hayan hecho su elección. Entonces, todas las cartas son mostradas simultáneamente de tal forma que todos los participantes pueden verlas. Es muy probable que en este punto los estimados varíen significativamente y esto, de hecho, son buenas noticias. Si estos difieren, los estimadores con las evaluaciones más bajos y más altos proceden a explicar su estimado. Nótese que no se trata de criticar o atacar a estos estimadores en este punto, sino de escuchar y entender cuáles fueron sus criterios. El grupo puede discutir la función bajo estimación por algunos minutos, durante los cuales se pueden tomar notas de puntos importantes para el momento de estar implementando dicha función. Después de la discusión, cada estimador revalora y realiza nuevamente un estimado seleccionando la carta correspondiente de manera privada. Las cartas permanecen privadas hasta que todos hayan evaluado y entonces todas las cartas son mostradas simultáneamente. Para la segunda vuelta es probable que los estimados hayan convergido, pero sino, será necesario repetir el proceso. El objetivo es que estos converjan en un solo estimado para la función en cuestión. No es absolutamente necesario que todos coincidan en un solo número, lo importante es que exista consenso.

Referencias [ Agile Software Development. The Cooperative Game by Alistair Cockburn ] [ Peopleware. Productive Projects and Teams by Tom DeMarco y Timothy Lister ] [ Controlling Software Projects. Management, Measurement and Estimation by Tom DeMarco ] [ Agile Estimating and Planning by Mike Cohn ]

AGO-OCT 2008

// fundamentos

Un, Dos, Threads! Una Introducción Simple a los Threads y sus Conceptos Básicos Por Erick Frausto Quizás están esperando leer algo sobre threads al comenzar a revisar este artículo, pero les propongo que recorran esta lectura de una forma diferente, qué les parece si comenzamos hablando sobre las casetas telefónicas. Se preguntarán ¿cuál es la relación de los threads con estas?, descubramos mas adelante la analogía. En la ciudad de México no me ha tocado ver en las esquinas de las calles casetas telefónicas con cabina, pero creo que todos hemos visto una en las películas, como aquellas donde Superman entraba a cambiarse para ponerse su disfraz. Ahora que menciono esto, Superman tendría que asegurarse de que nadie mas utilizará la caseta telefónica donde se cambiaba para que nadie descubriera quién era realmente, y debido a que las casetas telefónicas que ocupaba eran públicas y por lo tanto accesible para cualquier usuario, Superman tendría que tener cuidado. Sabemos que estas casetas al tratarse de un recurso compartido, su uso está sincronizado para atender a un usuario a la vez, así que por este lado Superman podría estar tranquilo, y los usuarios que desean hacer una llamada también lo estarán ya que nadie mas interrumpirá su conversación mientras usa la caseta telefónica. De lo contrario, ¡imagínense lo que pasaría si el uso de la caseta telefónica no estuviera sincronizado!. Cualquier persona entraría a la caseta mientras alguien más la está utilizando, colgaría su llamada y marcaría el nuevo número para comunicarse con alguien más, además de que la cabina se saturaría después de unos cuantos usuarios, seguro que habría bastantes problemas entre los usuarios además de que todos sabrían quién es Superman y se enterarían de todo lo que dice la persona que esté hablando. También deberíamos considerar que la caseta telefónica podría sufrir descomposturas o

requerir mantenimiento, y por lo tanto, debería un técnico estar al tanto de las reparaciones y mantenimiento de ésta, momento en el cual el siguiente usuario de la caseta deberá esperar fuera de esta si llegara alguno en el momento de una reparación o hacer fila si algún usuario ya se encontrara esperando para entrar (¡incluido Superman!) y con esto permitir el trabajo del técnico quien también tuvo que esperar a que terminara la llamada de algún usuario si es que alguno se encontrara usando la caseta en el momento de su arribo. Una vez que el técnico termine con el mantenimiento y/o reparaciones, dará el aviso a los usuarios para que continúen con el uso de la caseta. Llegando a este punto, seguro que las personas que planificaron la forma en como funcionarían las casetas telefónicas de uso público consideraron las siguientes situaciones: • Las casetas telefónicas serán de uso compartido • Los usuarios podrán llegar de forma concurrente a la caseta, por lo que el uso de la misma deberá sincronizarse • Un técnico se encargará de forma periódica de visitar la caseta telefónica para realizar el mantenimiento y/o hacer las reparaciones correspondientes si estas fueran necesarias. En este momento, la caseta no podría ser utilizada por ningún otro usuario Bien, ahora será momento de hacer la analogía de la caseta telefónica con los threads y de plasmarla en código para poder echar a andar nuestro ejemplo de manera práctica. Para esto, primero pensemos en el diseño de nuestra caseta y las diferentes formas en que podrá ser utilizada por sus usuarios, la primera sería su uso para realizar una llamada y dirigida a cualquier tipo de usuario; otra sería darle mantenimiento, enfocada a los técnicos encargados de que la caseta funcione correctamente. Es un hecho que

solo un usuario a la vez podría estar haciendo uso de la caseta telefónica y también es un hecho que diversos usuarios a la vez podrían necesitar hacer uso de ella, por lo que para resolver este problema necesitaremos sincronizar el uso de la caseta y de esta forma asegurarnos que solo un usuario a la vez la utiliza, por otra parte, el técnico encargado del mantenimiento también deberá ser el único que podría estar dentro de la caseta ya que mientras el mantenimiento se realiza, la caseta estaría temporalmente fuera de servicio y no podría ser usada ni por otro técnico ni por cualquier otro tipo de usuario. Con esto, nuestra clase que representa la caseta telefónica quedaría de la siguiente manera: package undosthreads; public class CasetaTelefonica { private String numeroMarcado; private boolean enUso; private boolean enMantenimiento; public synchronized void usarCaseta(String numeroTel) throws Exception { if(enMantenimiento) { wait(); // El usuario esperara a que el mantenimiento se termine } enUso = true; numeroMarcado = numeroTel; if(!numeroMarcado.equals(“”)) { System.out.println(“Se esta haciendo una llamada al numero: “ + numeroMarcado); } else { System.out.println(“El usuario no específico un número para hacer la llamada.”); System.out.println(“Tal vez entro superman para cambiarse y salir al rescate...”); } long duracionLlamada = Math.round(Math.random() * 10000); Thread.sleep(duracionLlamada); // Llamando... System.out.println(“Duración de la llamada: “ + duracionLlamada/1000 + “seg.”); numeroMarcado = null; // El usuario colgo el telefono enUso = false; } public synchronized void darMantenimiento() throws Exception { enMantenimiento = true; while(enUso) { } System.out.println(“Caseta Telefónica en mantenimiento...”); long duracionMantenimiento = Math.round(Math.random() * 10000); Thread.sleep(duracionMantenimiento); // En mantenimiento... System.out.println(“Duración del mantenimiento: “ + duracionMantenimiento/1000 + “seg.”); enMantenimiento = false; notifyAll(); // El tecnico avisa a los usuarios que pueden continuar con el uso de la caseta } }

Como podemos darnos cuenta, tanto el método usarCaseta() y el método darMantenimiento() se encuentran sincronizados (synchronized), con esto aseguramos que los usuarios se-

Erick Frausto es egresado de la carrera de Ing. en Informática en UPIICSA-IPN. Además de desempeñarse como Arquitecto JEE, organiza cursos sobre tecnología Java. Lo puedes contactar al siguiente e-mail: erick_frausto10@yahoo.com.mx. Erick dedica este artículo a su hermosa novia Irma.

AGO-OCT 2008

www.sg.com.mx

rán representados como threads podrán acceder uno a la vez a un método en particular, de esta manera tenemos que solo un thread entrará al método usarCaseta() y un solo thread entrará al método darMantenimiento(). Pero lo anterior no resuelve del todo nuestro problema de concurrencia, ya que la implementación que tenemos hasta ahora permite que un usuario normal y un técnico puedan hacer uso de la caseta telefónica al mismo tiempo, por lo que deberemos establecer una comunicación entre los usuarios normales y el técnico, esto lo logramos mediante los métodos wait() y notifyAll(), el método wait() le dice al thread que se este ejecutando que deberá suspender momentáneamente su ejecución hasta que otro thread le notifique que puede continuar, el método wait() será llamado por el thread que representa a un usuario normal cuando detecte que la caseta telefónica se encuentra en mantenimiento, y el método notifyAll() será llamado por el thread que representa al técnico, este método lo que hace es avisar a los threads que están en espera que pueden continuar con su ejecución, es decir, le dirá a los usuarios que la caseta telefónica esta lista para ser usada nuevamente. Una vez lista nuestra caseta telefónica, pasemos a la creación de nuestros usuarios. Como mencionamos antes, tanto la implementación de los usuarios normales como la implementación del técnico, deberán estar basados en threads. Existen dos formas en Java mediante las cuales indicamos que una clase será un thread, esto es extendiendo de la clase Thread o implementando la interfaz Runneable, en ambos casos debemos de implementar el método run() cuyo contenido será la actividad que el thread llevará a cabo. Veamos ambos casos: package undosthreads; public class Usuario1 extends Thread { private CasetaTelefonica ct; private String numTelefono; public Usuario1(CasetaTelefonica ct, String numTelefono) { this.ct = ct; this.numTelefono = numTelefono; } public void run() { try { ct.usarCaseta(numTelefono); } catch(Exception e) { System.out.println(e); } } }

www.sg.com.mx

package undosthreads; public class Usuario2 implements Runnable { private CasetaTelefonica ct; private String numTelefono; public Usuario2(CasetaTelefonica ct, String numTelefono) { this.ct = ct; this.numTelefono = numTelefono; } public void run(){ try { ct.usarCaseta(numTelefono); } catch(Exception e) { System.out.println(e); } } }

En el caso del técnico, la implementación quedará de la siguiente manera: package undosthreads; public class Tecnico extends Thread { private CasetaTelefonica ct; public Tecnico(CasetaTelefonica ct) { this.ct = ct; } public void run() { try { ct.darMantenimiento(); } catch(Exception e) { System.out.println(e); } } }

Finalmente nos queda crear una clase de prueba donde echaremos a volar nuestra pequeña aplicación, esta luce de la siguiente manera: package undosthreads; public class Test { public static void main(String[] args) throws Exception { CasetaTelefonica ct = new CasetaTelefonica(); Usuario1 a = new Usuario1(ct, “98776655”); a.start(); Usuario2 b = new Usuario2(ct, “99887654”); Thread hilo = new Thread(b); hilo.start(); Tecnico tecnico = new Tecnico(ct); tecnico.start(); Usuario1 superman = new Usuario1(ct, “”); superman.start(); Usuario1 c = new Usuario1(ct, “81909090”); c.start(); } }

Aquí tenemos la creación del objeto caseta telefónica que será compartido entre los distintos usuarios. Después tenemos la creación de diversos objetos que representan a los usuarios, lo interesante a mencionar en esta parte es la diferencia cuando creamos un thread cuya clase que representa su función hereda de la clase Thread o implementa la interfaz Runnable, en el primer caso solo es necesario crear el objeto de la clase que here-

da de Thread y llamaremos al método start(), el cual iniciará la ejecución del thread (la JVM se encargará de llamar al método run() que implementamos para este Thread), para el segundo caso después de crear el objeto de la clase que implementa Runneable, crearemos una instancia de Thread y le pasaremos a través de su constructor el objeto creado un paso antes, posteriormente llamaremos al método start() que tendrá la misma función que en el primer caso. Con la ejecución de la clase de prueba, podremos ver algo como esto: Se esta haciendo una llamada al numero: 98776655 Duración de la llamada: 2seg. Se esta haciendo una llamada al numero: 99887654 Duración de la llamada: 3seg. Caseta Telefónica en mantenimiento... Duración del mantenimiento: 4seg. El usuario no específico un número para hacer la llamada. Tal vez entro superman para cambiarse y salir al rescate... Duración de la llamada: 9seg. Se esta haciendo una llamada al numero: 81909090 Duración de la llamada: 1seg.

Conclusión Es claro que lo que vimos fue una introducción al tema de threads y a sus conceptos básicos, estos dan lugar a tantas opciones dentro de la creación de aplicaciones en Java, desde las que solo requieran levantar un thread en paralelo al thread principal para que borre archivos temporales hasta aplicaciones complejas que requieran toda una administración de threads, como una aplicación de scheduling donde se podrían tener diversos threads ejecutándose en paralelo y accediendo a recursos compartidos, donde la implementación de una aplicación de este tipo requerirá de toda la dedicación y atención posibles tanto en su diseño como en su desarrollo. El desarrollo de aplicaciones basadas en threads es un tema complejo y para el cual existen libros completos tratando el tema, sin embargo, espero que esta pequeña introducción sea un primer buen paso para los que se inician en el tema de threads y sus conceptos básicos.

AGO-OCT 2008

// COLUMNA

/*PRUEBA DE SOFTWARE*/

La Calidad del Software Mexicano Resultados del 2º Concurso e-Quallity Luis Vinicio León Carrillo es actualmente Director General de e-Quallity, empresa especializada en prueba de software, de la que es cofundador. Fue profesor-investigador en el ITESO durante varios años, que incluyeron una estancia de posgrado en prueba de software en Alemania, en la que abordó aspectos formales de dicha disciplina. Es autor de varias publicaciones nacionales e internacionales. Fue cofundador del Capítulo Jalisco de la AMCIS.

ecientemente el proceso de prueba de software, de la empresa en la que laboro, fue certificado con un nivel muy alto tanto en el modelo estadounidense Testing Maturity Model (TMM) como en el europeo Test Process Improvement (TPI). Aprovechando esta experiencia el año pasado lanzamos el Concurso e-Quallity 2007, en el que convocamos a la comunidad desarrolladora nacional de software a enviarnos productos pequeños terminados, para encontrar los productos con menor densidad de defectos (cantidad de defectos entre tamaño). Hicimos la premiación en el congreso SG’07 Conferencia y Expo, publicamos los resultados en la columna Prueba de Software del número 20 de esta revista. Este año llevamos a cabo el Concurso e-Quallity 2008, del cual hicimos la premiación en el pasado congreso SG’08 Conferencia y Expo. Aquí mostraremos los resultados que se obtuvieron. Nuestro objetivo no es realizar un estudio estadístico riguroso, sino poner nuestro grano de arena en la generación de datos para cubrir el enorme hueco de información que tenemos respecto a métricas de calidad de los productos mexicanos, y su repercusión en la industria.

El Impacto de probar inadecuadamente el Software En la publicación de esa columna, mencionábamos que en 2003 la industria de los Estados Unidos perdió cerca del 1% de su PIB por pruebas de software inadecuadas o inexistentes, equivalente a casi 60 mil millones de dólares. Comentamos que en México no existe una cuantificación semejante, pero que podemos pensar que en nuestro país el efecto es más nocivo, pues mientras que la industria

AGO-OCT 2008

5JFNQP

%FTBSSPMMP EFM QSPEVDUP

.BOUFOJNJFOUP DPO 1SVFCBT

7FOUBT

.BOUFOJNJFOUP TJO 1SVFCBT

Figura-1: Impacto económico de las pruebas

del software estadounidense es mucho más grande y madura, la nuestra está apenas despegando, lo que dificulta ganar inercia positiva, y crea un nocivo circulo vicioso. En The Impact of Software Testing in small Settings, publicamos datos del impacto económico de las de pruebas en dos proyectos reales en los que participamos. Puesto gráficamente tendríamos lo que se observa en la Figura 1. Aquí la curva negra muestra el consumo de los recursos al desarrollar un nuevo producto de software, considerando datos de A Guide to the Project Management Body of Knowledge; la verde los ingresos por ventas del producto; la azul los costos de mantenimiento cuando el software es probado adecuadamente antes de ser liberado y se elimina la mayoría de los defectos; y la roja los costos de mantenimiento cuando no se prueba o se prueba inadecuadamente el software. Cuando no se prueba adecuadamente el software, los costos de mantenimiento suelen mermar significativamente las utilidades (ventas – mantenimiento, grosso modo), dificultando la inversión en mercadotecnia e innovación en el producto, haciendo difícil el crecimiento de esa unidad de negocio.

El proceso y la muestra La evaluación de servicios la realizamos en tres fases: 1. Un Diagnóstico del software: un tester experimentado realiza pruebas exploratorias y detecta una primera capa de defectos. Utilizando esa información y nuestro Modelo Predictivo, se genera una estimación de los defectos que aún se encuentran en el producto, el costo de detectarlos, y la comparación del producto contra la media de calidad de los productos que hemos probado. 2. Con esos datos del diagnóstico, el interesado puede optar por contratar las Pruebas Profundas para detectar esos defectos: si el producto está muy mal, sólo se justifica invertir en pruebas lo suficiente como para detectar una pequeña segunda capa de defectos críticos (por ejemplo, probar sólo alguna(s) sección(es)); si está muy bien, recomendamos no invertir en pruebas pues resultará muy caro detectar los defectos; si el producto tiene un estado intermedio, las pruebas profundas sí pueden ayudar a mejorar significativamente el producto. 3. Si después de estas pruebas profundas y las correspondientes pruebas regresivas, el software muestra un buen comportamiento www.sg.com.mx

â&#x20AC;&#x153;Mientras que la industria del software estadounidense es mucho mĂĄs grande y madura, la nuestra estĂĄ apenas despegandoâ&#x20AC;?.

al aplicar nuestro Modelo de Calidad de Producto, otorgamos nuestro Sello de Calidad e-Quality Approved, mismo que fue validado con apoyo del Consejo Nacional de Ciencia y TecnologĂa (CONACyT). Para la ejecuciĂłn del Concurso aplicamos un proceso que representa un downsizing del DiagnĂłstico mencionado arriba (fase 1). Este aĂąo redujimos el nĂşmero mĂĄximo de concursantes a 20. Una cantidad considerable de productos fueron rechazados, ya fuera porque se excedĂan en el tamaĂąo, o porque no estaban completamente terminados. La muestra final constĂł de 15 productos, provenientes de varios dominios de aplicaciĂłn. Su tamaĂąo (entre 20 y 30 meses hombre) se midiĂł utilizando una mĂŠtrica interna semejante a los puntos de funciĂłn.

Resultados y AnĂĄlisis En la tabla que se muestra a continuaciĂłn presenta datos sobre la calidad de los productos concursantes (KLOC = miles de lĂneas de cĂłdigo).

(Esto es un tema en sĂ mismo, que buscaremos abordar en otro nĂşmero.) Por tanto, la hipĂłtesis no es concluyente. Por otra parte, este aĂąo recabamos la mĂŠtrica de los Defectos por KLOC (D/KLOC). En el marco del Encuentro Prosoft llevado a cabo recientemente, se anunciĂł el impulso que se le brindarĂĄ en nuestro paĂs al modelo Team Software Process (TSP); ahĂ mismo Watts Humphrey (autor de ese modelo y de CMMI) declarĂł que con TSP se pueden alcanzar densidades de defectos de hasta 0.06 D/KLOC, contra los 7.50 para el Nivel 1 de CMMI-1, los 6.24 para el 2, los 4.73 para el 3, los 2.28 para el 4, y los 1.50 para el 5. Los resultados obtenidos en este Concurso muestran que el 1Âş, 2Âş y 3er lugar tendrĂan densidades de defectos correspondientes al Nivel 4, 4 y 5 de CMMI respectivamenteâ&#x20AC;Ś lo curioso es que esas empresas no tienen tales acreditaciones. AquĂ tambiĂŠn hay que considerar la salvedad del tamaĂąo (size matters).

En un primer acercamiento, si comparamos directamente la segunda columna contra los resultados del Concurso pasado, podrĂamos pensar que estos productos son mĂĄs estables que aquellos. Sin embargo, estos fueron mĂĄs pequeĂąos, y como dijera un autor â&#x20AC;&#x153;Size mattersâ&#x20AC;?: un producto de 100 KLOC con 300 defectos en realidad tiene constituyentes mĂĄs confiables que un producto de 10 KLOC con 30 defectosâ&#x20AC;Ś siempre y cuando tengan complejidad estructural semejante.

ConclusiĂłn Un asunto pendiente que abordaremos en otro nĂşmero es cĂłmo los ganadores de los primeros lugares en el concurso lograron esos niveles de calidad. Por otro lado: se asevera que con TSP se puede obtener densidades de defectos de hasta 0.06 D/KLOC; sin embargo, hemos encontrado empresas

1SPEVDUP

%FGFDUPT $BTPT EF 1SVFCB

%FGFDUPT ,-0$

NgT NBEVSP

QSPNFEJP

NFOPT NBEVSP

en nuestro paĂs que reportan lograr densidades semejantesâ&#x20AC;Ś lo curioso es que son los mismos programadores los que realizan las pruebas, no un equipo de testers (interno o externo) debidamente entrenado, al que se le pague por detectar defectos (a los desarrolladores no se les entrena para eso, ni se les paga por ello). Para poder demostrar que con TSP verdaderamente se pueden alcanzar esas densidades de defectos, serĂa interesante ver resultados de pruebas realizadas por un tercero, no por los mismos desarrolladores de la empresa. HabrĂĄ que esperar ademĂĄs, mĂĄs precisiĂłn de TSP, pues no es lo mismo hablar de esas densidades de defectos para productos de 100 KLOC, que para productos de 1,000 KLOC. Surge tambiĂŠn la duda: ÂżcuĂĄntas KLOC suelen tener los compiladores comerciales?, Âżcon quĂŠ densidad de defectos? Si fuera superior a 0.06 D/KLOC, entonces los productos generados por ellos tendrĂan dificultad para alcanzar ese nĂşmero.

Referencias [ LeĂłn-Carrillo, L.: Columna â&#x20AC;&#x153;Prueba de Softwareâ&#x20AC;?, Software GurĂş, Feb-Abr 2008 ] [ LeĂłn-Carrillo, L.: The Impact of Software Testing in small Settings, en Oktaba, H. and Piatini, M. et.al. Software Processes in small Enterprises. IGI Global. 2008 ] [ The Project Management Institute: A Guide to the Project Management Body of Knowledge. USA, 2000 ] [ e-quallity.net/definiciones.php ] [ e-quallity.net ] Âť Luis Vinicio LeĂłn Carrillo

Tabla-1: Densidad de Defectos en Productos mexicanos pequeĂąos

www.sg.com.mx

AGO-OCT 2008

// COLUMNA

/*tendencias en SOFTWARE*/

Nuevos Patrones de Software para el Consumidor Digital El Concepto Mesh Luis Daniel Soto es director regional de desarrolladores y difusión de plataforma en Microsoft para América Latina. Es miembro de la orden nacional al mérito de México (ministro de educación). Luis Daniel obtuvo el primer lugar en el Concurso Nacional para Software de Exportación en 1989. blogs.msdn.com/luisdans

Presente

e han consolidado los medios sociales, complementando a los medios tradicionales de comunicación. Este conjunto de tecnologías del Web 2.0 junto con otras (por ejemplo, experiencia de usuario) evolucionan a Enterprise 2.0. El desarrollador de software vive una gran confusión entendiendo las tecnologías. Por ejemplo, si he de construir una experiencia Rich Internet Application (RIA) o una Rich Local Application, se tiene que entender a fondo las diferencias y ventajas para seleccionar entre Silverlight, WPF, Ajax, HTML, FLASH, AIR, JavaFX y otras. Las opciones que permiten crear aplicaciones Web, para dispositivos, para el escritorio y para el servidor con las mismas herramientas y lenguajes son muy pocas.

Nuevas realidades: cómputo en la nube El panorama se complicará, se demandará la creación de nuevos patrones de creación de soluciones de software. Por una parte el cómputo en la nube (trataremos ese tema en una columna futura), por otra el desarrollo de cómputo empresarial (tampoco lo trataremos a fondo ahora). Estamos por ver una evolución de las herramientas de desarrollo de software a creación de mashups que combinen sistemas internos y externos, y se continuará soportando mayor funcionalidad ALM en sistemas cliente-servidor. Hoy nos enfocaremos en los consumidores finales de tecnologías.

Un modelo para aplicaciones del consumidor digital Ni el desarrollo monolítico, ni el de múltiples capas, tampoco el modelo de software entregado como servicio resuelve las necesidades de los nativos digitales y del consumidor en la era digital:

AGO-OCT 2008

-BQUPQ

)PNF %FTLUPQ

"EE %FWJDF

8PSL -JWF %FTLUPQ

• Los dispositivos no tienen nociones de pertenencia entre ellos. El usuario no tiene una vista de todos sus dispositivos. Aunque a nivel empresarial está resuelta la distribución de software, un usuario que tiene varias computadoras tiene que pelear por mantener la configuración e instalar en forma independiente. • Los datos están atrapados. Apesar de vivir en la época de facilidad de intercambio de información, esto no es cierto. Un usuario con varias computadoras tiene que enviarse correos a sí mismo a veces para sincronizar sus sistemas. El paradigma actual de sincronización 1:1 es frágil y tedioso. • Las aplicaciones no son capaces de vivir en múltiples dispositivos: si fueron hechas para Internet su capacidad de operar fuera de línea es muy pobre. Carecen de capacidades básicas de explotar las redes sociales a nuestro alrededor: de la misma forma que hoy el menú “editar, copiar” existe, debería permitir “etiquetar (tag), calificar (rate)”, etcétera. Es decir, el individuo que hoy vive en la era digital no tiene acceso entre sus dispositivos, aplicaciones, datos y redes sociales con las que interactúa.

Solución El Web es el centro de intercambio de información: imaginemos que de alguna forma en

Internet un usuario almacena una lista de sus dispositivos para que estos tengan noción el uno del otro, para que posteriormente el usuario pueda definir la ubicación de archivos en cualquier dispositivo o en un almacenamiento en la nube. Además existe un software que es capaz de replicar los datos entre los dispositivos utilizando normas de Internet y traspasando cualquier configuración de red. Por ejemplo, Juan crea un listado que incluye la computadora de oficina, el sistema de teatro en casa, una Apple mac de uso personal y un teléfono celular inteligente. Después define que la carpeta “imágenes personales” va a residir en la computadora que corresponde a la sala de TV pero que se mantendrá sincronizada en todos los dispositivos. Ese usuario también desea que su esposa pueda acceder la carpeta por lo que de forma natural permite la colaboración grupal. Esas computadoras, podrán sincronizarse y comunicarse de dispositivo a dispositivo de forma segura: no se requiere Internet. Por último, la actualización será automática y transparente, los datos auténticamente se hacen disponibles en el momento necesario y en cualquier dispositivo. En el modelo más avanzado, es posible ahora crear una aplicación, por ejemplo de administración de proyectos, que puede trawww.sg.com.mx

“El individuo que hoy vive en la era digital no tiene acceso entre sus dispositivos, aplicaciones, datos y redes sociales con las que interactúa”. bajar indistintamente en la nube, en una red o localmente. Y cuando lo hace localmente eventualmente se sincronizará. El usuario tendrá la vista de que dispositivos han sido sincronizados. Sin duda, esto representa un innovador patrón que complementa los existentes hoy en día. Una implementación de este modelo es parte de lo que se ha denominado Live Mesh. Se compone de una plataforma que define modelos, servicios en la nube, software en el cliente y una experiencia de plataforma que expone dispositivos, archivos, aplicaciones, notificaciones y redes sociales. No hay que confundir las primeras aplicaciones con el concepto, la implementación de carpetas virtuales o acceso remoto son solo

www.sg.com.mx

las aplicaciones más triviales que se construyen bajo el nuevo esquema.

Resultado Los beneficios son: • Los dispositivos trabajan de forma integrada. Se comunican por canales encriptados, cada dispositivo puede tener poder de cómputo y almacenamientos muy variables, conforme lo demande la aplicación. • Acceso universal. Por primera vez, el mesh está disponible en cualquier dispositivo que puede ser accedido desde cualquier cliente o arbitrariamente en cualquier explorador de Internet. • Simple de compartir. Es fácil invitar a más personas a colaborar los unos con los otros.

•Manténgase informado. Es posible descubrir los cambios y actividades que a cada quién interesan. •Nuevas experiencias. Se hace posible que los sitios de Internet se extiendan en partes portátiles que hace sentido llevar y operar fuera de línea. Combine esto con tecnologías para crear interfaces cinemáticas en pantallas muti-tácto y los consumidores estarán complacidos. La era de la innovación en software más servicios apenas ha iniciado…

Rerefencias [ mesh.com ] [ is.gd/tgj ]

» Luis Daniel Soto

AGO-OCT 2008

// TECNOLOGÍA

/*INFRAESTRUCTURA*/

¿Repetir el Proceso? 10 recomendaciones para una migración P2V exitosa Traducido por Martín Álvarez Cuando se trata de migrar servidores físicos a máquinas virtuales, muchos profesionales de TI han descubierto que llegar ahí no es la mitad de la diversión. Muy a menudo, el proceso de conversión es más frustrante, confuso y tardado de lo que necesita ser. El tiempo y recursos requeridos para la conversión son variables importantes en el valor global y el costo total de propiedad que le brindarán sus sistemas virtualizados. Es fundamental seleccionar el enfoque correcto en la migración de servidores físicos a virtuales (P2V) para minimizar riesgos, mantener su proyecto dentro del presupuesto y en continuidad, y sus datos intactos. Presentamos las siguientes recomendaciones para el manejo del proceso y la selección de la solución que mejor satisfaga sus necesidades.

1. Evalúe las necesidades inmediatas y futuras La conversión P2V se ha llevado a cabo de muchas maneras, pero sólo unos cuantos enfoques han funcionado bien en las migraciones a gran escala. La escalabilidad y la velocidad son dos de los mayores diferenciadores entre las soluciones de conversión; de modo que es importante que entienda sus necesidades actuales y futuras.

sión. La mayoría de las organizaciones tienen una fecha límite para su conversión de físico a virtual y tienen tiempo extra limitado para completarlo. Por lo tanto, el tiempo de conversión total y la capacidad de conversión simultánea de cada enfoque son consideraciones importantes. Decida si puede desconectar servidores para realizar la conversión durante o después de horas de trabajo y determine de cuánto tiempo con los servidores desconectados dispone en total antes de la fecha límite del proyecto. A continuación, divida el tiempo disponible entre el número de servidores que virtualizará a fin de determinar su requisito de tiempo de conversión total del que puede disponer por servidor. Aquí el presupuesto es también un factor (¿se necesitará tiempo extra o personal adicional para completar el proyecto?).

3. Evalúe sus facultades Las preguntas acerca del personal y del presupuesto no se pueden responder hasta que determine si su personal tiene las facultades y el tiempo para llevar a cabo la conversión. Evalúe sus conocimientos de TI internas y su disponibilidad para determinar qué opciones tiene a disposición su organización.

4. Fije una meta de nivel de éxito

Considere no sólo cuántos servidores se necesitan convertir en el proyecto en curso, sino también si se pueden convertir otros servidores de forma periódica o en masa (como volver otro departamento virtual después de que se completen los proyectos actuales). También es importante tomar en cuenta si todos los servidores físicos serán convertidos a la misma plataforma virtual o si se pudieran utilizar múltiples entornos virtuales. Algunas soluciones de conversión sólo admiten un entorno virtual.

Las fallas en la conversión de servidores P2V no son raras. Pueden ocurrir fallas con máquinas virtuales de mayor tamaño por arriba del rango de los 50 gigabytes, y también cuando las herramientas P2V no cuentan con el soporte para ciertos entornos, controladores o servicios implícitos. Utilizando el tiempo y el personal disponibles como guías, determine cuántas conversiones fallidas puede soportar, fije una meta de nivel de éxito y úsela para ayudarse en la evaluación de opciones. Debe poder encontrar una solución que le proporcione un nivel de éxito de al menos 95%.

2. Establezca escalas de tiempo, fechas límite y presupuestos

5. Conozca las opciones (y sus limitaciones)

A menudo el mejor enfoque depende del tiempo disponible para completar la conver-

Si sigue las primeras cuatro recomendaciones tendrá un buen entendimiento de sus

AGO-OCT 2008

necesidades. Ahora es tiempo de empatarlas a las soluciones disponibles. Existen cuatro enfoques básicos de la conversión P2V. Cada uno de ellos es efectivo en casos de uso específicos y cada uno tiene sus limitaciones. Primero elija el enfoque general y luego comience por evaluar opciones de una solución específica. Éstas son cápsulas resumidas de enfoques de conversión P2V: • CDs de arranque más utilidades generales de clonación y copia. Las organizaciones a menudo utilizan software de clonación heredado y lo complementan con una utilidad de conversión de máquina virtual y CDs de arranque para capturar, convertir y transferir archivos. Éste es el enfoque de conversión original y puede ser difícil de usar, en especial si se le compara con alternativas más recientes. Es el mejor para proyectos de conversión pequeños o únicos. • Herramientas de conversión gratuitas de proveedores de plataformas de virtualización. Para los usuarios con un entorno virtual homogéneo, las herramientas gratuitas que ofrecen los fabricantes representan un paso adelante del enfoque de copiar e iniciar. Como las herramientas gratuitas se centran en el aspecto de la conversión y no intentan automatizar mucho del proceso global, el tiempo total que se requiere para preparar, convertir y solucionar problemas de los servidores puede ser muy largo, en especial en el caso de servidores grandes. Conclusión: son buenas para conversiones únicas y ocasionales. • Herramientas y soluciones de conversión comerciales. Las soluciones comerciales automatizan muchas tareas relacionadas con la preparación, conversión y procesamiento posterior, y a menudo proporcionan una interfaz de usuario única para estas etapas. Ofrecen el tiempo total de migración más corto y pueden incluir programación de actividades y funciones avanzadas de conversión simultáneas; de modo que a menudo son más adecuadas para proyectos de mediana y gran escala.

www.sg.com.mx

• La subcontratación de servicios con un proveedor de soluciones es siempre una opción y puede que sea la única opción práctica para organizaciones con necesidades únicas que no satisfacen las aplicaciones de conversión comerciales. Es más apropiada para organizaciones con restricciones severas de tiempo y personal.

6. Calcule el tiempo total que emplearía cada método Tras un análisis inicial, uno o dos enfoques de conversión podrían parecer apropiados para su proyecto. Uno de los errores más comunes (y costosos) que se comete en los proyectos de conversión P2V es subestimar el tiempo total requerido. Asegúrese de considerar la preparación de los servidores físicos, la programación de los tiempos para los propietarios de los servidores, los pasos precisos requeridos para llevar a cabo la conversión y los requisitos de procesamiento posteriores a la conversión cuando evalúe el tiempo total requerido. Estas recomendaciones deben ayudarle a identificar el enfoque y la solución que mejor se adapte a sus necesidades. Las recomendaciones siguientes se aplican a la ejecución de la conversión misma.

7. Prepare los servidores para optimizar el proceso de conversión Los tiempos de conversión pueden disminuir y los niveles de éxito aumentar cuando los servidores físicos son preparados de manera efectiva con antelación. Los pasos a seguir en esta etapa incluyen calcular el inventario de sus parámetros de configuración, detalles de la licencia y direcciones IP, instalar parches de software, desfragmentar unidades de disco, limpiar directorios, descomprimir archivos y realizar otras tareas de mantenimiento. También debe verificar que

la red disponga del ancho de banda para transferir la imagen virtualizada, y que la máquina virtual destino tenga la memoria para poder aceptarla. Trabaje con el propietario del servidor y programe la conversión y la prueba subsecuente del entorno virtualizado. Por último, fije fechas límite para solicitudes de cambios y programe la realización de la conversión real.

8. Automatice la ejecución hasta donde sea posible La realización del paso de conversión puede tomar de unos 30 minutos a 20 horas. El tiempo requerido tiene un impacto importante en el costo del proyecto y en la posibilidad de cumplir con la fecha límite. Se suscitan muchos procesos entre el momento en que se instala el software de conversión y se inicia el servidor virtual recientemente migrado. Se deben seleccionar, configurar y asignar nombres a destinos y anfitriones; es posible que se requiera alguna partición; que se necesite configuración adicional para la CPU y la memoria; se deben monitorear las redes y las condiciones de error; se debe asignar un nombre e iniciar la nueva máquina virtual; y se debe repetir el proceso con el siguiente servidor. Cuantas menos de estas tareas tenga que realizar el administrador manualmente, más rápido se realizará la conversión. Las velocidades de conversión reales varían considerablemente entre las herramientas y soluciones P2V, asegúrese de considerar la velocidad cuando manipule todas las variables.

9. Verifique y haga pruebas La complejidad de la preparación y la conversión misma crean oportunidades de error; de modo que las máquinas virtuales recientemente convertidas deben ser probadas para asegurarse de que la conversión haya sido exitosa. Incluso cuando resultó libre de errores, existen varias tareas posteriores

que se deben llevar a cabo. Entre estas se cuentan: revisar registros, reactivar servicios y agentes, actualizar controladores, realizar pruebas de control de calidad, ejecutar scripts generados por el usuario, activar y sincronizar la nueva máquina virtual, crear documentación y quitar el software de conversión. Estas actividades se deben contemplar al calcular los requisitos de tiempo total de conversión, que frecuentemente se pasan por alto. Una vez más, el tiempo requerido para completarlas depende de lo completa que sea la solución de conversión.

10. Repita el proceso las veces que sea necesario Para realizar conversiones de medio y alto volumen, el método debe ser repetible para ser efectivo. Las soluciones desarrolladas para estos escenarios de uso tienen características para eliminar mucha de la redundancia en la conversión de decenas o cientos de servidores físicos. Existen muchos enfoques para convertir un servidor físico en un entorno virtual, pero las opciones prácticas se reducen abruptamente cuando aumenta el tamaño del proyecto. En el caso de migraciones de servidores a gran escala, el tiempo del personal es a menudo el elemento más costoso del proyecto de virtualización. Las soluciones que ahorran tiempo ahorran dinero. Los conocimientos y la disponibilidad son también restricciones comunes. Las organizaciones deben considerar el tiempo de conversión total al evaluar diferentes enfoques y deben determinar qué tareas necesitan que manipule su solución de conversión. Considerando y manejando estas variables, las organizaciones pueden seleccionar la solución más eficiente para sus necesidades y por último minimizar el riesgo, el tiempo y el costo total.

Martín Álvarez realizó la traducción del documento original que pueden consultar en: http://www.vizioncore.com/articles/positiondoc/p2v.pdf

www.sg.com.mx

AGO-OCT 2008

// TECNOLOGÍA

/*gadgets*/

Connect-A-Desk ¿Cuántas veces has caminado con la lap-top encendida y escribiendo con una sola mano? Suena extraño, pero ¡es cierto!. En ocasiones, tenemos la necesidad de estar con la computadora portátil funcionando al mismo tiempo que caminamos o estamos parados, es un poco incómodo no solamente teclear con una sola mano, sino estar cargando con la otra la máquina con el riesgo de sufrir algún incidente (por ejemplo tirarla... bueno, tal vez este ejemplo sea un poco exagerado). Para evitar cualquier tipo de percance y para evitarnos la incomodidad de cargar con una mano y escribir con la otra, llega para complacer a todo tipo de usuario el Connect-A-Desk, un soporte para cargar la computadora portátil. Fácil de transportar, de utilizar, de ponerse y quitarse; además es un artículo en pro de la ecología al estar fabricado con plástico 100% reciclado, ergonómicamente diseñado, ajustable a cualquier estatura de persona, puede utilizarse con cualquier tamaño de laptop, notebook o tablet; no importa en dónde te encuentres o si estás caminando o sentado en la sala de espera. Compuesto por una base y un par de soportes que van al hombro, este producto llega para alivianar la carga de una herramienta de trabajo, que se ha vuelto popular en este tiempo: la laptop.

Sony VAIO

Mouse Talk

SE2 Labs

ITC One Los diseñadores industriales e ingenieros muestran su talento a través de este diseño compacto de mouse óptico de doble funcionalidad, es además un teléfono vía Internet. Como mouse, ofrece una resolución de 800 dpi y con un peso de 67 gramos, además de ser un teléfono para VOIP que puede ser utilizado con Skype; tiene un led indicador que se enciende, a manera de alerta, cuando entra una llamada. Con tan sólo presionar un botón, el mouse se abre para ponerlo en modo teléfono. Es ideal para laptop y ahorra espacio en la oficina, el hogar o mientras se está en los ahora restaurantes y cafeterías con servicio de WiFi. ¡Ah! y también está disponible en color blanco.

AGO-OCT 2008

Para los amantes de la tecnología, ha llegado la navaja suiza de los gadgets. Así es, SE2 Labs ha hecho posible el sueño electrónico de muchos y saca el ITC One, que ensambla lo más solicitado en el mercado del consumidor de tecnología. Con un procesador de sonido THX y 125 watts, un controlador Netlinx todo puede ejecutarse sin dificultades desde un control remoto. Bajo el concepto de Hi-Def, está elaborado con DVR y una pantalla touchscreen en el frente. ¿Complicado?, no, incluye un Apple iPod y un Xbox 360 (con sus respectivos puertos de control) que lo hace estándar, si eso no es suficiente se puede escoger opcionalmente un player Blu-ray, una AppleTV o un Nintendo Wii. www.sg.com.mx

INDEX

DIRECTORIO

Anunciante Adecco Avantare CIAPEM Compusoluciones Cutter e-Quallity Gartner IDC IT Institute Manpower Milestone Consulting Prodata Safe Net SIE Center

Pรกginas 2F, 1 43 15 63 3F 13 37 61 57 47 4F 11 7 9

Sitio www.adecco.com.mx www.avantare.com www.guerrero.gob.mx/ciapem2008 www.compusoluciones.com www.cutter.com.mx/summit2008 www.e-quallity.net www.gartner.com/mx/econit www.idc-eventos.com www.it-institute.org www.manpowerprofessional.com.mx www.milestone.com.mx www.prodataconsult.com.mx www.safenet-inc.com ciisa.gda.itesm.mx

TENEMOS UN ESPACIO RESERVADO PARA TI Si deseas anunciarte contรกctanos en el (55) 5239 5502 o en ventas@softwareguru.com.mx www.sg.com.mx

AGO-OCT 2008

// cOMUNIDADES

¿Cómo se Organiza la Comunidad? Coordinación de Esfuerzos en Grupos de Desarrollo e Integración de Software Libre Por Gunnar Wolf

Acercarse a comprender el funcionamiento y la organización de las tareas dentro de las comunidades de desarrollo de software libre es una tarea bastante complicada ante quien se acerca con curiosidad, proveniente del mundo del software propietario, desarrollado e integrado centralmente y dentro de compañías que operan como “cajas negras”. Sin exponer sus procesos, sin ofrecer a los clientes una ventana a cada uno de los momentos de su proceso de desarrollo. Comprender cómo funcionan las comunidades de Software Libre es una gran oportunidad para entender las distintas metodologías de ingeniería de procesos, en entornos donde todas las metodologías formales simplemente no tienen cómo ser aplicadas. El ejemplo que aquí se muestra se centra en el trabajo que realizo en el grupo de empaquetamiento de módulos de Perl (pkg-perl) para la distribución Debian GNU/Linux. Retomando el concepto de que Perl es un lenguaje de programación muy popular, especialmente para las tareas de administración de sistemas y de desarrollo de sitios Web, y uno de sus más importantes recursos es el CPAN (Comprehensive Perl Archive Network), una enorme biblioteca de módulos nacida en octubre de 1996, y que a febrero del 2008 cuenta con más de 13,000 módulos independientes. CPAN ofrece a sus usuarios, además, herramientas para el desarrollo y seguimiento colaborativo, un sistema de seguimiento de fallos y un sistema de organización, búsqueda y consulta de la documentación de dichos módulos. El proyecto Debian, por su parte, es la distribución de software libre, hoy por hoy, más grande del mundo, con más de 15,000 paquetes fuente independientes. Su propósito es presentar una colección coherente, consistente y con un elevado nivel de control de calidad. El reto del grupo pkg-perl es empaquetar (de una manera consistente con las políticas de Debian) y dar seguimiento a los fallos que vayan apareciendo en dichos paquetes. Debian ofrece a sus usuarios un sistema de seguimiento de fallos centralizado a través del cual pueden comunicarse directamente con los “mantenedores” de cada uno de los programas. Son ellos los responsables de determinar,

para cada fallo, si cae en el ámbito de la consistencia del sistema Debian (y por tanto debe ser corregido directamente por ellos) o si es relativo a la lógica de uno de los paquetes (en cuyo caso debe ser corregido en coordinación con el autor de dicho programa, para que la corrección “fluya” hacia las otras distribuciones que lo integran y, en general, hacia todos sus usuarios). Hasta hace unos cuatro años, la norma en Debian era que cada mantenedor fuera responsable exclusivo de los paquetes que le interesaran. En 2003 nació el sistema Alioth, basado en GForge, y ofreciendo de una manera centralizada las herramientas necesarias para un verdadero desarrollo colaborativo, se comenzaron a configurar grupos amplios de mantenimiento de infraestructura. Uno de los primeros en aparecer, ante la iniciativa de Joachim Breitner, fue pkg-perl. El eje fundamental en torno al cual gira el trabajo del grupo es el depósito Subversion, donde mantenemos sobre un esquema de manejo de versiones todos nuestros paquetes, programas y documentos, así como los cambios independientes que vamos realizando sobre de ellos. Los módulos del CPAN ofrecen varias ventajas para su mantenimiento masivo colaborativo. A diferencia de lo que ocurre en muchos lenguajes, casi la totalidad de los módulos están basados en una estructura de compilación ampliamente conocida (ExtUtils::MakeMaker o Module::Build). Esto permitió la creación de dh-make-perl, un script bastante genérico cuyo objetivo original era simplificar la creación de paquetes Debian directamente a partir del CPAN para ser instalados localmente por los administradores, pero que fue extendido por el grupo pkg-perl para automatizar la creación de paquetes. Si bien formalmente el grupo pkg-perl cuenta con 70 miembros, en todo momento hay aproximadamente 15 miembros activos. Actualmente, el grupo es responsable por 660 paquetes en las siguientes actividades: • Responsable el dar seguimiento a los fallos reportados • Mantenerlos al día (tanto respecto a nuevas versiones producidas por sus autores como respecto a las políticas en Debian, que van cambiando poco a poco reflejando la evolución del proyecto)

Gunnar Wolf ha sido usuario y promotor de Software Libre en México por más de diez años. Es fundador del Congreso Nacional de Software Libre (CONSOL) y miembro externo del Departamento de Seguridad de Cómputo en la UNAM. Participa como desarrollador en el proyecto Debian desde el 2003. Trabaja como administrador de red y en el desarrollo de sistemas para el Instituto de Investigaciones Económicas de la UNAM.

AGO-OCT 2008

www.sg.com.mx

“Comprender cómo funcionan las Comunidades de Software Libre es una gran oportunidad para entender las distintas metodologías de ingeniería de procesos”.

• Realizar operaciones transversales de control de calidad a través de todos los paquetes, y demás Para simplificar la coordinación de todas estas tareas, los integrantes del grupo (especialmente Martín Ferrari, de Argentina, Gregor Hermann, de Austria, y Damyan Ivanov, de Bulgaria) hemos creado un script que tiene las siguientes funciones: • Comparar el estado de los módulos en CPAN Comparar los paquetes en el depósito • Subversion • Comparar los reportes en el sistema de seguimiento de Debian, y los paquetes publicados en la distribución misma de Debian Hoy en día, este script es nuestra principal herramienta, brindándonos un reporte de estado condensado y adecuado específicamente a nuestro flujo de trabajo. Y tan útil resulta este resumen que actualmente estamos adecuando este script para que lo utilicen también otros grupos con un enfoque similar; probablemente para cuando este artículo esté impreso, lo están utilizando ya los grupos de empaquetamiento de Python y Java, habiendo varios más en el horizonte.

Conclusión El ejemplo que aquí se presenta es sólo uno de tantos, pero es ilustrativo. Bajo el modelo del software libre, las barreras entre desarrollo e integración se desvanecen, y el contacto directo entre usuario final y los desarrolladores deja de ser una rara ocurrencia, y se vuelve la norma, algo que damos por supuesto en todo momento de nuestros desarrollos.

Referencias [ debian.org ] [ perl.com ] [ cpan.org ] [ rt.cpan.org ] [ search.cpan.org ] [ pkg-perl.alioth.debian.org ] [ bugs.debian.org ] [ alioth.debian.org ] [ svn.debian.org/wsvn/pkg-perl ] [ pkg-perl.alioth.debian.org/cgi-bin/qareport.cgi ]

www.sg.com.mx

AGO-OCT 2008

// BIBLIOTECA

Ajax on Rails Scott Raymond O’Reilly, 2007

Las nuevas tendencias del desarrollo para web nos invitan al aprendizaje de herramientas de vanguardia, pero cuando un par de estas se combinan para trabajar, entonces se crea la mancuerna perfecta. Como ejemplo tenemos este libro. El lector aprenderá a construir aplicaciones web dinámicas utilizando dos de las herramientas más importantes de desarrollo actual: Ajax y Ruby on Rails. A través de sus páginas, conocerá cómo combinar ambas tecnologías para construir rápidamente aplicaciones con alto tiempo de procesamiento y escalabilidad. Los capítulos del libro no solamente incluyen una introducción a los conceptos de Ajax y Rails, además incluye la explicación y uso de Prototype, framework de JavaScript que permite el fácil desarrollo de aplicaciones web dinámicas. Para hacer una mejor mancuerna con Prototype, incluye un capítulo dedicado a uno de los add-on’s de este framework: script.aculo.us, en el que se enseña el uso de las características de la biblioteca que corresponden a la plataforma Rails.

Es importante mencionar que el autor no olvidó hablar de puntos importantes para el desarrollo de una aplicación como son las pruebas, detección de errores, seguridad y tiempo de ejecución. Dedicando por separado un espacio para cada uno de ellos, el autor habla sobre los principios de seguridad de las aplicaciones web, así como las estrategias de estudio del “performance”. En la sección de tiempo de ejecución incluye temas como: optimización de sesiones, tiempo de respuesta en las peticiones a Rails, reducción en la comunicación entre JavaScript, CSS y Ajax y la utilización de Ajax para mostrar el progreso de una tarea del usuario.

Inside Windows Communication Foundation Justin Smith Microsoft Press, 2007

Para los interesados en WCF con conocimientos previos en el mismo, llega este libro para profundizar más en el tema. Con la finalidad de dejarle los mejores conceptos al lector, el autor trata en la primera parte una introducción para enseñar el por qué del concepto además de mostrar las metas del mismo. En la segunda parte del libro, podemos encontrar conceptos más propios de Windows Communication Foundation como los mensajes, los canales y los administradores de canales para terminar con una tercera parte que trata sobre la capa del ServiceModel.

AGO-OCT 2008

A través de sus 10 capítulos el lector puede apreciar el por qué y el cómo de WCF, ya que el libro muestra el balance entre la cobertura del modelo y los conceptos que deben ser considerados dentro de las aplicaciones de WCF. Este libro brinda al lector, un vistazo dentro de Windows Communication Foundation para facilitar el diseño, construcción, pruebas y mantenimiento de las aplicaciones.

www.sg.com.mx

No. 21

www.sg.com.mx

SG SOFTWARE GURU - CONOCIMIENTO EN PRﾃ，TICA

Agosto-Octubre 2008