SG25 (Agosto-Octubre 2009)

• Software as a Service • Líneas de Productos de Software • Bases de Datos Columnares

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

[ ENTREVISTAS ]

Scott Hanselman Molly Holzschlag Luke Hohmann Key Speakers SG'09

Desarrollo

ÁGIL

México, $65.00

Noticias • Eventos • Lo que viene • Fundamentos • Carrera • UML • Gadgets

[ Tutorial ] Django

// CONTENIDO

directorio Dirección Editorial Pedro Galván Dirección de Operaciones Mara Ruvalcaba Coordinación Editorial Alejandro Escamilla

Editorial

Arte y Diseño Dafne Ortega, Oscar Samano Redacción y Estilo Susana Tamayo Consejo Editorial Jorge Valdés - PMI; Luis Cuellar - Softtek; Luis D. Soto - Microsoft; Hanna Oktaba - UNAM; Ralf Eder, Raúl Trejo - ITESM; Luis Vinicio León - e-Quallity

Hace tres años que publicamos un número dedicado a los métodos ágiles.

En ese entonces, el objetivo principal era evangelizar sobre este tema del que muchos habían oído pero pocos habían puesto en práctica. En ese entonces, para la mayoría de los consultores su experiencia con métodos ágiles consistía en conocer el manifiesto ágil y tal vez haber leído algún libro de eXtreme Programming.

Tres años después el escenario de los métodos ágiles ha cambiado significativamente.

Han dejado de ser una corriente de nicho y comenzamos a encontrarlos en todo tipo de organizaciones. Sin embargo, con este crecimiento en su adopción, surgen nuevos retos: ¿cómo podemos combinar los métodos ágiles con modelos de proceso formales?, ¿cómo podemos llevar los métodos ágiles más allá de proyectos individuales y aplicarlos a nivel de programas y portafolios de proyectos?, ¿cómo se relacionan los métodos ágiles y los métodos esbeltos?

Básicamente, estamos llevando los métodos ágiles al mundo real. Esperamos que el contenido que hemos reunido al respecto les sea de gran utilidad.

Otro tema de gran interés es el de la industria del software como servicio (SaaS).

Consideramos que SaaS representa una

02

AGO-OCT 2009

oportunidad con gran potencial para las pequeñas empresas de software en nuestra región. Nos hemos aventurado a investigar al respecto y presentar un análisis sobre este segmento de mercado.

En este número le damos la bienvenida a nuestra nueva columnista, Gloria Quintanilla. Seguramente recordarán que la entrevistamos en la edición de Julio-Agosto 2006. Gloria se estará enfocando en temas relacionados con el gobierno corporativo de TI, que sabemos que es un tema de gran interés para muchos de ustedes. ¡Bienvenida, Gloria!

La edición de este año de SG Conferencia y Expo ya está a la vuelta de la esquina.

Hemos aprovechado el acceso que tenemos a los conferencistas magistrales para poder realizar pequeñas entrevistas con ellos y compartir contigo la perspectiva de estas personas que están en la punta de la industria de software. Todos ellos son personas muy accesibles e interesados en convivir con los profesionistas de software en nuestra región. Así que si asistes a SG ‘09 no dudes en acercarte a ellos. ¡Nos vemos en SG ‘09! » Equipo Editorial

Colaboradores Gloria Quintanilla, Gunnar Wolf, Julio Acuña, Masa K. Maeda, Adalberto González, Tomas Björkholm, Omar Soto, Harvey Alférez, Victor González, Gilberto Grajales, Jaime González, Angelica Larios, Guillermo Morales, Emilio Osorio, Scott Ambler.

Ventas Claudia Perea Marketing y RP Paulina Olivares Circulación y Administración Edgar Dorantes Desarrollo Web Nathanael Gutiérrez Contacto info@sg.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 agosto de 2009 en Preprensa Digital. Distribuido por Sepomex.

www.sg.com.mx

contenido ago - oct 2009

26

EN PORTADA Métodos ágiles y esbeltos Conoce cómo puedes aplicar Lean y Agile en tu organización.

26

Productos LO QUE VIENE 10 Fusion Middleware 11g, BlueRuby, Silverlight 3 y Semantic Web Builder TUTORIAL 12 DJango, el framework para perfeccionistas con tiempos límite

Especial Columnas Tejiendo Nuestra Red por Hanna Oktaba

06

Programar es un Modo de Vida 54 por Gunnar Wolf

Mejora Continua por Luis Cuellar

08

Tendencias en Software por Luis Daniel Soto

56

Tierra Libre por Emilio Osorio

41

Entregando Valor por Gloria Quintanilla

58

Prueba de Software por Luis Vinicio León

52

La Oportunidad de SaaS 16 para Empresas de Software en México

Prácticas GESTIÓN DE DATOS Base de datos columnares

42

El nuevo paradigma para ambientes de Data Warehousing

MEJORA DE PROCESOS Líneas de producto de software

En Cada Número Noticias y Eventos

04

GADGETS

62

FUNDAMENTOS

60

CARRERA

64

44

Aplicando adaptación masiva al desarrollo de software

UML Entre la parálisis por análisis y la necesidad de modelar

48

¿Qué tanto y hasta donde se debe modelar?

22 Perfiles

PM CORNER Dirección ágil de proyectos

50

El impacto de los métodos ágiles en la disciplina de dirección de proyectos.

Scott Hanselman Molly Holzschlang Luke Hohmann

www.sg.com.mx

AGO-OCT 2009

03

// NOTICIAS

IBM Rational Software Conference 2009 El pasado mes de junio se realizó el IBM Rational Software Conference 2009, en la ciudad de Orlando, Florida; evento enfocado en promover las mejores prácticas y beneficios de utilizar herramientas Rational. Bajo la primicia de que debemos generar productos más inteligentes, en un mundo que cada vez es más inteligente, el congreso combinó la participación tanto de desarrolladores de software, como de usuarios de negocio; enfatizando el involucramiento de estos últimos en el proceso de desarrollo de software, como elemento clave para lograr resultados de valor al negocio.

Arquitectura empresarial, gestión de requerimientos, modelado, y gestión de cambios, fueron algunos de los temas que conformaron una agenda de más de 300 sesiones.

Simposio AMITI 2009 El pasado 9 de julio, en la Ciudad de México, se celebró el Simposio AMITI 2009; foro de análisis y discusión que reunió a líderes y expertos de la industria de Tecnologías de Información, con el objetivo de desarrollar iniciativas que permitan crear un Proyecto País fundamentado en el aprovechamiento de las TI. A diferencia de años anteriores, el formato de este año permitió la ejecución de talleres de discusión entre los distintos representantes de la industria: empresarios de TI, usuarios, gobierno, academia, cámaras, asociaciones, medios de comunicación, empresas de análisis; que como resultado generaron una propuesta viable, con recomendaciones específicas sobre cómo apoyar la competitividad del país mediante el uso de las TI.

Gartner Enterprise Integration Summit Del 23 al 24 de junio, se realizó en la Ciudad de México la Cumbre de Integración Empresarial de Gartner. Durante el evento, diferentes analistas de Gartner compartieron su visión sobre temas como modernización de las TI, arquitectura empresarial, SOA, BPM, servicios web y cómputo en la nube. Este último tema fue de gran interés por parte de los asistentes, haciendo ver que las organizaciones de TI en nuestra región ya están buscando caminos y estrategias para subirse a la nube.

La cumbre estuvo integrada por tres series de 18 sesiones agrupadas por tema, contando con una audiencia formada por directivos de TI, gerentes de desarrollo y arquitectos.

04

AGO-OCT 2009

www.sg.com.mx

// EVENTOs

12 al 14 de agosto 2009

27 al 30 de septiembre 2009

IPN- ESCOM CFIE Zacatenco, Ciudad de México.

Info: bugcon.org Contacto: David Araujo 5729 6000 ext. 52038

Congreso de Software de Nuevo León CINTERMEX, Monterrey.

Info: www.sg.com.mx/sg09 Contacto: sg09@sg.com.mx

BugCON Security Conference

1 al 3 de septiembre 2009

12th Gartner Anual Conference The Future of IT Centro Banamex, Ciudad de México.

Info: www.gartner.com/it/page.jsp?id=806912 Contacto: latin.america@gartner.com

SG ‘09 Conferencia y Expo

15 al 18 de octubre 2009

XXX Convención Nacional Anual CANIETI Hotel Fairmont Pierre Marques, Acapulco.

Info: www.canieti.org.mx Contacto: eventos@canieti.com.mx

21 y 22 de octubre 2009

6a. Semana Regional PyMe Monterrey 2009

X Encuentro Iberoamericano de Ciudades Digitales

8 al 10 de septiembre 2009

28 al 30 de octubre 2009

Hotel Presidente Intercontinental, Monterrey.

Info: www.imt.com.mx Contacto: contactforum@imt.com.mx

Cutter Consortium Hotel Marriott, Ciudad de México.

Info: www.cutter.com.mx Contacto: agalindo@cutter.com.mx

7 al 11 de septiembre 2009

CAINTRA CINTERMEX, Monterrey.

Info: http://www.semanapymemonterrey.org.mx Contacto: info@semanapymemonterrey.org.mx

8 Contact Forum Congreso Internacional Mty 2009

Gobierno del Estado de Veracruz World Trade Center, Veracruz.

Info: www.ciudades.gob.mx Contacto: econtreras@veracruz.gob.mx

Cutter Summit América Latina

Directores de TI

Super Happy Dev House

Del 10 al 12 de junio, la ANIEI presentó la XVIII Reunión Nacional de Directores de Escuelas y Facultades de Informática y Computación, teniendo como sede Nuevo Vayarta, Nayarit, y como anfitrión a la Universidad Autónoma de Nayarit. La reunión se centró en las tendencias de la educación en las TI, y entre los temas más relevantes se presentó el proyecto “Talento en TI”, proyecto que desarrolla modelos paracurriculares para las carreras de TI. Una de las principales problemáticas es la baja en la matrícula de dichas carreras, por lo que se realizaron talleres con el objetivo de revisar cómo hacerlas más atractivas.

El pasado 25 de julio se realizó en las instalaciones de Prosoftware la novena edición del Super Happy Dev House (SHDH) de la Ciudad de México. ¿Y qué es un SHDH? Básicamente es una reunión para desarrolladores donde cada quién lleva su computadora para trabajar todo un día. Cualquier persona puede pegarse a otro proyecto para colaborar, aprender y divertirse. En palabras de @boxbyte: “SHDH es la onda, es como un salón de clases con amigos computines que hablan el mismo código secreto.” Los SHDH nacieron en Silicon Valley, pero hoy en día se encuentran en todo el mundo. Si todavía no hay uno en tu ciudad, ¿qué esperas para organizarlo?

Empresas evaluadas en modelos de calidad De acuerdo al Sistema Nacional de Indicadores de la Industria de TI (SNIITI), hasta el momento se han registrado 138 empresas evaluadas en algún proceso de calidad. Para mayor información visita: edigital.economia.gob.mx/sniiti. Entre las empresas recientemente evaluadas destacan: Empresa Evaluación Fecha Lead Appraiser Ultrasist

CMMI N5 v1.2

marzo 2009 Jose Luis Iparraguirre Azertia (Indra Sistemas)

CMMI N3 v1.2

junio 2009 Jose Alfredo Calvo

www.sg.com.mx

AGO-OCT 2009

05

// COLUMNA

/*TEJIENDO NUESTRA RED*/

Picando Piedra: Segunda Parte Recordando a las personas que aportaron su granito de arena para elevar la calidad del software mexicano 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.

E

mpiezo la segunda parte de mis recuerdos, por corregir algunos datos de la entrega anterior. Mariana Pérez-Vargas me recordó que el nombre correcto de la primera empresa evaluada en México en SW-CMM es Tecnosys, que no fue nivel 2 sino 3.

También me pidió que mencionara, lo que fue mi omisión imperdonable, a José Cabrera como uno de los pioneros en introducir temas de calidad en Banamex y colaborador en Círculo de Calidad y en la AMCIS.

-Fue el año en que empezamos a contar en México con los primeros instructores certificados de PSP y posteriormente de TSP. Aquí me sucedió una cosa curiosa: cuando intenté corroborar con Luis Castro quién fue el primero en PSP, me aseguró que fue Carlos Montes de Oca y por su parte, Carlos me aseguró que el primero fue Luis.

Bueno, no importa, a este par se les sumaron Alfredo Calvo y Ricardo Vidrio, quienes desde hace varios años están difundiendo estas prácticas en México.

El recuento de lo sucedido en los últimos años no siempre tiene una fecha exacta, son esfuerzos de muchos años, por eso a veces la fecha sirve sólo para tener una referencia.

2002 -Secretaría de Economía empieza a organizar mesas de trabajo para definir lo que hoy se conoce como programa PROSOFT. Fue un esfuerzo de vital importancia para que la industria de software en México empezara a organizarse y tener un plan a corto y mediano plazo. Los fondos PROSOFT fueron creados para sostener dicho programa. Muchas personas aportaron sus ideas para la creación de PROSOFT, aquí menciono solamente a los funcionarios de la SE de esa época: Sergio Carrera, Jesús Orta y Claudia Ivette García, que tuvieron un papel decisivo.

1997 - hasta la fecha La comunidad académica empezó a organizar Talleres de Ingeniería de Software, que últimamente se convirtieron en un Simposio asociado al Encuentro Internacional de Computación (ENC) de la Sociedad Mexicana en Ciencia de la Computación.

Estos eventos se utilizan principalmente para intercambiar la información sobre las prácticas educativas y proyectos de tesis a nivel de maestría.

2000 -Inicia el doctorado en Ciencias de la Computación en Centro de Investigación y de Educación Superior de Ensenada (CICESE) , que complementa la maestría creada en 1994. Jesús Favela empieza a formar los primeros doctores en Ingeniería de Software, como es el caso de Guillermo Licea Sandoval. Mientras tanto, Josefina Rodríguez Jacobo dedica sus esfuerzos a nivel maestría preocupándose por aspectos humanos en Ingeniería de Software.

-En el CIMAT, Carlos Montes de Oca con Miguel Serrano y otros investigadores, crean la Maestría en Ingeniería de Software que basa su plan de estudios en el Master of Software Engineering de la Universidad de Carnegie Mellon. Hasta la fecha se reportan dos generaciones de ésta. CIMAT también cuenta con el programa de doctorado donde Carlos es el tutor.

-Angeles Sumano y Juan Manuel Fernández, ambos doctores en Ingeniería de Software por el Centro de Investigación en Computación, inician la Especialización en Ingeniería de Software en la Universidad Veracruzana, Xalapa, que en 2006 se convierte en maestría.

06 16

AGO-OCT 2009

-Uno de los primeros proyectos de PROSOFT, fue la creación del modelo de procesos para la industria de software MoProSoft. Tuve la enorme suerte de dirigir este proyecto en el cual se reunió un gran equipo: Claudia Alquicira (Ultrasist), Angélica Su (Itera), Alfonso Martínez (UAM-I), Gloria Quintanilla (Itera), Mara Ruvalcaba (Software Guru), Francisco López Lira (PPHS), María Julia Orozco Mendoza (Ultrasist), Yolanda Fernández Ordóñez (Colegio de Posgraduados), María Elena Rivera (¿?), y Miguel Ángel Flores Lemus (¿?). En paréntesis indico la organización donde laboran actualmente.

-A partir de este año empezamos a contar con los primeros evaluadores mexicanos reconocidos por el SEI: Alfredo Calvo (SW-CMM, CMMI), Cecilia Montero (SW-CMM), Mariana Pérez-Vargas (SW-CMM,CMMI), Enrique Pérez (CMMI) y Miguel Serrano (CMMI de alta madurez).

2003 -EvalProSoft fue el segundo proyecto que coordiné para definir el método de evaluación para MoProSoft. En este proyecto participaron: Claudia Alquicira (Ultrasist), Angélica Su (Itera), Carlos Pérez (Avantare), Jorge Palacios (JPE Consultores), Francisco López Lira (PPHS), Gloria Quintanilla (Itera), Cecilia Montero (independiente) y Alfredo Calvo (Itera). www.sg.com.mx

“ Uno de los primeros proyectos de PROSOFT, fue la creación del modelo de procesos para la industria de software MoProSoft ”.

2004 -Escribiendo para Software Guru no puedo olvidar mencionar la fecha de la creación de esta revista por Mara Ruvalcaba y Pedro Galván. Hoy en día no es sólo una revista, sino también un sitio web lleno de información e ideas. Gracias a SG la industria ha tenido, por ejemplo: acceso a las primeras encuestas sobre salarios y herramientas, así como a congresos de muy alto nivel.

González, Blanca Gil, Juan Manuel Hernández y su servidora, para poder atender dos reuniones anualmente y coordinar la edición de las partes 4 y 5 de lo que el año próximo se convertirá en el estándar internacional conocido como: ISO/IEC 29110 Software Engineering — Lifecycle Profiles for Very Small Entities (VSEs). En este estándar, MoProSoft se venderá en “comodas mensualidades” como una serie de perfiles llamados: Básico, Intermedio y Avanzado.

-Se crea la primera licenciatura de Ingeniería de Software en la Universidad Autónoma de Yucatán. Sus fundadores son Carlos Mojica, Fernando Curi Quintal y Francisco Madera, bajo la asesoría del Dr. Fernando Naveda del Rochester Institute of Technology, un mexicano pionero en este tipo de carreras.

Para concluir este recorrido, quiero mencionar algunas empresas mexicanas de la industria de software y sus líderes en aspectos de calidad, que a mi juicio han sido pioneros en adoptar buenas prácticas de diversos modelos para su beneficio:

-Fue el año de pruebas controladas de MoProSoft y EvalProSoft en cuatro empresas. Nuevamente me tocó coordinar el proyecto en el cual participaron: Claudia Alquicira (Ultrasist), Angélica Su (Itera), Francisco López Lira (PPH), Jorge Palacios (JPE Consultores), Ana Vázquez (mamá de Miranda) y Claudia Gutiérrez (Praxis). Durante el proyecto se capacitaron ocho consultores en formación de diversos estados de la República, entre ellos Claudia González (Kernel).

2005 Bajo la coordinación de Ernesto Martínez del subcomité de Software del NYCE se genera la norma mexicana NMX-I-059-NYCE-2005 Tecnología de la Información-Software-Modelos de procesos y de evaluación para desarrollo y mantenimiento de software, basada en MoProSoft y EvalProSoft. Su edición estuvo a cargo de su servidora y de Claudia Alquicira. Para darle soporte a la norma, NYCE crea un organismo Verificador en el cual Juan Manuel Hernández tiene el papel preponderante.

2006-2008 Maria Julia Orozco, Claudia Alquicira y su servidora picamos piedra en Iberoamérica con el proyecto de COMPETISOFT, dándole la difusión a la norma mexicana basada en MoProSoft. Como resultado, Perú ya adoptó la norma mexicana como suya; mientras que Argentina, Uruguay y Colombia están probando la versión publicada en el libro COMPETISOFT para ver si lo incorporan en sus países.

2006 Desde este año también empezamos a picar piedra a nivel internacional a través del WG24 ISO/IEC JTC1 SC7. Aquí abrieron brecha Ana Vázquez y Jorge Palacios para que la norma mexicana fuera la base para norma internacional. A este grupo se han sumado Claudia www.sg.com.mx

Softtek con Blanca Treviño y mi vecino de columna Luis Cuellar, por ser la más grande empresa mexicana con expansión mundial y por basar su éxito en CMMI entre otras prácticas.

Praxis con Edmundo Robert y Elsa Ramírez, por ser una empresa en constante crecimiento basado en la adopción de las prácticas provenientes de PMI y CMMI. Ultrasist con Guadalupe Quijano, Maria Julia Orozco, Evaristo Fernández y Claudia Alquicira, por ser una PyME que se ha mantenido y crecido en el mercado desde hace 15 años gracias a la adopción sistemática basada en objetivos de negocio de las prácticas de Orientación a Objetos, Modelado de Negocio, MoProSoft y CMMI. Es la primera empresa mexicana evaluada en CMMI 1.2 nivel 5.

QuarkSoft con los hermanos César y Carlos Montes de Oca, y Ricardo Vidrio, por tomar muy en serio las bondades de PSP, TSP y CMMI lo que les está redituando no solamente en el negocio, sino también en reconocimiento internacional como la Empresa más Innovadora ganadora del Premio Dell - American Express Corporate Card 2008.

Magnabyte con Oscar Flores, fundada en 2001, fue la que participó con mayor éxito en las pruebas controladas de MoProSoft en 2004 y es la primera en obtener en 2006 un certificado de NYCE por alcanzar el Nivel 2 en la norma mexicana: NMX-I-059/02-NYCE-2005.

Por el momento es todo lo que mi memoria y mis contactos me permitieron rescatar. Arnoldo Díaz ya me puso el apodo de Wilma. ¿Adivinen por qué?

» Por Hanna Oktaba AGO-OCT 2009

17 07

// COLUMNA

/*MEJORA CONTINUA*/

Planeación del Cambio Organizacional Plan vs. Estrategia 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.

“L

a principal razón por la que una implantación de CMM nivel 5 falla, es porque el área de procesos se comporta como una compañía de nivel 1”. Ésta fue la temática de un grupo de pláticas del SEI a las que asistí hace unos años. El mensaje es claro: ¿Cómo puede una área implementar mejores prácticas si no puede seguir las mismas?

Semejante realidad no sólo aplica a CMMi sino a cualquier esfuerzo de mejora. Si voy a cambiar mi organización, debo tener un plan de cómo lo voy a lograr, darle seguimiento al mismo, tener métricas claras, procesos definidos y demás. Últimamente he pensado mucho sobre esta problemática, así que dedicaré una serie de entregas de esta columna a compartir algunas ideas que tengo al respecto.

Comencemos por el principio, el primer problema que surge al definir una estrategia de cambio organizacional, tiene que ver con la planeación. Veamos qué podemos hacer al respecto.

Planeando la estrategia El primer problema al hacer un plan para generar un cambio, tiene que ver con lo que consideramos que es un plan. El plan que la mayoría de nosotros conocemos es el plan de proyecto. La problemática básica de la administración de proyectos es cómo coordinamos una serie de actividades ejecutadas en forma independiente por un grupo de personas, en una secuencia específica lo más rápido y barato posible. En este contexto, las gráficas de Gantt y el manejo de ruta crítica tienen mucho sentido.

En el caso de un proyecto de cambio, la problemática tiene mucho más que ver con una estrategia de ventas que con un plan de actividades. Las preguntas son diferentes: ¿cuál es nuestro objetivo?, ¿cómo lo comunicamos?, ¿quiénes son las personas

08

AGO-OCT 2009

críticas y cómo los convencemos para que nos apoyen?, ¿donde iniciamos para obtener la mayor cantidad de beneficios lo antes posible? Aquí la planeación se enfoca más en la estrategia a seguir, que en la secuencia de actividades. Por lo tanto las herramientas de planeación que necesitamos tienen que ver con cómo administrar una visión, misión y metas; cómo analizar la actitud, disponibilidad y posibilidades de los protagonistas; segmentación del problema, etcétera.

Visión, misión y metas A nivel corporativo, estos términos han pasado un poco de moda, y al menos yo ya no los escucho tanto. Sin embargo, para un área de administración de cambio son indispensables.

Existen varias analogías que dejan ver la importancia de una clara visión, misión y metas. Mi favorita compara un proyecto de cambio organizacional con cruzar un río caudaloso. Por más que todos los involucrados se hayan puesto de acuerdo, el proceso de cambio es turbulento y por naturaleza habrá circunstancias que constantemente tratarán de sacarnos de rumbo hasta que nos lleve la corriente. La visión, misión y metas son como tener una cuerda amarrada del otro lado. No importa lo caudaloso del río, si nos sujetamos fuerte, la cuerda nos ayudará a mantener el rumbo deseado. ¿Cómo definimos la visión, misión y objetivos de nuestra estrategia? Lo ideal es que participen todos los involucrados críticos al cambio. El primer diálogo debe enfocarse en definir cuál es la visión que tenemos, hacia dónde queremos llegar, cuál es la misión de las diferentes áreas dentro de esa visión y cuáles son los principales objetivos a cumplir.

Existen diferentes ideas sobre el nivel de generalidad, lo amplio y lo alcanzable o inalcanzable de estos puntos. Yo soy de la idea de que se necesita algo práctico. La visión debe ser deseable, concisa y lo más específica posible. Queremos algo, por lo que estemos dispuestos a trabajar para lograr en toda la organización. La misión en este contexto la podemos ver como el rol que juegan las diferentes áreas involucradas en el cambio. Debe ser clara y concisa, sin vaguedades. Finalmente, las metas nos ayudan a definir qué es lo primero en lo que nos vamos a enfocar, cuáles serían los hitos dentro de lo que buscamos. Lo anterior es importante porque nos da una idea de por dónde movernos, pero no puede estar tallado en piedra. Nuestro ciclo debe de ser flexible, dependiendo de lo que aprendemos, en lo que se ha logrado y lo que no se ha logrado.

Modelos ágiles de mejora Un plan de cambio es más parecido a un plan iterativo que a un plan de cascada.

El ciclo de calidad compuesto por las cuatro fases: Planea, Haz, Revisa y Actúa, no es más que un modelo iterativo de desarrollo. La visión y misión te dan la foto completa de hacia dónde quieres llegar, pero necesitas metas parciales que sirvan de base para generar las historias de usuario que nos indiquen a dónde vamos primero. Al final de cada iteración evaluamos qué ha funcionado y qué no ha funcionado, para continuar con nuestra siguientes iteración.

Se nos acabo el espacio por lo que en el siguiente artículo continuaremos con los que yo considero una de las principales herramientas para planear cambio: el análisis de involucrados críticos. Nos vemos pronto. » Por Luis Cuellar www.sg.com.mx

www.sg.com.mx

AGO-OCT 2009

09

// PRODUCTOS

/* LO QUE VIENE*/

Silverlight 3 Semantic Web Builder

Sigue mejorando

Web semántica al alcance de todos

El Centro Público de Innovación y Desarrollo Tecnológico Infotec liberó Semantic Web Builder. Esta nueva generación del sistema de gestión de contenidos Web Builder destaca en cuanto a sus capacidades como plataforma para aplicaciones semánticas.

Para impulsar la adopción y aprovechamiento de Semantic Web Builder, Infotec está promoviendo la creación de un ecosistema de empresas y centros de investigación que participen tanto en el desarrollo y evolución del producto, como en la educación e integración de servicios para la implantación en proyectos específicos. Esto puede significar una oportunidad importante para las empresas locales de desarrollo de software y servicios de TI. Semantic Web Builder está disponible como software libre bajo una licencia similar a LGPL. Más información en semanticwebbuilder.org

Cuando todavía no terminábamos de acomodarnos con Silverlight 2, Microsoft ya ha lanzado la versión 3.

Sin embargo no hay porque asustarse, en realidad esta versión es más una mejora sobre la versión 2 (digamos un 2.1), que algo completamente nuevo que requiera mucho aprendizaje.

Entre las mejoras introducidas en Silverlight 3 destacan las siguientes: • Soporte “fuera del navegador” que permite ejecutar aplicaciones web en el desktop • Nuevos componentes para graficación de datos.

• Mejoras en el motor de gráficos incluyendo soporte a gráficos 3D • Mejoras en el soporte para formatos de audio y video de alta resolución Junto con Silverlight 3, Microsoft hizo disponible un plugin gratuito para Visual Studio 2008 denominado “VS 2008 Tools for Silverlight” que facilita el desarrollo y depuración de aplicaciones Silverlight desde Visual Studio.

Mayor información en silverlight.net

Fusion Middleware 11g Oracle con un toque de BEA

BlueRuby Ruby + ABAP

Oracle liberó la versión 11g del Fusion Middleware. Esta versión es la realización de la visión de Oracle de incorporar lo mejor de la tecnología que adquirió de BEA Systems en una plataforma integrada de middleware. Es así que Fusion Middleware 11g brinda nuevas versiones de Coherence, Enterprise Manager, JDeveloper, JRockit y WebLogic Server. Junto con esta versión también se liberó la versión 11g de la plataforma para portales empresariales WebCenter Suite.

La intención de Oracle es que Fusion sirva de base para su próxima generación de aplicaciones empresariales que reemplazará a productos como Oracle Applications, PeopleSoft y Siebel. Se espera que en el OpenWorld de 2009 Oracle de a conocer una visión más completa sobre el futuro de su oferta de aplicaciones empresariales.

Más información en oracle.com/products/middleware

10

AGO-OCT 2009

De los laboratorios de SAP nos llegan noticias sobre un proyecto experimental denominado BlueRuby. La intención de este proyecto es crear una ambiente para poder ejecutar aplicaciones Ruby sobre la máquina virtual de ABAP. En lugar de simplemente permitir la ejecución de programas Ruby de forma aislada en el contenedor de ABAP, BlueRuby busca proveer interacción bidireccional con los componentes del ambiente ABAP. Es decir, los programas de ABAP podrán invocar código Ruby y los programas de Ruby podrán acceder funcionalidad de ABAP. Más información en wiki.sdn.sap.com/wiki/display/Research/BlueRuby

www.sg.com.mx

www.sg.com.mx

AGO-OCT 2009

11

// PRODUCTOS

/*TUTORIAL*/

Django El framework para perfeccionistas con tiempos límite por Julio Acuña

Django Reinhardt es considerado uno de los mejores guitarristas de todos los tiempos. Tuvo un accidente que lo dejó con dos dedos paralizados, sin embargo con sólo dos dedos podía tocar mejor que muchos y hacer música simplemente maravillosa. Django también es el nombre de un framework para desarrollo web escrito en Python, con el que podemos tener sitios web funcionando en muy poco tiempo; el código simple y elegante de las aplicaciones web hechas con Django nos hace recordar la música de Reinhardt.

Originalmente Django fue creado para funcionar en un ambiente periodístico donde los tiempos límite son cruciales para una publicación periódica, así que los desarrolladores tuvieron que adaptarse al ritmo de los reporteros y editores para poder sacar el contenido a tiempo en el sitio web del periódico. Adrian Holovaty, Simon Willison y Jacob Kaplan-Moss son el equipo de desarrolladores detrás de Django. En el 2005 después de asistir al PyCon, decidieron liberar el código de Django bajo licencia BSD y ahora muchos voluntarios ayudan en su desarrollo.

mente la creación de proyectos y aplicaciones. Durante la instalación django-admin.py debió ser copiado en algún lugar donde pueda ser invocado (por ejemplo en /usr/local/bin/ en sistemas Linux) así que desde la línea de comandos tecleamos: $django-admin.py startproject prueba

Esto creará el directorio “prueba” y copiará a él varios archivos que nos ayudarán en la creación de nuestras aplicaciones. El directorio contendrá los archivos: __init__.py, manage.py, settings.py, y urls.py.

A partir de este momento ya podemos visualizar nuestro sitio web. A estas alturas solo veremos la página default, pero es buen ejercicio validar que funciona. Corremos el servidor de desarrollo de Django con el comando: $python manage.py runserver

y abrimos nuestro navegador en http://localhost:8000 Django sigue el modelo MVC (Model View Controller - Modelo Vista Controlador), bueno realmente es MTV (Model Template View - Modelo Plantilla Vista ), separando la programación del diseño con lo que podemos tener trabajando en paralelo a programadores y diseñadores, ahorrando mucho tiempo. Esto también permite cambiar en cualquier momento el diseño del sitio sin preocuparse porque la aplicación pueda resultar dañada. La arquitectura de Django también se apega al principio DRY (Don’t Repeat Yourself - No te repitas a ti mismo), de tal forma que si se tiene que realizar un cambio en la aplicación, éste se haga solamente en un lugar, en vez de estarlo replicando por toda la aplicación.

Para empezar a desarrollar nuestra aplicación web necesitamos Python (versión 2.3 a 2.6), algún manejador de base de datos (sqlite3, PostgreSQL, MySQL, Oracle), el adaptador para el manejador de base de datos correspondiente (pysqlite[3], psycopg, MySQLdb, cx_Oracle), un servidor web (Apache, cherokee, lighttp ) y finalmente Django. Los detalles de la instalación pueden consultarse en el sitio oficial del proyecto.

Creando nuestro proyecto Django incluye el script django-admin.py que facilita significativa-

Configuración de la base de datos Django puede usarse con distintos manejadores de base de datos y oficialmente soporta PostgreSQL, MySQL, Oracle y SQLite. También es posible usarlo con otros manejadores como SQL Server, DB2 y Sybase, pero es posible que la funcionalidad que se pueda obtener no sea la misma que con los manejadores soportados oficialmente.

Si tienes disponible algún servidor de base de datos, solo es cuestión de que edites el archivo de configuración settings.py indicando la información correspondiente. Por ejemplo, para utilizar una base de datos en PostgreSQL en localhost, simplemente habría que indicar: DATABASE_ENGINE = ‘postgresql_psycopg2’ DATABASE_USER = ‘[nombre del usuario para conexión]’ DATABASE_PASSWORD = ‘[contraseña]’

Obviamente, la base de datos debe tener ese usuario creado y estar configurada para aceptar conexiones.

Eso es todo lo que tenemos que hacer con respecto a la base de datos.

Julio Acuña estudió en la Facultad de Química de la UNAM y es un apasionado del software libre. Ha trabajado tanto en el gobierno como en la iniciativa privada y ha participado en varios congresos de software libre a nivel nacional impartiendo conferencias y talleres. Julio es colaborador y editor de revista-sl.org

12

AGO-OCT 2009

www.sg.com.mx

“Django se encargará de crear las tablas y generar las sentencias SQL gracias a su Object-Relational Mapper (ORM)”.

Django se encargará de crear las tablas y generar las sentencias SQL gracias a su Object-Relational Mapper (ORM). Nosotros no tendremos que meternos con SQL a menos que quisieramos realizar alguna sentencia específica que no se pueda manejar por medio del ORM.

‘django.contrib.contenttypes’, ‘django.contrib.sessions’, ‘django.contrib.sites’, ‘prueba.blog’, ‘django.contrib.admin’, )

Creando nuestra aplicación de blogs Ya que tenemos creado y configurado nuestro proyecto y base de datos, podemos crear nuestra aplicación. Vamos a crear una aplicación llamada “blogs” que será un manejador de blogs.

Para crear las tablas en la base de datos que correspondan al modelo que definimos, basta con que invoquemos el comando: $python manage.py syncdb

$django-admin.py startapp blog

Aquí empieza lo divertido. Vamos a definir nuestro modelos de datos.

Para esto abrimos models.py en cualquier editor de texto y agregamos lo siguiente: class Post(models.Model): title = models.CharField(max_length=50) date = models.DateTimeField(‘published on’) body = models.TextField(‘Body’, blank=True)

Como podrán imaginar, definimos el modelo o entidad de información “Post” con los atributos title, date y body.

Uno de los elementos más poderosos de Django es la interfaz de administración automática. Esta se encarga de leer los metadatos de nuestro modelo y automáticamente provee una interfaz a través de la cual se puede agregar información a nuestra aplicación. Para habilitar la manipulación de información de nuestros modelos desde la interfaz de administración de Django debemos registrar nuestras clases en un archivo llamado admin.py. Creamos este archivo dentro del directorio de nuestra aplicación y le agregamos lo siguiente: from prueba.blog.models import Post from django.contrib import admin admin.site.register(Post)

Con esto habilitamos la interfaz de administración para la clase Post.

Ahora vamos a modificar una vez mas nuestro archivo settings.py para agregar la aplicación que hemos creado y habilitar la aplicación de administración. Abrimos el archivo settings.py y buscamos la sección de INSTALLED_APPS, agregando ‘prueba.blog’ y ‘django.contrib.admin’. Esta sección deber quedar así: INSTALLED_APPS = ( ‘django.contrib.auth’,

www.sg.com.mx

De manera instantánea ya tenemos nuestro esquema en la base de datos y nos pregunta si queremos definir un superusuario, elegimos que sí. Si tienes curiosidad, puedes conectarte a tu base de datos y verificar que se hayan creado las tablas correspondientes. Si esto no sucedió, verifica que hayas indicado correctamente los datos de conexión a la BD en settings.py y que el usuario tenga privilegios para crear bases de datos y tablas.

Diseñando urls Diseñar urls tal vez no sea lo más divertido del mundo, pero las ventajas de tener urls bonitas permite a los usuarios encontrar las páginas más fácilmente y a los buscadores la indexación. El diseño de urls se hace a través de expresiones regulares que se indican en el archivo urls.py. Encontramos este archivo y lo editamos para que contenga lo siguiente: from django.conf.urls.defaults import * from django.contrib import admin admin.autodiscover() urlpatterns = patterns(‘’, (r‘^admin/(.*)’, admin.site.root), (r‘^blog/’, include(‘prueba.blog.urls’)), )

Lo que hicimos con esto fue indicar que el patrón de urls admin/* apuntan a la interfaz de administración, mientras que los urls debajo de blog/ serán manejados por el archivo urls.py que está dentro del directorio prueba/blogs.

Así que ahora debemos crear el archivo urls.py dentro del directorio blog y agregarle el siguiente código: from django.conf.urls.defaults import * urlpatterns = patterns(‘’, (r‘^$’, ‘blog.views.front’),

)

AGO-OCT 2009

13

// PRODUCTOS

/*tutorial*/

Views y templates Las vistas (views) son funciones que reciben peticiones y devuelven respuestas de cualquier tipo, como puede ser HTML, XML, imágenes, PDF, etc. En la configuración de nuestros urls en blogs/urls.py definimos que cuando se acceda /blog/ debemos invocar una vista llamada “front”. Vamos entonces a definir esta vista en blog/views.py. Lo que queremos es que despliegue los últimos 5 posts: from django.shortcuts import render_to_response from django.http import HttpResponseRedirect from models import Post def front(request): entries = Post.objects.all().order_by(‘-date’)[:5] return render_to_response(“blog.html”, dict(entries=entries))

A continuación tenemos que crear nuestros templates, uno para el sitio en general y otro para nuestro blog. Vamos a crear un directorio ‘templates’ dentro de nuestro directorio prueba para almacenar estos archivos. Creemos el archivo templates/base.html con el siguiente código:

{% extends “base.html” %} {% block title %}Mi Blog{% endblock %} {% block content %} <h2>Entradas Recientes</h2> {% for entry in entries %} <h3>{{entry.title}}</h3> <h4>{{entry.date|date:”j/n/Y H:i”}}</h4> {{entry.body}} {% endfor %} {% endblock %}

Por supuesto que para que Django sepa dónde encontrar nuestros templates tenemos que indicarle la ruta. Esto lo hacemos en settings.py TEMPLATE_DIRS = ( “/home/usuario/django_projects/prueba/templates” )

Probando nuestro blog

<html> <head> <title>Mi Sitio</title> <meta http-equiv=”content-type” content=”text/html; charset=utf-8” /> </head>

Para comprobar que todo marche bien corremos el servidor de desarrollo de Django

<body> <div id=”content”> {% block content %} {% endblock %} </div>

al ir a http://localhost:8000/admin ya podemos acceder la aplicación de administración de Django con el nombre de usuario y contraseña que asignamos al crear el administrador. Incluso podremos registrar nuevos posts ahi. ¿Pero cómo sucede eso si no hemos definido ninguna forma para capturar posts? Precisamente eso es lo que hace la interfaz de administración automática. En base a los tipos de datos de nuestra entidad Post, nos ha generado automáticamente una forma para dar de alta instancias de esta entidad.

</body> </html>

En este template podremos añadir más adelante hojas de estilo o JavaScript para que luzca mejor. Incluso podemos crear una aplicación AJAX ligando la aplicación con la vista y utilizando una de las tantas bibliotecas que existen como jQuery, Mochikit, Dojo o Prototype, por mencionar algunas.

Django tiene su propio lenguaje de templates, fijémonos en los bloques {% %} dentro de los cuales podemos manipular el comportamiento de nuestra vista por medio de comandos como for o if. El lenguaje de templates es limitado y se debe utilizar únicamente para mostrar el contenido que se desea presentar al usuario (capa de presentación) y no para la lógica de negocio.

El siguiente template es el homepage de nuestro blog. Por medio del comando ‘extends’ podemos reutilizar el template base.html para no volver a escribir el mismo html y solo agregar el comportamiento

14

específico para este caso. Creemos entonces el archivo templates/ blog.html con el siguiente código:

AGO-OCT 2009

$python manage.py runserver

En http://localhost:8000/blog vemos el homepage de nuestro blog como habíamos indicado en urls.py.

Formas Desde la interfaz de administración de Django podemos manejar nuestros sitios, crear usuarios, modificar permisos y agregar contenido. Pero se hace necesario agregar formularios personalizados desde los cuales los usuarios puedan agregar contenido, hacer consultas o simplemente ponerse en contacto con nosotros. Para todo esto podemos echar mano de la biblioteca incluida en Django y ahorrarnos bastante trabajo al generar los formularios automáticamente.

Comenzamos creando un archivo forms.py dentro del directorio de nuestra aplicación que contenga lo siguiente:

www.sg.com.mx

from django import forms from django.forms import ModelForm from models import * class PostForm(ModelForm): title = forms.CharField(max_length=50, label=’Título’) date = forms.DateTimeField(required=True, help_text = ‘mm/dd/aaaa 24:00’) label = ‘Fecha y hora’ body = forms.CharField(widget=forms.Textarea) class Meta: model = Post

Ahora vamos a modificar blog/urls.py para definir un patrón que apunte al formulario de registro: urlpatterns = patterns(‘’, (r‘^$’, ‘blog.views.front’), (r‘newpost/’, ‘blog.views.main’),

) Luego editamos views.py para registrar este formulario en la función main (que es la que definimos en urls.py): from django.shortcuts import render_to_response from django.http import HttpResponseRedirect from models import Post from forms import PostForm def front(request): entries = Post.objects.all().order_by(‘-date’)[:5] return render_to_response(“blog.html”, dict(entries=entries)) def main(request): if request.method == ‘POST’: form = PostForm(request.POST) if form.is_valid: form.save() return HttpResponseRedirect(‘/blog’) else: form = PostForm() return render_to_response(‘main.html’, { form:‘form’})

Creamos el template main.html que solo requiere tener lo siguiente: {% extends base.html %} {% block content %} <form action=“/blog/newpost/” method=“post”> <h3>Nueva entrada</h3> {{ form.as_p }} <input type=”submit”, value=”Guardar”> </form> {% endblock %}

www.sg.com.mx

Lo último que faltaría sería modificar nuestro template blog.html para agregar una hiperliga que apunte a la forma de registro: <p><a href=“/blog/newpost/”>Agregar entrada</a></p>

Con esto ya tenemos un formulario para registrar nuevos Posts, que es accesible por el usuario. Podemos probar nuevamente nuestra aplicación y verificar que así sea.

Conclusión Como pudieron apreciar, la creación de aplicaciones web con Django es muy rápida y sencilla. Claro que este ejemplo es muy simple y muchas de las características de este framework no se pudieron ver aquí como lo son las formas en detalle y su validación, o las pruebas unitarias. Sin embargo espero haber dado un buen vistazo a este gran framework que ha ganado merecidamente su reputación dentro de la comunidad pythonista y fuera de ella por su rapidez y eficiencia frente a otros frameworks de desarrollo web.

* Los archivos con el código fuente que se utilizaron para este tutorial estarán disponibles para descarga en la versión online de este artículo en el sitio web de SG.

Referencias [1] Sitio oficial de Django www.djangoproject.com [2] Libro sobre Django con licencia libre www.djangobook.com [3] Django en español www.django.es

AGO-OCT 2009

15

La Oportunidad SaaS para Empresas de Software Mexicanas ¿Estás listo para la acción?

Por Pedro Galván

E

l esquema de Software as a Service (SaaS) se está convirtiendo en una alternativa atractiva para desarrollar productos de software y lanzarlos al mercado. Bajo este paradigma, las aplicaciones son instaladas, hospedadas, ejecutadas y actualizadas en centros de datos externos, de tal forma que los usuarios simplemente deben conectarse por Internet para utilizarlas.

El mercado de SaaS está creciendo a un ritmo impresionante. Gartner estima que el mercado actual de SaaS es de poco más de 6 billones de dolares que equivalen a un 6% del mercado total de software, pero que para el 2012 tendrá un tamaño cercano a los 20 billones de dólares, representando un 25% del mercado total de software.

Por sus características y potencial, el segmento de SaaS plantea una oportunidad muy viable y atractiva para las empresas desarrolladores de software en México y América Latina. Quienes mayor provecho pueden sacar de ofrecer aplicaciones y servicios bajo este esquema son aquellas pequeñas empresas que cuentan con capacidad técnica y de ejecución de proyectos, pero que carecen de la infraestructura y capital para competir en el mercado tradicional de soluciones de software. A través de una operación por Internet, los proveedores de software pueden tener clientes en cualquier lugar en el mundo sin necesidad de contar con una fuerza de ventas distribuida internacionalmente. Adicionalmente, el tamaño del mercado global se convierte en una herramienta para atraer capital de inversión hacia estas empresas.

Los empresarios de la industria de software en México tienen la obligación de considerar seriamente la incursión en el segmento de SaaS; al corto plazo por la gran oportunidad de crecimiento y rentabi-

16

AGO-OCT 2009

lidad que representa, y al largo plazo porque eventualmente este será el paradigma de facto para la adquisición y entrega de software. Es decir que aquellas empresas que no tengan la capacidad de desarrollar y entregar software como servicio, quedarán fuera de la industria o relegadas a nichos muy pequeños.

y la otra a organizaciones de TI. La figura 1 ilustra dicha clasificación.

Clasificación de infraestructura y aplicaciones SaaS

La oferta para usuarios finales está dividida en dos segmentos: • Servicios para consumidor. Servicios tipo web 2.0 dirigidos a personas individuales. Su modelo de negocio típicamente está basado en publicidad. Ejemplos populares de esta categoría son: Flickr, Facebook, last.fm y Grooveshark.

• Aplicaciones para empresas. Aquí se consideran aplicaciones web dirigidas a usuarios empresariales. Su modelo de negocio típicamente está basado en un esquema de renta o pago por uso. En este segmento podemos considerar servicios como: Basecamp, Manymoon o SugarCRM (en su versión hospedada).

La clasificación de la oferta SaaS que considero más adecuada es la que propone Forrester en el reporte “Future View: The New Tech Ecosystem of Cloud, Cloud Services and Cloud Computing”. En dicho reporte se argumenta que la oferta de SaaS y cloud computing (que son usados como sinónimos) está formada por cinco mercados distintos, los cuales se agrupan en dos categorías: una dirigida a usuarios finales

A nivel técnico, ambos segmentos son muy similares, ya que ambos tipos de servicio se desarrollan y entregan de la misma forma. Sin embargo, lo que difiere es el modelo de negocio y por ello Forrester insiste en que son dos mercados diferentes. Por otro lado, cada vez nos encontramos con más servicios que ofrecen una modalidad gratuita y otra versión de paga con algunos extras en cuanto a la

Este artículo está dividido en dos partes: primero presentamos un análisis sobre la oferta actual de SaaS con la intención de que el lector detecte oportunidades para incursionar, y posteriormente presentamos una lista de puntos a considerar al desarrollar una oferta SaaS.

Figura 1. Clasificación de la oferta SaaS

www.sg.com.mx

funcionalidad y nivel de servicio. Este modelo híbrido es conocido como “Fremium”.

La oferta SaaS para organizaciones de TI está dirigida a atender las necesidades de las personas y organizaciones que desean desarrollar y entregar sus propias aplicaciones bajo un esquema de cómputo en la nube. Es así que podemos distinguir los siguientes tres segmentos de mercado SaaS dirigidos a organizaciones de TI:

• Componentes aplicativos como servicio.

Componentes accesibles como servicio web que los desarrolladores utilizan para ensamblar o complementar sus propias aplicaciones web. Un ejemplo común es el de los servicios de mapeo tales como Google Maps y Yahoo! Maps. Un ejemplo dirigido al segmento empresarial es el de Avalara, que provee componentes para el cálculo de impuestos que los desarrolladores pueden integrar dentro de sus aplicaciones web empresariales.

• Plataforma como servicio (PaaS). No todas las aplicaciones de cómputo en la nube podrán ser ensambladas como mashups a partir de componentes existentes. En muchos casos se requiere desarrollar apoyándose en algún middleware que provea servicios como el de una base de datos, por ejemplo. La plataforma Azure de Microsoft, que incluye elementos como .NET Services o SQL Azure, cae en este segmento.

• Infraestructura virtual como servicio.

También conocido como “hardware como servicio” (HaaS), este segmento se refiere a la oferta de servicios de infraestructura de www.sg.com.mx

cómputo y almacenamiento en la nube. Tal vez el ejemplo más conocido sea el Amazon Elastic Compute Cloud.

Teniendo en cuenta esta clasificación de la oferta SaaS, cada lector podrá identificar donde considera que puede incursionar y armar una oferta competitiva y sustentable. Mi opinión personal es que para las empresas desarrolladoras de software en países en vías de desarrollo como México y América Latina lo que tiene más sentido es enfocarse en el segmento de aplicaciones para empresas, y componentes aplicativos como servicio.

En el caso del segmento de servicios para consumidores, hay que tener en cuenta que aún no hay un modelo de negocio exitoso.

Incluso servicios tan populares como Twitter y Facebook todavía están buscando un modelo rentable; encontrarlo es una gran oportunidad. Por otro lado, en el segmento de aplicaciones para empresas hay modelos de negocio más claros y sustentables. Este segmento de aplicaciones para empresas requiere enfocarse en nichos muy específicos, pero esto no es problema en cuanto al tamaño de mercado. Recordemos que al hablar de SaaS el mundo es nuestro mercado, así que un nicho por muy específico que sea puede tener decenas de miles de clientes.

Considero que la incursión en estos segmentos requiere de cantidades significativas de capital (tanto para desarrollar como para lanzar y sostener el servicio) y vinculación con agentes clave que habiliten al start-up a

cumplir su potencial. Estos dos elementos, capital de riesgo y vinculación, no se encuentran en cualquier lugar; por algo Silicon Valley es Silicon Valley. Mi recomendación para las empresas que deseen incursionar en los servicios web para consumidores es apoyarse en alguna incubadora o aceleradora de negocios globales, como es el caso de TechBA para empresas mexicanas, que les sirva de plataforma para acercarlos con agentes clave de capital de riesgo y vinculación.

Los segmentos de infraestructura como servicio y plataforma como servicio están destinados para las grandes empresas de tecnología que tienen acceso a grandes cantidades de capital, así como infraestructura de cómputo y telecomunicaciones de primer nivel a bajo costo. Supongo que estarán de acuerdo conmigo en que este es un segmento en el que las empresas de nuestra región difícilmente podrán competir.

Antes de cerrar esta sección, quiero poner sobre la mesa la oportunidad que tienen los gobiernos en nuestros países de fomentar soluciones SaaS al permitir la interacción con sus sistemas por medio de servicios web con APIs abiertos. Imaginemos que fuera posible desarrollar componentes aplicativos como servicio que realizaran acciones como registrar o actualizar personal en el IMSS, o pagar impuestos.

Esta estrategia ha sido bautizada como “Gobierrno como Plataforma” y representa una gran oportunidad de innovación para las empresas de software, y mejora de servicio para los ciudadanos.

AGO-OCT 2009

17

Recomendaciones para desarrollar oferta SaaS Hemos analizado los mercados de SaaS y reconocido donde puede haber oportunidades para nuestras empresas. El siguiente paso podría ser sentarnos a desarrollar una oferta SaaS para nuestra empresa. Pero antes de hacerlo, considero prudente revisar algunas recomendaciones que nos ayuden a mejorar la probabilidad de éxito de nuestra oferta SaaS. El blog “Chaotic Flow” (chaotic-flow.com) es una excelente fuente de información y perspectivas sobre el negocio de SaaS. El autor, Joel York, publicó un documento titulado “The Top Ten Do’s and Dont’s of SaaS”. Algunas de las recomendaciones dadas ahí pueden aplicar más al segmento de servicios para consumidor, y no tanto al de servicios para empresas, pero aun así considero que es buena lectura y les ayudará a mejorar sus ideas.

A continuación comparto las diez recomendaciones principales de Joel York al crear una oferta SaaS:

1. Escoge un mercado grande. No escribas una sola línea de código hasta que tengas idea del tamaño de tu mercado potencial y estés seguro de que valga la pena.

2. Crea un espacio central en la Web. Crea un espacio útil en el web y atrae a tus usuarios (reales y potenciales) hacia él.

3. Acelera el crecimiento orgánico. SaaS involucra un paradigma donde los clientes compran (pull) a diferencia de uno donde la empresa vende (push). El personal de ventas y marketing debe actuar más como catalizadores que como vendedores, deben estimular la demanda y facilitar la compra por medio de la comprensión del comportamiento natural de sus clientes.

4. Desarrolla una historia convincente. Recuerda que los clientes no compran productos, compran historias.

5. Incorpora el negocio dentro del producto.

A diferencia del modelo tradicional de software donde entregas un producto de software (por ejemplo un CD) y no sabes qué sucede con él una vez que es comprado, SaaS permite que tu producto esté directamente con tus clientes, y directamente con tus sistemas internos. Reconsidera tus procesos de negocio teniendo esto en cuenta.

6. Piensa más allá del firewall. SaaS abre oportunidades para que la comunicación e interacción no se quede solo dentro de una organización. Considera las oportunidades para interactuar con los agentes externos a tu organización tales como clientes, prospectos, prospectos de tus clientes, aliados y clientes de tus aliados.

7. Monetiza creativamente. No te cierres al esquema tradicional de cobrar por el acceso a tu software. Considera otras posibilidades

como publicidad, comisiones por referencia, pago basado en niveles de servicio, etcétera.

8. Habilita la personalización masiva. Tus clientes tendrán necesidades únicas. Una oferta exitosa de SaaS permite que sus clientes puedan usarlo de distintas formas y adaptarlo a sus necesidades sin necesidad de que el proveedor tenga que hacer algo a la medida.

9. Ábrete a la nube. Así como debes tender la mano hacia el Web para atraer clientes, también debes tender la mano hacia otras aplicaciones en el Web que complementen tu oferta, porque tu producto no se podrá mantener por sí solo. ¿Tu oferta SaaS es amigable con la nube? ¿Cuentas con un mecanismo abierto y basado en estándares para interactuar con otras aplicaciones en la nube?

10. Desarrolla y aprovecha a tu comunidad.

Una comunidad de usuarios satisfecha es tu mejor fuerza de ventas.

La versión completa del documento de Joel York se puede descargar gratuitamente. Se los recomiendo ampliamente.

Conclusión SaaS representa una gran oportunidad para las empresas desarrolladoras de software en países como México. Hay que tener en cuenta que no existe un solo mercado de SaaS, sino distintos mercados dirigidos tanto a usuarios finales como a organizaciones de TI, y cada uno tiene sus oportunidades y retos.

Las empresas que deseen desarrollar una oferta SaaS deben analizar cual es el segmento donde tienen mayor probabilidad de éxito y diseñar una estrategia consistente.

Referencias [1] Frank E. Gillet. “Future View: The New Tech Ecosystems Of Cloud, Cloud Services, And Cloud Computing”. Forrester Research, Agosto 2008.

[2] Joel York, “The Top Ten Dos and Don’ts of SaaS”. www.saas-business.com [3] Natán Saad-Lipshitz. “Trends and perspectives in the Development of Software as a Service (SaaS) Products”. Reporte preparado para TechBA.

18

AGO-OCT 2009

www.sg.com.mx

www.sg.com.mx

AGO-OCT 2009

19

AGO-OCT 2009

www.sg.com.mx

www.sg.com.mx

AGO-OCT 2009

// perfiles

Perfiles de SG09 Tenemos en puerta SG09 Conferencia y Expo, el congreso anual realizado por SG Software Guru, ahora presentado por el Consejo de Software de Nuevo León, y hemos aprovechado la oportunidad para hablar con algunos de los conferencistas magistrales. Te presentamos a Scott Hanselman, Molly Holzschlag y Luke Hohmann.

Scott Hanselman Scott Hanselman es Gerente de Programa para Desarrolladores en Microsoft. Sus actividades consisten principalmente en diseminar información sobre mejores prácticas y tecnologías para desarrollar software. Sus especialidades incluyen el diseño de interfaces humanas y arquitectura de aplicaciones de gran escala. Scott es coautor de diversos libros tales como: “Professional ASP.NET MVC 1.0”, “Professional ASP.NET 3.5”, y “Code Leader”. ¿Consideras que hay demasiados frameworks para aplicaciones web?

Realmente no creo que sean tantos. Desde mi punto de vista están ASP.NET, Django, Java, Rails y luego el resto. Creo que así como nunca habrá un solo idioma hablado (inglés vs. español) tampoco habrá solo un framework para aplicaciones web. Siempre habrá alguien que piense que puede hacer algo mejor, y eso es bueno.

¿A qué te dedicas en Microsoft?

Mi trabajo consiste en manejar la comunidad online para Microsoft Developer Tools. Esto significa encontrar las mejores maneras de conectarme con la comunidad de desarrolladores y asegurarme de que están obteniendo lo que necesitan. Por ejemplo: ¿están encontrando respuestas a sus preguntas?, ¿hay buenos contenidos (videos, blogs, cursos, artículos, etc) para que aprendan?, ¿la comunidad se encuentra saludable y activa?, ¿están habilitados para poder hacer más? ¿Qué habilidad consideras más importante para un desarrollador de software?

Creo que la habilidad más importante es la comunicación. Puedes ser el mejor programador del mundo pero si no puedes hacerte entender, entonces no sirve de nada.

28 22

AGO-OCT 2009

¿Que pueden hacer las universidades para preparar al tipo de ingenieros de software que necesita la industria?

Tengo experiencia como maestro, y considero que los recién graduados de universidad salen sin el suficiente conocimiento de los aspectos básicos. Me refiero a temas como direccionamiento de memoria, funcionamiento de sistemas operativos, funcionamiento de compiladores, recolección de basura, etc. Hay quienes ni siquiera saben como convertir un número hexadecimal a decimal sin una calculadora. ¿Qué le recomendarías a los estudiantes próximos a graduarse?

Mi principal consejo es que busquen obtener experiencia. Para esto les recomiendo involucrarse en un proyecto de software libre y contribuir código. El objetivo es que cuando se gradúen ya hayan trabajado en por lo menos un proyecto

real. También es buena idea que escriban un blog para practicar sus habilidades de comunicación escrita. ¿Qué tendencia en la industria de software actualmente te emociona más?

Posiblemente la tendencia hacia la simplificación e interoperabilidad que nos llevará a la portabilidad de datos (data portability).

El poder usar HTTP, JSON y/o XML para fácilmente llevar los datos de un lugar a otro (o de una aplicación a otra) abre muchas posibilidades. Sin embargo, la pregunta es: ¿nos dejarán las empresas (por ejemplo Facebook) tener acceso y control sobre nuestros propios datos?

Tal parece que pronto veremos avances significativos en el campo de las interfaces entre humanos y computadoras. ¿Qué opinas al respecto?

Creo que el siguiente gran paso es masificar el reconocimiento de movimientos.

En principio será con hardware especializado, y eventualmente podremos hacerlo con webcams tradicionales. El escenario de uso que yo visualizo es similar a lo que hacía Tom Cruise en la película “Minority Report”. Seguramente los lectores de SG están enterados del proyecto Natal de Xbox para reconocer movimiento por medio de cámaras. Creo que si Natal es exitoso, entonces todo cambiará. www.sg.com.mx

Molly Holzschlag Molly es una autora y evangelista altamente reconocida en el campo de estándares web. A lo largo de más de 15 años se ha dedicado a educar diseñadores y desarrolladores web sobre el uso y aprovechamiento de tecnologías para crear espacios en el web que sean atractivos, usables y sustentables. Actualmente labora como Evangelista para Opera Software, además de mantenerse activa como escritora de libros y consultora independiente

¿Es cierto que eres una busca problemas?

Yo resuelvo problemas, pero eso le crea problemas a las personas que se reusan a aceptar que hay un problema. ¿Por qué es importante la web abierta?

La tecnología juega un rol importante en cómo usamos y distribuimos los recursos globales. Para mí, la web abierta es una visión donde las personas y empresas de la industria son abiertos en cuanto a su comunicación, son justos en la forma en la que trabajan, comparten información sobre sus tecnologías, y hacen todo lo posible para que todo el mundo se beneficie de la tecnología, y no solo unos cuantos. En mi utopía, las necesidades sociales y humanas serían consideradas antes que la ganancia económica de las empresas. ¿Los estándares promueven o restringen la innovación?

Eso depende de a qué te refieras con estándar.

Los estándares en el web realmente no son estándares, son recomendaciones. A excepción del caso de las leyes de accesibilidad, no hay una obligación de seguir algún estándar. En mi opinión, mientras haya menos restricciones es mejor. La web se debe mantener democrática.

Por otro lado, un “estándar” sobre cómo hacer las cosas correctamente y de acuerdo a cierta especificación puede ser muy poderoso. Necesitamos ese tipo de lineamientos para el www.sg.com.mx

web, al menos por ahora para estabilizar la plataforma y asegurar que haya estándares abiertos y tecnologías que sean poderosas, seguras, de bajo costo, y que funcionen correctamente a través de las diferentes plataformas y dispositivos. Después de todo, esa es la visión del web. Y esa visión frecuentemente es opacada por empresas a las que solo les interesa obtener ganancias económicas al corto plazo y desestiman los beneficios a largo plazo para la humanidad. ¿Qué opinas sobre las tecnologías RIA como Flash, Silverlight y JavaFX? Los estándares abiertos son importantes debido a tecnologías como estas. Todos ellos tienen méritos y fallas. Así es la vida. Yo me pronuncio por la libertad de elección, quedar atrapado bajo la tecnología de un proveedor rara vez es benéfico.

Pero nos guste o no, HTML 5 ya se está implementando. Y como siempre lo he dicho, lo que está implementado vence a lo que está especificado. ¿A qué se debe el fracaso de XHTML? Principalmente a la falta de soporte en uno de los navegadores más populares para manejar correctamente el tipo MIME de XML. Pero también se debe a que no había una guía clara de lo que “extensible” realmente significaba. ¿Poder crear tu propio DTD? A mi me atrae la idea, pero es algo que no fue comprendido a nivel general.

¿Qué pasa con HTML 5? ¿Por qué debería importarnos?

Mi respuesta sincera es que no tengo idea de lo que HTML 5 será, ya que todavía se encuentra en cambio constante.

Por favor define en pocas palabras lo que piensas sobre los siguientes navegadores ...

Internet Explorer -> Adelantado a su tiempo hasta que se quedó atrás Firefox -> Los desarrolladores logran lo que quieren con extensiones Opera -> ¡Solucionamos problemas!

Chrome -> Siempre me han gustado los autos veloces Safari -> Si lo llamas “WebKit” me sentiré mejor

Personalmente a mi me gustaba más la visión de XHTML, sin embargo ésta ha perdido inercia (W3C detuvo el grupo de desarrollo para XHTML 2). La intención de que los navegadores manejen XHTML como XML estricto ha sido abandonada, lo cual es una lástima porque creo que hubiera abierto muchas posibilidades.

¿Algunas palabras para nuestros lectores?

Simplemente que hagan lo posible por asistir a la conferencia, y que no sean tímidos y se me acerquen. Me gusta mucho conocer personas. Sé suficiente español como para meterme en problemas, ¡así que vamos a hablar!

AGO-OCT 2009

23

// perfiles

Luke Hohmann Luke es fundador y CEO de Enthiosys Inc, empresa dedicada a crear ambientes donde las personas puedan maximizar sus habilidades creativas e intelectuales. Luke es autor de los libros: “Innovation games: Creating breakthrough products through collaborative play”, “Journey of the software professional: The sociology of software development”, y “Beyond software architecture”.

¿Qué son los juegos de innovación?

Son juegos serios que originalmente diseñamos para ayudar a los equipos que desarrollan nuevos productos a entender mejor a sus clientes. Sin embargo, conforme han pasado los años su aplicación se ha extendido a otros dominios. Por ejemplo, hay gerentes de desarrollo de software que utilizan los juegos para mejorar sus procesos de software. También hay áreas de RH que los utilizan para entrenar empleados para entender mejor a sus clientes.

empleadores rastrear nuestro desempeño. Y aunque tuviéramos eso, las estadísticas solamente toman en cuenta una pequeña porción de lo que hace la persona, ya que no dicen nada sobre su actitud, su capacidad de trabajo en equipo, y su empuje. También entran en juego las fuerzas de mercado externas; puedes pensar que mereces un mejor salario pero tu jefe puede pensar que no eres mejor que otras personas que están disponibles en el mercado laboral por un salario menor o igual al tuyo.

¿Qué se requiere para ser un desarrollador de software “completo”?

Un desarrollador de software completo es capaz de manejar tres dominios muy complejos. El primero es la competencia técnica. El segundo es la capacidad de entender el negocio y cómo es que el software que él desarrolla aporta valor al negocio. Finalmente, un desarrollador de software completo sabe trabajar con los diferentes involucrados y clientes para continuamente satisfacer los requerimientos cambiantes del mercado.

En resumen, creo que la respuesta consiste en encontrar formas de demostrar que estás entregando mayor valor, pero prepárate porque puede ser una tarea complicada. Habiendo dicho eso, lo que recomiendo es pedir ese aumento, y si la respuesta es negativa, entonces convierte esa respuesta en una conversación que te ayude a saber qué necesitas hacer para conseguir ese aumento.

¿Qué le recomendarías a un desarrollador que quiere un aumento de sueldo?

Me gustaría decir que es tan sencillo como encontrar formas de demostrar que estás entregando más valor por tu salario que otros recursos disponibles. Sin embargo, no es tan sencillo. A diferencia de los atletas profesionales por ejemplo, carecemos de estadísticas que le permitan a nuestros

24

AGO-OCT 2009

Llevas más de 15 años rastreando la sociología del desarrollo de software. ¿Ha cambiado durante este tiempo?

En un nivel básico no ha cambiado, simplemente porque las personas no hemos cambiado mucho en varios miles de años. Pero si nos vamos a los detalles, la sociología del desarrollo de software ha cambiado dramáticamente en estos años principalmente debido a que ahora es común tener equipos globalmente distribuidos. Adicionalmente, se ha incrementado significativamente la

práctica de métodos ágiles, lo cual habilita a los equipos para trabajar con mayor eficiencia y enfoque.

Los métodos ágiles nacieron en el desarrollo de software pero han ampliado su alcance a otros contextos. ¿Puedes darnos tu opinión al respecto?

Ver el crecimiento de Agile es uno de los aspectos que más he disfrutado durante la última década. Cuando Enthiosys comenzó dando consultoría sobre métodos ágiles en el 2003, nuestros clientes eran principalmente empresas desarrolladoras de software. Hoy en día atendemos todo tipo de organizaciones, desde empresas de alta tecnología hasta organizaciones de otros giros que desean mejorar sus prácticas de negocio por medio de Agile. ¿Qué estrategia de adopción de Agile es más efectiva, de la directiva a los empleados (top-down) o viceversa (bottom-up)?

Hemos visto éxitos y fracasos en ambos casos. Sin embargo, la estrategia topdown tiende a ser más efectiva ya que los directivos están genuinamente comprometidos, y eso es un requisito para lograr el cambio cultural en la organización que Agile requiere. ¿Algunas palabras para nuestros lectores?

Trabajen duro y sean profesionales. No se conviertan en desarrolladores de software porque alguien les dijo que sería un buen empleo; háganlo porque los apasiona crear software grandioso. www.sg.com.mx

www.sg.com.mx

AGO-OCT 2009

25

E

n los últimos meses tuve la oportunidad de dar en México diversas presentaciones sobre Agile y Lean para organizaciones privadas, gobierno y academia.

En prácticamente todas, surgía la pregunta: “¿Cómo utilizar agile/lean en organizaciones cuyos procesos deben mantener certificación con estándares o modelos tales como ISO, CMMI, MoProSoft, u otro?”. Dicha pregunta es muy importante, debido a que por una parte, un buen porcentaje de empresas en Latinoamérica busca apegarse a alguno de estos modelos, y por otra, existe la impresión que de que los métodos ágiles y el desarrollo esbelto no son compatibles con esos tipos de regulaciones, por lo que no pueden ser adoptadas.

Gobierno Corporativo +Agilidad Beneficiando Estándares Mediante Agile y Lean por Masa K. Maeda

26

AGO-OCT 2009

www.sg.com.mx

continua, lo cual es demostrable sólo mediante la renovación periódica de la certificación.

ISO ha generado los estándares más utilizados, los cuales con frecuencia se convierten en ley, ya sea mediante tratados o estándares nacionales; en parte gracias a su fuerte lazo con los gobiernos políticos.

Un modelo es una descripción, patrón o plan, cuyo fin es mostrar cómo opera un concepto o un sistema; por ejemplo: el planteamiento de una guía para el mejoramiento de procesos. A diferencia de un estándar, un modelo no tiene un requerimiento a cumplir sino un patrón a partir del cual los procesos a seguir son definidos; por lo que normalmente está mejor adecuado a la organización que lo adopta.

Esta distinción con frecuencia se pasa por alto, y existen empresas que tratan los modelos como si fueran estándares, lo cual llega a tener resultados desastrosos. Uno de los modelos más utilizados actualmente es el CMMI, el cual integra una serie de mejores prácticas para el perfeccionamiento de los procesos.

El objetivo de este artículo es resaltar los beneficios de adoptar el desarrollo ágil y esbelto en las organizaciones, y su compatibilidad con esquemas de gobierno corporativo. Por gobierno corporativo entiéndase el manejo consistente, las políticas cohesivas, los procesos y los derechos de decisión en un área de responsabilidad. De tal forma que cubre tanto estándares y modelos, como otros métodos de regulación interna que pueden apegarse también a regulaciones externas nacionales o internacionales.

Estándares, modelos y valores

Por último, un valor es una propiedad abstracta que representa el grado de importancia de un objeto y su conducta correcta; algo intrínsecamente valioso o deseable. Su objetivo es servir como un acimut o indicador de la ruta a seguir, respecto de los principios que nos permiten desarrollar metodologías para la gestión y desarrollo de proyectos y organizaciones. Agile y Lean es un conjunto de valores y principios tomados como base para el desarrollo de otras metodologías muy eficientes en la gestión e implementación de proyectos para organizaciones de todo tamaño. Algunas de esas metodologías son Scrum, Extreme Programming, Crystal Clear, Dynamic Systems Development Method, Feature Driven Development, etcetera.

Comencemos con entender la diferencia entre estándares, modelos y valores.

Agile es básicamente sentido común

Un estándar técnico es un requerimiento o norma expresada casi siempre como un documento que establece procesos, prácticas, métodos y criterios técnicos con el fin de obtener un gobierno corporativo técnico consistente y uniforme que puede hacerse obligatorio. Las empresas que deciden adoptar un estándar, normalmente pasan por un periodo largo y sumamente costoso de transición, y una vez establecido el estándar, deben cumplir con sus requerimientos de manera fiel y

Durante muchas de las presentaciones, algunos participantes comentaron: “Agile es básicamente sentido común”, y tienen razón. Tal atribución es un arma de dos filos. Los métodos ágiles y esbeltos son muy simples en principio, pero su implementación exitosa requiere de entrenamiento adecuado y disciplina a nivel corporativo. Hay empresas que intentan la adopción tomando como base tan solo la literatura, engañándose a sí mismos por la aparente simplicidad... estas empresas en su gran mayoría fracasan. Los valores de los métodos

ágiles formalizados en el manifiesto ágil[1], nos dicen que se valoran: • Individuos e interacciones sobre procesos y herramientas.

• Software funcional sobre documentación integral o total.

• Colaboración con el cliente sobre negociación por contrato.

• Respuesta al cambio sobre seguimiento de plan.

Estos valores están respaldados por una serie de 12 principios[2, 3] que ayudan a entender mejor su esencia. Aun así, los valores son normalmente malinterpretados. El primer aspecto a clarificar es la semántica de la palabra “sobre”, la cual quiere decir “más que” y no “en lugar de”. Por ejemplo: en el caso del primer valor, los procesos y herramientas son de importancia fundamental en el desarrollo de software, pero el enfoque debe ser en las personas involucradas en el proyecto y su interacción efectiva, de tal forma que los procesos y herramientas utilizadas sean aquellas que hacen a las personas eficientes; y son los procesos y herramientas lo que se tiene que adaptar a la forma en que las personas interactúan, y no las personas quienes deben adaptarse al proceso.

El objetivo de un proyecto de desarrollo de software es tener un producto que satisfaga las necesidades del usuario. En la práctica tradicional, la generación de requerimientos es la primera labor de un proyecto, por lo que generalmente se completa incluso si el terminarlo tomó mas tiempo del planeado en un principio; pero la implementación y prueba se cortan con el fin de cumplir con una fecha de terminación fija, por lo que el producto final está incompleto y es de baja calidad. Aun haciéndolo, los requerimientos cambian durante el desarrollo, pero la gran mayoría de tales cambios importantes para el cliente, terminan diferidos para una versión futura. Como resultado: el cliente recibe software limitado, con defectos, y que no satisface todas sus necesidades, aunque se generaron volúmenes de documentación. Los métodos ágiles reconocen esta realidad y ponen énfasis en la calidad y en satisfacer el mayor monto posible de las necesidades del usuario, generando únicamente la documentación mínima necesaria para el producto de manera dinámica, redundando en documentación más actualizada y útil que la acostumbrada con métodos tradicionales, no iterativos e incrementales.

El Dr. Masa K Maeda es Presidente y Fundador de Shojiki Solutions (www.shojiki-solutions.com), una empresa dedicada a ayudar empresas en la adopción y mejoramiento del uso de metodologías Agile-Lean. El doctor Maeda tiene más de 20 años de experiencia en la industria de software en Japón, México, y Estados Unidos.

Obtuvo el Doctorado y Maestría en Sistemas Inteligentes y Ciencias de la Información en la Universidad de Tokushima en Japón, y la Licenciatura en Ingeniería en Computación en la Universidad Nacional Autónoma de México. El doctor Maeda radica actualmente en Campbell, California, E.U., donde tiene su empresa.

www.sg.com.mx

AGO-OCT 2009

27

Crear un producto que satisfaga las necesidades reales del cliente requiere que la comunicación y colaboración con él sea sumamente efectiva. El cliente mismo puede no tener una idea completa del producto al inicio del proyecto, entre otras razones porque el entendimiento del producto mismo madura con el tiempo, y en parte porque una mejor funcionalidad suele surgir en la medida que el producto es construido. Tradicionalmente los cambios son puestos en lista de espera para una versión futura del producto, pero los métodos ágiles permiten y motivan que el producto madure durante su fabricación, para que el cliente obtenga el mayor valor posible en la menor cantidad de tiempo. El énfasis no es en tener un contrato detallado e inflexible sino en tener un contrato conciso que permita flexibilidad de adaptación mediante la colaboración.

Eisenhower dijo: “los planes son inútiles, pero la planeación es indispensable”. Esto se debe a que la ejecución de un proyecto difícilmente corresponde con lo planeado al principio.

Sin embargo, la planeación permite que las partes involucradas obtengan el mismo nivel de entendimiento del proyecto y la estrategia de desarrollo, lo cual les permite responder de manera más eficiente a cambios, cuando éstos se presentan, incrementando las posibilidades de éxito del proyecto. Los cambios pueden ser de índole tecnológica, económica, de mercado, social, político, u otro. El desarrollo ágil se enfoca en la planeación y la lleva a cabo de manera incremental.

Pensamiento esbelto para mejorar procesos La manufactura Lean, o esbelta, se originó en Japón con bases en estrategias de control de calidad total originadas en el mundo occidental y perfeccionadas por la empresa Toyota. Los tres valores de esta filosofía son conocidos como “Las Tres Emes” (Muri, Mura, Muda), las cuales me he atrevido a traducir como “Las Tres Des” (Disgusto, Desbalance y Desperdicio). El Disgusto (muri), surge cuando alguna persona o personas involucradas en la creación del producto son confrontadas con situaciones o detectan aspectos del proceso que les hacen menos eficientes. El Desbalance (mura), surge cuando aspectos que alteran el flujo eficiente de un proceso existen o son introducidos. El Desperdicio (muda), es toda actividad que no agrega valor al producto y absorbe tiempo o costos.

28

AGO-OCT 2009

Los principios esbeltos influenciaron los valores de los métodos ágiles y penetraron eventualmente el desarrollo de software en forma de siete principios[4,5]: 1. Eliminar desperdicio. Eliminar todo aquello que no agrega valor al producto.

2. Crear conocimiento. Mantener una cultura de mejoramiento continuo y solución de problemas.

3. Calidad de forma integral. La calidad debe existir aún antes de escribir la primer línea de código.

4. Diferir compromisos. Las decisiones deben ser tomadas en el último momento responsable.

5. Optimizar el todo. Detectar y resolver ineficiencias tanto de producto como de recursos.

6. Entregar rápido. Estabilizar ambientes de trabajo a su capacidad más eficiente y acortar los ciclos de desarrollo.

7. Respetar a la gente. Entrenar lideres, delegar decisiones y responsabilidades del producto en desarrollo al nivel más bajo posible, y fomentar buena ética laboral.

Los métodos ágiles y el desarrollo esbelto han mejorado la eficiencia en la fabricación de software y su calidad en medidas difícilmente alcanzadas por otras metodologías.

Las mejoras resultan en la alta posibilidad de terminar proyectos a tiempo y con costos significativamente menores comparadas con el método de cascada.

Los estándares y modelos tales como ISO12207/15504, CMMI, y MoProSoft comparten con Agile y Lean los objetivos de mejoramiento de calidad y de procesos. A continuación se muestra cómo dichos modelos pueden enriquecerse y ser más eficientes mediante la inclusión de prácticas de los métodos ágiles y el desarrollo esbelto.

ISO + Agile/Lean ISO le da énfasis al establecimiento de un proceso controlado mediante la creación, monitoreo, y mantenimiento de documentación detallada. Describe qué metas alcanzar sin indicar cómo alcanzarlas, dejando esa responsabilidad a cada proyecto. Se espera que las mejoras surjan, pero llevarlas a cabo es lento y costoso debido a que la mayoría de las veces requieren numerosos cambios en la documentación del proceso.

Los métodos ágiles proveen un “cómo” muy efectivo, que además de ser altamente productivo, permite que la documentación esté siempre actualizada. Parte de la documentación se genera durante la fase de planeación inicial, la cual es ligera y consiste en generar el monto mínimo necesario para tener un buen entendimiento del producto, sin entrar en detalles de implementación. Como los métodos ágiles son iterativos e incrementales, otra parte de la documentación se genera durante la planeación de cada iteración, en forma de criterios de validación de historias. Otra parte importante de la documentación proviene de la definición de las pruebas de validación de la historia.

Agile y Lean ayudan también a tratar otros tres requerimientos de ISO tradicionalmente difíciles de cumplir: 1) detectar defectos y tomar medidas correctivas; 2) revisar el proceso de calidad periódicamente para hacerlo más efectivo; 3) facilitar mejoramiento continuo. En los métodos ágiles, el criterio para declarar un componente de desarrollo como terminado es que todas sus pruebas hayan pasado, i.e. que la implementación del software se base en pruebas, por lo que la calidad es la brújula que dirige el desarrollo. Un desarrollador no puede comenzar a codificar algo nuevo hasta que lo que implementó haya pasado todas sus pruebas.

Mediante ciclos cortos, los métodos ágiles motivan la generación incremental del producto y la mejora continua, donde la calidad es parte integral del proceso en lugar de una fase tardía de pruebas, con el fin de envolver el código implementado con una capa “protectora”. El proceso de integración continua, elimina las demoras que surgen por dependencias entre componentes desarrollados de forma independiente. Tal efectividad es difícil de obtener utilizando ISO sin métodos ágiles.

Algunas empresas que hacen ISO y aplican métodos ágiles han indicado que ISO les ayuda a mantener una aplicación continua y uniforme de las prácticas porque puede proveer más estructura, tanto a la empresa como a los empleados, lo cual ayuda en la planeación y como evidencia para mantener certificación.

En mi experiencia, esto es más bien un aspecto cultural de cada empresa y un mecanismo para justificar la necesidad de continuar usando ISO. www.sg.com.mx

La integración de ISO con métodos ágiles, requiere que los auditores ISO entiendan que Agile genera documentación de forma distinta a lo acostumbrado (el cómo), y que también cumplan con los requerimientos del ISO (el qué); y que el proceso aunque es flexible, está definido y requiere de disciplina, por lo que puede especificarse.

CMMI + Agile/Lean CMMI establece prioridades y metas para el mejoramiento de procesos y calidad cubriendo tres áreas: 1) desarrollo de productos y servicios; 2) establecimiento, manejo, y entrega de servicios; 3) adquisición de productos y servicios.

El proceso de adopción es medido con base en cinco niveles de madurez. Similar al ISO, CMMI nos da el “qué” pero no el “cómo”, aunque en este caso lo que el modelo provee es una serie de guías que la empresa puede y debe moldear a sus necesidades.

Los métodos ágiles y esbeltos contribuyen a CMMI en forma similar a como lo hacen con el ISO, y le adicionan dos formas: una para alcanzar el nivel de madurez 3 y la otra en el nivel de madurez 5.

El nivel 1 y 2 contribuyen a establecer procesos de forma mas rápida a la vez que incrementan el nivel de productividad, lo cual permite alcanzar el nivel 3 en menor tiempo.

Tomemos por ejemplo el caso en el que usamos la metodología de Scrum. Ésta provee una manera efectiva para que el equipo se comunique y genere acuerdos. Durante la planeación de cada sprint se definen en conjunto las historias a implementar y se obtienen compromisos. El método de planeación ágil conocido como “poker de planeación” ha sido tan efectivo, que incluso empresas que no tienen interés en adoptar métodos ágiles lo han hecho con esta técnica.

En la madurez CMMI de nivel 5, estos métodos contribuyen al mejoramiento de procesos mediante planes de desarrollo que agregan valor; es decir, un enfoque esbelto. Lo que permite llevar a cabo planeación adaptativa para tener organizaciones más ágiles.

Algunas diferencias que hay entre CMMI y Agile radican en que CMMI presta más atención en documentar el proceso de manera detallada y en tener mas documentación a nivel de producto, que a nivel de código y pruebas. Adicionalmente, las fases iniciales www.sg.com.mx

de planeación son más pesadas que lo que recomiendan los métodos ágiles.

Para conjuntar efectivamente CMMI y los métodos ágiles y esbeltos recomendamos lo siguiente: • Generar una cultura corporativa de grupos auto-organizados con el fin de reducir la dependencia en la jerarquía corporativa.

• Desarrollar software de manera incremental.

• Cambiar las responsabilidades gerenciales de comando y control hacia guía y servicio.

• Llevar a cabo juntas concisas y efectivas.

• Enfatizar en la interacción del personal.

• Generar software funcional con miras a incrementar valor.

MoProSoft + Agile/Lean MoProSoft es un modelo de procesos originalmente adecuado para las necesidades de las industrias mexicanas, y cuyo impacto ha alcanzado ya niveles internacionales. MoProSoft está bajo revisión para ser promovido como estándar ISO (lo cual nos obliga a cuestionar si es entonces en esencia un estándar y no un modelo, o si ISO quiere usar el MoProSoft como un mecanismo para penetrar el mercado que no ha aceptado usar ISO). Considero que la aportación más importante de MoProSoft ha sido la de incrementar el nivel de conciencia en la industria Latinoamericana sobre la importancia de la madurez de procesos y la necesidad de incrementar el nivel de calidad de sus productos. MoProSoft está basado en ISO y CMMI, y está organizado en tres categorías: alta dirección, gerencia, y operación. Cuenta también con niveles de madurez similares a los de CMMI. La forma en que los métodos ágiles y esbeltos mejoran CMMI e ISO se aplica también a MoProSoft, por lo que a continuación se discuten solamente aspectos no tratados anteriormente. A nivel de alta dirección y gerencia, estos métodos brindan a MoProSoft una forma muy efectiva de comunicación que incluye mayor interacción con el cliente, con el fin de entender mejor el producto a construir. MoProSoft hace mucho uso de plantillas con el fin de controlar la forma en que el producto es documentado y construido, así como de establecer la forma en que el flujo de producción se lleva a cabo.

Debido a que las metodologías agile están diseñadas para generar productos de manera integral en lugar de funcional, cumplen con el requerimiento MoProSoft para la integración

de verificación, validación, documentación, y configuración, aunque de manera distinta a la propuesta por MoProSoft.

A nivel de gerencia media, Agile y Lean permiten utilizar esos roles en una forma más efectiva con miras a hacer que los desarrolladores sean más efectivos y que los requerimientos sean más cercanos a lo deseado por el cliente. Esto es porque los desarrolladores tenderán más a trabajar como equipo para codificar juntos, en lugar de distribuir la carga de trabajo e implementar de manera independiente lo que se les ha entregado para codificar. Esto obviamente requiere que la empresa acepte tal modalidad y permita el cambio en los hábitos de trabajo.

Si MoProSoft se usa como modelo, entonces es posible adoptar sólo aquello que es efectivo para el proyecto, por lo que inyectar prácticas de los métodos ágiles será posible. Pero si se usa como estándar, entonces será más complicado combinarlo con métodos ágiles.

Conclusión Los estándares, modelos y valores tienen la capacidad de coexistir exitosamente e incrementar la efectividad de tu organización. Incluir los métodos ágiles y esbeltos en tus procesos es una inyección para el incremento de la calidad y productividad en empresas, resultando en productos de mayor valor competitivo. Si tu empresa utiliza algún estándar/modelo y tus requerimientos empresariales mandan que mantengas certificación, entonces agregando Agile y Lean se incrementará la productividad y la calidad a niveles que difícilmente se logran utilizando únicamente estándares. Por otra parte, si tu empresa no ha hecho ningún tipo de adopción y no requiere legalmente de la utilización de modelos o estándares, entonces la mejor recomendación es adoptar únicamente métodos ágiles y esbeltos.

Referencias [1] www.agilemanifesto.org [2] www.agilemanifesto.org/principles.html [3] www.shojiki-solutions.com/documents/ spanish/AgileGoodForMex-sp.pdf [4] Poppendieck, Mary y Poppendieck, Tom. Lean Software Development: an Agile Toolkit. Addison Wesley, 2003.

[5] www.agilesoftwaredevelopment.com/ leanprinciples

AGO-OCT 2009

29

E

n el desarrollo de software tradicional la práctica esencial consiste en entregar productos en tiempo y forma, pero parece que hoy se necesita algo más. Las organizaciones buscan desarrollar productos y servicios que les permitan tener un claro diferenciador de sus competidores. El desarrollo de software ha demostrado ser un habilitador de ventaja competitiva, pero: ¿existe la visión en los encargados de desarrollar software para entregar ese plus que será la ventaja que los ayude a liderar el mercado?

Adaptar los Métodos Ágiles como Ventaja Competitiva

La Calidad en el Desarrollo de Software Hoy no es Suficiente

por Adalberto González Ayala

Los resultados son lo importante Durante varios proyectos en los que he tenido la oportunidad de participar, me he encontrado que, para ser tomado en cuenta en el desarrollo de software de primer nivel, se necesitan ciertas acreditaciones o certificaciones en modelos de procesos que rara vez se alinean con el comportamiento del cliente, pues en el área de negocios los resultados son lo único. Esto sin duda entra en contradicción, ya que tales acreditaciones son requisitos obligados para “jugar”, pero al parecer no son consideradas para verificar el resultado.

Al llegar la hora de rendir cuentas o auditar los productos, resulta que a nadie le interesa la metodología y la documentación, ¡solamente los resultados!; y no me refiero sólo al cliente, sino también al equipo de desarrollo. Cuando después de 96 horas semanales de trabajo forzado durante la fase de pruebas de aceptación ocurre que se debe actualizar la especificación funcional de lo que se acaba de modificar, el desarrollador se encontrará ante la decisión: “¿corregir la especificación o liberar la funcionalidad?” La segunda opción es la más socorrida, ya que a fin de cuentas lo que el cliente necesita es el software funcionando … luego encontraremos tiempo de completar la documentación, primero hay que entregar el producto…

El time-to-market es esencial Ahora, imaginemos el caso hipotético de una organización donde este tipo de situaciones no suceden, ya que cuenta con un proceso de desarrollo de software sumamente maduro, el cual es soportado por las más rigurosas practicas de administración de proyectos; no hay sorpresas ni desvíos de los planes originales.

Supongamos entonces, que un cliente tiene un

proyecto en puerta para un nuevo negocio, y que por lo tanto, requiere un nuevo sistema de información: lo encarga a dicha organización, se define la funcionalidad, se construye la aplicación, el cliente la acepta y todo se libera para competir en el mercado, pero sucede que desde que el cliente solicitó el sistema hasta que se ha puesto en producción han pasado al menos 12 meses. Hoy en día, ¡12 meses es muchísimo tiempo! No podemos esperar tanto por un sistema. En 12 meses la competencia ha presentado un nuevo producto, el congreso ha aprobado alguna nueva ley, los teléfonos ahora son touch screen, se dejaron de vender las playeras del Manchester por vender las de Barcelona por ganar la Champions League, etcétera.

Pues bien, razones como las que he mencionado, han sido causas que me llevaron a replantear el cómo nos conducimos al proveer servicios de desarrollo de software en el mercado, y la mejor solución con la que me encontrado, usado y recomendado, es: los métodos ágiles.

El uso de los métodos ágiles me ha permitido visualizar el orden en el que las necesidades de mi cliente deberán resolverse dentro de periodos de tiempo donde se puede aceptar el cambio, cambios a nivel de mercado que nos obligan a entregar cuatro números frecuentes para el celular en vez de sólo tres… son esos cambios los que nos debe interesar resolver en lo inmediato, ya que no podemos esperar 12 meses a que el sistema esté completo. Porque es casi seguro que sólo una de los cientos de funcionalidades solicitadas sea la prioridad. Si podemos hacer iteraciones cortas que nos permitan ir liberando nuevas versiones y mejores funcionalidades, podremos ofrecer esa ventaja competitiva antes mencionada.

Parecería algo radical, pero no lo es, únicamente los resultados lo son...¿cuántas versiones del teléfono celular que tenemos hemos visto llegar?... soóo en la función de la cámara tenemos incremento continuo en la cantidad de pixeles, luego detección de rostro, que dispare la foto cuando sonríes; casi de inmediato salió otro que se acuerda de los rostros y mañana no sabemos… la clave está en iterar… y hacerlo rápido.

Las ventajas de los métodos ágiles La naturaleza de los métodos ágiles nos permite el desarrollo iterativo de versiones, estableciendo el beneficio de la entrega de aquella funcionalidad que es crítica para el cliente, e inmediatamente después de haberla entregado, avanzar con la siguiente o inclusive con la aplicación completa; y todo esto con calidad incluida, pues parte fundamental del desarrollo ágil es la integración de las pruebas de forma continua durante el ciclo de desarrollo, lo que conlleva el asegurar la calidad del trabajo tan pronto como se está desarrollando. Lo anterior se traduce en libertad para el cliente para solicitar “ajustes” sin que el equipo resienta el costo de la calidad.Otra gran ventaja es la participación activa del usuario final, pues la alta visibilidad que se le inyecta al producto, así como la promoción de aceptar los cambios, incrementan sin lugar a duda la satisfacción del cliente, trasladándose en relaciones de negocios más duraderas. Por si fuera poco, el equipo de desarrollo adquiere una habilidad intrínseca para construir el producto adecuado, pues el producto que se construye está bajo continua revisión por parte del cliente, lo que rara vez sucede con en el desarrollo de software tradicional que requiere largos periodos de tiempo para entregar resultados, lo cual tiene como consecuencia común el encontrarse con decepciones al no entregar lo que se esperaba. Los métodos ágiles te llevan de la mano a construir lo que el cliente necesita y espera.

Adalberto González Ayala es consultor en Softtek donde participa en proyectos para el sector financiero global. Entre sus funciones se encuentran el seguimiento e implantación de CMMi y Agile así como el diseño y construcción de herramientas automatizadas para la extracción y análisis de datos. adalberto.gonzalez@sofftek.com

30

AGO-OCT 2009

www.sg.com.mx

Los métodos ágiles nos acercan al desarrollo de proyectos como productos. Nos olvidamos de la idea de que tenemos que construir un sistema que haga de todo en una primera versión, y que el cliente no puede cambiar de opinión porque para eso nos firmó con sangre una especificación de requerimientos y hasta pedimos testigos para que no se fuese a retractar. Hoy necesitamos aceptar el cambio en el momento preciso y los métodos ágiles nos preparan para aceptar y promover el cambio. No nos deberá molestar que el cliente diga: “no, no podemos ejecutar la funcionalidad de Honduras pues la situación político/económica nos impide tomar decisiones, continuaremos con Nicaragua”. Ni modo que respondamos: “¡No, eso no decía el plan!”.

Claro que no, el sentido común te invita a aceptar el cambio, de no hacerlo, seremos reemplazados por alguien que sí lo haga.

Definitivamente puedo asegurarte que adoptar los métodos ágiles ha ayudado a mi equipo de desarrollo a entregar ventajas competitivas, pero el adoptarlos no quiere decir que mágicamente las cosas van a cambiar. No. Hoy las organizaciones esperan que alguien les diga que con una inversión de 9,999 USD más gastos de envió, recibirán una serie de formatos preestablecidos que los llevarán al paraíso del desarrollo y no es así. El adoptar ágil en tu organización implica apertura, comunicación efectiva y un gran compromiso tanto del equipo como del cliente...

A pesar de todo, las ventajas competitivas que proponen los métodos ágiles son bastante concretas y perceptibles. Inténtalo, asegúrate de que está siendo implementado correctamente y los resultados serán tu mejor carta de presentación.

www.sg.com.mx

AGO-OCT 2009

31

32

AGO-OCT 2009

www.sg.com.mx

Scrum vs. Kanban ¿Cuál es Mejor? por Tomas Björkholm

La versión original de este artículo se encuentra disponible en Agile Journal (http://tinyurl.com/mssfkb).

Fue traducido y editado para SG con permiso de el autor.

D

esde hace tiempo he estado pensando acerca de qué es mejor, Kanban o Scrum, y no he podido decidirme así que decidí escribir un artículo donde planteo porque me gusta cada uno. Antes que nada creo que es pertinente dar una introducción a cada uno.

Scrum en un minuto Scrum busca regresarnos a aquellos tiempos en que las empresas eran pequeñas, los proyectos y equipos eran pequeños, y la comunicación era sencilla. Lo mejor de todo es que eramos eficientes.

Viéndolo de forma simplista, en Scrum lo que se hace es dividir un proyecto grande en proyectos pequeños organizados en base a iteraciones con duración fija (timebox) llamadas sprints. Los equipos son pequeños y cruzados (los miembros poseen habilidades y roles complementarios). La comunicación del equipo al resto de la empresa se realiza haciendo visible el plan y estado actual. El plan es conocido como sprint backlog y el estatus se muestra en una pizarra.

visualizar tu flujo de trabajo y empatar la demanda con la capacidad.

Kanban significa “letrero” en japonés y es un modo de trabajo inventado por Toyota para organizar el flujo de partes en sus líneas de ensamble. En esencia, Kanban consiste en una tarjeta que se agrega a una parte que será utilizada. Una vez que la parte es consumida, se regresa la tarjeta como petición de más partes. Dado que las tarjetas son reutilizadas, y no se generan nuevas tarjetas, esto permite limitar el número de partes en stock y al mismo tiempo asegurar que se ordenan partes nuevas en cuanto se necesitan.

En el caso del desarrollo de software, Kanban es una promesa de trabajo delimitado.

Un pizarrón de Kanban para desarrollo y mantenimiento de software indica un número limitado de slots de trabajo y la tarea que está asignada a cada slot, tal como se muestra en la figura 1.

Cada equipo decide cuanto trabajo puede manejar, lo cual se indica como cuadros donde se ponen tareas. Cuando una tarea se termina, se mueve al siguiente grupo solamente si tienen cuadros disponibles. Si la tarea se queda atorada, tenemos un problema de flujo de trabajo y debemos trabajar juntos para resolverlo.

Así que mientras Scrum se enfoca en cumplir promesas, Kanban se enfoca en mantener un flujo coordinado.

Hay una persona que representa al cliente, y se le denomina Product Owner (PO). Él es responsable de priorizar los requerimientos a desarrollarse. Esta lista se conoce como el product backlog.

Para facilitar la coordinación y comunicación se agregan algunas juntas breves pero necesarias: junta de planeación para cada sprint, juntas diarias de sincronización, y juntas al cierre de cada sprint para mejorar el producto y el proceso.

Kanban en un minuto Si Scrum es sencillo, Kanban lo es más todavía. Para que un proceso pueda ser considerado Kanban, basta con que puedas

Figura 1. Ejemplo de un pizarrón de Kanban para software

Tomas Björkholm trabaja en Crisp en Estocolmo, Suecia. Se dedica a ayudar organizaciones a ser más eficientes por medio de la aplicación de métodos ágiles y esbeltos. tomas.bjorkholm@crisp.se

www.sg.com.mx

AGO-OCT 2009

33

Similitudes Existen varias similitudes entre Scrum y Kanban. Entre ellas: • Priorización clara • Equipos autodirigidos • Transparencia (mostrar lo que has hecho, el estatus actual y lo que sigue) • Inspeccionar y adaptar (mejorar el producto y el proceso en base a hechos) • Asignación de tareas tipo pull • Buena comunicación y colaboración

Mejoras al final de cada sprint. Hacia el final de cada sprint puede haber tiempo disponible que se puede aprovechar para hacer mejoras al código, al ambiente de desarrollo o al proceso. Esto se traduce en mejoras en eficiencia al largo plazo.

Equipos cruzados. Los equipos cruzados (cross-functional) son capaces de hacer algo de principio a fin (de concepto a producto terminado) sin depender de otros, lo cual los hace más productivos. También se favorece la transferencia de conocimiento.

Es mejor para principiantes. Muchas de las prácticas usadas en Scrum se pueden usar con Kanban. Sin embargo, cuando eres nuevo en el desarrollo ágil, es mejor contar con un método que te guíe sobre cómo hacer las cosas.

Razones para preferir Kanban

La asignación tipo pull se refiere a que el equipo está “jalando” trabajo en lugar de que el líder se los “empuje”. Esto limita el trabajo a la capacidad disponible, disminuyendo el estrés.

Razones para preferir Scrum Compromiso. Al pedir a un equipo que establezca un compromiso y dar visibilidad a éste, se obtiene un efecto de estrés positivo.

También imprime cierta movitación hacia el final del sprint cuando la meta está al alcance. Después del sprint, el equipo se puede relajar y obtener energía para el siguiente sprint. Psicológicamente, es mejor saber que no estás en medio de un flujo interminable.

Es esbelto (lean). Kanban se basa en los principios del desarrollo esbelto (lean) establecidos hace cerca de 50 años y ha demostrado ser exitoso. El trabajo es visto como un flujo continuo. No hay muchas reglas. Simplemente es una estrategia para reducir/ eliminar el trabajo inútil, realizar una priorización adecuada y ajustar la demanda con la capacidad. Además de esto, se basa en los principios Lean tales como: calidad, just-intime, reducción del ciclo de desarrollo, mejora continua y minimización del desperdicio.

La mayoría de estos conceptos se pueden acomodar dentro de Scrum, pero creo que Scrum sí tiene algunos elementos que pueden llegar a ser desperdicio y por lo tanto no tendrían cabida en un enfoque esbelto.

Estimación. Para que el equipo pueda establecer compromisos, requiere estimar. Durante la estimación se genera información valiosa que se transfiere al Product Owner mientras el equipo pregunta lo que necesita saber para poder estimar.

Historias cortas. Scrum te obliga a dividir los requerimientos (historias de usuario) de tal forma que sean lo suficientemente pequeñas para ser realizables en un sprint. Dividir los requerimientos en partes pequeñas ayuda a reducir la complejidad y aumentar la eficiencia.

34

AGO-OCT FEB-ABR 2009 2009

del equipo. Pero si nada de esto se necesita, entonces es desperdicio. Si quieres métricas de velocidad, puedes contar el número de historias hechas por semana o mes. Y ya que estamos hablando de métricas, ¿por qué no medir algo que le interese al cliente? Por ejemplo, el tiempo que toma desde que un cliente pide algo hasta que lo obtiene.

Tamaño adecuado de las historias. En Scrum estás obligado a dividir las historias de tal forma que sean suficientemente pequeñas para caber en un sprint. En algunos casos esto puede ser complicado e incluso contraproducente ya que terminas con pseudohistorias que no agregan valor significativo al cliente. En Kanban no hay restricciones sobre el tamaño de una historia, y en aquellos casos donde es difícil dividir una historia puedes dedicarte a implementarla en lugar de romperte la cabeza tratando de dividirla.

Flujo constante. En Scrum, cuando el equipo termina las tareas asignadas a un sprint, se relaja demasiado y eso puede ser un desperdicio. Kanban se trata de establecer un flujo sin estrés pero con alto rendimiento continuo.

Funciona mejor para soporte. Los equipos de soporte y operación continuamente reciben requerimientos no planeados. En este contexto los compromisos de un sprint de Scrum pierden sentido. En Kanban es más fácil recalcular prioridades y reasignar tareas sobre la marcha que en Scrum.

La simplicidad da libertad. Kanban es simple y con pocas restricciones, lo cual te da la libertad para personalizar tu proceso y adoptar las prácticas que tengan sentido.

Dichas mejoras se pueden decidir durante juntas periódicas de retrospección.

Conclusión

Solo estima si te es útil. Si el Product Owner sabe lo que necesita y su único interés es que se termine lo antes posible, ¿para qué gastar tiempo en estimaciones? En Scrum las estimaciones se necesitan para que el equipo sepa qué tanto se puede comprometer a entregar en un sprint, y se pueda calcular la velocidad como métrica de desempeño

Todavía no puedo decidirme por Kanban o Scrum. Mi conclusión, para variar, es que depende de la situación. Evalúa cual de estas opciones tiene más sentido para el tipo de proyectos en que trabajas. En un ambiente reacio al cambio, tal vez sea más fácil implantar Kanban, mientras que Scrum se presta más para situaciones donde se va a establecer un proceso desde cero. Sea cual sea la decisión que tomes, recuerda que lo importante es hacer lo que de mayor valor a tus clientes. www.sg.com.mx

Scrum

Aplicación de a un Proyecto de Software El Caso de la Universidad de Montemorelos Por Omar Soto y Harvey Alférez

L

a Universidad de Montemorelos (UM) recientemente inició la adopción de Scrum para el desarrollo de sus sistemas internos. A continuación se relatan las crónicas de su éxodo desde la tierra árida donde no existe metodología alguna, hacia la tierra donde las metodologías dan excelentes resultados.

Nota del editor: Debido a limitaciones de espacio hemos obviado definiciones básicas de Scrum y nos lanzamos de lleno a los aspectos prácticos de este caso de estudio. Puedes consultar la versión completa de este artículo, que incluye definiciones de Scrum en la versión en línea de este articulo en el sitio web de SG.

Primeros pasos hacia Scrum La Dirección de Sistemas de la Universidad de Montemorelos (UM) desarrolla principalmente dos sistemas para la institución: el sistema financiero y el sistema académico. En el verano de 2008, el líder de proyectos del sistema financiero asistió a una charla impartida por la división de Servicios Educacionales de Sun Microsystems donde se presentaron algunos fundamentos del desarrollo de software ágil, y Scrum. En el transcurso de los siguientes días se investigó un poco más al respecto. Sin esperar demasiado, se decidió iniciar el primer Sprint con una duración de tres semanas, utilizando el conjunto de requerimientos en los cuales se estaba trabajando en ese momento, para alimentar el Product Backlog.

sin detenerse a pensar por un momento siquiera en el bienestar del equipo. Fue un cambio radical de mentalidad: “el ogro se transformó en benefactor”. Dejó de existir el jefe que mira a sus subalternos desde su pedestal para convertirse ahora en un miembro efectivo del equipo, que trabaja hombro con hombro con los demás integrantes para construir el proyecto, ayudando a eliminar los obstáculos que limitan el avance y promoviendo un ambiente armonioso de trabajo. Ahora, cada miembro del equipo podía expresarse de manera abierta y confiada, sin temor a reprimendas; y, a diferencia de otras ocasiones, ahora recibía ayuda del Scrum Master para buscar la mejor solución al problema.

El primer cambio que provocó esta decisión fue eliminar al ”Líder de Proyectos”. Es decir, eliminar todo ese concepto de “el jefe con el látigo en la mano”, cuyo único interés es cumplir a fuego y sangre con las fechas estipuladas en las gráficas de Gantt,

Omar Otoniel Soto Romero es líder de proyectos del Sistema Financiero en la Universidad de Montemorelos. Es graduado de Ingenieria en Sistemas Computacionales en 1997, y de la Maestria en Administracion de Empresas en 2007. Actualmente cursa la Maestria en Ciencias Computacionales con acentuacion en Ingenieria del Software. osoto@um.edu.mx

www.sg.com.mx

AGO-OCT FEB-ABR 2009 2009

35

Tareas Finalizadas

Nueva Funcionalidad

Tareas Pendientes

Corrección de Funcionalidad

Modificación de Funcionalidad

100%

9

90%

8

80%

7

70%

6

60%

5

50%

4

40%

3

30%

2

20%

1

10%

0

0% Sprint 1

Sprint 2

Sprint 3

Sprint 4

Sprint 5

Sprint 6

Figura 1. Comportamiento de los sprints.

En el daily scrum, los miembros del equipo se informaban entre sí en qué habían trabajado el día anterior, en qué trabajarían el día corriente y si tenían algún problema que les impedía avanzar en la tarea. En caso de que así fuera, el SM ayudaba a encontrar la solución.

les nació un interés genuino y les renació la esperanza de ver sus requerimientos solucionados de manera más ágil. Al conocer las ventajas que promete Scrum, decidieron aventurarse a jugar bajo las nuevas reglas, siendo nombrado el Director de Contabilidad como Product Owner.

En una temporada, se descuidó esta práctica hasta que eventualmente se dejó de realizar por completo el daily scrum, bajo pretexto de adelantar trabajo. Fue gracias a un integrante del equipo, el cual externó su sentir acerca de la necesidad de realizar el Daily Scrum, que se renovó el compromiso de apegarse a las prácticas de Scrum.

A partir de este momento, se hizo necesario crear dos documentos compartidos: el Product Backlog, donde el PO alimentaría todas las funcionalidades requeridas; y el Sprint Backlog, donde el Scrum Master y el equipo ingresarían aquellas tareas en las cuales trabajarían durante el Sprint. Estos documentos se compartieron además, con otros roles, como los Managers, haciendo transparente el proceso de desarrollo. Gracias a Google Docs, es por demás sencillo mantener el Product Backlog al día.

En el sprint review, al finalizar el primer Scrum, se hizo evidente que los resultados fueron positivos. Se lograron finalizar todas las tareas listadas en el sprint backlog en las tres semanas de duración del Sprint. Los miembros del equipo se sintieron motivados y expresaron durante el sprint retrospective que deseaban continuar trabajando de este modo. En este punto, algunas de las cualidades del Scrum se hicieron evidentes. En palabras de Jeff Sutherland: “Scrum está diseñado para agregar energía, concentración, claridad y transparencia en la planeación e implementación del proyecto”. Tan solo en el primer Sprint, el equipo había empezado a experimentar las bondades de la comunicación consistente y estable, al ver su creatividad estimulada y una mejora en su calidad de vida.

Siguientes sprints Antes de comenzar el segundo Sprint, se presentaron los principios básicos de Scrum al Director Financiero y al Director de Contabilidad de la institución. Cuando se les mencionó que bajo esta nueva forma de trabajo ellos serían parte activa del equipo,

Conforme se ha avanzado a través de los Sprint, se ha visto la necesidad de catalogar las tareas del Sprint Backlog en: tareas pendientes, tareas en las que se está trabajando y tareas finalizadas; usando un código de color para cada uno. También identificamos aquellas tareas en las cuales no se pudo trabajar, como por ejemplo: por falta de documentación suficiente. Este código de colores ha facilitado el seguimiento del Sprint por parte del PO y los Managers.

Cuando el proceso cíclico del Sprint llega a su fin, se organiza el Sprint Review, convocando el SM al PO y los Managers. Esta reunión ha servido para revisar de manera rápida el avance de cada una de las funcionalidades que el equipo se comprometió a realizar durante el Sprint. El PO verifica que los requerimientos especificados han sido correctamente solucionados en las aplicaciones demostradas.

Sprint 1

Sprint 2

Sprint 3

Sprint 4

Sprint 5

Sprint 6

Figura 2. Composición de las tareas.

En nuestra experiencia, durante los Sprint Review, el PO y los Managers rectifican las prioridades de los elementos del Product Backlog, llegando incluso a agregar nuevos requerimientos a la lista. En ocasiones, no ha sido posible que el PO y los Managers tengan un espacio disponible en sus agendas para poder llevar a cabo el Sprint Review en cuanto finaliza el Sprint. Para optimizar el uso del tiempo, el equipo financiero ha decidido organizar el Sprint Retrospective antes que el Sprint Review. El Sprint Retrospective, ha sido una instrumento de gran utilidad al equipo financiero. Durante estas reuniones se han identificado prácticas intrínsecas al equipo que sin un período de retrospección,no serían fáciles de reconocer. El resultado natural de los Sprint Retrospective, es la creación de estándares que por necesidad del mismo equipo se definen con el objetivo de agilizar el proceso de desarrollo de software.

A continuación se listan algunos de los estándares que el equipo ha acordado: 1. Crear prueba web sin parámetros para simular la ejecución de la funcionalidad desde el menú principal.

2. Definir de manera detallada cada una de las tareas.

3. Antes de dar por finalizada cualquier tarea, ésta debe ser cotejada de manera cuidadosa contra las pruebas por el SM y el integrante del equipo que la finalizó.

4. Incluir JavaDocs en todos los métodos, indicando propósito y cualquier situación especial a considerar para utilizar el método.

5. Incluir comentarios en aquellas líneas de código que así lo ameriten.

Una vez que se ha finalizado una iteración del proceso, éste comienza de nuevo con el Sprint Planning Meeting donde una vez

Germán Harvey Alférez Salinas es Coordinador del Departamento de Investigación de la Facultad de Ingeniería y Tecnología en la Universidad de Montemorelos, e investigador asociado de Mission College, Tailandia. Es graduado con honores del Master of Science in Information and Communication Technology en Assumption University, Tailandia. Sus áreas de interés incluyen software product lines, model driven development, y software architectures. fit.um.edu.mx/harvey

36

AGO-OCT 2009

www.sg.com.mx

Tareas Planeadas

Tareas No Planeadas

100%

90% 80% 70% 60% 50% 40% 30% 20% 10% 0% Sprint 1

Sprint 2

Sprint 3

Sprint 4

Sprint 5

Sprint 6

Figura 3. Tareas imprevistas.

más, el SM convoca al PO y Managers. Debido a las agendas ocupadas del PO y los Managers, durante el tiempo que el equipo financiero ha estado implementando Scrum, dicha reunión se ha ido adaptando de tal modo que el Sprint Review y el Sprint Planning Meeting se llevan a cabo como una sola reunión.

Resultados cuantitativos En el camino de esta aventura hemos generado algunos datos dignos de analizarse. A continuación, se analizarán y explicarán de manera detallada los resultados obtenidos.

Como se aprecia en la figura 1, durante los primeros tres Sprints el nivel de productividad se fue incrementando de manera progresiva. Es evidente que conforme el equipo fue asimilando el proceso de Scrum, un mayor porcentaje de las tareas se completó.

Es importante hacer notar que el éxito de cada Sprint se fundamenta en el análisis cuidadoso de cada una de las funcionalidades seleccionadas del Product Backlog. Si se descuida este factor de éxito, sería muy fácil sobrepasar la capacidad de trabajo del equipo, dando como resultado la incapacidad de cumplir con el compromiso de finalizar 100% de las tareas. Como en todo proceso de aprendizaje, es a través de la prueba y el error, que el equipo adquiere la maestría necesaria para lograr un equilibrio entre la capacidad del equipo y la carga de trabajo.

Se puede notar que a partir del cuarto Sprint hay una caída drástica de 35.71% en el nivel de productividad. Las causas se analizarán a detalle más adelante en la figura 3.

Bajo la forma particular de trabajo de Scrum, se espera que debido a la continua interacción entre el PO y el equipo, cada funcionalidad liberada cumpla de manera fiel todos los requisitos que se solicitaron, elevando así la calidad del software. Tomando como base este punto, se considera de relevancia el analizar de qué tipo de tawww.sg.com.mx

reas está compuesto cada Sprint. Es decir, tareas que agregan nueva funcionalidad, tareas que corrigen funcionalidad o tareas que modifican la funcionalidad.

En la figura 2 se puede observar que durante los Sprints uno, dos, cinco y seis, el Sprint Backlog se compuso exclusivamente de tareas orientadas a generar nueva funcionalidad. Es decir, en estos ciclos no se trabajó en resolver bugs, ni en agregar o modificar funcionalidad a aplicaciones ya existentes. En el tercer Sprint, 14.29% de las tareas que se trabajaron, estuvieron orientadas a modificar funcionalidades de aplicaciones ya liberadas anteriormente.

Esto puede interpretarse de dos maneras: a) Hizo falta un análisis más cuidadoso en compañía del PO a la hora de detallar las funcionalidades, para comprender perfectamente el requerimiento antes de iniciar alguno de los Sprints anteriores. b) El usuario final una vez que tuvo la funcionalidad requerida, se da cuenta que ésta no satisface sus necesidades.

En la figura 1 ya vimos que en el Sprint 4 hubo una caída notable de productividad en cuanto a tareas finalizadas. En la figura 3 se aprecia que a partir de este Sprint el equipo se vio en la necesidad de aceptar tareas que originalmente no habían formado parte del Sprint Backlog, lo cual provocó la baja en productividad. ¿Qué ocasionó este escenario? El sistema financiero tiene una antigüedad de siete años y cuenta con ocho módulos principales, haciendo de la labor de mantenimiento de código una necesidad primaria que demanda recursos. Tal situación abre la puerta para que el PO solicite ciertas modificaciones y correcciones con carácter de urgencia. Algunos de estos requerimientos extraordinarios, están en relación directa con determinadas fechas o acontecimientos bien identificados como parte de la vida institucional. Por ejemplo: inicio y término del ciclo escolar, inicio y fin de año contable. En la figura 3, los tres últimos Sprints se corresponden con periodos de cierre de año contable e inicio

del siguiente ciclo contable, lo cual explica la cantidad de tareas no planeadas.

Aunque se encuentra como una opción viable que el SM acepte nuevas tareas para un Sprint que ya inició, se considera una mejor práctica el finalizar el Sprint para reorganizar de nuevo las prioridades de los requerimientos.

Una táctica que el equipo financiero ha adoptado, es identificar en conjunto con el PO y los Managers, cualquier probabilidad de la existencia de solicitudes de requerimientos inesperados durante el Sprint, disminuyendo entonces de manera inversa la cantidad de tareas aceptadas por el equipo.

Conclusiones La implementación correcta de Scrum no sucede de la noche a la mañana. Este es un proceso paulatino, en donde cada uno de los distintos roles debe aprender sus responsabilidades y, a través de la práctica continua lograr jugar correctamente su papel.

Algunas partes de Scrum se han adaptado en la Dirección de Sistemas de la UM, con el objetivo de hacer la transición de una manera menos drástica, especialmente para el PO y los Managers. Afortunadamente Scrum es lo suficientemente flexible como para adaptarse y así facilitar la asimilación del proceso. Sin embargo, se debe estar atento de no degradar el Scrum, eliminando así cualquier valor que éste pudiera agregar a la organización.

En cada Sprint Planning Meeting fue necesario analizar detenidamente las funcionalidades que se aceptaron en cada Sprint. El determinar de manera real la cantidad de recursos que una funcionalidad demandará es un punto clave para el éxito de Scrum. La comunicación constante entre el PO, el SM y el equipo garantizó que en cada Sprint se trabajara sólo en aquellas funcionalidades que realmente le interesaban al PO, resolviendo necesidades reales y evitando así la generación de código ocioso.

AGO-OCT 2009

37

La versión original de este articulo fue publicada en la edición de enero 2009 del Cutter IT Journal. La versión que presentamos aquí fue traducida y editada por SG, y publicada con el permiso de Cutter Consortium México.

L

os métodos ágiles han dejado de ser un movimiento de unos cuantos radicales, y hoy en día son un fenómeno generalizado a lo largo de la industria de software. Sin embargo, a pesar de las victorias obtenidas a nivel de proyectos individuales, son raros los casos de organizaciones grandes que han logrado adoptar ágil a nivel organizacional y no tan solo en proyectos individuales.

Gestión Ágil del Portafolio de Proyectos Llevando el Desarrollo Ágil a Nivel Organizacional por Scott Ambler

El principal reto que enfrentan los métodos ágiles al tratar de escalar a nivel organizacional es el de poder funcionar en conjunto con prácticas de gobierno corporativo de TI. En particular, la gestión del portafolio de proyectos (project portfolio management) pareciera

contraponerse con los métodos ágiles. En realidad esta no es una incompatibilidad de fondo, simplemente es necesario que la gestión de portafolio de proyectos evolucione hacia un enfoque adaptativo, de modo que facilite en lugar de estorbar a los proyectos ágiles.

Scott W. Ambler dirige la práctica de desarrollo ágil en el grupo de software de IBM. Adicionalmente participa con Cutter Consortium contribuyendo como autor para las prácticas de Gestión Ágil de Productos y Proyectos, y Arquitectura Empresarial.

38

AGO-OCT 2009

www.sg.com.mx

En la mayoría de las organizaciones, las técnicas utilizadas para gestionar los programas y portafolios siguen siendo predictivas y dirigidas por planes. Se basan en ciclos de presupuesto anuales y planeación de la capacidad a largo plazo. No es sorpresa entonces que a pesar de haber adoptado métodos ágiles a nivel de sus proyectos, la mayoría de las organizaciones todavía no aprovechen los métodos ágiles a nivel de programas y portafolios de proyectos.

Poniéndolo en otras palabras, los proyectos ágiles están restringidos porque los portafolios que los engloban no son ágiles, lo cual entorpece la asignación efectiva de recursos. Ante esto, la pregunta que debemos hacernos es: ¿Cómo podemos escalar los métodos ágiles más allá de los proyectos individuales de tal forma que impacten y beneficien a los programas y portafolios que los engloban?

Definiendo la gestión de portafolio de proyectos Antes de ver cómo podemos cambiar la gestión de proyectos, hay que entender su esencia. La meta de la gestión de portafolio en un ambiente de TI es ayudarnos a manejar la eficiencia y efectividad global de los esfuerzos de TI en una organización. Esto se logra al asegurar que todos los proyectos y sistemas existentes son visibles, planeados, y alineados a las metas de la organización.

La gestión del portafolio de proyectos es importante ya que las organizaciones de TI exitosas son aquellas que ven más allá de las necesidades de un solo sistema. Las actividades fundamentales de esta disciplina incluyen la identificación y selección de proyectos, el monitoreo y gobierno de proyectos, y la gestión del inventario de activos de TI.

Definiendo el desarrollo ágil Definir el desarrollo de software ágil no es algo trivial. Muchas personas se refieren a los valores del Manifiesto Ágil como una definición. Sin embargo, para mí el manifiesto funciona mucho mejor como filosofía que como definición. Algunas personas establecen que conoces Agile hasta que lo ves –lo cual me parece una buena definición para los consultores experimentados, pero no para aquellos que apenas tratan de enwww.sg.com.mx

tenderlo. La definición que utilizamos en el grupo de software en IBM es la siguiente: “El desarrollo de software ágil es una estrategia disciplinada y evolutiva que consistentemente genera software de alta calidad, dentro de los tiempos y costos. Se realiza por medio de un ambiente altamente colaborativo y autodirigido, con la participación activa de los interesados para asegurar que el equipo entienda y resuelva sus necesidades cambiantes. Los equipos de desarrollo ágil adoptan justo la cantidad necesaria de formalidad para cada situación que enfrentan.”

Aunque esta definición describe lo que consideramos que son los aspectos esenciales del desarrollo ágil, encontramos que a muchos de nuestros clientes se les dificulta identificar si alguno de sus equipos realmente hace desarrollo ágil. Para resolver esto hemos definido un conjunto de criterios que consideramos que los proyectos deben cumplir para ser considerados ágiles: • Equipos autodirigidos • Participación activa de los interesados • Software ejecutable al final de cada iteración • Integración continua con pruebas de regresión • Mejora continua por medio de retroalimentación Habiendo definido lo que es la gestión de proyectos y el desarrollo ágil, quiero hacer algunas aclaraciones importantes: 1) Considero que no hay nada inherente al desarrollo ágil que implique que los proyectos ágiles no pueden encajar en un marco de gestión de portafolio. 2) Tampoco creo que todos los proyectos de software en un portafolio deban seguir el mismo proceso. 3) El paradigma de proceso elegido para desarrollar un sistema potencial es una decisión importante durante la identificación y selección de proyectos, ya que cada paradigma conlleva ciertos riesgos y beneficios. 4) Ya que diferentes proyectos pueden seguir diferentes paradigmas de desarrollo, la actividad de monitoreo de proyectos debe ser lo suficientemente flexible como para poder manejar este rango.

El alcance de la gestión de portafolios La gestión del portafolio de proyectos sucede más allá del ciclo de vida de un sistema en particular – desde antes de su concepción, durante el desarrollo, producción e incluso en el retiro del sistema.

Tal vez una de las razones por la que muchos desarrolladores malinterpretan la gestión de portafolio de proyectos es porque mucha de ésta sucede fuera del alcance del desarrollo de software mismo.

La identificación y selección de proyectos ocurre antes del esfuerzo de desarrollar el software, y gran parte del esfuerzo de monitoreo ocurre después de que el sistema es desarrollado.

Las organizaciones cuentan con recursos limitados, y muchas ideas u oportunidades de invertir dichos recursos. El resultado es que hay que escoger cuidadosamente cuales son los proyectos en los que la organización se enfocará para maximizar el retorno de inversión. Un concepto común entre los practicantes de ágil es el de la “Iteración 0”, que es el inicio del ciclo de desarrollo de un sistema. Es en esta iteración que se realiza el trabajo fundamental de organizar al equipo del proyecto, definir los requerimientos iniciales, la visión arquitectónica, y la planeación de alto nivel. Para que esta iteración 0 pueda llevarse, alguien tuvo anteriormente que decidir que este proyecto valía la pena.

Así que la iteración 0 no es la primera. Para mantener el esquema de numeración consistente, diremos que ese trabajo se realiza en la iteración -1.

Identificación y selección de proyectos Este esfuerzo es un proceso continuo en el que se recopilan ideas para nuevos proyectos, se evalúan y seleccionan.

La identificación de proyectos puede y debe ser lo más ágil posible. Cuando se propone un nuevo proyecto se debe realizar una inversión inicial para: • Definir el proyecto a alto nivel • Identificar una estrategia para llevarlo acabo • Evaluar su viabilidad AGO-OCT 2009

39

En base a este trabajo, el proyecto será desechado o priorizado y puesto en el backlog de proyectos. El backlog es una lista priorizada de proyectos potenciales que pueden ser tomados por el departamento de TI. La cantidad de proyectos potenciales siempre será mayor que la cantidad de proyectos que el departamento de TI puede atender, por ello la necesidad de priorizarlos. Así como los desarrolladores ágiles implementen requerimientos de acuerdo a su prioridad, los gerentes de portafolio ágiles deben ordenar los proyectos en base a su retorno de inversión.

Monitoreo y gobierno Iniciar el proyecto adecuado es tan solo un aspecto de la gestión de proyectos; también es necesario supervisar y guiar los proyectos en desarrollo, así como aquellos sistemas que ya están en producción o siendo retirados.

Los riesgos iniciales fueron identificaron durante la iteración -1, sin embargo estos evolucionarán durante el desarrollo del proyecto.

La naturaleza de los proyectos ágiles facilita la visibilidad hacia estos, lo cual facilitan la supervisión y gestión efectiva de proyectos dentro de un portafolio.

Los equipos ágiles disciplinados también contarán con un programa de métricas para soportar el gobierno de los proyectos. Las prácticas del desarrollo esbelto ofrecen una buena guía para establecer programas de métricas adecuados. Las tres principales recomendaciones son: Aplicar métricas sencillas y relevantes, supervisión continua de los proyectos y tener un ambiente integrado que automatice la generación de métricas. El aplicar métricas simples y relevantes permite que éstas sean más consistentes, precisas y útiles. La supervisión continua es crucial para poder corregir el rumbo a tiempo en un proyecto con problemas, o incluso cancelarlo antes de que haya grandes pérdidas.

Por último, la automatización de métricas es importante ya que mientras más se recaiga en métricas manuales, el costo de éstas será mayor y su precisión menor; peor aún, pueden ser completamente falsas ya que el

40

AGO-OCT 2009

equipo puede querer tapar lo que realmente sucede en el proyecto.

En mi experiencia, la supervisión efectiva de un proyecto de software requiere tres categorías básicas de métricas: costo, calidad y productividad. El costo y calidad son fáciles de entender. En cuanto a la productividad, la meta en realidad no es medir el nivel de productividad como tal, sino determinar si un equipo está siendo más productivo conforme pasa el tiempo. Una métrica que los equipos ágiles frecuentemente capturan es la llamada “velocidad”. La velocidad de un equipo es el número de puntos de trabajo que pueden realizar en una iteración, calculada al observar el historial de iteraciones previas. Los equipos ágiles se basan en su métrica de velocidad para determinar la cantidad de trabajo a la que se pueden comprometer en una iteración. Si analizamos el cambio de velocidad de un equipo a lo largo del tiempo –es decir su aceleración– entonces encontraremos una métrica de la mejora en productividad.

El monitoreo y gobierno de sistemas una vez que se encuentran en producción también es de gran importancia en la gestión de portafolios. Muchas personas se enfocan solamente en los aspectos de la gestión de portafolios relacionados con el desarrollo de nuevos proyectos, pero eso es un error.

Los gerentes de portafolio deben tener un buen entendimiento de los sistemas existentes en el inventario de activos de TI, así como de los sistemas que están por salir.

Retirar un sistema existente puede ser una tarea complicada, y por lo tanto debe ser cuidadosamente gestionada.

Gestión de Inventario de TI Las organizaciones de TI típicamente cuentan con una cantidad significativa de sistemas en producción, y comúnmente dichos sistemas están lejos de la perfección. Uno de los principales retos de los equipos de desarrollo es determinar estrategias viables para aprovechar dichos sistemas. Las estrategias técnicas para rehabilitar dichos sistemas ya existen y son suficientemente conocidas. El

reto principal no es técnico, sino en cuanto a cómo gestionar efectivamente el inventario de sistemas existentes.

Una estrategia que yo he visto ser utilizada en varias organizaciones es la de clasificar los activos de TI, ya sean sistemas o fuentes de datos, en las siguientes categorías: • Clase A. Activos críticos para la organización en el largo plazo.

• Clase B. Activos importantes, pero no se sabe con certeza si se mantendrán durante un largo periodo de tiempo.

• Clase C. Activos que no son críticos para la estrategia a largo plazo y posiblemente están próximos a ser eliminados o remplazados.

Esta categorización ayuda a los equipos de desarrollo a determinar en qué sistemas vale la pena invertir tiempo para refactorizar y mejorar componentes. Por ejemplo, automáticamente se invertiría en la calidad de los activos clase A, así que se implementarían pruebas de regresión para ellos y se aplicaría refactorización para mejorarlos gradualmente. En el otro extremo están los activos clase C, en los que no vale la pena invertir tiempo más allá de reparar defectos críticos. Los activos clase B están en medio y por lo tanto requieren ser juzgados caso por caso, así que mi recomendación es tratar de tener los menos activos posibles en esta categoría.

Conclusión La gestión del portafolio de proyectos es una disciplina importante en las organizaciones de TI, y puede ser adaptada para lidiar con las necesidades de los proyectos ágiles. De hecho, los esfuerzos de gestión del portafolio pueden ser mejorados a través de la incorporación de prácticas ágiles. Las estrategias efectivas para la gestión del portafolio de proyectos reflejan las necesidades de los sistemas a través de todo su ciclo de vida, y se coordinan con otras disciplinas organizacionales tales como la arquitectura empresarial y el gobierno corporativo de TI. www.sg.com.mx

/*TIERRA LIBRE*/

// COLUMNA

¿Estás Preparado para Adoptar Métodos Ágiles?

Algunas Palabras de Advertencia Emilio Osorio colabora actualmente como Consultor Asociado para Sun Microsystems México. Ha trabajado en desarrollos basados en Java desde 1996 y actualmente se dedica a ayudar a equipos de desarrollo a aprovechar las ventajas del Software Libre y los métodos ágiles en sus organizaciones.

Ferviente entusiasta de la aplicación social de la tecnología, a últimas fechas está involucrado con Organizaciones de la Sociedad Civil. Emilio estará encantado de recibir sus comentarios y quejas en oemilio@gmail.com

E

s increíble lo que este año ha sucedido en la adopción de métodos ágiles en México. La situación económica ha agudizado la necesidad en las organizaciones por ser más efectivas en costos y tiempos, y las empresas de consultoría y educación que antes promovían CMMI, PMBoK y demás modelos formales de la noche a la mañana se han convertido en agilistas expertos para poder satisfacer dicha demanda.

Esta necesidad que obliga a las organizaciones a hacer lo mismo o más que antes, pero con menos recursos, inevitablemente las lleva a considerar la adopción de métodos ágiles. A pesar de que esto plantea un “escenario ideal” para quienes nos dedicamos a promover el desarrollo ágil, considero una cuestión de integridad profesional aclarar lo siguiente: los métodos ágiles no son para todos. Así que por el bien de las empresas que decidan embarcarse en este profundo viaje y también por el beneficio del ecosistema de las prácticas ágiles, quiero tratar en estas líneas algunos puntos indispensables que deben considerarse antes de iniciar un proceso de adopción de métodos ágiles.

En base a nuestra experiencia comparto algunos principios esenciales a considerar antes de embarcarse en un esfuerzo de adopción de métodos ágiles. Como se darán cuenta, estos puntos van más allá de lo que normalmente leemos sobre métodos ágiles: Honestidad. Es difícil hablar de esto, pero vivimos en una industria carcomida por la corrupción. No es raro encontrar gerentes en contubernio con sus proveedores, que reciben comisión por parte de estos y por lo tanto no tienen ningún interés en introducir mejoras en costos o tiempos. Estos entornos no se beneficiarán en nada de implementar métodos ágiles.

Agentes de Cambio. Se habla hasta el cansancio del apoyo directivo como factor de éxito para proyectos de cambio organizacional.

Efectivamente es un factor importante, pero no podemos contar con que los directivos serán los agentes de cambio; ellos tienen muchas otras cosas que les preocupan más. Lo que se necesita es un pequeño grupo de personas dentro de la organización que tomen como suya la responsabilidad de cambiar. Los invito a ustedes lectores, a que tomen esta responsabilidad.

Paciencia. Son llamados métodos ágiles, no métodos fáciles. Si creemos que tomar una “certificación” de dos días de Scrum es todo lo que necesitamos para lograr un cambio sustentable, nos llevaremos una dura sorpresa. La adopción de estas prácticas es un proceso orgánico. Así como no esperamos que una Ceiba crezca de la noche a la mañana, debemos esperar a que las prácticas maduren en la organización. En general se debe considerar que este cambio tarda de 3 www.sg.com.mx

a 6 meses por equipo para afianzarse. Por favor no se embarquen en proyectos de “optimización de metodología” en un solo paso. Sean ágiles en la adopción de métodos ágiles: realicen iteraciones, crezcan gradualmente, proyecto a proyecto, equipo por equipo.

Clientes comprometidos. Los beneficiarios finales de todo lo que hacemos al transformar nuestra organización son nuestros clientes.

Por lo tanto, adoptar métodos ágiles sin que el cliente esté enterado es una receta segura de fracaso. El primer promotor de la adopción debe de ser el cliente, tenemos que empezar explicándole los beneficios y conseguir su apoyo total. Sé que no confiamos en el cliente, pero se sorprenderán lo efectivos que son y lo rápido que aprenden.

Confíen en sus clientes.

Valentía. Muchas cosas en la organización cambiarán, la transparencia que se logra con la adopción de métodos ágiles no es del agrado de todos los colaboradores. Debemos estar conscientes de que probablemente tendremos que dejar ir a gente que no está dispuesta a cambiar. No se sorprendan si gente “aparentemente” valiosa para la organización no se entusiasma por el cambio. Debemos entender lo que estamos haciendo y ser valientes para no permitir que una manzana podrida eche a perder al equipo.

Flexibilidad. Pocas cosas resultan más frustrantes que tratar de implementar métodos ágiles a través de una estrategia de planeación y control con poca flexibilidad. Es un hecho que una adopción de métodos ágiles no quedará bien a la primera. Se tiene que ir adaptando, probando y a veces hay que retroceder un poco para volver a avanzar. Los métodos se tienen que adaptar a la cultura, pero la cultura también se tiene que adaptar a los métodos. Si les cuesta trabajo ser flexibles, primero hay que trabajar en eso.

Conclusión

Probablemente les parezca extraño que un consultor en adopción de métodos ágiles levante tantas advertencias, pero parte esencial de la cultura que promulgamos es la idea de “parar la línea”, y no hay mejor momento que antes de empezar las cosas. La adopción de métodos ágiles es muy sencilla si estamos dispuestos a sostener estos valores y principios, pero si no lo hacemos, sólo gastaremos dinero, tiempo y “capital de cam » por Emilio Osorio bio organizacional” de forma innecesaria. Si aun así decidimos probarlo sin estar comprometidos con estos puntos, adelante, pero por favor no digamos que los métodos ágiles no funcionan cuando no obtengamos los resultados esperados.

AGO-OCT 2009

41

// PRÁCTICAS

/*GESTIÓN DE DATOS*/

Bases de Datos Columnares El Nuevo Paradigma para Ambientes de Data Warehousing Por Víctor González

Cada día es más común la utilización de ambientes de Data Warehousing para apoyar la toma de decisiones dentro de las organizaciones. Sin embargo, con las tecnologías y productos relacionales, como los conocemos actualmente, están llegando al límite de su capacidad debido al gran crecimiento en los volúmenes de datos que se almacenan en los repositorios y la alta velocidad con que éstos crecen. Las primeras manifestaciones son los altos consumos en disco, y aunque puede parecer trivial decir que el disco es barato, invito a los lectores a que soliciten a su jefe, varios Terabytes de disco y verán si es trivial o no el costo de almacenamiento.

El paradigma horizontal Desde que creamos como humanidad la computación, hemos pensado en forma horizontal.

Iniciando con las tarjetas perforadas, pasando por COBOL y hasta las bases de datos relacionales. Siempre nos hemos basado en el concepto del registro, y así siempre se piensa en registros horizontales que contienen por ejemplo: número de cliente, nombre, dirección, saldo, etétera.

La figura 1 muestra la manera en que estructuramos archivos o tablas como un conjunto de registros horizontales, en ambientes de data warehousing. Bajo este paradigma no es raro llegar a tener tablas de 80 ó 100 columnas.

leer todos los registros. Lo que resulta en una gran ineficiencia, ya que se están leyendo de disco todos los campos del registro (aunque al final sólo desplieguen un campo) y en realidad son campos irrelevantes para resolver la pregunta de negocio, únicamente quiero conocer el saldo promedio, no me interesan los nombres o direcciones de los clientes. Esto repercute en una alta cantidad de operaciones de acceso a disco (que es de lo más lento) y por consecuencia, nos da esos tiempos de respuesta tan altos que tienen insatisfechos a los usuarios.

Aunado al crecimiento exponencial de los datos que se deben almacenar, la tarea de administración de las bases de datos se ha hecho sumamente compleja. Los DBAs prácticamente no duermen, para tratar de remediar los tiempos de respuesta para manejar tales cantidades de datos; ya que tienen que pasar largas horas del día y de la noche velando sus procesos y esperando que terminen. En este aspecto es común ver procesos “nocturnos” corriendo a las 10 u 11 de la mañana (invito a los lectores que revisen cuando están terminando sus procesos nocturnos), arriesgando muchas veces la apertura al público de operaciones de sus organizaciones.

Por otro lado, los tiempos de respuesta a las consultas de negocio, cada vez son más lentas con la consecuente inconformidad por parte de las áreas usuarias y la frustración de las áreas de sistemas, porque por más esfuerzo que hacen, no logran satisfacer a sus áreas de negocio.

Tomando en cuenta las anteriores premisas, es como se realizó el trabajo de investigación doctoral de un servidor y del cual se hace una breve reseña en este artículo.

42

AGO-OCT 2009

Figura 1. Tabla como conjunto de registros

Pero analicemos cómo se comportan internamente los manejadores de bases de datos relacionales (RDBMS) para resolver una consulta de negocios sencilla, por ejemplo: “Quiero conocer el saldo promedio de los clientes”. El RDBMS lee el registro, lo pone en memoria y acumula el valor de la columna del saldo. Va por el siguiente registro y hace lo mismo, y así, hasta

El modelo binario-relacional ¿Qué sucedería si pudiéramos ver esa tabla de clientes en forma vertical? En vez de ver un grupo de registros veríamos un grupo de columnas.

Lo que sucedería es que se podría acceder únicamente a la columna de los saldos, evitando el acceso a información irrelevante para

www.sg.com.mx

“En el modelo binario-relacional todas las relaciones son de grado 2, sólo tienen una llave y un valor”.

la consulta de negocios. Esto es precisamente el cambio de paradigma que existe en las denominadas bases de datos columnares, las cuales se basan en una particularización del modelo relacional denominado por un servidor como el Modelo Binario-Relacional. Dicha particularización se refiere a que es un modelo relacional, pero donde todas las relaciones son de grado 2, a diferencia del modelo relacional tradicional donde las relaciones son de grado “n” (es decir, pueden tener n-atributos o campos). Por lo tanto, en el modelo binario-relacional, todas las relaciones sólo tienen una llave y un valor; viéndolo todo entonces, como si fueran columnas independientes.

Beneficios en almacenamiento y desempeño

En el modelo binario-relacional el servidor puede utilizar un “thread” separado por cada columna de datos, permitiendo que el procesamiento de cargas y resolución de consultas se haga en paralelo. Se refleja claramente en la figura 2.

¿Por qué guardar tantos valores repetidos? ¿qué sucedería si se pudiera guardar cada valor una sola vez, eliminando duplicados; relacionando dicho valor tantas veces como sea requerido? La consecuencia lógica es que se disminuiría el tamaño del almacenamiento de datos.

El consenso tradicional indica que si uno tiene cierta cantidad de datos, al cargarlos en un RDBMS hay que considerar entre 20% y 30% de espacio adicional a lo que mida el archivo de entrada. Pero si es para un ambiente de data warehouse, entonces hay que considerar varias veces el tamaño de los datos de entrada (por los acumulados y la cantidad de índices requeridos para tratar de remediar el rendimiento); es así que, frecuentemente se calculan de 3 a 5 veces el tamaño de los datos de entrada.

Analicemos un ejemplo sencillo: en una cadena de tiendas departamentales (o cualquier otra organización), ¿cuántas facturas se generan en un año? Seguramente millones, pero pensemos que son 10 millones de facturas. Equivalente a 10 millones de fechas almacenadas, porque cada factura trae su fecha, pero sabemos que sólo existen 365 valores distintos en un año.

Figura 2. Tabla como conjunto de columnas

Esta es la segunda característica del modelo Binario-Relacional, y por tanto de las bases de datos columnares. El resultado es disminución de espacio considerable, típicamente entre 30% y 50%. El caso extremo

que se logró en México con una institución gubernamental es 88% de ahorro en disco, permitiéndole así mantener muchos más datos históricos sin sacrificar el rendimiento. De hecho, esta institución logro mejorar sus tiempos de respuesta 98% (una muestra de 128 consultas pasó de requerir 4 horas a tan solo 4 minutos). Para lograrlo se reemplazó el RDBMS tradicional por Sybase IQ. Los aplicativos no requieren cambios ya que se cuenta con interfases ODBC y JDBC y se interactúa por medio de ANSI SQL. Cifras similares se han logrado con diversas organizaciones de todos los sectores.

Las bases de datos columnares son ideales para ambientes de consultas no planeadas, ya que en cada columna se guardan valores únicos ordenados, lo que equivale a un índice, por tanto equivale a tener todas las columnas de todas las tablas indexadas, cosa que no se puede hacer en un manejador tradicional. Por lo tanto, cualquier consulta que se haga tendrá un índice que le ayudará a resolverlo rápidamente.

Conclusión En este artículo mostramos un panorama muy breve sobre las bases de datos columnares. Para mayor información se pueden consultar las memorias de la Conferencia Nacional Británica de Bases de Datos (BNCOD – British Nacional Conference on Databases) de los años 2004, 2005, 2006 y 2009.

El Dr. Víctor Gonzalez Castro es Director de Servicios Profesionales en Sybase de México. Es Ingeniero en Computación por parte de la UNAM y cuenta con estudios de Doctorado en Ciencias de la Computación con especialidad en Base de Datos por la Universidad de Heriot Watt, Reino Unido. Ha trabajado en empresas como Oracle, IBM, Probursa, Kmart, Software AG, Microstrategy y JD Edwards. victor.gonzalez@sybase.com

www.sg.com.mx

AGO-OCT 2009

43

// PRÁCTICAS

/*MEJORA DE PROCESOS*/

Líneas de Productos de Software Aplicando adaptación masiva al software por Gilberto Grajales

Como sabemos, los sistemas de software cada vez son más complejos, debido tanto a los pasos agigantados que da la tecnología, como a la importancia que continuamente cobran los sistemas de información en nuestras vidas. A lo largo de los años, nuevos métodos, técnicas y herramientas han sido creados para mitigar esta creciente complejidad de desarrollar software.

Una de las técnicas que han surgido para mitigar dicha complejidad, es la reutilización, la cual consiste en desarrollar elementos de software que puedan utilizarse más de una vez con la mínima cantidad de modificaciones, garantizando que al reutilizar un elemento de software libre de defectos, implicará que el sistema que lo utilice no tendrá problema alguno en lo que respecta a dicho elemento.

Tal fue el éxito de aplicar la reutilización, que ésta evolucionó de alguna manera hasta generar el concepto de “Líneas de Productos de Software” (LPS) –conocido también como Familias de Sistemas de Software– para el cual se conocen indicios desde los años 70 cuando Parnas mencionó los beneficios de tener una familia de sistemas compartiendo características entre ellos[1].

Adaptación de productos de forma masiva Las LPS parten de las ideas de la producción en serie (como lo hizo Henry Ford), dando la capacidad a una organización de producir o generar (nótese que no se usa el término desarrollar) sistemas de software en forma masiva, satisfaciendo las demandas del mercado; entre otros beneficios significativos. La adaptación masiva consiste en la capacidad para generar productos que comparten en gran parte características comunes, pero también mantienen características propias de cada uno de ellos.

Tomando como ejemplo una línea de productos de automóviles, se puede ver que para un modelo específico de auto se pueden fabricar unidades con características propias tales como el color, el número de puertas, transmisión automática o estándar, eléctrico o no, etcétera. Manteniendo las características esenciales del modelo.

Líneas de productos de software Según el Instituto de Ingeniería de Software (SEI) una LPS se define de la siguiente manera: “Una LPS es un conjunto de sistemas de software compartiendo características comunes y administradas que satisface las necesidades

específicas de un segmento de mercado particular o misión y que son desarrolladas de forma preescrita a partir de un conjunto común de elementos clave”.

Como lo indica la definición, una LPS consiste en un conjunto de elementos clave para producir sistemas de software que comparten características comunes (llamadas similitudes), pero al mismo tiempo mantienen características propias (llamada variabilidad). Para proporcionar estas características individuales a cada miembro de la familia, la adaptación masiva debe ser lo suficientemente flexible para satisfacer tal necesidad, pues además el número distinto de miembros está limitado a una serie de restricciones las cuales también deben satisfacerse; a esto se le llama administración de la variabilidad.

Fases o etapas para implementar una LPS En una LPS se propicia una reutilización a alto nivel, desarrollando los elementos comunes que servirán como base para la generación de cada miembro de la familia. Las etapas esenciales a ejecutar son tres: 1. De ingeniería de dominios en la cual se desarrollan los elementos comunes.

2. De ingeniería de aplicaciones donde se generan los sistemas que son miembros de la familia. Dichos miembros se generan a partir de los elementos comunes, pero tomando en cuenta el modelo de variabilidad definido.

3. Un conjunto de actividades que orquestarán las dos etapas anteriores.

Es decir, se necesita de un proceso para ejecutar de manera ordenada la ingeniería de dominios y la ingeniería de aplicaciones.

Las dos primeras etapas están compuestas por las fases tradicionales del modelo de cascada (Requerimientos, Diseño, Implementación, Pruebas) pero con objetivos distintos como ya se mencionó.

Enfoques de adopción de una LPS Se han planteado varios enfoques como estrategia para realizar la adopción de una LPS, entre ellos algunos tienen nombre distinto de acuerdo al “framework” o metodología en la que están contenidos, pero consisten en la misma estrategia. Básicamente, existen tres enfoques de adopción los cuales han sido reportados bajo otros nombres, sin embargo, en esencia son lo mismo. Dischos enfoques son:

Gilberto Grajales obtuvo el grado de Maestro en Ingeniería de Software en el Centro de Investigación en Matemáticas (CIMAT) realizando investigación sobre Líneas de Productos de Software aplicado al área de Ingeniería de Requerimientos. Ha jugado distintos roles en proyectos de desarrollo de software. Actualmente labora en JPE Consultores donde se dedica a la consultoría, capacitación y mejora de procesos en Ingeniería de Software. Tiene un especial interés en las áreas de Ingeniería de Requerimientos y Calidad de Software. Puede ser contactado en gilberto@jpeconsultores.com

44

AGO-OCT 2009

www.sg.com.mx

Proactivo: funciona cuando la implantación de la LPS se hace desde cero, es decir que aún no se cuenta con sistemas de software que pertenecerán a la familia. Debido a la complejidad y al enorme esfuerzo que demanda este enfoque, es apropiado para las empresas que tienen una visión muy clara de los productos que conformarán la familia, además de que tienen niveles de madurez para predecir con gran certeza tal proceso y cuentan con los recursos económicos y humanos suficientes para realizar la inversión.

Extractivo: inicia con la selección de uno o más sistemas ya existentes, que serán parte de la familia de productos; efectuando un tipo de ingeniería inversa para extraer los artefactos de software comunes para establecerlos como elementos comunes y modelar la variabilidad que existe entre ellos. Este enfoque es ad-hoc para organizaciones que quieren efectuar la transición de una manera rápida, de desarrollar sistemas individuales a generar sistemas a partir de una LPS. Reactivo: toma la esencia del proceso de espiral o iterativo para efectuar la transición poco a poco. Se realizan los pasos como en el enfoque proactivo, pero para cada ciclo o espiral, de esta manera se van eliminando riesgos y se va aclarando la visión de las similitudes y variabilidades de los productos que serán miembros de la familia. Es adecuado para organizaciones que mantienen planes de trabajo agresivos, que no pueden dedicar los recursos humanos suficientes para la adopción y sólo pueden disponer de un subconjunto de ellos.

Beneficios de una LPS

sistemas de software a partir de una plataforma de artefactos comunes de manera que los productos sólo necesiten ensamblarse en vez de ser desarrollados individualmente.

• Mejora la capacidad para el “Time-to-market”. Muchas veces las demandas del mercado exigen tener estrategias de mercadotecnia que implican tener productos o implementar ideas innovadoras antes de cierta fecha. Bajo un esquema tradicional de desarrollo de sistemas individualmente, dichas estrategias son demasiado difíciles de ejecutar haciendo perder a una organización la oportunidad de crecer en un mercado cambiante, pues como se dice por ahí: “el que pega primero pega dos veces”. Con una LPS, una organización puede tomar el reto de establecer estrategias de mercadotecnia agresivas, ya que cuentan con la capacidad de generar productos de forma acelerada. En la figura 1 se muestra una gráfica que representa el tiempo de desarrollo de sistemas de software con y sin una LPS, donde el eje horizontal representa el número de sistemas distintos desarrollados ,y el eje vertical el tiempo de liberación en el mercado. Como se puede ver al inicio, el tiempo de desarrollo de la LPS hace que éste sea mucho mayor que el desarrollo de los primeros sistemas individuales ,debido a que primero se deben desarrollar los elementos comunes, sin embargo, conforme se empiezan a desarrollar más sistemas, el tiempo de liberación en una LPS se reduce radicalmente en comparación al desarrollo individual, lo cual demuestra que a un mediano plazo los beneficios serán mucho mayores; pues como se mencionó, una organización se puede comprometer a liberar cierto producto de su LPS en menos de la mitad del tiempo que le llevaría desarrollarlo individualmente.

La implantación de una LPS no es una tarea sencilla, sino que requiere un gran esfuerzo y sobre todo una gran inversión para su éxito. Sin embargo, los beneficios obtenidos motivan a realizarlo.

Los beneficios de un proyecto de mejora de procesos de software han sido presentados y documentados[2, 3] y se dice que el retorno de inversión va en un rango de 5:1 de costo-beneficio. En un caso de estudio de la empresa Cummins Engine Inc.[4] se adoptó una LPS después de haber realizado un proyecto de mejora de procesos; y reportan que la mejora de procesos por sí sola tuvo un radio de costo-beneficio entre 2:1 y 3:1; y la implantación de la LPS en adición a la mejora de procesos arrojó un costo-beneficio de 10:1. Lo cual muestra evidencia de que si un SPI vale la pena, una LPS vale aún más.

Existen muchos beneficios que una LPS puede proporcionar, destacando los siguientes entre los más relevantes: • Obtención de las ganancias de una producción a gran escala.

Como se mencionó en la adaptación masiva, una LPS habilita a producir www.sg.com.mx

Figura 1. Time-to-Market con y sin una LPS.

AGO-OCT 2009

45

// PRÁCTICAS

/*MEJORA DE PROCESOS*/

• Reducción de costos de desarrollo. Con una LPS los costos de desarrollo de los sistemas miembros de la familia, están muy por debajo de los costos de desarrollo de sistemas individuales.

Al igual que en el “time-to-market”, al inicio el desarrollo de los elementos comunes tiene mayor costo que desarrollar un sistema individualmente. No obstante, una vez obtenidos, el costo disminuye. Se puede decir que la tasa de incremento en el costo acumulado es mucho menor en una LPS que en sistemas individuales.

• Mejora de la calidad de los productos. Desde que el desarrollo de los elementos comunes es similar al desarrollo de los artefactos para un sistema individual, dichos elementos son probados constantemente por cada producto generado, y por formar parte de todos los productos de la familia se puede decir que la calidad es más fácil y fielmente asegurada en todos ellos.

• Logro de las metas de reutilización de la organización. Dado que las LPS se basan en la reutilización de artefactos para un conjunto de sistemas, la reutilización planeada se obtiene al desarrollar la plataforma de elementos comunes.

• Reducción de la necesidad de contratar nuevo personal. Desde que el proceso de generación de los productos de software se automatiza cada vez más, la necesidad de contratar gente disminuye debido a que dichos productos son generados cada vez con menos ingenieros de software, lo cual de alguna manera ayuda a disminuir los costos a la organización.

• Incremento de la satisfacción del cliente. Por varios de los beneficios mencionados anteriormente, los clientes y usuarios de los sistemas generados con la LPS obtienen productos de software de mucha mayor calidad a precios mucho más bajos que los que obtendrían con un proveedor que no cuenta con una LPS.

cación de características relevantes de sistemas de software que pertenecen a un dominio. Se dice que estas características son aspectos del dominio visibles al usuario final.

A pesar de que el método FODA está compuesto de tres fases, para las cuales hay una serie de actividades individuales [6], la más relevante es la del modelado de características, pues es la que definirá las similitudes y variabilidades implícitas en el dominio. Dicho modelo de características se define por medio de un árbol donde quedarán especificados los elementos comunes y variables del dominio.

Por ejemplo, en la figura 2 se muestra un árbol de características para una línea de automóviles donde se pueden ver las características comunes (como la transmisión y el caballaje) y las características variables. Las variables pueden ser opcionales y estar contenidas o no en un sistema particular del dominio (como es el caso del aire acondicionado). También puede haber características alternativas de las cuales sólo una se puede implementar en un sistema particular del dominio (por ejemplo: la transmisión puede ser manual o automática,pero no ambas). Además, dentro de un modelo de características se pueden incluir algunas reglas de composición las cuales definen algunas relaciones entre características opcionales y/o alternativas.

Existen principalmente dos tipos de ellas: la primera es donde la existencia de una implica o requiere la existencia de la otra; y la segunda es donde la existencia de una implica o requiere que no exista la otra (que sean mutuamente exclusivas). Para nuestro mo-

Existen otros beneficios no menos importantes, sin embargo los que aquí se presentaron son los más significativos. Si se desea obtener más información acerca de estos otros beneficios se recomienda consultar el capítulo 2 en [4].

El método FODA Desde antes de existir el concepto de LPS existía la herramienta de análisis de dominio (AD), que se enfoca en analizar los aspectos comunes de un dominio particular que podíría consistir de un conjunto de sistemas relacionados. A partir de esto, surgieron muchos métodos de AD, siendo el método FODA (Feature-Oriented Domain Analysis) el que marcó una pauta en el desarrollo del AD, pues ha sido ampliamente utilizado para extraer las similitudes y variabilidades de un dominio. El principal objetivo de FODA es la identifi-

46

AGO-OCT 2009

Figura 2. Árbol de características para una línea de automóviles.

www.sg.com.mx

“Una LPS consiste en un conjunto de elementos clave para producir sistemas de software, que comparten características comunes, pero mantienen elementos propios”.

delo de ejemplo en la figura, existe una regla donde la existencia de aire acondicionado requiere que el caballaje sea mayor a 100.

Conclusiones En este artículo se dió un vistazo a los fundamentos sobre los que descansan las líneas de productos de software. Como se pudo ver, la misma complejidad del sofware hace que nuevos métodos sean desarrollados para mitigarla, como lo son las LPS. Pero además de intentar reducir la complejidad de desarrollo de software, las LPS tienen otros beneficios significativos, como la disminución del costo de desarrollo, que motivan a las organizaciones a tomar el reto de invertir en la implantación de una LPS.

www.sg.com.mx

Referencias [1]. Parnas, D.L. “On the Design and Development of Program Families”.

IEEE Transactions on Software Engineering, SE-2:1-9, March 1976.

[2] Ferguson, P. et al. “Software Process Improvement Works!” (CMU/SEI-99TR-027, ADA371804)”. Software Engineering Institute, November 1999.

[3] Goldenson, D. & Herbsleb, J. “After the Appraisal: A Systematic Survey of Process Improvement, its Benefits, and Factors that Influence Success (CMU/SEI-95-TR-009, ADA302225)”. Software Engineering Institute, August 1995.

[4] Clements, P. & Northrop, L. “Software Product Lines: Practices and Patterns”. Reading, MA: Addison-Wesley, 2002.

[5] Kang, K. et al. “Feature-Oriented Domain Analysis (FODA) Feasibility Study, Technical Report CMU/SEI-90-TR-21”. Software Engineering Institute, November 1990.

AGO-OCT 2009

47

// UML

Entre la parálisis por análisis y la necesidad de modelar ¿Qué Diagramas Hacer y Cuánto Tiempo Invertirles?

Por Jaime González

Una de las preguntas más importantes en el análisis y diseño de sistemas es: ¿Cuáles diagramas debemos hacer, y qué tanto tiempo debemos invertir en la diagramación? Un punto de vista rigorista y dogmático sobre el análisis y diseño de sistemas nos podría inducir a la ciega creencia de que invariablemente hay que modelar todo, extensamente y a profundidad, porque así lo marcan los cánones.

De ahí que proyectos realizados de acuerdo a lo que se piensa que son las “mejores prácticas” caigan en el síndrome de la parálisis por análisis: los equipos de análisis y diseño producen un diagrama tras otro, y se la pasan perfeccionando sus modelos de manera obsesiva, al grado en que no llegan a producir los sistemas para los cuales fueron contratados.

El anecdotario de la ingeniería de software tiene, en abundancia, no sólo historias de proyectos fracasados debido a la carencia de análisis y diseño adecuados, sino también de instancias de lo que podríamos llamar el lado obscuro de las así conocidas “metodologías”: para cumplir con todas y cada una de las exigencias del proceso, tal o cual proyecto se quedaron estancados en la producción de modelos de papel, en lugar de avanzar hacia el desarrollo de un sistema que cubriera los requisitos de los clientes y los usuarios.

El Proceso Unificado y UML cuentan con una buena variedad de disciplinas y artefactos, y nos podríamos pasar la vida tratando de plasmar en todo tipo de diagramas el análisis y el diseño de una solución. ¿Cómo aprovecharlos de manera sensata, de tal suerte que realmente ayuden a nuestros proyectos, sin caer en costos o en tiempos excesivos? La respuesta es relativamente simple: sólo debemos producir aquellos modelos que añadan valor suficiente a cada proyecto particular; sin embargo, para determinar qué es lo que consideramos “valor suficiente”, debemos considerar varios parámetros.

¿Para qué estamos modelando?

Tanto la extensión como la profundidad del modelado pueden

variar conforme a las razones y exigencias por las que estamos modelando. Los proyectos de software pueden ser muy diferentes tanto en magnitud como en distintos aspectos de su ambiente: hay equipos y analistas muy fogueados en el modelado, y también hay multitud de instituciones y empresas que apenas comienzan a utilizar procesos formales de desarrollo. Existen, asimismo, equipos de trabajo relativamente pequeños cuyos elementos participan durante todo el ciclo de vida de sus proyectos, y por otro lado existen organizaciones especializadas en análisis y diseño, que entregan sus modelos a terceros que se encargarán del desarrollo.

Supongamos que voy a realizar un desarrollo relativamente sencillo, y que yo mismo lo voy a programar. Mi enfoque, en este caso, puede consistir en realizar diagramas básicos de los casos de uso, con la intención de entender qué es lo que voy a resolver, y para generar documentación suficiente para acordar los alcances del desarrollo con mi cliente. En este caso, me conviene bosquejar las secuencias básicas de estos casos de uso, y por lo menos detectar las secuencias alternas. Si tengo experiencia con la herramienta de modelado, me conviene hacer un modelo conceptual, mismo que es indispensable para realizar los diagramas de secuencia más esenciales, y que va a devenir en el modelo de clases y el modelo de datos. Este modelo de diseño me va a resultar sumamente útil en entender cómo voy a resolver el desarrollo, y me va a ahorrar mucho tiempo de mi proyecto, dado que es más fácil corregir un diagrama que realizar correcciones extensivas al código. Pudiera apoyar mis decisiones de diseño con artefactos tales como diagramas de estado, pero usaría éstos sólo en los casos en que resultaran muy necesarios.

Ahora, imaginemos el caso de que no tengo experiencia en realizar modelos conceptuales, y mucho menos en diagramar secuencias, clases y modelos de datos. Más aún, supongamos que no tengo tiempo de experimentar con modelos conceptuales o diagramas de

Jaime González es PMP y experto en UML. Es consultor master e instructor senior en Milestone Consulting, la primer empresa mexicana miembro de la OMG, especializada en la capacitación práctica y consultoría en modelado y buenas prácticas de software. Jaime participó en la traducción al español del libro UML Distilled. info@milestone.com.mx www.milestone.com.mx

48

AGO-OCT 2009

www.sg.com.mx

“Sólo debemos producir aquellos modelos que añadan valor suficiente a cada proyecto”.

secuencia, pero tengo una idea muy clara de cómo convertir los casos de uso a pantallas, diálogos y código. Al igual que en el caso anterior, sería altamente recomendable crear el modelo de casos de uso para entender el problema, y también para poder acordar los alcances con el cliente y los usuarios. Muy probablemente, en toda esta variedad de casos, me apoyaría en bosquejos de pantallas y diálogos, o en prototipos con funcionalidad limitada, para lograr una mejor comprensión de lo que el usuario y el cliente desean.

El caso extremo, en contraste con los anteriores, sería el de una organización especializada en análisis y diseño, que genera modelos para que otra organización especializada realice la programación. En este caso, las secuencias básicas y alternas de los casos de uso resultan indispensables, así como la elaboración de diagramas de secuencia detallados que apoyen claramente los modelos de clases y de datos.

Los modelos, en ese caso, no servirían sólo para entender el qué y el cómo, sino que representan las especificaciones para los programadores.

Tanto la extensión como la profundidad del modelado deben, entonces, ser en primer lugar consecuencia de la pregunta: ¿para qué estamos modelando?

¿Qué tan crítico es el producto a desarrollar?

No es lo mismo desarrollar un sistema de consulta encaminado simplemente a facilitar el trabajo de un usuario, que un sistema de misión crítica, o un sistema del cual dependan las vidas de las personas. La “criticalidad” (por llamarle de alguna forma) del www.sg.com.mx

proyecto es, pues, otra consideración primaria para determinar la extensión y la profundidad del análisis y el diseño: un sistema de misión crítica requiere de una considerable inversión en el diseño, ya que la operación de una empresa, o la vida de personas, están en juego. La experiencia ha demostrado, invariablemente, que los sistemas con un alto grado de diseño son los más estables, y que requieren menor grado de correcciones y de mantenimiento.

¿Qué tan visible y sujeto a ser auditado es este proyecto?

Existe también el caso de proyectos con determinado grado de visibilidad (ya sea en el ámbito de las instituciones gubernamentales, como en el de los negocios), para los cuales existen exigencias específicas en cuanto a la documentación que deben producir, así como el hecho de que pueden estar sujetos a procesos de auditoría informática. Para estos casos, un análisis y un diseño adecuados son indispensables, y resulta obligatorio contar con personal experto para producir los modelos y la documentación requeridos.

Lo que debemos producir en un sistema funcional Finalmente, la consideración suprema para determinar tanto la extensión como la profundidad del análisis y el diseño consiste en tener claro que lo que vamos a producir es una solución o un producto, que debe estar correctamente alineado con los objetivos primarios de la institución o empresa que lo han solicitado. El análisis y el diseño no son objetivos en si mismos, sino que son tan sólo escalones para llegar a producir la solución.

AGO-OCT 2009

49

// PM CORNER

Dirección Ágil de Proyectos Mejorando Significativamente los Proyectos Por Angelica Larios

En los últimos años, corrientes como los métodos ágiles y el desarrollo de software esbelto, han cobrado popularidad en el ámbito del desarrollo de software como respuesta a las necesidades de los clientes, tratando de hacer procesos que sean más simples y fáciles de implementar. El desarrollo de software, como muchas otras disciplinas y áreas de conocimiento, no escapa al manejo y aplicación de los principios de la dirección de proyectos y viceversa, ésta última también se nutre del pragmatismo con el que otros ámbitos del conocimiento resuelven su situación. Así, la Dirección de Proyectos se ha influenciado de estas corrientes y ha incorporado algunas prácticas para hacerse más ágil y fácil de implementar.

La experiencia en el manejo de proyectos nos ha enseñado que sin el apego a metodologías, los proyectos pueden irse a la deriva, siendo nuestros clientes los principales afectados.

Afortunadamente, contamos ahora con tantas herramientas y ayuda disponibles, que si bien es cierto que en ningún caso son la panacea, la realidad es que hacen que los proyectos sean más llevaderos y sobre todo, con resultados más confiables, evitando sorpresas en el camino. En un ambiente tan competido como es el que vivimos actualmente, con una amplia oferta de soluciones y con tanto personal capaz, es imperativo reinventarnos constantemente, adaptarnos y renovarnos o morir. La práctica de Dirección Ágil de Proyectos puede darnos luz en ciertos puntos, a continuación algunos aspectos que considero relevantes: • Entregas anticipadas y continuas. La prioridad más alta es la satisfacción del cliente a través de la entrega anticipada y continua. La recomendación para la práctica de Dirección Ágil de Proyectos en cuanto a proyectos de desarrollo de software, es aplicarlo en los ámbitos en donde esto pueda funcionar. La práctica orientada a la satisfacción del cliente, será siempre una máxima de toda operación, proyecto u organización; la particularidad radica en la iteración de fases de construcción/pruebas/ liberación de forma tal que se aseguren entregables útiles para el negocio en periodos de tiempo cortos (típicamente en periodos que no exceden dos o tres semanas). Esto se logra a través de la interacción con el cliente, lo cual tiene resultados benéficos en cuanto al riesgo y el manejo de expectativas; de manera que el proyecto continúe de forma sana. Es por ello que cuando pueda

implementarse debe llevarse a cabo. Otra arista de este enfoque se refiere a la participación más cercana entre la gente técnica y la gente de negocio. El racional detrás, es que mientras más cerca y en contacto estés con el usuario final, la satisfacción del cliente y su compromiso con el entregable serán más altos. Lo que contribuye a obtener beneficios adicionales, entre ellos, es que la mejor forma de transmitir información es, y seguirá siendo cara a cara. Lo anterior también cuando se habla de la transferencia de conocimiento.

• El control de cambios. Bajo una perspectiva de desarrollo iterativo, el control de cambios no puede hacerse esperar. La idea clave en este segmento radica en que el cliente puede solicitar un cambio durante el proyecto siempre y cuando dicho cambio pueda priorizarse, y en su caso, conocer y aceptar las implicaciones que el cambio de alcance pueda tener en otros aspectos del proyecto. La idea principal es que el equipo de proyecto esté preparado, listo y dispuesto a responder a las solicitudes del cliente.

Contribuyendo a flexibilizar las características del producto final, situación más que conveniente en un mundo que cambia a ritmos más vertiginosos cada vez.

• Seccionar el proyecto. Divide el proyecto en partes, de forma que tengas entregables parciales. Muchas veces el cliente se impacienta al no ver resultados; y para continuar con el patrocinio del proyecto, se deben precisar los entregables y mostrar resultados en plazos más cortos de tiempo. La recomendación es acortar los ciclos de procesos. Si tu proyecto puede seccionarse en periodos más cortos, hazlo. Adicionalmente, recuerda que entre más lejos está el horizonte de planeación, mayores serán los riesgos de cumplir con las fechas comprometidas.

• Manten las cosas simples: KISS (“Keep it Short and Simple” o “Keep it Simple, Stupid”) es otro de los máximos principios de esta innovadora corriente de pensamiento de nuestra disciplina. En la medida en que mantengas el foco en el entregable principal, al conservarlo simple, la cantidad de trabajo se reduce.

Esto permitirá salir rápidamente con el producto y dejar los “nice to have” para fases posteriores. Aunque recuerda lo que decía Einstein: “Las cosas deben hacerse los suficientemente simples,

Angélica María Larios Arias es consultora y escritora especializada en sistemas de inteligencia de negocios y aplicaciones financieras. Actualmente es Vicepresidente de Comunicaciones y Relaciones Publicas del PMI Capítulo México. Es Licenciada en Informática, Maestra en Administración, cuenta con más de 10 años de experiencia en proyectos y tiene la certificación de Profesional en Dirección de Proyectos (PMP), entre otras. Ha sido panelista invitada en importantes eventos nacionales e internacionales. angelica.larios@gmail.com

50

AGO-OCT 2009

www.sg.com.mx

pero no más”. Este enfoque también aplica a los procesos usados para dirigir el proyecto y su documentación. Dicha corriente de pensamiento privilegia la orientación a la acción, sobre la orientación hacia la documentación.

mente algunas de ellas que a mi juicio son las de mayor relevancia y cuya implementación no requiere un esfuerzo mayor. Si las ponemos en práctica seguramente podemos mejorar significativamente nuestros proyectos.

• Mejora continua y lecciones aprendidas. Si bien es cierto que el enfoque tradicional de Dirección de Proyectos señala la importancia y relevancia hacia las lecciones aprendidas como parte de los procesos de cierre, en la Dirección Ágil de Proyectos se pretende tener de forma regular y constante, periodos de reflexión para que los equipos de trabajo se auto-regulen. El objetivo es que confronten su situación actual evaluando sus capacidades, debilidades y fortalezas para entonces realizar los ajustes pertinentes a la forma de trabajo del equipo. También es posible que de aquí surjan recomendaciones aplicables no sólo al proyecto, sino a nivel organizacional. Esto se logra a través de lo que se conoce como juntas de pie o stand up meetings, en donde religiosa y diariamente se reúne el equipo para que cada uno de sus integrantes presente un resumen de cómo está avanzando en sus actividades.

Independientemente del enfoque que le quieras dar a tu proyecto, es fundamental que entendamos que aquellas empresas, organizaciones, áreas y responsables de proyectos que no se den el tiempo de entender y analizar en qué van a invertir, enfatizando cómo es que van a manejar los proyectos que se han planteado para alcanzar sus metas, estarán prácticamente tirando su dinero a la basura. Y creo que todos estaremos de acuerdo en que no están los tiempos para eso.

En esta corriente ideológica existen muchas más recomendaciones y aplicaciones a seguir; sin embargo, he seleccionado sola-

Por esta vez me despido, esperando que el contenido del artículo haya sido de tu agrado y sobre todo de utilidad. ¡Buena Suerte!

www.sg.com.mx

Les recomiendo que estudien con mayor profundidad y seriedad la disciplina de Dirección Ágil de Proyectos, ya que aunque aparenta ser más laxa que un enfoque tradicional, su práctica efectiva requiere de una férrea disciplina así como de una profunda colaboración e íntima relación con el cliente del proyecto.

AGO-OCT 2009

51

// COLUMNA

/*PRUEBA DE SOFTWARE*/

Certificaciones Internacionales para Testers Un Elemento en la Profesionalización de la Industria 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 lustros, que incluyeron una estancia de posgrado en prueba de software en Alemania, en la que abordó aspectos formales de esa disciplina. Es autor de varias publicaciones nacionales e internacionales, e invitado frecuente en eventos relacionados con la prueba de software.

E

n números anteriores hemos hablado de modelos de calidad especializados en prueba de software, como el Test Process Improvement (TPI). Estos modelos se utilizan principalmente para el diagnóstico y la mejora de capacidades de organizaciones de prueba. Dichos modelos permiten medir la evolución de organizaciones en lo individual, pero también comparar organizaciones entre sí. Tal como ocurre con modelos como CMMI, este tipo de certificaciones generan ventajas competitivas a las organizaciones que las poseen, y al mismo tiempo contribuyen a poner a México en el radar de la industria internacional del software.

Que las organizaciones de prueba puedan evaluarse y certificarse está muy bien, pero es probable que más de uno de ustedes se pregunte ... “¿Y para las personas qué?”

Bueno, pues en esta ocasión abordaremos el tema de las certificaciones para testers, como un elemento posible en el desarrollo profesional de los mismos.

El perfil del tester En la plática que Martin Pol –reconocido consultor holandés– impartió recientemente en México , subrayaba el comentario que hacía Myers en los años 70: “La prueba de software no es sólo una más de las actividades necesarias en el desarrollo de software, sino una disciplina en sí misma”.

Myers decía también que la entidad que desarrolla un producto no debe ser la misma que la que lo prueba. Compartimos con ustedes la siguiente anécdota que ilustra el punto: Al principio del primer curso de prueba de software que tomó uno de nosotros aún siendo estudiante (hace ya una cantidad no despre-

ciable de años), el profesor comenzó diciendo: “En todo salón suele haber un (una) estudiante que hace sus apuntes sistemáticamente, y les da buena presentación; a él (ella) recurren muchos antes de un examen para fotocopiar los apuntes y estudiar utilizándolos; ¿quién es esa persona en este grupo?”. Luego de identificar al escribano, el profesor le pidió pasar al frente con sus apuntes y los hojeó: “Efectivamente, son muy buenas notas; a mí también me servirían para estudiar” dijo; acto seguido sacó un encendedor y le dijo al compañero: “Tenga, quémelos. Le pongo 100 en el curso”.

Desconcertado, el escribano, comentó primero que en realidad iba al curso por aprender, no por la calificación, pero ante la insistencia reconoció que en el cuaderno tenía también apuntes de otras materias, y que en las otras no le pondrían 100 por la incineración. El profesor comentó: “Cuando construimos algo que nos interesa, solemos imprimirle cierta dedicación y entusiasmo; eso mismo genera una barrera mental que nos dificulta encontrar fallas en lo que hicimos. Esa misma barrera se presenta al hacer la prueba de software”.

La prueba requiere de un perfil sicológico particular, que es distinto del de los desarrolladores, y que incluye, entre otras cosas, un sentido crítico bien desarrollado y la habilidad para detectar fallas, omisiones e inconsistencias (una mente “negativa”), así como para comunicarlas adecuadamente (de una manera “positiva”).

La carrera como tester Un tester debe conocer distintas técnicas de prueba, así como el proceso y algunas herramientas para ello. En entregas anteriores de esta misma columna que se publicaron en SG de septiembre 2005 a abril

2006, describimos brevemente algunas de estas técnicas y herramientas.

Los testers pueden ganar experiencia y especializarse en algún (as) de las distintas áreas de la prueba, siguiendo rutas de un “plan de carrera”, que representan alternativas de desarrollo profesional que dejan claro cómo se puede ir creciendo dentro de una organización.

La relevancia de un plan de carrera se ejemplifica en una anécdota más: Trabajando aún en la universidad, uno de nosotros recibió la llamada del director de operaciones de una empresa local para que se le recomendara “un buen alumno que esté a punto de graduarse y que haya tomado al menos una materia de prueba de software; queremos fortalecer nuestro departamento de pruebas”; se le recomendaron varios candidatos. El siguiente semestre, se recibió la llamada del mismo director para que se le recomendara “un buen alumno que esté a punto de…”. Luego de explicitar que el estudiante que se le había recomendado hacía unos meses había dejado la empresa comentó que “se fue a -la trasnacional X- por unos pesos más”. Ahondando en el punto, resultó claro que no se había ido sólo por mejorar su ingreso o por entrar a una trasnacional, sino también como consecuencia de la ausencia en la organización de un plan de carrera para testers, que originó que el estudiante se sintiera desorientado.

El bosquejo de un plan de carrera puede obtenerse generalizando posibles rutas de certificación existentes, que se esbozan en la Tabla 1.

Harían falta, entre otras cosas, los sueldos asociados a los distintos niveles, así como las métricas concretas de productividad y efectividad.

Berenice Ruíz Eguino es consultora de e-Quallity en proyectos de mejora de organizaciones de prueba. A lo largo de su trayectoria profesional ha actuado también como tester senior, administradora de proyectos de prueba nacionales e internacionales, y directora de operaciones. Ha sido profesora de la Universidad Autónoma de Guadalajara, institución en la que realizó sus estudios de Maestría en Ciencias Computacionales.

52

AGO-OCT 2009

www.sg.com.mx

Las certificaciones para testers

Notas:

A diferencia de los títulos académicos como las licenciaturas, las maestrías y los doctorados, las certificaciones se orientan más bien a auscultar y reconocer el nivel de experiencia de las personas.

• La “carrera universitaria corta” del nivel básico se refiere a un equivalente al “Técnico Superior Universitario” de las Universidades Tecnológicas, que requieren 2 años de estudio después de la preparatoria.

•En el caso del nivel intermedio suele abrirse la posibilidad de especializarse en pruebas funcionales (caja negra), en pruebas estructurales (caja blanca), o en administración de proyectos.

• Las certificaciones suelen ser acumulativas: para certificarse en el nivel intermedio es necesario haber obtenido la certificación básica, y el

Como en el caso de otras disciplinas, las certificaciones para testers ofrecidas en el mercado suelen estar escalonadas en tres niveles: básico, intermedio y avanzado, aunque existen variaciones entre los distintos organismos.

La tabla 1 muestra el resultado del análisis de características generales.

avanzado requiere la certificación en alguna de las especialidades intermedias.

En la siguiente entrega de esta columna seguiremos hablando con mayor profundidad sobre el tema de certificaciones para testers.

Hasta entonces. » Por Luis Vinicio León / Berenice Ruíz

Referencias [1]. Myers, G. The art of software testing.

John Wiley & Sons, 1972

Tabla 1. Características generales de las diferentes certificaciones como tester.

www.sg.com.mx

AGO-OCT 2009

53

// COLUMNA

/*PROGRAMAR ES UN MODO DE VIDA*/

Manteniendo el Estado en Nuestras Aplicaciones Web Una Historia de Galletas y Resúmenes Gunnar Wolf es administrador de sistemas para el Instituto de Investigaciones Económicas de la UNAM; entusiasta y promotor del Software Libre, desarrollador del proyecto Debian GNU/Linux desde el 2003, miembro externo del Departamento de Seguridad en Cómputo de DGSCA-UNAM desde 1999.

U

na grandísima proporción de los sistemas desarrollados hoy en día siguen el paradigma cliente-servidor. Y si bien hay diferentes maneras de implementarlo, indudablemente la más utilizada actualmente es la de los sistemas Web. La conjunción de un protocolo verdaderamente simple para la distribución de contenido (HTTP) con un esquema de marcado (markup) suficientemente simple, pero también suficientemente rico para presentar una interfaz de usuario con la mayor parte de las funciones requeridas por los usuarios (HTML) crearon el entorno ideal para el despliegue de aplicaciones distribuidas.

El estándar del protocolo HTTP define cuatro “verbos”, que a su vez definen distintos tipos de solicitudes: • GET: solicitud de información sin requerir cambio de estado.

• POST: interacción por medio de la cual el cliente manda información compleja, que determinará la naturaleza de la respuesta.

• PUT: creación de un nuevo objeto en el servidor.

• DELETE: destrucción de un determinado objeto en el servidor.

En la práctica, la mayoría de los sistemas web hace caso omiso de estos verbos, ignorando a través de qué verbo llegó una solicitud determinada. Incluso varios navegadores ni siquiera implementan PUT y DELETE, dado su bajísimo nivel de uso. Aunque con la popularización del paradigma REST, esto probablemente esté por cambiar.

El protocolo HTTP, sin embargo, junto con su gran simplicidad aportó un gran riesgo: deja en el programador la responsabilidad de implementar cómo manejar la interacción repetida sobre un protocolo que delega el mantener el estado o “sesión” a una capa superior. HTTP fue concebido como un protocolo a través del cual se solicitaría información estática, por lo que para un servidor HTTP toda solicitud es única. A esto nos referimos cuando decimos que es un protocolo sin estado (stateless).

En los sistemas web más primitivos, la forma de simular “sesiones” es incluyendo en cada solicitud toda la información del estado. Dichos sistemas hacen un uso extensivo de los campos ocultos (hidden) en todos los formularios y ligas internas, transportando en cada solicitud información tal como: quién es el usuario en cuestión, en qué paso de una transacción se encuentra, preferencias que ha manifestado a lo largo de su interacción.

54

AGO-OCT 2009

Sin embargo, dicho mecanismo resulta no sólo engorroso, sino también muy frágil: un usuario malicioso o curioso (llamémosle “atacante”) puede verse tentado a modificar estos valores; es fácil capturar y alterar los campos de una solicitud HTTP a través de herramientas de depuración. E incluso sin estas herramientas, el protocolo HTTP es muy simple, y puede “codificarse” a mano, sin más armas que un telnet abierto al puerto donde escucha nuestro sistema. Cada uno de los campos y sus valores se indican en texto plano, y modificar el campo «user_id» es tan fácil como decirlo.

En 1994, Netscape introdujo un mecanismo denominado “galletas” (cookies) que permite al sistema almacenar valores arbitrarios en el cliente. El uso de las galletas libera al desarrollador del lío antes mencionado, y le permite implementar fácilmente un esquema verdadero de manejo de sesiones. Pero ante programadores poco cuidadosos, abre muchas nuevas maneras de –adivinaron– cometer errores.

Dentro del cliente (típicamente un navegador) las galletas están guardadas bajo una estructura de doble diccionario. En primer término, toda galleta pertenece a un determinado servidor (esto es, al servidor que la envió). La mayor parte de los usuarios tienen configurados sus navegadores, por privacidad y por seguridad, para entregar el valor de una galleta únicamente a su dominio origen (de modo que al entrar a un determinado sitio hostil, éste no pueda robar nuestra sesión en el banco). Sin embargo, nuestros sistemas pueden solicitar galletas arbitrarias guardadas en el cliente. Para cada servidor podemos guardar varias galletas, cada una con una diferente llave, un nombre que la identifica dentro del espacio del servidor. Además de estos datos, cada galleta guarda la ruta a la que ésta pertenece, si requiere seguridad en la conexión (permitiendo sólo su envío a través de conexiones cifradas), y su periodo de validez, pasado el cual serán consideradas “rancias” y ya no se enviarán. El periodo de validez se mide según el reloj del cliente.

Guardar la información de estado del lado del cliente es riesgoso, especialmente si es sobre un protocolo tan simple como HTTP. No es difícil para un atacante modificar la información que enviaremos al servidor, y si bien en un principio los desarrolladores guardaban en las galletas la información de formas parciales, llegamos a una regla de oro: nunca guardar información real en ellas. En vez, guardemos algo que “apunte” a la información. Esto es por ejemplo: en vez de guardar el ID de nuestro usuario, mejor guardamos una cadena encriptada que apunte a un registro en nuestra base de datos. En este mismo sentido, tampoco debemos grabar directamente el ID de la www.sg.com.mx

sesión (siendo sencillamente un número, sería trivial para un atacante probar con diferentes valores hasta “aterrizar” en una sesión interesante), sino una cadena aparentemente aleatoria, creada con un algoritmo que garantice una muy baja posibilidad de colisión y un espacio de búsqueda demasiado grande como para que un atacante lo encuentre a través de la fuerza bruta.

Los algoritmos más comunes para este tipo de uso son los llamados funciones de resumen (digest), que generan una cadena de longitud fija. Dependiendo del algoritmo, hoy en día van de los 128 a los 512 bits.

Las funciones de resumen más comunes en la actualidad, son las variaciones del algoritmo SHA desarrollado por el NIST y publicado en 1994. Usar las bibliotecas que los implementan es verdaderamente común.

Por ejemplo, usando Perl: use Digest::SHA1; print Digest::SHA1->sha1_hex(“Esta es mi llave”);

nos entrega la cadena: c3b6603b8f841444bca1740b4ffc585aef7bc5fa

Pero, ¿qué valor usar para enviar como llave? Definitivamente no queremos enviar, por ejemplo, el ID de la sesión. Esto nos pondría en una situación igual de riesgosa que incluir el ID del usuario, ya que un atacante puede fácilmente crear un diccionario del resultado de aplicar SHA1 a la conversión de los diferentes números en cadenas. El identificador de nuestra sesión debe contener elementos que varíen según algún dato no adivinable por el atacante (como la hora exacta del día, con precisión a centésimas de segundo) o, mejor aún, con datos aleatorios.

Este mecanismo nos lleva a asociar una cadena suficientemente aleatoria como para que asumamos que las sesiones de nuestros usuarios no serán fácilmente “secuestradas” (esto es, que un atacante no le atinará al ID de la sesión de otro usuario), permitiéndonos dormir tranquilos sabiendo que el sistema de manejo de sesiones en nuestro sistema es prácticamente inmune al ataque por fuerza bruta. www.sg.com.mx

Consideraciones Recuerden que algunas personas, por consideraciones de privacidad, han elegido desactivar el uso de galletas en su navegación diaria, a excepción de los sitios que expresamente autoricen. Tomen en cuenta que una galleta puede no haber sido guardada en el navegador cliente, y esto desembocará en una experiencia de navegación interrumpida y errática para dichos usuarios. Es importante detectar si, en el momento de establecer una galleta, ésta no fue aceptada, para dar la información pertinente al usuario, para que sepa qué hacer y no se encuentre frente a un sistema inoperante.

Retomando el asunto de las acciones invocadas a partir de recibir una petición tipo GET, un criterio de diseño debe ser que toda solicitud GET sea “idempotente”. Es decir que un GET no debe alterar de manera significativa el estado de los datos. Un GET puede por ejemplo: aumentar el contador de visitas, pero no generar cambio substantivos a los datos. Un ejemplo de algo que no se debe hacer sería permitir que por medio de un GET se pudiera eliminar cierto objeto.

Si hacemos esto, corremos el riesgo de que dicha acción sea disparada de forma inesperada e indiscriminada por robots indexadores de buscadores como Google. Es por ello que toda acción que genere un cambio en el estado sustantivo de nuestra base de datos debe llevarse a cabo a través de una solicitud tipo POST.

Referencias [1]. Descripción del protocolo HTTP implementado en 1991. www.w3.org/Protocols/HTTP/AsImplemented.html [2]. Mecanismo de manejo de estado sobre HTTP, RFC 2965. www.ietf.org/rfc/rfc2965.txt [3]. Funciones criptográficas de resumen. en.wikipedia.org/wiki/Cryptographic_hash_ function [4]. Funciones de resumen SHA. en.wikipedia.org/wiki/SHA_hash_functions

» Por Gunnar Wolf

AGO-OCT 2009

55

// COLUMNA

/*tendencias en SOFTWARE*/

El Futuro de las Plataformas de Software Aprovechando las Posiblidades de la Nube

Luis Daniel Soto Director de Divulgación Tecnológica para Microsoft. Responsable de la cuarta área de trece a nivel mundial en atención a desarrolladores de software. Coordina el esfuerzo de un grupo de 100 personas encargadas de Divulgación Tecnológica en América Latina.

Ingeniero en computación por la Fundación Arturo Rosenblueth, especialista en el tema de liberación al mercado de nuevas tecnologías y toma electrónica de decisiones. luisdans@microsoft.com luisdans.com\Twitter

L

a última década fue ciertamente significativa en términos de resolver el problema de la portabilidad del software. Prueba de ello son ejemplos como los siguientes: • Hoy es posible utilizar Java en teléfonos celulares, en múltiples sistemas operativos y en arquitecturas de hardware basadas en microprocesadores muy distintos.

• .NET ha ofrecido también independencia de lenguaje materializando no únicamente simetría del modelo de programación en el cliente y en el servidor, sino más allá: Silverlight incluye una versión de .NET que opera dentro en Internet Explorer, Firefox, SeaMonkey, Safari, Chrome y Opera, tanto en PC como en Macintosh y Linux, mediante Moonlight.

• Stonehenge (http://sn.im/lj94g) es una aplicación de referencia que demuestra mejores prácticas de integración entre sistemas Java, .NET y PHP – esta última, un modelo ampliamente aceptado en la web. El proyecto se extenderá en el futuro hacia otras plataformas.

• A pesar de estos avances en portabilidad, el tema de realizar las pruebas en cada plataforma y la capacidad de ofrecer soporte técnico continúa siendo costoso (desde la visión de un software que opere en cualquier dispositivo, aprovechándolo al máximo).

El siguiente paso: centros de datos públicos en la nube La evolución de la web nos ofrece una nueva posibilidad: aprovechar la infraestuctura de cómputo de empresas como Yahoo, Microsoft, Google y Amazon. En el caso de Microsoft, su oferta de cómputo en la nube está basada en la plataforma de servicios Windows Azure. Éste, es un ambiente de ejecución (runtime) para aplicaciones, que opera en centros de datos “públicos” (compartidos por usuarios).

La nube ofrece ventajas reales a problemas existentes en TI: • Pago por uso, no por propiedad.

• Reducción de costos al compartir la infraestructura de TI con otros “inquilinos”.

• Escalabilidad inmediata para responder a aumentos repentinos en carga de trabajo.

• Disminución del tiempo para habilitar nuevas aplicaciones.

Dando el salto a la nube Si bien es claro que un primer paso es “virtualizar” aplicaciones existentes y llevarlas de un equipo físico a una máquina virtual, o posiblemente a un centro de datos externo, en este escenario

56

AGO-OCT 2009

continúa presente un punto único de falla, y la escalabilidad se puede volver muy costosa, por lo que no es suficiente. Sin duda, a lo largo del tiempo se considerará construir los nuevos sistemas bajo las nuevas abstracciones, porque resuelven internamente los problemas de escalabilidad a miles de procesadores, administración de sistemas automatizada y privacidad, aun con múltiples empresas compartiendo infraestructura.

Las empresas deben estar preparadas para soportar las dimensiones de cómputo que les den ventajas tales como: uso del software existente en un esquema de virtualización; explotación del software en el servidor, la PC y dispositivo móvil; y aprovechamiento de las nuevas plataformas tecnológicas en la nube, –las experiencias llegarán a múltiples dispositivos permitiendo el acceso en cualquier lugar.

Combinando software local y en la nube La frase “cómputo en la nube” es muy amplia y casi nunca dice lo suficiente, pero lo que es claro, es que cada día menos personas anticipan que 100% de aplicaciones y datos se almacenen en Internet, es irreal pensar en ello. La combinación de software local y en la nube, permite casos completamente nuevos en la industria de software, por ejemplo: la empresa Iron Mountain complementa su servicio de manejo de archivo muerto físico con el servicio de almacenamiento de archivo muerto digital en la nube; ThoughtBridge, una empresa de consultoría en desarrollo de software, crea y vende extensiones para Sharepoint Online para la gestión de RH.

Consideraciones Una plataforma tecnológica para la nube, deberá soportar características particulares de la misma. Por ejemplo: se requiere de servicios que conecten una nube “privada” con la nube “pública” para escenarios de integración. Para escenarios web orientados al consumidor, se requieren también nuevos servicios como los de administración de datos y aplicaciones en el centro de datos, sin importar que éste se encuentre ubicado internamente, en un hosting dedicado o en la nube pública.

El resultado final: flexibilidad, agilidad, eficiencia y capacidad de enfoque en valor y no en mantener la infraestructura. El futuro de la plataforma de software es habilitar y hacer posible la nueva visión con un alto enfoque de productividad.

» Por Luis Daniel Soto

www.sg.com.mx

www.sg.com.mx

AGO-OCT 2009

57

// COLUMNA

/*ENTREGANDO VALOR*/

El Gobierno Corporativo de TI Entendiendo su Propósito y Dominios

Gloria Quintanilla es Directora de Innovación y Desarrollo de Itera. Cuenta con más de 20 años de experiencia en dirección y gestión de proyectos y servicios de TI. Ha sido miembro del Comité Técnico Nacional de Normalización en Sistemas de Calidad. Fue miembro fundador y presidente en dos ocasiones de la AMCIS. Actualmente es VP de Estándares del Capítulo México del Project Management Institute (PMI) y es Coordinadora del Comité Técnico Nacional para la atención de la ISO en Administración de Proyectos. Gloria es Instructor COBIT Autorizado por ISACA y sus certificaciones incluyen: Auditor Líder ISO 9000, Project Management Professional, ITIL Service Manager, Certified RUP Consultant y Certified MSF Practitioner.

B

ienvenidos a este nuevo espacio en el cual estaré compartiendo con ustedes perspectivas, conocimiento y experiencia respecto al Gobierno Corporativo de las Tecnologías de la Información (GCTI) y su relación con otros marcos y mejores prácticas de gestión de TI.

¿Qué es el Gobierno Corporativo de las TI? El GCTI se refiere a la capacidad que tiene una organización de dirigir y controlar la función de las tecnologías de información para asegurar que sostienen y extienden sus objetivos estratégicos mediante la realización efectiva de proyectos, la provisión de servicios de alta calidad, la gestión de riesgos y la optimización de recursos.

El estándar líder a nivel mundial sobre GCTI es COBIT®, acrónimo del inglés “Control Objectives for Information and related Technologies”. COBIT fue elaborado por el IT Governance Institute (ITGI)[1], un organismo creado por la Information Systems Audit and Control Association (ISACA)[2], y su primera versión fue liberada en 1996.

Les recomiendo leer el artículo “COBIT 4.1 Executive Summary and Framework” que pueden descargar sin costo[3] y que contiene una buena introducción a COBIT y su estructura.

Problemática que impulsa la adopción de GCTI Entre los impulsores más comunes para adoptar un marco de control para el GCTI se encuentran las siguientes problemáticas: • Falta de claridad en la rendición de cuentas de los servicios y proyectos de TI. No existen responsables últimos designados para asegurar que las inversiones realizadas en TI entreguen los beneficios esperados por la organización.

• Existencia de una brecha (que tiende a ensancharse) entre lo que el departamento de TI piensa que necesita el negocio y lo que el negocio piensa que el departamento de TI puede proveer.

• Unificación de las mejores prácticas. La mayoría de las organizaciones de TI (proveedores de servicios de TI internos o externos) ya han iniciado proyectos de mejora para introducir mejores prácticas basadas en modelos de referencia. El problema al que se enfrentan éstas organizaciones es la unificación armónica de dichas iniciativas en un programa de mejora cohesivo, alineado a los objetivos y prioridades del negocio. Frecuentemente estas iniciativas son independientes y en lugar de crear sinergia compiten por recursos y carecen de un lenguaje común, lo cual lleva al fracaso. Entre los estándares y marcos de referencia más usados se encuentran: en el ámbito de planificación estratégica y gestión de procesos el BSC e ISO 9001; en gestión de proyectos PMBoK y PRINCE 2; en gestión de servicios

58

AGO-OCT 2009

el ISO 20000 y el ITIL; en solución técnica e Ingeniería de Software tenemos CMMI, RUP, y MoProSoft; en arquitectura empresarial TOGAF y el Zachman; y finalmente en el ámbito de seguridad de TI el ISO 27000.

• Falta de visibilidad del valor que entrega la tecnología de información. La TI se percibe como un “mal necesario”, no hay un entendimiento claro y compartido del valor que entregan a la organización.

• Se carece de mecanismos para dirigir y controlar el desempeño de TI. No existen objetivos acordados y comunicados a todos los interesados y no se reporta el rendimiento con respecto a estos objetivos.

• La empresa enfrenta problemas y se encuentra expuesta sin control a una serie de riesgos de TI (por ejemplo, seguridad de la información) que afectan su capacidad de lograr los objetivos estratégicos.

Dominios de COBIT COBIT establece que el Gobierno Corporativo de TI tiene 5 áreas clave de atención que en su conjunto aseguran la creación de valor de TI y evitan que se pierda el valor ya creado. Estos cinco dominios son: • La alineación estratégica que asegura la alineación entre los objetivos de negocio y los objetivos y planes de TI. • La entrega de valor que asegura que la inversión en TI (proyectos, servicios y activos) entregue al negocio los beneficios prometidos en apoyo a la estrategia.

• La administración de riesgos que asegura que los riesgos de negocio asociados a la adopción, operación, uso o involucramiento de las TI, se encuentran bajo control y que haya una asignación de responsabilidades sobre su gestión.

• La gestión de recursos que asegura que se optimice el conocimiento y los activos de TI. • La evaluación del desempeño para medir la función de TI, en relación a los objetivos establecidos y la efectividad en la realización de proyectos y servicios.

En las siguientes columnas estaremos tratando cada uno de estos dominios en mayor detalle.

» por Gloria Quintanilla

Referencias [1]. www.itgi.org [2]. www.isaca.org [3]. www.isaca.org/cobit www.sg.com.mx

INDEX

DIRECTORIO

TENEMOS UN ESPACIO RESERVADO PARA TI

Anunciante

Páginas

Ciudades Digitales 63 Comunicarum 51 JPE Consultores 59 e-Quallity 49 Gartner 57 Gelattina 53 Itera 47 Kernel 19 Nextel 09 Matersys 2F, 1 Milestone 4F NYCE 3F Qualtop 15 SG 09 Conferencia y Expo 20 SG Guía 11 SG Revista Digital 55 Sistemas Humanos 25

Sitio www.ciudades.gob.mx www.comunicarum.com www.jpeconsultores.com www.e-quallity.net www.gartner.com/mx/futureit www.gelattina.com www.it-institute.org www.kerneltechnologies.com www.nextel.com.mx www.matersys.com.mx www.milestone.com.mx www.nyce.org.mx www.qualtop.com www.sg.com.mx/sg09 www.sg.com.mx/guia www.sg.com.mx www.humanos.com.mx/agiles

Si deseas anunciarte contáctanos en el (55) 5239 5502 o en publicidad@sg.com.mx www.sg.com.mx

AGO-OCT 2009

59

// fundamentos

Servicios Web Basados en REST Arquitecturas web orientadas a recursos por Nathanael Gutiérrez

¿Has checado tu facebook recientemente? ¿Escribiste en 140 caractéres vía twitter lo que hiciste hoy? ¿Estás suscrito a un canal RSS de algún blog interesante? ¿Envías bookmarks a del.icio.us? Si respondiste que sí a por lo menos una de estas preguntas, entonces este artículo te interesa. Parte del éxito de estos servicios en la web, es la arquitectura sobre la que fueron desarrollados. Dicho estilo arquitectónico es conocido como REST y en este artículo conoceremos un poco al respecto.

¿Qué es REST? El término REST (Representational State Transfer) se refiere a un estilo arquitectónico propuesto en el año 2000 por Roy Fielding.

Conforme han pasado los años, REST ha cobrado gran popularidad, y se ha convertido en la recomendación de facto para diseñar arquitecturas de aplicaciones web modernas.

Vale la pena aclarar que REST no es un estándar. No existe una especificación formal de REST, y tampoco encontrarás un kit de desarrollo para REST. Simplemente es un estilo arquitectónico, y por lo tanto no se puede embotellar. Simplemente hay que entenderlo para poder diseñar aplicaciones que cumplan el estilo REST. De acuerdo con Fielding: “Representational State Transfer pretende evocar una imagen de cómo se comporta una aplicación web bien diseñada: es una red de páginas web (una máquina virtual de estados), donde el usuario navega a través de la aplicación al ir seleccionando hiperligas (transiciones de estados), que resultan en una nueva página (el nuevo estado de la aplicación) siendo transferida y desplegada al usuario.”

Habiendo explicado la filosofía detrás de REST, procedamos a conocer los fundamentos de los servicios web basados en REST. Un RESTful web service, o servicio web basado en REST típicamente sigue cuatro principios de diseño: 1. Utiliza los métodos HTTP de manera explícita 2. No mantiene estados 3. Expone URIs en forma de directorios 4. Transfiere datos por medio de XML y/o JSON Veamos a que se refiere cada uno de estos principios.

Utiliza los métodos HTTP de manera explícita En REST las operaciones disponibles sobre los recursos son siempre las mismas y su semántica es conocida por todos los clientes y servicios. Empatando esto con los tipos de solicitud de HTTP tenemos que: • POST: Crea un recurso • GET: Obtiene un recurso

60

AGO-OCT 2009

• PUT: Cambia el estado de un recurso • DELETE: Elimina un recurso Es común encontrar aplicaciones que utilizan el método GET para agregar o modificar datos, lo cual no va de acuerdo con lo que REST recomienda. Veamos el siguiente ejemplo de una petición GET: GET /agregarusuario?nombre=Nao HTTP/1.1 Si la petición se procesa con éxito, un nuevo usuario sería agregado a la base de datos. Aquí el primer problema es semántico, pues los servidores web están diseñados para responder a las peticiones HTTP GET con la búsqueda de recursos que concuerden con la ruta del URI y devolver esta representación en respuesta, mas no añadir un registro a la base de datos. Desde el punto de vista del protocolo y del servidor web compatible con HTTP/1.1, este uso del GET es inconsistente. El otro problema, y mucho más grave, es que al ejecutar eliminaciones, modificaciones o creación de registros en la base de datos de esta forma, se puede provocar que las herramientas de caché web y los motores de búsqueda realicen cambios no intencionales en el servidor.

Para evitar estos problemas se utiliza una petición REST, que consiste en cambiar los nombres y valores de los parámetros en la petición del URI a tags XML. Los tags resultantes, son enviados en el cuerpo de un HTTP POST cuyo URI de petición es el padre de la entidad. Entonces, una petición correcta quedaría de la siguiente forma: POST /usuarios HTTP/1.1 Host: www.example.com Content-type: application/xml <usuario> <nombre>Nao</nombre> </usuario> De esta forma existe un uso correcto de HTTP POST y la inclusión de los datos en el cuerpo de la petición. Recordemos que GET se usa solamente para recuperar datos y es una operación que no debe poder alterar datos.

No mantiene estados En un servicio web REST, el cliente envía peticiones que incluyen todos los datos necesarios para cumplir el pedido, de manera que los componentes en los servidores intermedios puedan gestionar la carga sin mantener localmente el estado entre las peticiones.

El servidor es el responsable de generar las respuestas y proveer www.sg.com.mx

“Los servicios sin estado son mucho más simples de diseñar, escribir y distribuir a través de múltiples servidores”.

una interfaz que le permita al cliente mantener el estado de la aplicación. De esta forma se mejora el rendimiento de los servicios web y se simplifica el diseño e implementación. Además se elimina la necesidad de sincronizar los datos de la sesión con una aplicación externa.

En la plataforma JEE, un entorno de servicios con estado necesita bastante análisis y diseño para poder almacenar los datos eficientemente y poder sincronizar la sesión del cliente dentro de un cluster de servidores. Aquí ocurre un problema que le resulta familiar a los desarrolladores de servlets/JSP y EJB, quienes a menudo tienen que buscar la causa de una java. io.NotSerializableException cuando ocurre la replicación de una sesión. Puede ocurrir tanto en el contenedor de Servlets al intentar replicar la HttpSession o en el contenedor de EJB al replicar uno con estado. Además, la sincronización seguro que impactará negativamente en el rendimiento del servidor.

Los servicios sin estado son mucho más simples de diseñar, escribir y distribuir a través de múltiples servidores. Un servicio sin estado no sólo funciona mejor, sino que además mueve la responsabilidad de mantener el estado al cliente de la aplicación.

Expone URIs en forma de directorios Las URI deben ser intuitivas y funcionar como una interfaz auto-documentada que necesita de muy poca explicación para que un desarrollador pueda comprender a lo que apunta y cuales son los recursos derivados relacionados. Una forma de lograr este nivel de usabilidad es definir URIs con una estructura al estilo de los directorios. Dicha estructura jerárquica cuenta una ruta raíz única, y va abriendo ramas a través de las subrutas para exponer las áreas principales del servicio, lo que da como resultado un árbol con subordinados y padres organizados como nodos.

Ejemplo: http://www.xyz.org/discusion/temas/{id-de-tema} En este ejemplo, la raíz /discusion tiene un nodo /temas como hijo, y bajo este hay un conjunto de temas (tecnología, actualidad, etc.), cada uno de los cuales apunta a un hilo de discusión. Dentro de esta estructura resulta fácil recuperar hilos de discusión al escribir algo después de /temas/. Una gran ventaja es que estaremos ocultando la tecnología usada en el servidor que aparecería como extensión de archivos (.jsp, .php, .asp), de manera que en un futuro podemos mudar la solución a otra tecnología sin cambiar las URI, permitiendo que el cliente pueda generar bookmarks que permanezcan válidos. www.sg.com.mx

Este es el nivel de simplicidad que buscamos con REST. Tanto humanos como máquinas pueden generar estas estructuras de URI porque están basadas en reglas.

Estos son algunos lineamientos comunes para crear URIs para servicios web REST: • Mantener todo en minúsculas.

• Sustituir los espacios con guiones o guiones bajos (uno u otro).

• Evitar el uso de strings de consulta.

Transfiere XML, JSON, o ambos La representación de un recurso refleja el estado actual del mismo y sus atributos al momento en que el cliente de la aplicación realiza la petición. Esto podría ser una representación de un registro de la base de datos que consiste en la asociación entre columnas y tags XML, donde los valores de los elementos en el XML contienen los valores de las filas.

Un ejemplo de una representación de un recurso conectado podría ser un tema de discusión raíz con todos sus atributos e hiperligas embebidos a las respuestas al tema. <discusion fecha=”{ fecha}” tema=”{tema}”> <comentario>{comentario}</comentario> <respuestas> <respuesta de=”gaz@mail.com” href=”/discusion/temas/

{tema}/gaz”/> <respuesta de=”gir@mail.com” href=”/discusion/temas/{tema}/gir”/> </respuestas> </discusion> Es bueno construir los servicios de manera que usen el atributo HTTP Accept del encabezado, en donde el valor de este campo es un tipo MIME, mecanismo conocido como negociación de contenido. Esto permite que el servicio sea utilizado por distintos clientes escritos en diferentes lenguajes, corriendo en diversas plataformas y dispositivos. Así los clientes pueden elegir cómo manejar distintos tipos de documentos, y se minimiza el acoplamiento de datos entre el servicio y las aplicaciones que lo consumen.

Referencias [1]. Roy Thomas Fielding. Architectural Styles and the Design of Net work-based Software Architectures. http://bit.ly/14V9rQ [2]. RESTful Web Services. http://bit.ly/3itQu [3]. Roger L. Costello. Building Web Services the REST Way. http:// bit.ly/1wVQPx AGO-OCT 2009

61

// tecnología

/*gadgets*/

Esta sección es presentada por Geek

www.geek.com.mx

Microsoft

Zune HD Microsoft mantiene su intención de convertirse en un jugador importante en el segmento de los PMP (portable music player) y en septiembre lanzará la nueva generación Zune, de apellido HD. Zune HD no sólo ofrece un nuevo diseño más moderno, sino que además trae consigo una gran variedad de funciones y características: salidas de video HD y receptor de radio también en alta definición; navegación en internet por WiFi para descargar canciones, hacer streaming o lo que te plazca; pantalla táctil de 3.6” con resolución de 480 X 272; conexiones USB 2.0, HDMI y RCA compuesto; soporte a una gran variedad de formatos de audio y video. Habrá versiones en 4, 8, 16 y 32GB. Los rumores dicen que tal vez tendrá una cámara incorporada y soportará juegos 3D desde Xbox..

A-Data

XPG Xupreme 200X Con el lanzamiento oficial de Windows 7 A-DATA ofrece su nueva memoria USB llamada XPG Xupreme 200X, que ofrece capacidades en un rango desde ocho hasta 64GB y alcanza una velocidad de lectura de 30MB por segundo. Su diseño es bastante agradable porque tiene cubierta de aluminio color gris oscuro, además de contar con funda de cuero. Pero lo verdaderamente importante es que además de estar certificada para su uso con Windows Vista, ofrece total compatibilidad con Windows 7.

Ya se encuentra disponible en Latinoamérica, así que no hay razón para preocuparnos sobre el almacenamiento de nuestros documentos a la hora de hacer el inevitable salto al número 7.

62

AGO-OCT 2009

Logitech

Speakers Systems Z No se necesita ser un ultra gamer para querer disfrutar de una buena calidad de audio en la computadora. Logitech ofrece cuatro nuevos equipos con sonido de 360 grados: Z320, Z323, Z520 y Z523. La acústica omnidireccional permite al sonido distribuirse por un rango de espacio mucho más amplio que con las bocinas tradicionales de proyección frontal. No importa en qué parte de la habitación nos situemos, la calidad de sonido será la misma. Estos equipos saldrán a la venta entre septiembre y octubre de este año.

Firebox

Nintendo Mini Classics Ser un Nintendo Fanboy podría parecer algo extremadamente ñoño, quizá en alguna época lo fue, pero hoy en día tiene mucha onda. Así que para hacer alarde de ese fanatismo que se lleva en la sangre, qué mejor que un Nintendo Mini Classic con todo el aire del antiguo Game Boy. Hay tres juegos a elegir según el color de la mini consola súper portátil: Super Mario Bros (verde), Donkey Kong Jr. (amarillo) y Mario’s Cement Factory (azul).

www.sg.com.mx

www.sg.com.mx

AGO-OCT 2009

63

// CARRERA

/*REPUTACION DIGITAL*/

El Analista de Negocio Requisito para el Éxito por Guillermo Morales

A través de mi experiencia en la industria de TI, ha sido frecuente encontrarme con proyectos que inician y que lamentablemente no se completan o que terminan por encima del tiempo y presupuesto planeados, impactando significativamente los recursos y avance de las empresas. Seguramente todos estamos familiarizados con casos de estos.

Los principales detonadores de problemas se dan en las fases tempranas del ciclo de vida de los proyectos. El estudio “Business Analysis Benchmark 2008” elaborado por IAG Consulting indica que el 68% de las organizaciones tienen altas probabilidades de fracasar en sus proyectos de TI debido a la falta de competencias de análisis del negocio y requerimientos. Dicho estudio también indica que las empresas tienen un costo extra de hasta el 60% cuando su práctica de análisis de requerimientos y negocio es deficiente.

Queda claro entonces que aquellas empresas que inviertan en un equipo sólido de analistas de negocio, tendrán muchas más probabilidades de éxito en sus proyectos, que aquellas que no lo hagan.

Hablemos entonces del perfil y carrera del analista de negocio.

El analista de negocio Un analista de negocio trabaja como un enlace entre los distintos interesados de un proyecto para obtener, analizar, comunicar y validar los requerimientos de cambios a los procesos de negocio, políticas y sistemas de información.

El rol del analista de negocio es fundamental dentro de nuestras organizaciones, no solo porque gestiona los requerimientos, sino porque cierra la brecha que existe entre los interesados en el proyecto (stakeholders) y el equipo de desarrollo. El analista de negocio es relativamente una nueva figura en el equipo de trabajo, aunque actualmente existen muchas personas que realizan algunas de sus actividades en las organizaciones, y reciben muchos nombres diferentes, desde “embajadores”, hasta “representantes de negocio”. Sin embargo, es hasta hace pocos años que este rol se ha profesionalizado.

Entre las principales responsabilidades del analista de negocio están: • Desarrollo y administración de requerimientos de sistemas.

• Validación de requerimientos para reingeniería de procesos.

• Análisis y recomendación de soluciones de mejora continua.

• Validación y documentación de problemas y oportunidades de negocio.

• Análisis de requerimientos organizacionales y/u operacionales.

Profesionalización y certificación El International Institute of Business Analysis (IIBA), es una organización que desde hace más de 5 años se dedica a profesionalizar y certificar el rol del analista de negocio. Hoy en día ya es un organismo de clase mundial reconocido en el medio de la industria de TI, y que con presencia en varios países rápidamente se está colocando al nivel de otros organismos similares como el PMI. El IIBA ha creado un documento guía, un cuerpo de conocimiento, que sirve para definir los estándares de trabajo de los analistas de negocio llamado el Business Analysis Body of Knowledge (BABOK).

Asímismo ha creado una certificación llamada Certified Business Analysis Professional (CBAP). La certificación CBAP cuenta ya con el reconocimiento mundial y avala la experiencia y conocimiento de los individuos como analistas de negocio.

IIBA en México Nuestro país cuenta ya con la representación del IIBA de manera local, el IIBA Capítulo México. Como parte de éste, empresas y expertos de la industria comenzaron desde el año pasado a realizar los esfuerzos necesarios para fomentar la figura del analista de negocio en nuestro país. Actualmente, este grupo de personas y empresas, ofrecen servicios de entrenamiento oficial, consultoría, e implantación en las organizaciones de las mejores prácticas de análisis de negocios.

En el campo de la capacitación, se ha diseñado un plan específico de entrenamiento a la medida del mercado mexicano, apoyado directamente por Kathleen Barret (presidenta del IIBA en Estados Unidos), junto con el presidente IIBA Capítulo México y el vicepresidente de Educación IIBA. Este plan de certificación, está dividido en dos etapas, la primera enfocada a la adquisición del conocimiento sobre los conceptos de planeación y el BABOK, y la segunda etapa es para buscar la certificación como CBAP.

Conclusión El analista de negocios es pieza fundamental para los proyectos de TI de cualquier organización. Este rol puede dar grandes resultados como parte del equipo administrativo de un proyecto, y sobre todo ayudar a revertir significativamente esa tendencia negativa de entrega tardía y con costos excesivos en los proyectos. El analista de negocios es así, un requisito clave para el éxito de los proyectos de TI.

Mayor información [1]. www.theiiba.org [2]. www.ddi.com.mx/IIBA

Guillermo Morales es Socio y Director de Soluciones de Entrenamiento en Kryteria (www.kryteria.com.mx), empresa dedicada al entrenamiento y consultoría en soluciones TI. Tiene más de 12 años de experiencia en el campo de desarrollo de aplicaciones. Kryteria es el primer centro certificado por el IIBA para la entrega oficial de capacitación en México y mediante el cual, también se pueden obtener servicios de Consultoría e Implantación de los procesos de análisis de negocio.

64

AGO-OCT 2009

www.sg.com.mx

Aﾃｱo 05 No. 25

www.sg.com.mx

SOFTWARE GURU CONOCIMIENTO EN PRﾃ，TICA

Agosto-Octubre 2009