SG33 (Agosto-Octubre 2011) by Revista Software Guru

BPM Semántico P. 34

Arquitectura de información P. 36

Control de versiones P. 52

No.

Construcción de proyectos con Gradle

CONOCIMIENTO EN PRÁCTICA Agosto-Octubre 2011 www.sg.com.mx

EL FACTOR México, $65.00

HUMANO

EN LOS PROCESOS DE SOFTWARE

CONOCIMIENTO EN PRÁCTICA

.CONTENIDO Agosto-Octubre 2011 |

www.sg.com.mx

En Portada El Factor Humano en los Procesos de Software

Cuando hablamos de “mejora de procesos”, estamos hablando de una evolución más allá de mejores formatos o mejores procedimientos. En ésta edición encontrarás varios ángulos de análisis acerca del factor más importante en el desarrollo de software: el factor humano.

Columnas Tejiendo Nuestra Red

Por Hanna Oktaba

Mejora Continua

Por Luis Cuellar

Tendencias en Software

Por Luis Daniel Soto

Código Innovare

Por Ebenezer Hasdai Sánchez y Hugo Estrada Esquivel

Programar es un Estilo de Vida

por Gunnar Wolf

Pág.

20 02

Tecno-lógico por Mauricio Angulo

.CONTENIDO

SG 33

Productos Lo que Viene

Grails 2, SQL Server Denali, Android Open Toolkit, Heroku Cedar

Tutorial Construcción de Proyectos con Gradle

Por Enrique Zamudio

Carrera Inteligencia emocional

Pág.

16 Emprendiendo

El sector de TI en México

En Cada Número

En busca de proyectos para desarrollar el sector de TI Por Claudia Ivette García Romero, Secretaría de Economía

Prácticas Usabilidad Técnica detrás de una arquitectura de información efectiva

Project Management Estimación de Proyectos (parte 2)

Por Francisco Valdés Souto

Gestión de Procesos Paquetes de Puesta en Operación para la Arquitectura de Software y Diseño Detallado

Por Erick Serratos

Arquitectura El rol del arquitecto de software

Por Humberto Cervantes

Ágil ¿Cómo innovar colaborativamente?

Por Gustavo Quiroz

Prueba de Software Elementos para identificar el retorno de la inversión, basándose en pruebas de software

Editorial

Noticias

Publirreportaje

Fundamentos

Gadgets

Por Pamela Rodríguez

Por Berenice Ruiz

Por Ricardo Rangel

.EDITORIAL Bienvenida

“Sobre las personas existe mucho menos información, métricas y discusiones”.

Somos humanos después de todo

erramientas + Procesos + Personas. Es conocido que dicho trinomio forma la base para desarrollar software de calidad. Sobre herramientas y tecnologías es sencillo encontrar información y poder certificar nuestras habilidades. En el segundo caso, las metodologías y modelos de procesos también abundan, así como las discusiones sobre qué método es mejor o más adecuado para qué tipo de proyectos. Pero sobre el elemento de las personas existe mucho menos información, métricas y discusiones. Es por ello que hemos dedicado este número de SG a las personas, que a nuestro juicio son el elemento más importante de este trinomio. Si eres de los que solo se preocupan por el código y herramientas y crees que este número será muy “suave” para tu gusto, no te preocupes hemos incluido un par de artículos muy buenos sobre construcción de proyectos y control de versiones. Conforme escribimos estas líneas, estamos también atentos a los preparativos para SG Conferencia y Expo. Nos da gran gusto regresar con nuestro evento “insignia” a la Ciudad de México y con una gran variedad de actividades como feria de empleo, Ignite y App Circus. Consideramos que SG Conferencia y Expo tendrá algo para todos: profesionistas, ejecutivos, empresarios y estudiantes. Así que esperamos verte ahí.

››Equipo Editorial SOFTWARE GURU

DIRECTORIO SG Dirección Editorial Pedro Galván / Dirección de Operaciones Mara Ruvalcaba Coordinación Editorial Vanessa Amaya / Arte y Diseño Oscar Sámano / Suscripciones Denise Aguilar Consejo Editorial Jorge Valdés - PMI / Luis Cuéllar - Softtek / Luis D. Soto - Microsoft / Hanna Oktaba - UNAM / Emilio Osorio - Sistemas Humanos / Luis Vinicio León - e-Quallity / Gloria Quintanilla

Colaboradores Enrique Zamudio, Claudia Ivette García, Leonardo Nhaux, Cecilia Scauso, Rodrigo Torres, Elizabeth Almeraz, Susette Seoane, Ebener Sánchez, Hugo Estrada, Pamela Rodríguez, Francisco Valdes Souto, Erick Serratos, Humberto Cervantes, Gustavo Quiroz, Masa K. Maeda, Berenice Ruiz, Mauricio Angulo, Gunnar Wolf, Javier Novoa, Ricardo Rangel Ventas Claudia Perea / Alianzas Montserrat Ramírez / Webmaster Karen Rodríguez / Educación contínua Ana Karen Rosales Contacto info@sg.com.mx SG Software Guru es una publicación trimestral editada por Brainworx, S.A. de C.V., Temístocles 34 piso 3, México DF 11560. Los contenidos de esta publicación son propiedad intelectual de los autores y están licenciados bajo Creative Commons Atribución-No comercial 2.5 México. 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: En trámite. ISSN: 1870-0888. Registro Postal: PP15-5106. Distribuido por Sepomex. Se imprimió en agosto de 2011 en 4Press.

.NOTICIAS

.Evento Tendencias TI

.Startup weekend

.IBM Software Summit

El IBM Software Summit 2011 reunió a más de 400 profesionistas de software en la Ciudad de México, con quienes se compartió la estrategia de la división de software de IBM. IBM alineó su división de software en torno a dos áreas de crecimiento clave: a) Soluciones, que consiste de ofertas integradas de analítica de negocios, soluciones de industria, negocios sociales, comercio inteligente, y b) Middleware que considera administración de infraestructura física, gestión de la información e integración de negocios.

.Campus Party México 2011

La 3ra edición de Campus Party México se llevó a cabo del 18 al 24 de julio en Expo Bancomer Santa Fe, en Ciudad de México. El evento fue bastante concurrido y recibió mucha cobertura de parte de todo tipo de medios. A nuestro juicio, respecto a ediciones anteriores el evento tuvo sus mejoras (principalmente en logística) y retrocesos (en la calidad de los contenidos). Aun así, es un hecho que Campus Party es un evento notable y que vale la pena simplemente por el convivio con personas con intereses afines.

.Google Dev Fest

Del 9 al 11 de agosto se realizó en la Carpa Neumática del Hipódromo de las Américas en la Ciudad de México el evento “Esto es Google”. Dentro de este evento, el primer día fue un Google Dev Fest con contenidos enfocados a desarrolladores de software. Las sesiones estuvieron a cargo del equipo de evangelización de Google y fueron organizadas a lo largo de los siguientes tracks: desarrollo móvil (Android), HTML y web móvil, cómputo en la nube (App Engine), y geolocalización. En este último track, el conferencista principal fue Mano Marks, a quien recordamos por su participación en SG Virtual en abril de este año. Para mayor información, noticias al día y actualizaciones de la industria visita: www.sg.com.mx

www.sg.com.mx |

Software Guru

Startup weekend es un evento donde en un fin de semana personas de distintos perfiles trabajan de forma colaborativa para armar un startup llevándolo desde la idea inicial hasta un mínimo producto viable (MVP). Durante este verano se realizaron ediciones de este evento en Ciudad de México, Guadalajara y Monterrey, logrando excelentes resultados. Para quienes no crean que en un fin de semana se pueda armar un buen startup, les comentamos que uno de los startups participantes en Ciudad de México (NuFlick) incluso ya fue aceptado por el programa mexican vc y recibió capital semilla. Manténte al tanto y asiste al próximo startup weekend en tu región, u organiza uno propio.

El pasado 15 de junio se llevó a cabo en la ciudad de México el evento “Tendencias para la competitividad de las empresas de TI en México” organizado por las empresas Avantare, NYCE, IDC con el apoyo de NAFIN. Este evento logró reunir a casi 100 directivos y ejecutivos de empresas de TI interesados en escuchar cómo han evolucionado los servicios de TI tanto a nivel global como a nivel nacional, mejores prácticas para la prestación de servicios de TI, se profundizó sobre la gestión de procesos de TI y cómo esto impacta en los negocios y las ventajas competitivas de la certificación de estándares internacionales. En definitiva, todos los temas incluídos representan por sí mismos estrategias que las empresas de cualquier tamaño deben considerar.

.COLUMNA Tejiendo Nuestra Red

Ya Nació ISO/IEC

29110 Perfil Básico el primogénito de

arir MoProSoft como norma mexicana nos costó 4 años de trabajo (2002-2005). Dar a luz como estándar internacional a su primer hijo, llamado Perfil Básico, nos llevó 5 años (2006-2011). Como orgullosa mamá y abuela les quiero contar de este importante acontecimiento tratando de responder a las preguntas frecuentes sobre el papá y el hijo.

››En octubre de 2006, el WG24 tomó la decisión de presentar MoProSoft como estandar internacional. ¿Qué es MoProSoft?

MoProSoft (Modelo de Procesos para la Industria de Software) es un conjunto integrado de procesos de Gestión e Ingeniería de Software, compuesto por prácticas reconocidas (en su momento). El modelo de procesos MoProSoft tiene tres capas de procesos: Alta Dirección, Gerencia y Operación que reflejan la estructura típica de una organización. La capa de alta Dirección contiene el proceso de Gestión de Negocio. La capa de Gerencia está integrada por los procesos de Gestión de Procesos, Gestión de Proyectos y Gestión de Recursos. Éste último está constituido por los subprocesos de Recursos Humanos y Ambiente de Trabajo; Bienes, Servicios e Infraestructura y Conocimiento de la Organización. La capa de Operación está integrada por los procesos de Administración de Proyectos Específicos y de Desarrollo y Mantenimiento de Software.

¿Por qué se definió MoProSoft? La Dra. Hanna Oktaba es profesora de la UNAM, miembro del IPRC, y directora técnica del proyecto COMPETISOFT. hanna.oktaba@ ciencias.unam.mx

Para sugerir a las organizaciones que se dedican al desarrollo y mantenimiento de software, el tipo de prácticas que les pueden ayudar a mejorar su forma de trabajar y por lo tanto su desempeño. Esta fue la apuesta que motivó a la Secretaría de Economía a apoyar este proyecto para convertirlo en la norma mexicana para la industria de software.

MoProSoft

¿Para quién es MoProSoft?

MoProSoft está dirigido tanto a empresas como a áreas internas dedicadas al desarrollo y/o mantenimiento de software. Las organizaciones que no cuenten con procesos establecidos pueden usar el modelo ajustándolo de acuerdo a su contexto, mientras que las organizaciones con procesos establecidos pueden usarlo como referencia para identificar elementos faltantes.

¿Quiénes lo crearon?

MoProSoft fue creado en 2002 a solicitud de la Secretaría de Economía en México dentro del PROSOFT por el grupo editor: Hanna Oktaba (Directora), Claudia Alquicira, Angélica Su, Alfonso Martínez, Gloria Quintanilla, Mara Ruvalcaba, Francisco López Lira, Ma. Elena Rivera, Ma. Julia Orozco, Yolanda Fernández y Miguel Flores. Para completar la norma se necesitaba definir el método de evaluación basado en MoProSoft como modelo de procesos. Para tal fin se conjuntó otro equipo en 2003, que definió EvalProSoft (el método de Evaluación de Procesos de Software). Los miembros de este equipo fueron: Hanna Oktaba (Directora), Claudia Alquicira, Angélica Su, Carlos Pérez, Francisco López Lira, Jorge Palacios, Gloria Quintanilla, Cecilia Montero y Alfredo Calvo. Al principio de 2004 ya se tenían los elementos básicos, el modelo de procesos y el método de evaluación, para empezar los trámites de normalización. Sin embargo faltaba un “detalle”, probar que MoProSoft y EvalProSoft sirven en la práctica. Así surgió el tercer proyecto (Pruebas Controladas) con cuatro empresas que tenían el perfil promedio (18 personas) de la industria de software. El objetivo fue demostrar que en un lapso de tiempo relativamente corto, las empresas pueden elevar sus niveles de capacidad. El equipo de trabajo fue conformado por: Hanna Oktaba (Directora), Claudia Alquicira, Angélica Su, Francisco López Lira, Jorge Palacios Elizalde, Ana Vázquez y Claudia Gutiérrez. Los tres proyectos fueron financiados por la Secretaría de Economía a través de convenios con la UNAM. Posteriormente los esfuerzos se centraron en convertir MoProSoft en una norma mexicana. Para ello se trabajó dentro del Subcomité de Software del NYCE y el resultado fue la norma MNX-I-059-NYCE-2005 con sus 4 partes:

.COLUMNA Tejiendo Nuestra Red

• Tiene una estructura de procesos acorde a la estructura de las organizaciones de software (Alta Dirección, Gestión y Operación) que no tiene ningún otro modelo. • Destaca el papel de la Alta Dirección en la planeación estratégica, así como promotor del buen funcionamiento de la organización, a lo que no se atreve ningún modelo para esta industria. • Integra los elementos para la administración de proyectos en un sólo proceso. • Está en español.

MoProSoft en Iboeroamérica

MoProSoft se conoce en varios países de iberoamérica gracias al proyecto COMPETISOFT (Mejora de Procesos para Fomentar la Competitividad de la Pequeña y Mediana Industria del Software de Iberoamérica) dirigido por Dr. Mario Piattini de la Universidad Castilla La Mancha y una servidora. Este proyecto puso a MoProSoft al escrutinio y prueba de academia y empresas en España, Argentina, Chile, Colombia, Uruguay y Perú. Como resultado de este proyecto se publicaron dos libros y Perú adoptó MoProSoft como norma técnica peruana en 2009.

MoProSoft como estándar ISO/IEC

En 2005, ISO/IEC JTC 1 SC7 convocó a un grupo de trabajo (WG 24) para definir procesos de software para Very Small Enterprises (VSE), de 1 a 25 personas. Una de las primeras tareas del grupo fue averiguar si ya existía alguna propuesta dirigida a este sector. Se enteraron de MoProSoft e invitaron a México a presentarlo. Ana Vázquez hizo la presentación en la reunión del WG24 de mayo 2006 en Tailiandia, y en votación unánime los representantes decidieron tomar la norma mexicana como base para su trabajo. En octubre de 2006, el WG 24 tomó la decisión estratégica de presentar MoProSoft como estándar internacional en tres “cómodas mensualidades”, es decir en grupos de procesos divididos por las tres capas del modelo. El primer perfil a trabajarse, llamado posteriormente Perfil Básico, correspondió a los procesos de Administración de Proyectos Específicos y de Desarrollo y Mantenimiento de Software de la capa de Operación. El ISO/IEC 29110 (Software engineering — Lifecycle profiles for Very Small Entities) consta hasta ahora de las siguientes 07

Diferencia entre Perfil Básico y MoProSoft

Quienes tienen implementado MoProSoft a nivel 2 están cubriendo prácticamente el perfil básico de ISO/IEC 29110. Este último, como está dirigido a prácticas de un proyecto de software aislado tiene algunas tareas que en MoProSoft se delegan a otros procesos. Por ejemplo, a falta de la base de conocimiento de la organización se propone el uso de un repositorio local del proyecto. Algunos productos de trabajo sufrieron modificaciones a raíz de los comentarios del grupo y su apego a otros estándares ISO ya existentes, pero en general se parecen mucho. Las editoras de las partes 4-1 y 5-1-2 fueron Ana Vázquez, Blanca Gil, Claudia González y Hanna Oktaba. En cuanto al trabajo subsecuente, como ya comenté se está preparando el Perfil Entry (una simplificación del perfil básico), Perfil Intermedio (que incluirá los procesos de Gestión de Procesos, Recursos y Proyectos), y el Perfil Avanzado con el proceso de Gestión de Negocio. Por supuesto, estos procesos sufrirán modificaciones con respecto a sus versiones originales debido a las lecciones aprendidas de su uso y las aportaciones de la comunidad internacional. Además, a la comunidad de sistemas les gustó el trabajo que hemos hecho y están trabajando el Perfil Básico para desarrollo de Sistemas y Software. Los que trabajan el estándar de servicios también están viendo la necesidad de generar una versión para VSEs y los “agilistas” están clamando por la modalidad ágil del Perfil Básico. Así que habrá trabajo para rato. Espero que estas preguntas y respuestas les ayuden a ubicar el nuevo estándar en su justa dimensión. De ninguna manera es una revolución en el área de procesos. Es una aportación mexicana a la forma en que se presentan las prácticas a los lectores. Ni más, ni menos.

››Por Hanna Oktaba

Software Guru

¿Cómo se distingue MoProSoft de modelos similares?

partes y documentos: 1) Overview, 2) Framework and taxonomy, 3) Assessment guide, 4-1) Profile Specifications: Generic profile group, 5-1-2): Management and engineering guide: Generic profile group: Basic profile. El perfil básico está incluido como Parte 5-1-2, el 1 significa que pertenece al primer grupo de perfiles genéricos, basados en MoProSoft, y el 2 es su número consecutivo (se está terminando un perfil más elemental llamado Entry, que será el número 1 en este grupo). El perfil básico se publicó en mayo de 2011 y para promover su uso se hizo disponible de forma gratuita en http://bit.ly/sg33r1. Las partes 2 y 4-1 también están publicadas pero tienen costo. El perfil básico se recomienda para las organizaciones pequeñas que pueden ser empresas, departamentos o proyectos de hasta 25 personas. La Guía se aplica en proyectos de desarrollo de software ya sea internos o externos (subcontratados).

www.sg.com.mx |

1) Definición de conceptos y productos, 2) Requisitos de procesos (MoProSoft), 3) Guía de implantación de procesos y 4) Directrices para la evaluación (EvalProSoft). Dichos documentos fueron redactados de forma voluntaria por Claudia Alquicira y una servidora. La norma entró en vigor el 15 de octubre de 2005. Cabe destacar que la gran mayoría de las personas mencionadas fueron miembros de la extinta Asociación Mexicana para la Calidad en Ingeniería de Software (AMCIS). ¡Ay, como nos hace falta!

.COLUMNA Mejora Continua

El Poder de las Ideas

la mejor idea es la mejor implementada

e estado leyendo un fascinante libro titulado “The Lords of Strategy” de Walter Kiechel, el cual se adentra en la historia de la consultoría y sus diferentes protagonistas, lo recomiendo ampliamente. En el libro se hace una afirmación que llamó mucho mi atención y ha cambiado mi perspectiva: “El mundo de la consultoría es un mundo de ideas”. ¿Simple y tal vez obvio, no? Puede ser, pero a veces las cosas simples tienen implicaciones trascendentes. Incluso en mayor medida que el mundo de la consultoría, el mundo del software también es un mundo de ideas. Todo lo que construimos en una computadora no son más que bits de información que realmente no existen en un mundo físico. Y si es un mundo de ideas, entonces ¿qué hace que una idea sea mejor que otra? Muchas de las discusiones que tenemos a diario como: ¿qué metodología utilizamos?, ¿somos ágiles o estructurados?, ¿es más importante la ingeniería de software o la administración de proyectos? pretenden manejar ideas como si fueran verdades absolutas, como si existieran en realidad en lugar de ser simples puntos de vista.

››En un mundo de ideas ninguna es mejor que otra.

Luis R. Cuellar es director de calidad a nivel mundial de Softtek. Es reconocido por la ASQ como Certified Quality Manager, Certified Sofware Engineer y Six Sigma Black Belt. @lcuellar

Cuando hacíamos programas en la escuela, el mundo era más sencillo. Había que conocer el lenguaje lo mejor posible y resolver en forma lógica un problema real de una forma matemática. Pero luego pasamos a resolver sistemas, y conocer el lenguaje ya no fue suficiente. Hay que manejar datos, modularidad, entender lo que el cliente requiere y comunicarlo adecuadamente. El sistema involucra a un número de actores con los que hay que interactuar: ¿cómo sé que entendí lo que el cliente me está pidiendo?, ¿cómo sé si él sabe lo que quiere? A esto se agrega un nivel adicional que involucra las negociaciones para el pago de nuestros servicios: ¿cómo definimos el esfuerzo que requiere el proyecto?, ¿qué pasa si surge un inesperado?, ¿cómo negociamos un cambio de alcance?, ¿manejar minutas en un proyecto es parte del proceso de desarrollo de software?, quien dice que no nunca ha perdido millones de dólares en una litigación porque el cliente no recuerda (o no respeta) un acuerdo verbal. En resumen, desarrollar software en la vida real no es simplemente sobre construir software sino que existen muchas capas adicionales que lo hacen complicado.

Regresando a nuestro punto, para cada fase, para cada decisión, existe un sinnúmero de ideas en la industria que tomamos como verdades absolutas. “Desarrollo iterativo es la mejor forma de llevar a cabo un plan”, depende, desarrollo iterativo es excelente cuando el usuario no tiene claro qué es lo que quiere lograr. Pero esto complica el cobro de los servicios ya que los clientes no necesariamente están dispuestos a pagar por una entrega parcial o el desarrollo puede irse al infinito ya que siempre habrá algo que mejorarle al sistema. Otra discusión común es la de la importancia que tiene la ingeniería de software sobre la administración de proyectos. Después de todo, la ingeniería de software es lo que utilizamos para asegurar que entregamos un producto bien hecho, de acuerdo a lo especificado. Pero este argumento asume que el desarrollo de software es únicamente la creación de un producto, olvidando la parte del servicio. Imaginemos que compramos una computadora, la mejor del mundo, pero no sabemos cuando la vamos a recibir, el vendedor no sabe decirnos qué puede hacer ni cómo usarla, tampoco tenemos soporte si falla o queremos modificarla. ¿Qué es más importante, la calidad de la computadora o que llegue a tiempo y la podamos usar? ¿A dónde voy con todo esto?, la realidad es que en un mundo de ideas ninguna es mejor que otra, unas pueden ser más completas, mas escalables, más entendibles o más fáciles de vender, pero ninguna es por definición la mejor. Lo único que diferencia una idea de otra es nuestra habilidad de implementación. La mejor idea es la mejor implementada; la forma de trabajo, organización o estructura cuya ejecución hace que realmente sobresalgamos como organización. No podemos hablar del mejor modelo de calidad sino del que nos parece más práctico, más compatible a nuestra organización, a nuestra cultura. No podemos enfocarnos en el proceso de análisis e ignorar el de peer review; cada proceso tiene su razón de ser y hasta no entender el lugar de cada práctica en nuestro proyecto no podemos juzgar un proceso más importante que otro. Una idea no existe hasta que se ejecuta, una idea que tú puedes ejecutar excelentemente no necesariamente es una idea que toda la organización pueda ejecutar excelentemente. Cada concepto e idea tiene su lugar su tiempo y su posibilidad de existencia. Como agentes de cambio nuestra labor es encontrar las ideas, tiempos y posibilidades que unan el esfuerzo de cada individuo y lo hacen funcionar mejor que la suma de sus partes.

››Por Luis Cuellar

Administración, desarrollo y ajuste de rendimiento de SQL Server…

Pero más rápido.

Ocuparse de la información de su compañía es una tarea importante. Simplificarla y agilizarla es nuestro trabajo.

DB PowerStudio™ Presentamos DB PowerStudio para SQL Server. Le brinda herramientas altamente visuales (y sorprendentemente asequibles) que ahorran tiempo y reducen errores al simplificar y automatizar muchas de las cosas complejas que usted tiene que hacer para ocuparse de su información y bases de datos de SQL Server. Tanto si usted ya usa SSMS o alguna otra herramienta de terceros, descubrirá que puede hacer muchas cosas más rápido con DB PowerStudio para SQL Server. > Administración de SQL Server más sencilla con DBArtisan®, una herramienta de administración de bases de datos visual con editores gráficos y asistentes para simplificar las tareas rutinarias y reducir errores. Además, los análisis de la base de datos identifican el rendimiento, la capacidad y las cuestiones de administración del almacenamiento antes de que se transformen en problemas > Rendimiento más veloz con DB Optimizer™, una herramienta gráfica de creación de perfiles sin agentes que localiza rápidamente los problemas de rendimiento y aporta un Ajustador visual de SQL para que usted pueda comprender y optimizar rápidamente el mal desempeño del SQL > Desarrollo más veloz con Rapid SQL™, un IDE con todas las funciones que simplifica el scripting de SQL y T-SQL, la creación de consultas, la administración de objetos y el control de versiones. > Control de cambios simplificado con DB Change Manager™, una herramienta para coordinar los cambios de la base de datos en todo el ciclo de vida del desarrollo, hacer cumplir los estándares de configuración de la base de datos y enmascarar los datos de prueba para cumplir con los mandatos de privacidad Lo mejor de todo es que DB PowerStudio para SQL Server funciona en todas las versiones de SQL Server desde una sola interfaz, de modo que usted no tiene que activar diferentes versiones de herramientas ¡No se olvide de la creación de modelos! Embarcadero también ofrece ER/Studio®, la mejor herramienta de la industria para la creación de modelos de datos en colaboración.

.PRODUCTOS Lo Que Viene

Grails 2

La búsqueda ha terminado (por ahora)

La versión 2 de Grails ya vio la luz por medio de su primer milestone release. Grails es una plataforma para el desarrollo de aplicaciones web basado en el lenguaje dinámico Groovy, que se apoya en tecnologías como Hibernate para la persistencia en base de datos relacionales y SpringFramework para la Inversion de Control e Inyección de Dependencias. Entre las características principales de Grails 2 están: soporte a Groovy 1.8, Spring 3.1, Hibernate 3.6 y Tomcat 7; Scaffolding con soporte para elementos de HTML 5; soporte para capacidades asíncronas de Servlet 3.0, mejoras en el mapeo objeto-relacional. Adicionalmente, existen más de 650 plugins para Grails, y continuamente se agregan nuevos, con los que puedes agregar funcionalidad adicional a tus aplicaciones. http://grails.org

Ya está disponible el 3er Community Technology Preview (CTP3) de la próxima versión de SQL Server, nombre clave “Denali”. Las nuevas capacidades de Denali giran alrededor de 3 ejes: alta disponibilidad, inteligencia de negocios, diseñado para el contexto de la nube. Denali busca ser no solo una base de datos, sino una plataforma de información. De acuerdo con Microsoft, Denali podrá manejar datos estructurados, no estructurados, XML, y espaciales, ofreciendo capacidades de búsqueda semánticas y de texto completo. También facilitará la sincronización de datos en la nube via SQL Azure DataSync, y el acceso abierto a datos por medio de OData. Otras características: • AlwaysOn, una solución para administración de bases de datos de alta disponibilidad y con soporte a recuperación de desastres. • “Apollo”, una nueva tecnología para almacenamiento basado en columnas. • “Crescent”, una solución para visualización de datos en web. • “Juneau”, el nuevo ambiente de desarrollo para aplicaciones dirigidas por base de datos. • SQL Server Data Quality Services, depuración de datos basada en conocimiento.

SQL Server Denali CTP3 y contando

http://www.microsoft.com/sqlserver/en/us/future-editions.aspx

Android Open Accesory Toolkit Controla el mundo desde tu Android

¿Te gustaría poder crear accesorios de hardware que interactúen con tus dispositivos Android? Ese es el propósito del Android Open Accesory Toolkit, el cual fue dado a conocer durante el Google I/O 2011. Por medio del toolkit podrás controlar dispositivos externos via WiFi, USB, Bluetooth. Próximamente se agregará soporte a protocolos adicionales para controlar lámparas, termostatos y dispositivos electrónicos en el hogar. Para propósitos de desarrollo y experimentación, se ha hecho disponible hardware de referencia basado en tarjetas Arduino. El ADK es soportado en las versiones 3.1 y 2.3.4 de Android. http://accessories.android.com

Heroku es sin duda uno de los proveedores líderes en el espacio de Plataforma como Servicio. Aunque inició como una plataforma para Ruby on Rails, está evolucionando para soportar una variedad de lenguajes y frameworks. Recientemente liberaron la versión beta de su nuevo stack llamado Celadon Cedar, el cual brinda soporte para Node.js y Clojure. Otras ventajas que incorpora el stack Cedar son: nuevo modelo de ejecución basado en procesos; mejoras en el manejo de acciones rake desde línea de comandos; disminución de la inyección de código y mayor depuración de ésta gema para utilizar PostgreSQL. http://devcenter.heroku.com/articles/cedar 10

Heroku Celadon Cedar

Programación políglota en la nube

.COLUMNA

El Futuro de Internet

Tendencias en Software

elementos de la alquimia

El diluvio de datos actual ya es alto con los videos y fotografías capturadas desde dispositivos móviles conectados. El registro de los patrones de navegación de sitios web es otro formidable generador de datos. Esto va a empeorar con muchas de esas “cosas en Internet” que serán sensores de bajo costo. Algunos pacientes hoy ya tienen en su cuerpo sensores generando información para el mejor diagnóstico y tratamiento de enfermedades. Moore continúa haciendo de las suyas. Hoy es posible adquirir 40 núcleos con 512Gb de RAM por menos de $50 mil dólares y en 18 meses las dimms de 32Gb habilitarán sistemas de 2Tb por menos de $150 mil dólares, que es el costo total promedio de un empleado para una empresa internacional.

El bajo IQ de la Inteligencia de Negocios

La inteligencia de negocios está limitada a los escenarios donde se conocen las preguntas a contestar y continuará siendo relevante en ambientes transaccionales. Sin embargo, la “BI” 11

es limitada porque no es predictiva, social ni accesible a todos en cualquier dispositivo. Se estima que la información estructurada representa menos del 10% de la información que se está produciendo, por lo que hay que poner los ojos en el problema mayor.

Alquimia 2.0

La gran interrogante no es sobre el futuro de la infraestructura de Internet sino la posibilidad de entender y explorar la información. Se especula que esto es posible, pero de hecho hoy ni los gigantes de internet pueden articular las preguntas que desean contestar en forma clara. Lo asocio a la era en que los alquimistas querían transformar materiales en oro. Si esto es cierto, la mercadotecnia se transformará en algo de mayor precisión y que dependa mucho de matemáticos y actuarios. Esto no es todo: en los puntos de acceso también hay transformación. Veamos un ejemplo a continuación ...

El fin de las apps

En junio de este año el Financial Times lanzó una nueva app para leer sus contenidos desde dispositivos iOS. La peculiaridad es que no es una app que se adquiere en el app store sino que simplemente es un sitio web en HTML5. La principal razón para esto fue evitar el control que Apple impone (30% de los ingresos de suscripciones, control de los datos de los usuarios). Se reportó que 100 mil de sus 224 mil suscriptores accedieron la aplicación la semana que se hizo disponible. En el mismo mes se corrió el rumor de que el proyecto Spartan de Facebook estaría basado en HTML5. Facebook está interesado en llegar directamente al consumidor, de hecho es necesario para generar un modelo de negocios con crecimiento a largo plazo. El “cara-libro” se encuentra en una posición estratégica para competir por la distribución de contenido contra la manzana. A la última le ha costado años generar 225 millones de cuentas con tarjetas de crédito registradas, ha tenido que hacer grandes inversiones en contenido e incluso incursionar en el hardware. HTML5 puede ser un disruptor de la misma forma que la tienda de Apps lo ha sido en 3 años. Por supuesto, las aplicaciones nativas no desaparecerán por completi ni de forma inmediata, pero el futuro está en HTML5. Nuevamente estamos viviendo en el borde de una importante trasformación tecnológica. Después de todo, quizá no haya una Burbuja 2.0

>> Por Luis Daniel Soto

Software Guru

nternet enlaza actualmente a 2 mil millones de personas, y anualmente se integran otros 200 millones. La red representa en la actualidad menos del 4% del producto interno bruto en países en desarrollo y 6% en economías desarrolladas, de acuerdo a McKinsey Globlal Institute. El mismo estudio encontró un incremento en productividad de PYMES de 10% gracias al uso de Internet. Todos coinciden en los beneficios para el individuo, la empresa, el gobierno y el desarrollo económico. ¿Qué sigue, cuál es el futuro? • Los padres de Internet han deseado que sea semántico, no solo “folletería digital” o transaccional. • Hoy ya es social. De hecho, tan solo Facebook está provocando que el uso de internet haya cambiado radicalmente. • El cómputo en la nube es sin duda una nueva realidad en Internet. En mi opinión, el destino final de adoptar la nube pública es inevitable, aunque estemos artificialmente enfocados en la nube privada por limitantes en el manejo de datos. • Algunos quieren que la red sea optimizada para comunicación entre máquinas y no entre humanos, como fue en la etapa inicial. Cisco lo llama “La internet de cosas” y explica que a fines del 2010 existían 1.84 dispositivos por habitante. El aprendizaje automático será necesario ya que no hay humanos suficientes para realizar la labor. • Se ha perdido temporalmente el énfasis en interconectar empresas y procesos, pero seguramente regresará.

www.sg.com.mx |

2.0

Luis Daniel Soto Maldonado labora en la división de negocio de servidores y herramientas de Microsoft Corp. @luisdans

.PRODUCTOS Tutorial

Construcción de Proyectos con fácil y rápido

na parte importante del desarrollo de software es la construcción de los proyectos y los sistemas completos. Desde la clásica herramienta make en los 70’s, ha habido varios mecanismos y sistemas distintos para construcción de proyectos, algunos enfocados a ciertos aspectos de la construcción, otros tratando de abarcar todo el espectro: compilación, manejo de dependencias, integración contínua, automatización del proceso de construcción, etc. En el mundo Java, primero tuvimos Ant, una herramienta en cierta forma similar al make pero hecha 100% en Java, enfocada a construcción de proyectos Java. Al principio parecía muy buena, porque la sintaxis no era tan oscura como la de make, sino que usa XML, de modo que es más entendible lo que se quiere hacer. Pero cuando se comienzan a hacer scripts más complejos, la XML-itis se vuelve difícil de entender y modificar. Luego hemos tenido otras cosas como Ivy y Maven. Ivy se enfoca al manejo de dependencias, que consiste en indicar qué bibliotecas externas de software se necesitan para poder compilar el proyecto, cuáles se necesitan para correrlo, cuáles para probarlo, etc. Maven, por su parte, abarca el ciclo completo: compilación, manejo de dependencias, pruebas unitarias, documentación técnica (javadoc) y hasta el sitio del proyecto puede hacer, todo esto gracias a que tiene una arquitectura de plugins bastante completa. Pero Maven, al ser tan completo, se vuelve a la vez complejo: para compilar un proyecto tipo “hola, mundo!” y generar su documentación se requieren unas 30 líneas de XML (probablemente más líneas que el mismo código fuente de un proyecto tan simple).

Gradle: Un sistema muy groovy

Nos saltamos a 2008, cuando surge el proyecto Gradle (pronunciado más o menos greirol). Este sistema para construcción de proyectos toma lo mejor de lo que ya existe: puede integrar tareas de Ant, usar el manejo de dependencias de Ivy, ciclos de compilación y pruebas tipo Maven y, lo mejor de todo, sigue el paradigma de convención sobre configuración; es decir, todas las opciones configurables tienen valores por defecto con lo más común o útil, de modo que sólo es necesario modificarlos para casos especiales, pero para la mayoría de los casos se puede usar el valor por omisión, lo cual nos permite tener scripts bastante breves. Una de las características que hacen a Gradle tan sencillo de usar, es que los scripts usan un lenguaje específico de dominio (Domain-Specific Language, DSL) que extiende el lenguaje de programación Groovy. Esto le da a Gradle a la vez sencillez y poder, ya que en los scripts se pueden utilizar elementos tanto de programación orientada a objetos como de programación funcional. Gradle cuenta también con una arquitectura de plugins y de entrada ofrece varios muy útiles: para compilar proyectos Java, proyectos Groovy (y por supuesto híbridos Java+Groovy), crear artefactos para publicar en repositorios Maven, generar documentación técnica (Javadoc/Groovydoc), realizar pruebas unitarias y generar reportes con los resultados, etc. Y por supuesto, cuenta con una API para que terceros puedan crear sus propios plugins. Veamos un ejemplo sencillo, para lo cual necesitamos crear un proyecto muy sencillo, algo un poquito arriba del típico “Hola, Mundo!” para poder integrar pruebas unitarias y documentación. 12

Gradle ››Por Enrique Zamudio

Hola, Gradle

Lo primero, por supuesto, es instalar Gradle. El único prerrequisito previo es tener instalado un JDK. Teniendo esto, descargamos la versión más reciente de Gradle en http://gradle.org (que al momento de escribir este artículo, es 1.0-milestone-3), desempaquetamos el .zip en el destino de nuestra preferencia, y apuntamos a ese directorio la variable de ambiente GRADLE_HOME. También es recomendable agregar a la ruta de ejecutables (PATH) el directorio $GRADLE_ HOME/bin para que podamos llamar al ejecutable de gradle desde cualquier directorio. Para probar que la instalación es correcta, podemos ejecutar en una línea de comando gradle -v y nos debe regresar el número de versión de gradle que instalamos. Una vez que hemos completado la instalación, crearemos un proyecto Java. Por el momento, vamos a crear de forma manual la estructura de directorios del proyecto, pueden hacerlo ya sea desde línea de comando o con el administrador de archivos de su sistema operativo. Hay que crear un directorio raíz para el proyecto, HolaSG (Gradle usará el nombre de este directorio para el nombre del proyecto) y debemos tener la siguiente estructura de directorios debajo: src/main/java/ejemplo src/main/resources src/test/java/ejemplo src/test/resources

Si les parece conocida la estructura, es porque está basada en la que Maven ha hecho tan popular. En src/main/java va el código fuente, src/ test/java contiene las pruebas unitarias. Los directorios src/main/resources y src/test/resources son para recursos auxiliares (XML, properties, imágenes, etc), tanto para el proyecto como para sus pruebas unitarias, pero este ejemplo es muy simple y no vamos a usar archivos auxiliares, de modo que podemos simplemente omitir estos directorios.

El código

Ahora sí, vamos a crear una clase en Java: HolaJava.java (dentro de src/main/java/ejemplo)

package ejemplo; public class HolaJava { public String saluda(String quien) { return String.format(“Hola, %s! (en Java)”); } }

Por ahora vamos a saltarnos la prueba unitaria, para irnos directo a compilar. A fin de cuentas, este artículo es de Gradle, no de Test Driven Development.

El script

El script de Gradle debe ir directamente bajo el directorio HolaSG.

.PRODUCTOS Tutorial

Puede tener cualquier nombre, pero así como en ant la convención es un build.xml, en Gradle es un build.gradle. Y debe contener la fabulosa cantidad de una línea de código:

Y ahora debemos agregar unas líneas al script de Gradle, para que quede así: apply plugin:’java’

apply plugin:’java’

gradle build

Veremos cómo se ejecutan varias tareas: compileJava (compila el código), processResources (copia los archivos de src/main/resources a donde quedaron las clases compiladas), classes, jar, assemble (arma los artefactos o entregables definidos para el proyecto), compileTestJava (compila las pruebas unitarias), processTestResources (copia los archivos de src/test/resources a donde quedaron las pruebas unitarias compiladas), testClasses y test (que ejecutan las pruebas unitarias), check y finalmente, build. Debemos al final ver el mensaje de BUILD SUCCESSFUL y el tiempo que le tomó todo el proceso. Ahora podemos ver que tenemos dos directorios nuevos bajo HolaSG: .gradle y build. El .gradle es un directorio interno de Gradle para almacenar el estado de todos los recursos involucrados en la construcción del proyecto, lo cual le permite saber entre otras cosas, qué clases hay que recompilar en ejecuciones subsecuentes. Y el directorio build contiene el resultado del proceso. Dentro podemos ver un directorio classes/main y ahí encontraremos nuestro HolaJava. class; y si vemos en libs encontraremos un HolaSG.jar. Si ejecutamos nuevamente gradle build, veremos la lista de tareas nuevamente pero junto a cada una saldrá la leyenda UP-TO-DATE, esto gracias al cache que le permite a Gradle saber que todo está actualizado y por lo tanto ninguna tarea hizo realmente nada.

Pruebas unitarias

Bien, ahora que ya vimos a Gradle en acción por primera vez, agreguemos una prueba unitaria al proyecto. En este caso utilizaré jUnit para mis pruebas, para mostrar lo fácil que es configurarlo y utilizarlo: TestAll.java (en src/test/java/ejemplo)

package ejemplo; import org.junit.*; public class TestAll { @Test public void testSaludo() { HolaJava o = new HolaJava(); assert “Hola, Mundo! (en Java)”.equals(o.saluda(“Mundo”)); } }

Figura 1. Reporte de resultado de pruebas.

Software Guru

Con esto modificamos la configuración de Gradle: primero, definimos repositorios de código para poder descargar las dependencias necesarias. Dado que el repositorio central de Maven es el lugar más utilizado, Gradle ya tiene un método para agregar su configuración a los repositorios, de modo que sólo tenemos que invocarlo. Y para las dependencias, estamos indicando que para la compilación de las pruebas unitarias queremos usar jUnit 4.8.2. Las dependencias se pueden indicar simplemente con una cadena en formato groupID:artifactID:version para buscarlas en el repositorio de Maven. En este caso definimos dependencias para la tarea de compilación de pruebas con testCompile, pero también lo podemos hacer para otras tareas como compile (compilación de clases del proyecto), runtime (ejecución de la aplicación) o testRuntime (se usan para correr las pruebas, no para compilarlas). Es posible definir dependencias para tareas adicionales en caso que fuera necesario, pero estas que menciono son las más comunes. Para ejecutar las pruebas tecleamos gradle test. Veremos pasar las tareas de compileJava y demás con la señal UP-TO-DATE y posteriormente compileTestJava donde se compila nuestra nueva clase de prueba. Luego, al llegar a la tarea test que es donde se ejecutan las pruebas, nos encontraremos con un mensaje de error. La prueba unitaria falló (la clase HolaJava tiene un error intencional). Podemos abrir el reporte en build/reports/tests/index.html para ver la razón (Gradle nos entrega un reporte muy bonito en HTML con el resultado de las pruebas unitarias, ver figura 1).

www.sg.com.mx |

Como mencioné al principio, Gradle usa la convención sobre la configuración. De modo que lo único que estamos haciendo aquí es indicarle que cargue el plugin para proyectos Java, y ese plugin se encargará del resto. Este plugin es bastante completo, ya que va a descargar las dependencias necesarias (ninguna por el momento), compilar el código, ejecutar las pruebas unitarias y hasta puede generarnos un JAR con las clases compiladas. Vamos a ejecutarlo, en la línea de comando debemos ir al directorio HolaSG y teclear:

repositories { mavenCentral() } dependencies { testCompile ‘junit:junit:4.8.2’ }

.PRODUCTOS Tutorial Al revisar la prueba podemos ver que tenemos un defecto en nuestra clase HolaJava. Corregimos el código, cambiando la línea que genera el saludo para agregar el parámetro faltante:

Primero agreguemos a las opciones de javadoc la lista de ligas externas con la referencia a la documentación de Java, para que el parámetro y valor de retorno del método saluda tengan referencia a la clase String. Agreguemos esta linea al final de build.gradle:

return String.format(“Hola, %s! (en Java)”, quien);

Ahora ejecutamos nuevamente las pruebas con gradle test para verificar que salen bien. Aprovechemos este momento para agregarle una etiqueta con la versión y descripción a nuestro proyecto. Para agregar estos datos, simplemente hay que agregar unas líneas en nuestro script de gradle, debajo de nuestra línea donde invocamos el plugin de java.

version = ‘0.1’ description = ‘Ejemplo de uso de Gradle para Revista SG’

Documentación Técnica

La documentación técnica es una parte fundamental de todo proyecto. En Java tenemos la facilidad del javadoc que nos permite generar documentación de cada clase y cada método a partir de los comentarios que se le pongan al código, siguiendo ciertos lineamientos. El problema generalmente es generar la documentación, ya que el comando es muy engorroso de invocar. Herramientas como Ant lo hacen un poco menos complicado y Maven incluye lo necesario para poder generar la documentación; por supuesto Gradle no se queda atrás. Primero que nada, hay que agregar los comentarios a nuestro código, para que haya algo que generar: /** Clase de ejemplo para demo Gradle en SG * * @author Enrique Zamudio */ public class HolaJava {

}

/** Devuelve un saludo a la persona que se indique. * @param quien La persona a quien hay que saludar * @return Una cadena saludando a la persona indicada. */ public String saluda(String quien) { return String.format(“Hola, %s! (en Java)”, quien); }

Y ahora simplemente debemos ejecutar gradle javadoc y después podemos abrir en un navegador el archivo build/docs/javadoc/index. html para ver la documentación generada. Adicionalmente, en proyectos de tipo biblioteca de clases, es común generar por separado un JAR con el javadoc y otro JAR con los archivos de código fuente (en proyectos de software libre y en proyectos subcontratados), para tener una distribución completa. Para crear los JARs, necesitamos definir dos tareas nuevas. En Gradle, las tareas llevan un nombre, un tipo, y algunas otras propiedades, como dependencias con otras tareas, etc. Cada tarea puede tener propiedades distintas. Una tarea se declara con la palabra task y el nombre de la misma. Cada tarea lleva una serie de acciones y se le pueden agregar acciones a las tareas existentes, así como modificar sus propiedades. Gradle mantiene una lista de todas las tareas en la propiedad tasks y se pueden obtener por nombre. 14

tasks.javadoc.options.links=[ ‘http://download.oracle.com/javase/6/docs/api/’ ]

En esa lista se pueden agregar referencias a la documentación de otras dependencias del proyecto, pero por el momento no tenemos ninguna. Las tareas que necesitamos definir para crear los JARs son estas (las podemos agregar al final del script): task javadocJar(type:Jar, dependsOn:’javadoc’) { from javadoc.destinationDir classifier=’javadoc’ } task sourcesJar(type:Jar) { from sourceSets.main.allSource classifier=’sources’ }

Lo que estamos haciendo es definir la tarea javadocJar, de tipo Jar y que depende de la tarea javadoc; es importante definir esta dependencia para obligar a que primero se genere la documentación, sino vamos a generar un jar vacío o con documentación desactualizada. Para el segundo Jar no tenemos dependencias porque sólo vamos a incluir los fuentes, pero hay que indicar que queremos únicamente los fuentes del proyecto y no los de las pruebas. Cabe mencionar que el plugin de Java agrega el concepto de sourceSets a Gradle, que son precisamente los conjuntos de archivos de código fuente. Por omisión se definen dos conjuntos: main, con las clases del proyecto, y test, con las pruebas unitarias. Por omisión, los fuentes del conjunto main están en src/main/java. Dado que estamos siguiendo convenciones, no es necesario que especifiquemos todo esto de forma explícita en nuestro script. En la tarea de sourcesJar, estamos incluyendo TODOS los fuentes (incluyendo recursos) del conjunto main. Y a cada Jar le pusimos un clasificador, el cual irá en el nombre del archivo resultante, ya que por omisión Gradle va a crear los Jars usando el nombre del proyecto, la versión y el clasificador. Y ahora podemos ejecutar estas tareas de manera secuencial, simplemente hay que indicar cada una en la línea de comando. De modo que tecleamos gradle javadocJar sourcesJar y al final en el directorio build/libs tendremos HolaSG-0.1-javadoc.jar y HolaSG-0.1-sources.jar. Pero estas son tareas definidas específicamente en este proyecto, no parecen ser algo estándar; la idea de estos scripts y herramientas es facilitarle la vida a cualquier persona que quiera construir el proyecto, permitiéndoles ejecutar el script sin tener siquiera que verlo; honestamente, ¿cuántos de nosotros hemos visto un Makefile de un proyecto que bajamos y construimos desde fuentes? Simplemente le damos ./ configure && make && sudo make install y listo. Afortunadamente, el plugin de Java para Gradle detecta cualquier tarea de tipo Jar y la agrega automáticamente a la tarea de assemble. Y esa tarea a su vez depende de las de compilación (pero no de las de pruebas). De modo que podemos definir que algunas tareas se ejecuten por omisión en nuestro script. Agreguemos esta línea después de donde definimos la versión:

defaultTasks ‘build’, ‘assemble’

Ahora, podremos simplemente ejecutar gradle sin ningún argumento adicional y se ejecutarán las tareas de compilación, pruebas, javadoc, etc. Puedes borrar todo tu directorio build antes de correr la tarea, para asegurar que sí se recree todo. Al final, en build/libs tendremos tres JARs: el binario, el de fuentes y el de documentación.

Capacidades avanzadas

La simplicidad de uso de Gradle puede ser engañosa, pues es realmente una herramienta muy, muy poderosa. En esta ocasión quise resaltar lo sencillo que puede ser su uso, para compilar un proyecto muy sencillo. Algunas capacidades avanzadas que no se cubrieron en este tutorial de introducción pero que seguramente requerirán en proyectos complejos son: incluir dependencias en la configuración de compile y tal vez la de testRuntime; agregar dependencias locales, para esos casos tan comunes en que se tiene un directorio con muchos JARs existentes; convertir el proyecto en uno políglota, cambiando el plugin de Java por el de Groovy para compilar y probar clases en ambos lenguajes; crear scripts multi-proyecto, para poder compilar, armar y juntar varios proyectos con un solo comando, manejando dependencias y otras configuraciones tanto de manera individual como global. Esta última capacidad hace a Gradle mucho muy superior a otras herramientas de construcción populares. También es posible crear tareas de manera dinámica, es decir, que no están definidas de manera formal en el script pero éste contiene código que al momento de ejecutarlo, genera tareas que pueden depender de otras tareas y agregarse a las existentes. Esto parece muy esotérico al principio, pero realmente puede facilitarnos la vida, especialmente cuando se usa Gradle para organizar, integrar y automatizar la construcción de proyectos existentes. El código fuente utilizado para este tutorial está disponible en: https://github.com/chochos/HolaSG .BIO Enrique Zamudio es Licenciado en Sistemas Computacionales egresado de la Universidad Iberoamericana y tiene 17 años desarrollando software profesionalmente, principalmente utilizando tecnologías relacionadas con Java del lado del servidor. Es autor de los proyectos de software libre jAlarms y j8583, y forma parte del staff de la comunidad de desarrolladores JavaMéxico. @chochosmx github.com/chochos.

El sector de TI en México en búsqueda de proyectos ››Por Claudia Ivette García Romero

l sector de servicios de tecnologías de información (TI) es considerado estratégico debido al valor agregado de la actividad así como por el potencial con que cuenta México para poder competir internacionalmente. Por ello, el gobierno federal desde finales del año 2002 desarrolló, en conjunto con el sector privado y público en sus tres niveles, una agenda sectorial específica para desa16

rrollar el sector TI. Cabe señalar que en 2008, ésta fue revisada y mejorada para dar lugar a lo que hoy conocemos como PROSOFT 2.0, documento que integra las acciones de política pública que se requieren ejecutar para poder aprovechar la capacidad de nuestro país como una plataforma para desarrollar servicios de TI tanto para consumo interno como global.

.EMPRENDIENDO Industria

“El fondo PROSOFT en sus primeros

siete años de operación ha apoyado 2,084 proyectos logrando un monto de inversión total de más de 10,144.53 millones de pesos.”

Iniciativas

Hoy en día PROSOFT 2.0 cuenta con un conjunto de iniciativas de alcance nacional que permiten avanzar en el desarrollo de la agenda, por lo que cada una de ellas se puede vincular a alguna de las siete estrategias del programa. La tabla 1 lista las iniciativas agrupadas por estrategia que apoyan:

Inversiones y exportaciones • Mexico IT • IT Link

Capital Humano • Mexico FIRST • Talento de TI • Estándares laborales

Marco legal • Ley de datos personales • Homologación normativa • NOM 151 - Conservación de mensajes de datos

Difusión de uso de TI • Proyectos de usuario • Centros Adhoc • Sellos de confianza

Productividad y sinergia • Iniciativas de clusters • Fomento a la innovación • Mapas de ruta (nichos) • Parques de TI

Calidad y madurez • MoProSoft • Iniciativa PSP/TSP • CMMI

Financiamiento • Fondo PROSOFT • Fondo contragarantías • Mexico Venture Tabla 1. Estrategias e iniciativas de Prosoft.

Fondo PROSOFT

Quizá la iniciativa más conocida es el fondo PROSOFT, mismo que en sus primeros siete años de operación ha apoyado 2,084 proyectos logrando un monto de inversión total de más de 10,144.53 millones de pesos, de los cuales 2,981.05 millones fueron aportados por el PROSOFT, 1,685.78 millones de pesos por las entidades federativas y 5,438.80 millones de pesos por el sector privado, académico y otros participantes. Hay que tener presente que el fondo busca facilitar el despliegue de las acciones para lograr los objetivos planteados en la política pública sectorial, así como potenciar el impacto de los recursos, fortaleciendo la cobertura de las acciones a través de la coordinación institucional y vinculación de acciones con las entidades federativas, el sector privado y el académico. Para lograr ésta alineación, los objetivos específicos del fondo toman como base lo definido en las estrategias previamente mencionadas. Para el ejercicio 2011, el fondo cuenta con 676 millones de pesos para apoyar proyectos que permitan alcanzar los objetivos antes descritos. A la fecha, el Consejo Directivo del PROSOFT ha aprobado proyectos por 190 millones de pesos que permitirán capacitar a más de 15,200 personas y certificar a casi 9,500 en habilidades técnicas, de negocio y de manejo del idioma inglés. Con esto se fortalecerá el capital humano, principal insumo de esta industria basada en conocimiento. Recientemente el Consejo Directivo del PROSOFT aprobó la emisión de la Cuarta Convocatoria del año para recibir proyectos, misma que cerrará el próximo 31 de agosto del presente. Dado que la demanda de recursos para los proyectos que se reciben sobrepasa los recursos disponibles, el Consejo aprobó la aplicación de un modelo paramétrico que se utiliza para priorizar proyectos de forma transparente. El modelo paramétrico otorga puntos en función de elementos que se encuentran en el proyecto, es decir premia la existencia de los mismos. Los elementos con mayor puntaje son actividades de innovación, certificación de competencias, creación de empleos de alta especialización, ya sea de nivel posgrado o expertos en vocaciones estratégicas, así como las acciones de impacto nacional. Es importante que los interesados en someter solicitudes de apoyo conozcan el modelo y tengan en cuenta los elementos a los que se les otorga mayor puntaje al momento de priorizar la asignación de recursos. .BIO Finalmente, hay que recordar Claudia Ivette García Romero es Directora General de Comercio que los fondos se otorgan conforInterior y Economía Digital de Secretaría de Economía. me a lo dispuesto en las Reglas de Operación del Programa, por lo que los proponentes deben no Referencias: [1] PROSOFT. http://www.prosoft.econosólo tener en cuenta los beneficios mia.gob.mx de recibir un apoyo sino también [2] PROSOFT, Modelo paramétrico. http://swgu.ru/sg33r7 las obligaciones y compromisos vinculados a estos.

Software Guru

Este programa se basa en las siguientes siete estrategias: 1. Promover las exportaciones y la atracción de inversiones. 2. Elevar la cantidad y calidad del capital humano. 3. Promover la adopción de un marco legal que impulse el uso y la producción. 4. Incentivar el acercamiento entre usuarios de TI con empresas del sector ubicados en el país. 5. Crear una base más amplia de empresas y agrupamientos del sector de TI, así como elevar la competitividad de los mismos. 6. Promover que las empresas alcancen niveles internacionales en capacidad de procesos. 7. Aumentar las opciones y posibilidades de acceso a recursos financieros para el sector de TI.

www.sg.com.mx |

Estrategias

.PUBLIRREPORTAJE

INFOTEC

ejemplo de innovación tecnológica mexicana

l Fondo de Información y Documentación para la Industria INFOTEC es un fideicomiso del Conacyt fundado hace más de 36 años. Comenzó su como un Centro de Investigación; en la década de 90’s como el encargado de administrar la Red Tecnológica Nacional (RTN), la primera red de Internet en el país, siendo la institución que se ha propuesto superar los retos que trae consigo el siglo XXI con la denominada Sociedad de la Información y el Conocimiento (SIC). INFOTEC, se ha enfocado en mantener a México a la vanguardia en el ámbito tecnológico, por ello, su misión está orientada al apropiamiento de las TIC, para que las personas y las organizaciones puedan tener un mejor desarrollo. A través de las tecnologías se puede mejorar el bienestar y la productividad. Con base en la colaboración y participación de líderes y especialistas mexicanos, INFOTEC ha impartido asesoría para la creación y administración de portales web, académicamente, cuenta con una Unidad de Posgrados avalados por la Universidad de Texas y también ha dedicado todos sus conocimientos en desarrollar e impulsar software libre nacional.

SemanticWebBuilder: Una plataforma para el desarrollo de aplicaciones y portales semánticos

Internet se ha convertido en un ente tan grande que es difícil imaginarlo, y aun cuando lográramos hacerlo, justo en ese momento ya habría cambiado exponencialmente. Desde el momento en que incrementó el uso de las nuevas tecnologías INFOTEC creó su propia plataforma para la construcción de páginas web. Por medio de WebBuilder el contenido de un portal es posible distribuirlo mediante módulos, permitiendo conocer el ciclo de vida de un sitio, adjuntar fuentes externas y dar un diseño idóneo a la temática del portal. Plataforma fueron reconocida por la Cámara de Diputados por su contribución al e-Gobierno en el país. WebBuilder evoluciona a SemanticWebBuilder una plataforma que permitirá la transición de la web 2.0 a la web 3.0, dando significado al mundo de información contenida en la red, con esta herramienta se podrán realizar búsquedas basadas en esquemas ontológicos, lo que permitirá obtener información precisa y no dispersa.

BeakOSGNU/Linux. Software Libre impulsado por INFOTEC

Para tener un mayor impulso dentro de la generación tecnológica mexicana, INFOTEC creó el Sistema Operativo BeakOS, el cual está basado en el kernel de Linux y puede ser utilizado tanto en computadoras con bajos recursos como en servidores de alto rendimiento. El Sistema ayuda a un mejor aprovechamiento del consumo del CPU y la 18

memora RAM de los equipos de cómputo, permitiendo que el usuario final pueda hacer uso de él con tan sólo 256 MB de RAM. Uno de los casos de éxito de BeakOS y que han sido testigos de las ventajas que ofrece el SO ha sido el Portal del Bicentenario, desarrollado al 100% bajo un esquema de solución por medio de BeakOS.

Gobiernos Locales Digitales. Conectando el Gobierno Local con sus ciudadanos.

INFOTEC puso en marcha el proyecto Gobiernos Locales Digitales con la finalidad de acercar a los municipios a la política de gobierno digital, disminuir la brecha digital y mejorar las percepciones de los ciudadanos con respecto a las administraciones municipales. El objetivo es concentrar en un portal las políticas públicas y campañas del municipio para que puedan ser consultadas por la población desde cualquier parte.

Posgrados en INFOTEC. Dedicados a la formación y desarrollo de capital humano

En la actualidad, el acelerado progreso y penetración de la Sociedad de la Información y el Conocimiento, está impulsando el crecimiento de empresas de base tecnológica, lo cual se ha traducido en el incremento de lasnecesidades de personal con perfiles especializados en el campo de las TIC. Es por ello, INFOTEC ha desarrollado conjuntamente con universidades internacionales una oferta académica de calidad, con posgrados enfocados a formar y capacitar capital humano de alta especialización con conocimientos, habilidades y aptitudes para la dirección estratégica de empresas y proyectos de los sectores público y privado. Ejemplo de la calidad es la Maestría en Dirección Estratégica de las Tecnologías de la Información y la Comunicación (MDETIC), la cual fue reconocida en 2010 como uno de los mejores posgrados de México por la revista Expansión.

Más de INFOTEC…

Por otro lado, INFOTEC, formando parte de la administración federal, trabaja para sectores públicos y privados a los que ofrece servicios integrales en TIC y soluciones de infraestructura que abarcan desde telecomunicaciones, seguridad informática, centro y base de datos, bóveda de medios, administración y operación de portales. Es por ello que empresas, organizaciones y sectores gubernamentales se pueden acercar a INFOTEC para solicitar un servicio de Fortalecimiento Tecnológico, cuya atención estará siempre disponible en las instalaciones ubicadas en Av. San Fernando 37, delegación Tlalpan. http://infotec.com.mx

factor humano en los procesos de software Generalmente

escuchamos la frase “desarrollar software es un arte”, ¿por qué no es tan sólo un trabajo de ingeniería? Porque es un conjunto de variables técnicas y variables humanas. Las normas y los modelos para el desarrollo de software tienen dos componentes básicos: los administrativos y los ingenieriles. Pero cuando hablamos de proyectos de mejora de procesos, se considera una estrategia completa si en ella se consideran iniciativas de motivación, manejo del cambio y trabajo en equipo, porque de lo contrario la implantación de procesos no es exitosa. Incluimos este tema como principal en ésta edición debido a que continúan en auge las iniciativas de mejora de procesos en las organizaciones, lo cual implica una inversión importante para las empresas, por lo que asegurar el alcance de los objetivos planteados es vital para evitar pérdidas en dicha inversión y esto no depende del modelo o norma elegida, sino de la estrategia de definición e implantación en la cual el factor humano no debe pasar por “obvio” sino ser analizado y guiado para poder modelarse. Cuando hablamos de “mejora de procesos”, estamos hablando de una evolución más allá de mejores formatos o mejores procedimientos porque detrás de un proceso mejorado, hay una mejora en comunicación y retroalimentación sobre su uso, hay una cultura de procesos en marcha entre todos los roles que en ellos participa, hay beneficios en los proyectos, mejoras en los equipos y todo ello, nos trae una mejora organizacional. ¿Y qué es una mejora organizacional? ¿una mejora de procesos, una mejora en tecnología o una mejora en las personas? Para nosotros, es una mejora de las tres y eso es lo que trae a nuestra industria de TI, una verdadera evolución.

www.sg.com.mx |

Software Guru

.PRINCIPAL

Software People

Improvement

responsabilidad y consciencia

››Por Walter Ariel Risi

Un líder

de proyecto estaba entrevistando a desarrolladores para un puesto vacante. Al terminar sus entrevistas platiqué con él y sus conclusiones fueron muy interesantes: “el primer candidato es ‘senior’ en el lenguaje que nos interesa y tiene mucha experiencia en desarrollo”. Pregunté entonces, “¿y qué hay del segundo candidato?”, y me respondió “el segundo me gustó más todavía… tiene menos experiencia en el lenguaje, pero es ‘senior como persona’, es el tipo de desarrollador que quiero en mi equipo, estoy seguro de que la falta de experiencia la compensará enseguida”. ¿Por quién se volcó nuestra decisión? En ese momento, por el segundo candidato… ¡y los resultados nos dieron razón! En pocas semanas, parecía que hubiéramos conocido a esta persona de varios años, tal era la confianza que creamos mutuamente. ¿Y las deficiencias técnicas? Las compensó en los primeros meses, poniendo un poco más de sí mismo cada día. En otra ocasión, estábamos muy presionados por los tiempos. Entrevistamos varios candidatos para una posición técnica clave y el candidato técnicamente más sólido mostraba varias características que nos hacían dudar (se mostraba egocéntrico e inestable, particularmente). Como estábamos presionados por una necesidad urgente en un proyecto, decidimos contratarlo, sabiendo que era posible que el candidato renunciara a los 6 meses de haberlo incorporado. Pensamos “no será un problema, ya que el proyecto dura 7 meses”. A nuestra sorpresa, no renunció a los 6 meses… renunció a los 4 meses, dejando el proyecto casi a la mitad y obligándonos a buscar de urgencia un reemplazo.

¿‘Seniority Personal’?

¿Qué quiso decirnos el entrevistador cuando nos decía que el primer candidato era ‘senior como persona’? Lo que quiso decirnos es que esta persona, más allá de su juventud, evidenciaba responsabilidad en sus puestos anteriores, consciencia por sus fortalezas y limitaciones, entre otras características. Elementos menos medibles y tangibles que el nivel de seniority en .NET o Java, pero igual de importantes a la hora de integrar un equipo sólido y hacer una apuesta a largo plazo por un profesional de software.

Alternativamente, el segundo caso nos encontró con una persona madura en cuanto a edad (algo más de treinta años), con fuerte experiencia técnica, pero con menos de ese ‘seniority personal’ del que nos habló el entrevistador. La persona mostraba limitado compromiso en sus puestos anteriores (“siempre busco un mejor postor, si alguien me paga más, cambio inmediatamente de trabajo”) y un manejo emocional que nos llenaba de dudas (era engreído, egocéntrico, no escuchaba e interrumpía constantemente al otro al hablar). Los elementos tangibles en este candidato eran muy fuertes (sabía mucho de .NET, efectivamente) y tomamos la decisión en pos de ello. Sin embargo, al poco tiempo estaba causando incomodidades en su equipo de trabajo y se fue de la empresa antes de terminar sus compromisos. La emocionalidad y la consciencia en la empresa han estado dando vueltas desde hace bastante tiempo, pero normalmente en los estratos ejecutivos, encontrando aún poco eco en los niveles de ingeniería. Normalmente más escépticos a lo ‘blando’, quienes nos educamos como ingenieros hemos sido formados para confiar en lo tangible y medible. Pero como vimos en los relatos anteriores, esto no siempre es suficiente… a veces, confiar solamente en los aspectos técnicos de un profesional nos puede causar desagradables sorpresas. Y al revés, muchas veces profesionales menos sólidos técnicamente pueden apoyarse en sus características personales para suplir rápidamente sus falencias técnicas.

Algunas características

¿Cuáles son los elementos del mencionado ‘Seniority Personal’? Es una pregunta fácil con una respuesta difícil o incluso inexistente. La realidad es que hemos acuñado este término específicamente para este artículo, con propósitos eminentemente prácticos y no corresponde a una definición académica alguna. Posiblemente, encontraremos algunas potenciales respuestas a esta pregunta en una publicación dedicada a la psicología organizacional o espiritualidad en el trabajo, pero estamos inmersos en el mundo de la ingeniería de software y necesitamos una aproximación práctica y no necesariamente perfecta desde la teoría. En este contexto, me atrevo a delinear una serie de elementos que debería tener una persona ‘senior en lo personal’ para un puesto de ingeniero de software o similar:

.PRINCIPAL

Por supuesto, esta es una lista sesgada por mis propias experiencias y posiblemente incompleta. Pero como dijimos, apuntamos a lograr una definición práctica. El lector podrá incorporar sus propias características. A continuación, profundizaremos en cada uno de los elementos mencionados.

Responsabilidad

Es aquí donde se juega la responsabilidad. En el primer caso, podemos decidir quedarnos más tiempo, sabiendo que nuestra responsabilidad es cumplir con ciertos hitos durante ese día y que invertimos más tiempo del habitual en actividades de esparcimiento. En el segundo caso, podemos decidir invertir algo de tiempo de nuestro almuerzo o posterior a las seis de la tarde para compensar nuestras falencias técnicas y estudiar. En el tercer caso, podemos acordar con nuestros compañeros volver después del partido o bien, trabajar desde nuestra casa para ayudar al resto del equipo.

www.sg.com.mx |

La responsabilidad suena a un concepto tan intuitivo que parece obvio plantearlo como un elemento fundamental en el Seniority Personal. Sin embargo, ¿cuántas veces observamos notables faltas de responsabilidad en nuestro propio trabajo y en el ajeno? En mi experiencia, la responsabilidad es muchas veces utilizada como palabra, pero no tan frecuentemente puesta en acción. La mayoría de nosotros trabajamos en un horario de nueve a seis de la tarde o similar, y somos al menos responsables de cumplir con nuestro horario de trabajo. ¿Qué sucede entre las nueve y las seis y que sucede después? En el mejor de los casos, nuestro trabajo puede realizarse en el horario establecido, sin complicaciones y nos retiramos de la oficina a la hora habitual. Pero no siempre es así: • Podemos no terminar el trabajo porque dedicamos más tiempo a un almuerzo por el cumpleaños de un compañero, nos distraemos en la máquina de café charlando con colegas sobre el partido de ayer o salimos varias veces a fumar a la calle. • Ingresamos a nuestro puesto sabiendo que teníamos menos experiencia de la requerida. Digamos que conocíamos del lenguaje requerido, pero no lo suficiente y fuimos aceptados igualmente cuando vieron nuestro

interés. Pero en la práctica, llegan las seis de la tarde y nuestro trabajo no está terminado aún dada nuestra falta de experiencia. • El proyecto está complicado y todos nuestros compañeros están postergando compromisos personales para quedarse hasta más tarde, puesto que hay una fecha límite por cumplir. Llegan las seis de la tarde y tenemos entradas para un partido de fútbol importante de nuestro equipo favorito.

Software Guru

• Responsabilidad. Ser capaz de balancear sus intereses y necesidades personales con los compromisos adquiridos con sus compañeros y empleadores. • Consciencia. Ser capaz de darse cuenta de los efectos de sus propias acciones en sí mismo y en el resto. Detenerse a pensar antes de actuar inmediátamente. • Salud emocional. Presentar tendencia hacia las emociones que favorecen un clima de trabajo positivo y agradable.

.PRINCIPAL

“Desgraciadamente, en muchas organizaciones la responsabilidad es reemplazada por la amenaza”. No se trata de sacrificar nada, sino de honrar los compromisos establecidos desde la propia iniciativa. Seguramente, el almuerzo con los compañeros, la charla de café y el partido nos sirven para mejorar nuestro humor y relajarnos, pero los compromisos siguen vigentes y si somos responsables, encontraremos la manera de honrarlos. No se trata tampoco de forzar situaciones desagradables. Desgraciadamente, en muchas organizaciones la responsabilidad es reemplazada por la amenaza: “hoy no se va nadie hasta terminar esto”, “el que no termina hoy es despedido”, “el fin de semana se trabaja obligatoriamente”. Estos mecanismos más que crear responsabilidad, la destruyen. Un empleador que hace esto con sus empleados es también irresponsable por su propia salud y bienestar. Los empleados en tal situación se volverán irresponsables recíprocamente, sólo cumplirán sus compromisos por la fuerza y ante la primera oportunidad se cambiarán de trabajo. La responsabilidad real está típicamente en nuestro interior por voluntad propia, no es forzada por amenazas ni motivada por el dinero. Si encontramos un ingeniero técnicamente bueno y además responsable, cuidémoslo, puesto que él no solamente trabajará mejor sino que difundirá el valor de la responsabilidad entre sus compañeros. Por el contrario, un ingeniero técnicamente bueno pero irresponsable es casi tan impredecible como un ingeniero técnicamente pobre.

Consciencia

Aquí hablamos de una acepción práctica e intuitiva de consciencia. Esto es “estar en pleno uso de nuestros sentidos y habilidades y actuar en consecuencia”, o bien “darnos cuenta de qué estamos haciendo, por qué lo hacemos y que ocurrirá después de que lo hagamos”. Volvamos ahora al mundo del desarrollo de software: ¿actuamos conscientemente en todo momento? Tal vez la mayoría de las veces, pero probablemente no todo el tiempo. Y quizás, cuando estamos a través de una de esas ocasiones de “inconsciencia”, tenemos que tomar una decisión crítica o realizar alguna acción clave. ¿Suena raro? Veamos algunos ejemplos: El usuario de nuestro proyecto nos insiste con un requerimiento adicional que está claramente "fuera de alcance". Incluir este cambio implica un riesgo fuerte de no cumplir con la fecha del proyecto, así que nos mantenemos inflexibles y no aceptamos negociar el cambio. Entonces, alguien nos pregunta, "¿le serviría el software al usuario si no incluimos este cambio?"… después de pensar por un tiempo, somos conscientes de que el software entregado será casi inútil para el usuario sin ese requisito. Estamos trabajando en dos proyectos diferentes. Nos gusta el reto de uno de ellos y no soportamos el otro, que es aburrido y burocrático. Así, día tras día, priorizamos el trabajo en el primero. Pasan un par de meses en este ritmo, y de repente nos encontramos con que no sólo el segundo proyecto es aburrido y burocrático, sino que también está muy, muy atrasado. De repente nos damos cuenta que hemos postergado las tareas que no nos gustan por mucho tiempo y estamos con un gran problema, entonces ahora somos conscientes de esto, pero es muy tarde. Estamos dirigiendo un proyecto para un cliente muy importante y el usuario quiere cumplir con una fecha que es casi imposible. Como no 24

queremos enfrentarnos a este usuario tan influyente, aceptamos la fecha y forzamos al equipo a trabajar los fines de semana. Al mes, el equipo está completamente agotado y varios miembros clave deciden renunciar. Miramos hacia atrás y vemos no sólo fuimos inconscientes al comprometer una fecha imposible, sino que también lo fuimos al presionar irracionalmente al equipo. Ahora tenemos un doble problema: explicarlo al usuario y conseguir reemplazo para esas personas que renunciaron. Es muy probable que el lector encuentre estas situaciones muy familiares. Todos hemos pasado a través de una o más situaciones como estas. Simplemente, algo se pone entre nosotros y nuestro mejor juicio, y de repente, no vemos claramente. Apresurados, presionados, asustados, tomamos una decisión sin tener en cuenta que va a suceder realmente y al tiempo, las consecuencias son muy negativas. En esos casos, tomamos decisiones sin estar el pleno dominio de nuestras facultades… tomamos decisiones sin total uso de nuestra consciencia.

Salud emocional

En mi experiencia, existen personas que por las cuáles nos aumentan las ganas de venir a trabajar todos los días. Son personas que en situaciones difíciles, nos las hacen más llevaderas y agradables. Veamos algunos casos típicos: • Alguien que nos inspira continuamente para especializarnos en una tecnología particular. Por ejemplo, el fanático de Test Driven Development que nos contagia su fanatismo por el código sólido y ordenado. • Alguien que convierte los proyectos aburridos en oportunidades de aprendizaje. Por ejemplo, el desarrollador experimentado que cuando nos toca un proyecto con tecnología obsoleta, aprovecha para enseñarnos como hacer una reingeniería. • Alguien en quien podemos confiar 100% en todas las situaciones y saber que siempre jugará por nuestro mutuo beneficio. Por ejemplo, el colega al cual le podemos dejar nuestro trabajo en las vacaciones sabiendo que nos hará quedar bien y que podremos descansar tranquilos. • Alguien que siempre da lo mejor para compartir lo que tiene. Por ejemplo, el arquitecto experimentado que comparte su conocimiento y termina formando gente igual o mejor que él, recibiendo por ende un gran respeto a cambio. Estamos hablando de personas técnicamente muy competentes, pero que además exhiben características emocionales que ejercen este efecto positivo sobre el clima de trabajo en general. El trabajo agradable se hace más agradable y el trabajo más aburrido se hace más llevadero cuando las personas tienen varias de las características siguientes, entre otras: • Pasión, como es el caso de ese ingeniero que nos inspiró para especializarnos en esa tecnología en la cual él estaba convencido. • Positividad, como es el caso de ese desarrollador que convirtió un proyecto aburrido en una oportunidad para aprender una nueva habilidad. • Integridad, como es el caso de esa persona a la cual podemos delegar nuestras tareas en vacaciones, y confiar 100% en que dará lo mejor de sí. • Generosidad, como es el caso del arquitecto experimentado que daba lo mejor de sí, y formaba otros iguales o mejores que él. La lista, por supuesto, sigue e incluso el lector podrá agregar sus propias emociones a la misma. Otros ejemplos son la gratitud exhibida por un líder

.PRINCIPAL

Las últimas décadas han encontrado a la ingeniería de software haciendo cada vez más avances en los procesos y metodologías para lograr proyectos de software más productivos, predecibles, económicos y con un mayor nivel de calidad. Durante los últimos diez años, los métodos ágiles y enfoques derivados (por ejemplo, “Software Craftmanship”) han revigorizado la importancia de las personas y sus interacciones por sobre los procesos y herramientas. Métodos como el People CMM promueven la madurez en los procesos de gestión de las personas, como el desarrollo de la carrera y el desarrollo de competencias. Sin embargo, todos estos enfoques siguen viendo a las personas desde la óptima mayormente profesional… ¿qué hay de las características personales? Si no las consideramos, estamos ignorando un componente clave y los resultados no serán del todo óptimos. De poco sirve un ingeniero muy capacitado y muy experimentado si es irresponsable, si no actúa conscientemente en situaciones críticas o si es dominado por emociones negativas. Invito a ir más allá de los planes de carrera y la importancia de la competencia técnica de los programadores, e invito a mejorar a las profesionales como “personas”. Nos hemos preocupado mucho tiempo por el Seniority en términos de competencias técnicas, de liderazgo y organizacionales, pero poco por el “Seniority Personal”. En mi experiencia, la excelencia técnica sumada a un “Seniority Personal” considerable (combinando responsabilidad, consciencia por sus acciones y una emocionalidad saludable) hace la diferencia entre un profesional excelente y uno excepcional. Invito a complementar el Software Process Improvement, la mejora de los procesos, con Software People Improvement… una mejora de las personas.

El primer paso

Lecturas recomendadas

En los últimos años hemos estado viendo una creciente importancia de la disciplina llamada “negocios conscientes” o “Conscious Business”. En forma sencilla, podemos definirla como una disciplina que busca hacer del trabajo un lugar en el cual puedan ponerse en práctica los valores humanos. En un sentido práctico, Conscious Business argumenta que humanizar el trabajo mejorará tanto la vida de las personas como los resultados económicos. Personalmente, me considero un ferviente creyente en esta disciplina. Las siguientes son algunas referencias a publicaciones, autores y organizaciones que se mueven en el área de Conscious Business o bien en campos cercanos o relacionados. • Los libros “La Empresa Consciente” (“Conscious Business”) y “Metamanagement”, de Fred Kofman, son absolutos clásicos en la materia. Ambos están disponibles en español. Fred Kofman es además socio fundador de una de las principales consultoras en la materia. • Los libros del filósofo americano Ken Wilber sientan las bases filosóficas subyacentes a los negocios conscientes. Ken Wilber es el fundador de la llamada “teoría integral”, un marco teórico que unifica diferentes aspectos del universo (desde lo físico hasta lo espiritual). Recomiendo empezar por el libro “Breve Historia de Todas las Cosas” (“A Brief History of Everything”), también disponible en español. • La organización sin fines de lucro “Waking up the Workplace” (http://www.wakinguptheworkplace.com) organizó una serie de “teleconferencias” con los autores más reconocidos en la temática de negocios conscientes. Las charlas son realmente muy buenas, y son una buena aproximación hacia los diferentes autores y enfoques. Por supuesto, hay más referencias y autores, y la lista podría seguir y seguir. A los lectores interesados los invito a contactarme por mail, Twitter o a través de mi Blog.

¿Cómo empezamos a mejorar a las personas? ¿Qué podemos hacer para elevar el nivel de responsabilidad, consciencia y salud emocional en el trabajo? Existen profesionales y organizaciones especializados en temática relacionadas, y el detalle de las posibles iniciativas excede este artículo e incluso mi área de especialidad. Entre las actividades posibles a realizar está desde el coaching individual de las personas hasta iniciativas de cambio cultural a lo largo de toda la empresa, que pueden llevar varios años. En la siguiente sección (Lecturas y referencias recomendadas) incluyo varias referencias a autores reconocidos a .BIO Walter Ariel Risi tiene más de 12 años de experiencia en el mercado de IT. Su foco actual está en conciliar la tecnología, los negocios y los aspectos humanos. Actualmente, es Gerente de Tecnología y Desarrollo para Argentina en Pragma Consultores (Practia Consulting en México), un prestigioso grupo internacional de empresas de consultoría en Tecnología y Negocios. Walter es Licenciado en Informática, con estudios de posgrado en negocios, calidad y coaching. Walter puede ser contactado en wrisi@pragmaconsultores.com, @wrisi y a través de su blog (www.walterarielrisi.com).

Software Guru

Software People Improvement

través de los cuáles se puede profundizar en la temática. De todas maneras, siempre hay un primer paso que podemos dar relativamente con poca ayuda externa. Ese primer paso tiene que ver con comenzar a valorar la responsabilidad, consciencia y salud emocional. Ese primer paso nos permitirá empezar a reconocer su presencia o ausencia en las demás personas y sobre todo, en nosotros mismos.

www.sg.com.mx |

a su equipo por el esfuerzo realizado, o la fuerza de superación que exhibe un profesional para vencer a los obstáculos de un proyecto y sacarlo adelante. Si bien estas cosas parecen bastante cotidianas, reflexionando sobre nuestras propias experiencias, seguramente encontraremos muchos de estos casos donde las emociones incrementaron el valor de un profesional de software. En mi experiencia, no sólo las personas que exhiben estas “emociones saludables” son más confiables y productivas, sino que también contagian las mismas a sus compañeros. Además de ser buenos profesionales, son constantes productores de un buen clima laboral en los equipos de software

.PRINCIPAL

El Sponsor

liderando el cambio

››Por Leonardo N’Haux y Cecilia Scauso

Existe

una historia que relata un episodio del tristemente célebre pirata galés Henry Morgan: Huyendo de la Armada española que pretendía capturarlo, se ve en la necesidad de anclar en el interior de una bahía caribeña para reabastecer y reparar su galeón. Ya en tierra, ordena a un grupo de sus hombres instalar un pesado cañón en la cima de un risco a la entrada de la bahía, para de esa manera proteger su posición. Regresa a las dos horas para constatar el avance del proyecto y verifica que el equipo designado solo había movido el cañón poco más de 200 metros. Molesto por la evidencia encontrada exige una explicación al líder del equipo, quien contesta: “Mi Capitán, es que solo somos 10 para semejante encomienda”. Buscando comprometer al equipo con el resultado deseado, Morgan saca su trabuco, apunta con dirección al marino que tenía más cerca y dispara, matando al desdichado colaborador. Guarda su arma, y mirando fijamente al resto del equipo, les dice: “Pues a ver si ahora entre 9 lo pueden hacer más rápido.” Henry Morgan pudo haber sido un líder muy exitoso como filibustero, pero como sponsor de un proyecto de mejora hubiera sido un fracaso rotundo. 26

En agosto de 2005 tuve la oportunidad de participar en uno de los primeros eventos donde los diferentes Clusters de TI de México buscan compartir experiencias y alinear sinergias. Dicha reunión fue en Aguascalientes, las autoridades locales hicieron un excelente trabajo y el evento fue todo un éxito. Pero fue en ese magno foro que me tocó escuchar una de las aberraciones más recordadas de mi carrera profesional. Como parte de la agenda, se había conformado un panel para abordar el tema de los modelos de calidad y su impacto en la productividad de la industria. Entre los participantes había prestigiosos académicos, empresarios, el director de TI de una empresa multinacional y un alto ejecutivo de un organismo gubernamental, responsable de uno de los grupos de desarrollo de software más grandes de la administración pública nacional. Cada disertante presentó sus argumentos en favor de los distintos modelos, se habló de CMMI, Moprosoft, ITIL, etcétera. Luego de escuchar atentamente las respectivas presentaciones le llegó el turno al representante gubernamental, quién con voz firme comentó: “Todos estos modelos son muy interesantes, pero nosotros no utilizamos nada de eso. Nosotros nos basamos en el Modelo Azteca: al que no termina en tiempo, le cortamos la cabeza”. Yo sentía que estaba viendo a Henry Morgan en persona. Cualquier iniciativa de implementar mejores prácticas en este contexto y con esa filosofía de trabajo enfrenta muchos obstáculos: limita el impacto de la mejora, desmotiva a los equipos de trabajo, y como consecuencia, la organización en su conjunto pierde una valiosa oportunidad de aumentar su competitividad. Ser sponsor de un proyecto de mejora implica compromiso y disciplina. Lamentablemente es común que este importante rol no sea tomado con la seriedad requerida. Ningún proyecto de mejora debería llevarse a cabo sin un sponsor, sin su participación activa no puede haber una visión clara para lograr resultados exitosos. El primer paso para iniciar un proyecto de mejora es construir un soporte organizacional a través de un patrocinio fuerte de la alta gerencia. Como consultores, en ocasiones somos testigos del cambio que sufre la imagen del sponsor hacia adentro de la organización, dependiendo de la etapa del proyecto. La misma persona que al inicio identifican como el líder visionario, al poco tiempo es el villano de la película, que lejos de proveer visión y recursos, espera milagros irrealizables. Nosotros sabemos que los sponsors no son villanos, que realmente quieren obtener beneficios del proyecto de mejora. La situación es que los sponsors son por lo general dueños de empresas o directores de la organización de TI, razón por la cual sus prioridades entran en conflicto habitualmente, por ende se pierde el foco en las responsabilidades del rol específico del sponsor.

Tips para sponsors

A continuación compartimos algunas buenas prácticas para que usted se convierta en el héroe de la película.

.PRINCIPAL

2. Recursos disponibles. El sponsor debe planear anticipadamente la asignación de los recursos necesarios para la ejecución del proyecto. Esto puede implicar actividades de negociación con empleados y clientes, modificar planes de proyectos en curso y liberar espacio para las actividades propias del proyecto de mejora. Debe seleccionar y capacitar a las personas involucradas, para lo cual debe entender las habilidades y conocimientos requeridos. Esto no es trivial, semejante transformación necesita gente con un perfil muy específico. 3. Disponibilidad oportuna de proyectos y/o actividades. La sustentabilidad de los modelos de calidad se basan en la institucionalización de mejores prácticas, y esto se logra con la repetición continua de los procesos diseñados. El sponsor debe tener visibilidad de los proyectos y actividades de la unidad organizacional sujeta a mejora, para prever el impacto de la liberación de nuevos procesos en la operación actual. En organizaciones pequeñas donde el flujo de proyectos es inestable, esta actividad es clave para garantizar la continuidad del proyecto de mejora. 4. Infraestructura. El entorno debe ayudar a motivar y facilitar el cambio. El sponsor debe asegurar la infraestructura adecuada: espacio, estructura organizacional, herramientas. Kick-Off del proyecto de mejora. El Kick-Off no debe ser una reunión más como tantas otras, es una oportunidad irrepetible para hacer notar a todos los involucrados la importancia que este proyecto tiene para la organización. El sponsor debe asegurarse que cada colaborador entienda con precisión cuál será su rol y qué se espera de él. Comunicación. Todos en la organización deben conocer cuál es su rol: usted es el responsable por el éxito o fracaso del proyecto porque usted es el líder de la mejora. Si esto no está claro, hay mucha presión y frustración en su gente porque consideran que tienen que tomar

Monitorear plan y avance del proyecto de mejora. La disciplina es clave en esta actividad. Postergarla, eludirla o cancelarla equivale a firmar el certificado de defunción del proyecto. La mayoría de las actividades propias del proyecto de mejora, deben ser ejecutadas por personas que ya tienen otras asignaciones previamente, razón por la cual es muy frecuente el conflicto de prioridades. La reunión de monitoreo es de gran importancia, cada persona debe confrontarse periódicamente a sí mismo con sus propios resultados. Este es un motivador natural muy efectivo, ya que pocas cosas dan mayor satisfacción que el reconocimiento por un objetivo cumplido. Reconocimientos. La madurez es cuestión de tiempo, implica trabajar arduamente por meses, años a veces. Es un error identificar como único logro una certificación. Cada mejor práctica implementada e institucionalizada implica beneficios para la organización y ese es un logro en sí mismo. Además, definir e implementar un proceso organizacional, por pequeño que sea, implica una mejora en la eficiencia operativa que evidentemente también trae beneficios. Esto también es un logro en sí mismo y es en base a estos pequeños logros como finalmente se logra la implementación de una norma o modelo de calidad. Es vital que el sponsor entienda esta dinámica y utilice estos momentos en favor del proyecto de mejora, reconociendo estos logros que finalmente son los peldaños de la escalera que lleva a la consecución de los objetivos de negocio de la organización.

Conclusión

Nunca me he topado con una empresa que me dijera: “Me sobra dinero, no tenemos nada mejor que hacer, entonces vamos implementando un modelo de calidad”. Estas iniciativas surgen como respuesta a problemas organizacionales que afectan el ambiente de trabajo, la relación con los clientes, y/o la rentabilidad del negocio. Y el rol del sponsor es indispensable para el éxito de estos proyectos. Por sobre todas las cosas, se educa con el ejemplo. El sponsor debe ser el modelo a seguir por la gente de su organización, para que el cambio que se quiere implementar sea real, efectivo y beneficioso para la organización y toda la gente involucrada. En www.qualtop.com/activossponor, se pueden descargar checklists, templates, formatos y manuales, entre otros activos valiosos que le ayudarán a ejecutar de manera sobresaliente el rol del sponsor. .BIO

Leonardo N’Haux ha participado activamente en la industria de software de México desde el año 2002, enfocado principalmente a la mejora de procesos en empresas del sector. Actualmente, como Director General de Qualtop SA de CV, lidera un equipo de consultores que, en conjunto, han participado en más de 120 proyectos implementando mejores prácticas basadas en CMMI y Moprosoft. lnhaux@qualtop.com @lnhaux Cecilia Scauso es Ingeniera en Sistemas de Información y Lead Appraiser Certificada para Desarrollo y Servicios. Desde el año 2002 se ha enfocado a apoyar a organizaciones en actividades de mejora de procesos con diversos modelos. Actualmente se desempeña como Directora de Investigación y Desarrollo en Qualtop y Lead Appraiser en Liveware. Ha realizado más de 25 evaluaciones SCAMPI. Fue la primer Lead Appraiser en acreditar a una empresa en Mexico con el modelo CMMI for Services. cscauso@qualtop.com

Software Guru

1. Compromiso de la alta dirección. En niveles medios y operativos, la falta de compromiso de la alta dirección con el proyecto se lee como desinterés: “si al dueño no le interesa, ¿por qué ha de importarme a mí?”. El sponsor debe tener claro cómo impactan los resultados de esta iniciativa en los indicadores claves del negocio.

decisiones por usted y no pueden hacerlo. Estas mejoras organizacionales producen cambios culturales y no se pueden hacer desde abajo.

www.sg.com.mx |

Planear el proyecto de mejora. Las cosas no suceden porque “sí”, y esta no es una excepción. La viabilidad del proyecto se sustenta en 4 pilares fundamentales:

.PRINCIPAL

Definición vs. Implementación

¿a cuál darle mayor importancia?

››Por Rodrigo Torres Garibay

Al comenzar

un proyecto de mejora de procesos la primera pregunta que viene a la mente del líder del proyecto de mejora es: ¿por dónde comenzar? Cuando logras como líder identificar por donde atacar vienen las preguntas clave del proyecto: ¿en cuántas fases debo de dividirlo?, ¿cuál es la de mayor importancia?, ¿cuánto tiempo debo de dedicarle? Es sobre estos aspectos en los que nos estaremos enfocando en los siguientes párrafos. Es indispensable que al comenzar el proyecto de mejora de procesos se haga un diagnóstico inicial en el cual se identifiquen las debilidades y fortalezas de las diferentes áreas de la organización para que con base a estos elementos se pueda generar un plan de acción o plan de proyecto de mejora. En otras palabras, si estás pensando en orientar las velas de tu barco para un mejor rumbo, primero revisa que no se esté metiendo el agua o que tus remos no estén rotos. En el capítulo 3 del Competisoft nos hablan de “estrategias de implementación del modelo de procesos” en el cual proponen comenzar a implementar la mejora desde un perfil de proyectos, al revisarlo le cuestioné a una de las autoras de este capítulo sobre comenzar por proyectos y no por dirección a lo cual me contesto: “Uno debe de comenzar a implementar la mejora por las áreas donde se tenga mayor seguridad o conocimiento; sobre todo para luchar contra la resistencia al cambio”. Si entendemos que un modelo como Competisoft está orientado a pequeñas empresas de desarrollo de software, sería por el área de desarrollo de software y proyectos donde se debería de tener mayor conocimiento, a diferencia de un área de RH o de coordinación de proyectos. Una vez generado este diagnóstico se deberá de generar el plan de acción o plan de proyecto para el proyecto de mejora de procesos y es ahí donde aparece la pregunta que nos trajo a escribir este artículo “Definición VS Implementación, ¿A cuál darle mayor importancia?”. Hagamos una breve explicación de lo que se realizaría en cada una de las fases. En la fase de definición, como su nombre lo indica, se definirán los productos de trabajo, procesos y actividades que se llevarán dentro del área a mejorar. En otras palabras, es la fase teórica del proyecto donde se coloca los bocetos y en papel lo que se vaya a implementar. Posteriormente, en la fase de implementación se toma lo que se generó en la fase de definición y se lleva a la práctica dentro del área a mejorar, es comprobar la teoría con la práctica. Asímismo, la implementación nos brinda retroalimentación sobre los ajustes que se tienen que generar para volver a definir.

Ventajas y riesgos

Cuándo se le da mayor importancia a la fase de Definición, entre las ventajas que se podrá tener es que se lleva una adecuada generación de los procesos, actividades y productos de trabajo para implementar 28

en el área a mejorar. Por otro lado, hacer demasiado énfasis en la definición tiene el riesgo de que esa definición puede ser muy distante a lo que sucede en la realidad en la área a mejorar. A su vez, cuándo se le da mayor importancia a la fase de Implementación, entre las ventajas que se podrá tener es que se va probando y piloteando lo que se definió anteriormente, dando tiempo en el proyecto de mejora a que se hagan los ajustes necesarios para que la definición se apegue a la realidad. El principal riesgo consiste en que no se tenga una adecuada definición y se genere descontrol en la fase de Implementación por la falta de lineamientos que se deberían de generar en la fase de Definición. Por lo tanto, la fase de definición e implementación no se podrán eliminar del proyecto de mejora o del plan de trabajo que se tiene ya que las dos fases van ligadas y se requieren una a la otra. Por lo que regresamos a la pregunta del principio ¿A cuál darle mayor importancia? Existe un factor clave que debemos de considerar siempre que hablemos de procesos, y es algo que a los profesionistas de TIC se nos olvida y son las personas. Como dice el refrán “El martillo le ve cara de clavo a cualquier problema”. Los que somos de TIC muchas veces pensamos que todo es definir, montarlo en un sistema, automatizarlo y listo, ya tenemos procesos en la organización … ¿Y las personas? Todos los procesos que se implementen en la organización tienen que llevar un programa o actividades alternas que estén enfocadas a permear los procesos dentro de la organización y a través de las personas, ya que al final del proyecto los que van a utilizar lo que se definió serán las personas. Un factor de éxito para todo proyecto de mejora siempre será luchar contra la resistencia al cambio, lograr que los procesos nuevos o las actividades nuevas que hayan surgido del proyecto de mejora se integren a la vida diaria de cada uno de los colaboradores de la organización. Una estrategia para poder atacar este objetivo será integrar a los diferentes sectores de la organización a definir e implementar ellos mismos sus procesos y actividades, con esto se logrará que los colaboradores de la organización se “adueñen” de la mejora y la defiendan contra la presión del día a día que siempre intenta echar abajo los procesos. Es en la fase de Implementación en la que se enfrenta la teoría contra la presión del día a día, es en esta fase en la que los colaboradores que participaron en la definición revisan que lo que hicieron está acorde a lo que hacen. Es en esta fase donde se pilotea y se prueban las mejoras, generando ajustes tal vez para la definición. ¿Entonces tendríamos que regresar a la definición?

Iterar para mejorar

Un ciclo de vida de un proyecto de mejora no tiene que ser estrictamente en forma de “cascada”, más bien lo recomendable es que se busquen pequeñas iteraciones que vayan resolviendo problemas y se comiencen a integrar procesos al área de mejora. Con esto se podrá tener

.PRINCIPAL

“Un factor de éxito para todo proyecto de mejora siempre será luchar contra la resistencia al cambio”. Por lo tanto ¿A cuál darle mayor importancia? La clave no es darle mayor importancia a una o a otra sino más bien identificar cuantas veces se encuentra el proyecto en alguna de las fases e intentar estar más veces en un tiempo más corto. En otras palabras aumentar la frecuencia y bajar la duración de cada fase.

www.sg.com.mx |

Software Guru

tiempo para la definición, tiempo para la implementación, tiempo para aprender y tiempo para volver a planear. En la siguiente iteración se podría ajustar en la fase de definición lo que se generó como “ajustes” en la fase de la implementación anterior; y así sucesivamente generando e integrando a los colaboradores de la organización dentro del proyecto de mejora.

.BIO Rodrigo Torres Garibay es Lic. en Informática por la UNAM, con estudios de especialización en Calidad e Ingenieria de Software por la Universidad de Santiago de Chile. Ha participado en más de 50 implementaciones de la norma MoProSoft y realizado evaluaciones con EvalProSoft a lo largo de la República Mexicana. Actualmente colabora como Consultor de Calidad en la firma Innevo.

.PRINCIPAL

El Rol del SQA haciendo aliados en los diferentes niveles ››Por Elizabeth Almeraz

El rol

de SQA (Software Quality Assurance/Advisor) no es sencillo, sobre todo desde el punto de vista organizacional. En ocasiones el SQA es sub-valorado por las organizaciones, ya que se observa como un personaje externo al proyecto, no confiable y que no aporta valor a la organización, incluso para aquellas donde se han establecido prácticas de calidad y mejora de procesos. Esta visión resta importancia y respeto al papel que este rol desempeña, por lo cual es importante reivindicarlo para que pueda mostrar sus bondades al resto de la organización y la revisión de aseguramiento de calidad se convierta en algo que nos brinda un valor agregado más que una pesadilla que no nos deje conciliar el sueño en la noche.

Cambiando el paradigma

Para lograr una reivindicación adecuada del SQA, es necesario contestar las siguientes preguntas: ¿Quién es un SQA?, ¿cuáles son las actividades que realiza?, y ¿para qué las realiza? Contestando a las preguntas iniciaremos diciendo que un SQA es el rol en una organización que se encarga de revisar y auditar los productos y actividades para verificar que éstos cumplen con los procesos aplicables al proyecto y los estándares establecidos. De esta manera proporciona a la gerencia la visibilidad del estatus en que se encuentran los procesos y los productos de los diferentes proyectos. Sin embargo, las actividades del SQA no se limitan a realizar auditorías y revisiones. Una de las principales tareas de los individuos que son SQA’s es la de proporcionar guía y asesoría a los miembros de los equipos de trabajo sobre el uso y aplicación de los procesos descritos en la organización, al nivel de sus proyectos. Así pues, podemos decir que el SQA realiza principalmente las actividades de: auditar-revisar a los proyectos y asesorar sobre el uso o aplicabilidad de los procesos.

Haciendo aliados

Es fundamental que los diferentes grupos de la organización visualicen el valor que el grupo de SQA puede brindar, no sólo en el cumplimiento de los objetivos de calidad, sino en las labores cotidianas de cada uno de ellos. A continuación se muestran algunas sugerencias de lo que el grupo de SQA puede realizar para obtener el apoyo y la cooperación de los diferentes grupos en la Organización.

Ingenieros de Software • Asesorarlos en sus funciones con respecto a la calidad, por ejemplo: cómo poner bajo configuración sus documentos o programas, realizar respaldos, reportar sus avances en la herramienta de planeación, guiarlos en las revisiones entre colegas. • Ayudarles a visualizar metas cortas y a su nivel, tal como registrar los tiempos de corrección de defectos, registrar el tiempo real de ejecución de las tareas asignadas. • Mostrarles cómo los procesos les ayudan a hacer mejor su trabajo. Responsables de proyecto • Asesorarlos en aspectos relacionados con su proyecto, guiándolos en la manera en cómo aplicar algún proceso a su proyecto, asesorarlos en el llenado de formatos nuevos o bien en el registro de datos o información requerida, registro de estimaciones, lecciones aprendidas. • Recompensar sus esfuerzos, dándoles visibilidad. Esto es, comentar con los niveles superiores, cuando sea posible, cuáles son los puntos en los cuales se han destacado. De igual manera, proponer las buenas prácticas que utilicen en sus proyectos para que otros proyectos de la organización se beneficien de utilizarlas. • Señalar las desviaciones y aplaudir los logros. Registrar los logros en los reportes de revisión, de la misma manera en que se registras las desviaciones o hallazgos. • Entrenar para mejorar la calidad. Los responsables de proyecto, requieren que se les ayude a visualizar de manera sencilla, cuáles son los aspectos que deben cuidar en su trabajo diario para mejorar la calidad de sus proyectos. De esta manera, los estaremos enseñando a pescar y no estaremos pescando por ellos. • Escuchar y escalar sus sugerencias de mejora. Es muy importante este punto, pues con ello, los responsables de proyecto realmente se sentirán parte del proceso de mejora continua. Nadie mejor que ellos, quienes son los que llevan a la práctica los procesos, para sugerir mejoras a los mismos. El SQA debe escuchar atentamente sus sugerencias de mejora y escalarlas a los niveles superiores, así como al grupo responsable del programa de mejora (SEPG). • Mostrándoles cómo los procesos les ayudan a hacer mejor su trabajo. Hacerles ver de manera práctica los beneficios que se obtienen al seguir los procesos. Gerencia media • Mantenerlos informados sobre estado de los proyectos a su cargo. • Asesorarlos en las funciones que corresponden a su nivel y realizar las revisiones que les correspondan de acuerdo a los procesos definidos por la Organización. De igual manera se debe dar seguimiento directo con ellos, a las acciones preventivas/ correctivas, derivadas de una revisión de SQA y de las que sean responsables.

Figura 1. El SQA y su interacción con otros grupos

.PRINCIPAL • Proporcionarles visibilidad sobre los problemas comunes de aseguramiento de calidad en sus áreas y/o de otras áreas de la organización. De esta manera se pueden evitar problemas, buscar soluciones conjuntas o cooperar con otras áreas para buscar una solución común. • Sugerir mejoras a prácticas administrativas y de ingeniería de software en sus proyectos.

Como puede verse, identificando actividades sencillas y prácticas que ayuden a mejorar las relaciones del grupo de SQA con el resto de los roles de la organización, se ayuda a crear un ambiente de sinergia que mejore su credibilidad, reivindique su función y coadyuve a mejorar la productividad de los equipos y la calidad de su trabajo y los productos generados. Es mil veces mejor tener un aliado que mil enemigos.

www.sg.com.mx |

Software Guru

Alta gerencia • Vigilar el apego a procesos, procedimientos, estándares y políticas definidos en la organización. • Escalar problemas que deban ser atendidos a este nivel. No sobre-informar a la alta gerencia con problemas que pueden ser resueltos en otros niveles, pero es importante que este nivel esté informado de manera oportuna de los asuntos urgentes relacionados con la calidad que afecten los objetivos y metas del negocio. • Reportar resultados de las diferentes áreas. De esta manera, se les brinda un panorama general sobre el estado de la implantación / ejecución del programa de mejora. • Brindar visibilidad sobre la calidad de los productos. Este es un indicador clave que es requerido para la toma de decisiones estratégicas. • Mantener informado sobre la operación del negocio y el apego a los procesos. Con esto se pueden tomar decisiones para prevenir o contener posibles riesgos que pudieran surgir.

Grupo de mejora de procesos (SEPG) • Proveer visibilidad con respecto a la implantación de procesos al grupo de mejora. Con ello se obtendrá la retroalimentación necesaria que requiere el SEPG para continuar con el impulso del programa de mejora. • Proporcionando retroalimentación sobre prácticas de ingeniería de software y administración de los proyectos. Esta actividad constituye una entrada fundamental para la realización y mantenimiento del plan de mejora y el establecimiento de objetivos del programa de mejora. • Proponer la adopción de mejores prácticas. Con ello se va fortaleciendo el capital intelectual de la Organización. • Evaluando la implantación de procesos. Así como el SEPG es fundamental en la definición de los mismos, el grupo de SQA es clave para evaluar la implantación y aceptación de éstos. • Revisando las actividades del SEPG. Se garantiza la objetividad de las actividades del programa de mejora. • El SQA puede sugerir mejoras a los procesos definidos, con base en su experiencia a través de las revisiones a los proyectos.

.BIO Elizabeth Almeraz es Lic en Ciencias de la Informática del IPN, cuenta con un MBA enfocado en TI de la EDHEC-THESEUS en Francia, así como una especialización en Medición y Análisis del SEI y un diplomado en 6-Sigma a nivel Green Belt. Es pionera en temas de aseguramiento de calidad y cuenta con más de 12 años de experiencia brindando consultoría en el área de calidad y mejora de procesos en México. Actualmente se desempeña como Consultor de Alta Madurez y Gerente de Consultoría en Avantare. www.avantare.com

.PRINCIPAL

¿Colonización o Mestizaje? mejora de procesos en fusiones y adquisiciones ››Por Susette Seoane

Una

de las características de este mundo globalizado es que las empresas continuamente se ven involucradas en operaciones como fusiones, adquisiciones o alianzas. El objetivo de este tipo de operaciones típicamente es fortalecer una línea de negocio, incursionar en donde no necesariamente son líderes, lanzar o posicionar un nuevo producto o servicio que de manera tradicional podría tomar un tiempo considerable, o bien no se cuenta con la capacidad de hacerlo de manera interna. Dichas operaciones generan un crecimiento denominado “inorgánico”, a diferencia del crecimiento “orgánico” que se da de manera interna. Para que este tipo de crecimiento sea saludable, es necesario administrarlo de forma adecuada y contar con una buena estrategia. Al fusionar, adquirir, aliar, se suman activos explícitos tales como infraestructura, cartera de clientes, cartera de productos/servicios, ingresos (venta), así como una serie de elementos de soporte tales como procesos, capital intelectual y un ingrediente secreto que llamaremos “cultura organizacional”. La cultura organizacional representa las diferentes maneras de hacer las cosas, estilos de liderazgo, políticas, procesos entre otros. Pensemos en cómo los clientes son afectados por una de estas operaciones de fusión o adquisición. Imagina que eres cliente de un banco, tú seleccionaste ese banco porque cubría tus necesidades personales, te quedaba cercano a tu domicilio u oficina, tenía un cajero disponible y además el gerente era tu amigo. De pronto, un buen día sin que nadie te preguntara, tu banco es parte de otro banco al que tú habías rechazado anteriormente por su pésimo servicio y por supuesto ya no cubre con tus criterios de selección inicial. Pongámonos también en los zapatos de los colaboradores o empleados, cuando de un día para otro la empresa en la que felizmente trabajabas es adquirida o fusionada y de pronto cambias de actividades, compañeros, superiores, ubicación, métricas de desempeño. Este tipo de situaciones cada vez se dan más en organizaciones de software y tienen un impacto profundo en ese ingrediente secreto que comentabamos, la cultura organizacional. En este contexto hay que responder de forma muy ágil a la nueva situación de negocio. Se demanda seguir operando, no poner en riesgo la operación, la satisfacción de los clientes, colaboradores y mantener los estándares de calidad en su nivel óptimo. Y si existen sus certificaciones o evaluaciones, estas deberán continuar sin sorpresas ni hallazgos significativos. Pero no nos enfrentamos a un problema exclusivo de tecnología, herramientas o procesos, pues somos las personas quienes operamos

y vivimos, somos la cultura organizacional. Un proceso de cambio mal administrado genera resistencia, sentimiento de pérdida, lucha de poder y en ocasiones hasta guerra. Para atender este tipo de retos, tengamos en cuenta dos estrategias que se han llevado a cabo a través de la historia de nuestra civilización: la colonización y el mestizaje. La colonización, trasladada a este contexto, consiste en la imposición de una nueva forma de trabajo. Tiende a ser directa y rápida, aunque no necesariamente el mejor camino ya que no toma en cuenta la cultura organizacional de la colonia. Es decir, no aprendemos ni asumimos las buenas prácticas de origen. Por su parte, el mestizaje consiste en la formación de una nueva cultura organizacional que asimile elementos de las organizaciones anteriores. En un mercado demandante donde perder el control significa perder liderazgo, participación y mercado, el adoptar una estrategia de mestizaje puede ser visto como riesgoso. Sin embargo, debemos reconocer que cada organización tiene una cultura, sus raíces y seguramente buenas prácticas. Un mestizaje puede tomar mayor tiempo de implementar, pero el resultado generalmente es más duradero y con mejores resultados. El reto está en asumir las buenas prácticas, analizar lo valioso e integrar las dos culturas u organizaciones. A pesar de mi preferencia por el mestizaje, reconozco que no siempre es posible o práctico. Así que a continuación comparto algunas recomendaciones para lidiar con fusiones o adquisiciones ya sea como colaboradores, directores o empresarios: 1) Cada cultura organizacional cuenta con sus valores y creencias, identifícalos y respétalos. 2) Es posible y recomendable rescatar las buenas prácticas. Se requiere de análisis, conocimiento y confianza. 3) Incorpora un proceso de administración del cambio cuidando la comunicación, el ambiente, las resistencias. 4) No existen procedimientos perfectos, son evolutivos. Pero es mucho mejor tener procedimientos con funcionalidad básica que operar sin los mismos. Como individuo recuerda que los organismos que se adaptan sobreviven, asume nuevas formas y prácticas, súmate a la transformación, no te resistas, evoluciona, puedes elegir ser parte o no, pero tú lo decides. .BIO

Susette Seoane se desempeña como socio director en Invest in Quality (“IQ”), consultando y apoyando a las organizaciones en sus procesos de mejora continua, administración del cambio, procesos de negocio, viviendo la ejecución y entrega de sus clientes. Cuenta con más de 20 años de experiencia en el sector de TI y ha participado en varios procesos de evaluación y acreditación formal bajo marcos de referencia como CMMI, ISO, ITIL, COBIT entre otros. www.iqever.com

.COLUMNA Código Innovare

BPM Semántico la evolución de la gestión de procesos

›› Por Ebenezer Hasdai Sánchez y Hugo Estrada Esquivel

a adopción de metodologías de gestión de procesos de negocio ha aumentado considerablemente en las empresas en los últimos años. En este contexto es indiscutible la necesidad de usar herramientas tecnológicas para hacer factible la gestión de los procesos. Como consecuencia, existe una gran variedad de herramientas que apoyan en las distintas fases del ciclo de vida de los procesos de negocio. Sin embargo, muchas de estas herramientas no toman en cuenta el conocimiento organizacional como directriz en el desarrollo de los procesos. En este artículo se presenta un nuevo enfoque, basado en tecnología semántica, para las herramientas de gestión de procesos de negocio. La aplicación de tecnologías semánticas provee ventajas importantes para los dueños del negocio, ya que no sólo permiten gestionar los procesos sino también el conocimiento generado y transformado por los mismos.

mación de valor para poder adecuar los procesos a las necesidades cambiantes del entorno, de sus clientes y del mercado. Actualmente existen una gran variedad de herramientas de distintos fabricantes, éstas son algunas de sus características comunes: • Independencia de alguna metodología específica de gestión de procesos, lo cual permite su adecuación de acuerdo a las necesidades de cada organización. • Acotamiento a alguna de las etapas del ciclo de vida del proceso, es decir, se tiene una herramienta específica para modelado, otra para ejecución y otra para monitoreo. Esto puede ser una desventaja ya que obliga a aprender distintas herramientas para cubrir el ciclo de vida completo. • Típicamente no se incluye mecanismos para la captura, administración y explotación del conocimiento asociado a los procesos de la organización, por lo que dicho conocimiento se encuentra disperso en cada una de las personas y técnicas utilizadas en las distintas fases del ciclo de vida.

Introducción a BPM

La gestión de procesos de negocio o BPM (Business Process Management) es una disciplina que considera tanto el uso de las metodologías de mejora de procesos como el uso de herramientas que soportan las fases definidas en las metodologías [1], tomando en cuenta aspectos sociales y tecnológicos. BPM tiene como objetivo, por un lado, el ayudar a automatizar, administrar y optimizar procesos; por otro lado, intenta facilitar la interacción entre los humanos y las herramientas requeridas para operar los procesos de negocio. De manera general, el ciclo de vida de desarrollo de los procesos de negocio en BPM considera las fases de diseño, modelado, ejecución, monitoreo y optimización mostradas en la figura 1. Este ciclo permite llevar un proceso desde su descubrimiento y documentación hasta la propuesta e implantación de mejoras en la ejecución del mismo. Una buena parte del ciclo de vida se puede automatizar mediante herramientas de gestión de procesos, que implementan diversos estándares –como XPDL [2] y BPMN [3]– para el modelado y ejecución de procesos de negocio. Dichos estándares permiten: a) el intercambio de información mediante formatos que facilitan la interoperabilidad entre sistemas, y b) el entendimiento del negocio mediante la aplicación de notaciones que proporcionan un lenguaje común para todos los involucrados en los distintos niveles del proceso: administradores, analistas, operadores e incluso clientes. Ver Figura 1.

BPM basado en tecnologías semánticas

Con la materialización de la Web Semántica (basada en el significado explícito de la información contenida en las páginas de Internet), surge un conjunto de tecnologías enfocadas al descubrimiento, representación y gestión de conocimiento. En el contexto de los procesos de negocio, estas tecnologías permiten integrar, además de la gestión de los procesos de negocio, un mecanismo para hacer explícito y concentrar el conocimiento a nivel organizacional. De este modo, las organizaciones pueden transformar su enfoque de desarrollo de procesos hacia un enfoque orientado al conocimiento organizacional que les permita una mejor toma de decisiones y una mayor flexibilidad para atender las necesidades de los clientes. Este enfoque tiene como objetivo incorporar el conocimiento organizacional en las fases de diseño, modelado y ejecución de procesos con el desarrollo de técnicas más expresivas y formales para representar la semántica contenida en los mismos. Esto implica el cambio a una nueva manera de hacer el descubrimiento y documentación de los procesos existentes para lograr capturar el conocimiento implícito. En este sentido, es el conocimiento quien define el intercambio de información entre las actividades del proceso, en lugar de ser el flujo del proceso quien determina la ruta de la información. La figura 2 presenta un esquema de este enfoque. Ver Figura 2. El enfoque semántico de las herramientas de gestión de procesos incorpora una etapa más en la fase de diseño, ésta consiste en el modelado del conocimiento organizacional usando ontologías (conceptualización explícita de un área de conocimiento en términos de entidades y sus relaciones) para capturar los conceptos relevantes asociados a la información manejada en la operación de los procesos. Las ontologías constituyen un

Herramientas BPM tradicionales

Las herramientas para la gestión de procesos de negocio proporcionan mecanismos para que los involucrados en el desarrollo de los procesos puedan identificar y documentar sus procesos clave, ejecutarlos y medir su efectividad. Estos mecanismos proveen infor34

Figura 2. Desarrollo de procesos semántico.

repositorio de conocimiento institucional accesible por todos los miembros de la organización y facilitan la interoperabilidad de los humanos y los sistemas involucrados en el ciclo de vida de los procesos. Los conceptos en la ontología introducen nuevas restricciones y dependencias de información que deberán ser consideradas para construir el flujo de los procesos (basado en actividades, compuertas y eventos), permitiendo detectar desde un inicio rutas críticas y productos esenciales para los procesos. En el modelado de los procesos se relaciona el conocimiento previamente descubierto con las actividades definidas, indicando las transformaciones necesarias en cada actividad para generar los productos (información) del proceso, almacenarlos y facilitar su exposición y explotación en la base de conocimiento. Estas relaciones son interpretadas por el motor de ejecución, quien utiliza el flujo y la base de conocimiento de los procesos para hacerlos operables. Algunas de las ventajas del uso de herramientas basadas en la tecnología semántica son: • Facilitan el modelado dinámico de objetos de negocio a través de modelos ontológicos, lo cual permite que un cambio en la estructura de la información se vea reflejado de manera inmediata en la ejecución actual del proceso. • Permiten integrar en una sola herramienta el desarrollo de todas las fases del ciclo de vida, incrementando con esto la facilidad de explicitar el conocimiento generado en cada una de las fases y reducir la curva de aprendizaje necesaria para llegar a la operación de los procesos. • Permiten contextualizar los procesos de negocio para descubrir nueva información a través de inferencias realizadas sobre su base de conocimiento. • Facilitan la integración con componentes SOA por la manera en que representan la información. • Integración natural con la Web Semántica, que permite una recuperación más eficiente de la información contenida en la base de conocimiento y la incorporación de dominios tecnológicos como el procesamiento de lenguaje natural, computación en la nube y bases de datos semánticas.

to asociados a la misma han permitido cambiar el enfoque de modelado de procesos hacia metodologías que toman como punto de partida la información relevante de las organizaciones para determinar el flujo de los procesos. Este enfoque ha disparado la creación de herramientas que combinan el modelado de procesos de negocio y el modelado de conocimiento organizacional mediante el uso de mecanismos de representación estándares como ontologías y notaciones de modelado de procesos. Algunas de las ventajas de estas herramientas son el modelado dinámico de la información, el manejo integral del ciclo de vida de los procesos, el descubrimiento de nuevo conocimiento y la integración de los sistemas de ejecución de los procesos con la Web semántica. Aunque las tecnologías semánticas se han aplicado hasta ahora en ciertas fases del ciclo de vida de los procesos, se están realizando trabajos para incorporar dichas tecnologías en el resto de las etapas. El objetivo de estos trabajos es lograr definir metodologías y herramientas tecnológicas que permitan obtener de manera semi-automática el flujo de los procesos de negocio partiendo del conocimiento modelado en las primeras etapas.

Conclusiones

La gestión de procesos de negocio sigue evolucionando. El surgimiento de la web semántica y los mecanismos de representación de conocimien-

Referencias [1] W.M.P. van der Aalst et.al. Business Process Management: A Survey . Proceedings of the 1st International Conference on Business Process Management, 2003. http://swgu. ru/sg33r6 [2] XML Process Definition Language. http://www.xpdl.org [3] Business Process Management Initiative. http://www.bpmn.org

.BIO Ebener Hasdai Sánchez Pacheco colabora en la Gerencia de Desarrollo de Nuevos Productos en el Infotec (www.infotec.org). Cuenta con una Maestría en Ciencias de la Computación con especialidad en Inteligencia Artificial por parte del Centro Nacional de Investigación y Desarrollo Tecnológico (CENIDET). ebenezer.sanchez@infotec.com.mx El Dr. Hugo Estrada Esquivel colabora en el Departamento de Ciencias Computacionales del CENIDET. Cuenta con un Doctorado en Informática por parte de la Universidad Politécnica de Valencia. Sus áreas de especialidad son el modelado de negocios, ingeniería de requisitos y reingeniería de procesos de negocios. hestrada@cenidet.edu.mx

www.sg.com.mx |

Figura 1. Ciclo de vida BPM.

Software Guru

.COLUMNA Código Innovare

.PRÁCTICAS Usabilidad

Arquitectura de información

l primer problema detrás del diseño de una interfaz es que la mayoría de las personas no comprende del todo en qué consiste la arquitectura de información, siendo que se trata del pilar más importante que soporta el éxito de dicha interfaz. Y es que, visto de forma lógica y directa, ¿cómo va el usuario a aprovechar los contenidos y funcionalidades que se le ofrecen si no puede llegar a ellos? La arquitectura de información define, a grandes rasgos, qué contenido se presentará en un sitio o aplicación y de qué maneras podrá llegar hasta él un usuario. Por consiguiente, un diagrama de la arquitectura de información es una especie de mapa hacia todos los posibles destinos. Tener en claro todos los caminos que existirán para llegar a cada fragmento de contenido agilizará y asegurará la efectividad de procedimientos posteriores como el diseño de la navegación y la organización de la información dentro de cada página o pantalla.

Distintos Tipos de Arquitecturas

Para comenzar a construir la arquitectura de información es necesario conocer los tipos de arquitectura con los que se puede llevar a cabo la organización del contenido. De manera muy general, se pueden establecer dos tipos de arquitectura de información: Tener una arquitectura de información ancha significa que se cuenta con un esquema de arquitectura que no conlleva muchos clicks por parte del usuario para llegar hasta el nivel de mayor detalle, pero que se tienen muchas opciones en cada nivel. Por otro lado, una arquitectura de información profunda es aquella que cuenta con menos opciones por nivel, pero que requiere de mayor número de clicks para llegar al nivel de menor jerarquía. La figura 1 muestra visualmente ambos tipos de arquitectura, profunda y ancha.

Definiendo la Arquitectura de Información: Card Sorting

La técnica de card sorting conlleva una explicación sencilla. Se trata

técnicas efectivas

›› Por Pamela Rodríguez

de un método de definición de arquitectura de información en el cual se establecen las clasificaciones de contenido y posteriormente se ordenan hasta encontrar la organización óptima para las mismas. El material requerido para este proceso es un simple paquete de post-its. También puede ser llevado a cabo por medio de tarjetas. En cada post-it o tarjeta se escribe el nombre de una sección o página del contenido de la aplicación o sitio web, y posteriormente se realiza el card sorting ya sea en su modalidad básica o invertida. Los explico a continuación. El card sorting básico es el proceso que se sigue al presentar un conjunto de tarjetas con los nombres que identifican el contenido, solicitando a los participantes (que pueden ser los miembros del equipo de diseño o un grupo de usuarios seleccionados) que los organicen de la manera más intuitiva posible. El card sorting invertido se realiza cuando a los participantes en el proceso (igualmente pueden ser miembros del equipo o usuarios selectos) se les presentan las tarjetas con los nombres que identifican el contenido, pero en este caso éstas se encuentran ya organizadas de una manera predefinida por el moderador del procedimiento. Los participantes deberán modificar esa organización de acuerdo a los factores que consideren que ayudarán a mejorarla. Al finalizar alguno de los dos procesos anteriormente mencionados, el resultado será la base que definirá la arquitectura de información del proyecto en desarrollo. Sin embargo, aún queda trabajo por hacer para completar el procedimiento.

Construyendo el Diagrama de Arquitectura

Una vez completados los procedimientos para definir la arquitectura de información, es necesario plasmarla de manera clara para que sirva como una referencia dentro del resto del proceso de desarrollo del proyecto. Esto significa el establecimiento de

Figura 1. Arquitectura profunda o ancha.

Figura 2. Diagramado de jerarquías.

Iniciar Sesión

Inicio

Análisis Estadísticos

Error Detalle Gráfica General Registro

Tabla de resultados

Figura 3. Tomando elementos de diagramas de flujo.

jerarquías sólidas, caminos que entrelazan al contenido, e incluso grados de detalle como la restricción de contenido a usuarios con un registro previo. Para lograr esto, existen diversos métodos de diagramado de arquitectura de información que pueden ser utilizados. Uno de estos métodos es el diagramado de jerarquías estrictas, que consiste simplemente en plasmar la información de la arquitectura en un mapa jerárquico de crecimiento vertical (en el caso de arquitecturas profundas) u horizontal (en el caso de jerarquías anchas), tal como se muestra en la figura 2 Se le puede agregar más detalle al diagrama especificando la acción que vincula cada elemento dentro de la jerarquía (como un click o una acción de tipo “drag and drop”). Es posible, además, agrupar los elementos en grupos de requisición de registro de usuarios y de contenido de disposición libre. Por otro lado, existen métodos de diagramado más detallado y no limitados a jerarquías estrictas (aquellas con un solo camino entre elementos de contenido). Se trata del vocabulario visual propuesto por Jesse James Garrett (que puede ser consultado en su totalidad en http:// www.jjg.net/ia/visvocab/). Consiste en utilizar una gama iconográfica para representar los diversos tipos de contenido existentes, los cuales son una página, un archivo, o un conjunto de alguno de ambos. Estos contenidos, a su vez, pueden estar interconectados entre si y estas conexiones pueden representar más de un camino para llegar a un mismo destino. Pueden, además, representarse condiciones y decisiones como en un diagrama de flujo. Existen, a su vez, maneras de representar agrupaciones entre distintos contenidos o funcionalidades, así como nomenclatura para representar repeticiones de los mismos. La figura 3 muestra un fragmento de un diagrama realizado por medio de este método. La iconografía para este tipo de diagramas está disponible para diversos paquetes de software de diagramado, y se pueden conocer algunos en la liga proporcionada anteriormente. Al final, lo importante es elegir la combinación de métodos que se acoplen mejor al tipo de proyecto con el que se esté trabajando para conseguir el mejor resultado posible. Por ejemplo, un sitio web informativo comúnmente tiene una navegación poco compleja, por lo que una estricta jerarquía funcionará perfectamente. Sin embargo, si se trata de una red social, una jerarquía estricta no permitiría reflejar en su totalidad la capacidad en funcionalidad y disponibilidad de contenido del proyecto. .BIO Pamela Rodríguez es egresada de la Universidad de Monterrey de la carrera de Ingeniería en Sistemas Computacionales con estudios avanzados en diseño web. Actualmente es Diseñadora de Interfaces para Aplicaciones Móviles en Naranya AppHouse, docente, conferencista y autora de artículos relacionados. @thepam http://thepam.blogspot.com

.PRÁCTICAS Project Management

Estimación de Proyectos de Software parte

2: modelo epei

n la edición anterior describimos y mostramos un ejemplo en el cual una mala estimación puede ocasionar desde problemas de negociación hasta problemas económicos por tener que absorber costos no planeados. Esta situación es bastante común en la industria. De hecho, de 49 organizaciones que yo he entrevistado, tanto consultoras de software como corporativos e instituciones públicas, solamente 3 (6%) me han manifestado la ausencia de problemas en el tema relativo a las estimaciones. A pesar de que ya conocemos el problema que implica la falta de información en etapas tempranas de los proyectos (la mayoría de las variables son subjetivas, no hay mucho que contar) y que sabemos que el método más utilizado porque mejor se acopla a esa realidad es el “juicio de experto”, el problema sigue existiendo, ¿por qué? Esta pregunta no es sencilla pero en parte se debe a que la ingeniería de software es relativamente joven comparada con otras ingenierías. También tiene que ver con que la gente cree que el software es más intelectual que físico y por esto no se puede medir. Difiero con esto porque si no tenemos qué medir, entonces no podemos hacer ingeniería, lo que hacemos es arte. Y el problema con hacer arte es que los resultados dependen por completo de tener buenos artistas y no es algo sustentable. La IEEE define ingeniería de software como; “La aplicación de una estrategia sistemática, disciplinada y cuantificable, al desarrollo, operación y mantenimiento de software; es decir, la aplicación de ingeniería al software”. [1] Entonces, para hacer ingeniería necesitamos medir. Si la mayoría de las variables que tenemos son cualitativas entonces necesitamos un mecanismo para medir este tipo de variables. Esta situación ha sido detectada y estudiada por varias personas, algunas de las cuales han encontrado en la Lógica Difusa un apoyo para trabajar mejor con estas variables [2,3], ya que estos modelos son diseñados típicamente sobre la base de reconocidos expertos que identifican e intuitivamente cuantifican las entradas con valores lingüísticos para inferir la variable dependiente. Se han realizado a nivel científico varios estudios que demuestran que en comparaciones contra los métodos tradicionales utilizados para generar modelos de estimación como regresión lineal, redes neuronales, etc., los basados en lógica difusa han presentado ventajas en las capacidades de modelado [4]. Existe un modelo que cubre estos requisitos además de un estu-

›› Por Francisco Valdés Souto

dio formal muy extenso, es mexicano y se denomina Estimación de Proyectos en Entornos de Incertidumbre (EPEI), el problema del proyecto descrito en el número anterior se evaluó con este modelo y se presentan a continuación el proceso y los resultados. Configuración del Modelo. Se reunió a los participantes en la estimación original del proyecto, los roles que participaron fueron: Gerente de Procesos y Calidad, Gerente de Administración de Proyectos, Consultor en Procesos, Director de Administración de Proyectos, Director de Tecnología y Calidad. La configuración y generación de siete escenarios distintos llevó aproximadamente 2 horas. Variables de Entrada. A estas personas se les pidió que identificaran las variables que afectaron mayormente al resultado del proyecto. Las variables identificadas fueron: Experiencia en tecnologías, conocimiento del negocio, disponibilidad de recursos, nivel de liderazgo. Variable de Salida. Para la variable de salida ellos definieron que sus proyectos iban del rango de 2 meses hasta 36 meses, ya que les interesaba estimar duración. Para la parte de estimación de esfuerzo ellos utilizaban la tabla mostrada en la figura 1. Sin embargo, esta tabla de esfuerzos no representa la realidad ya que una sola hora puede ser la diferencia entre un proyecto pequeño y uno mediano, o uno mediano y uno grande. El modelo EPEI utilizó algo que representa mejor la variable de salida que es una función como la que se muestra en la figura 2 con rango de 2 a 36 meses para duración y con rango de 500 a 19000 horas para esfuerzo. Este enfoque del modelo es muy relevante ya que trabaja en función de precisión de significado, esto es que se entiende que un proyecto conforme deja de ser Pequeño, empieza a ser Promedio, y conforme deja de ser Promedio empieza a ser Grande, de hecho en algún momento puede pertenecer a dos valores al mismo tiempo, es decir, un proyecto pareciera ser entre Promedio y Grande. Este enfoque de manejo de variables sin duda refleja de mejor manera la realidad que el manejo de rangos. Reglas de Inferencia. Al grupo de expertos se les pidió que definieran la relación de las distintas variables de entrada que definieron en función de la variable de salida del proyecto en base 38

.PRÁCTICAS

Project Management

Nombre Variable

(Gerente de Procesos y Calidad)

(Gerente de (Consultor en (Director de Admon. Admon. Procesos) Proyectos) Proyectos)

(Director de Tecnología y Calidad)

Promedio

CASO

EXPERIENCIA EN TECNOLOGÍAS

1.8

CONOCIMIENTO DEL NEGOCIO

2.4

DISPONIBILIDAD DE RECURSOS

2.6

NIVEL DE LIDERAZGO

0.6

(Gerente de Procesos y Calidad)

(Gerente de (Consultor en (Director de Admon. Admon. Procesos Proyectos) Proyectos)

(Director de Tecnología y Calidad)

Promedio PERT

Estimación 12141.33 usando el EPEI

11641.86

11514.47

10031.35

9639.45

11583.32

11352.34

Estimación Original

4767

Duración Real

12395

% Retraso Sin EPEI

160%

% usando EPEI

19%

22%

Tabla 1. Evaluación de variables.

Tabla 2. Estimación de esfuerzo (hh) modelo EPEI y Juicio de Experto.

a reglas “If…then”, generando con esto un motor de inferencia propio para la organización ya que representa el conocimiento de sus expertos.

que deben de ser realizadas con el mismo instrumento para poder compararse, lo que no es posible realizar con juicio de experto. El uso de este modelo nos habilitaría a realizar ingeniería incluso tomando como base el juicio de experto, al permitir realizar el enfoque cuantificable aún en etapas tempranas del desarrollo de software.

Resultados obtenidos. A los expertos que participaron en la estimación original y en la configuración del modelo se les pidió que evaluaran las variables de entrada en el rango definido (de 0 a 5). Con estos valores se generaron distintos escenarios, uno para cada participante, se obtuvo el promedio de los valores asignados a cada variable y se obtuvo un escenario promedio, ya con los datos se obtuvo un escenario PERT ([O-P]/6).

Referencias

La evaluación de las variables se utilizó tanto para estimar la duración como el esfuerzo. En las tablas 1 y 2 se muestran la evaluación de las variables y los resultados obtenidos.

Conclusiones

Se ha mostrado en las dos partes de este artículo que existe un problema vigente para la estimación de proyectos de software en etapas tempranas. Al mismo tiempo se ha propuesto el uso de un modelo novedoso que permite realizar estas estimaciones con un enfoque de ingeniería incluso cuando la mayoría de las variables son cualitativas. El modelo presenta una posible solución con varias ventajas, entre las que se encuentran que la experiencia pasa a ser un activo de la organización ya que se almacena en una base de datos basada en inferencias definidas por los expertos y que permite que la experiencia sea replicada sistemáticamente, ya que una vez definida la base de conocimiento las estimaciones pueden ser realizadas por otras personas, conservando el principio de las mediciones

[1] IEEE Standard Glossary of Software Engineering Terminology. [2] A. Idri, A. Abran, T.M. Khosgoftaar. “Fuzzy Analogy: A New Approach for Software Cost Estimation,” International Workshop on Software Measurement (IWSM’01), Montréal, Québec, 2001. [3] Idri, A., Abran, A., T.M. Khoshgoftaar, and Robert, S. “Estimating Software Project Effort by Analogy Based on Linguistic Values,” 8th IEEE International Software Metrics Symposium, Ottawa, Ontario, 2002. [4] A. Gray, S.G. MacDonell. “A Comparison of Techniques for Developing Predictive Models of Software Metrics”, Information and Software Technology 39, 1997.

.BIO Francisco Valdés Souto es Candidato a PhD. en Ingeniería de Software con especialización en medición y estimación de software Universidad de Quebéc en École de Technologie Supérieure. Certified ScrumMaster (CSM). Project Manager Professional (PMP). Primer mexicano certificado como COSMIC FFP Size Measurer por el COMMON SOFTWARE MEASUREMENT INTERNATIONAL CONSORTIUM (COSMIC). Es socio de SPINGERE, empresa especializada en servicios de dimensionamiento y estimación de software. @valdessoutofco

Software Guru

Figura 2. Función de variable de salida EPEI.

www.sg.com.mx |

Figura 1. Función de variable de salida original.

.PRÁCTICAS Gestión de Procesos

Paquetes de Puesta en Operación

ISO/IEC 29110

arquitectura de software y diseño detallado

n este artículo se presenta el proyecto de desarrollo de “paquetes de puesta en operación” que pretenden ayudar a pequeñas organizaciones de desarrollo de software a adoptar una parte de la norma ISO/IEC 29110 (ver “Tejiendo nuestra red”, pág 6, para conocer más sobre esta norma). El desarrollo de dichos Paquetes es parte de un proyecto dirigido por el Mtro. Alfonso Martínez Martínez (UAM) y la Dra. Hanna Oktaba (UNAM).

¿Para qué definir DPs?

Un Paquete de Puesta en Operación (DP, Deployment Package) es un conjunto de artefactos que son propuestos para facilitar la implementación o puesta en operación de un conjunto de prácticas. Es importante aclarar que un DP no es una norma ni un modelo de procesos, simplemente son artefactos de soporte o guía. Los elementos típicos de un DP son: descripción de la parte del proceso que se pretende implantar, actividades a realizar, referencias a normas y modelos reconocidos, plantillas, listas de verificación, ejemplos, material de soporte y una lista de herramientas. El proyecto de definición de DPs tiene los siguientes objetivos: • Desarrollar DPs que faciliten la adopción de la Norma ISO/ IEC 29110, en particular para las actividades de arquitectura de software y diseño detallado. • Incorporar en estos DPs los métodos y herramientas propuestos por el Software Engineering Institute (SEI) para la arquitectura de software y diseño detallado. • Probar los DPs en pequeñas organizaciones de desarrollo de software. Para este trabajo se analizó el contenido de la Norma ISO/IEC 29110 así como los métodos que propone el SEI para el ciclo de vida de la arquitectura de software, tales como: QAW (Quality Attribute Workshop), ADD (Attribute Driven Design), V&B (Views and Beyond), ARID (Active Reviews for Intermetidate Designs) y ATAM (Architecture Tradeoff Analysis Method). En este análisis se verificó que los métodos del SEI cumplieran con las actividades de Arquitectura de Software y Diseño Detallado del ISO/IEC 29110. Como resultado, se han generado dos Paquetes de Puesta en Operación cuyo método concluye hasta que se logra una arquitectura que satisface los principales requerimientos de atributos de calidad. Se decidió complementar los DP con plantillas, ejemplos sencillos, listas de verificación y autoevaluación, una lista de herramientas y matrices de cobertura con las normas ISO/IEC 29110, ISO/IEC 12207, ISO 9001-2000 y el modelo CMMI. Cabe señalar que se puso especial atención en la redacción de tal manera que sean fáciles de entender. En ambas guías, se indican las tareas que hay que realizar, para cada una se plantea: el objetivo, fundamento para realizarla, rol principal involucrado, artefactos producidos, pasos que la componen con

›› Por Erick Andrey Serratos Álvarez

su descripción detallada y una nota adicional que ofrece sugerencias, recomendaciones, información adicional o bibliografía útil. Algunos beneficios que pueden esperar las organizaciones que utilicen los DPs son: • Facilitar el diseño, documentación y evaluación de la arquitectura de software en su organización. • Incrementar la productividad y competitividad de su organización. • Incrementar la confianza y satisfacción del cliente. • Ayudar y acelerar la adopción de buenas prácticas de normas internacionales. • Acercar a la organización a una certificación o evaluación por el uso de normas internacionales. • Reconocimiento por desarrollar productos de alta calidad. Los DP ya fueron probados dando como resultado la identificación de los principales requerimientos de atributos de calidad y un diseño arquitectónico que satisface dichos requerimientos. De esta manera se puede ofrecer un producto de software de alta calidad pues satisface los requerimientos que los clientes precisaron importantes para ellos. Como trabajo a futuro se considerará la posibilidad de aplicar los DPs en pequeñas empresas de desarrollo de software. También se verá la posibilidad de poder publicar los DPs aquí mencionados, en un repositorio dedicado a DPs para todas las etapas del desarrollo de software. Finalmente se buscará traducir al inglés dichos DPs para que puedan ser publicados como reportes técnicos ISO/IEC. Si estás interesado en participar en este proyecto y aplicar los DPs en tu organización, por favor comunícate con los involucrados: Lic. Erick Serratos Álvarez (prop@xanum.uam.mx), Mtro. Alfonso Martínez Martínez (almm@xanum.uam.mx), Dra. Hanna Oktaba (ho@fciencias.unam.mx).

Referencias [1] “ISO 29110: Software Life Cycle Profiles and Guidelines for Very Small Entities (VSEs)”, Wikipedia. http://swgu.ru/sg33r8 [2] R. Kazman et al. “A life-cycle view of Architecture Analysis and Design Methods”. Software Engineering Institute, 2003. http://swgu.ru/sg33r9

.BIO Erick Serratos Álvarez es fundador y director de calidad de Qualitech, empresa dedicada a la implantación y mejora de procesos de desarrollo de software. Actualmente cursa el Posgrado en Ciencias y Tecnologías de la Información de la Universidad Autónoma Metropolitana, Unidad Iztapalapa (UAMI), asesorado por el M. en C. Alfonso Martínez Martínez y la Dra. Hanna Oktaba. erick@qualitech.com.mx

.PRÁCTICAS Arquitectura

El Rol del

Arquitecto de Software

¿qué hace un arquitecto?

lo largo de las distintas entregas de esta columna hemos cubierto las actividades del ciclo de desarrollo de la arquitectura de software y su integración dentro del ciclo de desarrollo de software. En todas estas actividades, hay un rol específico que juega un papel preponderante y es el del arquitecto de software. Mucho ha sido escrito en relación con este rol, sin embargo, en esta columna hablaremos al respecto enfocándonos más bien en las actividades que debe realizar el arquitecto a lo largo del ciclo de desarrollo, particularmente en el contexto de desarrollos de software a la medida.

Actividades del arquitecto

Concepción del proyecto. Un proyecto de desarrollo de software, particularmente cuando se trata de un desarrollo a la medida, inicia generalmente por una etapa en la cual se debe de generar una propuesta técnica y económica, muchas veces en un periodo corto de tiempo. En ésta etapa, el arquitecto juega un papel muy importante pues en general en él recae la responsabilidad de realizar una traducción de las necesidades que expresa un cliente hacia una solución técnica preliminar, que es una pieza clave para producir una estimación del esfuerzo necesario para realizar el desarrollo. El arquitecto puede, de hecho, también participar en el trabajo de estimación del sistema. Durante esta etapa del proyecto, el arquitecto debe hacer uso de habilidades técnicas (“duras”) y no-técnicas (“suaves”). Como parte de las habilidades técnicas, debe poder identificar estilos arquitectónicos y tecnologías que sean apropiados para resolver el problema y proponer una solución preliminar. Como parte de las habilidades no-técnicas, debe ser capaz de realizar un análisis de las necesidades del cliente, especialmente desde una perspectiva de negocio y poder explicar la solución técnica que propone a los distintos involucrados del proyecto.

››Por Humberto Cervantes

parse por que se identifiquen atributos de calidad pertinentes para el sistema (alineados a los objetivos de negocio) y que las métricas asociadas estén justificadas. En caso de que el cliente solicite atributos de calidad con métricas muy demandantes (por ejemplo una disponibilidad del 99.99%) debe ser capaz de entender la justificación de esas métricas y, en caso necesario, debe poder negociar con el cliente para establecer métricas adecuadas. Nuevamente, el arquitecto debe emplear aquí una combinación de habilidades “duras” y “suaves” con el fin de lograr una identificación adecuada de los requerimientos que influirán sobre el diseño arquitectónico. Diseño del sistema. La etapa de diseño del sistema es aquella donde el arquitecto de software juega el papel principal, particularmente al momento de diseñar la arquitectura. Aquí el arquitecto debe hacer uso de todas sus habilidades técnicas con el fin de establecer una solución técnica pertinente que satisfaga, en la medida de lo posible, los requerimientos que influyen en la arquitectura (ver Figura 1. La realización del diseño requiere de muchos conocimientos técnicos.

Figura 1: Durante el diseño de la arquitectura, el arquitecto toma como

.BIO El Dr. Humberto Cervantes es profesor-investigador en la UAM-Iztapalapa. Ha realizado investigación en temas relacionados con arquitectura de software desde el año 2000 y en años recientes se ha enfocado en el estudio y la aplicación de métodos que apoyen al desarrollo de arquitectura de software dentro de la industria Mexicana. www.humbertocervantes.net

Requerimientos. Durante la fase de requerimientos, el arquitecto de software se involucra con los requerimientos que influyen en la arquitectura (“drivers”) y particularmente con respecto a los atributos de calidad del sistema. El arquitecto debe preocu-

entrada los requerimientos que influyen la arquitectura (drivers) y produce un diseño arquitectónico.

Durante la etapa de diseño, el arquitecto debe también hacer uso de muchas habilidades no-técnicas. La comunicación durante esta etapa es fundamental, ya que el arquitecto debe ser capaz de comunicar el diseño, y las decisiones que lo llevaron al mismo, ya sea de forma escrita, como parte de la documentación de la arquitectura, o bien de forma oral al explicar el diseño 42

.PRÁCTICAS

Arquitectura

“…

el arquitecto de software debe asumir un papel de liderazgo y ser alguien con mucha iniciativa capaz de aprender continuamente …”

Liberación. Al momento de implantar el sistema en el ambiente productivo, muchas veces es necesario realizar ajustes finos sobre el sistema, en particular una vez que el sistema ya está operando en el ambiente de uso definitivo. La participación del arquitecto puede estar enfocada a realizar ajustes finos de la aplicación con el fin de lograr un funcionamiento óptimo de la misma.

Categorías de arquitectos

Dependiendo del tamaño del sistema, es posible que no haya un solo arquitecto que participe a lo largo de todo el proyecto y que, más bien, existan distintos arquitectos especializados que intervienen a distintos momentos del desarrollo. Así, frecuentemente, el arquitecto que participa en la concepción de un proyecto es

Conclusión

Es muy difícil poder establecer un perfil único del arquitecto de software, es por esa razón que en este artículo más bien se habló acerca de las actividades que juega este rol a lo largo del desarrollo. Un aspecto complejo del rol del arquitecto de software es que es responsable de conciliar las demandas de los distintos involucrados dentro del desarrollo. Así, debe buscar satisfacer las necesidades (no siempre compatibles) de los clientes y de la organización de desarrollo. Un arquitecto no puede, por ejemplo, proponer el uso de cualquier tecnología sin considerar aspectos tales como la curva de aprendizaje del equipo de desarrollo, si éste último no está familiarizado con la herramienta propuesta. Adicionalmente, el arquitecto de software debe asumir un papel de liderazgo y ser alguien con mucha iniciativa capaz de aprender continuamente, pero a la vez debe poder comprender que los miembros del equipo de desarrollo pueden no tener el mismo nivel técnico que él y, por ello, debe también fungir como un mentor dentro del equipo. Frecuentemente se considera que el rol de arquitecto de software es un rol extremadamente técnico y que personas que son muy buenas para la tecnología automáticamente pueden ocupar este papel. La realidad es que el rol de arquitecto de software es un rol complejo que requiere de una combinación equilibrada de habilidades técnicas y no-técnicas que son indispensables en las distintas etapas del desarrollo de un sistema.

Software Guru

Construcción y pruebas del sistema. Durante de la construcción del sistema, el esfuerzo técnico del arquitecto disminuye, aunque ésto no significa que ya no se realizan actividades técnicas. En esta etapa, desde un punto de vista técnico, el arquitecto debe terminar de completar las partes faltantes del diseño de la arquitectura y corregir las decisiones previas que hayan resultado ser equivocadas. Desde un punto de vista no-técnico, el esfuerzo aumenta pues el arquitecto debe enfocarse en cuidar que el sistema se desarrolle de acuerdo a la arquitectura que se definió para el mismo. Aquí el arquitecto juega un papel de mentor y muchas veces debe explicar cuestiones del diseño del sistema al equipo de desarrollo. El arquitecto puede también realizar actividades de aseguramiento de calidad tales como inspecciones de productos de trabajo, ya que su nivel técnico y conocimiento del dominio del problema le da una ventaja para identificar problemas que posiblemente podrían no ser identificados por ingenieros con un nivel técnico y conocimiento del dominio del problema menores. Al momento de realizar pruebas del sistema, la participación del arquitecto es importante, particularmente al momento de realizar pruebas relativas a los atributos de calidad del sistema.

conocido como el “Arquitecto de Soluciones” mientras que el arquitecto que participa durante el desarrollo es conocido como el “Arquitecto de Software”. Pueden haber otras especializaciones tales como el “Arquitecto de Sistemas”, que se encarga de tomar decisiones de diseño que van más allá del software y que involucran hardware, o bien el “Arquitecto Empresarial” que, como su nombre indica, se especializa en el diseño de una arquitectura empresarial. Existen también ciertas especializaciones a nivel tecnológico, como por ejemplo el “Arquitecto SOA”. Cualquiera que sea la especialidad del arquitecto, en general, un aspecto común es que su rol involucra la toma de decisiones que tienen un fuerte impacto sobre el sistema.

www.sg.com.mx |

de la arquitectura al equipo de desarrollo. Durante la evaluación del diseño de la arquitectura, el arquitecto debe ser capaz de presentar el contexto del problema y el diseño de la arquitectura al comité de evaluación, y debe ser capaz de responder a las preguntas de dicho comité, o bien de aceptar las observaciones que se hacen al diseño.

.PRÁCTICAS Ágil

Innovar Colaborativamente?

¿Cómo lecciones aprendidas

radicionalmente se ha considerado a la creatividad y la innovación como características o actividades primordialmente individuales. Sin embargo, existe una cantidad interesante de evidencia que nos demuestra que, en realidad, muchas de las producciones artísticas y científicas que vemos en la actualidad son el resultado de un esfuerzo que se apoya en la interacción de diversos agentes, los cuales intercambian fluidamente información y conocimiento para crear cosas tales como: una canción, una novela, una nueva teoría científica o todo un movimiento artístico. En el libro Artful Making, de Lee Devin y Robert Austin, se presenta una serie de principios y casos reales que pueden ayudar a comprender mejor este escenario dentro un contexto empresarial. El año pasado, Lee Devin dictó una conferencia en nuestro país (Perú) [2] y nos brindó su visión sobre cómo crear una cultura de innovación sostenible y que funcione.

El modelo teatral

Devin parte del ejemplo de cómo un elenco de actores gesta una obra de teatro y lo utiliza de modelo para ilustrar cómo funciona el proceso innovador dentro del contexto de un equipo. Una compañía teatral crea un nuevo producto, es decir la obra, y lo comienza a vender anticipadamene. Dicho de otra forma, consigue financiamiento y vende entradas antes de la fecha de estreno. Quizás lo que resulta más interesante es que logra vender el producto antes de que esté terminado y nadie sepa exactamente cómo va a ser. Y también es interesante que, en la gran mayoría de casos, se logre terminar el producto a tiempo y dentro del presupuesto para presentarlo durante la noche del estreno. Toda obra se basa en un guión. Sin embargo, cada representación posee características únicas que la hacen distinta de todas las anteriores. Una puesta en escena de Hamlet en Lima en el año 2011 es distinta de una puesta en escena en la misma ciudad en el 2008 y también es dis.BIO tinta de una en Buenos Aires en el mismo año, de una en Nueva Gustavo Quiroz es consultor y director en Open Edge Technologies, York en el 2005 y, por supuesto, empresa basada en Lima, Perú. Gustavo ha dedicado los últimos 4 años de de todas las anteriores puestas en su carrera a dirigir y asesorar equipos escena de Hamlet desde hace más ágiles en algunos de los corporativos más importantes del Perú. de 400 años. gustavo@openedgetech.com La razón de esto se basa en el proceso artístico de construcción

››Por Gustavo Quiroz

de la obra basado en los ensayos que realiza el elenco. Si bien cada actor debe llegar debidamente preparado al ensayo, es durante el mismo que se producen interacciones impredecibles que desafían cualquier concepción previa por parte de los actores o del director. Un actor debe pues estar preparado para responder a estas interacciones, aunque esto implique, inevitablemente, desechar ideas y planes sobre cómo debería interpretarse tal o cual personaje. La obra puede verse, entonces, como el resultado emergente de un proceso iterativo y colaborativo ejecutado por los actores con la supervisión del director. Son precisamente estas características (producto emergente, iteración y colaboración) las que forman parte de cualquier proceso innovador ejecutado en equipo. ¿Y cómo trasladamos estos conceptos a un entorno empresarial? Para entenderlo, examinemos primero las cualidades esenciales que deben estar presentes en una cultura que fomente la innovación, las cuales forman parte integral de la perspectiva de los actores y artistas respecto a su trabajo.

Cualidades esenciales

La primer cualidad es reconocer y celebrar la diferencia entre planeación y preparación. Un actor planifica horarios, materiales, enfoques y objetivos para abordar al personaje, y expectativas de cómo reaccionarán los personajes con los cuales interactuará. Pero, además de esto, se prepara. Esto es, se aprende las líneas de memoria para poder pronunciarlas a modo de reflejo y sin pensar. Investiga el contexto del personaje para situarse lo mejor posible en él y responder de manera adecuada ante lo inesperado. Esto es similar a lo que realiza un deportista, practica movimientos canónicos pero una vez en el partido improvisa intuitivamente. Lo siguiente es sentirse cómodo con la ambigüedad y darle la bienvenida a la casualidad. El trabajo innovador es, por definición, impredecible. Por lo tanto, debemos estar dispuestos a observar atentamente todo aquello que se nos cruce en el camino y no desechar nada de antemano. Las investigaciones de Devin y Austin concluyeron que, al menos la mitad de todas las innovaciones científicas y médicas, fueron producto de accidentes y casualidades. Dos casos famosos son el descubrimiento de la penicilina por parte de Alexander Fleming —a causa de mantener un laboratorio desaseado— y el uso del sildenafil para tratar la disfunción eréctil, cuando la intención inicial era tratar la hipertensión. Estas nociones desafían el concepto de eficiencia a corto plazo, pues el proceso innovador puede parecer errático y desenfocado por momentos. 44

.PRÁCTICAS Ágil

Boeing escogió alrededor de 30 de sus mejores trabajadores para conformar el grupo. Ellos recibieron considerable autonomía para desenvolverse, no tenían un lugar formal en el organigrama ni un espacio dedicado, podían recorrer la planta de ensamblaje, hablar con cualquier persona y revisar cualquier proceso para encontrar cosas que mejorar. Su método era el siguiente: ante cualquier problema o situación, proponer siete diferentes soluciones, sin preocuparse por la factibilidad o los recursos disponibles. Esto, por supuesto, requería deshacerse del miedo al fracaso. Al principio, nadie sabía que pensar de este grupo de “locos” y eran vistos con recelo. Su primer gran desafío fue enfrentarse al problema de cargar y fijar los asientos en una nueva línea de montaje. El método existente para cargar y fijar una fila de asientos para pasajeros en un avión requería 2 turnos completos de 16 personas cada uno, 256 horas-hombre en total. El grupo decidió salir de la planta a buscar cosas que les pudieran ser útiles. Uno de lo miembros encontró un cargador de heno en un corral y le pareció que algo así podría funcionar así que convenció al granjero para que le construyera uno de acuerdo a sus especificaciones. Realizó algunos ajustes y le agregó un motor que encontró en un sótano. Al día siguiente lo llevaron a la planta para mostrarlo. La burla inicial por parte de los trabajadores se convirtió en interés al comprobar que funcionaba. Les tomó dos años refinar el dispositivo, pero cuando terminaron el tiempo de instalación de una fila de asientos era de 30 minutos y sólo requería de 4 personas. Es decir, 2 horas-hombre en lugar de 256, lo cual representó millones de dólares de ahorro anual. Posteriormente esta mejora se aplicó en la línea de ensamble de otros aviones de Boeing, y moonshine ha contribuido a diversas mejoras en la empresa.

Caso: Moonshine en Boeing

Veamos, a continuación, un caso que muestra cómo se plasman algunas de estas cualidades en la práctica. Moonshine es una técnica Lean para buscar métodos innovadores para mejorar las operaciones; su nombre viene de trabajar de noche, bajo la luz de la luna. La corporación aeroespacial Boeing creó en el 2001 un grupo moonshine con la tarea de “ser creativo e innovador y no quedar atrapado en la manera en que siempre se han hecho las cosas”. Esto se traducía en descubrir nuevas formas para reducir el tiempo y el costo requeridos para ensamblar aviones.

Referencias [1] R. Austin, Lee Devin. Artful Making: What Managers Need to Know About How Artists Work. http://amzn.to/sg33r3 [2] L. Devin. “Artful Making: Toward a Culture of Innovation”. Ágiles 2010: 3ra Conferencia Latinoamericana sobre Metodlogías Ágiles http://bit.ly/sg33r4 [3] J. W. Shenk. “Two Is the Magic Number”, Slate Magazine. http://slate.me/sg33r5 [4] R. Austin, R. Nolan, S. O’Donnell. “Boeing Co.: Moonshine Shop”, Harvard Business Review, 2007.

www.sg.com.mx |

La tercer cualidad es reconocer y celebrar la diferencia entre problemas y dificultades. Un problema se resuelve y entonces termina. Tiene límites definidos. Las dificultades, por el contrario, no se resuelven. Debemos enfrentarlas continuamente. Si tratamos una dificultad como problema, malentendiendo su naturaleza, nuestras estrategias y tácticas serán inadecuadas y albergaremos sentimientos de futilidad y fracaso por la falta de progreso. Justamente, una consecuencia provechosa de emplear el enfoque de las dificultades es minimizar la amenaza del fracaso. La sensación de fracaso nos paraliza y nos impide innovar pues, para hacerlo, requerimos cometer errores y aprender de ellos. Otra cualidad es emplear la imaginación como herramienta. En muchos entornos se considera a la imaginación como desbocada y poco confiable. Para los artistas, sin embargo, es esencial. Una cultura de innovación privilegia la imaginación. Es decir, encuentra maneras de alimentarla y protegerla. Es conocido que varias de las empresas más innovadoras permiten un tiempo específico para proyectos que no tienen aplicación directa o valor comercial, como es el caso de Google. La quinta y última cualidad es la consideración del trabajo como valioso y digno de hacerse en sí mismo. Esto debe asumirse como una decisión consciente y no cómo una característica variable según el tipo de trabajo. Es decir, para innovar debemos concentrar nuestra atención en el proceso, en el propio acto creativo en lugar de en el producto o destino final. Esta también es una característica distintiva de los grandes artistas. No les importa la fama, el dinero o lo que pensamos de ellos. Les interesa su trabajo y hacerlo bien. Incluso, si alguno de sus trabajos es percibido como fallido por el público, están convencidos de que valió la pena hacerlo y de que influirá todo trabajo posterior.

Software Guru

››El trabajo innovador es, por definición, impredecible.

.PRÁCTICAS Prueba de Software

Complementando

CMMI TMMi con

analizando el retorno de inversión

propósito del fuerte impulso a la capacitación y certificación de organizaciones e individuos en nuestro país, vale la pena poner en perspectiva los logros obtenidos, por ejemplo, en áreas de mejora de procesos de software, donde la meta es alcanzar cierto nivel de madurez ya sea en Moprosoft o CMMI. En el caso de éste último, abundaremos particularmente sobre algunos elementos que apoyarían en el análisis del retorno de la inversión, desde el punto de vista de las pruebas, a través de la aplicación de un proceso basado en algún Modelo Especializado en Pruebas como TMMi (Test Maturity Model integration), el cual podría visualizarse como una opción natural para cubrir principalmente las áreas de Validación y Verificación contempladas en el nivel 3 de CMMI. Recordando que en Diciembre del 2010 se liberó finalmente la versión 3.1, versión ya completa, de TMMi es muy reciente su liberación y por ende las empresas no podían certificarse en TMMi, pues al no estar completamente definido (faltaban por desarrollar los niveles 4 y 5), tampoco existía un proceso formal para realizar assessments. Sin embargo esas posibilidades están cada vez más cerca. Para aquellas organizaciones que han optado por buscar la mejora de sus procesos de prueba basándose en TMMi, les hago énfasis en la importancia de que luego de realizar un assessment, un consultor los ayude a trazar un plan de mejora tomando en consideración no sólo aspectos técnicos sino también el retorno de la inversión que ese plan requerirá [2]. Esto hará más rentable y viable el esfuerzo de mejora de procesos. Aún cuando TMM (Testing Maturity Model) ha sido su principal fuente, TMMi se basa .BIO además en aspectos de CMMI y en estándares internacionales Sandra Berenice Ruiz Eguino es Consultora de e-Quallity en proyectal como el de la IEEE[3], entre tos de mejora de organizaciones de Prueba de Software. Cuenta con otras fuentes, incluso una parte certificación internacional en Prueimportante de la terminología de bas por el ASTQB. A lo largo de su trayectoria profesional ha actuado pruebas empleada se basa en el como Ingeniero de Pruebas Senior, Líder de Proyectos, AdministraISTQB [4]. dora de Proyectos nacionales e internacionales, y Directora de Como ya hemos comentado Operaciones. Ha sido profesora anteriormente, el modelo TMMi de la Universidad Autónoma de Guadalajara, donde realizó sus se basa en una estructura de 5 niestudios de Maestría en Ciencias Computacionales. veles que son:

››Por Sandra Berenice Ruiz Eguino

1. Inicial. No existe como tal un proceso definido para pruebas, éstas son concebidas como parte del debugging. La organización no cuenta con un entorno estable para el soporte de los procesos. 2. Administrado. Las pruebas se convierten en un proceso administrado y claramente independiente del debugging. Considera las siguientes áreas clave: políticas y estrategia de prueba, planeación de prueba, monitoreo y control de prueba, diseño y ejecución de prueba, ambiente de prueba. 3. Definido. Las pruebas se encuentran totalmente integradas en el ciclo de vida de desarrollo del software, dejando de representar una fase aislada posterior a la codificación. Considera: organización de prueba, programa de entrenamiento para prueba, ciclo de vida de prueba, prueba no funcional, revisiones de pares (peer review). 4. Medido. En este nivel, las pruebas ya son un proceso perfectamente definido y medible. Aquí entran áreas como: medición de prueba, evaluación de la calidad del software y revisiones de pares avanzada. 5. Optimizado. La organización es capaz de llevar un control sistemático de costos y efectividad del proceso de pruebas, es capaz de continuar mejorando sus procesos. Se apoya en áreas como prevención de defectos, optimización del proceso de prueba, y control de calidad. La relación de TMMi con CMMI hace a este modelo especializado en pruebas especialmente interesante para aquellas empresas que cuentan con cierto nivel de madurez en CMMI y que desean ya sea subcontratar las pruebas o bien, implantar su propio proceso basados en TMMi. Como bien sabemos, entre algunas de las áreas de proceso que habría que implantar para alcanzar por ejemplo, el nivel 3 de CMMI, se encuentran primordialmente la de Verificación y la de Validación, (e incluso la de Integración de Producto), las cuales podrían alcanzarse mediante el desarrollo de un proceso basado en algún Modelo Especializado en Pruebas, como TMMi, el cual a su vez debiera contemplar la definición de métricas de producto. Estas métricas que se obtienen de las pruebas pueden ser de gran utilidad para medir el retorno de la inversión (trátese de 46

.PRÁCTICAS

Prueba de Software

Cantidad de defectos potenciales • Problemas en requerimientos, diseño, documentación, inadecuada corrección de defectos, errores en planes de pruebas, en casos de prueba.

Comportamiento del producto comparando resultados de pruebas regresivas y progresivas • Esfuerzo empleado en remoción de defectos y costos asociados (correcciones, re-trabajo, análisis de defectos, etc.) • Cantidad y costo de errores que pasan a producción • Ahorros estimados en mantenimiento Una expectativa natural al implantar un modelo como CMMI, es que permita mejorar el proceso de desarrollo, y que implícitamente mejore además la calidad del producto. Sin embargo, aún cuando esto pareciera tener cierta lógica, no siempre ocurre así. Quizás en buena medida porque el principal objetivo oculto que ciertas organizaciones persiguen, no se focaliza en obtener una mejora como tal de sus procesos, sino simplemente en obtener mejores credenciales para vender. Lo cual no es precisamente malo, pero sí nos debiera llevar a evaluar qué tan bien estamos aplicando nuestras estrategias corporativas, en relación a lo que buscamos en el mediano y largo plazo. Por lo anterior, se esperaría entonces que la aplicación sistemática de un Modelo de Calidad Especializado en Pruebas, contribuya en alto grado a la mejora de calidad de un producto de software; y si este modelo de pruebas (TMMi) a su vez es uno que contiene áreas y prácticas alineadas a las manejadas por el modelo de desarrollo que nosotros o nuestros clientes hemos adoptado (CMMI), nos allanará el camino, incluso aún cuando se trate de la aplicación de algún proceso de pruebas basado en su modelo predecesor TMM, o hasta en algún otro modelo de pruebas que maneje áreas semejantes.

Densidad de defectos • Densidad = Cantidad de defectos / tamaño del software (ya sea que se mida en líneas de código, puntos de función, etc.) Cantidad de defectos removidos • Por etapa en la que fueron removidos- antes o después de las pruebas, durante el deployment, etc. • Por causa raíz (código, base de batos, ambiente, datos de prueba, etc.) • Eficiencia en la remoción de defectos • Tasa de remoción de defectos por desarrollador/por período • Tasa de remoción de defectos por ciclo de prueba

Referencias [1] Erik van Veenendaal, TMMi Framework v3.1,Test Maturity Model Integration TMMi Foundation, 2010 [2] La calidad del proceso de software, Software Gurú, Feb-Abr 2009 [3] IEEE, 829 Standard for Software Test Documentation,1998 [4] ISTQB, Glosario de Términos del ISTQB (International Software Testing Qualifications Board), 2007

Software Guru

Por otro lado, como resultado de la evaluación de varios productos de software que realizamos durante los concursos llevados a cabo en 2007 y 2008 sobre productos de software mexicanos, mostramos en ediciones anteriores, cómo el no probar adecuadamente incrementa los costos de mantenimiento, lo cual a su vez merma las utilidades y dificulta la inversión en otros rubros estratégicos para las organizaciones. Es importante por lo tanto, poner especial énfasis en las métricas de pruebas, de manera que podamos realizar las actividades necesarias para bajar costos, mejorar la productividad, mejorar la calidad del software y los procesos que permitieron desarrollarlo, asegurando así un notorio retorno de la inversión en el corto plazo. Algunos ejemplos de métricas de pruebas que pudieran ser de utilidad son:

• Tiempos de respuesta en la corrección de defectos • Cantidad de defectos por severidad (1. Muy Alta, 2.Alta, 3.Media, 4.Baja, 5.Mejora) • Cantidad de defectos por desarrollador • Cantidad de defectos pospuestos

www.sg.com.mx |

la inversión hecha para implantar tanto un modelo de mejora de desarrollo o uno especializado en pruebas). Es decir, podemos contar con elementos que nos lleven a definir cuánto tiempo nos llevará recuperar lo invertido en mejorar nuestros procesos de desarrollo. Para ello debemos conocer: • ¿Cómo estamos? • ¿Qué tanto nos cuesta hacer las cosas como las hemos venido haciendo? • ¿Qué problemas tenemos y cuánto tiempo y costo nos implica resolverlos? • ¿Cuánto esfuerzo hay que aplicar para corregir problemas (re-trabajo)? • ¿Quienes cometen más errores? • ¿Cuánta capacitación necesitamos para mejorar?

.COLUMNA Tecno-lógico

Es un

Nuevo Mundo

trabajadores del conocimiento y procesos

ablar de la “Revolución Informática“ en estos días ya suena a algo anacrónico y viejo: empezando la segunda década del siglo XXI pocos dudan del impacto que las tecnologías de información han tenido en el mundo de los negocios, en la cultura general y la manera en que vemos y entendemos el mundo. A pesar de ser considerada como una industria joven, con apenas unas décadas de nacimiento, ésta ha probado su valía creando a algunas de las compañías más grandes y rentables del mundo en los últimos 40 años. Sin embargo, debido también a la novedad en esta disciplina, los métodos y procesos usados para crear tanto hardware como software siguen cambiando y desarrollándose para adaptarse al nuevo mundo de una vida digital, conectada y con millones de usuarios.

La administración científica

A principios del siglo XX, el ingeniero y economista norteamericano Frederick Winslow Taylor redactó en su libro Principles of Scientific Management un sistema de organización del trabajo llamado “administración científica“, que después sería conocido como Taylorismo, basado en la aplicación de métodos científicos positivistas y mecanicistas a la relación entre los obreros y las técnicas de producción desarrollados en la revolución industrial con el fin de maximizar la eficiencia de la mano de obra y de la maquinaria mediante la división sistemática de las tareas, la organización del trabajo en sus secuencias y procesos, además del cronometraje de las operaciones, mas un sistema de motivación mediante el pago de primas al rendimiento, suprimiendo la improvisación en la actividad industrial. De esta manera, la administración científica se aplica a los métodos de producción como una dirección que asigna al proceso laboral los principios básicos del método científico, basado en: • La división del trabajo en dirección y trabajadores. • La subdivisión de las tareas en otras más simples. • La remuneración del trabajador según su rendimiento en producción.

Mauricio Angulo es programador desde 1989 divulgador, ávido escritor y emprendedor. Actualmente es CEO y fundador de Tesseract Space donde realiza funciones de asesor y consultor de innovación tecnológica, mercadotecnia digital y experiencia de usuario.

El Taylorismo aumentó la eficiencia en las fábricas para la producción de bienes por medio de la reducción, simplificación y optimización de procesos, tanto incluyendo tecnología en ellos como capacitando y entrenando a los obreros para especializarlos en labores técnicas. El Taylorismo como método de trabajo tuvo un impacto importante en la creación y formación de las primeras empresas a principios del siglo pasado y es debido a esta teoría que las empresas utilizan un sistema de división de áreas como “administración“, “legal“, “recursos humanos“ y varias más que todavía se usan en la administración de empresas en nuestros días.

Los trabajadores del conocimiento

Si bien la administración científica proveyó de las guías y métodos que se necesitaban para suministrar la creciente demanda de bienes de consumo a las grandes ciudades, a mediados del siglo XX se crea la figura del “trabajador del conocimiento“, una especie de “obrero“ especializado cuyo trabajo no puede ser medido en el número de piezas que produce por hora, sino por la innovación que aporta a los procesos de producción. Un trabajador del conocimiento produce intangibles: ideas, información, que para que sean productivos alguien debe apropiárselos e integrarlos en una tarea. Son trabajadores del conocimiento tanto los investigadores científicos y los cirujanos, como los dibujantes, los creativos, los publicistas, los gerentes o los empleados que trabajan con una computadora. El problema en la gestión de los trabajadores del conocimiento es que su trabajo no puede ser simplificado o sistematizado debido a la naturaleza intangible de lo que producen: una buena idea puede producir más en términos de beneficios al negocio que años de optimización de procesos. Las condiciones para que un trabajador del conocimiento pueda operar eficientemente difieren mucho a las que requiere un obrero, ser un trabajador del conocimiento implica autogestionarse, es decir, concentrarse en la tarea, administrar el tiempo, asumir responsabilidad por su propio desarrollo, crecimiento y por los resultados generados.

TI y la administración actual

A 100 años de la definición del Taylorismo las empresas, sus áreas y sub-áreas siguen siendo organizadas de la misma manera que cuando eran sólo fábricas que producían bienes de consumo, enfrentándose a serios problemas en cuanto al manejo y gestión de los trabajadores del conocimiento. Peter Drucker menciona en su libro Knowledge-Worker Productivity: The Biggest Challenge que “en términos de los conocimientos reales sobre la productividad del trabajador del conocimiento, estaremos en el año 2000 aproximadamente donde estábamos en 1900 en términos de los conocimientos sobre la productividad del trabajador manual”, lo que es indicativo de lo mal preparadas que se encuentran las empresas para manejar y gestionar sus áreas de TI de forma óptima. Dentro de los grandes corporativos cuyo foco no es la tecnología –por ejemplo, el gobierno– las áreas de TI se encuentran englobadas dentro de las áreas de administración porque se les consideran “áreas de servicios“, limitadas a sustentar la base tecnológica del corporativo. En los corporativos cuyo foco es la tecnología, las personas especialistas en su desarrollo se encuentran en las partes bajas del organigrama dejando la toma de decisiones a ejecutivos que muchas veces no tienen la preparación ni el conocimiento de primera mano sobre la misma tecnología que se crea en las empresas para las que trabajan. 48

En ambos casos el problema en la administración deficiente se refleja como la burocracia alrededor de los trabajadores de TI: reportes, reglamentos, juntas, reuniones, planes, procedimientos y varios otros elementos que más que facilitar el proceso de creación e innovación son obstáculos cuyo fin es justificar el trabajo en lugar de volverlo sustentable. En un entorno así, el personal de TI se vuelve burocrático y reactivo, enfocado en llenar formatos y documentos en lugar de crear tecnología eficiente y enfocado a usuarios reales. No digo que los elementos de administración deban ser eliminados por completo, sino que deberían ser reducidos a lo que es estrictamente necesario para dar un modelo e infraestructura que sustente a los trabajadores de información dentro de las áreas técnicas de las empresas, pero con 100 años a cuestas de administración científica en el cuerpo directivo esta no será una tarea sencilla, al menos en las empresas tradicionales. Este puede ser un indicativo de por qué cada vez hay más startups de tecnología y porqué el talento técnico empieza a preferir trabajar en empresas pequeñas o incluso en sus propias ideas.

La nueva realidad

Actualmente, cuando se trata de tecnología, todos pueden comenzar un negocio. Las herramientas y plataformas que solían estar fuera del alcance de muchos ahora son fácilmente accesibles y la tecnología de alto costo ahora se puede obtener por precios muy bajos o inclusive de manera gratuita. Una persona puede realizar el trabajo de dos o tres y en ocasiones de departamentos enteros. Cosas que hasta hace unos años eran consideradas imposibles son algo simple hoy en día. Las tecnologías de información nos habilitan para tener acceso a prácticamente toda la información que podamos necesitar sin movernos de nuestra silla, trabajar en cualquier lugar sin necesitar de una oficina y colaborar en tiempo real con personas que se encuentran a cientos de kilómetros. Debemos repensar los procesos y métodos con los que trabajamos basados en el nuevo mundo en el que vivimos, muy diferente de aquel en que fueron redactados los principios con los que se crearon las empresas que existen hoy en día. La verdadera mejora de procesos se encuentra en el enfoque al usuario y al mercado, no en la burocracia laboral.

››Por Mauricio Angulo

.COLUMNA Programar es un Estilo de Vida

Interoperabilidad

¿a qué aspiramos cuando hablamos de ella?

Gunnar Wolf es administrador de sistemas para el Instituto de Investigaciones Económicas de la UNAM y desarrollador del proyecto Debian GNU/Linux. www.gwolf.org

l pasado 2 de junio participé en el foro «Software Libre en México, reflexiones y oportunidades», organizado por la Comisión de Ciencia y Tecnología del Senado de la República. En este foro tocamos cuatro temas principales: Educación, gobierno, industria y sociedad. Si bien el objetivo explícito central del foro fue presentar ante los legisladores y medios interesados tanto los puntos de vista que tenemos los activistas del software libre como las historias de éxito, los avances y problemas con que nos hemos encontrado en los ya más de quince años que llevamos de existencia en nuestro país, posiblemente lo más importante que nos llevamos los participantes fue la reactivación de un grupo de discusión para tratar temas políticos relacionados con la tecnología y con el factor cohesivo de estar interesados en la difusión del software libre. Este grupo, coordinándose a través de una lista de correo pública[1], está actualmente en proceso de definir los puntos de la agenda digital a presentar; el primero de ellos es el de la interoperabilidad. El tema coincide con la presentación de la versión preliminar de un acuerdo de la Secretaría de la Función Pública (SFP), a ser discutido y –esperamos– aprobado en las próximas semanas o meses. Nos resulta de gran importancia no sólo analizar y proponer en lo relativo a esta temática hacia el interior de nuestro grupo (y de las instancias gubernamentales involucradas), sino también hacia los demás profesionales en el tema, como lo son los lectores de esta revista. Dada la imposibilidad de proporcionar referencias a un documento aún inexistente y motivado por el interés que seguramente ésto causará a más de uno de ustedes, coloqué a su disposición una copia de una versión preliminar de este texto en mi sitio Web[2].

¿A qué nos referimos con interoperabilidad?

Al enfrentar un desarrollo, un punto fundamental a considerar desde muy temprano es cuál será su límite o

interfaz, sea un sistema, un API sobre la nube, un servicio, un componente o una biblioteca, debemos delimitar por qué mecanismo recibiremos las solicitudes de los usuarios y por cuál le entregaremos los resultados. Del mismo modo, nuestro sistema parte de un contrato con diversos elementos (nuevamente, de cualquiera de los niveles antes descritos) que le brindarán facilidades, por ejemplo, de conectividad a red o de manejo de bases de datos. Hablar de interoperabilidad significa que en cada uno de dichos puntos, en cada una de las interfaces, el intercambio de datos se realice de forma tal que evite imponer dependencia en algún paquete específico, en los designios de algún producto que a futuro pudiera –de cierto modo– mantener como rehén sea al usuario final, al desarrollador o a la entidad que requirió del desarrollo en cuestión. En palabras del Grupo de Trabajo para la Interoperabilidad, de la Asociación Francófona de Usuarios de Software Libre[3]: “La interoperabilidad es la capacidad que tiene un producto o un sistema, cuyas interfaces son totalmente conocidas, para funcionar con otros productos o sistemas existentes o futuros y eso sin restricción de acceso o de implementación.” El borrador de la SFP divide la definición de interoperabilidad en cinco sub-definiciones: • Interoperabilidad - Definición del concepto global. • Interoperabilidad organizacional - Homologar criterios y procedimientos entre distintas dependencias. • Interoperabilidad semántica - Un manejo estandarizado del significado de los diversos conceptos. • Interoperabilidad técnica - A las especificaciones técnicas que garantizan que los componentes tecnológicos de los sistemas de información están preparados para interactuar de manera conjunta. • Neutralidad tecnológica - Busca que cada dependencia pueda elegir los programas y mecanismos más adecuados para su desarrollo sin que se favorezca o penalice a ninguno por criterios más allá de los puramente técnicos. 50

.COLUMNA

Programar es un Estilo de Vida

Las múltiples facetas de la interoperabilidad

Hablar de interoperabilidad no se limita a permitir que usuarios con configuraciones diversas puedan usar los sistemas de gobierno, como lo mencionamos en el primer apartado, parte importante de la interoperabilidad se refiere a cómo facilitar el intercambio de información entre entidades del mismo gobierno, a la creación de modelos estandarizados (la ya citada interoperabilidad semántica) con los que puedan representarse e intercambiarse datos acerca de las estructuras más comúnmente encontradas y repetidas, las cuales posiblemente faciliten que paulatinamente se vaya creando, en vez de una colección de sistemas que conforman al e-gobierno, una nube de información con un mínimo de duplicación de información. ¿Y cómo elegir entre tantos estándares disponibles? ¿Qué formatos, protocolos y lenguajes son los más adecuados? ¿Cómo podemos determinar cuál es un estándar abierto? Este es un tema que da para largas discusiones, y motivo de los diferentes foros referidos. Cito lo que marca el Proyecto de Acuerdo al respecto: Los estándares abiertos deberán tener, como mínimo, las características siguientes: a. Disponibilidad. b. Que los derechos de autor estén disponibles, libres de regalías y condiciones. c. Maduros. d. Internacionalmente aceptados. e. De fácil distribución. f. Con amplio soporte en el mercado. El sólo hecho de reducir la cantidad de datos redundantes (y por consiguiente avanzar en la larga lucha contra los peregrinares a mil ventanillas para cualquier trámite trivial) ya por sí sólo lo valdría. Agreguemos a esto que reducirá fuertemente la dependencia de proveedores únicos y de la permanencia en el mercado de productos específicos, fomentando el crecimiento de una verdadera industria de desarrollo de software. Sigamos entonces, la discusión que se presentará sobre estos temas en los próximos meses. Este es un tema que indudablemente impactará el trabajo de todos nosotros y en el que todos tendremos algo que aportar.

››Por Gunnar Wolf

Referencias [1] Archivo público de la lista de correo «discusion-softlibre-senado» [2] Proyecto del Acuerdo por el que se establece el Esquema de Interoperabilidad y de Datos Abiertos de la Administración Pública Federal [3] Grupo de Trabajo para la Interoperabilidad, AFUL

Software Guru

Quien pegue una etiqueta en una página web que diga “esta página se ve mejor con el navegador X” es un nostálgico por los días viejos y malos, antes de la Web, cuando tenías muy pocas probabilidades de leer un documento escrito en otra computadora, otro procesador de textos u otra red. — Tim Berners-Lee, Technology Review, julio 1996 El documento presentado por la SFP nos parece muy esperanzador, está escrito de forma clara y bastante exhaustiva. El cuidado que debemos ahora poner va principalmente para que el acuerdo no quede en letra muerta, debe ser del conocimiento de las diversas dependencias y ser tomado en serio para beneficio no sólo de toda la población, sino que de cada una de dichas dependencias. Además, debe ser conocido y comprendido por la industria nacional de desarrolladores de software, dado que interoperar sin restricciones no únicamente beneficia al sector público, sino que, a fin de cuentas, a todos los implicados. Escribir software que no dependa de implementaciones específicas es sencillamente escribir mejor software. Al día de hoy, como usuarios, tristemente nos resulta muy común encontrar, una y otra vez, ejemplos de cosas que podrían trivialmente ser interoperables, pero resultan no serlo y lo que es peor: sin razón alguna. Ejemplos de lo que digo son demasiado comunes. Desde la aplicación desarrollada por el SAT para presentar la declaración de impuestos (desarrollada en Java, plataforma que se popularizó al ser la primera en impulsar explícitamente la interoperabilidad como su principal promesa), que sencillamente se niega a operar al ser llamada con cualquier navegador que no sea Internet Explorer, hasta el SUA del IMSS, única manera en que una empresa puede dar de alta y administrar a su plantilla de trabajadores ante IMSS e INFONAVIT, que requiere ser ejecutada en computadoras corriendo Windows. Y al igual que estos dos casos de altísima visibilidad, seguramente ustedes podrán citar a ejemplos adicionales que obligan a sus usuarios a emplear tecnologías específicas, sin justificación técnica alguna para hacerlo. El pretexto más frecuente que encontramos ante cualquier solicitud de que algún sistema sea utilizable desde una plataforma distinta es el ya sabido “eso es lo que hay y no podemos hacer nada al respecto” donde modificar la base de software ya desarrollado e instalado significaría una tarea titánica. Sin embargo, los servicios fundamentales que deben estar disponibles para toda la población deben ser priorizados. Resulta inaceptable que a la población en general se le imponga el requisito de emplear una tecnología específica (independientemente del papel dominante que ésta tenga actualmente en el mercado), especialmente dado el desarrollo y rápida adopción de estándares como HTML5, que permiten un despliegue extensivo de interfaces de usuario ricas y completamente multiplataforma.

www.sg.com.mx |

Del dicho al hecho

.FUNDAMENTOS

Entendiendo el Control¿qué dees Versiones y cómo funciona? ››Por Javier Novoa

na de las tareas fundamentales que todo programador debería de aprender, si no a administrar por lo menos a usar, es la del versionado de código. En lo que concierne a la escuela de la cual soy egresado, esto no se enseñaba cuando era estudiante, y fue sólo hasta que me fui metiendo más al ambiente de mi carrera profesional que me di cuenta de la importancia de estas herramientas.

¿Que es un versionador?

Figura 1. Ejemplo de un esquema con branches.

¿Cómo funciona?

viarle a algún colaborador con permisos de escritura al repositorio original los cambios que se desean integrar. En versionadores distribuidos como Git o Mercurial, se puede tener un propio repositorio local que alojará los cambios del colaborador sin permisos, y a través de un proceso llamado pull request, solicitar la integración al repositorio original. Cuando surge la necesidad de reparar algún error reportado, o de comenzar a trabajar en el código fuente para implementarle mejoras o nuevas funcionalidades, sería un caos que todos trabajaran sobre la misma base de código. Un versionador nos permite tener varias líneas de nuestro sistema desarrollándose al mismo tiempo sin que interfieran unas con otras. A cada línea se le suele llamar un branch (rama), y a la línea principal se le suele llamar el trunk (tronco). Generando branches, el trabajo se vuelve más sencillo, cada uno trabaja en su ámbito, y sólo es cuestion de hacer los merges adecuados para integrar al trunk los cambios que cada branch vaya teniendo listos. La figura 1 muestra el ejemplo de un esquema con branches y merges. Los tags son un tipo de branch especial dedicado a mantener ‘fotografías’ fijas de ciertas versiones del proyecto, por ejemplo liberaciones.

De la wikipedia en español: “Se llama control de versiones a la administración de los diversos cambios que se realizan sobre los elementos de algún producto o una configuración del mismo”. Un versionador o sistema de control de versiones permite y controla que distintas personas puedan trabajar sobre un conjunto de archivos sin estorbarse unos a otros, incluso pudiendo hacer cambios concurrentes sobre un mismo archivo, o trabajando a la par en dos posibles versiones diferentes del producto (digamos una versión dedicada a nuevas características y otra dedicada a corregir errores de una versión anterior).

Básicamente un versionador funciona de la siguiente manera: 1. Se tiene un repositorio origen desde el cual el colaborador puede sacar una copia para trabajar localmente (working copy). A este proceso se le llama checkout o clone dependiendo del tipo de versionador que uses. 2. Una vez con su working copy, el colaborador trabaja localmente con los archivos, los modifica, hace sus pruebas, etcétera. 3. Cuando el colaborador tiene listos sus cambios para compartirlos con el resto del equipo, los sube al repositorio origen. A este proceso se le suele llamar commit (o checkin o push, dependiendo el versionador del que estemos hablando). Si el colaborador no tiene permisos de escritura sobre el repositorio origen, entonces deberá solicitarlo a otro que sí tenga permisos, enviándole sus cambios por algún medio. 4. Al subir los cambios al repositorio origen, es posible que el versionador requiera hacer un merge para integrar los cambios hechos por distintos colaboradores. También se realiza un merge cuando el colaborador ya ha hecho modificaciones a su copia local, y decide actualizarla con los cambios más recientes de la versión origen (operación llamada pull, update o fetch). Un buen versionador hace los merge de forma inteligente para acomodar los cambios de todos los colaboradores. Sólo en caso de conflictos que no sabe como resolver, avisará al colaborador en cuestión de que es imposible hacer el merge, pidiéndole que resuelva el conflicto (posiblemente esto requiera que ambos colaboradores que entraron en conflicto se pongan de acuerdo para evitar pérdidas en los cambios particulares de cada uno). Muy escuetamente, este es el proceso que se sigue con un versionador. En versionadores centralizados como CVS o SVN, no queda otra opción mas que utilizar un medio externo (como el correo electrónico) para en-

¿Por qué usar un versionador?

• Porque nadie es perfecto y nadie escribe código perfecto al primer intento (y quien diga que sí miente o no hace suficientes pruebas), por lo que es necesario mantener un historial del código para que, al ir evolucionando el trabajo, se pueda saber exactamente quién hizo cambios que introdujeron errores, y cuándo los hizo, y más importante aún qué cambios fueron. Y hacer esto sin un versionador equivale a mantener tanta información como antes la mantenía el registro civil de la federeación, con innumerables carpetas y documentos insondeables. • Porque organizar un equipo de más de un colaborador implica acordar no solamente quién hará qué cosas, sino que muchas veces es necesario que varios hagan cambios sobre el mismo conjunto de archivos, y hacer esto sin un versionador equivale a no tener semáforos en las avenidas. • Porque una vez que un proyecto tenga una versión liberada en producción y esté en uso constante por una comunidad creciente de usuarios, requerirá de mantenimiento, corrección de defectos, nuevas versiones y hacerlo sin un versionador provocará un caos. 52

Este artículo es una versión editada del artículo en línea “Versionando con Git y Github - Parte 1” disponible en http://bit.ly/sg33r2 y ha sido publicado con el permiso del autor.

¿Centralizado o distribuido?

Los sistemas de control de versiones se dividen en dos tipos: centralizados y distribuidos. A continuación se enlistan las características principales de cada uno. Centralizado. • Un solo servidor contiene el repositorio con el código origen, y el historial de cambios. • Los cambios se transmiten entre servidor-clientes vía archivos cambiados. • Sólo el servidor central se puede considerar una fuente fidedigna del código y sus versiones. • Luego de un checkout, el proceso es: Update/Merge local -> Commit/Merge remoto, o si no se tienen permisos de escritura, enviar un archivo con las diferencias (diff) a los encargados y estos aplican un patch con los cambios y luego hacen Commit/Merge. • Se permite manejo de branches en el servidor, pero el merge entre las ramas y el tronco puede ser problemático. Distribuido. • Cada usuario que clone cierto servidor origen tiene su propio repositorio con el código y su historial. Además cada repositorio así generado se convierte en potencia en un nuevo servidor para que otros usuarios clonen. • Los cambios se transmiten entre repositorios origen-destino vía cambios puntuales (mucho menos información transmitida, control más fino, espacio en disco menor). • Cada repositorio clonado del origen es en sí mismo una fuente fidedigna del código y sus versiones. • Luego de un clone, el proceso es: Fetch/Merge local -> Add/Commit/Merge local Push/Merge remoto. O si no se tienen permisos de escritura, pull request, y los encargados del repositorio remoto deberán hacer el fetch/merge correspondiente con el repositorio que aquí llamamos local. • Cada repositorio puede tener sus branches, y el proceso de merge entre las ramas y el tronco es lineal y sencillo. A pesar de que los sistemas distribuidos parecen tener más ventajas, no por ello hay que descartar por completo a los sistemas centralizados ya que dependiendo de la situación puede ser más conveniente uno u otro. Los versionadores centralizados siguen siendo muy utilizados en organizaciones donde el software es modificado por un equipo cuyos miembros se pueden ver físicamente, trabajan dentro de las mismas instalaciones y tienen fácil, rápido y seguro acceso al servidor central. Por otro lado, en organizaciones donde los miembros se encuentran dispersos en distintos lugares del mundo, tal como típicamente sucede con los proyectos de software libre, entonces los versionadores distribuidos son una solución mucho más conveniente. Entre los ejemplos de versionadores centralizados más populares tenemos a CVS y Subversion. Por su parte, entre los versionadores distribuidos destacan Git, Mercurial y Bazaar. En un artículo siguiente compartiré un tutorial para iniciarse en el uso de git. .BIO Javier Novoa es ingeniero en sistemas con maestría en ciencias de la computación con preferencia por la administración de servidores GNU/Linux y el desarrollo en Python/PHP/Java/C++. Radica en la Ciudad de México y es fanático de la literatura fantástica, la astronomía amateur, el ajedrez y la música rock. jstitch@gmail.com @JaviStitch.

.TECNOLOGÍA Gadgets

SONY

NEX-C3 Como parte de la actualización a su línea de cámaras Alpha, Sony lanza la NEX-C3, su cámara más compacta y ligera con lentes intercambiables. De hecho, la NEX-C3 presume ser la cámara más ligera del mundo con esta capacidad, pesando tan solo 225 gramos. La NEX-C3 cuenta con un nuevo sensor CMOS Exmor APS HD con filtros de colores primarios RGB y resolución efectiva de 16.2 megapixeles, función sweep panorama en 2D y 3D, detección de rostros y smile shutter, entre otras capacidades. Si alguna vez habías querido tener un equipo tipo reflex pero que no fuera tan grande ni pesado, te recomendamos considerar la NEX-C3. Y si el color rosa no es lo tuyo, no te preocupes, también puedes encontrarla en plateado y negro.

EMOTIV

EPOC neuroheadset La empresa Emotiv ha desarrollado una interfaz para interacción humano computadora que consiste en una especie de auricular con múltiples sensores alrededor de la cabeza, el cual sintoniza la actividad cerebral, de tal forma que puede detectar pensamientos, sentimientos y expresiones que se pueden transmitir de forma inalámbrica como comandos a una computadora. Los asistentes al Campus Party México tuvieron oportunidad de interactuar con el EPOC y quedaron asombrados porque … es real, no hay más que decir. La edición para usuario final tiene un precio de $299 dólares y la versión para desarrolladores que incluye el SDK para crear aplicaciones cuesta $500 dólares. ¿Estás listo para crear esas aplicaciones controladas por la mente?

MOTOROLA, SAMSUNG, TOSHIBA, ASUS, SONY

Tabletas Android

No es ningún secreto que el iPad es como el “Pan Bimbo” de las tabletas, básicamente definiendo esta categoría. Sin embargo, las tabletas basadas en Android empiezan a llegar al mercado y buscarán atraer a consumidores de todo tipo de gustos y presupuestos. Antes de este verano ya teníamos algunas como la Motorola Xoom y la Samsung Galaxy Tab (la cual recientemente fue actualizada), pero ahora también contamos con la Toshiba Thrive (que presume puertos HDMI y USB además de lector de tarjetas SD), la Asus Eee Pad Transformer (con su teclado removible), y Sony con sus tabletas S1 y S2 (aunque parece que solo la S1 llegará a México). Si llevas tiempo esperando al momento adecuado para adquirir una tableta basada en Android, ahora es el momento. 54

Directorio Adobe Camp México 2011

Pág. 41

http://www.adobecamp.com.mx

Agile Conference México 2011

Pág. 19

http://agileconf.com.mx

Alpha Consultoría

Pág. 53

http://www.alpha-consultoria.com

Embarcadero Technologies

Pág. 09

http://www.embarcadero.com

Extend Solutions

Pág. 15

http://www.extend.com.mx

Gartner

Pág. 3F

http://www.gartner.com/mx/econit

ProNatura

Pág. 4F

http://www.neutralizate.com

Qualtop

Pág. 37

http://www.qualtop.com

Reach Core - RC Timbre

Pág. 49

http://www.reachore.com

SG Campus

Pág. 33

http://www.sgcampus.com.mx

TENEMOS UN ESPACIO RESERVADO PARA TI SG se distribuye de manera impresa en la República Mexicana, y de manera digital llega a más de 25mil lectores de habla hispana. El anuncio en la revista digital cuenta con hiperliga directa a tu sitio web, lo que te dará la oportunidad de acercarte a nuevos clientes. “Es una gran oportunidad participar con Software Guru, pues comprobamos que es un medio efectivo.” -Novalys Latinoamérica Contáctanos en el (55) 5239.5502 o en publicidad@sg.com.mx

.CARRERA

La Inteligencia Emocional clave para el desempeño sobresaliente ››Por Ricardo Rangel

n un ambiente laboral cada vez más competitivo, es evidente que los profesionistas debemos prepararnos mejor para enfrentar los retos. Esta preparación no solamente consiste en teoría y práctica, ya que hay otros factores que influyen en un buen desempeño. Según el Dr. Daniel Goleman, el factor determinante para que un profesionista alcance el éxito en un trabajo no es el Coeficiente Intelectual (CI) como se ha creído tradicionalmente, sino un tipo de Inteligencia diferente y más importante, la inteligencia emocional (IE).

¿Que buscan las empresas?

En los últimos años las empresas se han visto obligadas a cambiar para tratar de adaptarse a los tiempos tan vertiginosos que estamos viviendo en el ámbito laboral. Hoy en día nadie tiene el empleo asegurado. Ya no es posible brindar nuestra lealtad a una compañía con la esperanza de ser recompensado, hay que ser capaz de integrar un equipo, pero también estar listo para pasar a otra cosa y ser autosuficiente. A medida que las organizaciones se encogen en sucesivas oleadas de reducción de personal, las personas que quedan, cargan con más responsabilidad y son más visibles. Si antes un empleado de nivel medio podía disimular fácilmente un temperamento irritable o tímido, ahora se notan más que nunca aptitudes tales como el control de las emociones, el manejar bien los enfrentamientos, el trabajo de equipo y liderazgo.

Pericia y aptitudes

La pericia es una combinación de conocimiento y la habilidad que adquirimos con la práctica; la pericia es una aptitud básica. Hay que tenerla para obtener un empleo y ejecutar el trabajo, pero lo que determina el desempeño no es la pericia, sino la manera de hacerlo. Es aquí donde entran en juego aptitudes como empatía, adaptabilidad, espiritú de colaboración, habilidad de comunicación y de negociación. La idea es traducir nuestra pericia en algo comercializable, algo que se destaque. Otra aptitud imprescindible dentro del área de TI es la capacidad de escuchar. Un profesional de TI sin esta habilidad podría terminar construyendo algo diferente o innecesario de lo que realmente necesitaba el cliente. Usualmente los profesionales de TI carentes de esta habilidad se complican la vida por no saber obtener y simplificar los deseos del cliente, sin mencionar que dan la sensación de estar completamente desconectados del proyecto.

Inteligencia emocional

El conjunto de estas aptitudes, que llevan a un desempeño laboral superior es lo que se conoce como “Inteligencia Emocional”. La inteligencia emocional (IE) no significa ser simpático, sino saber enfrentar sin rodeos a los problemas y a las personas. Esto no significa que tengamos que pasar por encima de los demás para lograr algo, todo lo contrario, significa saber manejar adecuadamente los sentimientos de tal modo que podamos expresarlos adecuadamente y con efectividad.

La IE determina nuestro potencial para aprender las habilidades prácticas que se basan en sus cinco elementos: conocimiento de uno mismo, motivación, autorregulación, empatía y destreza para las relaciones. Cuanto más complejo es el trabajo, mas importante es la inteligencia emocional, aunque solo sea porque la deficiencia en estas facultades puede dificultar la aplicación de la pericia técnica.

La IE en hombres y mujeres

¿Cuantas veces no hemos escuchado que las mujeres son “más inteligentes” o que los hombres “son más capaces”? La realidad es que cada persona tiene un perfil de puntos débiles y fuertes que puede ser útil o insuficiente dependiendo de la tarea a realizar, independientemente del sexo al que pertenezca. Sin embargo si hay algunas cosas que caracterizan mejor a las mujeres y a los hombres en el ámbito laboral. Por lo regular, las mujeres tienen mayor conciencia de sus emociones, demuestran más empatía y son más aptas para las relaciones personales. Los hombres por su parte son más optimistas y seguros de sí mismos, se adaptan con más facilidad a las circunstancias y manejan mejor el estrés.

Tips adicionales

Además de todo lo antes mencionado, existen otros factores importantes que nos permitirán sobresalir en el trabajo como es el mantenerse actualizado, hacer respaldos de nuestra información importantes con el fin de prevenir desastres, el tener ordenados nuestros documentos, herramientas y archivos así como llevar un control de todo aquello con lo que estemos trabajando. Finalmente, debemos prestar atención a todas aquellas oportunidades de aprendizaje que se nos presenten en cada día con el fin de superarnos.

Conclusión

Como profesionales de TI, debemos darnos cuenta que no todo son habilidades técnicas. Hay otros aspectos muy importantes que debemos tomar en cuenta para desempeñarnos eficazmente en nuestro trabajo y no solo eso, sino además sobresalir. La inteligencia emocional ha cobrado gran importancia en el ámbito laboral en los últimos años. La buena noticia es que la IE puede ser aprendida y afinada.

Referencias [1] D. Goleman. La Inteligencia Emocional en la Empresa. Ed. Vergara.

.BIO Ricardo Rangel Ramírez es Licenciado en Informática por la Universidad de Ecatepec. Ha desarrollado Sistemas de Información para diferentes empresas, tanto de escritorio como de entorno web. Consultor en proyectos independientes, actualmente colabora en el Departamento de Sistemas de Stanhome de México. riccardorangel@hotmail.com