SG39 (Febrero-Abril 2013) by Revista Software Guru

Inversiﾃｳn para Startups pag. 10

Casos de Uso pag. 42

Desarrollo Dirigido por Ontologﾃｭas pag. 48

NO.

Tutorial Notiicaciones

Push en WP8

CONOCIMIENTO EN PRﾃ，TICA

Project Management Moderno

CERTIFICACIONES Y NORMAS Mﾃｩxico, $65.00

www.sg.com.mx |

Especial

Software Guru

Febrero-Abril 2013 www.sg.com.mx

www.sg.com.mx |

Software Guru

CONOCIMIENTO EN PRÁCTICA

PÁG.

.CONTENIDO

Febrero-Abril 2013 | www.sg.com.mx

En Portada Certiicaciones, Normas y Modelos de TI

Gracias a las normas y modelos de TI, podemos ser capaces de identificar los puntos fuertes que debemos explotar como individuos y como empresas para desarrollar proyectos de gran alcance, así como también detectar las debilidades que nos pueden frenar la adaptación de los cambios del mercado, reducir la calidad. Conoce las tendencias y recomendaciones de este importante tema.

Especial Project Management Moderno Ideologías renovadas en el horizonte

Por Vanessa Amaya Estimación Empírica de Proyectos con Planning Poker 17 Por Hector Cuesta-Arvizu y Sergio Ruiz-Castilla

Gestión de Equipos con el Uso de agilidad

Por Pablo Cáceres Ferreira

Columnas Tejiendo nuestra red

Por Hanna Oktaba

Tendencias en Software

Por Luis Daniel Soto

Columna Invitada

Por Aarón Moreno

Código Innovare

Por Karen Mariel Nájera Hernández

Programar es un modo de vida Por Gunnar Wolf

.CONTENIDO

PÁG.

Herramientas y Novedades

Lo que viene

Tutorial Windows Phone

Por Amin Espinoza

Fundamentos Como distinguir entre un riesgo y un problema

Por Iván Rivera González

Carrera Escala para determinar el nivel de un profesionista de TI

Por Pedro Galván

En Cada Número

Software Guru

Por Humberto Cervantes

Por Efraín Cordero

Prueba de Software Hablando de pruebas de software, ¿debo certiicar procesos, personas o productos?

Por Berenice Ruiz Eguino

Procesos Aceptando ¿o refutando? nuestras creencias -- experimentación en ingeniería del software Por Omar Sánchez

www.sg.com.mx |

Prácticas

Calidad Casos y Cosas de Casos de Uso

Noticias

Por Celeste North

Arquitectura Certiicaciones en arquitectura de software

Emprendiendo Opciones de inversión para Startups en México

Editorial

.EDITORIAL BIENVENIDA

. “Ya somos vistos como parte del negocio en lugar de vernos como un área de apoyo al negocio.”

El Ineludible Protagonismo

as tecnologías de información se han convertido en parte fundamental de cualquier empresa. Ya somos vistos como parte del negocio en lugar de vernos como un área de apoyo al negocio. Y es precisamente esta condición de protagonistas la que nos exige cada vez más garantías, ya que el hecho de tener los “relectores” encima todo el tiempo nos lleva a tener que ser más cuidadosos, comprometidos y responsables con nuestro trabajo. Entre los elementos que dan mayor sustento a estas garantías están las certiicaciones, normas y modelos de calidad, es por ello que constituyen el enfoque principal de este número de SG. Adicionalmente, consideramos que la disciplina de Project Management está evolucionando para ajustarse al contexto del desarrollo de software moderno: ágil, iterativo y con equipos distribuidos. Es por ello que hemos incluido una sección especial sobre prácticas modernas de Project Management. Te pedimos una gran disculpa por el retraso de este número de SG. Entre SG Virtual y el relanzamiento de SG Talento, saturamos la capacidad de ejecución de nuestro pequeño equipo. Fue así que decidimos “congelar” el desarrollo de este número hasta que pudieramos prestarle la atención que merece. Quedamos bastante satisfechos con el resultado y esperamos que tú también. Gracias por seguir siendo parte de nuestra comunidad.

››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 Karina Saad 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 Aarón Moreno, Amin Espinoza, Berenice Ruiz Eguino, Carlos Gutiérrez, Celeste North, Efraín Cordero, Elsa Ramírez Hernández, Fernando Rueda Téllez, Gabriel Almeida, Gunnar Wolf, Héctor Cuesta-Arvizu, Héctor Santa María, Humberto Cervantes, Iván Rivera González, Karen Mariel Nájera , Masa K Maeda, Rodrigo Torres Garibay y Sergio Ruiz-Castilla

Ventas Claudia Perea / Alianzas Daniel Velazquez / Webmaster Karen Rodríguez / Luis Sánchez / SGCampus Ana Karen Rosales Contacto info@sg.com.mx SG Software Guru es una publicación trimestral editada por Brainworx, S.A. de C.V., San Francisco 238 Altos. Col. Del Valle. 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 marzo de 2013 en EDAMSA Impresiones S.A. de C.V.

.NOTICIAS

.Hackathon: Desarrollando América Latina (DAL 2012)

.SAP Forum: Acelerando la Innovación en México El pasado 6 y 7 de Febrero se llevó a cabo el SAP Forum en Ciudad de México. Bill McDermott , CO-CEO de SAP motivó a la audiencia hablando sobre las ventajas que tiene nuestro país, entre las que destacó: la energía, la pasión y el crecimiento de profesionistas de TI, incluso superando a Alemania en graduados de ingeniería. El ejecutivo destacó que México es la mejor subsidiaria de SAP en el mundo y que la empresa de origen alemán está apostando fuertemente al cómputo móvil empresarial para el 2013. Foto cortesía de SAP México.

El 3 y 4 de diciembre del 2012 en la Ciudad de México se realizó el primer Hackathon de OpenData de América Latina cuyo objetivo fue generar soluciones para problemas como salud, educación, seguridad entre otros. El evento se realizó simultáneamente en Argentina, Brasil, Chile, México, Perú y Uruguay. En México fue coordinado por Fundar, Centro de Análisis e Investigación, y Citivox, con el apoyo del CIDE y del IFAI. Esfuerzos como este logran comprobar que los datos de los gobiernos pueden ser accesibles y aprovechables para todos los ciudadanos. Fotografía cortesía de fundar.org.mx

. BugCON Security

.Demo Day 500 Mexico City

La aceleradora de startups 500 Mexico City presentó el pasado 31 de Enero a las 10 compañías que formaron parte de su programa de aceleración. En esta ocasión encontramos compañías como Rubberit la cual ofrece un servicio de suscripción de condones o Yaxi que con solo apretar un botón de su app te mandan un taxi seguro a donde te encuentres. 500 Mexico City es el nuevo nombre con que se le conoce a la irma de inversión Mexican.VC, al día de hoy han realizado inversión en 21 compañías mexicanas.

.CANISOFT El pasado 24 de enero se realizó la primera reunión de la Camara Nacional de la Industria del Software (CANISOFT) la cual reunió presencialmente alrededor de 100 representantes de empresas desarrolladoras de software a las cuales se sumaron más empresarios que asistieron a la reunión de manera virtual. La reunión tuvo como objetivo convocar al registro y envío de la carta de intención para poder tramitar la creación de este Organismo Promotor. Este esfuerzo no comenzó en la reunión, para sensibilizar a la audiencia, se habló de todos los esfuerzos tanto de difusión, alianzas y trámites que han realizado los emprendedores detrás de la iniciativa. Jaime Juárez del Ángel, Presidente de CANISOFT invitó a todos los fabricantes de software a unirse para poder llegar a la meta y poder hacer este Organismo una realidad. http://canisoft.org/ Para mayor información, noticias al día y actualizaciones de la industria visita: www.sg.com.mx

www.sg.com.mx |

Los pasados 13, 14 y 15 de febrero se llevó a cabo la 5ª edición de BugCON Security Conference: Safety is just a myth…!. Un evento altamente técnico, que en un ambiente sin censura se ha posicionado como uno de los foros más relevantes para los profesionales e investigadores en seguridad informática. En esta edición BugCON reunió a más de treinta ponentes e instructores de México, Colombia, Argentina y Luxemburgo, los cuales durante tres días compartieron sus conocimientos yexperiencias con más de 600 asistentes de todo el país. BugCON nuevamente hizo hincapié en el alto nivel técnico de los contenidos, no es nada extraño asistir y mirar a los ponentes con diapositivas llenas de código ensamblador, algunos mostrando herramientas que ellos mismos han desarrollado o estructurando complejos modelos matemáticos que pueden ser aplicados a la gestión de los riesgos de TI. www.bugcon.org

Software Guru

Conference: Safety is just a myth…!

.COLUMNA TEJIENDO NUESTRA RED

MoProSoft, ISO/IEC 29110 y KUALI-BEH REFLEXIONES Y NOTICIAS MoProSoft. Reflexión de aniversario

La Dra. Hanna Oktaba es profesora de la UNAM, miembro del IPRC, y directora técnica del proyecto COMPATISOFT. hanna.oktaba@ ciencias.unam.mx

caban de cumplirse 10 años de la entrega del modelo de procesos MoProSoft a la Secretaría de Economía como resultado de uno de los primeros proyectos del programa PROSOFT. Todavía no comprendo como 11 personas, de los cuales 9 solo pudieron dedicar al proyecto su tiempo libre, logramos en 4 meses generar un modelo de procesos completamente original e innovador. Estructurado en tres capas, la de Alta Dirección con el proceso de Gestión de Negocio, la de Gerencia – con los procesos de Gestión de Procesos, Recursos y Proyectos y la capa de Operación con Administración de Proyectos Especíicos y Desarrollo y Mantenimiento de Software. Cada proceso tuvo a su editor responsable y, como curiosidad, les puedo comentar que Mara Ruvalcaba, la Directora de Operaciones de SG, fue responsable por el proceso de Gestión de Negocio, uno de los más apreciados por los directivos de las empresas. Les recuerdo que los documentos originales de MoProSoft se pueden descargar de www.comunidadmoprosoft.org.mx ¿Qué le cambiaría después de 10 años al modelo? – en la estructura no mucho, tal vez separaría mantenimiento del desarrollo. Sin embargo, en los detalles hay muchas cosas que se podrían simpliicar y, sobre todo, cambiar la redacción para que se pueda interpretar fácilmente con las prácticas de los métodos ágiles. Curiosamente el valor de MoProSoft en México no fue muy comprendido y reconocido a pesar del apoyo que el mismo programa de PROSOFT otorgó a las empresas para adoptarlo. El excelente relato de la historia típica de la adopción fracasada se publicó en el artículo de Alfredo Lozada en el número anterior de SG. A nivel internacional MoProSoft fue reconocido como una propuesta muy valiosa, sobre todo para las PyMEs. Ultrasist es el ejemplo de una empresa que adoptó MoProSoft de manera muy exitosa. Desde 2003 empezaron a incorporarlo, iniciando por el plan estratégico de Gestión de Negocios, y hoy en día son una empresa sólida. Han quintuplicado su operación y fueron evaluados por segunda ocasión nivel 5 de CMMI. Sospecho que una de las razones del éxito de Ultrasist es que en la empresa trabajan dos de las creadoras de MoProSoft: María Julia Orozco y Claudia Alquicira, que llevan en la sangre la correcta interpretación del modelo. Pero creo que la otra razón, igual de importante, es la constancia del esfuerzo de toda la organización y la verdadera (medible) mejora continua, basada en la Gestión de Procesos.

ISO/IEC 29110. Reflexión y noticia Ha pasado año y medio de la publicación como estándar internacional del ISO/IEC 29110 5-1-2 Peril básico, que contiene los procesos de la capa de Operación de MoPro-

Soft ligeramente modiicados. En México hay muy poco conocimiento de esto, ya que las instituciones correspondientes tales como la Dirección General de Normas, CANIETI o NYCE no han difundido dicho estándar. En contraste, les puedo comentar que Brasil desde hace un año tiene un proyecto muy intenso para la adopción del Peril básico, que incluye la capacitación de los consultores y la deinición de la certiicación reconocida internacionalmente. Tailandia, Perú, España y Canadá también están avanzando en la materia. El año pasado hicimos un análisis de la brecha entre los procesos de Operación de MoProSoft nivel 2 y Peril básico (ver la referencia 1), que realmente es muy pequeña. Esto podría utilizarse para que las empresas mexicanas obtengan fácilmente reconocimiento internacional del cumplimiento con el Peril básico. Pero para darles esta ventaja competitiva a las empresas, que han hecho esfuerzos adoptando MoProSoft nivel 2, se necesita una estrategia y un plan de acción, los cuales al día de hoy no existen. El grupo WG24 (donde se acuerda el estándar 29110) tuvo reunión de trabajo en Buenos Aires, Argentina en noviembre del año pasado. La delegación mexicana presentó el Peril Intermedio (una versión mejorada de los procesos de la capa de Gerencia de MoProSoft) para su última revisión interna antes de ser enviado a las revisiones y votaciones formales por los países. Estábamos a punto de presentar la propuesta del Peril Avanzado (basado en Gestión de Negocio), cuando durante una foto del grupo, nos robaron 13 laptops y 4 mochilas (incluida la mía). Con eso el trabajo del WG24 quedó suspendido, porque nos quedamos sin herramientas y pasmados.

KUALI-BEH y ESSENCE. Noticia La “boda” ya entre KUALI-BEH y ESENCE se consumó. El 12 de noviembre fue enviada la propuesta de ESSENCE con KUALI-BEH integrado como su extensión a OMG. Ahora faltaba la aprobación de su parte para convertirlo en el estándar. El 12 de diciembre se hizo la votación en la reunión de San Francisco. Yo no pude asistir a esta reunión, pero el que estuvo fue mi alumno de doctorado Miguel Ehécatl Morales Trujillo. A continuación está su relato, narrado en forma inversa (de lo más reciente hacia atrás): “Lo que parecía un viaje de trámite a California, en donde ESSENCE-BEH sería votada para ser adoptada como especiicación de OMG, resultó en algo más complejo; aunque nadie había dicho que sería fácil. El trayecto del centro de San Francisco al aeropuerto sirvió para asimilar lo sucedido. A bordo del transporte subterraneo (BART), caí en cuenta que la batalla era más amplia y con más obstáculos de los ya conocidos. Mientras caminábamos hacia el comedor del hotel donde se realizó la reunión Ivar Jacobson se acercó y me

››“CURIOSAMENTE EL VALOR DE

MOPROSOFT EN MÉXICO

>> Por Hanna Oktaba

Referencias [1] Miguel Morales Trujillo, Teresa Ventura, Hanna Oktaba and Rodrigo Torres, “From MoProSoft Level 2 to ISO/IEC 29110 Basic Proile: Bridging the Gap”, el artículo fue aceptado para ser publicado en el CLEI Electronic Journal en abril de 2013.

www.sg.com.mx |

dijo: “Miguel, the important thing is that there were only two votes against”. Esos dos votos en contra fueron emitidos por Armstrong Process Group —empresa que hizo su aparición hasta el día de la votación y de la que previamente no teníamos noticia, pero curiosamente fue la primera en votar— y por IBM, representado por una persona muy cercana al desarrollo de FACESEM, que abandonó la sesión inmediatamente después de votar. El proceso de la OMG realiza la votación en dos etapas: V2V y Voting for Adoption. El V2V en palabras simples es una votación para decidir si se vota, aunque suene absurdo así está establecido en el protocolo de OMG. Es necesario que en el V2V se obtenga por lo menos 75% de los votos a favor, para dar paso al Voting for Adoption. De las 23 compañías con derecho a voto estuvimos presentes 15 en la reunión. De éstas, once votamos a favor, dos en contra, y dos abstenciones. El resultado fue una aprobación de 73%, insuiciente para realizar el Voting for Adoption. El acuerdo al que se llegó es que el Voting for Adoption se realizará en la próxima reunión en Reston, VA el 20 de Marzo de 2013. Previo al comienzo de la sesión, Ivar me dijo “Miguel, this is exciting because it is not for sure, soon we will know”. Y así fue, no era seguro y tendremos que esperar tres meses para concretar este gran paso. Al salir de México tenía la impresión de que el camino aún tendría algunos escollos que sortear, no esperaba uno tan contundente, pero el ánimo no decae, lo aprendido hasta ahora es suiciente motivación para seguir por la misma ruta.” Tres meses entonces para la “luna de miel” entre KUALI-BEH y ESSENCE. Ahora todo depende de la habilidad negociadora de Ivar Jacobson con los que no asistieron a la votación.

Software Guru

NO FUE MUY COMPRENDIDO.”

.HERRAMIENTAS Y TECNOLOGÍAS LO QUE VIENE

Amazon Redshift Data warehouse as-a-service

Amazon web services anunció la disponibilidad de Redshift, un servicio de data warehouse en la nube diseñado para manejar grandes cantidades de datos (estamos hablando de cientos de gigabytes a incluso varios petabytes). Dado que Redshift se basa en tecnología de RDBMS y utiliza SQL como lenguaje de sentencias, es compatible con herramientas existentes de analítica y BI. Adicionalmente, varios proveedores como Microstrategy, SAP, Pentaho y Tableau conirmaron alianzas con Redshift para ayudar a las empresas a integrar Redshift con su infraestructura de TI existente. De acuerdo con Amazon, un terabyte de datos en Redshift tendrá un costo aproximado de $1,000 dólares, lo cual es un precio bastante atractivo comparado con soluciones tradicionales de data warehouse. http://aws.amazon.com/redshift

Windows Azure Mobile Services es un servicio de backend en la nube diseñado para aplicaciones de nueva generación. Su objetivo es facilitar el manejo de datos estructurados en la nube que puedan ser accedidos desde aplicaciones que puedan estar corriendo ya sea en computadoras personales, smartphones, smart TVs u otro tipo de dispositivos de cómputo. Entre las ventajas de usar un servicio como Azure Mobile Services está el poder apoyarse en servicios como autenticación o notiicaciones. En el momento de su lanzamiento en agosto del 2012, Azure Mobile Services solamente soportaba aplicaciones Windows 8, lo cual era un gran limitante. Sin embargo, desde entonces ha ido agregando soporte a más plataformas y actualmente ya se puede utilizar también para aplicaciones iOS y Android, lo cual le da una perspectiva mucho más atractiva. http://www.windowsazure.com/en-us/develop/mobile

Hudson Se gradúa de la incubación

Agrega soporte para Android

El servidor de integración continua Hudson inalmente se graduó de su estatus de incubación en la Fundación Eclipse y liberó su versión 3.0, la primer versión para producción que libera después de haber sido “adoptado” por la Fundación Eclipse. Hudson administra la generación automatizada de builds de un software. Para ello, periódicamente ejecuta tareas como: obtener el código de un proyecto, compilarlo, aplicar pruebas unitarias, integrarlo, aplicar pruebas de integración, y reportar los resultados. La integración continua es una práctica originalmente propuesta en Extreme Programming que muchos equipos ya han adoptado, independientemente de si usan XP o no. Hudson soporta una variedad de herramientas de control de versiones, entre ellas CVS, Subversion, Git y Clearcase. Además puede manejar proyectos de Ant y Maven, así como shell scripts y comandos batch en Windows. Hudson está hecho en Java y se ejecuta en un contenedor de Servlets, como por ejemplo Tomcat. http://www.eclipse.org/hudson

Xamarin liberó la versión 2.0 de su plataforma que permite desarrollar aplicaciones nativas para iOS, Android y Mac utilizando el lenguaje de programación C#. Esta versión introduce el IDE Xamarin Studio, así como un add-in para Visual Studio y el Xamarin Component Store. El add-in para Visual Studio permite que los desarrolladores de .NET pueden crear aplicaciones nativas iOS y Android desde Visual Studio. El Component Store, es una tienda en línea donde los desarrolladores pueden comprar y vender elementos como librerías, temas de diseño o controles visuales que incorporen en sus aplicaciones. http://xamarin.com 08

Azure Mobile Services

Xamarin Nuevo IDE y tienda de componentes

.COLUMNA

TENDENCIAS EN SOFTWARE

La Reinvención de la Industria de T.I. LA MUERTE DEL SERVIDOR

››“SE HA HECHO

ara una empresa mediana o grande, la noción de un servidor “único” es cosa del pasado. La imperativa es mantener decenas o cientos de servidores, pensar en “granjas de servidores” y tratar a la infraestructura de forma uniicada.

ridad que han logrado los juegos casuales en dispositivos móviles, se prevee que los volúmenes de ventas de consolas del pasado probablemente no regresen nunca.

Mini PC

Hardware dedicado

La Raspberry Pi es una computadora de $35 dólares. En el rango $40 a $70 dólares la mini-PC en USB ha estado disponible desde hace meses en el mercado, Dell empujará un concepto similar denominado “Ophelia” a un costo menor de $100 dólares en Estados Unidos. Se ha hecho realidad la era de la PC desechable, de bolsillo. Se está utilizando para llevar el cómputo a todos los lugares: es posible adquirir teclados que incluyen a la Raspberry Pi y similares. Los aficionados a la fotografía extienden sus cámaras DSLR con una pequeña computadora, accionando remotamente y transmitiendo datos al instante. Prácticamente cualquier televisión puede tener su propia PC.

La transformación de hardware es más amplia, sucede en autos, dispositivos del hogar, en infraestructura de redes, etcétera. En éstos últimos los vendedores tradicionales como Freescale, Texas Intruments y Xilinx empujan por hardware dedicado. Pero Intel con Crystal Forest planea resolver todos los problemas de procesamiento de datos. Era inevitable la “comoditización” de la tecnología.

REALIDAD LA ERA DE LA

PC DESECHABLE”.

M2M La “salud móvil” (mHealth) se reiere a dispositivos que miden una serie de variables biológicas, las almacenan y las transmiten. Estamos en un proceso de estandarización de las comunicaciones (Bluetooth Smart Ready). El número de dispositivos y parámetros de medición crecerá dramáticamente, en 5 años la colección de datos será enorme. Se moverá del dispositivo, al teléfono, a redes más amplias, se combinará con videocámaras y sensores en la ciudad. La comunicación “máquina a máquina” superará el tráico de interacciones humanas en internet (Internet of hings).

Post-PC Hacia el futuro cercano, el software empresarial continuará en su forma existente. Pero antes de 10 a 15 años será inminente la migración de soluciones a la nube, aunque hoy continúe la resistencia y lucha de mantener el poder. En el escritorio, las “apps” han aniquilado al software como modelo de negocio. El futuro del modelo de negocio son los “servicios y dispositivos” por medio de suscripciones.

Microsoft se reinventa TV Hoy existe una gran fragmentación entre el contenido en vivo y el contenido bajo demanda, acceso en web de temporadas pasadas vs. nuevas, derechos que varían mucho por cada dispositivo. Están surgiendo servicios que llevan la experiencia social a la TV, tales como Matcha, Fanhattan o Zeebox. DLNA permite la integración de contenido entre dispositivos conectados. La PC de teatro en casa ha evolucionado a nueva funcionalidad como Video Gateways (HomeBase) y amplio acceso remoto (Plex Media Center). La convergencia avanza.

9a Generación de consolas y Multi-pantallas Las gafas de Oculus Rift, así como Google Glass, sensores como Kinect o aquellos que permiten convertir cualquier supericie en interactiva, incluyendo el proyecto “Immersive Display Experience” de Microsoft son buenos ejemplos de soluciones tempranas de “Cómputo ubiquo” que facilitan aplicaciones de realidad aumentada. La consola se integra con otros dispositivos en el videojuego. Aun así, dada la popula09

La automatización total de los servidores y el acceso a la información por cualquier persona en cualquier lugar continúa siendo una ambición. En una reciente entrevista, Steve Ballmer (CEO de Microsoft) enumeró sus apuestas tecnológicas: nuevos dispositivos con interfaces naturales, la nube y el aprendizaje automatizado (machine learning). La reinvención está en proceso.

Personas En general, la forma de trabajar y aprender ha cambiado. Las herramientas sociales permiten que ahora más que educación a distancia, se pueda localizar al talento que resuelva problemas especíicos. El acceso a la tecnología es generalizado, he escuchado la frase: “la gente de negocios es el siguiente departamento de sistemas”. Conforme los servicios de software sean verdaderamente inteligentes, esto podría suceder. En el pasado mi columna ha tratado sobre posibles rumbos de la tecnología, cambios graduales. En ocasiones, al abrir los ojos, no es evidente que el mundo ha cambiado tanto.

››Por Luis Daniel Soto

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

Software Guru

Software

www.sg.com.mx |

En el espacio cómputo personal, la atención ha gravitado hacia las tabletas y teléfonos inteligentes. Se estima que estos dos segmentos combinados lograron ventas por 83 millones de dólares en el 2013, mucho mayor a lo anticipado. La PC de escritorio ha evolucionado al “todo en uno”. Por su parte, la “laptop” se ha hecho ultraportátil pero no se han transformado radicalmente todavía, posiblemente pronto veamos una verdadera reinvención.

.EMPRESAS EMPRENDIENDO

Opciones de Inversión para Startups

››Por Celeste North

na de las preguntas más comunes que se hace un nuevo emprendedor en nuestra región es: “¿dónde puedo encontrar opciones de inversión y cómo elegir la mejor opción?” (ok, son dos preguntas pero entienden a qué me reiero). Aunque hay diversas opciones para fondear un startup (inanciamiento, fondos gubernamentales, etc.), en este artículo me enfocaré en las opciones de inversión en modalidad de capital de riesgo. La inversión de capital de riesgo básicamente consiste en que un inversionista adquiere una parte de tu empresa con miras a que el valor de ésta aumente, y obtener una ganancia en un futuro al vender su parte (ya sea que la empresa sea comprada por un tercero, reciba una nueva ronda de inversión, o comience a cotizar en la bolsa de valores). Dependiendo de la etapa en la que te encuentres, puedes acceder a distintos inversionistas independientes o fondos dedicados especíicamente a esto. En el caso de capital semilla (inversiones que van desde $50 hasta $500 mil dólares) en México hemos visto un lorecimiento de opciones en los últimos dos años, muchos en modalidad de aceleradoras de negocios. Comparto a continuación una breve reseña de los principales:

500 Startups Mx (antes Mexican VC) http://500.vc/mexicocity La subsidiaria en México de la aceleradora internacional 500 Startups. Manejan el mismo esquema con todos los startups: $25 mil dólares en capital + un programa de mentoría por 4 meses, a cambio de un 10% de participación. Cuentan con oicinas en la Ciudad de México y una red de mentores nacionales e internacionales. Inicia con una semana de inmersión en Silicon Valley para arrancar el programa y concluyen con un Demo Day para conectarte con inversionistas para tu siguiente etapa.

Wayra - http://mx.wayra.org La aceleradora de Telefónica. Invierten entre $30 y $70 mil dólares de acuerdo a la valoración que se haga de tu empresa, en relación a esto se determina el porcentaje que adquieren. Ofrecen un espacio de trabajo, soporte tecnológico, mentores y acercamiento a una red de inversionistas. Opera en diversas ciudades tales como Cd. de México, Bogotá, Lima, Buenos Aires, Santiago, Sao Paulo, Barcelona y Madrid entre otras.

interesante es que cuentan con dos modalidades para entrar al programa: cesión del 10% de participación o bien una cuota única de inscripción de $6 mil pesos y una cuota mensual de $28 mil pesos.

Fondo de Coinversión de Capital Semilla Startup México http://nafin.com Impulsado por NAFIN, este fondo invierte en empresas de tecnología de alto potencial en un rango de los 100 mil a los 5 millones de pesos. Los requisitos son sencillos: debes tener menos de un año operando, todavía no estar en punto de equilibrio y contar con un inversionista o los recursos propios para la coinversión. Ellos igualan la cantidad por el mismo porcentaje que el otro inversionista.

Angel Ventures México - http://angelventuresmexico.com Para proyectos en una etapa más madura, una buena opción es Angel Ventures. Ellos invierten entre 2 y 20 millones de pesos y el porcentaje de participación depende de cada caso. Aunque no cuentan con un programa de aceleración, apoyan con asesorías en distintas áreas. Estas son solo algunas de las opciones a las que te puedes acercar en búsqueda de inversión. De acuerdo a la etapa en la que te encuentres, es muy importante que consideres el nivel de acompañamiento que necesitas. Para muchos startups, esto puede ser incluso más valioso que el capital en sí. Evalúa todas tus opciones y considera fechas de inicio para programas de aceleración. Si quieres conocer más opciones, te recomiendo te acerques directamente a NAFIN o a la AMEXCAP (Asociación Mexicana de Capital Privado), estas organizaciones cuentan con más información sobre los fondos de inversión a los que puedes acceder. Sea cuál sea la decisión que tomes, un consejo básico para todo emprendedor es postergar lo más posible la inclusión de un inversionista a tu empresa. Entre más logres entender de tu mercado antes de recibir inversión, mejor será el aprovechamiento que le des a estos recursos cuando sea momento de crecer tu producto o servicio. .BIO

Venture Institute - http://institute.vc Cuenta con una detonadora de negocios que se enfoca en startups tecnológicos y está respaldado por Venture Partners. Su programa incluye espacio de trabajo, metodología de detonación y mentores. El programa dura 15 semanas y el rango de inversión depende de cada caso. Algo 10

Celeste North (@celestenorth) es fundadora de NuFlick, plataforma de distribución de cine independiente y festivales de cine on demand enfocado en el mercado Latinoamericano. Organiza Founder Friday, un evento para fomentar el emprendimiento entre mujeres en la Ciudad de México. Es colaboradora editorial sobre temas de innovación y emprendimiento en Opinno, Emprendela y Software Guru.

www.sg.com.mx |

Software Guru

.TUTORIAL

Notificaciones y Mosaicos en

Windows Phone ››Por Amín Espinoza

in temor a equivocarme puedo decir que el principal distintivo de la plataforma Windows Phone son sus mosaicos; esos recuadros que no solo son accesos directos a aplicaciones sino que muestran información sin tener que acceder a la aplicación. En este artículo mostraré cómo implementar notiicaciones en Windows Phone. Además de considerar las notiicaciones de mosaico (tile), también mostraré como implementar notiicaciones Toast (como por ejemplo las que se muestran al recibir un mensaje SMS) y notiicaciones Raw (mensajes de texto simple).

El listado 3 muestra el código que usaremos para enviar notiicaciones Raw, que simplemente son una cadena de texto. Las notiicaciones deben enviarse como arreglos de bytes codiicados en UTF8, así que utilizaremos la clase UTF8Encoding. Más adelante detallaremos el método InsertarInformacionURLSuscritas(), que utilizaremos en los 3 tipos de push. public void InsertarInformacionRaw(string mensajeRaw) { UTF8Encoding encoding = new UTF8Encoding(); InsertarInformacionURLSuscritas(encoding.GetBytes(mensajeRaw), “raw”); } Listado 3. Envío de notificaciones Raw

El servicio de notificaciones Lo primero que haremos será crear un servicio WCF que envíe las notiicaciones. Para ello creamos un proyecto en Visual Studio de tipo “Aplicación de servicios WCF”, bautizando nuestro proyecto como Servicio Notiicación. Veremos el archivo Service1.svc.cs, podemos abrirlo y eliminar los métodos GetData() y GetDataUsingDataContract() que esencialmente funcionan sólo como ejemplos. El listado 1 muestra nuestro código inicial. Como comenté, hay tres tipos de notiicaciones: Tile, Toast y Raw. Utilizaremos un enumerador público “IntervalosDeValores” para identiicar el tipo de notiicación. También creamos un diccionario estático “URISucripción” para registrar a los teléfonos suscritos a nuestro servicio. Como llave usamos un Guid (identiicador global único) y como valor un Uri que establece un canal de comunicación entre el servicio web y el dispositivo.

El listado 4 muestra el código para insertar notiicaciones toast. Estos mensajes manejan un título y un cuerpo. Para que el mensaje tenga la estructura requerida, lo formamos como XML usando la clase XMLWriter. public void InsertaToast(string tituloToast, string mensajeToast) { MemoryStream miStream = new MemoryStream(); XmlWriter escritorXML = XmlWriter.Create(miStream); escritorXML.WriteStartDocument(); escritorXML.WriteStartElement(“wp”, “Notiication”, “WPNotiication”); escritorXML.WriteStartElement(“wp”, “Toast”, “WPNotiication”); escritorXML.WriteStartElement(“wp”, “Text1”, “WPNotiication”); escritorXML.WriteValue(tituloToast); escritorXML.WriteEndElement(); escritorXML.WriteStartElement(“wp”, “Text2”, “WPNotiication”); escritorXML.WriteValue(mensajeToast);

public enum IntervalosDeValores {

escritorXML.WriteEndElement();

TileInmediato = 1,

escritorXML.WriteEndElement();

ToastInmediato = 2,

escritorXML.WriteEndDocument();

RawInmediato = 3,

escritorXML.Flush();

}

InsertarInformacionURLSuscritas(miStream.ToArray(), “toast”); }

private static Dictionary<Guid, Uri> URISuscripcion = new Dictionary<Guid, Uri>();

Listado 4. Envío de notificaciones Toast.

Listado 1. Enumerador y diccionario

El listado 2 muestra el método para suscribir teléfonos al diccionario. public void SuscribirMiTelefono(Guid IdTelefono, string canalURI) { Uri direccionLocal = new Uri(canalURI);

El listado 5 muestra el código para enviar notiicaciones tipo “Tile”, es decir las que actualizan la información que se muestra en un mosaico. Hay tres diferentes elementos que se pueden enviar en una notiicación tile: título, imagen y contador. El procedimiento es similar al que utilizamos en nuestro método para insertar mensajes Toast.

if (URISuscripcion.ContainsKey(IdTelefono)) { URISuscripcion[IdTelefono] = direccionLocal; } else {

public void InsertaInformacionTile(string tituloTile, int contadorTile, string direccionImagenTile) { MemoryStream miStream = new MemoryStream();

URISuscripcion.Add(IdTelefono, direccionLocal); }

XmlWriter escritorXML = XmlWriter.Create(miStream); escritorXML.WriteStartDocument();

}

escritorXML.WriteStartElement(“wp”, “Notiication”, “WPNotiication”);

Listado 2. Suscribir teléfono

escritorXML.WriteStartElement(“wp”, “Tile”, “WPNotiication”);

.TUTORIAL

escritorXML.WriteStartElement(“wp”, “BackgroundImage”, “WPNotiication”); escritorXML.WriteValue(direccionImagenTile); escritorXML.WriteEndElement(); escritorXML.WriteStartElement(“wp”, “Count”, “WPNotiication”);

Habiendo implementado la lógica de nuestro web service, vamos a deinir los contratos necesarios para que los métodos puedan ser accesibles por clientes externos. El listado 7 muestra el código que debe tener la clase IService.cs para deinir los contratos de servicio correspondientes.

escritorXML.WriteValue(contadorTile); escritorXML.WriteEndElement();

using System;

escritorXML.WriteStartElement(“wp”, “Title”, “WPNotiication”);

using System.ServiceModel;

escritorXML.WriteValue(tituloTile);

namespace Servicio_Notiicacion {

escritorXML.WriteEndElement();

[ServiceContract]

escritorXML.WriteEndElement();

public interface IService1 {

escritorXML.WriteEndDocument();

[OperationContract]

escritorXML.Flush();

void SuscribirMiTelefono(Guid phoneID, string channelURI);

InsertarInformacionURLSuscritas(miStream.ToArray(), “tile”);

[OperationContract]

}

void InsertarInformacionRaw(string message);

Listado 5. Enviar información a un mosaico

[OperationContract] void InsertaInformacionTile(string tileTitle, int tileCount, string tileImageURI);

Como ya notamos anteriormente, todos los métodos terminan invocando InsertarInformacionURLSuscritas(). Este método se encarga de distribuir la información deseada hacia los dispositivos suscritos. El listado 6 muestra el código de este método. A grandes rasgos, lo que hace este método es 1) crear una solicitud de tipo HttpWebRequest, 2) agregarle el header correspondiente al tipo de notiicación, 3) escribir la información deseada y enviarla, 4) Recibir la respuesta. Esto se repite dentro de un ciclo por cada dispositivo suscrito. private static void InsertarInformacionURLSuscritas(byte[] informacionRecibida, string tipoNotiicacion) { foreach (var direccion in URISuscripcion.Values) {

[OperationContract] void InsertaToast(string ToastTitle, string ToastMessage); } } Listado 7. Contrato de servicios

Una vez hecho esto, podemos compilar nuestro proyecto y publicarlo. Luego podemos veriicar que esté accesible utilizando el cliente de pruebas WcfTestClient (C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\WcfTestClient.exe). Seleccionamos la opción “Agregar servicio” del menú Archivo y alimentamos la referencia a nuestro servicio WCF.

var solicitud = (HttpWebRequest)WebRequest.Create(direccion);

solicitud.ContentLength = informacionRecibida.Length; solicitud.Headers.Add(“X-MessageID”, Guid.NewGuid().ToString()); switch (tipoNotiicacion) { case “toast”: solicitud.Headers[“X-WindowsPhone-Target”] = “toast”; solicitud.Headers.Add(“X-NotiicationClass”,

La aplicación Windows Phone Habiendo creado nuestro servicio, ahora crearemos la app para Windows Phone. Para ello creamos una nueva solución Windows Phone en Visual Studio y agregamos la referencia al servicio WCF. Para ello damos un clic derecho sobre el proyecto y seleccionamos la opción “Agregar referencia de servicio”. En la dirección, usamos la dirección IP local de nuestra máquina y el nombre del servicio que creamos en la sección anterior. La igura 1 muestra el ejemplo de cómo se debe ver esta ventana.

((int)IntervalosDeValores.ToastInmediato).ToString()); break; case “tile”: solicitud.Headers[“X-WindowsPhone-Target”] = “token”; solicitud.Headers.Add(“X-NotiicationClass”, ((int)IntervalosDeValores.TileInmediato).ToString()); break; case “raw”: solicitud.Headers.Add(“X-NotiicationClass”, ((int)IntervalosDeValores.RawInmediato).ToString()); break; } using (var streamSolicitud = solicitud.GetRequestStream()) { streamSolicitud.Write( informacionRecibida, 0, informacionRecibida.Length); Figura 1. Agregar referencia de servicio

} var respuesta = (HttpWebResponse)solicitud.GetResponse(); } } Listado 6. Envío de solicitud

Para desplegar la información en nuestra app, en la página principal de ésta colocaremos tres cajas de texto que desplieguen la información recibida. El código para esto se ve en el listado 8.

Software Guru

solicitud.ContentType = “text/xml”;

www.sg.com.mx |

solicitud.Method = WebRequestMethods.Http.Post;

.TUTORIAL

la comunicación por medio del canal; SuscribirMiTelefonoCompleted que se dispara cuando la suscripción del teléfono al servicio de notiicaciones haya sido exitosa, el ChannelUriUpdated que se dispara cuando la dirección del canal haya sido obtenida (o actualizada); yHttpNotiicationReceived que se dispara cuando la aplicación reciba información pero sin ser formateada. El listado 10 muestra el código de este método.

</Grid> Listado 8. Cajas de texto para desplegar información

void adjuntarFuncionesManejadores() { miCanalPush.ErrorOccurred += myPushChannel_ErrorOccurred;

Pasemos ahora al código C#. Por simplicidad, pondremos en nuestro constructor el código para disparar los eventos. El listado 9 muestra el código para el constructor. Estas acciones también se podrían disparar desde el método OnNavigatedTo().

miCliente.SuscribirMiTelefonoCompleted += miCliente_SuscribirMiTelefonoCompleted; miCanalPush.ChannelUriUpdated += myPushChannel_ChannelUriUpdated; miCanalPush.HttpNotiicationReceived += myPushChannel_HttpNotiicationReceived; } Listado 10. Definición de manejadores

Guid phoneID; ServicioNotiicaciones.Service1Client miCliente = new ServicioNotiicaciones.Service1Client();

El listado 11 tiene el manejador para el evento miCanalPush.ErrorOcurred. Este simplemente muestra en pantalla el mensaje de error.

HttpNotiicationChannel miCanalPush; public MainPage() {

void myPushChannel_ErrorOccurred(object sender, NotiicationChannelErrorEventArgs e) {

InitializeComponent();

txtEstadoSuscripcion.Text = e.Message;

if(IsolatedStorageSettings.ApplicationSettings.Contains(“IdDispositivo”)) {

} Listado 11. Manejo de error

phoneID = (Guid)IsolatedStorageSettings.ApplicationSettings[“IdDispositivo”]; } else { phoneID = Guid.NewGuid(); IsolatedStorageSettings.ApplicationSettings[“IdDispositivo”] = phoneID;

El listado 12 tiene el manejador del evento miClient.SuscribirMiTelefonoCompleted. Consiste en desplegar un mensaje de error o éxito según sea el caso, así como el contenido del canal de comunicación utilizado.

} miCanalPush = HttpNotiicationChannel.Find(“miCanal”);

void miCliente_SuscribirMiTelefonoCompleted(object sender, System.ComponentModel.

if (miCanalPush == null) {

AsyncCompletedEventArgs e) {

txtMensajeRaw.Text += “Canal nulo”;

if (e.Error == null) {

miCanalPush = new HttpNotiicationChannel(“miCanal”);

txtEstadoSuscripcion.Text = “¡Suscrito!”;

adjuntarFuncionesManejadores();

} else {

miCanalPush.Open();

txtEstadoSuscripcion.Text = e.Error.Message;

} else {

}

txtMensajeRaw.Text += “¡Canal encontrado!”;

txtCanalUri.Text = miCanalPush.ChannelUri.ToString();

adjuntarFuncionesManejadores();

}

miCliente.SuscribirMiTelefonoAsync(phoneID,

Listado 12. Manejo de suscripción

miCanalPush.ChannelUri.ToString()); } } Listado 9. Constructor de la aplicación Windows Phone

Analicemos el código del listado 9. Primero creamos unos objetos de tipo Service1Client (esta clase viene del servicio web que creamos) y HttpNotiicationChannel. Veriicamos que nuestra aplicación contenga un identiicador único guardado en el almacenamiento aislado —y si no, lo creamos. Luego obtenemos el valor del canal que utilizaremos —si es nulo creamos una nueva instancia del canal y lo abrimos— e invocamos la operación SuscribirMiTelefono() del servicio web. En el listado 9 habrán notado llamadas a adjuntarFuncionesManejadores(). Este método deine cuatro manejadores de eventos: ErrorOcurred que se dispara en caso de que algún error haya ocurrido con 14

El listado 13 tiene el código para el manejador miCanalPush. ChannelUriUpdated. Lo primero que hacemos es usar la propiedad IsShellTileBound para veriicar si el canal de suscripción se encuentra enlazado a alguna notiicación de mosaico. Si no se encuentra enlazado, enlazamos por medio del método BindToShellTile() de miCanalPush enviando una lista de dominios o IPs permitidos para el consumo de datos. De manera similar, veriicamos si el canal de suscripción se encuentra enlazado a una notiicación tipo Toast, y si no es así lo enlazamos. Finalmente, desplegamos un mensaje de estatus (“uri actualizada”) y ejecutamos el método SuscribirMiTelefonoAsync() del cliente. void myPushChannel_ChannelUriUpdated(object sender, NotificationChannelUriEventArgs e) { if (miCanalPush.IsShellTileBound == false) { var ListOfAllowedDomains = new Collection<Uri> {

.TUTORIAL

new Uri(@”http://192.168.0.46”) }; miCanalPush.BindToShellTile(ListOfAllowedDomains); } if (miCanalPush.IsShellToastBound == false) {

Para probar las notiicaciones de mosaico vamos a colocar el mosaico de la aplicación que creamos en la pantalla de aplicaciones principales. Después de hacerlo, ejecutamos la operación InsertarInformacionTile(). La igura 3 muestra un ejemplo de qué información incluir en los parámetros.

miCanalPush.BindToShellToast(); } txtMensajeRaw.Text = “uri actualizada”; miCliente.SuscribirMiTelefonoAsync(phoneID, miCanalPush.ChannelUri.ToString()); }

Figura 3. Parámetros

Listado 13. Manejo de actualización de canal

al invocar Insertar

void myPushChannel_HttpNotiicationReceived(object sender, HttpNotiicationEventArgs e) { Deployment.Current.Dispatcher.BeginInvoke(() => { StreamReader miLector = new StreamReader(e.Notiication.Body); txtMensajeRaw.Text = “Notiicación RAW recibida: “ + miLector.ReadToEnd(); }); } Listado 14. Manejo de HttpNotificationReceived

Juntando ambas partes Una vez que tenemos el servicio web y la app de Windows Phone podemos veriicar su funcionamiento. Al desplegar la pantalla de inicio de nuestra aplicación, la aplicación marcará una excepción que explica un acceso no autorizado. Para solucionar este problema vamos a la pestaña de capacidades del archivo WMAppManifest y seleccionamos la opción ID_CAP_PUSH_NOTIFICATIONS. Con esto debe quedar resuelto el acceso. Ahora regresamos al cliente de pruebas del servicio WCF y ejecutamos la operación InsertarInformacionRaw(). Esto debe mostrarnos una pantalla en el teléfono indicando la recepción del mensaje, así como el contenido de este. Como pueden ver, en el segundo renglón después de la leyenda Notiicación RAW recibida se despliega el mensaje enviado. Si ahora intentamos ejecutar la operación InsertaToast() enviando el título “notiicacion” y el cuerpo “mensaje de prueba”, el dispositivo mostrará algo similar a la igura 2.

Figura 4. Notificación de mosaico

Conclusión Con esto terminamos este tutorial donde mostramos como crear notificaciones y desplegar notificaciones en Windows Phone. Este es un recurso muy útil y que le da gran interactividad a nuestras aplicaciones. Por otro lado, también debemos tener cuidado de no abusar de las notificaciones, ya que podemos terminar agobiando a nuestros usuarios.

Referencias [1] “Push notiications for Windows Phone”. MSDN. http://swgu.ru/r6 [2] “Sending push notiications for Windows Phone”. MSDN. http://swgu.ru/sg39r7

.BIO Amín Espinoza (@aminespinoza) es un desarrollador de software especializado en las plataformas Windows Phone, Windows 8 y Silverlight. Es un apasionado de la historia, y fan de las luchas, los comics, el café y la música. http://aminespinoza.com Figura 2. Despliegue de notificación toast

www.sg.com.mx |

La imagen debe ser de 173x173 pixeles. La dirección de la imagen debe ser absoluta. En este caso yo la coloqué en el servidor web local de mi computadora. Para ahorrarse el trabajo de crear la imagen podemos recurrir al servicio de imágenes de lorem pixel. Simplemente usamos la dirección http://lorempixel. com/173/173 La igura 4 muestra un ejemplo de cómo se vería en el dispositivo una notiicación de mosaico (imagen del ciclista con el título “Ejemplo Tile” y el contador 9).

Software Guru

InformacionTile

El listado 14 muestra el manejador de eventos para HttpNotiicationReceived. Consiste en recibir el cuerpo del mensaje en un objeto de tipo StreamReader y desplegarlo en pantalla.

.ESPECIAL PROJECT MANAGEMENT

MODERNO

Project Management Moderno Ideologías renovadas en el horizonte

››Por Vanessa Amaya

omo sabemos, construir o implantar software no es una actividad trivial: involucra la colaboración de personas con distintos periles, administrar los riesgos, costos, tiempos, materiales, etcétera. En pocas palabras, un proyecto de software es un proyecto digno de administrarse. Mencionamos esto, que para muchos puede parecer obvio, porque pareciera ser que ante los factores que están moldeando nuestra industria —tales como reducción en los tiempos de construcción de software, adopción de lujos continuos tipo Kanban, automatización de actividades en el ciclo de vida de software, posibilidad de ensamblar apps a partir de elementos existentes—, la administración de proyectos está perdiendo relevancia. Nosotros consideramos que no es así, el project management sigue siendo tan importante y necesario como siempre, pero está evolucionando (y debe hacerlo) para satisfacer las necesidades y contexto de los proyectos de software modernos. A continuación listo algunas de las características que considero más relevantes sobre este project management moderno.

yectos consiste principalmente en cambiar mentes, más que cambiar métodos. Si se quiere adoptar solamente las prácticas sin cambiar la mentalidad y costumbres, no se lograrán los beneicios esperados.

LIDERAZGO COMPARTIDO

La inversión que se ha hecho en las PMOs es gigantesca, ya que no solo se trata de la operación interna sino de los recursos que directa o indirectamente consumen en las organizaciones como herramientas, infraestructura, tiempo de otras áreas, consultorías, y capacitaciones. Como toda gran inversión es necesario que sea cuestionada y de ser necesario reinventarla para alinearla a los nuevos objetivos de la empresa.

Conforme la tendencia es hacia establecer equipos auto-dirigidos, una de las principales responsabilidades de un líder moderno es la de establecer un ambiente bajo el que pueda haber un liderazgo compartido. Este punto implica no tener un único responsable del éxito o fracaso de un proyecto. Un indicador importante de que el liderazgo comienza a lorecer, es cuando la comunicación luye mejor, cuando en las reuniones de trabajo no solo es una persona la que habla, pide y opina sino que se presentan escenarios donde la sana retroalimentación es parte de la dinámica de los proyectos. La comunicación da paso a la iniciativa y la iniciativa a la creatividad: estos elementos alimentan al liderazgo.

ÉNFASIS EN LA MOTIVACIÓN La administración de proyectos de software moderna reconoce la importancia de las personas. El éxito de un proyecto está ligado a la motivación de sus miembros. Esta motivación no solo radica en “echar porras”, sino en mantener una buena comunicación, lograr que realmente haya un objetivo común, que es más importante que el desempeño individual de cada integrante. .BIO

INCORPORACIÓN DE PRÁCTICAS ÁGILES

Vanessa Amaya (@vanessa_amaya) es Coordinadora Editorial de SG. Es Ing. en Sistemas Computacionales por la Universidad Autónoma de Guadalajara y tiene más de 10 años de experiencia en proyectos de desarrollo de software en distintas industrias. Ha capacitado a más de 2,000 profesionistas de software en temas de Ingeniería de Software, administración de proyectos y comunicación efectiva.

Los métodos ágiles han afectado signiicativamente la forma en que construimos software, desde la adopción de modelos iterativos e incrementales, hasta la forma en que programamos o probamos (ej. test driven development). Sin embargo, debemos recordar que la gestión ágil de pro16

››

“ … TODA EMPRESA DESEA Y REQUIERE SER UN SEMILLERO DE LÍDERES…” ANÁLISIS DE NEGOCIO No importa que un software se haya hecho en tiempo, costo y de acuerdo a las especiicaciones, si no contribuye a resolver el problema de negocio deseado. Un software funcional, pero que no está alineado al negocio, no sirve de mucho. Es por ello que en los últimos años ha cobrado gran popularidad la disciplina de análisis de negocio. El análisis de negocio provee también la visión para poder descubrir oportunidades bajo una perspectiva más global y a largo plazo.

¿Y LAS OFICINAS DE PROYECTOS?

Algunos aspectos importantes a cuestionar son: Credibilidad de sus indicadores. ¿Son utilizados para tomar decisiones de peso en los proyectos? ¿Por qué? Las respuestas a estas preguntas desencadenan un análisis muy profundo y acciones que traerán mejoras sustanciales. Cooperación. ¿Qué tanto se involucran las PMOs con los equipos de trabajo y viceversa? Es recomendable crear comunidades de apoyo para restablecer los vínculos perdidos. Mesas redondas o Mesas de análisis donde se hablen de las problemáticas frecuentes en los proyectos y a través de expertos se identiiquen las causas raíz. Esquemas de comunicación. También es importante analizar si es necesario aligerar y adaptar los esquemas de comunicación que se tienen de la PMO hacia los proyectos (por tipo de proyecto, por tipo de plataforma, por duración, por tipo de cliente, etc). Es importante que estos esquemas sean adaptables y lexibles. La información e indicadores podrán ser buenos, pero no todos los proyectos requieren los mismos indicadores en todo momento. Cada fase debería de tener indicadores particulares. Un proyecto siempre será un reto a resolver de manera coordinada por lo que toda disciplina y práctica que se incorpore en el ámbito de los proyectos facilitará el control de todas las variables a vigilar.

.ESPECIAL

PROJECT MANAGEMENT MODERNO

Estimación Empírica de Proyectos con

Planning Poker ››Por Héctor Cuesta-Arvizu y Sergio Ruiz-Castilla

Consiste en crear una reunión de trabajo con el grupo de expertos. Se requiere de un moderador que dirigirá la actividad. Primero se expone el proyecto que se va a desarrollar. Luego se determinan las actividades requeridas para ejecutar el proyecto, y entonces para cada una de las actividades los distintos miembros del equipo realizan una estimación empírica y se conjuntan y discuten los resultados con el in de cerrar la brecha y converger en un valor estimado para cada tarea. La información obtenida con la estimación de cada tarea se utiliza para realizar el plan general del proyecto y conocer el esfuerzo total.

EL PROCESO

III. Verificación y Validación Es recomendable que al terminar el proyecto y realizar el post-mortem de éste se compare la estimación contra el esfuerzo real, de manera que esto se tome en cuenta para futuras estimaciones. Para esto podemos recurrir al cálculo del balance relativo de error (BRE) con la siguiente ecuación:

Figura 1. Interface web para realizar estimaciones en planningpoker.com

ciones. También hay que tener cuidado cuando uno de los integrantes tiene demasiada autoridad, ya que puede sesgar la estimación. No es posible estimar un proyecto entero de esta forma, sino que se recomienda estimar por historia o sprint si se trabaja con SCRUM. Uno de los beneficios de esta técnica es que permite considerar distintos puntos de vista. Adicionalmente, ayuda a hacer amenizar una tarea que puede ser tediosa. Resulta ser una técnica mejor que Delphi y que grupos no estructurados, tal vez por la discusión cara a cara entre los participantes. A medida que se practica Planner poker se podrán hacer mejores estimaciones.

Referencias [1] N. Haugen. “An empirical Study Planning for user story estimation”. Proceedings of AGILE 2006 Confe-

X+Y BRE = Min(x,y) Donde X = real y Y = estimado

rence. IEEE, 2006. [2] N. Haugen & K. Molokken-Ostovoldl. “Combining Estimates with planning poker: An empirical study”. Proceedings of the 2007 Australian Software Engi-

CONSIDERACIONES Esta técnica requiere de un moderador con gran pericia para lograr que rápidamente haya convergencia en las estima-

neering Conference. IEEE, 2007. [3] T. Stober & U. Hansmann. Agile Software Development: Best Practices for Large Software Development Projects. Springer, 2010.

.BIO

A continuación mostramos el proceso en mayor detalle que se realiza para cada historia de usuario a estimar. 1. El moderador lee y explica una historia o requerimiento ante los miembros del equipo. Se podrán hacer preguntas para dejar claro qué se desea alcanzar. 17

Héctor Cuesta-Arvizu (@hmcuesta) es Lic. en Informática y actualmente cursa la maestría en ciencias de la computación en la UAEM Texcoco. Cuenta con seis años de experiencia desarrollando y administrando proyectos de software. Adicionalmente se desempeña como instructor para Nyce en el área de base de datos e ingeniería de software. José Sergio Ruíz Castilla es Profesor Investigador de la Universidad Autónoma del Estado de México, estudia el Doctorado en Ingeniería de Software y trabaja en proyectos de Ingeniería de Software y Sistemas de Gestión del Conocimiento.

Software Guru

LA TÉCNICA

2. Los participantes anotan en una tarjeta su estimación para dicha tarea y la entregan al moderador de manera anónima, es decir que no se sepa qué tarjeta corresponde a qué persona. 3. El moderador captura los resultados en un pizarrón o en alguna herramienta de software tal como la de http://www.planningpoker.com 4. Una vez que se conoce los integrantes deberán discutirlas, haciendo énfasis en el razonamiento detrás de los valores extremos (el más bajo y el más alto). 5. Tomando en cuenta el conocimiento obtenido por esta discusión, cada participante hace una nueva estimación para la historia y la anota en una tarjeta. 6. El moderador captura las estimaciones ajustadas y en caso de no haber consenso se vuelven a discutir.

www.sg.com.mx |

ara planear el desarrollo de un software es necesario estimar de una u otra forma su tamaño y por supuesto su costo. Existen diversas mecanismos para estimar el tamaño de un software y el esfuerzo requerido para construirlo, en las páginas de SG anteriormente se han publicado artículos sobre métodos como la estimación por puntos de función, así como el recurrir a información histórica de proyectos anteriores. En este artículo se muestra una técnica de estimación empírica conocida como “Planning Poker”, donde un grupo de expertos discuten y evalúan el esfuerzo requerido para cada tarea del proyecto. Se utiliza la opinión de expertos como referencia ya que su experiencia les permite adaptarse a nuevas tareas en base a su similitud. Esta técnica se utiliza en metodologías ágiles como XP (Programación extrema) para estimar cada historia de usuario [1].

.ESPECIAL PROJECT MANAGEMENT

MODERNO

Gestión Ágil de Equipos ››Por Pablo Cáceres Ferreira

radicionalmente, los equipos de desarrollo de software tienen una estructura jerárquica, con la fuerte presencia del jefe de proyecto y alto énfasis en la asignación de roles y especializaciones a personas, que solo se dedican a efectuar el trabajo de su rol o especialización. Este tipo de estructura restringe la interacción entre los miembros del equipo. La utilización de Kanban & Lean se orienta a generar equipos auto-organizados, en donde se alinea el alto empoderamiento con el alineamiento de objetivos comunes: alta flexibilidad, sin tendencia al caos. La gestión tradicional de los equipos visualizados como recursos intercambiables y renovables, puede lograr resultados a cierto grado, pero tiene un alto costo humano, la motivación y autovaloración del desarrollador van mermando, generando un alto riesgo de abandono laboral y la incapacidad de generar equipos fuertemente de alto rendimiento, debido a que nunca se genera un equipo fuerte y permanente, sólo personas que vienen y van.

UN INTENTO FALLIDO Alguna vez colaboré en un proyecto con una empresa dedicada a las microinanzas. El proyecto era de gran relevancia, y mi jefe directo tenía una fuerte intención de utilizar metodologías ágiles. Al ingresar detecté en los miembros del equipo un alto interés en aprender y trabajar de forma diferente. Les expliqué que utilizaríamos Kanban, que con sus principios básicos era suiciente para partir e iniciar el proceso de .BIO mejora continua (Kaizen). Aprovechamos cuando el jefe Pablo Cáceres Ferreira es Project Manager en Rhiscom S.A Chile. Se de proyectos se fue de vacaciones especializa en el desarrollo y gespara hacer un tablero Kanban. tión de proyectos tecnológicos y de innovación utilizando metodologías Nuestro tablero contaba con coágiles. Su próximo objetivo es por lumnas para agrupar los elementos medio de BPM lograr la alineación estratégica de la tecnología al servien Pila, Seleccionado, En curso, cio de los negocios y los procesos. Listo para revisión, Revisión y Terminado. Iniciamos las Stand-Up 18

Meeting diarias. Si bien existía una Gantt como guía de actividades y tiempos, debido a los altos cambios que sufría el proyecto, la stand-up meeting nos permitían organizarnos día a día balanceando las cargas de trabajo, aumentando el rendimiento de equipo y lo más importante, el ánimo y cohesión generado al ser los únicos trabajando en forma distinta al resto de los equipos. Al regresar nuestro jefe, en un inicio se interesó bastante en la forma de trabajar. Sin embargo, conforme pasó el tiempo el interés fue mermando, haciendo más hincapié en el seguimiento y re-planiicación de la Gantt que poseía. El equipo no se juntaba si nuestro jefe no participaba o no invocaba, el tablero se dejó de actualizar y dejó de tener sentido utilizarlo.

UNA NUEVA SITUACIÓN En mi nuevo trabajo me comentaron inmediatamente la urgencia de estructurar y gestionar las actividades de cada desarrollador del equipo. El problema observado en primera instancia era la sobrecarga de tareas a cada desarrollador, sin tener una priorización clara o planiicación. Adicionalmente teníamos los siguientes impedimentos: • Bajo nivel técnico del equipo. • Restricción inicial de contratación de analista QA. • Restricción inicial de contratación de nuevo desarrollador. Cuando el desarrollador estimaba e iniciaba una tarea, se le asignaban 2 o 3 tareas más (además de retrabajos), generando retrasos y grandes problemas de calidad ya que no estaba controlado el trabajo que tenía en curso. Esto generaba una gran frustración, sobrecarga emocional y estrés, además de existir un mal ambiente interno, generando diferencias técnicas y de calidad en el trabajo. Esto generaba una división y un quiebre interno (entre los que trabajaban bien, y los que no). Existía una fuerte desconfianza de parte del cliente sobre nuestros desarrollos, por carecer de calidad e innovación tecnológica. Si bien los desarrollos eran entregados en un corto tiem-

.ESPECIAL PROJECT MANAGEMENT MODERNO

“LOS RECURSOS NO TIENEN CAPACIDAD DE AUTO-ORGANIZACIÓN, LAS PERSONAS SÍ.”

VISUALIZACIÓN DEL TRABAJO

TIMEBOXING

Lo primero que se realizó fue la creación del tablero Kanban (ver igura 1) para el equipo completo, con las siguientes columnas: Pila, Seleccionado, Análisis, Desarrollo (restricción de WIP, que puede tener el estado de “en progreso” o “listo”), Revisión y Terminado.

De un universo limitado de funcionalidades, se pueden escoger un subconjunto de estas que sean inmediatamente prioritarias y determinar una fecha de entrega fija. Se negocian las funcionalidades que podemos asegurar entregar para esa fecha. Esto elimina los retrasos de entrega, logrando entregar lo prioritario primero, ganando tiempo y permitiendo limitar y enfocar nuestro trabajo en curso. En nuestro caso, cada requerimiento recibido de parte del cliente contenía varios “sub-requerimientos” que eran específicamente las funcionalidades que el cliente requería, por lo tanto, lo que efectuamos es definir conjuntamente con el cliente las funcionalidades más prioritarias e indicar una fecha de entrega de ese subconjunto de funcionalidades priorizadas y una segunda fecha para entregar el resto de funcionalidades. Claramente, una vez entregado el primer subconjunto de funcionalidades existía una re-priorización, lo que nos permitía nuevamente re-planificar y adecuarnos a las necesidades y prioridades del

Para abarcar y solucionar esta problemática, se deinieron las siguientes metas: 1. Mejorar motivación y compromiso del equipo. 2. Optimizar el trabajo en curso (WIP). 3. Mejorar la calidad de los desarrollos. 4. Recuperar la conianza del cliente.

La visualización del trabajo nos permitió inmediatamente detectar y visualizar en conjunto la carga de trabajo que tenía el equipo, y los tipos de tareas que existirían (mantenimientos, requerimiento nuevo, soporte, error, urgencia o documentación.). Fue el inicio del cambio. Adicionalmente, cuando creamos el tablero Kanban acordamos limitar el trabajo en curso y cumplirlo con total rigidez, no superando nunca el límite establecido.

HITOS Y DOCUMENTACIÓN Se deinieron ciertos criterios e hitos a cumplir en la transición de cada tarea en el tablero, que incluían la generación de documentación simple. A continuación la documentación que acordamos generar: 19

www.sg.com.mx |

A continuación describo las acciones realizadas para lograr estas metas.

• Identiicación de necesidades: Descripción de las necesidades de los clientes, validadas por un representante del cliente. • Documento de evidencia de pruebas: Generación de pruebas unitarias y revisión completa del desarrollo, permitiendo detectar el máximo de problemas antes de pasar a producción. • Documento de entrega: documento en donde el desarrollador enumera todos los fuentes creados o modiicados y su descripción, permitiendo detectar posibles alteraciones al sistema por un desarrollo nuevo (impacto a la funcionalidad en producción). • Setup: El documento de Setup está orientado a generar un instalable de uno o más desarrollos que se solicitan instalar en producción. Eso se debe a que cada desarrollador puede generar uno o más entregables, pero estos se pueden efectuar en una sola instalación. La utilización de estos documentos permitió al desarrollador y al equipo dedicar tiempo a la comprensión de los requerimientos y a la revisión más exhaustiva de los desarrollos terminados.

po, el tiempo destinado a hacer retrabajos era aproximadamente un 30% de tiempo involucrado en desarrollar, tiempo que era tomado de estimaciones de otros desarrollos, por lo cual el desarrollador debía efectuar esta corrección y además continuar con los desarrollos asignados y en el tiempo comprometido. En el equipo esto generaba una frustración, ya que se sentían “malos desarrolladores”.

Software Guru

Tabla 1. Tablero Kanban

.ESPECIAL PROJECT MANAGEMENT

MODERNO

“ALTA FLEXIBILIDAD, SIN TENDENCIA AL CAOS.”

cliente, permitiéndonos entregar las funcionalidades de mayor importancia a su negocio. Esto nos permitió directamente establecer un marco de mayor conianza con el cliente y priorizar nuestro trabajo, limitando nuestro trabajo en curso a lo priorizado, eliminando la sobrecarga laboral y canalizándola de una manera más estratégica.

Con el tiempo las reuniones diarias se alargaban, planiicando y analizando nuevos requerimientos recepcionados, por lo cual empezamos a efectuar planiicaciones semanales de máximo 2 horas los lunes. Estas reuniones nos permitían generar metas concretas, especíicas y priorizadas, lo que permitiría al equipo cuantiicar sus avances y sentir que han logrado nuevas y mejores cosas. Esto nos permitía elegir e iniciar aquellas tareas más prioritarias según los objetivos deinidos al iniciar la semana.

también tiene un efecto dramático. Esto aún no ha sido 100% implementado, ya que trabajar con TDD es duro y requiere un cambio mental fuerte. Realizar inspecciones de Código. Establecimos una práctica de revisión por terceros, lo cual nos ayudó a mejorar la calidad del código que generamos. Esto nos ha permitido detectar deficiencias de código, corregirlas y que todo el equipo aprenda para no replicarlas. Hacer análisis y diseño en colaboración. La calidad se incrementa cuando se les pide a los equipos que trabajen juntos para analizar problemas y soluciones de diseño. Decidimos analizar todos los requerimientos en conjunto (todo el equipo) identiicando riesgos, dependencias y dudas, para luego deinir ítems de trabajos (subconjunto de funcionalidades), que pueden ser priorizadas y paralelizadas. Esto permitió distribuir el trabajo en el equipo completo, balanceando la carga de trabajo, aumentando la comunicación en el equipo y disminuyendo la especialización, además de permitirnos compartir conocimiento y estrategias de implementación. Apoyarse en patrones de diseño. Aplicar patrones de diseño facilita y acelera el diseño, además de que ayuda a reducir errores. Utilizar herramientas modernas de desarrollo. Muchas de las herramientas modernas incluyen funciones para realizar un análisis estático y dinámico de código. No poseemos herramientas modernas de desarrollo, pero esta dentro de nuestro próximo objetivo.

ENTREGA CONTINUA

CONCLUSIONES

La entrega continua de los desarrollos permitió inmediatamente alinearlos con las necesidades del cliente y recuperar su conianza. Deinimos dos tipos de entregas: Entrega parcial: Nos permite informar al cliente de un avance en ambiente de revisión interna, pero con riesgos de mal funcionamiento o problemas de escritura en los desarrollos. El objetivo de una entrega parcial es montar un ambiente de integración, rectiicación de un requerimiento completo o netamente para disminuir la angustia del cliente ante cortos tiempos de desarrollo. Entrega total: Es la entrega de una funcionalidad completa en los tiempos planiicados, con documento de evidencia de funcionamiento y entrega. Esto quiere decir que con el visto bueno del cliente, se procedía a la instalación de esa funcionalidad o de otras.

El uso de Kanban, sumado con conceptos de gestión ágil, nos ha permitido aumentar la calidad de nuestros desarrollos, permitiendo el retorno de conianza de nuestros clientes. Gracias a esto, uno de nuestros clientes recientemente nos evaluó como una de las empresas proveedoras Top Ten en conianza, calidad y responsabilidad. Por otra parte, el trabajar con una metodología ágil, limitar el trabajo en curso, deinir hitos o explicitar el proceso, y llevar a cabo las reuniones deinidas (stand-Up meeting, planiicación semanal y análisis en conjunto) ha permitido al equipo conformar una identidad única en la empresa, mejorando su ánimo, motivación y empoderamiento, ya que se ha logrado con una simple guía y políticas puntuales, una auto-organización fuerte, entendida y compartida por todo el equipo. Los miembros del equipo no nos sentimos como recursos genéricos, sino como una fuente de mejora, innovación y orgullo por las metas conseguidas en conjunto: calidad de los desarrollos, optimización de nuestro trabajo, retorno de la conianza del cliente, y lo mejor, motivación y compromiso por parte del equipo.

STAND UP MEETING Se iniciaron las reuniones diarias, en donde se presentaba la tarea asignada y el progreso que se tenía de esta, además de los impedimentos (qué estoy haciendo, qué haré y qué problemas he tenido) poco a poco se va “barriendo” el tablero de derecha a izquierda, iniciando por las tareas inconclusas, hasta las que se planean efectuar (para de iniciar, empieza a terminar).

PLANIFICACIONES SEMANALES

ENSEÑANZA PARA MEJORAR LA CALIDAD. Basándonos en el Libro de Kanban de David J. Anderson, rescatamos la siguiente receta para permitir aumentar la calidad de nuestros desarrollos: Aplicar desarrollo dirigido por pruebas (TDD). Pedirle a los desarrolladores que escriban pruebas unitarias y las automaticen para proporcionar pruebas de regresión automatizadas 20

Los recursos no tienen capacidad de auto-organización, las personas sí.

www.sg.com.mx |

Software Guru

Certificaciones, Normas y Modelos de TI La voz de la industria Trabajar regidos por un modelo o norma es una red de seguridad que debe ayudarnos a controlar y mejorar los resultados de nuestros proyectos de software. Pero el control y garantías no sólo son requeridas hacia el interior sino también hacia el exterior, y es aquí cuando las certiicaciones adquieren un valor más allá del control. En el afán de conseguir reconocimiento como un jugador destacado en la industria internacional de TI, en México en los últimos años se le ha dado gran importancia y apoyo a las certiicaciones, tanto a nivel de profesionistas como de organizaciones y productos. Gracias a ello hoy en día contamos con una masa crítica de profesionistas certiicados en las tecnologías más utilizadas a nivel internacional, así como un número signiicativo de empresas acreditadas en modelos de calidad como CMMI y MoProSoft. Aunque mucho se puede discutir sobre si una certiicación realmente garantiza la calidad del trabajo de una persona o empresa, lo que sí debemos reconocer es que la masa crítica de personas y empresas certiicadas es uno de los elementos que más puede contribuir a mejorar el posicionamiento de un país en la industria global de TI. Es así que hemos dedicado el reportaje principal de esta edición de SG para platicar sobre certiicaciones profesionales y modelos de calidad organizacionales. A lo largo de los siguientes artículos conocerás tendencias, modelos y recomendaciones para conseguir las certiicaciones de mayor demanda en la industria de TI actualmente.

Estudio SOBRE

CERTIFICACIONES 1. Obtener mejores resultados en sus proyectos. 2. Incrementar competencias y habilidades. 3. Mejorar la calidad de los productos de trabajo. Un tema que va de la mano con los programas de adopción de modelos y certiicación organizacional es la consultoría de procesos. Así que preguntamos a los encuestados sobre el rol que debe de asumir el consultor dentro de este tipo de programas. Dentro de los tres primeros lugares se encuentra:

Certificaciones personales La tabla 1 muestra los la lista de certiicaciones personales más buscadas entre los encuestados. Las de mayor interés fueron las de PMP, ITIL y SCRUM Master. Un porcentaje considerable también indicó interés en certiicaciones en lenguajes o plataformas tecnológicas especíicas, sin embargo no se obtuvo el detalle de éstas ya que el enfoque del estudio fue hacia normas y modelos de TI.

1. Aumento de la productividad. 2. Cooperación entre individuos, equipos y áreas. 3. Mejora de la calidad y satisfacción de los clientes. 4. Cuando toda la organización conoce los procesos definidos y se entiende su razón de existir. 5. Cuando hay cambio positivo en la cultura organizacional.

Acreditaciones organizacionales

Próximamente publicaremos en el sitio web de SG la versión completa del estudio referido aquí.

Objetivos En cuanto a las principales razones para adoptar estos modelos, se encuentran:

Beneficios Para conocer los beneiciones económicos que obtienen los profesionistas al certiicarse recurrimos a un estudio realizado recientemente por Select para Mexico FIRST. De acuerdo con dicho estudio, los profesionistas de TI en promedio obtienen un aumento de 36% en su compensación económica en un periodo de 18 meses después de conseguir una certiicación.

Tabla 2. Adopción de modelos y normas en las empresas

Las certiicaciones profesionales típicamente requieren una inversión signiicativa tanto en tiempo, esfuerzo y dinero. Es así que algunas organizaciones dudan de apoyar a su personal para conseguir certiicaciones, ante el riesgo de que después de invertir en la certiicación de un empleado, éste consiga su certiicación y se vaya a otra empresa. Sobre este punto, Raúl González, director de Mexico FIRST, nos comentó que “Es cierto que un pequeño porcentaje de los empleadores no invierte en certiicar a su personal por el tema de la rotación. Sin embargo, el estudio arrojó que la satisfacción de los empleadores fue del 96%, ya que no solo aumentan las habilidades y se mejoran los resultados en los proyectos, sino que hay más idelidad de los empleados y por ende disminuye la rotación.” Más información Próximamente publicaremos en nuestro sitio web una versión completa del estudio de SG sobre certiicaciones. Mantente al pendiente.

Software Guru

1. Facilitador 2. Coach 3. Agente de cambio Obtener una certiicación es un logro, mas no es un indicador de una implantación exitosa a largo plazo, para asegurar que un modelo o norma ha permeado en una organización, nuestros encuestados señalan como indicadores principales los siguientes:

En el caso de las organizaciones, la tabla 2 lista algunos de los modelos, normas de procesos o metodologías (algunos especíicos a TI) más populares. Se indica el porcentaje de personas que indicaron que se utilizaba dicho modelo en su organización.

Tabla 1. Certificaciones de interés a nivel personal.

www.sg.com.mx |

n SG recientemente realizamos un estudio para conocer los objetivos de certiicación de nuestra audiencia. Para ello aplicamos una encuesta entre cerca de 300 profesionistas de TI. En el siguiente artículo compartimos un breve resumen sobre los aspectos más relevantes. El objetivo del estudio fue brindar un panorama actual de los intereses que mueven a profesionistas y empresas para buscar una certiicación o para alinearse a la implantación de procesos basados en normas y modelos (aunque no busquen una acreditación o certiicación). Dentro de la muestra se contemplaron todos los periles que intervienen en un desarrollo de software: Directivos, Gerentes, Líderes de Proyecto, Desarrolladores, Arquitectos, Auditores, Consultores, Ing. De Procesos, Testers, Ejecutivos de venta, seguridad e Infraestructura.

Certificaciones sobre Análisis de Negocio Una tendencia necesaria Por Gabriel Almeida

l análisis de negocio (business analysis) es un conjunto de prácticas orientadas a entender, documentar y gestionar los requerimientos que genera una organización con el in de implementar los proyectos que satisfarán las necesidades de negocio. La mayoría de los lectores de SG estará familiarizado con los estudios de la industria como el Chaos Report que indican que tan solo el 25% de los proyectos de desarrollo de software son exitosos. Estas fallas afectan drásticamente el valor accionario de las organizaciones además que la complejidad e incertidumbre de los proyectos se ha incrementado derivado de las nuevas tendencias de la industria. Entre las principales razones de fallas en los proyectos, están la inadecuada administración de proyectos y administración de requerimientos. El objetivo central del análisis de negocio es entender con mayor precisión la necesidad de negocio con el in de especiicarlo de la manera más apropiada para que los diferentes grupos de participantes del proyecto puedan ejecutar las tareas del mismo de forma más completa y alineada a la necesidad de negocio. Por otro lado, además de asegurarse de que la necesidad de negocio es satisfecha, se asegura de medir el desempeño de la solución con el in de evaluar si esta cumple con los objetivos por los que el proyecto fue iniciado.

Evolución del análisis de negocio En 2010 una encuesta de Forrester Research realizada con 128 CIOs de empresas prestigiosas de la industria determinó que el análisis de negocio era el rol más importante de TI dentro de los 13 roles principales de la industria. Lo anterior demuestra cómo esta nueva profesión ha ido evolucionando desde que en 2003 fue creado el International Institute of Business Analysis (IIBA), quien creó el cuerpo de conocimientos de la práctica conocido como el BABoK (Business Analysis Body of Knowledge) que rige los estándares de la práctica. La versión más reciente del BABoK es la 2, publicada en 2005, aunque se espera que a inales del 2013 se publique la versión 3. El número de miembros del instituto a nivel mundial ha tenido un crecimiento exponencial, en 8 años llegó de 181 miembros a más de 26,000 al inal de 2012.

Tendencias de la industria Actualmente existen más de 2 millones de posiciones de analistas de negocio en el mundo. Estudios realizados por el IIBA en 2010, dieron como resultado que la composición de analistas de negocio

dentro la industria está principalmente constituida por las empresas de TI con un 26.1%; empresas inancieras, de seguros y casas de bolsa con un 24.8%; empresas sin ines de lucro 11.0%; industria aeroespacial y de defensa 9% y el resto distribuida en otras industrias. En México se ha notado un incremento en la demanda de este rol principalmente en las empresas inancieras, de TI y de retail. Con relación a las tendencias del entorno que han cambiado el rol del analista de negocio, hoy encontramos una economía dinámica e interdependiente, un mercado global de clientes y proveedores con competidores nuevos más agresivos; un panorama económico sombrío afectado por profundas recesiones y quiebras de corporativos y países; clientes más astutos que utilizan redes sociales con acceso a información libre, rica e interconectada; empresas extendidas que utilizan soluciones basadas en SaaS (Software as a Service), recursos globales y en outsourcing; encontramos también un incremento en automatización inteligente a través del uso de motores de decisión para mercados inancieros, reconocimiento de voz y herramientas generadoras de código y por último un importante cambio en los modelos de negocio (Apple, Amazon, Google, Facebook). El reto es tener los resultados correctos a la primera. Los resultados de los proyectos son mediocres, ha habido un incremento importante del gasto en TI ($3.7 Trillones USD en 2011 según Gartner) lo que hace que el costo de tener fallas en los proyectos puede representar unos $250 billones de dólares de pérdida por mala especiicación de los requerimientos. Respecto a las tendencias tecnológicas que más han impactado el rol del analista de negocio se encuentran: el desarrollo de proyectos bajo metodología ágil; el análisis de la información requerida para proyectos de Business Intelligence; los procesos de negocio afectados por implementaciones de Business Process Management; la tendencia de independizar las reglas de negocio (Business Rules) de los procesos y sistemas; el creciente uso de frameworks de Arquitectura Empresarial y los constantes cambios organizacionales así como el uso de soluciones basadas en cómputo en la nube. Todo lo anterior obliga de alguna forma a tener analistas de negocio especializados en algunas de estas tendencias para entender mejor el negocio y poder proponer soluciones más adecuadas a las necesidades del mismo.

Las certificaciones profesionales del IIBA Una certiicación profesional es una designación ganada por un individuo identiicando que ha demostrado un nivel estándar de habilida-

“En México se ha notado un incremento en la demanda de este rol principalmente en las empresas financieras, de TI y de retail.”

Hacia el futuro, podemos ver que seguirá el acelerado crecimiento de conciencia y conocimiento del rol del analista de negocio y su valor. Hay una necesidad del uso de prácticas y un lenguaje común de negocios y tecnología consistente a lo largo de las organizaciones. Se está dando una integración de disciplinas de proyectos alineados hacia los objetivos de la organización. Y por último pero no por ello menos importante, está aumentando el enfoque hacia las relaciones personales. Todos estos factores provocarán que la demanda por analistas de negocio continue creciendo. Adicionalmente, el rol está sufriendo una transición a una posición de liderazgo.

¿Por qué elegir certificaciones del IIBA? Siendo una organización global profesional sin ines de lucro para el Business Analysis, el IIBA está interesado en el reconocimiento y apoyo a individuos y a la gran comunidad de analistas de negocio. Esto te da la conianza de que tu certiicación profesional del IIBA será reconocida a donde quiera que vayas no sólo donde un proveedor de capacitación particular es conocido. La igura 1 muestra los requisitos de certiicación para cada nivel de certiicación.

Figura 1. Requisitos de certificación

[BIO] Gabriel Almeida, CBAP® es Socio Fundador, Primer Presidente y VP de Desarrollo Profesional IIBA Mexico City Chapter. Estudió Licenciatura en Informática en UPIICSA y tiene 35 años de experiencia en la industria de TI. Ha ocupado puestos directivos como Subdirector de Ingeniería Sistemas; Subdirector de Ingeniería Procesos; Director de Innovación y Tecnología en distintas empresas. Actualmente imparte cursos, conferencias y talleres sobre Business Analysis. galmeida@seanmexico.com

Software Guru

Escenario futuro

www.sg.com.mx |

des, experiencia y conocimiento dentro de su campo. Las certiicaciones son generalmente ganadas a través de una asociación profesional con un cuerpo de certiicación y son otorgadas basadas en una combinación de formación, experiencia y conocimiento, más que solo por haber pasado un examen. El proceso de desarrollo, administración y mantenimiento de la certiicación es realizado con base en estándares internacionales. Muchas certiicaciones profesionales se utilizan indicando las siglas de la certiicación después del nombre (ejemplo: Juan Pérez, CBAP) Las dos designaciones del IIBA, CBAP – Certiied Business Analysis Professional y la CCBA – Certiication of Competency in Business Analysis son certiicaciones profesionales. El IIBA tiene un Cuerpo de Certiicación cuya responsabilidad es el desarrollo y vigilancia de las certiicaciones profesionales de las organizaciones. El Cuerpo de Certiicación es independiente del IIBA con el in de eliminar conlictos de interés entre el cuerpo de certiicación y el IIBA. Las designaciones CBAP y CCBA son únicamente otorgadas una vez que los individuos han logrado los requerimientos de formación, experiencia y conocimientos en lugar de ser estrictamente evaluados por sus conocimientos (ejemplo: pasar un examen). El programa de certiicación del IIBA ha sido desarrollado alineado a los requerimientos ISO 17024. El ISO 17024 es el estándar internacional para cuerpos de certiicación para individuos. Alineándose a este estándar el IIBA demuestra su compromiso de dirigir un programa de certiicación equitativo.

Las Certificaciones que Todo Tester debe Conocer Por Gerson García y David Aguilar

eguramente como Ingeniero de Pruebas te has preguntado algo como ¿qué certiicaciones existen en el mercado?, ¿cuál tiene mayor validez?, ¿por qué me debería de certiicar con un ente extranjero y no con un representante nacional? o si vivo en México ¿por qué el ASTQB y no el HASTQB?, si al inal del día existe un representante en México ¿por qué hacerlo con un extranjero? En este artículo analizaremos algunas de las opciones más populares para certiicación en testing.

La evolución de las pruebas de software como disciplina El funcionamiento de los sistemas modernos de TI depende de nuestra habilidad de producir software en una forma costeable. El término “ingeniería de software” se usó por primera vez en el taller de la OTAN en 1968 en Alemania Oriental. ¡Este taller se enfocó en la crisis del software! Desde ese momento se observaba una crisis en la calidad, coniabilidad, altos costos, etcétera., de los proyectos de sistemas de software, es decir, comenzó mucho antes de que la mayoría de nuestros testers del día de hoy hubieran nacido. La actitud respecto a las pruebas de software ha tenido una evolución positiva e importante en los últimos años. En los 50’s las pruebas no eran otra cosa que “debuggear” o depurar, en los 60’s al usar compiladores, las pruebas se separaron de la actividad del “debugging” o depuración. En los 70’s al introducir los conceptos de ingeniería de software, las pruebas evolucionaron como una disciplina técnica. Al tener una mayor relevancia los sistemas de software, ha crecido el interés en la protección, seguridad y aceptación, hasta desarrollar la disciplina como una profesión formal.

El perfil del tester Si bien sabemos que un “probador de software” deberá de ser: curioso, perceptivo, inquisitivo, crítico, analítico, persistente, buen comunicador y negociador, estas características y habilidades son parte del peril de un buen ingeniero, pero son en su mayoría implícitas a la

profesión y difíciles de medir de forma concreta. Es por eso que se requiere de una formación estructurada y especializada que pueda ser validada para garantizar los conocimientos básicos y la experiencia. Al día de hoy, la mayoría de los ingenieros de pruebas han aprendido a desarrollar su profesión de forma empírica. Si bien algunos cuentan con mayor o menor formación formal en términos de sistemas de software y una carrera universitaria afín al área de TI, pocos han sido los que han tenido entrenamiento formal y han logrado acreditar certiicaciones en la disciplina. Esta disciplina ha tomado una gran relevancia en las últimas 3 décadas y al día de hoy ya se considera una profesión madura que cuenta con diferentes ofertas para validar los conocimientos de sus practicantes. A continuación describiremos las principales certiicaciones disponibles y comentaremos sus principales diferencias y puntos clave.

Principales organizaciones certificadoras y su oferta El International Software Testing Qualiications Board es una organización basada en Alemania pero con representación en distintas regiones del mundo. En el caso de América está el ASTQB (American Software Testing Qualiications Board) para Estados Unidos, CSTB (Canadian Software Testing Board) para Canada y HASTQB (Hispanic America Software Testing Qualiications Board) para países de habla hispana. Estos son los niveles y opciones de especialización para las certiicaciones que ofrece ISTQB: • Nivel de fundamentos (Foundation). • Nivel avanzado (Advanced) con 3 opciones de especialización: Test Manager, Test Analyst, Technical Test Analyst. • Nivel experto con 4 opciones de especialización: Improving Test Process, Test Management, Test Automation, Security Testing. Asímismo, el IIST (International Institute for Software Testing) de Estados Unidos ofrece los programas: Certiied Software Test Professional (Associate, Practitioner, Master Levels). • Certiied Agile Software Test Professional. • Certiied Test Manager. • Certiied Software Quality Manager. • Certiied Software Test Automation Specialist. La American Society for Quality (ASQ) es un organismo bastante importante en Estados Unidos, que ofrece programas de formación y certiicación para roles de gestión de calidad en distintos dominios. En el caso especíico del software, ofrece el programa CSQE (Certiied Software Quality Engineer).

Algunos puntos a considerar: • Todas las certiicaciones mencionadas en la tabla, se acreditan por medio de examen, a excepción de IIST que se acredita simplemente por entrenamiento. • Solamente ISTQB cuenta con representación regional en México (HASTQB). • ISTQB contempla dos especializaciones técnicas: Technical Analyst, Test Automation. • IIST tiene la especialización técnica de: Test Automation Specialist.

Por último, el Instituto de Examinación para Ciencias Informáticas en Holanda ofrece programas de certiicación orientados a la metodología TMap (Test Management Approach): • TMAP NEXT Test Engineer • TMAP NEXT Test Manager

las pruebas de software ha tenido una evolución positiva e importante.”

además del examen es forzoso haber tomado el curso oicial asociado a la certiicación. • Vigencia. El tiempo que acredita la certiicación, algunas no expiran y otras deben renovarse cada cierto tiempo (3 a 5 años). Niveles de Certiicación. Normalmente las organizaciones con mayor madurez ofrecen más de un nivel y esto permite una ruta de desarrollo más robusta. • Ramas de especialización. También hay algunas organizaciones que ofrecen más de un esquema de crecimiento, ya que uno puede especializarse en una rama de la disciplina de pruebas como es la Administrativa, Mejora de Procesos, Pruebas No Funcionales, Automatización, etc.

Conclusión

Tabla 1. Detalles de las Certificaciones

En general podemos observar que la mayoría de las ofertas de pruebas se orientan a un nivel básico y permiten la especialización como administradores o líderes de pruebas. Son pocas las organizaciones que validan diferentes niveles de dominio de la disciplina (niveles intermedios, avanzados o expertos) y sólo un par ofrecen certiicaciones relacionadas a pruebas técnicas y automatización de pruebas. Seguramente en los siguientes años veremos una mayor especialización en términos de automatización de pruebas y pruebas no funcionales. Además, se puede ver claramente que la profesionalización de la disciplina se ha adoptado tanto en EUA y Europa. También se debe considerar que además de la oferta de estas organizaciones, diferentes compañías locales y regionales están comen-

“La actitud respecto a

Puntos importantes al decidir sobre una certificación • Presencia a nivel mundial y reconocimiento. Es recomendable contar una certiicación por parte de una organización con presencia mundial a través de capítulos o coordinaciones regionales. Aquí vale la pena revisar las organizaciones que tienen más tiempo en la industria y que han logrado formar vínculos con entidades gubernamentales u otras asociaciones similares. • Tipo de Acreditación. Básicamente hay dos tipos, las que son basadas en exámenes y las que son basadas en entrenamientos. Para las primeras, únicamente se requiere acreditar un examen y pagar su costo. Para las segundas,

Hoy en día es difícil imaginar alguna empresa u organización que no dependa de la tecnología, es por ello que los sistemas cada día deben de aportar mayor calidad y iabilidad a los usuarios inales. Con lo anterior es evidente que en el día a día se necesitan Ingenieros de Prueba con mayor preparación y experiencia para garantizar la funcionalidad de los requerimientos solicitados, pero también para robustecer los sistemas; es decir, que sean resistentes-coniables para el público en general. En México el HASTQB es uno de los organismos acreditados más importantes y cada día a nivel mundial mediante el ISTQB cobra mayor fuerza. Actualmente cuenta con más de 250,000 personas certiicadas en diferentes niveles en más de 70 países. Claramente vemos el desarrollo y madurez de la profesión del ingeniero de pruebas y es por ello que la preparación y acreditación formal cobran mayor importancia.

[BIO] Gerson García es Gerente de Tecnología en Testing IT y David Aguilar es Gerente de Operaciones en la misma empresa. Han participado en proyectos de pruebas de software para empresas de diversos sectores y cuentan con certificaciones del ISTQB (Foundation & Advanced Level) y en IREB (Ingeniería de Requisistos). www.testingit.com.mx

Software Guru

El British Computer Society / Information Systems Examinations Board (BCS/ ISEB) en el Reino Unido ofrece los siguientes programas de certiicación: • Foundation, Advanced, Expert (en alianza con ISTQB) • Intermediate Certiicate in Software Testing. Este certiicado se considera como un nivel intermedio entre los niveles Foundation y Advanced del ISQTB. • Certiied Agile Tester (en alianza ISQI)

zando a deinir sus propios esquemas de certiicación y rutas de entrenamiento. La tabla 1 muestra un comparativo de las opciones ofrecidas por las distintas organizaciones.

www.sg.com.mx |

También tenemos al iSQI (International Software Quality Institute) en Alemania, que destaca por un lado por ofrecer un programa de certiicación para testing ágil y por otro por ofrecer un programa especíico para el modelo V. Estos son sus programas: • CAT Certiied Agile Tester (Foundation Level y Advanced Level) • QAMP Quality Assurance Management Professional • TTCN-3 Testing and Test Control Notation • Certiied V-Model XT Project and QA Manager

Uso de Técnicas Ágiles en Modelos de Calidad Mejorando Resultados de Negocio Por Elsa Ramírez Hernández y Fernando Rueda Téllez

os modelos de procesos para desarrollo de software tales como ISO/IEC 15504 de la Organización Internacional para la Estandarización (ISO) o CMMI® del CMMI Institute proporcionan un marco de trabajo que las organizaciones pueden adoptar para mejorar el desempeño de sus procesos. Ambos modelos cubren un amplio rango de actividades a través de una clasiicación de procesos que, para muchas empresas, es difícil de implementar, debido al cruce de acciones y responsabilidades entre diferentes roles cubriendo varias disciplinas. Y este tipo de operación, típicamente resulta en un sistema documental complejo basado en prácticas muy robustas tipo RUP, PMI, estándares ISO o IEEE, que generan lujos de trabajo complicados y dependientes, así como la generación de muchos artefactos (documentación) que implican tiempo y esfuerzo a pesar de la adecuación (tailoring) que puedan hacer para cada tipo de proyecto. En este artículo platicaremos sobre cómo podemos combinar este tipo de modelos formales con técnicas de las metodologías ágiles para mejorar y agilizar los resultados.

Principales características de las metodologías ágiles Antes de continuar, demos un pequeño repaso acerca de métodos ágiles. Dichas metodologías surgieron como alternativa a los procesos tradicionales de desarrollo, retomando aspectos esenciales de los modelos de proceso formales, pero proporcionando una dimensión al proyecto. Entre las metodologías más comúnmente usadas tenemos: SCRUM: Deine un conjunto de prácticas y roles que pueden ser 28

consideradas como punto de partida para el proceso de desarrollo a usar. Indicado para proyectos con alto índice de volatilidad de los requerimientos. Se caracteriza por deinir Sprints (iteraciones) de corta duración. Permite mostrar al cliente un producto que va incrementando funcionalidad con cada sprint ejecutado, permitiendo la validación continua del producto en construcción. Programación Extrema (XP): Deine un proceso iterativo e incremental con pruebas unitarias continuas y entregas frecuentes. El cliente o un representante se integran activamente al equipo de desarrollo. Promueve el desarrollo de las funciones del producto con dos personas en el mismo puesto: programación por pares. Considera la corrección de todos los defectos encontrados antes de incorporar nueva funcionalidad y realizar pruebas de regresión constantes para detectar los posibles errores. Feature-Driven Development (FDD): Deine un proceso iterativo, con iteraciones cortas de dos semanas como máximo. Consta de cinco pasos: 1. Desarrollo de un modelo global, 2. Construcción de una lista de funcionalidades, 3. Planeación por funcionalidad, 4. Diseño por funcionalidad y 5. Construcción por funcionalidad. Test-Driven Development (TDD): Minimiza el número de defectos del código maximizando su calidad (código limpio). Su funcionamiento se basa en la escritura de una prueba, en la cual se veriican fallas. Posteriormente, se implementa el código que hace que la prueba pase satisfactoriamente, inalizando con la refactorización del código escrito.

Beneficios y resultados de negocio Dentro de los beneicios que se pueden obtener al implementar CMMI con técnicas ágiles podemos encontrar: • Cumplir con las expectativas de los proyectos. • Conservar la visibilidad de los proyectos hacia la Alta Gerencia pero con datos actualizados diariamente permitiendo una mejor toma de decisiones. • Mejor comunicación entre todos los involucrados. • Mejora de la planeación y mejor entendimiento del producto a construir. • Reducción del re-trabajo (al menos un 50% en nuestro caso). • Aumento de la productividad (al menos un 60% en nuestro caso). • Reducción de defectos (al menos un 60% en nuestro caso). • Disminución de los costos. • Incremento del nivel de satisfacción del cliente.

Figura 1. Procesos de CMMI afectados por métodos ágiles.

En el caso de la administración de proyectos, Scrum es posible el método ágil que mayor inluencia puede tener en esta categoría, ya que deine prácticas relacionadas a Requirements Management (REQM), Project Planning (PP) y Project Monitoring and Control (PMC). Algunas actividades del proceso Product and Process Quality Assurance (PPQA) son cubiertas de forma natural por el Scrum Master al asegurar que el proceso Scrum es ejecutado por el equipo, sin embargo para obtener evaluaciones objetivas se debe deinir desde el principio estándares y procedimientos que, luego a través de listas de veriicación, puedan evaluarse. Para realizar la implementación robusta del proceso Measurement and Analysis (MA) se recomienda usar GQIM. Para el proceso Supplier Agreement Management (SAM) Scrum no considera prácticas relacionadas con el tema. En cuanto a los procesos de ingeniería, Scrum recomienda prácticas que se pueden utilizar para Requirements Development

Conclusiones y retos futuros La implementación de CMMI usando técnicas ágiles trae consigo lo mejor de dos mundos: contar con procesos deinidos y un buen nivel de control pero ahora sobre técnicas sencillas y eicientes enfocadas al cliente y al producto. La implementación de las prácticas ágiles en un entorno de procesos riguroso, como el establecido a través del uso de CMMI, permite: • Contar con una combinación poderosa para adaptarse rápidamente a los cambios así como la predictibilidad de los resultados y toma de decisiones oportuna. • Considerar el time to market como factor de ventaja competitiva. • Elevar los índices de satisfacción del cliente. Hay que aprovechar ahora el enfoque de diversos grupos como PMI con administración ágil, RUP con su versión para desarrollo ágil y diversos modelos ágiles, para obtener mejores resultados en la producción de software. ¡Es cuestión de agilizar!

[BIO] Elsa Ramírez Hernández es Directora de Innovación en Praxis. Es experta en implantación de CMMI habiendo dirigido esfuerzos para la acreditación en CMM 3, CMMI 4, CMMI 5 y CMMI 5 con ágiles para una empresa de desarrollo. Fernando Rueda Téllez es consultor CMMI en Praxis. Es experto en procesos de administración, desarrollo y soporte. SEPG Manager y participó en SCAMPIs para CMM 3, CMMI 4, CMMI 5 y CMMI 5 con ágiles para una empresa de desarrollo.

Software Guru

Buscando en Internet podemos encontrar diversas propuestas de mapeos de correspondencia entre modelos de procesos y metodologías de software. Lo interesante no es esta descripción, sino la adaptación que cada organización hace de su proceso estándar para la adopción de nuevas técnicas o procesos. En el caso de métodos ágiles, considerando que se ha contado con experiencia en la implementación de un modelo como CMMI, se pueden aprovechar las actividades relacionadas con la eiciencia de los recursos y la estrecha colaboración con el cliente simplemente ajustando el ciclo de vida tradicional para incorporar prácticas ágiles en aquellas actividades donde tenga sentido. Generalmente los procesos más afectados son los de las categoría de administración de proyectos, ingeniería y soporte. La igura 1 muestra un panorama de esta arquitectura de procesos modiicada.

(RD) y Requirements Management (RM). A su vez, tanto XP como FDD y TDD cubren varias actividades del resto de los procesos de ingeniería. Los procesos de soporte como Process and Product Quality Assurance (PPQA) y Coniguration Management (CM) sufren modiicaciones, sin dejar de obtener las ventajas de su implementación. La velocidad de desarrollo implica implementar técnicas de integración continua que permitan ser más veloces en la realización de liberaciones parciales y formales diariamente. Uno de los retos principales es acoplar el proceso de auditorías al dinamismo y practicidad para documentar los aspectos técnicos que usa el equipo, ya que se ejecuta siempre de forma muy estricta a los artefactos documentados en detalle y generalmente en versiones que cubren al menos el 90% del alcance deinido.

www.sg.com.mx |

Mapeo de procesos CMMI vs. métodos ágiles

¿Qué Tan Ágil Puede Ser Mi Modelo de Procesos? Por Rodrigo Torres Garibay

“Nosotros somos ágiles por eso no documentamos”… “Eso va a hacer más lento el proceso”… “¿Por qué siempre me pides evidencia con una minuta irmada?”…

stos y muchos otros cuestionamientos similares solemos encontrar quienes nos dedicamos a mejorar procesos de software; por un lado la noción de que los modelos de procesos “clásicos” (CMMi, MoProSoft, PMBOK, ITIL, etc) van a entorpecer o hacer más lentas las actividades del día a día y por otro lado esta percepción de que los modelos de procesos “ágiles” (SCRUM, Lean, Kanban, etc.) signiican no documentar. ¿Pero son realmente los modelos “clásicos” unos modelos lentos? O es más bien una inadecuada interpretación de un consultor con poco conocimiento o un evaluador o “Lead Appraiser” con poco criterio para enfocarse a las necesidades de la organización y no solamente a que cubran el modelo/norma o estándar. Todos los modelos de procesos se pueden convertir en la peor pesadilla para cualquier organización sino se saben interpretar o si se quiere seguir al pie de la letra lo que dicen. Ningún modelo es lo suicientemente completo para cualquier organización, por lo tanto se debe de revisar qué es lo que nos ofrece cada modelo y enfocarlo principalmente a las necesidades de la organización en la que se quiera implementar. Recordemos que los modelos de procesos nos marcan el “Qué” y la organización decide el “Cómo”. Por ejemplo, un modelo nunca te pide que generes tres minutas y que éstas sean irmadas con sangre por todos los involucrados, lo que el modelo pide es que notiiques los planes de trabajo a tus involucrados. Queda a criterio de cada organización decidir la mejor forma de implementar esto de acuerdo a su contexto y necesidades.

“Queda a criterio de cada organización decidir la mejor forma de implementar.”

De la misma manera, el Project Management Body Of Knowlege (PMBOK) del Project Management Institute (PMI) deja muy claro desde su primer capítulo cuando nos dice que una “buena práctica” no signiica que todo el conocimiento ahí descrito deba de ser aplicado de la misma forma en todos los proyectos de la organización, sino que es la organización o el líder de proyecto quien debe decidir sobre qué prácticas tomar para cada proyecto. Por su parte, en el Capability Maturity Model Integration (CMMi) del Software Engineer Institute (SEI) nos marca en su representación escalonada para el nivel 2 la implementación de 7 áreas de procesos y para el nivel 3 la implementación de 11 áreas de procesos. Si contabilizamos sus sub-prácticas en la constelación de desarrollo, para nivel 3 estamos hablando de 138 sub-prácticas a lo largo de las 18 áreas de proceso. Además de sumarle las 12 prácticas genéricas las cuales tendrían que estar implementadas en las 18 áreas de proceso, lo cual nos da 216 “evidencias” que se tendrían que mostrar. Como vemos, si nos ponemos a contar cada una de las prácticas e intentamos lograr generar una evidencia diferente para cada práctica o práctica genérica terminaremos con un montón de documentos en un servidor de la empresa que lo más probable es que al inal del proyecto terminemos tirando a la papelera de reciclaje.

Lo esencial es estudiar el modelo para saber qué áreas de proceso y prácticas se relacionan entre sí. Con esto lograremos que por medio de una sola actividad varias prácticas del modelo al mismo tiempo. Recordemos que CMMi nos dará el qué y la organización propondrá el cómo. Además de que CMMi nunca nos solicita que tengamos minutas irmadas o documentos muy extensos, recordemos que tenemos también las prácticas de “Guías de adaptación”. CMMi nos solicita que llevemos las prácticas pero no necesariamente de la misma forma en todos proyectos (si previamente así lo documentamos). Se puede considerar que todos los procesos tienen “caducidad”, por lo tanto entre más se automaticen o se utilicen herramientas para su gestión será mejor la forma para que no se “echen a perder” en la organización, ya que de forma automatizada se podría estar renovando. En conclusión, todo modelo de procesos se puede volver tan ágil o lento como uno quiera, todo dependerá de la adaptación, adecuación e interpretación del modelo que se le quiera dar. Cuántas veces hemos escuchado que se dice que los modelos “Ágiles” no pueden convivir con los modelos “clásicos”, más bien considero que aquellos que aseveran eso, es porque no han logrado interpretar adecuadamente los modelos “clásicos”.

[BIO] Rodrigo Torres Garibay (@garicorp) es Consultor de Calidad en la firma Innevo, donde ha logrado llevar a varias empresas a niveles 1, 2 y 3 de MoProSoft; niveles 2, 3, 4 y 5 de CMMI en las constelaciones de DEV ySVC, así como en proyectos de mejora con el marco de referencia de ITIL. rtorres@innevo.com

Software Guru

¿Cuál es la clave?

www.sg.com.mx |

Cuando se comience un proyecto de mejora no importando el modelo, norma o buena práctica que se quiera implementar como marco de referencia, se debe de hacer la pregunta: “¿Qué es lo que se quiere mejorar?” Con esto se logrará deinir el objetivo para el proyecto de mejora. Si comenzamos el proyecto sin hacernos esta pregunta y en lugar de eso colocamos en el objetivo “alcanzar el nivel x del modelo x” vamos a provocar que toda la implementación esté orientada a obtener “el papel” y nunca la mejora. Es cuando se comienza a volver los modelos lentos, tortuosos y “requeridos porque el jefe lo pidió”. Todo modelo debe de ajustarse a la organización y no la organización al modelo. Al embarcarse en un esfuerzo de mejora de procesos, el objetivo siempre debe de ser la mejora, nunca el papel. Si se orienta desde un principio el proyecto a mejorar los resultados de la organización, se estará cubriendo las necesidades de ésta y de paso obteniendo el nivel deseado. Comúnmente me encuentro con implementaciones de modelos que parten de plantillas, productos base o formatos que son provistos por una irma consultora para “apoyar” a la empresa con la deinición de sus procesos. Creo que esta práctica es un arma de doble de ilo. Si estas plantillas se utilizan como un ejemplo para partir de una idea para comenzar a deinir los procesos creo que está correctamente utilizado, pero si por otra parte se utilizan estas herramientas sin una explicación previa, capacitación y revisión de las prácticas existentes en la organización podríamos estar privando a la organización de la creatividad, innovación y libertad para la deinición de procesos lo cual será clave para la buena adecuación del modelo. Imaginemos el caso de un líder de proyecto que aprovechando el esfuerzo de mejora quiere modernizar los planes de proyecto usando una herramienta de gestión de proyectos en la nube, con reportes automatizados, actualización en tiempo real … y de pronto se le aparece un documento de texto plano con una portada, índice, capítulo de introducción, alcance, glosario, aprobaciones, etc. que en su conjunto la pura plantilla sin contenido son siete hojas (de las cuales realmente funcionan dos), que requiere de irmas de todos los involucrados del proyecto y para rematar se le dice “solamente con este producto puedes alcanzar el nivel deseado de madurez”. Estoy seguro que en este tipo de situaciones cualquier modelo con el nombre que se le quiera dar se puede volverá en una pesadilla para el líder de proyecto y todo el equipo. Por ejemplo, el Modelo de Procesos para la Industria del Software (MoProSoft) nos señala que en su nivel 2 y a lo largo de sus 9 procesos, existen 77 productos de trabajo. Si lo vemos fríamente además estos productos de trabajo se podrían incrementar debido a las evidencias solicitadas de la gestión de los proyectos si consideramos que cualquier acuerdo se puede ver relejado solamente con una minuta irmada por los involucrados. En este caso en particular MoProSoft en ninguna parte de la norma nos señala que estos productos tienen que ser documentos en texto plano, hojas de cálculo, minutas, etcétera; uno podrá deinir cómo llevar estos productos de trabajo y documentar los procesos utilizando las guías de ajuste.

Lo que Pocos Saben sobre CMMI 5 En la definición está la clave Por Carlos Augusto Gutiérrez

ctualmente existen 8 empresas en México reconocidas por el SEI con nivel 5 de CMMI implementado satisfactoriamente y 2 empresas con nivel 4 (sólo el 10% de las organizaciones evaluadas en todo el país). Este resultado se debe a que la mayoría de las compañías ven complicada la implementación de estos niveles debido al poco entendimiento e interpretación de lo que se requiere para deinirlos, lo que se releja en el número de empresas acreditadas. Entre los principales factores que auspician la creencia de la diicultad en la implementación de los niveles de alta madurez de CMMI, se encuentran los modelos predictivos. Sin embargo, con una guía adecuada, es posible adoptarlos de forma satisfactoria. Los niveles de alta madurez de CMMI consideran la implementación de cuatro áreas de proceso que corresponden a la administración cuantitativa y a la optimización de los procesos. Para llegar a estos niveles, es importante que las empresas cuenten con una base bien deinida de los niveles 2 y 3. En el nivel 3 de CMMI se deinen los procesos y la organización cuenta con un conjunto estándar de procesos que establecen la forma en que opera y que pueden ser ejecutados bajo determinadas condiciones. Por su parte, en el nivel 4, se administra cuantitativamente la organización y controla los procesos mediante estadísticas y otras técnicas cuantitativas con dos áreas de proceso fundamentales: Organizational Process Performance (OPP) y Quantitative Project Management (QPM). Ya en el nivel 5 se optimizan los procesos y la organización mejora continuamente, considerando las causas comunes de variación con las siguientes áreas de proceso: Organizational Performance Management (OPM) y Causal Analysis and Resolution (CAR).

Estrategia organizacional Los niveles de alta madurez buscan alinear las actividades estratégicas de la organización con las actividades y mediciones de proceso de los proyectos, para lograr una sinergia entre las diferentes áreas y proyectos de una organización. Con base en esa alineación con la estrategia de negocio, la organización aplica esfuerzos de medición estadísticos a los elementos críticos (los denominados subprocesos). Uno de los principales retos para las organizaciones que buscan niveles altos de madurez es el tema de la adecuación o reestructuración de parte o todo su sistema de medición debido a

que en la mayoría de los casos el sistema actual no soporta adecuadamente los requerimientos de administración cuantitativa de subprocesos críticos de la organización.

Beneficios Algunas de las empresas mexicanas que han alcanzado los niveles altos de madurez han demostrado: • Un mejor control sobre los proyectos que ejecutan, al igual que los gerentes y directores cuentan con más elementos para la toma de decisiones informada. • Un mayor sentido a las estrategias de negocio de la organización y con ello, se ha mejorado la participación en las diferentes iniciativas. • Mejoras cuantitativas que representan para la organización ahorros substanciales tanto en tiempo, esfuerzo y/o costo. Apoyando de esa manera al logro de los objetivos de negocio y estratégicos de la organización. Otro de los beneicios que se obtienen de una implementación de procesos de alta madurez es la generación de un lenguaje común en términos numéricos (cuantitativos) más que en términos cualitativos. Esto permite un mayor entendimiento entre las áreas de la organización. Es importante considerar también los beneficios a nivel individual respecto a la madurez que adquieren los administradores de proyectos es importante, ya que muchas de las actividades ejecutadas en nivel 4 son enfocadas a ese rol, pues la experiencia y el uso de datos cuantificables para la administración integrada del proyecto brinda las herramientas a los administradores para controlar y evitar problemas de manera objetiva. Finalmente, el resultado de implementar procesos de alta madurez ha ayudado a las empresas a ser puntos de referencia en la industria, y por lo mismo tener mayor participación en el mercado debido a la madurez alcanzada. Recomiendo que las empresas evaluadas en CMMI Nivel 2 y 3 continúen su camino hacia la mejora continua, hasta llegar a la institucionalización de los procesos. Contar con una masa crítica de empresas en estos niveles releja una industria fuerte, lo que puede ser una plataforma para posicionarnos mejor como país en el mercado global.

[BIO] Carlos Augusto Gutiérrez Pérez actualmente trabaja en Avantare Consultores en donde se especializa en la implementación de procesos de CMMI en niveles de alta madurez (4 y 5). También ha participado en la implementación de marcos de medición basado en el Acuerdo de Niveles de Servicio (SLA). http://www.avantare.com

.COLUMNA

COLUMNA INVITADA

Laboratorio Nacional de Prueba de Software UNA FUENTE DE MÉTRICAS PARA LA INDUSTRIA

››CON “ACTUALMENTE EN MÉXICO NO SE CUENTA UNA BASE DE DATOS COMPLETA Y CONace ya algunos meses se constituyó en México el Laboratorio Nacional de Prueba de Software (LNPS). La misión del LNPS es proveer a la industria mexicana servicios de clase mundial que por un lado permitan otorgar objetivamente reconocimientos a productos, a probadores de software y a organizaciones de prueba por su alta calidad; y que por otro generen información objetiva y confiable en forma de métricas, estadísticas y registros que faciliten elevar la confianza en los productos de software en México. Actualmente en México no se cuenta con una base de datos completa y confiable de empresas y personas con alguna certificación en prueba de software. En el LNPS estamos desarrollando un sistema que estará a disposición de la comunidad, que permitirá por un lado que las empresas que cuenten con una certificación o con un producto certificado, puedan enviar la información y evidencia de la certificación para que pueda ser accesible para algún interesado; y por otro también será posible que personas envíen evidencia de alguna certificación en prueba de software otorgada por algún organismo nacional o internacional, lo cual permitirá generar estadísticas sobre las capacidades actuales de prueba de software en nuestro país y facilitar acciones que puedan incrementarlas. El LNPS tiene también entre sus objetivos generar y compartir métricas de calidad. Conforme se vayan obteniendo estas métricas se darán a conocer. Entre las métricas que planeamos recolectar y compartir con la comunidad están: Efectividad de pruebas unitarias. Como los lectores de SG saben, las pruebas unitarias ayudan a identiicar defectos conforme el software se va implementando. En el LNPS realizaremos una clasiicación que identiique claramente los defectos unitarios (o que debieran ser detectados en pruebas unitarias). Con esto podremos medir la efectividad de dicha prueba, y basados en esto implementar acciones encaminadas a mejorarla. Densidad de defectos. Esta métrica básicamente trata de la cantidad de defectos que un sistema tiene por unidad de tamaño. El reto es encontrar la unidad de tamaño que pueda ser estandarizada. Existen varios esquemas para realizar estas mediciones: líneas de código y puntos de función son algunos de los más conocidos. En nuestra experiencia ambos tiene grados importantes de imprecisión, por esto es altamente probable que dos organizaciones diferentes obtengan un tamaño distinto del mismo producto. Debido a esto, la densidad de defectos la calcularemos basados en una medición estándar de tamaño, con la que ya contamos en la actualidad y que permitirá realizar comparaciones entre productos que hayan sido probado en el LNPS

(para realizar la comparación con otros productos habría que buscar un nuevo punto de referencia). Defectos por severidad. Cuando hablamos de cantidad de defectos (involucrada en la métrica de densidad de defectos) tenemos una buena idea de la madurez del producto; sin embargo no tenemos la radiografía completa de su calidad. La métrica de cantidad de defectos por severidad es muy importante ya que la severidad indica el impacto del defecto en la aplicación. Si combinamos esta métrica con el tamaño, podríamos obtener adicionalmente una métrica de densidad de defectos por severidad. Esta métrica podría completar la radiografía de los productos dándonos una mejor idea de la calidad del mismo. Defectos inyectados por fase y retrabajo. Los defectos detectados en las fases de pruebas de integración y sistema, que serán los que tendremos registrados en el LNPS, serán analizados para identificar la fase de pruebas en que se deberían haber detectado y removido en el respectivo retrabajo de desarrollo. Esta métrica nos dará información acerca de la calidad que estamos teniendo como industria en cada una de las fases de desarrollo y cuando los usuarios del Laboratorio nos hagan llegar el tiempo invertido en la corrección de dichos defectos tendremos un mapa completo del costo de la calidad para analizar posteriormente su retorno de la inversión.

Conclusión Las métricas que mencioné aquí son las que considero más relevantes, sin embargo en el laboratorio recolectaremos muchas otras que también estaremos publicando. Estas métricas, además de aquellas que se obtengan de las evaluaciones de empresas y de personas, nos permitirán tener una buena radiografía de la calidad en la industria del software en México. Tenemos altas expectativas de que esta información contribuya a la mejora de nuestro sector. Para mayor información visita www.lnps.mx

››Por Aarón Moreno Aarón Moreno Monroy es actualmente Presidente del Laboratorio Nacional de prueba de Software (LNPS). Tiene una vasta experiencia en prueba de software en muchos proyectos en los cuáles a actuado como Ingeniero de Pruebas, Líder de Proyectos y Administrador de Proyectos de prueba y de desarrollo. Ha sido instructor y consultor en prueba de software. Tiene una certificación en prueba de software por el ASTQB y es desarrollador PSP certificado por el SEI. Cursó sus créditos de maestría en el CINVESTAV campus Guadalajara.

www.sg.com.mx |

Software Guru

FIABLE DE EMPRESAS Y PERSONAS CON ALGUNA CERTIFICACIÓN EN PRUEBA DE SOFTWARE.”

.SECCIÓN PATROCINADA

UNA HISTORIA DE ÉXITO INNOVADORA, CMMI 5 CON METODOLOGÍAS ÁGILES.

Lo más relevante: •PRAXIS innova su servicio de desarrollo de software combinando lo mejor del modelo CMMI con lo mejor de las metodologías ágiles. En nuestros días se habla mucho sobre certiicaciones de calidad para empresas y personal; ambas son referencia de ventajas competitivas que logren marcar la diferencia ante la competencia. Dentro del mundo de las TI, las organizaciones cada día buscan que sus productos o desarrollos tengan esa calidad que los lleve a contar con un gran diferenciador en los mercados globales, donde la certiicación de los procesos de fabricación es garantía y aval de calidad. El modelo CMMI es aceptado a nivel internacional como sinónimo de calidad, con adopción en los cinco continentes, ayuda a integrar funciones, establecer objetivos y prioridades de procesos, proveer guías de calidad, brindar puntos de referencia y mejores prácticas probadas en la industria que brindan efectividad a los procesos, y por lo tanto, a los productos resultantes. Típicamente el modelo para desarrollo aplica sobre metodologías tradicionales probadas y que cumplen con cada uno de los procesos deinidos.

Las metodologías existentes para desarrollos tradicionales involucran varios roles, muchos artefactos y por ende tiempo, las metodologías ágiles prometen una mayor rapidez en la implementación, enfocándose en su mayoría al producto inal, dando mayor valor a la colaboración con el cliente. Este enfoque está mostrando su efectividad en proyectos con requisitos muy cambiantes y cuando se exige reducir los tiempos de desarrollo; las metodologías agiles, están revolucionando la manera de producir software. Diversas corrientes mencionan que CMMI es un modelo muy complejo que solicita documentación excesiva de procesos, provocando costos elevados para garantizar la calidad del software. Hoy en día se puede demostrar que el contar con procesos de calidad no signiica que no puedan ser ágiles. Casar lo mejor del CMMI que representa un estricto control y seguimiento para lo toma de decisiones con Ágil que constituye un ciclo de vida con técnicas sencillas que permiten una mejor interacción con resultados rápidos, serán un reto y una necesidad actual en la producción de software. PRAXIS, al elegir CMMI como un modelo de mejora de procesos, ha logrado optimizar tanto el desempeño de los proyectos, la previsibilidad de sus costos, cronogramas, calidad del producto, dando como resultado la satisfacción del cliente. Al operar en cumplimiento a CMMI se ha logrado el uso eicaz de otros modelos, tales como PMBok, BPM, Six Sigma, ISO, RUP, y los métodos Ágiles (XP, TDD, FDD, Kanban, SCRUM), con el propósito de enfocar los recursos hacia el logro de los objetivos de negocio. La innovación y mejora basada en información estadística ha permito pronosticar el resultado conociendo la productividad

a nivel individual, la calidad de los productos e índices de desempeño mejorando el nivel de satisfacción de todos los stakeholders. “En PRAXIS hemos innovado nuestro servicio de desarrollo que combina lo mejor del modelo CMMI con lo mejor de las metoElsa Ramírez dologías ágiles (este proceso fue evaluado nivel 5 de CMMI en diciembre de 2012). Con este servicio se tendrá la certeza que será un desarrollo avalado por un organismo internacional como lo es el CMMI Institute* y ventajas como: la documentación suiciente del proceso, aseguramiento de calidad y control de la coniguración, y lo mejor de todo es que el tiempo de entrega y los costos se puede reducir hasta en un 50% sin sacriicar el resultado. Contar con información estadística es útil tanto para el desarrollador como para la dirección en la toma de decisiones.” comentó Elsa Ramírez Hernández, directora de Innovación y Calidad de PRAXIS. Mediante este esquema PRAXIS demuestra que la inversión que realiza en innovación de sus procesos y servicios es un compromiso ilimitado para con sus clientes. *Organismo de reciente creación también de Carnegie Mellon como el SEI, anterior responsable del modelo. Recursos Adicionales: Síguenos en Twitter @Praxis_IT Únete a nuestra comunidad en Facebook https://www.facebook.com/pages/ Praxis-M%C3%A9xico/117986241636766

ACERCA DE PRAXIS PRAXIS, empresa 100% mexicana, líder en proyectos con metodologías y herramientas especializadas, con un enfoque estratégico en consultoría, integración, Solution Center y desarrollo de sistemas, busca fortalecer el desarrollo de las empresas a través del uso adecuado de las tecnologías de información. Con más de 15 años en el mercado, PRAXIS garantiza soluciones en Tecnología de Información con compromiso ilimitado para sus clientes, con altos estándares de calidad y asesoría en tecnología de punta. Cuenta con oicinas en Monterrey, Querétaro, D.F., Miami, Dallas, Madrid, Argentina, Puerto Rico y Panamá, además forma parte del cluster de Tecnología InteQsoft en Querétaro; del cluster Prosoftware del DF; y también forma parte del cluster AETI en Monterrey Nuevo León.

.SECCIÓN PATROCINADA

PMP®, PMIT®, 7 Certiicaciones en TI, Capacitación, Asesoramiento, Consultoría en Estrategias, Proyectos, Programas, Beneicios, Portafolios, Estructuras de Gobierno y PMO. raymundo@stratominds.com www.stratominds.com

Concluyendo: Es un excelente momento para voltear a ver la certiicación PMP®, hay más demanda que oferta, esta posicionada la necesidad, y en TI representa crecimiento a la persona de manera inmediata, así como beneicios incalculables a las empresas en tiempos, costos y satisfacción al cliente. Si te interesa la certiicación PMP® y te interesa en que te asesore a diseñar tu plan de estudio sin costo, contáctame y te ayudo a que tú equipo y tú se certiiquen. ¡Éxito!

www.sg.com.mx |

Ing. Raymundo Sánchez Ticó Socio Director Consultoría Stratominds

ace un par de años en un proyecto de implementación de PMO en México me pedían 15 personas certiicadas como PMP®, el negocio para Stratominds, la irma consultora, fue que el cliente pagaba por cada recurso una iguala mensual de $190,000 MN mientras que el sueldo estándar de alguien con esta credencial es de $40,000 MN. En la industria, las personas con esta certiicación tienen posiciones de trabajo solventes, lo cual diiculta involucrarlos en este tipo de proyectos. Ahora bien, imagina que te certiicas como PMP®, que te invito a participar en este proyecto, te ofrezco $40,000 MN y tú me pides $100,000 MN ¿Crees que no te los pagaría sabiendo que tengo que conseguir 15 personas? IBM® cuenta con 300,000 empleados de los cuales 25,000 son administradores de proyectos y 14,000 cuentan con la credencial PMP®, Steve DelGrosso, Director del Centro de Excelencia de Administración de Proyectos indica que el número de certiicados crece porque los clientes así lo están pidiendo. Es cierto que una certiicación no hace un mejor profesionista, pero también es cierto que mientras los profesionistas estudien más certiicaciones, tienen mayores armas para enfrentar los retos de TI hoy en día. PMP® contiene el primer marco de referencia que se debe conocer en gestión de proyectos antes que cualquier otro, es el punto de partida, no es suiciente conocer la certiicación PMP® para obtener proyectos exitosos, pero se vuelve más complicado tener éxito sin estudiarla de manera inicial. Muchas certiicaciones de TI son de carácter lógico, por ejemplo, 1 + 1 siempre será 2. Las certiicaciones de proyectos evalúan de manera combinada conocimiento, experiencia y criterio en diversos escenarios, lo que implica crecimiento profesional en las personas, mayores ingresos, que puedas aplicar a posiciones con menor trabajo técnico y claro, nada es perfecto, mayor presión y responsabilidad. También es cierto que un MBA tiene un marco de estudio más completo que PMP®, pero ¿Cuál es más barata? ¿Cuál obtienes más rápido? ¿Cuál está pidiendo la industria? Nunca me ha pedido un cliente personas con MBA, los requerimientos siempre me han llegado de PMP®. No es fácil certiicarse en PMP®, no basta leer el PMBoK®, memorizar o estudiar las mejores guías del mundo, lo más importante para lograr la meta es el método de estudio, el cual debe ser diseñado diferente para cada persona, de acuerdo a su experiencia, peril, habilidades, costumbres de estudio, tiempo disponible, fecha límite, etc.

Software Guru

.SECCIÓN PATROCINADA

¿Por qué obtener una certiicación organizacional? • En la actualidad, la mejora de procesos es un tema de interés para las PyMEs y organizaciones de TI. • Porque estas pretenden asegurar la calidad de sus productos y servicios a través de la evaluación y mejora de sus procesos, y por consiguiente su acreditación en modelos o estándares de calidad nacionales e internacionales reconocidos por la industria. • Todo esto, como parte de su estrategia para aumentar su ventaja competitiva con respecto a sus competidores y así garantizar su supervivencia en el mercado. Comúnmente, algunas de estas organizaciones pretenden asegurar la calidad de sus productos y servicios a través de la mejora de la capacidad de sus procesos, debido a dos razones fundamentales: 1.Imagen, ya que este es un factor clave para mantenerse en el mercado local y establecer un posicionamiento en el mercado internacional. 2.Necesidad, para asegurar que sus proyectos terminen en tiempo y costos esperados.

Algunas de las interrogantes que comúnmente se plantean las empresas de TI ¿Cuáles son los estándares disponibles en el mercado? ¿Por qué adoptarlos y cuáles son los beneicios de implementar y certiicar a la organización de TI en alguno de ellos? Muchas PyMEs pueden plantearse asegurar la calidad de sus productos y servicios a través de la mejora de sus procesos y la acreditación en estándares internacionales creados por: • International Software Organization (ISO) • Software Engineering Institute (SEI) • IEEE, ESI, Softex, ANSI, BSI, etc., entre los cuales se destacan las normas ISO/IEC 15504, ISO/IEC 12207, ISO/IEC 20000, ISO/IEC 29110, ISO 9001, CMMI-DEV y CMMI-SVC, MPS.BR, entre otros.

Sin embargo, la implementación de estos estándares comúnmente es larga y costosa, porque los modelos de procesos y su evaluación, propuestos por estos organismos, están estructurados para ser aplicables a grandes empresas u organizaciones de TI.

¿Por qué certificarse bajo un estándar de calidad organizacional? La mejor razón para querer adoptar e implementar un estándar de calidad es para mejorar la eiciencia y eicacia de las operaciones de la organización. Una organización puede decidir buscar la certiicación por muchas razones, ya sea por un requisito contractual o reglamentario, para satisfacer las preferencias de los clientes o incluso para demostrar que tiene capacidad para ofrecer productos y servicios que satisfagan los requisitos de los clientes.

Ventajas de una certificación organizacional Por lo regular una certiicación bajo un modelo o estándar de calidad proporciona un marco de trabajo y un enfoque sistemático que permite gestionar los procesos de manera que el producto software o servicio de TI resultante satisfaga las expectativas del cliente. Además, la implantación de este tipo de estándares ahorra dinero y aumenta la eicacia y eiciencia de los procesos de negocio. La mayor parte de las empresas que han obtenido la certiicación consiguen también procesos más eicientes, clientes más satisfechos, así como productos y servicios de más calidad. Para los clientes, la certiicación de los proveedores bajo alguno de los estándares anteriormente mencionados signiica la seguridad de que el desarrollo y la provisión de los productos y servicios se realiza siguiendo documentos de referencia globalmente acep36

tados. Por supuesto, esto quiere decir que clientes y proveedores están capacitados para competir en los mercados de todo el mundo. Obtener una certiicación organizacional conlleva numerosas ventajas, aunque las empresas deben asegurarse de perseguir la certiicación por los motivos correctos: •Para llegar a nuevos clientes, puesto que cada vez son más las empresas que consideran la certiicación en un modelo o estándar de calidad como un requisito esencial para establecer una relación comercial con un nuevo proveedor. •Para acceder a mercados globales gracias al amplio reconocimiento de los estándares internacionales. •Para disponer de mejor documentación para diversos ines. •Para dar a la empresa una ventaja competitiva y demostrar su compromiso con la calidad de sus productos y servicios. •Para evidenciar al cliente la calidad del producto y servicio que se le ofrece. Dentro de las empresas que ofrecen dicho servicio está: JPE Consultores cuyo objetivo es ayudar y acompañar a las PyMEs y organizaciones de TI en sus esfuerzos para obtener una certiicación organizacional a través del desarrollo de su metodología llamada “Modelo Simpliicado”que ayuda a las organizaciones a implementar más rápido, con consultores certiicados y a un menor costo, comparado con métodos tradicionales.

JPE Consultores Ofrece Experiencia a través de su trayectoria obtenida en la ejecución de una gran cantidad de proyectos exitosos, seguridad y conianza a la hora de iniciar un esfuerzo de certiicación organizacional bajo un estándar de calidad.

.SECCIÓN PATROCINADA

n el campo de la tecnología, la certiicación es el conjunto de pruebas que permiten la obtención de una constancia que asegura a un profesional que posee determinados niveles de conocimiento y de habilidades, y que le facilitan ejercer su profesión en las mejores condiciones. Una certiicación implica la posibilidad de mejores oportunidades de desarrollo profesional y laboral, pues permite demostrar el conocimiento y especialización que se posea, ya sea sobre un modelo o producto tecnológico, idioma o cualquier otra área del quehacer humano. SemanticWebBuilder (SWB) es una plataforma de productos web, desarrollada por INFOTEC, Centro de Investigación dependiente del CONACYT, la cual durante más de una década ha sido utilizada en distintas instituciones y dependencias de Gobierno Federal principalmente, así como por grandes empresas y organizaciones privadas para la construcción de diversos portales y aplicaciones web, y que en su constante evolución ha implementado los modelos tecnológicos de integración y relación de información denominados semánticos como son RDF, OWL, Linked Data, entre otros. Dichos modelos, según los objetivos establecidos por la W3C (Organismo internacional encargado de deinir y establecer los estándares de desarrollo para tecnologías de internet), están encaminados a construir una Web más inteligente, que permita relacionar información de distintos tipos y fuentes en un contexto coherente y acorde a la naturaleza de las necesidades de información del usuario, y que además pretende ser tan abierta que pueda ser analizada y clasiicada no sólo por personas como ocurre hoy día, sino por las propias máquinas al momento de publicar y consultar la información. Con el propósito de brindar a los profesionales un respaldo más sólido respecto de esta tecnología, se ha buscado desarrollar un programa de certiicaciones en este producto, que además le permita a quien así la ostente, no sólo acreditar la experiencia en la operación, también como respaldo para la generación de modelos de negocio tanto a profesionales independientes como PyMEs

que deseen ofrecer sus servicios a empresas y dependencias que ya cuentan con el producto instalado, y a nuevos nichos de mercado.

¿Cuáles son los niveles de Certiicación? a.SWB Certiied Manager. Respaldará a los usuarios en sus habilidades de uso, operación y administración del producto SWB Portal para la creación de portales y soluciones diversas. Con la capacidad de brindar servicios alrededor de los productos de la suite. b.SWB Certiied Developer. En este peril, la imaginación y los requerimientos de desarrollo de sus proyectos serán el límite. Esta certiicación formará desarrolladores expertos en SWB, de forma que sean capaces de elaborar componentes, aplicaciones y soluciones completas basadas tanto en el API de SWB como en los modelos de desarrollo semántico de la suite. Sin embargo, estas son sólo las primeras líneas de certiicación abiertas, pues se plantea liberar una para “Diseñadores Web” y otra para “Arquitectos de Ontologías”, así como algunas variantes para empresas en un programa tipo “Partners”, o proveedores certiicados de servicios, a partir de ciertas condiciones que se publicarán posteriormente en el sitio del producto: www.semantiwebbuilder.org.mx y en el de INFOTEC: www.infotec.gob.mx

¿Quién puede certiicarse? Aun cuando se trata de un producto tecnológico para el desarrollo de aplicaciones, y que la certiicación fue pensada principalmente en profesionales de la informática, en realidad puede realizarla cualquier persona que demuestre y acredite la experiencia en la administración y coniguración de ambientes web mediante la plataforma SWB para el caso de ser “SWB Certiied Manager”. Y si son amantes del código y la programación, pueden aspirar a ser “SWB Certiied Developer”. Los interesados sólo tienen que tomar el curso de capacitación respectivo al programa que desean conquistar y presentar el examen correspondiente. Actualmente quienes ya conocen y operan el producto, pueden optar por la opción 37

directa y solicitar la presentación de su examen con el personal en INFOTEC asignado a este programa. Interesados contactar por medio del siguiente correo: soportewb@infotec.com.mx Cabe mencionar que el examen se presenta en línea ante la empresa americana Prometric, la cual es líder internacional en el mercado de las certiicaciones, lo que garantiza que no se trata de un examen simple, ni que se podrán realizar “arreglos especiales” en la acreditación del mismo. De esta manera se sostiene la idea de que el proceso es completamente transparente y sólido. Y para aquellos que no conocen la plataforma SWB o aún no son expertos en la misma, pueden optar por adherirse a un programa de capacitación especíicamente constituido con el propósito de formar profesionistas capaces de certiicarse. Este programa se imparte ya sea en INFOTEC o en distintas universidades públicas del interior de la república, donde se están formando grupos de entrenamiento.

¿Quién avala la certiicación? Quienes obtengan este reconocimiento deberán saber que está avalado por INFOTEC, CONACYT y PROMETRIC, con la intención de que tenga un respaldo nacional e internacional de prestigio, y puedan acceder a proyectos en Gobiernos Municipal, Estatal o Federal donde ya existen instalaciones de SWB. Lo que se ha buscado es garantizar de la manera más efectiva la verdadera calidad de los conocimientos de quienes acrediten el examen, y que además puedan hacer valer su mérito no sólo a nivel nacional sino internacional, pues SWB ha comenzado en los últimos años a romper las fronteras y darse a conocer en otros países de América Latina principalmente. Durante 2012 se buscó reconocer y crecer los méritos de los miembros de la comunidad SWB, y para el 2013 se ha planteado como meta, la consolidación de esquemas de colaboración entre profesionales y el ámbito comercial para diversas PyMEs TIC en México, de forma que puedan contar con más herramientas para desarrollar nuevas líneas de negocio y ofrecer a sus clientes a través de SWB.

www.sg.com.mx |

Software Guru

Programa de certiicaciones en

.SECCIÓN PATROCINADA

Las certiicaciones en México en materia de Tecnologías de Información

a certiicación, según la deinición contenida en la Ley Federal sobre Metrología y Normalización (LFMN), es el procedimiento mediante el cual se asegura que un producto, proceso, sistema o servicio, cumple o bien está conforme con las especiicaciones contenidas en las normas. Es decir, la certiicación es el procedimiento mediante el cual se evalúa la conformidad de un producto o proceso acorde con la normativa aplicable. Para evaluar la conformidad de dicho producto, proceso, sistema, servicio o persona, en principio deben existir los estándares que contengan las especiicaciones de dichos productos o procesos, por tanto, no puede existir certiicación si no existe una normativa para ello. Por lo anterior desde hace 18 años, Normalización y Certiicación Electrónica S.C., (NYCE) contribuye a la creación de estándares para la industria de Electrónica, Telecomunicaciones y Tecnologías de Información, y es en este rubro de las TI’s donde ha tenido mayor crecimiento en los últimos años. Asimismo, NYCE proporciona el servicio de capacitación en dichos estándares, así como el de la evaluación de la conformidad de los mismos (certiicación y/o veriicación), según sea el caso. La gran mayoría de las normas mexicanas que NYCE elabora están armonizadas (son idénticas) a las normas internacionales correspondientes, de organismos internacionales reconocidos como la ISO o la IEC. El primer estándar que NYCE evaluó en México, con actividades de veriicación en sitio, fue la norma MoProSoft (NMXI-059-NYCE-2006, actualizada en el 2011), creada para proveer un modelo de madurez de procesos para la industria del software, con el objetivo de hacerla más competitiva, y de que con el tiempo pueda incrementar sus capacidades organizacionales -ya que cuenta con 5 niveles de madurez- para desarrollar software que se entregue a tiempo, que cumpla las especiicaciones del cliente y que se apegue al presupuesto. NYCE como organismo de Certiicación para evaluar la conformidad de Sistemas de Gestión de TI, está acreditado en las siguientes Normas: NMX-I-20001-NYCE-2010 Gestión del Servicio, cuyo objetivo es promover la adopción de un enfoque de procesos integrados para proveer servicios (de TI) que satisfagan los requisitos del negocio y de los clientes, dicha norma está armonizada con la norma ISO/IEC 20001. NMX-I-27001-NYCE-2010 (ISO/IEC 27001), orientada a im-

plementar un Sistema de Gestión de Seguridad de la Información, que es aplicable a cualquier tipo de institución preocupada por minimizar los riesgos inherentes al manejo, almacenamiento y uso de información, lo cual normalmente se realiza mediante tecnologías de vanguardia. Últimamente esta norma ha sido el marco idóneo para utilizarla como el Sistema de Gestión que le permita a las organizaciones cumplir con diferentes regulaciones como la Ley Federal de Protección de Datos Personales en Posesión de los Particulares, entre otras. Otros estándares que NYCE evalúa en materia de Tecnologías de la Información son la norma NMX-I-NYCE-38500 (ISO/IEC 38500) para el Gobierno Corporativo de TI; la ISO/IEC 22301 sobre Sistemas de Gestión de Continuidad del Negocio; la NMX-I-25000-NYCE que marca las especiicaciones para la Calidad de Productos de Software y 9 normas más que regulan las actividades de la industria del juego electrónico en México. Asimismo, NYCE cuenta con el servicio de certiicación de personas para Evaluadores de Procesos de Software y de Consultor Integral en TI, abarcando este último las 4 disciplinas que mencionamos anteriormente: NMX-I-38500, NMX-I-059, NMX-I-20001 y NMXI-27001 en 3 niveles: Fundamentos, Consultor Jr. y Consultor Sr. Cabe mencionar que en años pasados la Organización Internacional de Estándares (ISO por sus siglas en Inglés) tomó como base la norma mexicana MoProSoft, para crear un nuevo estándar internacional, bautizado bajo la serie ISO/IEC 29110 – Lifecycle Proiles for VSE (Periles del ciclo de vida – del software – para empresas muy pequeñas). De los tres periles que conformarán esta norma -básico, intermedio y avanzado- en México ya existen empresas que están implementando el peril básico y NYCE estará ofreciendo en breve el servicio de certiicación. A la fecha NYCE ha veriicado a más de 400 empresas en diferentes niveles y continuamos incrementando ese número para hacer que la industria del desarrollo de software, contribuya cada vez más a aumentar las exportaciones para lograr ser uno de los 3 primeros países exportadores de servicios de TI. Para mayor información: J. Salvador SÁNCHEZ ABARCA Director de Operaciones de TI ssanchez@nyce.org.mx 38

CAPACÍTESE EN RED HAT ENTERPRISE LINUX Y GANE MÁS

Grandes empresas y entidades de gobierno en México, como el Instituto Federal Electoral, han apostado por la tecnología de Código Abierto Red Hat y han decidido seguir invirtiendo en años futuros.

¿No está seguro de por dónde empezar? Tome sin costo la evaluación de habilidades** para determinar cuál es el camino adecuado para usted y obtenga un 20% de descuento** *Reporte Dice.com http://www.linuxfoundation.org/publications/ linux-foundation/2012-linux-jobs-report **Red Hat ofrece 20% de descuento en Carrera de Red Hat Certiied Engineer (RHCE) que incluye los cursos RH124, RH134 RH135 y RH255. Para hacer valida la promoción usted deberá presentar una copia del resultado de su evaluación de habilidades que puede obtener en este link: http://mx.redhat.com/resourcelibrary/articles/training-skills-assessment-latam y enviarla a training-mx@redhat.com . La oferta es válida durante todo 2013, el participante es responsable de evaluar su formación en Linux e inscribirse en el curso adecuado, la promoción no es transferible, el descuento no es aplicable en otros cursos impartidos por Red Hat, el descuento no se puede combinar con otros programas de descuentos, paquetes, promociones o cupones, los términos y condiciones están sujetos a cambios sin previo aviso. Para mayor información del principal proveedor de Linux y de Software de Código Abierto, con soluciones de: Plataforma, Middleware, Virtualización, Storage, Cloud Computing, Servicios Profesionales y Entrenamiento, contacte:

Correo: training-mx@redhat.com Tel en México: +52 (55) 8851-6400 Visite: mx.redhat.com 39

Software Guru

Sea nuevo en Linux o busque desarrollar habilidades más avanzadas, Red Hat ofrece cursos y certiicaciones que impulsan su carrera.

www.sg.com.mx |

n 1991, Linus Trovald, sin imaginar el alcance que tendría años más tarde, comenzó a programar lo que hoy conocemos como sistema operativo Linux. Tuvo la visión de robustecer su creación, compartiéndolo con el mundo y convirtiéndolo en un software de código abierto. Hoy en día, la superioridad de este sistema operativo, multitarea, multiusuario, multiplataforma y multiprocesador, ha acaparado la mirada de grandes y medianas empresas, ya que les permite contar con soluciones robustas y lexibles, de acuerdo al giro y crecimiento de su negocio y a un costo muy bajo. Red Hat, comprometido con sus clientes y con la comunidad de código abierto, se ha dado a la tarea de crear profesionales, capaces de seguir aportando a este ecosistema, pero sobre todo, dándole la oportunidad a cualquier empresa de contar con tecnología de última generación a un bajo costo. De acuerdo a un reporte publicado por dice.com* y la Fundación Linux, las compañías están buscando profesionales entrenados en Linux, y están dispuestos a pagar bien por ellos, ya que, aún a pesar de la creciente adopción en Latinoamérica de Linux, existe la percepción de que el talento Linux es escaso. El reporte predice que las contrataciones irán en aumento en comparación con otras áreas dentro de TI. Con base a lo anterior, y con la demanda a la alza, las compañías están ofreciendo a aquellos con entrenamientos recientes y experiencia en código abierto: •Mejores salarios, bonos y beneicios, como horarios lexibles. •Mayores aumentos salariales cada año, comparados con otros profesionales de la tecnología. •Entrenamiento adicional y programas de certiicación.

Evalúe sus conocimientos en Linux

.PRÁCTICAS ARQUITECTURA

Certificacionesen Arquitectura de Software ››Por Humberto Cervantes e Iván González

provechando el tema principal de esta edición de SG, en esta ocasión dedicaremos esta sección a hablar sobre certificaciones en arquitectura de software. En un artículo dedicado específicamente a las certificaciones en arquitectura de software [1], Paul Clements menciona que existen distintas categorías de certificaciones. Primeramente, las certificaciones pueden ser internas o bien públicas. Las certificaciones internas existen en grandes empresas tales como Boeing o Raytheon y están orientadas a sus empleados, mientras que las certificaciones públicas son otorgadas por organismos tales como el Software Engineering Institute (SEI) y pueden ser obtenidas por el público en general. Por otro lado, Clements hace también una distinción entre los certificados (certificate) y las certificaciones (certification). Los certificados pueden ser obtenidos mediante el seguimiento de cursos y pueden requerir o no que se realice un examen. Las certificaciones, por otro lado, hacen referencia al otorgamiento de credenciales en base a la ob.BIO servación de la aplicación exitosa El Dr. Humberto Cervantes es profesor-investigador en la UAMdel conocimiento adquirido. AlIztapalapa. Además de realizar docencia e investigación dentro gunos otros aspectos que diferende la academia en temas relaciocian a las certificaciones son los nados con arquitectura de software, realiza consultoría y tiene pre-requisitos y también si estas experiencia en la implantación de métodos de arquitectura dentro certificaciones están asociadas o de la industria de desarrollo nacional. Ha recibido diversos curno a alguna plataforma. sos de especialización en el tema A continuación comentarede arquitectura de software en el Software Engineering Institute, mos sobre algunas opciones disy está certificado como ATAM Evaluator y Software Architecture ponibles en la industria. Cabe Professional por parte del mismo. señalar que los autores hemos tewww.humbertocervantes.net nido experiencia con las dos priIván González Aguilar es ingeniero en Telemática, graduado de meras que se discuten. la UPIITA del IPN. Actualmente trabaja en la industria del desarrollo de software y busca de forma continua su formación integral. Entre algunos de sus intereses afines en estos días se encuentran: temas relacionados con estilos de arquitecturas, el diseño de aplicaciones, y la programación con los lenguajes Clojure y Ruby. Además está certificado como Oracle Certified Master, Java EE Enterprise Architect. http://mx.linkedin.com/ in/ivangonzalezaguilar

Software Engineering Institute El SEI cuenta con varios programas de educación que permiten obtener certiicados en el tema de arquitectura de software. Estos incluyen: • Software Architecture Profes-

sional: Proporciona una base teórica sólida en el tema de la Arquitectura de Software. Consta de cuatro cursos: Principios y Prácticas de la Arquitectura de Software; Documentando Arquitecturas de Software; Análisis y Diseño de Arquitecturas de Software; y Líneas de Productos de Software. Además es necesario realizar un examen. • ATAM Evaluator: Capacita al participante como miembro de equipo de evaluación de arquitectura siguiendo el método ATAM [2]. Consta de los cursos: Principios y Prácticas de la Arquitectura de Software; y Entrenamiento del Evaluador ATAM. También se debe tomar el mismo examen que en el programa Software Architecture Professional. • SOA Architect Professional: Proporciona una base teórica sólida en el tema de Arquitecturas Orientadas a Servicios. Involucra los cursos: Principios y Prácticas de la Arquitectura de Software; Mejores Prácticas para la Adopción de SOA y temas avanzados de SOA, además de haber realizado el examen previamente mencionado. La ventaja de los programas del SEI es que los cursos son impartidos por los autores mismos de los métodos y libros de referencia. Salvo raras excepciones, los cursos se imparten en las instalaciones del SEI en Pittsburgh. Esto es una experiencia muy interesante y enriquecedora, sobre todo porque se tiene la oportunidad de conocer a profesionales de empresas y organizaciones muy reconocidas a nivel mundial. Uno de nosotros recuerda, por ejemplo, en una ocasión haber tenido como compañero de curso a un ingeniero que trabajó en los sistemas de aviónica del transbordador espacial. Los programas del SEI gozan de cierto reconocimiento, en particular en empresas que están familiarizadas con otras propuestas del SEI como pueden CMMI o PSP/TSP. Entre las principales desventajas están el alto costo, ya que no solo involucra el costo directo del curso sino los gastos de viaje.

Oracle Certified Master, Java EE Enterprise Architect Tiene un enfoque muy claro y marcado hacia a la plataforma Java en su edición Empresarial. Se enfoca básicamente en el 40

.PRÁCTICAS

ARQUITECTURA

“ES IMPORTANTE EVALUAR QUÉ ES LO QUE

UNO BUSCA OBTENER DE UNA CERTIFICACIÓN”.

entendimiento de temas de arquitectura a nivel aplicativo, y en el cómo resolver problemas de diseño e implementación de un aplicativo con el apoyo del modelo de programación, stack de componentes, especificaciones, estándares definidos y soluciones probadas que presenta la edición empresarial de java. En los tiempos de la extinta Sun Microsystems, esta certificación (Sun Certified Enterprise Architect) constaba de los siguientes requisitos:

mente amplió su alcance para incluir otros tipos de arquitectura de TI. Ofrece programas de certificación en 4 áreas de especialización: Arquitectura de negocios, Arquitectura de infraestructura, Arquitectura de información y Arquitectura de software. Los cursos de IASA se imparten en distintas ciudades del mundo e incluso algunos se pueden tomar en modalidad online, lo cual es una ventaja para quienes estamos en países donde no hay capítulo local de IASA.

1. Un examen de opción múltiple sobre los tópicos que marca el temario. 2. Una asignación de diseño de solución de un aplicativo para ser resuelto y enviado de vuelta para su calificación por personal de Oracle. 3. Un examen de preguntas abiertas sobre las decisiones tomadas en la solución de la asignación entregada en el paso anterior.

Otros

IASA IASA es la asociación global de arquitectos de TI. Originalmente solo se enfocaba en arquitectura de software pero posterior-

•“Microsoft Certified Architect” http://www.microsoft.com/learning/mcp/architect •“Open Group Certified Architect” http://www.opengroup.org/openca/cert •“IBM Certified Solution Designer Rational Software Architect” http://www-03.ibm.com/certify/certs/38003001.shtml

Existe una gran variedad de programas de certiicación relacionados con la arquitectura de software. A pesar de que las certiicaciones no son una garantía de que quien las posea es un arquitecto competente, al menos implican que ésta persona tuvo contacto con una capacitación y tuvo que estudiar los conceptos que ahí se impartieron con el in de aprobar el examen asociado (si lo hay). Las certificaciones asociadas a una plataforma específica tienen la ventaja de que tienden a ser más valoradas en la industria, pero tienen la desventaja de que el conocimiento asociado puede volverse obsoleto más rápidamente. Las certificaciones que no están asociadas a una plataforma específica tienden a ser menos valoradas en la industria, pero tienen la ventaja de que pueden aplicarse a distintas plataformas y el conocimiento asociado tiene menos riesgo de volverse obsoleto. Por lo anterior, es importante evaluar qué es lo que uno busca obtener de una certificación, y elegir la que sea más adecuada a nuestras necesidades. En nuestra experiencia consideramos que la obtención de certificaciones relacionadas con arquitectura de software es una inversión que vale la pena realizar.

Referencias [1] Clements, P., “Certified Software Architects”, IEEE Software, Vol. 27, Issue 6, pp 6-8, Noviembre / Diciembre 2010 [2] H. Cervantes. “El Valor de la Arquitectura de Software”. Revista Software Guru # 31, Marzo-Abril 2011.

Software Guru

Conclusión

www.sg.com.mx |

Bajo Oracle esto se ajustó y ahora adicionalmente se requiere tomar un curso previo a presentar el primer examen y contestar un cuestionario final. Con esto la certificación, ahora, se obtiene en 5 pasos. Tanto el paquete de solución como el examen de preguntas abiertas deben ser contestados en inglés, así que hay que tenerlo en consideración. Si planean obtener esta certificación, recomiendo que al presentar la solución esperada sean concisos y delimitados, ya que finalmente lo revisará alguien con quién no se podrá defender las ambigüedades presentes. Apóyense en la utilización de conceptos, modelos y patrones que condensan largas explicaciones. Cada paso tiene un costo por separado. El tiempo para librar con éxito cada paso es bastante razonable, lo que da pie a realizar una planeación en la inversión en esta certificación. Las fortalezas de esta certificación son: el plan de auto-estudio que proporciona el temario, la inmersión durante y posterior a la preparación de la certificación en la bibliografía que señala como recomendada, y por supuesto la elaboración de la tercera y última parte del examen. Una debilidad de la certificación es el estar un tanto rezagada en la inclusión de las tendencias y necesidades actuales dentro del desarrollo de aplicaciones empresariales. La certificación, por ejemplo, no aborda actualmente tópicos de diseño de aplicaciones preparadas para la nube, arquitecturas REST, procesamiento batch, entre otros. Seguramente en un futuro las incluirá, pero en su momento dejará atrás otras, hasta que exista un API o JSR en la plataforma que adopte el estándar y mejores prácticas de la industria.

Algunos otros programas de certificación relacionados con la arquitectura incluyen:

.PRÁCTICAS REQUERIMIENTOS

Casos y Cosas de los ››Por Efraín Cordero

Casos de Uso

Reordenando racimos de uvas Es común encontrar sistemas con varias decenas o incluso cientos de casos de uso. Intentar representar todos estos casos en unos pocos diagramas no es muy útil ya que debido al exceso de elementos se complica el entendimiento del alcance. Los diagramas dan la apariencia de contener racimos de uvas que amenazan con derramarse de tanto peso. Para solventar esta situación, una estrategia es establecer un criterio de subdivisión del modelo y fragmentar los diagramas saturados. El criterio normalmente proviene del negocio, y pueden ser roles, áreas de la empresa, áreas de proceso, prioridades, etc. Por ejemplo, si el criterio fuera “Roles” y como tales hubiera “Cajero”, “Contador”, etc., por cada uno de ellos se crea un paquete y en él se colocan los elementos que le correspondan. Este mecanismo facilita la comprensión del alcance, enfoca las revisiones con usuarios, permite establecer prioridades y simpliica las búsquedas de elementos.

Un hermoso martillo dorado Un “martillo dorado” se reiere a abusar del uso de cierto recurso o herramienta, queriendo aplicarla incluso en problemas para los que no está diseñada. Veamos el siguiente caso de uso: Caso de Uso: Generar Reporte X. Objetivo: Generar y desplegar el reporte X. Actores: Actor X. Flujo Básico: 1. El actor X indica al sistema que desea consultar el reporte X. 2. El sistema permite al actor X indicar los valores para iltrar el reporte. 3. El actor X proporciona los valores a usar para iltrar el reporte. 4. El actor X solicita al sistema que genere el reporte. 5. El sistema genera el reporte y lo muestra al actor X. Flujo Alterno: Información no .BIO existente 5.1 El sistema determina que no hay Efraín Cordero López es responsable técnico y líder de proyecto información y lo notiica al actor X. en grupo CARSO. Es licenciado en computación por la Universidad 5.2 Regresa al paso 3 del lujo básico. Autónoma Metropolitana y cuenta con acreditaciones como SCJP, SCWCD y Oracle SOA Implementation Champion. Es autor de cursos de diseño, pruebas unitarias y mejores prácticas de ingeniería de software.

¿Qué tiene de malo el caso de uso anterior? Describe la interacción completa de un usuario con el sistema, el objetivo es claro, y

la secuencia de pasos parece lógica. El problema es que en casos como este, lo más importante es la información que debe contener el reporte, cómo se obtiene y se despliega, y el caso de uso no dice nada sobre esto. El siguiente ejemplo muestra un extremo de esta situación: Caso de Uso: Ejecutar Proceso Z Objetivo: Que el proceso Z sea ejecutado. Actores: Actor X Flujo Básico: 1. El actor X indica al sistema que ejecute el proceso Z. 2. El sistema ejecuta el proceso Z. ¿En situaciones como estas agrega algún valor tener casos de uso? Los casos de uso son útiles cuando hay gran interacción entre el actor y el sistema, pero cuando no es así o la cantidad de reglas es abrumadora (ej. procesos batch, interfaces B2B), es mejor considerar otras alternativas. Gottesdiener proporciona una lista de opciones para documentar diferentes tipos de requerimientos tales como diagramas de estado, mapas de procesos, prototipos y modelos de datos. Para situaciones donde hay una gran cantidad de reglas, la opción es extraerlas de la narrativa y colocarlas en anexos o documentos separados, dejando en la narrativa las correspondientes referencias.

A ritmo de “copy-paste” Imaginemos un caso de uso de registro de elementos en un catálogo, que tendría un lujo básico similar al siguiente: 1. El actor X indica al sistema que desea registrar un elemento X. 2. El sistema despliega la forma de registro para un elemento X. 3. El actor X llena la forma de registro e indica al sistema que desea proceder con el registro. 4. El sistema revisa que la información proporcionada sea válida. 5. El sistema registra el elemento X. Es muy posible que para todos los catálogos simples el proceso de inserción sea muy similar al descrito, por lo que el equipo seguramente tomará la decisión de usarlo como “plantilla base”. Por tanto, si el sistema comprende 50 catálogos, se generarán 49 clones donde lo único que diiere es el nombre del “elemento X”. 42

.PRÁCTICAS

REQUERIMIENTOS

“¿REALMENTE SERÁ ÚTIL LIDIAR CON VARIOS DOCUMENTOS QUE DICEN LO MISMO?”

En un proyecto en el que participé algunos años, nos encontramos con que a pesar de que los desarrolladores eran buenos, estaban teniendo problemas para implementar correctamente el sistema. El problema era que los desarrolladores desconocían la operación del negocio, así que no entendían cómo los casos de uso soportaban el proceso de negocio y por lo tanto no les era obvio el orden en el que se debían realizar las interacciones indicadas en los casos de uso. A pesar de que los casos de uso manejan relaciones de inclusión y extensión, así como el manejo de precondiciones en las narrativas, éstas no son suficientes para establecer el orden de ejecución de escenarios para la consecución de flujos completos. Por ende, cuando un desarrollador trabajaba con un caso de uso, tenía que “descubrir” como funcionaba el proceso completo haciendo ingeniería inversa. Esto, además de ser propenso a errores, consumía demasiado tiempo. Para corregir esta situación realizamos las siguientes acciones: • Brindar inducción a los nuevos integrantes del equipo en aspectos de negocio. • Documentar los lujos a través de diagramas de proceso de negocio, y registrar la rastreabilidad procesos - casos de uso. • Asignar a recursos experimentados como “coaches” de negocio. • Manejar matrices de rastreabilidad que documenten qué partes del código corresponden a qué caso de uso, para detectar elementos compartidos. • Diseñar baterías reutilizables de datos de prueba para consumo de todo el equipo. • Implementar esquemas de integración continua para detectar impactos laterales lo más rápido posible.

Rompiendo el principio de impenetrabilidad Extrapolando el principio de impenetrabilidad de física a los casos de uso, se tendría que un caso de uso no puede establecer al mismo tiempo la funcionalidad establecida por otro. Aunque

• Reemplazo total: Se bosqueja la funcionalidad actual y solo se describe de manera detallada lo que cambia. • Reemplazo parcial: El caso de uso solo trata de los cambios a la funcionalidad actual. En el primer caso, los desarrolladores pueden terminar creando duplicados de funcionalidades en lugar de actualizar las existentes. En el segundo caso, el resultado es un Frankenstein de modelo donde para conocer la funcionalidad del sistema es necesario realizar un tour entre entre los casos de originales y los n casos de uso “complementarios”. Adicionalmente, se pueden dar situaciones de choque entre fragmentos de funcionalidad. Esto se vuelve verdaderamente inmanejable. Las razones más comunes por lo que sucede lo anterior son: partir de un modelo desactualizado, desconocimiento del modelo, o simplemente pereza. Es necesario promover la actualización del modelo, capacitar a los levantadores de requerimientos en el mismo, y establecer un responsable que supervise que las actualizaciones sean congruentes y no rompan la estructura.

Conclusiones Los casos de uso son y seguirán siendo una muy buena herramienta para documentar y comunicar requerimientos. Sin embargo, es fácil dejarse llevar por la idea de que su uso es trivial y que son adecuados para capturar todo tipo de requerimientos. Una adecuada comprensión de sus limitaciones junto al conocimiento de otras herramientas de levantamiento de requerimientos, aunado a la aplicación de estrategias simples de organización y distribución, traerá como consecuencia requerimientos mejor plasmados, más completos y más sencillos, en beneicio tanto de los equipos de desarrollo como de los usuarios inales y el resto de las áreas involucradas. Referencias [1] S. Ferg. “What’s Wrong with Use Cases?” http://swgu.ru/sg39r2 [2] E. Gottesdiener. “Top Ten Ways Project Teams Misuse Use Cases - and How to Correct Them.” http://swgu.ru/sg39r3 [3] I. Jacobson et al, Object-Oriented Software Engineering - A Use Case Driven Approach. Addison-Wesley, 1992.

Este artículo es una versión resumida del Whitepaper con el mismo nombre publicado en el sitio web de SG http://sg.com.mx/whitepapers

Software Guru

Perdidos en el espacio

suena lógico, en mantenimiento evolutivo una situación común es que, en lugar de modificar los casos de uso preexistentes, los levantadores de requerimientos prefieren crear nuevos sin avisar que reemplazan o “complementan” otros. Esto típicamente sucede bajo dos modalidades:

www.sg.com.mx |

Esto se repetirá para consulta, modiicación y eliminación, por lo que se tendrán 196 narrativas creadas a partir de las 4 base, para un total de 200 elementos. Más que cuestionar la validez del tratamiento anterior, la pregunta es ¿realmente será útil para el equipo lidiar con 200 documentos que dicen prácticamente lo mismo? ¿Y para el cliente? ¿Ese tipo de documentación realmente le sirve? Aunque para los diagramas basta con manejar relaciones de generalización, para las narrativas la estrategia es crear un documento base y aislar en un anexo o documento separado las peculiaridades de cada elemento. De esta manera terminará teniéndose una sola narrativa.

.PRÁCTICAS PRUEBA DE SOFTWARE

¿Debo Certificar Procesos, Personas o Productos? Algunas recomendaciones convenientes ››Por Berenice Ruiz Eguino

uando de probar software se trata, resulta útil preguntarnos qué estrategia es la que mejor conviene aplicar al negocio. Si ya estamos convencidos de la ventaja competitiva que por sí misma las certiicaciones pueden tener, el siguiente paso es decidir el orden prioritario de los criterios sobre los cuales nos basaremos para orientar nuestros esfuerzos y recursos al momento de invertir en ellas. Seguramente hay quienes piensan que “las certiicaciones sólo sirven para vender mejor”, y si bien hay algo de verdad en dicha aseveración, también la hay en el hecho de que comenzamos a vendernos desde muy temprano (y nos seguiremos vendiendo siempre, en muchos ámbitos); muestra de ello, por ejemplo, es que para obtener mejores oportunidades laborales, estudiamos una carrera profesional y pretendemos demostrar nuestros conocimientos por medio de un título que avala que concluimos exitosamente nuestros estudios universitarios. Contar con dicho título, ciertamente no asegura que seremos los mejores profesionistas, sin embargo sí eleva las probabilidades de que eso ocurra, generando mayor conianza en aquellas personas interesadas en contratarnos. Igualmente habrá quienes sin tener “el papel” logren tener dichos conocimientos, es solo que ellos tienen que buscar otros caminos para avalar sus conocimientos y capacidad. Aún así, como bien decíamos la certiicación pudo haber ayudado en primer instancia a vendernos mejor, sin embargo para mantener la reputación también hay que demostrar una y otra vez la efectividad de los resultados logrados como consecuencia de estar mejor preparados. Normalmente quien vende algo malo, no vende más, independientemente de si está certiicado o no. En base a esto, considero que certiicarse no debiera ser pecado, tampoco mera presunción. Debemos usar la certiicación como un medio para allegarnos de más conocimientos especializados (asumiendo que ello implica un período de preparación), asimilar mejores técnicas y herramientas para aplicarlas de manera focalizada en el área de interés seleccionada, demostrando a otros la pericia que nos ayudará a .BIO mejorar, no sólo a vender. Partiendo de esta premisa, evalueBerenice Ruiz Eguino es Directora de Operaciones de e-Quallity, mos ahora respecto a la prueba de softademás ha participado como Consultora Senior en proyectos ware qué puede resultarnos más conde mejora de organizaciones de veniente certiicar cuando deseamos Prueba de Software. Cuenta con certificación internacional en Prueefectivamente mejorar la calidad del bas por el ASTQB. A lo largo de su trayectoria profesional ha actuado software que creamos y/o utilizamos. también como Ingeniero de Pruebas Senior, Líder de Proyectos, Administradora de Proyectos nacionales e internacionales, analista y desarrolladora. Ha sido profesora de la Universidad Autónoma de Guadalajara (UAG), donde realizó sus estudios de Maestría en Ciencias Computacionales.

Diagnóstico Para tomar una decisión acertada sobre la mejor estrategia para nuestra organización, un buen comienzo es contestar las siguientes preguntas:

1. ¿Tenemos una necesidad recurrente de desarrollar o evaluar diversos productos de software? 2. ¿La mayoría de esos productos son estratégicos para la organización? 3. ¿Gran parte de ellos nos brindarán importantes ventajas competitivas? 4. La demostrada alta calidad de todos esos productos ¿nos generará diferenciadores medibles en términos económicos? 5. Desarrollar o evaluar diversos productos de software ¿es parte de nuestro “core business”? 6. ¿Pesa directamente sobre nosotros la calidad de todos esos productos de software? 7. El demostrar la buena calidad de todos esos desarrollos, ¿engrosará nuestra cartera de clientes? 8. Institucionalizar la forma de evaluar varios sistemas además de motivante será ¿nos hará más productivos? 9. ¿Requiero demostrar a otros la pericia individual de quienes evalúan nuestros productos de software? (siendo elementos internos) 10. El reconocimiento oicial e individual de las habilidades técnicas de los probadores de software, ¿se traducirá en beneicios medibles para la organización? 11. El conocimiento demostrado por nuestros probadores de software facilitará el posicionar mejor nuestros productos/servicios? 12. ¿Es uno de nuestros servicios clave el “sourcing” de personal de pruebas de software? 13. ¿La especialización en pruebas de software es el foco del plan de carrera de nuestro personal o de una parte de ellos? 14. ¿Considera la organización el valor de una certiicación como elemento clave de retención de su personal de pruebas? 15. ¿Requiere su organización promover mejor (Mercadotecnia) un producto de software estrella, dentro de su mercado? 16. La mala calidad de dicho producto ¿derivaría no sólo en inconformidades de clientes, sino incluso en problemas legales por excesivos defectos críticos en producción? 17. ¿La operación de su negocio está basada en la efectividad de un sistema de información clave? 18. Requiere su organización, por estatutos o normatividad oicial, demostrar la alta calidad de cierto sistema de información. 19. El mayor porcentaje de sus ganancias (o pérdidas) está directamente ligado al buen (o mal) funcionamiento de uno de sus sistemas (por ejemplo, punto de venta). 20. ¿Requiere diferenciar notablemente alguna de sus aplicaciones, respecto a otras similares en su mercado? Si respondió airmativamente a más del 50% del bloque de preguntas de la 1 a la 8: a su organización podría resultarle útil buscar una certiica44

.PRÁCTICAS

PRUEBA DE SOFTWARE “CERTIFICARSE NO DEBIERA SER PECADO, TAMPOCO MERA PRESUNCIÓN.”

Atributos a considerar al certiicar software En el caso de querer evaluar la calidad de uno o más productos de software, ¿qué aspectos son los que debemos tomar en cuenta? En el artículo previamente publicado en SG titulado “Priorización de Atributos de Calidad en Sistemas Modulares Integrados” [5], se explican los atributos de calidad interna y externa del software que considera el estándar internacional ISO-IEC-9126 (NMX-I-9126-1NYCE en México). Dichos atributos son agrupados en seis características básicas de calidad que debieran estar presentes en un producto de software. A continuación listo dichas características y atributos. • Funcionalidad: Adaptabilidad, exactitud, interoperabilidad, seguridad de acceso. • Coniabilidad: Madurez, tolerancia a fallas, recuperación, conformidad de funcionalidad. • Usabilidad: Facilidad de comprensión, facilidad para aprender, operatividad, atractivo. • Eiciencia: Tiempo de respuesta, utilización de los recursos.

• Mantenibilidad: Facilidad de análisis, facilidad para introducir cambios, facilidad de prueba. • Portabilidad: Adaptabilidad, facilidad de instalación, coexistencia, facilidad de reemplazo.

Para evaluar dichos atributos de calidad, se contempla la aplicación de una gran cantidad y variedad de métricas, que ayudarán a conocer el nivel de cumplimiento y con ello, el nivel de calidad alcanzado por dicho sistema. En deinitiva, para conocer el nivel general de calidad logrado en los productos de software evaluados, la organización que provea un servicio tal de Certiicación de Productos de Software deberá tener desarrollado, implantado y sistematizado un modelo para aplicar dichos criterios y métricas, de modo que con bases fundamentadas pueda emitir un juicio de valor respecto a las evaluaciones que realice, y por cuyos resultados estará en condiciones o no, de emitir una certiicación o sello.

Conclusión La decisión sobre apostarle a una certiicación de Proceso de Pruebas, o a una de Personas (Testers) o a una de Producto, deinitivamente está en sus manos. Ante limitaciones en presupuesto, tal vez resulte conveniente concentrar gradualmente los esfuerzos en alcanzar primero alguna de ellas y posteriormente ir buscando alguna otra, solo si realmente es relevante para el negocio invertir en más de una de ellas. Y por supuesto, dicha decisión también debiera sustentarse en un inminente retorno de la inversión.

Referencias [1] León Carrillo, Luis Vinicio y Ruiz Eguino, Sandra Berenice. “Modelos de Calidad para Prueba de Software”, Software Gurú, Dic 2008. [2] Ruiz Eguino, Sandra Berenice y Silva, Armando. “TMMi: Un modelo especializado en pruebas”,

Software Gurú, Marzo 2011.

[3] Ruiz Eguino, Sandra Berenice. “El Modelo de Calidad Europeo TPI”. Software Gurú, Mayo 2009. [4] León Carrillo, Luis Vinicio y Ruiz Eguino, Sandra Berenice. Certificaciones Internacionales para Testers I y II, Software Gurú, Sep 2009 y Nov 2009. [5] González Álvarez, Larisa, Martín Cruañes, Roberkys y Rivero Álvarez, Tahirí. “Priorización de Atributos de Calidad en Sistemas Modulares Integrados”, Software Gurú, Oct 2012.

Software Guru

Adicionalmente se pueden considerar características de calidad asociadas especíicamente al uso de un software. Estas son: • Productividad. Que usar un software aumente nuestra productividad. • Efectividad. Que usar un software nos permita realizar tareas correctamente y sin errores. • Satisfacción. Que usar un software sea una experiencia satisfactoria. • Seguridad. Que podamos coniar en la seguridad de nuestra información cuando usamos un software.

www.sg.com.mx |

ción de su proceso de pruebas de software, si es que ya lo tiene deinido e implantado; de no ser así, habrá una ardua labor enfrente para comenzar a desarrollarlo, requiriendo inversión ya sea de recursos existentes, o además los de una consultoría especializada. Una vez deinido el proceso de pruebas, implantado y documentado algún proyecto piloto, su organización podría estar en condiciones de buscar alguna de las certiicaciones conocidas en modelos de Pruebas de Software (TPI, TMM, TMMi, etc.), como los que ya hemos explicado en ediciones anteriores de SG [1, 2, 3]. Si respondió airmativamente a las preguntas de la 9 a la 14: valdría la pena considerar la opción de apoyar a obtener una certiicación al personal de su organización dedicado a probar software. También en números anteriores de SG hemos aportado algunas consideraciones y recomendaciones acerca de las certiicaciones internacionales para testers [4]. Por ejemplo: certiicaciones en diferentes niveles, avaladas por organismos internacionales de testing como el ISTQB (International Software Testing Qualiications Board), o el QAI (Quality Assurance Institute), las cuales incluso son apoyadas en México con subsidios por medio del programa México FIRST. Finalmente, si sus respuestas al bloque de preguntas de la 15 a la 20 han sido airmativas: muy probablemente en su organización se tenga la necesidad de certiicar algún o algunos productos de software. Para ello, una alternativa sería encomendar dicha labor a algún tercero independiente e imparcial especializado en servicios de pruebas de software, y no sólo eso, sino muy particularmente en servicios de Certiicación de Software (o algún sello de calidad), de preferencia con reconocimiento internacional. De esta forma su organización podrá coniadamente demostrar a otros (clientes, prospectos, inversionistas, etc.) que su(s) producto(s) cuenta(n) con un sello de conianza por cumplir con atributos y características de calidad del software en apego a normas y estándares internacionales.

.PRÁCTICAS PROCESOS

Aplicando

Experimentación Científica

a la Ingeniería del Software ››Por Omar S. Gómez

a ingeniería de software (IS) es una disciplina joven donde, a diferencia de otras ingenierías, solemos construir sistemas no en base a leyes inmutables, sino en base a ideas o creencias, a las que llamamos “mejores prácticas”, pero ... ¿qué sustenta a dichas prácticas? En este artículo presentamos de manera general un enfoque experimental que podemos usar para sustentar con evidencia cientíica nuestras decisiones al construir sistemas de software. El experimento examina la duración y esfuerzo que conlleva la programación por pares.

Proceso de experimentación Así como en nuestra disciplina contamos con un proceso para construir software, en la experimentación se cuenta con un proceso para hacer experimentos. Este proceso consta básicamente de las siguientes fases: Idea, Deinición, Diseño, Ejecución y Análisis. Una de las doce prácticas de la programación extrema (XP) [1] consiste en programar por pares. Básicamente, esto consiste en que dos programadores trabajan juntos en una misma tarea usando una computadora. Uno de los programadores —quien toma el rol de controlador— escribe el código mientras que el otro programador —identiicado como observador— revisa de .BIO manera activa el trabajo realizado por el controlador con el in de detectar Omar S. Gómez es Ingeniero en Computación por la Universidad de posibles defectos. El observador Guadalajara, Maestro en Ingeniería de Software por el Centro de puede hacer anotaciones o deinir Investigación en Matemáticas y estrategias para llevar a cabo la tarea Doctor en Software y Sistemas por la Universidad Politécnica de Madrid. a realizar, también puede buscar refeActualmente es profesor en la Licenciatura en Ingeniería de Software rencias para ayudar a resolver alguna de la Universidad Autónoma de Yucatán. omar.gomez@uady.mx cuestión que se presente durante la realización de la tarea.

Se dice que el uso de esta práctica ayuda a producir programas más pequeños, implementar mejores diseños y que los programas contienen menos defectos que aquellos escritos de manera individual. Se dice también que la productividad al trabajar de este manera es mayor que si las personas trabajaran de manera individual.

Idea Dada la información que acabamos de leer sobre programación por pares, nos viene a la mente contrastar con hechos esta práctica para conocer de manera más coniable en qué medida se cumplen las bondades que de ella se mencionan.

Deinición El objetivo del experimento es evaluar la productividad al programar por pares, comparado con la programación individual. El estudio se realiza en el contexto de un aula con computadoras donde alumnos de la carrera en Ingeniería de Software de la Universidad Autónoma de Yucatán (UADY) realizarán dos programas ya sea por pares o de manera individual.

Diseño Básicamente se especiica cómo se asignan los tratamientos a los sujetos, el tipo de sujetos a emplear así como la preparación de instrumentos o materiales para ejecutar el experimento. En este experimento participaron 21 sujeto-estudiantes: 14 de ellos trabajaron en pares (siete pares) y 7 de manera individual. El experimento se dividió en dos sesiones, en cada sesión los sujetos codiicaron un programa diferente (variable de bloque). En la primera sesión los sujetos que trabajaron individualmente utilizaron el 46

.PRÁCTICAS PROCESOS

“EL OBJETIVO ES HACER DEL DESARROLLO DE SOFTWARE UNA ACTIVIDAD PREDECIBLE”

NetBeans IDE para codiicar el primer programa mientras que los sujetos que trabajaron en pares usaron como herramienta un editor de texto. En la segunda sesión se intercambió la herramienta de soporte (variable de bloque), los sujetos que antes trabajaron individualmente con NetBeans IDE ahora trabajaron con un editor de texto, mientras que los sujetos que trabajaron en pares codiicaron el segundo programa con NetBeans IDE. Para las sesiones del experimento se eligieron programas pequeños que los sujetos pudieran codiicar en cada sesión.

Análisis En esta fase se emplean diferentes técnicas estadísticas para analizar e interpretar las métricas generadas. Usualmente en el diseño de experimentos se emplea el análisis de la varianza (en inglés ANOVA). Básicamente el ANOVA se basa en examinar la variabilidad de las métricas recabadas y la variabilidad de otros elementos como pueden ser otras variables así como el error experimental. La Tabla 1 muestra de manera resumida los resultados tras aplicar dos ANOVAS, una por cada métrica.

La Tabla 2 muestra las diferencias obtenidas (pares y solos) en minutos con respecto a la duración y esfuerzo. Como se observa en esta tabla, se obtuvo una diferencia de 36 minutos a favor de la programación por pares, lo cual signiica un ahorro del 28%. Con un nivel de conianza del 95%, esta diferencia puede variar de 6 a 66 minutos (ahorro del 4% al 51%). A pesar del ahorro en tiempo obtenido en la programación por pares, al tomar en cuenta el esfuerzo medido en minutos-persona, la programación individual tiene una ventaja de 56 minutos (30% menor) sobre la programación en pares. Este valor puede variar de 8 a 104 minutos (decremento de 4% a 55%).

Tabla 2. Diferencias entre pares y solos respecto a duración y esfuerzo

Conclusiones

Tabla 1. Valores p obtenidos tras el análisis de la varianza

El ANOVA usa un tipo de prueba conocido como prueba F de Fisher que ayuda al investigador a determinar si hay o no una diferencia signiicativa entre los tratamientos examinados en el experimento. El valor p es la probabilidad de obtener un resultado (en este caso F) al menos tan extremo como el observado. Usualmente el investigador deine un valor crítico llamado alfa (α) para contrastarlo con el valor p observado. Si un valor p es menor o igual al valor alfa entonces la hipótesis nula es rechazada. La Figura 1 muestra los histogramas con las medias de los tratamientos respecto a la duración y esfuerzo.

En este artículo mostramos un ejemplo de cómo aplicar experimentación científica para evaluar prácticas de ingeniería de software. Las organizaciones desarrolladoras de software podrían aplicar experimentos como este para sustentar decisiones sobre prácticas que quieran institucionalizar o tecnologías que deseen evaluar antes de institucionalizarlas. Para concluir, en palabras de Pfleeger, llevar a cabo experimentos en IS nos permitirá aumentar la comprensión de qué hace ser a un software bueno y cómo construir software bien.

Referencias [1] K. Beck. Extreme Programming Explained: Embrace Change. Addison Wesley Professional, 1999. [2] G.E.P. Box et al. Statistics for Experimenters: An Introduction to Design, Data Analysis, and Model Building. John Wiley & Sons, 1978.

Software Guru

Los sujetos registraron el tiempo de inicio y inal que les llevó codiicar el programa. La diferencia de estos tiempos (calculada en minutos) se usó como métrica para obtener la duración y el esfuerzo. Respecto a la métrica de esfuerzo, que mide la cantidad de trabajo gastado para realizar una tarea (en este caso persona-minuto), se duplicó el tiempo usado por los pares.

Figura 1. Resultados

www.sg.com.mx |

Ejecución

.COLUMNA CÓDIGO INNOVARE

Desarrollo Dirigido

por Modelos y Ontologías

l surgimiento y evolución de plataformas y tecnologías de desarrollo de software, la evolución del hardware, las nuevas formas de interacción humano-computadora, los avances en el cómputo móvil, el incremento de los usuarios de los sistemas y de los datos que deben gestionar y el surgimiento de la Web de datos, son algunas de las razones por las cuales los sistemas de software son cada vez más complejos. Un medio para manejar esta complejidad y continuar proporcionando sistemas que soporten las nuevas y crecientes necesidades del mercado, es el llevar a cabo el desarrollo de software utilizando métodos apropiados de abstracción [1]. En este contexto, un paradigma de desarrollo de software que se ha vuelto popular en la academia y M.C. Karen Mariel Nájera Hernández la industria en los últimos años es el Desarrollo Dies egresada de la rigido por Modelos (Model Driven Development Universidad Autónoma de Puebla – MDD). MDD basa el desarrollo de software en de la carrera Ingeniería en Ciencias la construcción de modelos conceptuales que desde la Computación. Obtuvo el criben el sistema a desarrollar (estructura del sistegrado de Maestra ma, comportamiento, estructura de datos, aspectos en Ciencias en en la especialidad de de presentación, etc.). Es parte de un modelo que Tecnologías Web por el Centro de conceptualiza el dominio del problema, y de maneInvestigación y ra sistemática este modelo se va transformando en Desarrollo Tecnológico (CENIDET) otros modelos de niveles de abstracción más bajos, en donde en conjunto con la hasta generar implementaciones concretas. Fundación Bruno Kessler (Italia) Mientras más completa y precisa sea la especidesarrolló trabajos icación de las funcionalidades de un sistema en los de investigación enfocados modelos, mayor será el porcentaje del código fuente al modelado organizacional y del sistema que se podrá generar automáticamente. ontologías. Actualmente colabora en proyectos para la web semántica en la Gerencia de Desarrollo de Nuevos Productos en INFOTEC. karen.najera@ infotec.com.mx

Para la construcción de modelos se cuenta con: • Lenguajes de modelado de propósito general (GPLs), que soportan el modelado de cualquier dominio. Un ejemplo de GPL sería UML (Uniied Modeling Language). • Lenguajes de modelado de dominio especíico

(DSLs), los cuales se deinen especíicamente para un dominio, como el proporcionado por EAGLE (Easily Applicable Graphical Layout Editor), un software de modelado, creación y simulación de circuitos electrónicos. Para llevar a cabo las transformaciones entre modelos se deinen conjuntos de reglas de transformación que describen cómo es que los elementos de un modelo pueden ser transformados en elementos de otro modelo de menor nivel de abstracción. Las reglas pueden ser reusadas para transformar nuevos o distintos modelos y además pueden ser implementadas para realizar el proceso de transformación de manera automática. El lujo común de transformaciones se presenta en la igura 1. Se inicia con el modelo de más alto nivel de abstracción que generalmente corresponde a la conceptualización del dominio del problema, el cual es transformado a modelos de más bajo nivel de abstracción mediante transformaciones Modelo a Modelo (M2M) y inaliza con una transformación de Modelo a Texto (M2T) que como resultado arroja el código fuente del sistema.

Figura 1. Flujo de transformación de modelos.

Dentro de las ventajas de MDD se encuentra la generación automática de código, mayor calidad en implementación (menos defectos), desarrollo ágil: aplicación de cambios rápido y fácil, permitiendo la evolución y el mantenimiento del sistema de una forma más simple; reúso de código y/o modelos. El proyecto de modelado de Eclipse [2] se enfoca en la evolución y promoción de tecnologías de desarrollo basadas en modelos dentro de la comunidad de Eclipse. Utiliza como base la 48

.COLUMNA CÓDIGO INNOVARE

›› “LAS ONTOLOGÍAS PROPORCIONAN UN ENTENDIMIENTO COMPARTIDO DEL DOMINIO DEL PROBLEMA.”

Una de las tendencias actuales en la ingeniería de software es el uso de ontologías como parte del proceso del desarrollo dirigido por modelos, es decir, como medio para representar los modelos conceptuales que deinen al sistema a desarrollar en el paradigma MDD. Una ontología representa un modelo abstracto que identiica los componentes más relevantes de cierto fenómeno del mundo real, y los describe en un lenguaje formal, es decir, que puede ser entendido por una computadora, a través de conceptos, propiedades, relaciones, funciones, restricciones y axiomas. La ventaja principal del uso de ontologías como modelo en MDD es que en una sola ontología es posible representar la estructura del sistema, su comportamiento y el modelo de datos, además de describir la lógica de negocio y restricciones de software en el mismo modelo. Entre otras ventajas del uso de las ontologías, además de las que por defecto se heredan de MDD, se encuentra que proporcionan un entendimiento compartido del dominio del problema y una especiicación formal de los requisitos de un sistema, lo que permite el reúso de deiniciones existentes de conocimiento del dominio; además proporcionan mayor soporte para inferencias lógicas, y la integración e interoperabilidad con otros componentes o aplicaciones. SemanticWebBuilder (SWB) [4] es una plataforma para el desarrollo de software implementada en INFOTEC. SWB parte de una ontología (deinida en el lenguaje estándar de la Web Semántica OWL - Web Ontology Language) y a partir del conocimiento modelado en la ontología se genera automáticamente código en lenguaje Java que representa la arquitectura base del sistema a desarrollar. Los datos del sistema resultante son representados en el formato de la Web semántica (RDF) por lo que pueden ser procesados por computadoras y consumidos a través de la Web.

Estos sistemas, además de ser generados bajo el paradigma de MDD, también proporcionan el mecanismo bajo el mismo paradigma, para ser extendidos con funcionalidades especíicas a partir de requisitos especiicados en una ontología.

Conclusión En conclusión, el desarrollo dirigido por modelos es un paradigma visto, por muchos, como la mejor opción para incrementar el nivel de abstracción en el cual construimos, mantenemos y razonamos sobre el software. Su aplicación se encuentra en constante crecimiento debido a las ventajas que ofrece al ciclo de vida del software principalmente la automatización del desarrollo de sistemas y la reutilización de componentes desde los niveles de abstracción más altos hasta la codiicación de la solución. El uso de ontologías como punto de partida para el desarrollo de software permite la representación de la información contenida en el sistema en un formato deinido por un lenguaje formal que puede ser interpretado y procesado por personas y/o sistemas. Por lo tanto, es posible aplicar técnicas de inferencia a los datos para por ejemplo, generar nuevo conocimiento y obtener predicciones, útiles para toma de decisiones. Además, se pueden aplicar mecanismos Web para exponer la información del sistema en la Web Semántica, y explotar los datos con los nuevos paradigmas de la Web Semántica como Linked Data.

>> Por Karen Mariel Nájera Hernández

Referencias [1] B. Anda, et al. “Experiences from Introducing UML-based Development in a Large Safety-Critical Project”. Emprical Software Engineering, vol. 11, pp. 555-581, 2006. [2] Eclipse Modeling Project. http://www.eclipse.org/modeling [3] OMG MDA. http://www.omg.org/mda [5] SemanticWebBuilder. http://www.webbuilder.com.mx

Software Guru

Las ontologías como modelos en el proceso de desarrollo

La plataforma SWB ha servido de base para la construcción de sistemas de diferentes dominios. Entre los productos creados con SWB están: • SWBPortal, un sistema de gestión de contenidos con licencia de código abierto para desarrollar y administrar portales de internet con tecnología semántica. • SWBProcess, un sistema de gestión de procesos de negocio semántico que parte de modelos de procesos descritos con el estándar BPMN 2.0 y a través de transformaciones de BPMN 2.0 a ontologías y de ontologías a código en lenguaje Java proporciona la implementación necesaria para la ejecución de los procesos.

www.sg.com.mx |

Arquitectura Dirigida por Modelos (Model Driven Architecture - MDA) [3] una iniciativa presentada por el Object Management Group (OMG) que soporta el paradigma de MDD. MDA se enfoca en el uso de tecnologías interoperables que soportan el desarrollo dirigido por modelos con transformaciones automáticas y para ello deine un conjunto de estándares (UML, MOF, OCL, QVT, XMI). El proyecto de modelado de Eclipse proporciona: frameworks de modelado y de generación de código automático para desarrollar aplicaciones basadas en modelos de datos estructurados, componentes e infraestructura en tiempo real para el desarrollo de editores gráicos, un lenguaje para deinir reglas de transformación (ATL), etcétera.

.COLUMNA PROGRAMAR ES UN ESTILO DE VIDA

Aaron Swartz, el Acceso Abierto y los Estándares

aron Swartz fue un joven entusiasta de la programación, irme creyente de la necesidad de la libre circulación de la información. Su vida tiene muchos momentos dignos de nota, los puntos más relevantes incluyen: • Participó en la creación de la especiicación RSS 1.0 (W3C RFC 3870) a los 14 años de edad. • Fue co-autor del lenguaje de marcado Markdown, diseñado para hacer más natural a un usuario no técnico preparar páginas Web que lo que hasta entonces permitía el HTML. • Es uno de los creadores de la iniciativa Creative Commons, un conjunto de licencias orientadas a facilitar a los creadores elegir un marco que permita la libre circulación de los bienes culturales, sin renunciar a sus derechos autorales. • Participó en la creación del sitio sindicador de noticias sociales Reddit, uno de los primeros sitios en aprovechar la interacción viral y en deinir lo que hoy conocemos como temas tendencia (trending topic). • Estuvo involucrado en diversas campañas oponiéndose a las propuestas legislativas encaminadas a la restricción de las libertades individuales en línea, entre las cuales destaca SOPA • Creó la Open Library, populándola con la información bibliográica completa de la Biblioteca del Congreso de los Estados Unidos. Previamente, a pesar de que dicha información era legalmente del dominio público, se cobraba por su acceso. • Descargó en 2008 la base de datos completa de registros judiciales públicos (PACER), otro caso de información legalmente del dominio público pero restringida por un cargo por acceso. Donó los archivos resultantes a http://public.resource.org, siendo este el primer caso que le mereció ser abiertamente investigado por el FBI, aunque el caso fue cerrado sin presentarle cargos después de dos meses.

Dentro de su lucha por la puesta a disposición irrestricta de la información pública, entre 2010 y 2011 descargó cerca de cuatro millones de artículos académicos del repositorio JSTOR, aprovechando la política de «campus abierto»[1] que sostenía el MIT. Los artículos en cuestión provenían mayormente de investigaciones realizadas con fondos públicos, por lo que deberían ser para beneicio de la sociedad entera, pero por las diversas distorsiones que sufre la publicación cientíica formal, para tener un factor de impacto deseable para sus autores, tienen que ser publicadas en revistas especializadas que (cada vez menos, pero aún por regla general) ejercen una política intransigente de control de derechos de autor. En julio de 2011 fue acusado formalmente por esta descarga de actividad criminal. Si bien JSTOR retiró su demanda, las autoridades judiciales continuaron persiguiéndolo de oicio — La iscal Carmen Ortiz buscó repetidamente incarle una sentencia de hasta 35 años de cárcel y una multa de hasta un millón de dólares, equiparando sus acciones con actos terroristas. Ante esta presión (y con antecedentes de depresión severa), el pasado 11 de enero Aaron Swartz se suicidó. Gunnar Wolf es administrador de sistemas para el Instituto de Investigaciones Económicas de la UNAM y desarrollador del proyecto Debian GNU/Linux. http://gwolf.org

Las ideas sobreviven Aaron, del mismo modo que muchos de los activistas del movimiento del software libre, fue encontrando la necesidad ética de actuar para fomentar la libre circulación y correcta preservación a largo

plazo del conocimiento. Para muchos de nosotros, el movimiento del conocimiento libre es sencillamente la consecuencia lógica del movimiento del software libre, y surge naturalmente (y con las mismas premisas) una vez que el acceso a Internet llega a toda la sociedad. A in de cuentas, el código es sólo una herramienta de expresión y comunicación humana (aunque tenga la restricción de un lenguaje formal, de ser interpretable por una computadora). El ideario completo de la Fundación del Software Libre puede aplicarse a cualquier otra área del conocimiento —y tenemos hoy las herramientas para que la circulación del conocimiento no sólo resulte irrestricta, sino que a un costo de reproducción prácticamente nulo. En sus 26 años de vida, Swartz contribuyó con buena parte de la implementación técnica y activismo social necesarios para impulsar al movimiento del Acceso Abierto (Open Access) [2]. Los diversos protocolos y sitios con los cuales él contribuyó quedan no sólo como legado, sino como indicador de cómo y hacia dónde un joven brillante vio que podríamos, y deberíamos, avanzar.

El acceso abierto y estructurado Un corolario fundamental del acceso abierto es que la información, para ser útil, debe estar adecuadamente organizada y clasiicada. Simplemente volcar millones de artículos cientíicos (o programas de computadora, obras culturales o literarias, arte, etc.) en un espacio sin estructura no sirve de mucho. Ahogarse en un mar de información resulta casi tan inútil como no tener acceso a ella. Es por eso que el Open Access va casi siempre de la mano del empleo de herramientas de clasiicación, redistribución y agregación basadas en estándares ampliamente reconocidos. Hay muchos sitios (incluyo entre ellos, por cierto, al de nuestra revista SG) destinados a la difusión de información con importantes cuerpos históricos. Si bien aplaudo y agradezco la decisión de Software Gurú de ofrecer el acervo histórico de ya ocho años de trabajo, para que esta información sea verdaderamente útil debería comprometerse a mantener URLs estables a largo plazo y adherirse a un esquema de publicación de material bibliográico. Muy probablemente, el esquema más adecuado sería el DublinCore[3]. Este estándar permite la indexación, cosecha y agregación de repositorios por medio de protocolos como el OAI-PMH[4]. ¿Qué signiica semejante verborragia de siglas? Signiica que, para que la información resulte de utilidad para el avance técnico-cientíico, no podemos solamente coniarnos al criterio de los “indexadores” de los motores de búsqueda. Siguiendo un poco la retórica de Tim Berners-Lee impulsada con el título de Web semántica, extiende la red de páginas hipervinculadas legibles por humanos, insertando metadatos legibles por computadora acerca de las páginas y sus interrelaciones, permitiendo a los agentes Web entenderlas más inteligentemente y realizar tareas en nombre de los usuarios. Si bien hay críticas bien fundadas a la propuesta de Berners-Lee, para información tan estructurada como una revista de publicación periódica como esta, el modelo de metadatos DublinCore se ajusta perfectamente. El Instituto de Investigaciones Económicas de la UNAM, donde trabajo, participa del proyecto de Red de Acervos Digitales (RAD-UNAM) [5]. Hemos ido creando un acervo interdisciplinario con diversas entidades universitarias que, por medio de OAI-PMH, ofrece una colección uniicada y distribuida con miles de objetos académicos de gran diversidad, rescatándolos en buena medida del olvido y de la inaccesibilidad. 50

>> Por Gunnar Wolf Nota del editor: Gracias por la recomendación, Gunnar. Sin duda nos interesa mejorar la organización, identiicación y permanencia de los contenidos que hemos publicado.

Referencias [1] Política que permitía a cualquier usuario externo conectar una computadora de su propiedad en la red universitaria y aprovechar los convenios que ésta tenía subscritos. Podemos encontrar políticas similares en todas las principales universidades, partiendo de la premisa de facilitar la labor académica y reducir trámites. [2] Por si se van perdiendo en la sopa de letras de movimientos libertarios, Open Access busca el libre acceso a publicaciones académicas. [3] Dublin Core Metadata Initiative. http://dublincore.org [4] Open Access Initiative Protocol for Metadata Harvesting. http://www.openarchives.org/OAI/ openarchivesprotocol.htm [5] Repositorio Institucional RAD-UNAM http://rad.unam.mx

Software Guru

www.sg.com.mx |

Software Guru va más allá de ser una revista — El cuerpo de noticias del ramo, whitepapers y congresos presenciales y virtuales podrían sumarse al cuerpo de conocimiento disponible y sistematizado publicado en nuestro país, impulsando de este modo su visibilidad y el impacto de lo aquí publicado. Del mismo modo, otras revistas (sean más formales o menos formales, impresas o en línea), boletines, congresos y demás actividades de nuestra área de conocimiento podrían beneiciarse de adoptar estos estándares. Un repositorio correctamente descrito puede ser cosechado enfatizando en diferentes facetas. El esfuerzo para lograrlo, cierto, no es despreciable, Pero tengo la certeza de que Software Gurú tendría mucho por ganar. Y más que nuestra revista: Sé que muchos de quienes aquí escribimos, y quienes trabajan con dedicación brindándonos este espacio, más que por ganancia personal, lo hacemos en un afán de contribuir con nuestro granito de arena a la sociedad, y si bien la revista tiene su carga técnica, muchos de nosotros aspiramos a contribuir a la profesionalización de nuestro gremio, a una introspección acerca del rol y la responsabilidad social que cargamos. A los pocos días de la muerte de Aaron Swartz, cientos de académicos hicieron públicas copias de sus artículos secuestrados por las editoriales cientíicas restrictivas como un tributo al trabajo de este joven idealista y activista. En una especie de paralelo, espero poder impulsar un poco más a través de este texto el conocimiento de las herramientas (y no sólo los principios éticos) que puedan permitir que el acceso abierto y pleno al cuerpo de conocimiento generado por los especialistas sea puesto al servicio de la humanidad toda de forma más efectiva.

.FUNDAMENTOS

Cómo Distinguir entre un Riesgo y un Problema

››Por Iván Carlos Rivera González

odo administrador de proyectos debe enfrentar en su trabajo diario la administración de riesgos, y parte fundamental de esto es saber distinguir cuando una situación es un riesgo o un problema, y administrarlo de forma adecuada. Como señala Madsen [1], “La administración de riesgos y problemas es fundamental en el trabajo del administrador de proyectos”. Es una actividad que debe realizarse en forma semanal y de ser necesario, diaria”. Se requiere proactividad para identiicar y controlar las situaciones de riesgo antes de que se conviertan en problemas; por lo que es importante distinguir estos conceptos. A continuación comparto algunas deiniciones extraídas de la edición más reciente del PMBoK [2]. • Incidente (Issue): Punto o asunto bajo cuestionamiento o disputa; punto o asunto que no se ha resuelto y está bajo discusión. También conocido como asunto, polémica o punto de atención. • Riesgo (Risk) es un evento o condición incierta que, si se produce, tiene un efecto positivo o negativo en los objetivos de un proyecto. Adicionalmente, el Instituto Nacional de Estándares y Tecnología de EU deine el riesgo como “la medida en la que una entidad es amenazada por una circunstancia o evento potencial, en función de (i) los impactos adversos que se presentarán si la circunstancia o evento ocurre: y (ii) la probabilidad de ocurrencia” [3]. El riesgo inherente es el riesgo que existe en el ambiente alrededor de un proyecto y es exclusivo de la organización ejecutante, de su cultura y políticas. Por ejemplo, en un negocio fragmentado (ya sea geográica o funcionalmente), hay un riesgo inherente de falta de comunicación. Existen riesgos especíicos del proyecto derivados de la naturaleza de lo que se está haciendo. También hay ciertos riesgos comunes a cualquier proyecto, por ejemplo, la falta de familiaridad de los usuarios con la tecnología que se va a implementar. Por último, hay riesgos asociados a la actividad particular de cualquier fase del plan del proyecto. Como señala Farragut [4], hay que hacer hincapié en el aspecto de incertidumbre o probabilidad de riesgo. Otros autores consideran que la principal diferencia entre un problema y un riesgo es el tiempo y el nivel de impacto en el proyecto: los problemas son los acontecimientos actuales que tienen poco efecto sobre el proyecto y su solución general es fácil, mientras que los riesgos son eventos futuros que pueden tener graves efectos sobre el proyecto y su solución requiere de ingenio. Esto quiere decir que no todos los riesgos se convertirán en problemas y es trabajo del administrador de proyectos gestionar para mantener este control tratando de impedir la materialización de un riesgo o minimizar / gestionar / neutralizar el impacto de este riesgo una vez que se ha materializado. La tabla 1, tomada de Farragut [4] ofrece una comparación entre riesgos y problemas:

RIESGO

PROBLEMA

Un recurso crítico podría dejar

Un miembro del equipo ha

el proyecto a la mitad de su

renunciado a la compañía. Su

ejecución.

último día de trabajo es el próximo viernes.

Los miembros del equipo de

Nadie sabe exactamente cuando

trabajo podrían tomar vacacio-

los miembros del equipo toma-

nes durante las etapas críticas

rán sus vacaciones.

del proyecto. Podrían ocurrir cambios en los

Acaba de ser identificada una

requerimientos que no hayan

nueva funcionalidad que ne-

sido anticipados.

cesita agregarse al alcance del proyecto.

El análisis de impacto podría

El análisis de impacto descubrió

descubrir que se deben hacer

dos nuevos cambios que obligan

cambios que aceleren las fechas

a adelantar una semana la fecha

de entrega.

de entrega de proyecto.

Existe la posibilidad de que la

La organización ejecutante es

productividad disminuya si el

matricial, para reducir la confu-

proyecto se ejecuta en una orga-

sión sobre la autoridad y respon-

nización matricial.

sabilidad del Administrador del Proyecto se deben desarrollar documentos que describan el rol con precisión.

Tabla 1. Comparación entre riesgos y problemas

Otro ejemplo de un riesgo es: “No se podrá completar el proyecto a tiempo si la pieza que se necesita no llega a tiempo.” No estamos seguros de que tenemos un problema todavía. Pero sabemos que si la pieza que necesitamos no está disponible cuando sea necesaria, entonces tendremos un problema. Un riesgo del proyecto afectará el costo, el cronograma, el alcance o la calidad del proyecto. Si el riesgo no se materializa hasta después de que el proyecto ha terminado, entonces no es un riesgo para el proyecto. Puede ser un riesgo para el programa u organización, pero no del proyecto. Lo mismo puede decirse de un problema. ¿Afecta a los aspectos que son responsabilidad de administrador del proyecto? Si no, entonces debe ser manejado por los responsables del programa o de la organización. A continuación un ejemplo de un riesgo que no pertenece al proyecto: “El sistema que estamos construyendo está diseñado para 100 usuarios concurrentes, pero si se conectan más puede correr lento o incluso fallar.” Si el proyecto termina cuando el sistema se ha implementado, entonces este riesgo no se producirá durante el proyecto. Si los requisitos del sis52

Debido a que riesgos y problemas se tratan de manera diferente, entender la diferencia entre ellos ayuda a enfocar el tiempo y energía del equipo de trabajo. En la sección de referencias comparto enlaces a bibliografía que será de gran utilidad si te interesa aprender más sobre este tema. Referencias [1] S. Madsen. “Risk management is how adults manage projects”. http://swgu.ru/sg39r1 [2] A Guide to the Project Management Body of Knowledge (PMBoK Guide), 4th edition. 2008. [3] R.S. Ross. “Guide for Conducting Risk Assessments”. National Institute of Standards and Technology (NIST). Septiembre, 2012. http://swgu.ru/sg39r4 [4] “Do you know the diference between an issue and a risk?”. http://swgu.ru/sg39r5

.BIO Iván Carlos Rivera González tiene una Maestría en Administración de TI por el Tecnológico de Monterrey, es SCPM (Stanford Certified Project Manager), certificado como PMP. Su experiencia incluye administración de proyectos, planeación estratégica, desarrollo de aplicaciones, administración de redes y telecomunicaciones. Se dedica a dirigir proyectos para sus clientes, comunicar y coordinar equipos de trabajo. http://ivanrivera-pmp.com

www.sg.com.mx |

CONCLUSIÓN

Software Guru

tema dicen que tiene que soportar 100 usuarios simultáneos y el sistema los soporta, entonces no es un riesgo del proyecto. El riesgo de tener más usuarios de los esperados y las consecuencias posteriores son del dominio de las operaciones de negocio, no del proyecto. Desde el punto de vista del proyecto es más bien una falla en la deinición del alcance. Los riesgos se documentan cuando se descubren; es de esperar que la mayoría se documenten al inicio del proyecto. Luego se evalúan la probabilidad y el impacto para agregar al plan del proyecto las tareas de mitigación. Se puede crear un plan de contingencia para documentar lo que planeamos hacer en caso de que se materialice un riesgo. Ya que se está ejecutando el proyecto, es importante hacer un seguimiento regular sobre las acciones implementadas de seguimiento y control de riesgos y validar que estas realmente ayudan a reducir el peril de riesgo general del proyecto. Y si eventualmente los riesgos se materializan a pesar de las acciones de prevención, entonces se convierten en problemas. Sobre los problemas hay que actuar en forma inmediata. Las acciones sugeridas pueden involucrar la adición de tareas con el plan, la ampliación del calendario o el aumento del presupuesto. Se les da seguimiento tomando acciones hasta que son resueltos y ya no afectan al proyecto.

.PERSONAS CARRERA

Certificaciones Profesionales

VALOR Y LIMITANTES

››Por Pedro Galván

n esta edición de SG hemos platicado ampliamente sobre certiicaciones profesionales. Este es un tema que tiende a generar polaridad, con algunos fuertemente a favor y otros fuertemente en contra. Por ser del interés de la industria, la mayoría de los artículos publicados en estas páginas promueven las certiicaciones como algo positivo. Sin embargo, estamos conscientes de que también hay muchas personas que ven a las certiicaciones como algo negativo. A continuación comparto mi análisis personal sobre el valor y limitaciones de las certiicaciones profesionales.

profesionistas talentosos normalmente están construyendo software, y no sería práctico que fueran ellos quienes se dediquen a detectar candidatos para reclutar —sí está bien, y de hecho es deseable que los desarrolladores experimentados se involucren en las etapas inales de entrevista a candidatos, pero no que sean ellos quienes identiiquen candidatos de entre cientos de currículums. Se requiere que los reclutadores y personal de RH puedan realizar por lo menos un primer nivel de iltrado, y las certiicaciones los ayudan a hacer esto.

La necesidad

Habiendo dicho que las certiicaciones profesionales tienen su utilidad, también debemos reconocer que tienen varias limitantes. Aquí algunas de ellas: • No todas las personas tienen acceso a certiicaciones, debido al costo que involucran (aunque al menos en México esto es mitigado en cierto grado con programas como Mexico FIRST). • A pesar de que parezca haber una gran variedad, la realidad es que solo existen programas de certiicación para un conjunto reducido de tecnologías/especialidades. Por ejemplo, a pesar de su popularidad, al dia de hoy no existe un programa oicial de certiicación para desarrollo en iOS. • El nivel de rigor entre programas de certiicación varía. Por un lado tenemos programas como el de Scrum Master (que hasta hace poco consistía en tomar un curso de 2 días y con eso estabas certiicado) y por otro programas como el de PMP que involucran comprobar experiencia previa, capacitación, pasar un examen y luego realizar actividades de aprendizaje de manera continua para mantener tu estatus.

Para explicar mi percepción sobre las certiicaciones, primero les platicaré sobre cómo escojo una botella de vino. Sé que esto parece no estar relacionado, pero pido su paciencia. Personalmente, aunque disfruto tomar una copa de vino de vez en cuando, la verdad es que conozco muy poco sobre la calidad de los vinos; es decir, conozco algunas cosas básicas sobre los tipos de uvas y sus sabores, pero no sabría decir si cierta región produce mejores vinos que tal otra, y mucho menos si cierto año fue bueno o no. Adicionalmente, no me gusta estar tomando siempre el mismo vino, me gusta experimentar. Esto presenta un reto cada que compro una botella de vino: ¿Cómo puedo maximizar la probabilidad de escoger una botella que me guste? No soy un experto en el tema que pueda identiicar un buen vino simplemente viendo de qué región y año es. Tampoco es posible estar abriendo y probando todas las botellas para ver cual me gusta. Es así que mi proceso de decisión típicamente consiste en: 1) Elegir el rango de precio que estoy dispuesto a pagar, y 2) Seleccionar alguno de los vinos en ese rango que tenga algún comentario especial de parte de un tercero, tal como “Selección de nuestro catador”, o “Vino del mes por la revista X”. Un proceso similar es el que deben realizar los reclutadores de TI: necesitan reclutar profesionistas en temas altamente especializados, sin ser ellos expertos en dichos temas. No pueden entrevistar a todos los candidatos posibles porque no sería práctico. A partir de cientos, o miles de candidatos, deben generar una “lista corta” de candidatos con mayores probabilidades de cumplir las expectativas del cliente (ya sea interno o externo). Así que recurren a la validación de un tercero, es decir una certiicación. Entonces, creo que debemos reconocer que si las certiicaciones profesionales existen y son usadas, es porque resuelven una necesidad. La necesidad es darle a los reclutadores un mecanismo para conocer de manera rápida y comparable el nivel de conocimientos de una persona en cierto dominio. Es cierto que un profesionista experimentado puede reconocer a otros profesionistas talentosos rápidamente, tan solo platicando con éste unos minutos o simplemente leyendo algunas de las entradas en su blog. El problema con este mecanismo de detección es que los

Limitaciones

Por otro lado, también debemos reconocer que así como habrá vinos muy buenos de los que tal vez no nos enteremos porque no quisieron entrar al programa de recomendaciones, va a haber muy buenos profesionistas que no están certiicados. De hecho, los mejores desarrolladores de software raramente están certiicados, simplemente porque no lo necesitan.

Conclusión En esencia las certiicaciones son tan solo un mecanismo para que las personas que carecen de reputación o experiencia comprobable, puedan demostrar un nivel de conocimiento básico en cierta área. En sí, las certiicaciones profesionales no son algo negativo, el error ha sido pretender que sean una medida absoluta e inequívoca sobre la capacidad de un profesionista. .BIO Pedro Galván (@pedrogk) es cofundador y editor de SG Software Guru.

Directorio ALPHA CONSULTORIA

www.alpha-consultoria.com

ATL

www.atl-capacitacion.com.mx

Cutter Consortium

Testing IT

SG Buzz

SG Campus

www.sgcampus.com.mx 07

www.innevo.com

JPE Consultores

sg.com.mx

www.infotec.com.mx

Innevo

Stratominds

www.testingit.com.mx

www.ithink.mx

Infotec

www.stratominds.com

www.cutter.com.mx/eventos

I Think Soluciones

SEAN www.seanmexico.com

SG Eventos

sg.com.mx/eventos-sg 36

www.jpeconsultores.com

México First

www.mexico-first.org

NYCE

www.nyce.org.mx

Pronatura

www.pronatura.org.mx

RedHat

mx.redhat.com

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

Software Guru

www.praxis.com.mx

www.sg.com.mx |

Praxis

.SG MARKET

ANÚNCIATE AQUÍ

SG MARKET Excelente oportunidad para llegar a más de 20mil lectores a nivel habla hispana.

¡No la dejes pasar! Contáctanos:

publicidad@sg.com.mx

www.sg.com.mx |

Software Guru