SG31 (Marzo-Abril 2011) by Revista Software Guru

Integrando TSP y CMMi

Diseño Arquitectónico

Lean-Agile y Kanban

P.38

P.42

P.44

No.

Un Vistazo a

Ruby on Rails

CONOCIMIENTO EN PRÁCTICA Marzo-Abril 2011 www.sg.com.mx

G A P

N E OS

Haz

de o i c o g ne

Ap s u t e sd

ni O: Mí D N E ENDI EMPR

México, $65.00

ducto o Pro

A E LÍN

Viab

lez

encil

S ad y d i r a l D: C ILIDA B A S le / U

CONOCIMIENTO EN PRÁCTICA

Pág.

31 .CONTENIDO Marzo-Abril 2011 |

www.sg.com.mx

En Portada Pagos en Línea

En esta ocasión nos enfocamos en cómo poder recibir pagos y facturar desde tus aplicaicones en Internet.

Columnas Tejiendo Nuestra Red

por Hanna Oktaba

Mejora Contínua

por Luis Cuellar

Tendencias de Software

por Luis Daniel Soto

Columna Invitada

por Ignacio Mendivil

Programar es un Estilo de Vida

por Gunnar Wolf

Prueba de Software por Sandra Berenice Ruiz

.CONTENIDO

SG 31

Productos Lo que Viene

Gemstone Appcelerator jBPM 5 Sinatra

Un vistazo a Desarrollando con Ruby on Rails

Conoce por qué esta tecnologia está cobrando tanta popularidad.

En Cada Número Pág.

16 Emprendiendo

Mínimo Producto Viable (MPV)

Editorial

Noticias

Tecnología 16

Conocerás de cerca éste estrategia clave para ayudar a los startups a construir su producto mientras aprenden lo que el mercado necesita.

Infraestructura

52 54

Prácticas Usabilidad La importancia de la claridad y sencillez de la interfaz

Claves para conquistar la satisfacción del cliente

Gestión de procesos Integrando TSP y CMMi

Estrategias para hacer sinergia desde lo individual hasta lo colectivo

Arquitectura Evaluación de la arquitectura de software

Entendiendo y cuestionando el diseño arquitectónico

Agilidad Apropiación de Lean-Agile y Kanban Para el desarrollo tecnologías y contenidos de la educación en línea

www.sg.com.mx |

Software Guru

Gadgets

.EDITORIAL Bienvenida

Tendencias que impactan la forma de vivir y hacer negocios

“El ciberespacio es un terreno fértil y perfecto para los forajidos”

n esta edición de Primavera 2011, les traemos artículos que demuestran cómo la tecnología de información sigue y seguirá impactando en la forma de vivir y hacer negocios. Como dijo John Perry Barlow: “El ciberespacio es un terreno fértil y perfecto para los forajidos y las nuevas ideas sobre libertad” por lo que aunque nuevas tendencias se suman todos los días a nuestra industria, sigue siendo un terreno fértil y perfecto en el cual se abren oportunidades y se rompen las fronteras, transformando así las relaciones sociales y de negocios. Ejemplo de lo anterior es la serie de artículos principales de ésta edición que lleva por tema “Pagos en línea” en los cuales buscamos ayudarte para que comiences a implementar cobro y facturación desde tus aplicaciones. Así como la primavera es una invitación a despertar, cada una de nuestras ediciones es una invitación a explotar el potencial de nuestros lectores, por lo que los invitamos a que continuen proponiendo contenidos y colaborando con SG. Para este 2011 tenemos planeados grandes cambios, entre ellos el regreso de la 5ta. edición del congreso SG Conference & Expo, y la 2da. edición del congreso virtual SG Virtual Conference, eventos en los que esperamos contar con tu presencia. Finalmente queremos dar la bienvenida al equipo de SG a Vanessa Amaya, quien estará a cargo de la coordinación editorial de la revista.

››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, Alexis Ramírez 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 Ricardo Rangel, Manual Contreras, José Cruz Hernández, Heber Lazcano, Pamela Rodríguez, Humberto Cervantes, Mario Chávez, Gunnar Wolf, Berenice Ruiz, Armando Silva, Andrés Hurtado, Oscar Mondragón, Hugo Stevens, Ignacio Mendivil, Paul Avenant, Jorge Contreras, Norma Hernández, Luis Nava

Ventas Claudia Perea / Marketing y RP Montserrat Ramírez / Desarrollo Web Karen Rodríguez Contacto info@sg.com.mx SG Software Guru es una publicación trimestral editada por Brainworx, S.A. de C.V., Temístocles 34 piso 3, México DF 11560. Los contenidos de esta publicación son propiedad intelectual de los autores y están licenciados bajo Creative Commons Atribución-No comercial 2.5 México. Todos los artículos son responsabilidad de sus propios autores y no necesariamente reflejan el punto de vista de la editorial. Reserva de Derechos al Uso Exclusivo: En trámite. ISSN: 1870-0888.

.NOTICIAS

.IDC: Latinoamérica recurre a los servicios en la nube para transformarse

.IBM Industry Trend & Forum 2011

Con el objetivo de presentar diversas soluciones para industrias más inteligentes, los días 3 al 5 de marzo, IBM presentó en la Ciudad de México un espacio de encuentro en el que la innovación, la tecnología y el conocimiento ofrecieron un completo retrato de las últimas tendencias del mercado. La agenda del evento contó con especialistas que trabajan alrededor del mundo como facilitadores estratégicos y generadores de valor, así como con la experiencia de líderes de industria. El tercer día del evento estuvo dirigido a la red de desarrolladores, enfocándose en la importancia que tiene la divulgación de la inteligencia a través de las infraestructuras tecnológicas.

La adopción de servicios Cloud por parte de empresas con más de 100 empleados en América Latina aumentó del 3.5% en enero del 2010 al 15% en enero del 2011, lo que indica que las tecnologías Cloud se están convirtiendo en un fenómeno cada vez más masivo (mainstream), según lo revela IDC en su estudio titulado Latin America Cloud Report Card 2011. “Este aumento en la adopción constituye un punto de inflexión, ya que esta masa crítica de usuarios preliminares se convertirá en un semillero para la adopción masiva de los servicios Cloud”, comentó Ricardo Villate, VP de Investigación y Consultoría de IDC Latinoamérica. Dicho tema se analizó durante el evento IDC Cloud Solutions Roadshow LA 2011, realizado en la Ciudad de México el pasado mes de marzo.

.IBM Inaugura Centro de Innovación

En el marco de la celebración mundial de su centenario y del aniversario número 84 en nuestro país, con el objetivo de impulsar el crecimiento del sector TI mexicano, IBM inauguró en el mes de marzo su primer Centro de Innovación en México, sumándose a una red mundial de 39 centros a nivel mundial. El nuevo Centro proporcionará a emprendedores mexicanos, asociados de negocio IBM y a la Academia, acceso a capacitación, servicios de consultoría, y una amplia infraestructura técnica para ayudarlos a introducir nuevas tecnologías al mercado. También se lanzó la iniciativa IBM Global Entrepreneur, la que ofrece a start-ups acceso sin cargo a tecnologías específicas en un esquema de cómputo en la nube, así como acceso a la comunidad de investigación y a recursos técnicos y de mercadotecnia de IBM.

.Americas IT Forum 2011

Con el interés en conocer lo que requieren las empresas de TI de América Latina para competir en el mercado norteamericano y acercarse a clientes potenciales, el pasado 10 de marzo se llevó a cabo el Americas IT Business and Investors Forum en la ciudad de Austin, Texas. El evento contó con la participación de empresas y organismos tales como TechBA, CSoftMTY, Softtek, BrainUp, Deintec, Common Sense y SG entre otros. Representantes del gobierno de Texas también participaron y dejaron clara su intención de posicionar a Austin como el centro de la vinculación en TI entre EU y latinoamérica.

Para mayor información, noticias al día y actualizaciones de la industria visita: www.sg.com.mx

www.sg.com.mx |

El pasado mes de febrero se llevó a cabo en la Ciudad de México el evento denominado Tercer Foro de Gobierno Oracle, evento donde se discutieron los diferentes desafíos que enfrentarán las instituciones de gobierno durante el 2011. Bajo la premisa de que dichas instituciones necesitan ser cada vez más eficientes y ágiles, y requieren transformarse para cumplir con las necesidades crecientes de los cudadanos, el evento cubrió interesantes temas como: optimización en los procesos gubernamentales, planeación y gestión financiera, la transformación de entrega de servicios, y modernización de la infraestructura de TI entre otros.

Software Guru

.Tercer Foro de Gobierno Oracle

.COLUMNA Tejiendo Nuestra Red

Barreras para la Mejora de

Procesos de Software (SPI)

comparación

de un país desarrollado con respecto a uno en vías de desarrollo

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

n muchas ocasiones nos preguntamos ¿por qué la adopción y mejora de procesos de software en México, guiada por el modelo que gusten, no trae resultados tan rápidos e impactantes como nos hubiera gustado? Para intentar entender el fenómeno, quiero compartir con ustedes los resultados de un estudio [1] en el cual se compara la percepción de la importancia de las barreras en SPI en el contexto de un país en vías de desarrollo – Vietnam, con uno desarrollado – Australia. El objetivo del estudio fue entender a profundidad las barreras que pueden dificultar los esfuerzos de SPI en el contexto de Desarrollo Global del Software (ver mi columna del número anterior de SG), es decir cuando colaboran en un proyecto equipos de países con niveles de desarrollo distintos. La idea fue averiguar si estas barreras son diferentes según el tipo de país y, en su caso, servir de guía a los gestores de mejora de procesos para poder enfocar sus esfuerzos tomando en cuenta ese contexto. El método de investigación fue empírico. El estudio utilizó las 15 barreras de SPI, identificadas en un estudio previo [Tabla 1]. Se solicitó a que los profesionales de Vietnam los calificaran en una escala de importancia de Alto, Medio y Bajo. Los resultados se compararon con los que se obtuvieron previamente en Australia. Para recolectar los datos se aplicó un cuestionario de manera presencial a 34 desarrolladores de software y administradores de proyectos en Australia y 23 de Vietnam. Ver Tabla 1. En el caso de Vietnam, las barreras que obtuvieron calificación de “Alto”, en orden de número de votos, fueron: 1. Falta de administración de proyectos (5) 2. Falta de recursos (6) 3. Falta de patrocinio (7) 4. Equipo sin experiencia (1) 5. Falta de preocupación (awareness) por SPI (2) Mientras que, en el caso de Australia, la lista con la misma calificación y orden, fue la siguiente: 1. Falta de soporte (8) 2. Políticas organizacionales (12) 3. Falta de preocupación (awareness) por SPI (2)

ID Barrera Descripción 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15

Equipo sin experiencia Falta de preocupación (awareness) por SPI Falta de comunicación Falta de una metodología definida de implantación de SPI Falta administración de proyectos Falta de recursos Falta de patrocinio Falta de soporte Falta de herramientas Falta de capacitación Negativa/Mala experiencia Políticas organizacionales Documentación/procedimientos formales SPI entorpece trabajo real Presión de tiempo

Tabla 1. Barreras de mejora de procesos de software (SPI).

La primera observación es que los del país en desarrollo identificaron una tercera parte de las barreras que les fueron presentadas como las de importancia alta, mientras que los del país desarrollado solo consideraron una quinta parte de ellas. Ambos coinciden en que la falta de preocupación por el SPI es un obstáculo grave, pero difieren en el resto. Se nota que un país desarrollado ya tiene en cierta manera resuelto el problema de uso de prácticas de administración, disponibilidad de recursos humanos y físicos, la capacitación y la compresión de los directivos. Mientras que en un país en desarrollo estos temas siguen siendo un problema básico. Es interesante constatar que los australianos se quejan más por el problema de soporte y políticas organizacionales con respecto al SPI. De las barreras que obtuvieron menor calificación, las de Falta de comunicación (3), Falta de herramientas (9), Falta de capacitación (10), Negativa/Mala ex-

“Ambos coinciden en que

la falta de preocupación por el SPI es un obstáculo grave.”

periencia (11), SPI entorpece trabajo real (14) y la de Presión de tiempo (15) son las que preocupan bastante a los vietnamitas pero tienen relativamente menor importancia en Australia. Un dato curioso es que la barrera de Documentación/procedimientos formales (13), que mucha gente en México saca como uno de los primeros argumentos en contra de SPI asegurando que va a incrementar la burocracia, es más importante en Australia que en Vietnam.

¿Y qué saco nos ponemos en México?

Estoy segura que contamos con las empresas cuyas preocupaciones se asemejan a las de los australianos. Son las empresas que empezaron desde hace años su proyecto de mejora de procesos (siguiendo CMMI, MoProSoft o las prácticas que les parecían adecuadas) y no han desfallecido en el intento. Estas empresas buscan optimizar los esfuerzos de SPI y, tal vez, su mayor preocupación es lograr reconocimiento adecuado en el mercado y los beneficios, que esto debería de traer. ¿Y el resto de las empresas? Se lo dejo de tarea.

>> Por Hanna Oktaba

Referencias: [1] Mahmood Niazi, Muhammad Ali Babar, June M. Verner, Software Process Improvement barriers: A crosscultural comparison, Information and Software Technology 52 (2010), pág. 1204–1216, Editorial Elsevier.

.COLUMNA Mejora Continua

Mejora Continua vs. Mejora Perfecta ¿qué es una cultura de mejora continua?, ¿cuáles son sus ventajas y desventajas?

l año inicia lleno de nuevos retos, muchos cambios y mejoras que llevar a cabo. Esta semana me tocó dar una presentación sobre la cultura de mejora continua a un grupo de clientes y proveedores. Una de las temáticas que se abordó fue ¿cómo iniciar un esfuerzo de mejora continua en la organización? El tema causó interés por lo que vamos a aprovechar este espacio para hablar de las conclusiones.

››Una cultura es un grupo de sistemas, comportamientos y símbolos que define la forma de ser de una organización.

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

Antes que nada hablemos de qué es una cultura. Personalmente me gusta mucho la definición que escuche en una conferencia de Carolyn Taylor, una de las principales expertas sobre cambio cultural y autora del libro “Walking the Talk”: Una cultura es un grupo de sistemas, comportamientos y símbolos que define la forma de ser de una organización. Esta definición nos da mucho con que trabajar, si una cultura es un grupo específico de sistemas, comportamientos y símbolos, sólo tenemos que cambiar algunos de ellos para poder crear una cultura totalmente nueva. Con esto en mente pasemos al siguiente punto. ¿Qué es una cultura de mejora continua?, ¿cuáles son sus ventajas y desventajas? Pues sabemos de acuerdo al párrafo anterior, que una cultura es una serie de sistemas, comportamientos y símbolos y estos se ajustan de acuerdo a nuestras ideales. Uno de los ideales que es muy común en el hemisferio occidental es el amor

por las grandes soluciones. Veamos por ejemplo el caso reciente de las armadoras de coches americanas, Ford casi se daba por muerta y ahora está revolucionando el mercado con los sistemas de cómputo, GPS y demás que traen sus automóviles, algo que nadie más tiene tan desarrollado y que tomó al mercado totalmente por sorpresa. Esta forma de pensar normalmente nos enfoca en encontrar una innovación irresistible, incorporando todo lo que sabemos de las mejores prácticas de la industria, para lograr un cambio revolucionario. Desafortunadamente en el mundo actual el cambio es continuo y vertiginoso, los clientes son cada vez más difíciles de satisfacer, las grandes ideas son cada vez más costas, de mayor riesgo y rara vez son exitosas. En el mismo ejemplo, podemos también mencionar que de las tres compañías de automóviles solamente Ford sobrevivió, las demás no pudieron hacer el cambio. Ahora, El hemisferio oriental es famoso por la implantación de un ideal un poco diferente, el cual fomenta el trabajo en equipo la participación de todos y el cambio continuo de los procesos, Los ejemplos todos los conocen, compañías como Toyota y Nissan han hecho mundialmente famosas estas prácticas. Estas mismas compañías en estos momentos no son el centro de las noticias ya que han pasado en forma estable y con pocos incidentes toda la crisis y siguen creciendo como ya llevan años haciendo. Esto tiene sus desventajas: Estas compañías van en contra de nuestro sueño de ser los héroes que toman al mundo por sorpresa, requiere una mayor alineación de la gente a un fin común y el cambio revolucionario es más lento. Pero por otro lado los beneficios son constantes, alineados a los cambios del mercado, con una increíble estabilidad y flexibilidad través del tiempo. Cada quien tiene que decidir si realmente desea cambiar su cultura a la de mejora continua, digo realmente desea ya que no es bajo ninguna circunstancia

››Cada quien tiene que decidir si realmente desea cambiar su cultura a la de mejora continua algo fácil de hacer, si tu decisión es ¡si hacerlo!, ¿cómo lo hacemos?: Pues primero necesitamos generar un proceso para resolver problemas, lo más común en estos casos es iniciar con una estrategia de Six Sigma y tratar de institucionalizarla en tu organización. El modelo Six Sigma es una excelente herramienta para resolución de problemas pero en algunas ocasiones es demasiado costosa para iniciar, sobre todo que al principio es relativamente claro las cosas que se tienen que hacer. Regresemos a nuestra idea de cambiar comportamientos, sistemas y símbolos. Los comportamientos más importantes que influencian a una cultura de mejora continua son los siguientes: Estar seguro que todos los involucrados entienden el problema. Esto normalmente se logra con la práctica de crear un “chárter” ante cada problema que se quiere resolver, el chárter puede ser una sola hoja que marca claramente cuál es el problema, el objetivo a lograr como solución, el alcance que debe de tener esta solución, cómo medimos que resolvimos el problema y la lista de beneficios que nos daría resolver este problema de preferencia en dinero, esta información nos asegura que todos entendemos lo que queremos resolver y tiene el beneficio adicional que hace visible los beneficios de nuestro trabajo, esto funciona como un excelente motivador para iniciar la estrategia. No podemos mejorar algo si no existe un proceso a mejorar. La mejora continua implica que tienes algo sobre que trabajar continuamente por lo que es forzoso que exista un proceso en donde radique el problema. Muchas veces la solución inmediata a un problema es definir el proceso

que se debe seguir y entrenar a la gente en cómo seguirlo. Identificar causas raíz. Desde pequeño nos enseñan que un problema tiene una causa y una solución. La realidad es que vivimos en un mundo complejo y los problemas tienen muchas posibles causas y muchas posibles soluciones, debe de ser una práctica del proceso de resolución de problemas al menos dialogar sobre todas las posibles causas y soluciones que podemos implantar. Sólo implantar las soluciones de mayor impacto y menor costo. Esto suena extraño: Si ya tengo una solución ¿por qué no implantarla? En la realidad no hay nada más complejo que cambiar el compartimento de un grupo de gentes entre menos cambios existan más posible es el éxito del proyecto, adicionalmente recordemos que lo que queremos mejorar en forma continua, siempre tendrá otra posibilidad de mejorar en la siguiente vuelta. Establecer un plan de control. Como dije, lo más difícil es cambiar a un grupo de personas, por lo que se requiere de un plan para asegurar que no se regrese a las prácticas anteriores. No es suficiente creer que porque se dio un beneficio ya las cosas cambiaron para siempre, requiere de al menos un año de operar consistentemente de una forma nueva para pensar que ya está estable. Como ya mencioné el camino no es fácil, pero precisamente mejora continua implica cambiar poco a poco en forma sistémica y controlada hasta volverte el gigante que nadie puede vencer. Suerte.

››Por Luis Cuellar

.PRODUCTOS Lo Que Viene

Gemstone

Gemfire Enterprise

GemFire Enterprise es una plataforma que opera en memoria (in-memory) para administrar datos en ambientes distribuidos. Gemfire coordina recursos (memoría, CPU, red y opcionalmente espacio en disco) a través de múltiples procesos para administrar los objetos y comportamiento de las aplicaicones de negocio. Utilizando técnicas de particionamiento de datos y replicación dinámica, GemFire Enterprise ofrece alta disponibilidad, alto desempeño y escalabilidad linear sin comprometer la consistencia de los datos, aún en condiciones de falla. GemFire también provee capacidades de mensajería y notificación asíncrona, por medio de una capa de comunicación optimizada y de baja latencia. Más información en http://community.gemstome.com

Conforme ha explotado la necesidad de desarrollar aplicaciones para una gran variedad de dispositivos móviles, las herramientas ya están evolucionando para satisfacer esta necesidad. Una herramienta que ha cobrado popularidad en los últimos meses es Appcelerator Titanium. Esta es una plataforma de software libre para crear aplicaciones enriquecidas para dispositvos móviles, tablets y desktop utilizando lenguajes como Javascript, HTML, CSS, Python, Ruby, y PHP. El objetivo es permitir que los desarrolladores puedan crear aplicaciones nativas para cada dispositivo sin necesidad de aprender los lenguajes y herramientas específicos a cada uno. Más información en http://appcelerator.com

Red Hat jBPM 5

Appcelerator

Appcelerator Titanium

Red Hat anunció que ya se encuentra disponible JBoss Enterprise SOA Platform 5.1 con nuevas extensiones para la integración de servicios de datos. JBoss Enterprise SOA Platform 5.1 incluye: • El stack de web services Apache CXF. • JBoss Developer Studio 4.0, con herramientas actualizadas para SOA. • Una versión previa de WS-BPEL. • Una versión previa de Apache Camel Gateway. Más información en http://jboss.com

Si estás involucrado en el desarrollo de aplicaciones web, Sinatra es una de las tecnologías que debes conocer. Posiblemente hayas escuchado que es un framework de aplicaciones web hecho en Ruby y hayas pensado “¿quién necesita otro framework?”. Estrictamente, Sinatra no es un framework, sino un Domain Specific Language (DSL) y se comporta muy diferente a la mayoría de los frameworks. Al contrario de otros frameworks web hechos en Ruby tales como Ruby on Rails, Merb, o Nitro, Sinatra no se basa en ningún patrón tipo Modelo-Vista-Controlador ni provee elementos de ayuda para crear formas de captura, administras conexiones a bases de datos ni nada de esto. Simplemente se enfoca en definir acciones tipo REST y cómo se va a responder a estas; nada más que eso. Debido a estas características, Sinatra está siendo una elección común para el desarrollo de APIs REST. Más información en http://sinatrarb.com

Sinatra

.COLUMNA

El Futuro del

Centro de Cómputo los avances están

Tendencias en Software

lejos

de agotarse

os encontramos en un sorprendente momento en la evolución de la computación: el nacimiento de una nueva década para los sistemas de cómputo empresariales.

se percibe a Microsoft, VMWare, Oracle, IBM y Cisco como los líderes en el segmento, pero las propuestas difieren radicalmente. Los consumidores están por definir cuales realmente son los elementos deseables.

Todo inicia con el hardware. Para muchos ha pasado desapercibido el hecho de que un sistema de dos procesadores hoy, puede hacer lo que hace un año requería cuatro. Es decir, en tan solo 12 meses la capacidad se ha duplicado para cargas como la de un servidor de base de datos.

››La carrera por el desempeño

Microprocesadores. Para el primer trimestre del 2011 el Westmere-EX ofrece 10 núcleos y 20% mejor desempeño que los 8 de Nahalem. El AMD Interlagos ofrece 16 núcleos. En las publicaciones de supercómputo cada vez se menciona más a NVIDIA y el GPU; la nueva realidad es paralela.

Evolución del centro de cómputo

Sistemas. Hoy, el servidor de 4 procesadores es el más común, pero el de 8 se encuentra próximo. Sin embargo, la llegada de los dispositivos dedicados o computing appliances va a tener un impacto mucho mayor, ahorrando de 3 a 12 meses en el ajuste de hardware y software, dependiendo de la escala del producto. Software. Queda claro que el cómputo en la nube no se puede detener. La existencia de centros de datos privados tampoco se discute. La gran pregunta es ¿cuál es la ruta a los sistemas híbridos? ¿Quién será el primer proveedor de software capaz de construir ambos lados con una sola versión del producto y al menor costo? Es altamente probable que para alcanzar ese modelo, se requiera una nueva plataforma aplicativa. Los avances en sistemas operativos, bases de datos, sistemas de archivos y middleware están lejos de agotarse. La nube privada. Para algunos proveedores la nube privada es únicamente la virtualización, otros creen que es una solución de hardware y software empaquetada. Actualmente 11

››Por Luis Daniel Soto

Software Guru

Redes y E/S. Hay una convergencia entre redes e interconexión de almacenamiento utilizando 10G como transporte y normalizando el hardware.

El centro de datos empresarial está evolucionando de la siguiente manera: 1. La virtualización está logrando maximizar el uso de los sistemas de cómputo, la “consolidación” es un tema de moda. El siguiente paso inmediato es la administración de las distintas máquinas virtuales. Se inicia con ambientes de pruebas y posteriormente con sistemas en producción. En un nivel avanzado de virtualización, será posible automatizar múltiples configuraciones en producción de manera diaria. 2. Una siguiente etapa consiste en establecer “servicios compartidos” a través de una organización entera. Bajo esta visión, es posible que una organización estandarice todos sus sistemas bajo una sola versión de un producto (por ejemplo SQL Server) del que se provisionen instancias conforme se vayan necesitando, bajo un modelo común y repetible. Posteriormente se procede a hacer verdaderamente invisible el servicio, integrándose con centros de datos de terceros para tener capacidad global; la unión con la nube pública y con ello, aplicaciones capaces de reconocer las reglas para el ambiente híbrido. 3. La aspiración final es un ambiente totalmente de autoservicio, que opera bajo las cualidades de confianza y desempeño que hoy son posibles solamente con hardware especializado. En el 2005, 10% de los embarques de servidores de alto costo significaron el 61% de las ventas. Para el 2013 este número se reducirá a 2% pero con un monto de 32% de ventas. Es decir, el gasto en servidores que no sean x86 se reducirá de 3 a 5 billones de dólares. Así que hay que ser cautelosos en la compra de mainframes de la actualidad. La carrera por el desempeño puro va a ser demasiado costosa. Posiblemente viviremos para ver la creación de una nueva plataforma de misión crítica con cualidades distintas a las que hoy han reinado. Potencialmente basados en verdadero costo/beneficio e innovación. Auguro que este cambio nos tendrá ocupados por varios años.

www.sg.com.mx |

Almacenamiento. Estamos viviendo una transformación fundamental con la memoria no volátil (NVM), tanto en forma de ahorro de energía como encendido instantáneo de una PC. El eNVMHCI llegará a servidores de bajo costo a mediados de año, con un tiempo de acceso de la mitad de los discos de estado sólido.

puro va a ser demasiado costosa.

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

.PRODUCTOS Un Vistazo

desarrollando con

Ruby on Rails ››Por Mario Chávez

¿estás listo para

i estás involucrado en el desarrollo de aplicaciones web, seguramente has oido mencionar “Ruby on Rails” ultimamente. Ruby on Rails es una de las tecnologías más “candentes” del momento. Aunque dista mucho de tener la base instalada de aplicaciones y desarrolladores que PHP o Java, para proyectos nuevos es una de las principales tecnologías que se está considerando. Esto ha hecho que la demanda de desarrolladores Ruby este aumentando considerablemente. Así que si te interesa mantenerte actualizado, debes por lo menos conocer las bases de RoR.

Antecedentes

Ruby on Rails es un marco de trabajo (framework) para el desarrollo de aplicaciones web, escrito en el leguaje de programación Ruby. Ruby es un lenguaje dinámico orientado a objetos, con sintaxis inspirada en Python, Perl y Smalltalk. Ruby vio la luz en 1995 de la mano de Yukihiro “Matz” Matsumoto. Ruby on Rails es la creación de David Heinemeier Hasson; todo comenzó en el 2004 con el desarrollo del producto estrella de la empresa 37 Signals, Basecamp. David extrajo el código base de la aplicación y de esta manera se dio el inicio de Ruby On Rails. Ruby on Rails —o Rails como lo nombraré en el resto del articulo— es un framework de “opinión”. Esto se refiere a que el marco de trabajo realiza una serie de suposiciones en las que asume cuál es la mejor forma de hacer las cosas. De esta forma provee un incremento en la productividad, ya que se encarga de la “talacha” y nos permite enfocarnos en las características que dan valor para el usuario final.

Principios

Rails se basa en una serie de principios filosóficos: 12

aumentar tu productividad?

• DRY. Son las siglas de “Don’t Repeat Yourself ” y se refiere a evitar escribir el mismo código una y otra vez. • Convención sobre configuración. En base a “reglas de convención” y a través de generadores se crea un esqueleto básico de nuestra aplicación. Este esqueleto organiza archivos y directorios en categorías que dictan qué piezas de nuestra aplicación deben de acomodarse dentro de esa estructura. Con esto se evita el tener que definir incontables o larguísimos archivos de configuración para configurar tal organización. • TATFT - TAFT son las siglas de “Test All The F* Time”, y se refiere a “probar todo el tiempo”. Rails se basa en la estrategia de Desarrollo Dirigido por Pruebas (Test Driven Development, TDD). Básicamente, ántes de escribir la funcionalidad requerida, vamos a escribir las pruebas o especificaciones con las que vamos a verificar que el comportamiento que implementemos sea el deseado.

Tecnología de Rails

MVC. Como ya vimos, Rails tiene una serie de conceptos filosóficos. En términos de estructura arquitectónica, Rails se basa en el patrón Modelo-Vista-Controlador (VC). La mayoría de ustedes ya deberían conocer bien este patrón, ya que es muy utilizado, e incluso se han publicado artículos al respecto en ediciones anteriores de Software Guru. Aun así, demos un repaso rápido para explicarlo. El concepto de este patrón implica la separación lógica de las partes de nuestra aplicación. Para realizar el funcionamiente del sistema, se divide este en distintas piezas que pueden ser modelos, vistas o controladores. A continuación se explica cada uno: • Modelo. Representa a nuestro dominio, patrón implementa el patrón de ActiveRecord para todas las operaciones de manejo de información entre nuestros modelos y la base de datos. En el modelo

.PRODUCTOS

Un Vistazo A

››“¿Primero debo aprender ruby o

me enfoco en rails y aprendo ruby en el camino?”

Una pregunta común que se hacen los desarrolladores nuevos a Ruby y Rails es si primero deben aprender el lenguaje Ruby o si mejor se enfocan en Rails y en el camino aprenden Ruby. Ámbos son caminos válidos. La primera recomendación es visitar el sitio de Ruby On Rails [1], donde hay una serie de recursos a sitios y vídeos sobre el tema. En la referencia [2] (“¿Cómo iniciarse en Rails?”) pueden encontrar un listado de recursos en español e ingles sobre el tema. Para iniciarse en Ruby, la mejor opción es visitar el sitio de Ruby [3]. Y por último, visita las comunidades de Rails y/o Ruby. Incluso existen algunas de habla hispana como Rails.mx y Tijuana.rb.

Instalación de Rails

Rails, al igual que Ruby son software libre y están disponibles para las plataformas Windows, Linux y OSX. Considero que no tiene caso usar este espacio para explicar como instalarlo, pero en http://decisionesinteligentes.com/guides pueden encontrar guías de instalación y configuración en español.

“quehacer” es el nombre de nuestra aplicación y “rails new” es el comando para crear la aplicación. Después de unos segundos tendremos un directorio llamado quehacer con una seria de archivos y carpetas. Para iniciar con nuestra aplicación es necesario instalar las librerías que son dependencias de nuestra aplicación, en el mundo Ruby las librerías se conocen como Gemas (Gems). Rails hace uso de una herramienta llamada Bundler que automatiza la instalación de Gemas y sus dependencias. $ cd quehacer $ bundle install Una vez que bundler ha terminado, podemos ejecutar nuestra aplicación, aunque a estas alturas nos mostrara únicamente una pantalla genérica de bienvenida. $ rails server Una vez iniciado el servidor navegamos a http:// localhost:3000 y veremos la mencionada pantalla. El servidor lo podemos detener en la consola con un simple ctrl + c.

Scaffolding

Una manera muy rápida y sencilla de empezar a desarrollar en Rails es haciendo uso de “scaffold”. Simplemente ejecutamos un “scaffold” con la información de nuestro modelo y en cuestión de segundos tendremos un modelo, controlador y vistas listas para usarse, todo construido por Rails a partir de las “suposiciones” que mencionabamos en un inicio. Vamos generando un “scaffold” para el modelo “event”, el cual representara un evento. $ rails generate scaffold event title:string description:text date:datetime address:string

Ejemplo básico

A continuación vamos a explorar un ejemplo básico con Rails, aunque por cuestiones de espacio en el articulo actual, vamos a omitir la parte de pruebas. Partiremos de que ya se tiene un ambiente de desarrollo instalado y configurado, y haremos uso de la consola de comandos. La aplicación que vamos a construir es una que nos permita publicar eventos y mostrar el listado de los mismos. Vamos a prescindir de características como autentificación y autorización con la finalidad de poder tener este prototipo funcionando en cuestión de minutos. El primer comando que vamos a ejecutar va generar el esqueleto inicial de nuestra aplicación. 13

Al ejecutar el comando tendremos una serie de archivos generados. Nuestro modelo event tendrá 4 datos a almacenar: título, descripción, fecha y dirección. Quizás se pueda necesitar más datos, pero para el caso practico de este ejemplo esto será suficiente. Uno de los archivos que se genera automáticamente, y que vamos a revisar es el archivo de tipo migración. Este lo vamos a encontrar en el subdirectorio db/migrate de nuestra aplicación. Parte del nombre del archivo será create_event.rb, en mi caso el archivo es 20101224222550_ create_events.rb en su caso el valor del timestamp será diferente.

Software Guru

¿Como me inicio con Rails?

$ rails new quehacer

www.sg.com.mx |

también incluimos cosas como las validación y acciones especificas para realizar con la base de datos. • Controlador. Es el punto intermedio que se encarga de orquestar el flujo de operación de nuestra aplicación, es el responsable procesar las solicitudes del usuario y responder de manera adecuada. • Vista. Se usan para desplegar la información a los usuarios de manera amigable. En Rails se usa “Embedded” Ruby o ERB como se conoce comúnmente, el cual es un lenguaje de plantilla que combina html y Ruby para la generación de interfaces de usuario. • REST (Representational State Transfer). Es un paradigma para definir rutas en aplicaciones web. En base a REST, las aplicaciones de Rails determinan qué parte de aplicación mostrar y cómo responder a las solicitudes del usuario.

.PRODUCTOS Un Vistazo

››“Las migraciones en rails tienen versión, con lo que podemos manejar los cambios al esquema de base de datos.”

Dentro de este archivo vamos a encontrar instrucciones de Ruby para crear una tabla de eventos en nuestra base de datos. La ventaja de que estas instrucciones estén escritas en Ruby es que nos permite que sean independientes del manejador de base de datos. Por omisión, en nuestra aplicación estamos usando SQLite3, pero bien pudiésemos estar usando MySql, Postgresql, Oracle o Microsoft SQL Server. El archivo que configura el motor de base de datos a usar es config/database.yml. El archivo de migración tiene dos secciones: up y down. Ambas son utilizadas para poder realizar rollbacks a cambios realizados en la base de datos, ademas de que las migraciones en Rails tienen versión, con lo que podemos manejar los cambios al esquema de la base de datos. Para aplicar la migración ejecutamos: $ rake db:migrate En este punto podemos volver a ejecutar nuestra aplicación y ya tendremos la funcionalidad de Crear, Ver y Actualizar eventos, esto gracias a que en el proceso de “scaffold” nos creo el controlador del evento en “app/controllers/event_controller.rb”, el cual define 7 acciones que siguen el estándar REST mencionado anteriormente: • Index • Show • New • Create • Edit • Update • Destroy El controlador en este momento está completamente funcional. Hay que notar que el nombre del controlador sigue una convención <modelo>_controller, que también al igual que REST es una convención establecida en Rails. Al igual que el controlador, el “scaffold” genero las vistas: index. html.erb, show.html.erb, new.html.erb, edit.html.erb, _form.html. erb. Estas son utilizadas por el controlador para responder a las acciones, de hecho no es casualidad que el nombre de las vistas concuerden con algunas de las acciones del controlador. Dentro del código del controlador del evento, a manera de comentario para cada acción, nos indica cómo podemos navegar a cada acción a través del navegador. Por ejemplo, para ver el listado de eventos navegamos a /events o para crear un nuevo evento navegamos a /events/new. Si inicias el servidor y visitas http://localhost:3000/ events/new verás algo parecido a la figura 1. 14

Rutas

Las rutas de nuestra aplicación están definidas en el archivo config/ routes.rb, al inicio del archivo vamos a encontrar la linea resources :events. Con esa sola instrucción nos aseguramos que evento responda a la convención REST. Para ver como están configuradas las rutas podemos ejecutar: $ rake routes y el resultado será el siguiente: GET /events(.:format) {:action=>”index”, :controller=>”events”} POST /events(.:format) {:action=>”create”, :controller=>”events”} new_event GET /events/new(.:format) {:action=>”new”, :controller=>”events”} edit_event GET /events/:id/edit(.:format) {:action=>”edit”, :controller=>”events”} event GET /events/:id(.:format) {:action=>”show”, :controller=>”events”} PUT /events/:id(.:format) {:action=>”update”, :controller=>”events”} DELETE /events/:id(.:format) {:action=>”destroy”, :controller=>”events”} Listado 1. Rutas REST en nuestra aplicación.

Modelo

Finalmente, revisaremos el modelo de nuestro evento, el cual en-

.PRODUCTOS

Figura 2. Mensajes de error al intentar guardar un evento.

contraremos en app/models/event.rb. Curiosamente, nos daremos cuenta que el archivo no contiene prácticamente código. Gracias a la convención usada por Rails, nuestro modelo funciona sin problemas. Algo que podemos hacer es agregar validación para prevenir que se guarde un evento sin titulo y descripción.

usanza de Rails” y lograr tener aplicaciones que cumplan con las necesidades de los usuarios y que sean mantenibles al mismo tiempo. Rails actualmente cuenta con una comunidad muy activa de individuos y empresas que le están apostando a esta forma de hacer aplicaciones web. Rails también ha sido un ejemplo a seguir en otros lenguajes de programación, y hoy en día podemos encontrar marcos de trabajo parecidos o modelados a partir de Rails en lenguajes como Phyton, PHP, Java y .NET.

Para agregar la validación editamos app/models/event.rb y justo entre la linea de declaración de clase y end agregamos la siguiente linea: validates_presence_of :title, :description Guardamos el modelo, ejecutamos el servidor y tratamos de crear un evento nuevo sin llenar el formulario, vamos a encontrarnos que Rails nos muestra un mensaje de error, además de indicarnos qué campos son los que ocasionan este error.

Referencias [1] “Ruby on Rails”. http://rubyonrails.org [2] “¿Como iniciarse en Rails?”. http://bit.ly/sg31r7

Conclusión

[3] “Ruby Language”. http://www.ruby-lang.org/es/

A través del articulo tuvimos la oportunidad de conocer sobre Ruby on Rails y cómo de manera muy rápida podemos crear un prototipo funcional. Este ejercicio también nos permitió conocer sobre la convención que utiliza Rails y que nos ayuda a evitar tomar decisiones sobre la arquitectura de la aplicación, permitiéndonos enfocarnos de manera rápida en lo que proporciona valor a nuestros nuestros usuarios. Este ejemplo apenas toco los temas mas básicos de Rails, aun queda mucho mas por aprender para desarrollar aplicaciones “a la 15

[4] “Guías de configuración del ambiente”. http://bit.ly/sg31r8

.BIO Mario Chavez es Ingeniero en Sistemas y radica en Tijuana, México. Se especializa en desarrollo con Ruby on Rails y es desarrollador independiente (http://decisionesinteligentes.com). También es fundador de la comunidad http://tijuana.rb

www.sg.com.mx |

Figura 1. Forma para crear un nuevo evento

Software Guru

Un Vistazo A

.EMPRENDIENDO

Mínimo Producto Viable (MVP) Construir un producto en un startup es diferente

››Por Hugo Stevens

l proceso para desarrollar un producto en un startup o en cualquier ambiente con altos niveles de incertidumbre, es muy diferente al modelo usado tradicionalmente. En un startup, tanto el problema (lo que el cliente necesita) como la solución (lo que debe hacer el producto) son desconocidos. Esto requiere una combinación de un proceso iterativo para entender el problema del cliente a través de hipótesis y experimentos y al mismo tiempo, desarrollar la solución a través de datos y retroalimentación. En la práctica este proceso requiere desarrollar prototipos y múltiples versiones del producto para mostrarlo a los clientes e irlo refinando en base a sus reacciones. Este enfoque, el cual combina elementos del Proceso de Desarrollo de Clientes de Steve Blank y métodos de desarrollo ágil, se conoce 16

como un lean startup, y el Mínimo Producto Viable (MVP por sus siglas en inglés) es una estrategia clave para ayudar a los startups a construir su producto mientras aprenden lo que el mercado necesita, al enfocarse en realizar múltiples iteraciones del producto para depurarlo con base en la retroalimentación de los clientes.

Un MVP permite aprender sobre los clientes

Un Mínimo Producto Viable es una versión de un producto que permite a un equipo recabar la mayor cantidad de aprendizaje validado sobre los clientes con el menor esfuerzo posible. Es usado para probar rápidamente de manera cuantitativa y cualitativa la respuesta del mercado a un producto o una funcionalidad espe-

.EMPRENDIENDO

››“El objetivo principal en el proceso de

desarrollo de un startup es minimizar el ciclo de decisión.”

Un MVP contiene sólo la funcionalidad mínima requerida para aprender de los “earlyvangelists” – clientes visionarios y early adopters. Típicamente, el producto está enfocado en este tipo de clientes, los cuales en principio son más tolerantes, están más dispuestos a proporcionar retroalimentación y poseen mayor capacidad para entender la visión del producto con sólo un prototipo o información básica del producto, además de ayudar a llenar los ‘huecos’ en la funcionalidad deseada.

Un MVP puede ser diferente dependiendo del producto

No hay una fórmula exacta para definir un MVP ya que se requiere cierto nivel de criterio y depende del contexto del producto. Por ejemplo, al equipo de IMVU, un cliente de Instant Messaging en 3D, le tomó 6 meses crear su MVP original, en contraste con otras compañías donde la primera versión llega a tomar 5 años antes del lanzamiento. Sin embargo, en otras ocasiones puede tomar hasta 2 semanas desarrollar cierta funcionalidad que al final nadie quería, cuando una simple prueba a través de anuncios en Google hubiera podido demostrar en unos días que nadie estaba interesado.

Cómo construir un MVP

El objetivo principal en el proceso de desarrollo de un startup es minimizar el ciclo de decisión, el cual consiste en Construir – Medir – Aprender a través de ideas, código y datos, buscando minimizar el tiempo total en cada iteración. El proceso es repetido hasta que se obtiene el producto que efectivamente responde a la necesidad del mercado o hasta que se determina que el producto no es viable. La figura 1 ilustra este proceso.

Un MVP permite aprender y cambiar de dirección si es necesario

El mayor desperdicio que puede haber al crear un producto es construir algo que nadie quiera. Un MVP busca comprobar que efectivamente el producto resuelva una necesidad del mercado antes de tener que invertir demasiados recursos en su desarrollo. Normalmente se construye un primer prototipo y después de mostrarlo a algunos clientes (aún si nadie lo quiere inicialmente), a 17

Figura 1. Proceso de desarrollo de MVP

Software Guru

Un MVP esté enfocado en early adopters y clientes visionarios

través de iterar rápidamente es posible corregir el rumbo sin tener que invertir esfuerzo de más, gracias a la retroalimentación frecuente que se tiene, comparado con pasar meses encerrados construyendo el producto “perfecto” para después darse cuenta que no era lo que el mercado quería. Lo importante es recordar que si el producto resuelve una necesidad real, un MVP permite alcanzar una gran visión en pequeños incrementos. Una metáfora que ayuda a ilustrar cómo funciona el proceso, es el concepto del ciclo de Observar/Orientar/Decidir/Actuar que tiene sus fundamentos en teoría militar. Según John Boyd, el creador del modelo, “la clave de la victoria es ser capaces de tomar las decisiones apropiadas más rápido que el enemigo”. El mismo principio aplica a los startups, los cuales normalmente se enfrentan al problema de tener que maniobrar en terreno con condiciones confusas o desconocidas, por lo que deben tener la capacidad de generar hipótesis, aprender rápidamente y reaccionar ante condiciones desconocidas. Un MVP, es una de las herramientas críticas que permite lograr este aprendizaje, ya que permite realizar múltiples iteraciones, las cuales facilitan el aprendizaje y la flexibilidad.

www.sg.com.mx |

cífica. Un MVP tiene sólo aquella funcionalidad requerida para mostrar el producto al cliente y su principal objetivo es evitar el desarrollar productos que los clientes no quieran y maximizar la información obtenida sobre los clientes con base en el costo y esfuerzo invertidos. A pesar de su nombre, el MVP no se trata solamente de crear un producto. Es una estrategia y un proceso enfocados en crear y vender un producto a un grupo de clientes. Es un proceso iterativo de generación de ideas, desarrollo de prototipos, presentación, recolección de datos, análisis y aprendizaje. Si el objetivo es simplemente crear algo rápido, un MVP en sí no es realmente necesario. En la mayoría de los casos, un MVP requiere esfuerzos adicionales en invertir tiempo en hablar con clientes, definir métricas y analizar los resultados.

.EMPRENDIENDO

Algunas tácticas que pueden ser usadas en cada etapa del proceso son: • Construir: Generar lotes pequeños y producción continua. • Medir: Realizar pruebas A/B para verificar hipótesis. • Aprender: Construir un mínimo producto viable, apoyarse en análisis de causa raíz.

Ejemplos y técnicas

A continuación se mencionan algunas técnicas y ejemplos prácticos de MVPs en acción: Sólo un landing page. Este enfoque es lo que podríamos llamar “vender antes de construir”, y consiste en empezar solamente con una página web de inicio (landing page) describiendo el producto a desarrollar con un link para solicitar más información. Se utiliza publicidad en Google u otros medios para generar tráfico a esta página y ofrecer el producto. En este sencillo experimento es posible comprobar cuánto interés hay en el producto – por ejemplo, si 0% de los visitantes hace click en la oferta de compra, entonces no hay razón para desarrollar el producto, ya sabemos que no hay interés en él. Es mejor usar esos recursos para redefinir el producto y encontrar qué características son las que efectivamente desea el mercado. .BIO

Probar funcionalidad específica. Insertar un link a una nueva funcionalidad en una aplicación web, el cual dirige a una sección con mayor información o solicitando al usuario registrar su interés. Los links son registrados y sirven como una medida de qué tan necesaria es esa funcionalidad. Por ejemplo, Fliggo (un servicio para compartir videos) empezó a ofrecer una versión pagada además de su versión básica preguntando a sus clientes si querían recibir una notificación cuando el nuevo producto estuviera listo. Al hacer esto, pudieron medir el interés de los usuarios: si muy pocos se registraban, sabían que ese no era lo que los clientes deseaban sin haber tenido que construir el producto completo.

Hugo Stevens es Ingeniero en Electrónica y Comunicaciones por el Tec de Monterrey. Tiene una maestría en Desarrollo de Nuevas Empresas por la Universidad de Stanford y un MBA por la Universidad de Pforzheim en Alemania. Cuenta con experiencia en múltiples industrias, países y proyectos de implementación de tecnología. Es fundador de Startup University y AspireLabs, un fondo para startups de tecnología en México, y puede ser contactado por email en hugo.stevens@aspirelabs.net o por Twitter en @hugostevens

Referencias: [1] E. Ries. “How to Build a Lean Startup”. http://slidesha.re/sg31r1 [2] E. Ries. “Minimum Viable Product: a guide”. http://bit.ly/sg31r2 [3] J. Baptiste. “A Step By Step Guide On How We Created A Minimum Viable Product In One Weekend”. http://bit.ly/sg31r3 [4] A. Barreto. “Modelos de Negocios: Realidad de América Latina”. SG Emprende. http://slidesha.re/sg31r4

Eliminar funcionalidad, enfocarse en una sola cosa. La idea original para Grooveshark (servicio de música en línea), era combinar elementos de Limewire, eBay, Wikipedia, Facebook, LastFM e iTunes. Después de darse cuenta que el producto iba a ser increíblemente complejo (un monstruo de Frankenstein, de acuerdo a uno de los fundadores), la compañía se enfocó en ofrecer una simple función: buscar una canción y reproducirla. Después de probar varias hipótesis, empezaron a agregar funciones adicionales. Crear un producto sencillo. El primer prototipo de Twitter fue creado en un periodo de dos semanas, el cual fue suficiente para que varios usuarios lo pudieran probar. Si dos semanas parecen demasiado, considera que el MVP de Cloudomatic, un servicio para promover aplicaciones en línea, fue construido en un fin de semana. De ahí la frase: “hay una versión de 2 semanas de lo que sea”. Manualización (flintstoning). Para comprobar si un cliente requiere o no cierta funcionalidad pero sin tener que realizar un desarrollo completo, se puede utilizar la estrategia de flintstoning, la cual consiste en dar la apariencia de que algo se hace de forma automatizada, aunque en realidad tras bambalinas se haga manualmente. El término viene de Los Picapiedra (The Flintstones), que movían sus automóviles con los pies. Existe una historia de una persona que quería vender autos en línea, pero esto requería escribir un producto bastante complicado y no sabía si funcionaria o no. Así que creó un website con formas, pero todo el procesamiento de la información era manual —lo que pasaba detrás de escenas era realizado a mano— y esto fue suficiente para confirmar que el negocio podría funcionar. Lanzar 1.0 e iterar rápidamente. La recomendación más importante es lanzar la primera versión del producto e iterar con base en la retroalimentación de los clientes. Por ejemplo, PayPal empezó como un servicio de transferencia de dinero entre PDAs y al poco tiempo se dieron cuenta de que no había mucha demanda para este producto. Sin embargo, también notaron que la funcionalidad de transferir dinero por email (una función a la que ni siquiera le habían puesto mucha atención) estaba atrayendo múltiples usuarios y el resto es historia. Otros ejemplos incluyen la primera versión de Facebook, Windows, y hasta el iPod 1.0 (se pueden encontrar imágenes de todas estas primeras versiones en Wikipedia). La regla de oro para saber cuándo lanzar viene de Reid Hoffman, fundador de LinkedIn: “Si no te da vergüenza la primera versión de tu producto, es que esperaste demasiado para lanzar.”

.PRINCIPAL

IMPLEMENTANDO PAGOS POR

INTERNET

explorando las opciones

Internet es hoy en día una herramienta fundamental para las empresas, no sólo porque les permite interactuar con los clientes, sino porque también permite hacer negocios y transacciones en línea. > Para recibir pagos por internet existen distintas opciones. Las empre-

sas grandes típicamente abren una cuenta mercantil e implementan una terminal virtual apoyados en la infraestructura del banco de su elección. Por otra parte, muchos negocios no tienen los recursos para implementar esto, o prefieren no hacerlo. La opción para estos casos es recurrir a un IPSP (Internet Payment Services Provider), el cual es un intermediario que provee el servicio de pago en línea a cambio de una comisión. En este artículo explicaremos a grandes rasgos distintas estrategias para recibir pagos en línea. 20

››Por Ricardo Rangel

Pago por medio de IPSP

En un IPSP, el vendedor tiene creada una cuenta con un IPSP, la cual utiliza para recibir pagos de parte de los consumidores. En algunos casos el consumidor también requiere crear una cuenta, mientras que en otros solo necesita proveer sus datos de tarjeta de crédito, o incluso realizar su pago en una tienda de conveniencia indicando una clave de referencia. Un factor importante es el de verificar cual de los servicios está disponible en el país en cuestión, qué tipos de tarjetas de crédito y métodos de pago acepta cada compañía, información sobre el tipo de moneda y otras cuestiones locales. Algunos transfieren dinero de persona a persona y los pagos necesitan ser verificados manualmente. Otros ofrecen integración mas sofisticada con nuestro sitio web.

.PRINCIPAL

Si no queremos recurrir a un IPSP, podemos implementar funcionalidad a la medida para soportar transacciones con tarjeta de crédito en nuestro sitio. Empezaremos por ver la teoría que hay detrás de las transacciones con tarjetas de crédito, los tipos de organizaciones que nos permitirán procesarlas y el tipo de transacciones que son posibles. Los bancos y otras instituciones financieras usan redes seguras para sus transacciones, basadas en el protocolo X.25 en vez de usar el de TCP/ IP. X.25 no es algo que necesitemos conocer a fondo, fuera del hecho de que es un protocolo de red y de que no es compatible con TCP/IP. Por esta razón, las redes basadas en X.25 son completamente separadas de Internet, aunque es posible acceder directamente a ellas, pero no es recomendable. Para hacerlo, necesitaríamos entrar en una negociación muy seria con el propietario de la red que quisiéramos usar. El propietario deseará estar 100 % seguro de que somos unos clientes confiables y que somos capaces de implementar todo tipo de medidas de seguridad para prevenir un ataque al sistema. El propietario de la red no puede obsequiar licencias al por mayor, porque la mayoría de la gente no podría proporcionar las medidas de seguridad requeridas. Dado la complejidad de acceder directamente a una red X.25, lo recomendable es recurrir a un intermediario conocido como “Gateway Provider”. Esto nos permitirá implementar nuestra parte del protocolo para la transacción en Internet, mientras que al mismo tiempo dependemos del Gateway que hayamos elegido para comunicarnos con la red X.25. Aunque esto implica un costo, por lo menos nuestro proveedor ha negociado algún convenio con la institución financiera para mantener bajos los mismos, por lo que esta opción es mucho más barata que implementar nuestra propia conexión a la red X.25. Este método también es más barato que usar IPSPs como PayPal, sin embargo requiere que codifiquemos por nuestra cuenta mucha de la funcionalidad que ya ofrecen estos servicios.

Trabajando con Gateway Providers

Para trabajar con un Gateway Provider, primero necesitaremos abrir una cuenta de tipo mercantil en un banco, con lo cual obtendremos un número único de identificación que nos servirá para registrarnos en el Gateway. El siguiente paso es elegir nuestro Gateway Provider. Algunos de los más populares son: firstdata.com, cardservice.com, verisign.com, worldpay.com, datacash.com. Cualquiera que sea el Gateway que utilicemos, los principios básicos de las transacciones por tarjeta de crédito son los mismos. Para empezar, la clase de transacciones con las que estaremos trabajando en un sitio web son conocidas como transacciones sin tarjeta (CNP, Card Not Present transactions), lo cual significa que no tenemos la tarjeta de crédito enfrente de nosotros y por lo tanto no podemos verificar la firma del cliente. Al utilizar Gateway Providers, podemos implementar varios tipos de transacciones incluyendo los siguientes: 21

Además, los Gateway Providers pueden ofrecer servicios avanzados al ofrecer verificaciones de dirección del dueño de la tarjeta, verificación de código de seguridad, revisión de historial de la tarjeta, etc, aunque todos estos servicios son secundarios.

Ejemplo

Independientemente del Gateway Provider que hayamos elegido, los pasos a seguir son similares en todos los casos. Por ejemplo, si eligiéramos a DataCash como nuestro Gateway Provider, estos serían los pasos a seguir: 1. Ir a www.datacash.com 2. Localizar la sección “Apply Now” y dar click en el vínculo “Get a Test Account” 3. Introducir los datos solicitados y enviarlos 4. Del correo que recibamos, tomar nota de nuestro username y password, además de la información requerida para acceder al sistema de reportes de DataCash El siguiente paso es normalmente bajar el toolkit del Gateway Provider para una fácil integración con nuestro sitio. Sin embargo, si el Gateway Provider no provee una implementación compatible como es el caso de .Net, deberemos usar una API en XML para implementar transacciones. Básicamente, esto implica enviar peticiones XML a determinada URL usando una conexión SSL y desencriptar el resultado del XML. Como es de esperar, sería imposible mostrar en este artículo todo el código necesario para implementar el procesamiento con tarjeta de .BIO crédito en un sitio web, pero esRicardo Rangel Ramírez es Licenciado en Informática egresado pero que éstas líneas den una idea de la Universidad de Ecatepec. Ha desarrollado software en general sobre como funcionan éste plataforma .Net para diferentes tipo de transacciones por Internet. empresas. Actualmente labora en

Conclusión

El aprendizaje de la implementación de pagos por Internet es fundamental para aquellos webmasters que deseen enfocarse en comercio electrónico, ya que la finalidad primordial de éstos sitios es obtener ganancias. ¿Estás listo para hacer dinero por Internet?

el Departamento de Sistemas de Stanhome de México y en proyectos independientes. Sus principales habilidades son la Gestión y Explotación de Información, y el Análisis, Diseño y Desarrollo de Sistemas de Información. riccardorangel@hotmail.com

Referencias: [1] C. Diarie & K. Watson. Beginning ASP. Net 2.0 E-Commerce in C# 2005. APress, 2005.

Software Guru

Transacciones con tarjeta de crédito

• Autorización: Tipo básico, verifica los fondos de la tarjeta y hace la deducción correspondiente. • Preautorización: Verifica los fondos de la tarjeta y los asigna pero no hace la deducción inmediatamente • Completar preautorización: Completa una transacción preautorizada, deduciendo los fondos ya preasignados. • Reembolso: Reembolsa una transacción completa o simplemente pone el dinero en una tarjeta de credito.

www.sg.com.mx |

Algunos proveedores funcionan desde cualquier parte del mundo, mientras que otros funcionan solo para un país en específico, por lo que esta sería la primera cuestión a considerar. En www.online-payment-processing.com puedes consultar una lista de los IPSPs más populares.

.PRINCIPAL

GATEWAYS DE análisis de paypal y dineromail ››Por Manuel Contreras

PAGO

El comercio electrónico en México ha tenido una lenta penetración. Algunos causas son la falta de educación en computación en general, la pobre infraestructura en gran parte del interior del país, y a la gran desconfianza que existe de dejar en un sitio web los datos de una tarjeta de crédito. > Hace unos 10 años, cuando Amazon ya era todo un éxito, en México todavía eran muy pocos los sitios que aceptaban tarjetas de crédito para hacer transacciones. En nuestro país existía el riesgo real de que los datos fueran interceptados, o de que nunca se recibieran los artículos adquiridos. Por ello las terminales “virtuales” para aceptar pagos vía Internet requerían fianzas, garantías, y no todas las instituciones bancarias las sabían manejar. Además de deber salvar este tipo de obstáculos, el sitio que recibiera los datos del plástico debía reunir medidas de seguridad poco accesibles en el pasado, como contar con certificados de seguridad, y la obligación de encriptar los datos de la tarjeta de crédito no eran asunto que cualquier persona pudiera resolver con los medios a su alcance, ya que era necesario contar con los servicios de un desarrollador experimentado en estas cuestiones y contratar hospedajes que ofrecieran ciertas sofisticadas medidas de seguridad, que incluían la instalación de certificados SSL entre otros muchos requisitos. Al pasar del tiempo surgieron nuevas opciones en México para aceptar este tipo de pagos, que brindan a cualquiera la infraestructura y medidas de seguridad que aseguren una transacción exitosa, cobrando a cambio una comisión por cada transacción. Estos son los llamados Gateways de pago en Internet. El uso de estos Gateways o portales de pago presenta varias ventajas, porque además de liberar al vendedor de las cuestiones técnicas que implica manejar cargo a tarjeta de crédito, generan en el comprador la percepción de que es poco probable que se trate de un fraude o de un intento de robo de identidad. Los Gateways de pago son sencillos de integrar prácticamente en cualquier tipo de página de Internet, y permiten la compraventa de cualquier artículo, incluso productos digitales tales como eBooks o música. Hoy en día estos Gateways han permitido mayor participación de las ventas en línea en el mercado de nuestro país. De acuerdo con un estudio de la AMIPCI, en 2009 la confianza de los compradores en Internet ya era del 55%, y solamente el 2% desconfiaba de hacer pagos por la web. En este artículo hablaremos de dos grandes Gateways de pago en México, que son PayPal y DineroMail.

Funcionamiento general

Ambos funcionan de manera similar. El comprador debe registrarse para establecer una cuenta. La información solicitada es la más elemental: datos personales, dirección postal y de correo electrónico, números de contacto, nombre de la empresa o negocio, un titular para la cuenta, y listo. Prácticamente desde ese momento se podrán empezar a hacer y recibir pagos por Internet. El funcionamiento es sencillo. Un comprador ingresa al sitio de venta y selecciona las mercancías que pretende adquirir. Una vez que informa estar listo para pagar, es remitido a la interfaz del Gateway, que lo lleva a un servidor seguro externo para que procese el pago. En ese sitio, donde se cumplen los protocolos de seguridad requeridos, validan la transacción. Una vez que el pago ha sido aceptado el comprador es remitido al sitio original, donde se le informan tanto el resultado del proceso de pago como las demás cuestiones involucradas en la transacción. En cuanto a la entrega del dinero cobrado al vendedor, el Gateway en cuestión tomará el pago realizado, restará la comisión establecida, y el importe será abonado a la cuenta del vendedor. Cada Gateway de pago maneja diferentes políticas para hacer retiros, y aunque en general no existen montos mínimos, usualmente cobran una comisión cuando se hacen en cantidades pequeñas. 22

www.sg.com.mx |

Software Guru

.PRINCIPAL

La manera más sencilla de convertir en dinero “real” el saldo acumulado en alguno de estos dos Gateways de pago es transferirlo vía electrónica a una cuenta bancaria previamente configurada. Hoy en día también es posible mantener el saldo en dichas cuentas y usarlo para pagar otros servicios a través de los mismos Gateways, gracias a que la red de compradores y vendedores que aceptan estos métodos de pago se va extendiendo aceleradamente dado que el mecanismo es popular, rápido y sencillo. Así de fácil es ofrecer a los usuarios opciones de pago por Internet hoy en día. Ahora bien, al manejarse dinero, es importante que exista el mayor número de verificaciones posibles, lo que redundará en una buena reputación en cuanto a la aceptación de estos medios de pago. Cada Gateway de pago tiene opciones diferentes para efectuar estas verificaciones.

Verificación

En el caso de PayPal existen límites de transacción antes de que la cuenta sea verificada. Los límites se establecen en cuanto a “Límite de envío de dinero”, “Límite de retiro de dinero” y “Límite anual de recepción de dinero”. Esta verificación se elimina al proporcionarse los datos de una tarjeta de crédito, en la cual PayPal efectúa un cargo no mayor de $2.50 USD —o su equivalente—, que aparecerá en el estado de cuenta junto a una clave, la clave indicada se deberá ingresar en la cuenta PayPal para liberar las limitaciones. Una vez verificada la cuenta, PayPal bonifica la cantidad cargada inicialmente. En el caso de DineroMail, la verificación se debe hacer enviando una serie de documentos, que dependen del modelo fiscal de la empresa o negocio, tales como identificación oficial, comprobante de domicilio, copia del estado de cuenta a la que se transferirán los recursos; si se trata de una persona moral, adicionalmente será necesaria copia del RFC y del Acta Constitutiva. En ambos casos es importante la dirección electrónica del sitio y una breve descripción de los servicios a comercializar. Estas verificaciones son muy importantes para que los clientes adquieran confianza en el sitio. Existen diversos tipos de cuentas, tanto para vender como para comprar, así como diferentes maneras de integrar estos métodos de pago a un sitio web.

Tipos de Pago.

En ambos casos se pueden aceptar pagos vía correo electrónico. Para esto el vendedor genera una solicitud de pago a través del Gateway, desde donde se envía inmediatamente un correo electrónico al comprador que contiene un enlace único. A través de este link o enlace, el destinatario ingresa con un clic y termina el pago. Al cerrarse la transacción se envía un correo electrónico a ambos con el resumen de la operación, además de agregarse al historial de pagos en los paneles de ambas cuentas. En el caso de la integración de los servicios en una página web, en ambos casos es sumamente sencilla. Ambos Gateways permiten crear botones con importes y características de productos predefinidos. Estos botones se reducen a un tramo de código HTML, el cual se copia y se pega en el sitio donde se requiera. Incluso se pueden personalizar con una imagen desarrollada específicamente. 22

En general PayPal cuenta con botones predefinidos, con los que a través de una sencilla interfaz se puede generar el código que permite empezar a utilizarlo de inmediato en un sitio web, agregándose botone tales como: “Comprar Ahora”, “Suscribirse”, “Donativo”, etc. Actualmente se pueden hacer pagos en México, sin importar si el cliente esté o no registrado en PayPal, siempre que utilice tarjetas de crédito o débito Visa o Master Card, o tarjetas American Express. Por su parte, DineroMail tiene una forma de implementarse muy similar. Se pueden crear también botones de pago y/o integrar en el sitio web un sencillo carrito de compras. Una de las ventajas que ofrece DineroMail es que se pueden generar botones con mayor grado de personalización, por ejemplo, cuando se desean ofrecer al comprador paquetes de mensualidades pero sólo con ciertas tarjetas de crédito. DineroMail también ofrece la posibilidad de aceptar pagos con tarjetas Visa, Master Card y American Express. PayPal es mucho más grande que DineroMail a nivel mundial. Opera más de 150 millones de cuentas, y hoy en día es parte de E-Bay —un sitio destinado a la subasta de productos a través de Internet y uno de los pioneros en este tipo de transacciones desde 1995—, por lo que ofrece total integración para los pagos en este sitio de subastas. También cuenta con la opción de CheckOut Express, en la cual proveedores de productos de comercio electrónico incluyen módulos programados para que únicamente se proporcionen los datos de la cuenta PayPal y pueda utilizarse de inmediato para compras en línea. DineroMail es una empresa que va creciendo y ganando mercado, principalmente en América Latina. En México ofrece una posibilidad muy interesante, que es la creación de cupones de pago. Éstos se pueden generar desde la página web del emisor o ser enviados por correo electrónico, y con ellos se puede efectuar el pago en miles de tiendas de conveniencia a lo largo del país (ej. Oxxo). Esta opción resulta de gran ayuda para cerrar ventas, ya que mucha gente no cuenta con tarjeta de crédito o no se atreve a usarla para comprar por Internet. Resulta una buena forma de poner el negocio al alcance de todos. El pago es reportado por DineroMail entre 24 y 48 horas después de realizado. En general ambas opciones son muy buenas, sin embargo, es importante analizar qué tipo de aplicación se pretende desarrollar, qué producto se va a vender, y qué alcance se quiere tener. Por ejemplo, si se planea comercializar artículos que se enviarán a los Estados Unidos, PayPal tiene mayor presencia en ese país y por lo mismo generará mayor confianza en su mercado objetivo. Por el contrario, si se pretende vender productos destinados a zonas en el interior de la República, las opción de cupones de pago ofrecida por DineroMail podría ser mejor.

Tarifas

Ambas soluciones ofrecen un servicio seguro, y sus tarifas son competitivas. El rango de PayPal va del 2.4% al 3.4% mas una tarifa fija de $4.00 pesos por transacción. En el caso de DineroMail las comisiones van desde el 1.99% hasta el 4.99%, en pagos que se pueden recibir incluso en mensualidades, más una tarifa fija de $3.00 pesos por transacción. En cualquiera de los dos casos las comisiones suelen resultar más económicas que las ofrecidas por la mayoría de las instituciones bancarias.

Diferencias

A pesar de todo, entre PayPal y DineroMail existen diferencias muy marcadas. En caso de pretenderse implementar soluciones un tanto más complicadas, PayPal ofrece una extensa documentación que permitirá desarrollar una aplicación completamente automatizada. Ofrece adicionalmente un ambiente para pruebas, donde se puede simular la operación de las aplicaciones, y una enorme cantidad de manuales y ejemplos para apoyar a desarrolladores con más experiencia, quienes al valerse de estos recursos pueden lograr una aplicación que se integre perfectamente con PayPal. Por otro lado, en lo que respecta a DineroMail, la documentación es simple y muy sencilla de digerir, pero las soluciones para desarrolladores expertos son mucho más limitadas. El soporte y la atención al cliente son cuestiones muy importantes que hay que mencionar. En el caso de PayPal existe una estructura muy funcional; por ejemplo, todas las preguntas, quejas o sugerencias se hacen vía correo electrónico, simplemente levantando un “ticket”. Cualquier cuestionamiento suele tener respuesta en cuestión de horas. En general el servicio al cliente de PayPal es rápido, directo, y lo más importante, en el idioma del solicitante. Por otro lado, DineroMail, a pesar de tener su sede en la Ciudad de México, basa su soporte técnico y su atención al cliente meramente en el correo electrónico. 25

Las respuestas suelen tardar entre 24 y 48 horas después de haberse levantado el “ticket”.

Conclusión

Ambas empresas son muy buenas opciones para la venta de bienes por Internet, sin embargo, la decisión final sobre la elección de una u otra —o las dos— debe basarse principalmente en cuestiones tales como los hábitos de consumo del mercado meta o la zona geográfica de destino de los productos a comercializar. Finalmente es necesario recalcar que el comercio por Internet ha tenido gran crecimiento a nivel mundial en la última dé.BIO cada, y México no es la excepManuel Alejandro Contreras es desarrollador web y asesor ción. Al existir opciones como en estrategias de marketing en Interplanet. Ha implementado PayPal y DineroMail al alcance gateways de pago en distintos de la mano, no quedan pretexproyectos, destacando principalmente el de SuEmpresa.com. tos para seguir pensando que Manuel es ingeniero en sistemas egresado del Tec de Monterrey comprar bienes por Internet Campus Ciudad de México. es más bien una creación de la @senseimac pluma de Isaac Asimov.

www.sg.com.mx |

Software Guru

.PRINCIPAL

GENERACIÓN DE

agrega facturación electrónica a tus apps ››Por Heber Lazcano Camargo

CFDI

A partir del 1 de enero del 2011 entro en vigor la versión 3.0 de facturación electrónica en México; en donde para los contribuyentes que estén obligados o decidan usar está versión tienen que realizar sus comprobantes vía Internet. Los requisitos que debe cumplir el contribuyente para emitir CFDI son: 1. Contar con Firma Electrónica Avanzada vigente. (FIEL) 2. Tramitar al menos un Certificado de Sello Digital (CSD) 3. Contar con un sistema informático para la generación de las Facturas Electrónicas 2011. 4. Enviar a validar las facturas electrónicas al proveedor autorizado de certificación (PAC) En la figura 1 se ilustra a grandes rasgos el proceso para generar un CFDI: 1. Generar un archivo XML 2. Enviar el XML a un PAC para que lo verifique y genere un Timbre Fiscal Digital. 3. Insertar el Timbre Fiscal Digital a nuestro XML dentro del nodo Complemento. 4. Enviar el CFDI al cliente.

Figura 1. Proceso para generar un CFDI.

.PRINCIPAL

Generación del archivo XML

El archivo XML que se tiene que generar deberá cumplir con las reglas definidas dentro del Anexo 20 de la Resolución Miscelánea Fiscal del 2010 publicado por el SAT, el cual especifica: • La estructura que deber tener el CFDI • La forma de generación del sello digital • El uso del complemento obligatorio: Timbre Fiscal Digital Para realizar el XML siguiendo la estructura definida, descargamos el esquema XML disponible en http://www.sat.gob.mx/sitio_internet/cfd/3/cfdv3.xsd. Utilizando la tecnología Apache XMLBeans podemos generar clases de Java automáticamente a partir del archivo xsd. Una vez que descarguemos e instalemos XMLBeans (http://xmlbeans.apache.org) ejecutaríamos el siguiente comando:

el número de certificado del CSD, así como el mismo CSD pero codificado en base 64 (Ver listado 4). Para ello crearemos un objeto X509Certificate y usaremos las funciones que se aprecian en el listado 3.

Listado 2. Creación de un emisor.

Listado 3. Funciones para leer un CSD.

Listado 4. Asignación del número de certificado y CSD en base64.

Sello Digital

Una vez teniendo todos los valores asignados a nuestro objeto Comprobante, el siguiente paso es generar el sello digital con lo cual garantizaremos la integridad y autenticidad de este. Listado 1. Creación de un objeto Comprobante.

Continuaremos generando la demás información del comprobante: emisor, receptor, conceptos, impuestos, entre otros. Dentro del listado 2 podemos apreciar cómo crear el emisor. También necesitamos incluir dentro del objeto Comprobante 27

Para ello es necesario: 1. Generar la cadena original del comprobante 2. Aplicar el método de digestión SHA-1 a la cadena original. 3. Aplicar el algoritmo de encriptación RSA al resultado de la digestión.

www.sg.com.mx |

Esto generará el archivo dfdv3.jar que contiene las clases que corresponden al esquema XML. Registra este jar así como las librerías de XMLBeans en tu proyecto del IDE que estés utilizando. Una vez que tenemos registradas las librerías necesarias, podemos proceder a programar el comportamiento deseado. Empezaremos creando un objeto de tipo ComprobanteDocument y a partir de eso generaremos un objeto Comprobante, el cual nos permitirá construir toda la estructura del XML y asignar los valores deseados a nuestro comprobante. Este código se aprecia en el listado 1.

Software Guru

~\xmlbeans\bin>scomp.cmd -compiler “[Ruta a jdk]\bin\javac. exe” cfdv3.xsd -out cfdv3.jar

.PRINCIPAL

Listado 7. Función para generar el sello digital.

Ahora solo nos resta invocar a las 2 funciones anteriores para generar el sello digital y hacer la asignación del resultado al objeto Comprobante, esto lo apreciamos en el listado 8.

Listado 8. Generación del sello digital.

Timbrado del CFDI

Hasta este punto aunque ya tenemos un comprobante creado y firmado como se indica en el Anexo 20, todavía no es válido ya que no contiene un timbre fiscal digital. Debemos enviar nuestro XML generado a un PAC, para que este lo verifique y genere el timbre fiscal digital (TFD) que debemos incluir dentro de nuestro XML en el nodo de complemento. En el sitio web del SAT se puede consultar la lista de PACs autorizados que nos pueden ofrecer el servicio de timbrado. Todos ellos implementan un servicio web estándar que definio el SAT y que realiza lo siguiente: 1. Recibe el comprobante firmado 2. Valida el comprobante 3. Genera el timbre fiscal digital Listado 5. Función para generar la cadena original.

Para el paso 1 el SAT público un XSLT que genera la cadena original de la forma que se encuentra especificada dentro del Anexo20, por lo cual lo único que debemos hacer es aplicar una transformación XSLT a nuestro XML que generamos anteriormente (Ver listado 5). Para la digestión y encriptación Java puede realizar estos 2 pasos llamando a una sola clase (Ver listado 7), para ello primero tenemos que tener un objeto PrivateKey (ver listado 6) que es la representación de nuestra llave privada otorgada por el SAT para firmar los comprobantes que generemos.

La tabla 1 muestra las validaciones que el PAC realiza a un comprobante, junto con el código de error correspondiente. Para ejemplificar como podría hacerse el timbrado con un PAC, vamos a mostrar como utilizaría el cliente llamado StampyClient que es proporcionado por el PAC Tralix a sus clientes para realizar el timbrado. En el listado 9 se muestra como invocar este cliente. Cabe mencionar que Tralix también provee un cliente para .NET y se invoca de manera similar. Si por alguna razón nuestro XML no pasará alguna de las validaciones de la tabla 1, el cliente arrojara una excepción de tipo StampyClientException que contiene el código y la descripción del error.

Conclusión

En este artículo hemos aprendido cómo generar desde nuestras aplicaciones un CFDI 100% válido que podemos entregar a nuestro cliente por medios electrónicos. Les recuerdo que por obligación fiscal, debemos almacenar los CFDIs que generemos por 5 años.

Listado 6. Función para obtener la llave privada.

Listado 9. Invocación de timbrado.

Código 301 302 303 304 305 306 307 308 401 402 403

Descripción de la validación Que cumpla con el estándar de XML conforme al W3C y con la estructura del XSD publicado en el Anexo20 y complementos aplicables. Que el sello del emisor sea válido. Que el CSD del emisor corresponda al RFC que viene como emisor en el comprobante. Que el CSD del emisor no haya sido revocado, utilizando la LCO. Que la fecha de emisión esté dentro de la vigencia del CSD del emisor. Que la llave utilizada para firmar corresponda a un CSD y no a una FIEL. Que no contenga un timbre previo. Que el CSD del emisor haya sido firmado por uno de los certificados de autoridad del SAT. Que el rango de la fecha de generación no sea mayor a 72 horas para la emisión del timbre. Que exista el RFC del emisor conforme al régimen autorizado, utilizando la LCO. Que la fecha de emisión sea posterior al 01 de Enero 2011.

Tabla 1. Validaciones de un comprobante.

Referencias: [1] SAT. “Comprobantes Fiscales”. http://bit.ly/sg31r6

.BIO Heber Lazcano actualmente se desempeña como Arquitecto de Software en Tralix México. @heberlazcano

.PRINCIPAL

ANÁLISIS DEL SISTEMA DE

FACTURA ELECTRÓNICA extensiones posibles ››Por José Cruz Aarón Hernández

Desde mayo del 2004 el Servicio de Administración Tributaria (SAT) aprobó la facturación electrónica como un esquema de comprobación fiscal. La factura electrónica o Certificado Fiscal Digital a través de Internet (CFDI) es utilizada por el comprador y por el vendedor como comprobante ante las autoridades y en las auditorías internas.

.PRINCIPAL

Una Plataforma de Facturación Electrónica debe ser un sistema seguro, con una alta disponibilidad, robusto e interoperable, el cual se encargue de administrar transacciones en las que la unidad fundamental de operación es la factura electrónica. Dicho sistema debe interactuar con sistemas externos que lo alimenten y consuman los servicios provistos para el proceso de facturación. Cada sistema externo representa a uno o más contribuyentes los cuales tiene la necesidad de emitir y recibir comprobantes digitales asociados al giro, actividad o servicio que preste dicho contribuyente. • Plataforma Interna del SAT. La plataforma interna del SAT es la encargada de coordinar, administrar y sincronizar a los proveedores autorizados, además de administrar la información concerniente a los contribuyentes y sus facturas electrónicas asociadas. • Proveedor Autorizado de Servicios. Fungen como intermediarios entre el contribuyente y el SAT, brindando una gama de servicios para llevar a cabo correctamente el proceso de facturación electrónica y posteriormente realizar tareas de sincronización con el SAT. • Sistema externo del contribuyente. Cualquier aplicación de software que incorpore el proceso de facturación electrónica. Dicho sistema consume servicios que provee el proveedor autorizado. A continuación se plantean los aspectos principales del sistema propuesto que pudiera extender y mejorar al existente.

Seguridad

Para el manejo de la seguridad de las facturas electrónicas, el SAT considera el uso de criptografía de clave pública, por lo que provee a cada contribuyente de un par de claves, una pública y otra privada, además de un certificado digital que avala la identidad del contribuyente especificando sus datos fiscales además de su llave pública. Una factura electrónica contiene dos firmas digitales, una provista por el emisor del comprobante fiscal utilizando su clave privada y firmando la factura y otra emitida por un tercero autorizado que firma los datos de fecha y hora del timbrado, el identificador de la transacción así como la

En este esquema se utilizan dos certificados digitales: uno que acredita la clave pública que conforma a la FIEL de un contribuyente y otro u otros para sellar digitalmente facturas digitales. Dichos certificados son RSA con claves de 1024 bits y 2048. Un incoveniente es que dichos certificados no están disponibles en un repositorio de certificados mediante el cual cualquiera pudiera obtener un certificado que le interese, como por ejemplo el de los contribuyentes que le emitieron facturas digitales, para poder verificar los comprobantes recibidos. Para el correcto uso y funcionamiento de los certificados digitales es necesario de la incorporación de la Infraestructura de Llave Pública (PKI), la cual es una combinación de software, tecnologías de cifrado, y servicios que permiten proteger la seguridad de las transacciones de información en un sistema distribuido. Debido a que el SAT asume el papel de una autoridad certificadora —ya que genera los certificados digitales y también cumple con tareas de afiliación de los contribuyentes—, el SAT podría hacer uso de PKI para un buen funcionamiento en cuanto a poner a disposición de los contribuyentes los certificados digitales de los demás, así como las listas de revocación. En cuanto a los mecanismos criptográficos, se propone el uso de certificados digitales RSA donde se utilice una PKI para los procesos de autenticación y negociación de claves en el intercambio de datos, pero para la firma de los comprobantes digitales se utilicen Curvas Elípticas ECC. Para esto sería necesario brindar un esquema donde se firmen las facturas con la clave privada de un contribuyente pero utilizando criptografía de Curvas Elípticas y por ende la utilización de certificados digitales ECC. Desafortunadamente aun no existe un estándar para una Infraestructura de Clave Pública con certificados que utilicen Curvas Elípticas. Para determinar la validez de un documento es necesario un mecanismo que nos asegure su validez. En las facturas electrónicas dicho mecanismo es el de la firma digital usando criptografía de clave pública. Dicha firma está compuesta por un resumen del documento al que se le aplica una operación de cifrado con la clave privada del emisor, de tal forma el documento no puede alterarse por que la firma lo acredita, en caso de alteraciones a la factura el proceso de validación utilizando la clave publica fallaría, haciendo evidente la alteración del documento. Es importante estar seguros que los métodos de criptografía utilizados en las facturas digitales sean lo suficientemente complejos para que no pueda descifrarse y no permitir que un tercero no autorizado pueda emitir facturas en el nombre de alguien más. Existen diferentes formas de firmar un documento digital, sin embargo cada mecanismo tiene ventajas y desventajas. Se propone la utilización de ECDSA, ya que utiliza criptografía de curvas elípticas, y esta posee los elementos necesarios para firmar comprobantes fiscales digitales con un buen nivel de seguridad, también se propone el uso de SHA-256 para generar el valor resumen de la factura digital. 31

Software Guru

Plataforma de Facturación Electrónica

primera firma del comprobante fiscal digital, ambas están inmersas en un nodo de la factura digital que se le denomina Timbre Fiscal Digital.

www.sg.com.mx |

> El anexo 20 de la miscelánea fiscal especifica el estándar para conformar correctamente una factura digital, la que es un documento XML que es integrado por los datos del emisor de la factura, el receptor de la misma, los conceptos e impuestos, además de la posibilidad de integrar campos de información útiles para sus sistemas internos, dichos datos son posibles de integrar gracias al nodo addenda. En el presente artículo se presenta un análisis general del esquema existente de facturación electrónica en México, y posteriormente se propone un sistema que pueda extender al actual y trate de mejorar las áreas de oportunidad detectadas.

.PRINCIPAL

En a la autenticación, en el el esquema de facturación digital para 2010 la autenticación en los sistemas del SAT se puede realizar mediante el uso de la Clave de Identificación Electrónica Confidencial CIEC, que está formada por el RFC del contribuyente y una contraseña asociada. Este mecanismo sirve para tramitar la Firma Electrónica Avanzada FIEL y los Certificados de Sello Digital. Otra forma de autenticación es utilizando la FIEL desde un aplicación que se ejecuta en la máquina del contribuyente.

En el caso de la recepción de facturas digitales, el contenedor recaba las facturas asociados al contribuyente. Posteriormente el interesado y dueño de las facturas consume un servicio que le permite recuperar las mismas que se encuentran en su contenedor. Cuando se consume el servicio asociado a recibir las facturas digitales en las que el contribuyente es el receptor, automáticamente se genera el proceso que se encarga de actualizar el estado de la factura a “Recibida”, con lo que se completa el proceso de acuse.

La FIEL no es más que un mecanismo de criptografía de clave pública, esto con el fin de poder firmar digitalmente trámites en los procesos en línea que provee el SAT; uno de ellos es el de firmar el requerimiento para que se otorgue el certificado de sello digital para emitir facturas electrónicas. Para la plataforma de facturación electrónica propuesta se propone adoptar el mecanismo de autenticación de dos vías o mutuo, el cual está definido en el protocolo y permite que ambas partes que intervienen en la comunicación posean un certificado digital, en este caso la FIEL del lado del contribuyente, y un certificado digital del lado del servidor. De esta forma se establece un canal seguro entre la aplicación del contribuyente y la plataforma de facturación.

Conclusión

Envío, recepción y acuse de CFDI

En el esquema de facturación actual no se tiene contemplado formalmente el envío y recepción de los comprobantes fiscales digitales. Se especifica que se pueden intercambiar electrónicamente, pero no se detalla en absoluto un esquema formal de envío, recepción ni acuse. En el caso práctico, los contribuyentes regularmente envían por correo electrónico los comprobantes digitales a aquellos que se les emite dicha factura digital. Sin embargo no se contemplan los casos en los que por una u otra razón el correo no fue recibido exitosamente (ej. dirección de correo equivocada, categorizado como spam, etcétera). La propuesta de la plataforma de facturación electrónica consiste en definir servicios web que se encarguen de las tareas de enviar, recibir y acusar las recepciones. El proceso de envío es muy simple. Cuando se genera un comprobante fiscal digital y el proceso que lo genera se completa de forma satisfactoria, es hora de enviárselo al receptor de dicha factura digital por lo que automáticamente se envía al contribuyente que esté marcado como receptor en el comprobante fiscal digital. De tal forma que cada contribuyente posee un contenedor de facturas digitales, donde se acumulan las facturas electrónicas donde el contribuyente figura como receptor. Es muy similar a una bandeja de entrada de correo electrónico, sólo que en lugar de correos electrónicos llegan facturas digitales y en lugar de direcciones de correo electrónico se usa el RFC propiedad de un contribuyente en particular. 32

En este artículo revisamos algunas extensiones que se podrían hacer a una plataforma de facturación electrónica para poder mejorar su seguridad y desempeño.

Referencias: [1] F. Rodríguez, N. Cruz Cortés & V. González García. “On the Security of Mexican Digital Fiscal Documents”. http://bit.ly/sg31r5

.BIO José Cruz Aarón Hernández es Ingeniero en Ciencias de la Computación y Desarrollador de Software desde 2007. Actualmente está cursando la Maestría en Ciencias de la Computación con especialidad en Base de Datos en la Universidad Autónoma de Puebla. @alarakx

.COLUMNA Invitada

Certificados Digitales

diferencias cualitativas importantes que hacen que muchos paradigmas del mundo del papel no se puedan trasladar al mundo de la electrónica. Mientras que la firma autógrafa opera sobre papel y el mensaje está consustancialmente ligado a él, en forma que es legible para el firmante, la firma digital opera sobre un stream de bits que se visualizan mediante una gran variedad de aplicaciones. En el papel, el firmante ve directamente el mensaje a firmar; en la firma digital no. Así las cosas, la seguridad de una firma digital depende mucho de la seguridad de un dominio aplicativo. Un dominio aplicativo inseguro puede llegar, en el peor de los casos, a robar la clave privada, o en el mejor de los casos, obtener la firma de un mensaje diferente al mensaje que el firmante cree estar firmando. ¿Usted expondría su, única y universal, clave privada a la aplicación del vendedor de pizzas local? ¿La misma clave privada con la que transfiere electrónicamente dinero? Claro que no. El certificado universal es un concepto que no funciona. Resulta ser considerablemente más seguro utilizar un par de claves por cada dominio aplicativo. También es importante que el estampillado de tiempo (timestamping) se regule, pues las estampillas de tiempo —al contrario de los certificados— no tienen evidencia material que los sustente y les de valor probatorio. Su valor probatorio depende de que, quien los emita, pueda demostrar que efectivamente, no puede emitir estampillas fuera del tiempo real. En nuestro país, la NOM-151 tiene esta función de regular el estampillado de tiempo, pero desafortunadamente lo hace mediante su propio protocolo, en lugar de adoptar uno de los estándares internacionales que existen en esta materia. La Secretaria de Economía, quien tiene la función de regular en esta materia —y quien por cierto tiene a reguladores conocedores y experimentados en este campo— se encuentra en el proceso de revisión de la NOM151. Todo parece indicar que el cambio será hacia la adopción de estándares internacionales, lo cual será muy beneficioso para nuestro país.

››Por Ignacio Mendivil .BIO Ignacio Mendivil es Fundador y Presidente de SeguriData, empresa ganadora del Premio Nacional de Tecnología 2005. Ignacio es autor del libro “El ABC de los Documentos Electrónicos Seguros”.

Software Guru

n la criptografía asimétrica y su acompañante, la infraestructura de clave pública PKI, todo empezó muy bien en el aspecto matemático, computacional y estructural. Pero todo empezó mal con la nomenclatura de certificado digital y de autoridad certificadora. Considero que credencial digital y unidad de credencialización digital son términos más adecuados. En los años noventa mientras se trabajaba en la ley modelo de la UNICTRAL imperaba el criterio de que los certificados digitales deberían ser emitidos por autoridades certificadoras reguladas. Esta noción se basaba en trasladar el paradigma de credenciales confiables del mundo del papel hacia el mundo de la electrónica. Este traslado de paradigma resulta ser, en el mejor de los casos, muy limitado. Sin embargo, la gran aportación de la ley modelo de firmas electrónicas de la UNICTRAL es su clausulado en materia de firma electrónica y su gran fracaso es el clausulado en materia de autoridades certificadoras. El excelente clausulado sobre firma electrónica catalizó el uso de la firma electrónica utilizando autoridades certificadoras de dominio aplicativo. Las organizaciones que arrancaron autoridades certificadoras de dominio aplicativo estaban conscientes de que la regla de oro era preservar una o más pruebas, incontrovertibles, de la vinculación de los firmantes con su clave pública. Esto les garantizaba un alto valor probatorio, de mensajes firmados digitalmente y su vinculación al firmante, ante cualquier contingencia o contención. Las organizaciones que intentaban arrancar sistemas de firma digital se dieron cuenta que: Era mucho más fácil y barato, e igual de seguro, certificar a sus usuarios con su propia autoridad que mediante autoridades certificadoras reguladas. En la gran mayoría de las aplicaciones, la parte jurídica denominada “quien confía” es la propia organización implementando firma en su dominio aplicativo. Existe un proceso de enrolamiento de los usuarios con el dominio aplicativo. Esto hace que el certificado resida en el registro del usuario ante el dominio aplicativo y, por lo tanto: a) se blinda al dominio aplicativo del problema de certificados falsos, b) se reduce la problemática de la revocación, y c) los certificados son solo válidos en el dominio aplicativo y fuera del dominio no representan ningún riesgo. Por otra parte, la visión de que los certificados emitidos por autoridades reguladas podrían ser utilizados indiscriminadamente en diferentes dominios aplicativos resultó ser un falso traslado del paradigma de “credenciales universales” del mundo del papel. La verdad es que aunque la firma autógrafa y la firma electrónica son equivalentes funcionalmente, éstas tienen

www.sg.com.mx |

panorama y posibilidades de mejora

.COLUMNA Invitada

Cambiando a un Modelo de Entrega SaaS consideraciones clave

Si cubre las necesidades de su organización en términos de metas, entonces el modelo de entrega de SaaS debe ser adoptado. Es muy importante permanecer centrado en los problemas que usted está intentando solucionar antes de seleccionar el modelo correcto de entrega de software para su organización. Asegúrese de no centrarse exclusivamente en el ahorro en costes o el ROI asociado al soporte físico, al software, y a los costos administrativos asociados. Éstos son importantes, pero usted puede alcanzar un valor de negocio perceptiblemente mayor seleccionando una solución que ha probado las capacidades para mejorar la eficacia y la eficacia del personal de su Service desk y de los procesos de negocio. Las soluciones entregadas vía SaaS deben ser capaces de proveer un activo integrado y cambios administrativos, así como un service desk y la gestión de incidentes y problemas. También deben proveer auto servicio, incluir la configuración de activos, el rastreo de inventarios e integrarse a la plataforma de base de datos. Con la entrega a través de SaaS en la Gestión de Servicio, su departamento de TI se puede beneficiar al tener solamente un Modelo de Datos Central y compartido y un punto de vista de servicio unificado de un extremo a otro de todas las funciones y procesos por medio de la plataforma de bases de datos además de apalancar una arquitectura única, sin interfaces de punto a punto que mantener. Sólo como Administración de Servicio de TI, ayuda a que la empresa sea más eficiente y responsable, los métodos mediante los cuales se utilizan y mantienen las soluciones pueden tener mayor impacto en la productividad y el desempeño de TI de la compañía. SaaS puede ser una gran opción que permita que su organización de TI empiece a funcionar y a correr más rápido, particularmente si no cuenta con las habilidades necesarias dentro de su compañía. Además esto le puede ayudar a centrarse en los problemas esenciales que quiere resolver. Considere seleccionar un proveedor que tenga las mejores prácticas ya integradas en soluciones desde el inicio, que pueda ofrecer una configuración estandarizada de IT Infraestructure Library (ITIL) para conseguir comenzar. Evite un ofrecimiento de SaaS donde necesite adaptar en exceso la solución para obtener capacidades básicas aceptables para resolver sus necesidades. Sus necesidades de negocio cambiarán con el tiempo, por lo que es particularmente importante buscar por un proveedor que le dé la oportunidad de moverse fácilmente, costo-beneficio y rápido de un modelo de servicio a otro.

l Software como servicio (SaaS) es más que un modelo de entrega basado en la nube. Es un acercamiento al servicio que las organizaciones están considerando para satisfacer sus necesidades de Gestión de Servicio TI. Este modelo es atractivo porque puede ofrecer muchos de los beneficios que ofrece el modelo tradicional de administración de servicio de TI, agregando otras como la reducción de costos, acelerar el tiempo en que las aplicaciones empiezan a funcionar y a correr además de proveer actualizaciones de una forma más sencilla. Los modelos típicos de SaaS permiten que el servicio sea hosteado, entregado y administrado remotamente vía Web y ofrecen un procesamiento de información compartido y el almacenamiento de recursos a través de una suscripción.

Cómo decidir: ¿Un modelo In-House de Gestión de Servicio o SaaS?

La respuesta depende del tipo, del nivel y del costo de las habilidades de TI dentro de su organización, también del presupuesto contra costos operacionales, de la probabilidad del crecimiento en su infraestructura de TI y del nivel de personalización e integración que requieren sus procesos entre otros elementos de su infraestructura de TI y de las soluciones de gestión. Las organizaciones de TI que deben considerar integrarse a una administración del servicio de TI vía el modelo de SaaS tienen muchas de las siguientes necesidades: • Falta de tiempo, presupuesto, o personal para implementar la configuración administrativa de las plataformas de bases de datos (CMDB) o para integrar los nuevos sistemas de gestión múltiples a los propios. • Necesidad de reducir o de evitar los costos por comprar el soporte físico y software adicionales. • Requiere seguridad de datos de SAS 70 o de ISO 27002 pero carece del personal o las habilidades para ejecutarlo. • Tiene requisitos variables en las capacidades de Gestión de Servicio de IT o enfrenta un crecimiento imprevisible. .BIO Paul Avenant es Software Senior Vice President, Enterprise Service Management Products and Strategy en BMC.

SaaS es una opción viable para la Gestión de Servicio de TI como entrega y una opción de modelo de negocio.

››Por Paul Avenant 34

.PRÁCTICAS Usabilidad

La Importancia de la Claridad y Sencillez de una Interfaz de Usuario

›› Por Pamela Rodríguez Domínguez

pesar de que este concepto ya tiene tiempo de existir y circular por el mundo de la tecnología de información, la ‘experiencia del usuario’ aún no ha sido comprendida en su totalidad por la mayoría de los que trabajamos en este medio. Un error común es el de pensar que la experiencia del usuario sólo debe tomarse en cuenta al trabajar en aplicaciones web. El concepto de la experiencia del usuario ni siquiera se limita a la tecnología de información y su importancia va más allá de generar en nuestros clientes meta, la sensación de que utilizan algo bonito.

La verdadera experiencia

En realidad, el objetivo no es que el usuario se dé cuenta de lo que hemos hecho bien al desarrollar una interfaz. Normalmente aplica más la premisa popular de ‘Si no hay noticias, son buenas noticias’, puesto que algo que genere comentarios en los usuarios normalmente será algo erróneo. Si la experiencia de uso de un producto es satisfactoria, la persona reconoce esa satisfacción, mas no se detiene a notar qué es lo que la ha provocado. Se acepta la satisfacción recibida, así como el producto, nada más. Si su experiencia, en cambio, ha resultado negativa, cada uno de los detalles que conforman su incomodidad permanecerán en su memoria. En palabras de uno de los más grandes exponentes en la actualidad de la experiencia del usuario, Jared M. Spool: “El buen diseño es invisible”. Otro error muy común entre desarrolladores es pensar en términos de lo que será más sencillo de programar: no siempre lo sencillo es lo más práctico o lo más eficiente o más preocupante aún, lo más sencillo no equivale a lo más intuitivo, es decir, a lo que será más fácilmente comprendido por el usuario. De este modo, terminamos perdidos en interfaces complejas y asimétricas que poco hacen por ayudar a las personas a cumplir con su objetivo en el uso de las mismas. Pero no solamente recaen en los desarrolladores las equivocaciones que afectan la experiencia del usuario ya que también se encuentran los diseñadores que en su intento por utilizar todas las tecnologías, colores, imágenes, gráficas, entre otros aditamentos que pueden y gustan de aplicar, logran al final generar interfaces complejas, pesadas y lentas. No obstante, la profesión no es el único punto clave que lleva a cometer equivocaciones que entorpecen el proceso de creación de

una interfaz efectiva. El error que la tecnología actual ha provocado se suscita al ignorar la existencia de los dispositivos móviles. En el caso de un desarrollo para ambiente web, no podemos estipular que no estamos trabajando para el ambiente móvil por lo que deben tomar en cuenta las consideraciones mínimas necesarias para que, en el caso de que alguno de los usuarios decida visitar el sitio desde su dispositivo, pueda hacerlo sin problemas. Un ejemplo de esto son los formularios y la alineación de sus etiquetas con respecto a los campos para introducir información. Si las etiquetas se colocan a la izquierda de cada campo, el usuario de un dispositivo móvil no podrá verlas. Esto sucede debido a que al seleccionar un campo en el dispositivo, el campo se agranda para ocupar la totalidad de la pantalla y así mejorar la visibilidad del usuario mientras escribe, anulando por completo la etiqueta que se encontraba a su izquierda. De este modo, al hacer uso del botón de siguiente campo jamás aparecerá en pantalla la siguiente etiqueta y el usuario tendrá que disminuir el porcentaje de acercamiento para poder leerla antes de completar la información. Si estas etiquetas son colocadas arriba de los campos de texto en lugar de a su izquierda, aparecerán visibles incluso para los usuarios de dispositivos móviles en todo momento. Se trata de una consideración sencilla, pero no todos la toman en cuenta.

Relevancia en términos de inversión

Tratando el tema desde el punto de vista de las consecuencias en ventas, una interfaz de usuario mal hecha puede perjudicar mucho a un negocio. Después de todo, si el usuario no logra encontrar el producto que está buscando, tarde o temprano decidirá buscar en otro lugar y esa venta se perderá. De igual modo, si el proceso de compra es poco comprensible o poco confiable, el usuario decidirá no completarlo. Una mala interfaz de usuario puede generar desconfianza al momento de una compra, con detalles tan sencillos como la falta de una pantalla de confirmación al terminar el proceso de pago. Si no confirmamos con claridad al usuario que su compra se ha terminado con éxito y simplemente lo redirigimos a la página de inicio de nuestro portal, la confusión generada puede afectar de manera negativa. Las interfaces de un portal de comercio electrónico conllevan de manera más explícita la importancia de un buen proceso de desarro36

.PRÁCTICAS

Usabilidad

“Lo más sencillo no equivale a lo más intuitivo.”

Conceptos e implicaciones

El generar una experiencia satisfactoria de uso de un producto se reduce a la aplicación correcta de un término que hoy en día va ganando terreno en el ambiente de términos tecnológicos: La usabilidad. La comprensión del concepto de usabilidad se basa en entender que no se trata de lo estético, si no de qué tanto es posible para un usuario el utilizar un determinado producto para cumplir una meta específica de manera efectiva, eficiente y satisfactoria dentro de un contexto previamente establecido. En palabras más sencillas, provistas por el afamado autor Jakob Nielsen, “la usabilidad es un atributo de calidad que determina qué tan sencillas son de utilizar las interfaces de usuario”. Esto se traduce en la combinación de dos aspectos muy importantes: las metas del negocio y las necesidades del usuario. Para que el negocio cumpla con lo que se propone al lanzar un determinado producto, el público meta debe utilizar ese producto. Sin embargo, para que las personas que conforman ese público meta utilicen el producto, este debe cumplir los requisitos que sus necesidades específicas les exigen.

En términos más directos: • Si algo es difícil de utilizar, no será utilizado. • Si una intranet es confusa, los empleados evitarán su uso en lo posible. • Si un sitio web de ventas es complejo, los productos que promueve no se venderán. • Si un sistema es complejo, sus funcionalidades no se aprovecharán en su totalidad.

• Facilidad de aprendizaje - El uso de una interfaz debe ser intuitivo, una persona de entre las que conforman su público meta debe ser capaz de entender su funcionamiento sin la necesidad de un manual. • Eficiencia - El flujo de acciones debe ser corto y veloz, no requiriendo muchas etapas o mucho tiempo por parte del usuario, mas sin embargo entregando los resultados esperados. • Sin requisición de memoria - El usuario no debe necesitar de su capacidad de memorización. A pesar de haber dejado de utilizar la aplicación por un tiempo, es importante que logre llevar a cabo las tareas que requiere sin mayor problema o consulta adicional. • Índice de error - La aplicación debe estar preparada para recuperarse en caso de errores, generar la menor cantidad posible de los mismos y ofrecer alternativas de corrección para el usuario en caso de que se presenten. • Experiencia satisfactoria - El usuario debe sentirse victorioso tras haber llevado a cabo una tarea con la ayuda de la aplicación, es decir, debe sentir la satisfacción de haber logrado la .BIO meta que se proponía. Pamela Rodríguez Domínguez En artículos posteriores se tratará el tema más a detalle, con las recomendaciones y los pasos a seguir en el proceso de crear interfaces efectivas para nuestras aplicaciones. 37

es egresada de la Universidad de Monterrey de la carrera de Ingeniería en Sistemas Computacionales con estudios avanzados en Diseño Web. Actualmente ocupa el puesto de Diseñadora de Interacción e Interfaces para una empresa de consultoría de experiencia del usuario y escribe para diversas fuentes en línea sobre el tema.

Software Guru

Concretamente y según los estudios realizados por Jakob Nielsen, una interfaz de usuario que sea usable debe ser una interfaz que cumpla con los siguientes factores:

www.sg.com.mx |

llo. Existen, sin embargo, otras aplicaciones que no resultan de tan obvia necesidad de cuidado. Un ejemplo de estos casos lo constituyen los desarrollos internos ya que a estos desarrollos tiende a dárseles menor importancia puesto que los productos terminados no van a ser recibidos ni juzgados por un cliente, si no que serán utilizados por personal de la empresa que puede ser capacitado para ello. Las interfaces resultan a veces tan complejas que estas capacitaciones no son suficientes. Si se considera la situación de que alguno de los empleados se vea en la necesidad de consultar un comunicado general en la intranet y no haya comprendido la interfaz en su totalidad, el tiempo que pierde en buscar dicho comunicado es tiempo de trabajo perdido. Por lo tanto, es tiempo por el que la empresa está pagando, y aunque se trata de una pérdida menos obvia, igual termina siendo una pérdida. Otro desarrollo interno al que no se le da la importancia requerida es el de los puntos de venta, de igual manera sobre estimando el alcance que tienen las sesiones de capacitación. Pero a pesar de la existencia de estas sesiones, el proceso de adaptación posterior de una interfaz demasiado compleja puede hacer que el empleado se desempeñe de manera muy lenta, acabando con la paciencia de los clientes esperando su turno por ser atendidos.

.PRÁCTICAS Gestión de

Procesos

TSP y CMMI

Integrando

lo mejor de los dos mundos

Introducción

El desarrollo de software es una actividad joven, comparada con otras ingenierías. En sus inicios, ésta disciplina se desarrolló con base en habilidades personales y con la firme creencia de que su naturaleza era artesanal. La falta de procesos, la indisciplina personal y la falta de visión para conceptualizar al desarrollo de software como una ingeniería se materializó en la crisis del software en los años 70 y desde entonces se han tomado acciones para cambiar las malas prácticas y considerar al desarrollo de software como una ingeniería. Se integraron prácticas universales de la administración de proyectos y se refinaron ciclos de vida. Adicionalmente, la IEEE creo la Certificación para Profesionistas de Desarrollo de Software (CSDP), liberó el libro del conocimiento de ingeniería de software (SWEBOK) y en conjunto con la ACM hicieron el diseño curricular de la carrera de Ingeniero de Software en el 2004. Desafortunadamente, los esfuerzos no han sido suficientes. En el reporte “Resumen del Caos 2009” del Grupo Standish se indica que tan solo el 32% de los proyectos evaluados fueron exitosos, es decir: fueron entregados en tiempo, en presupuesto y con la funcionalidad requerida. Otra línea de acción para aliviar el problema ha sido el promover la mejora de procesos de software en las organizaciones a través del estándar ISO 9000, el modelo TSP y el modelo CMMI. Este artículo describe cómo el TSP y el CMMI están apoyando a desarrollar software de manera más disciplinada.

Proceso para equipos de software (TSP) .BIO Oscar A. Mondragón Campos colabora en el SIECenter desde mayo del 2004 como consultor de modelos de calidad de software y es instructor certificado de Intro to CMMI DEV, profesional de PSP y coach de TSP por el SEI. Dr. Mondragón es un Profesional Certificado de Desarrollo de Software (CSDP) de la IEEE y miembro del comité central de CSDA/CSDP. Mondragón tiene un doctorado en Ingeniería en Computación y una maestría en Ciencias de la Computación en USA. También es ingeniero en Comunicaciones y Electrónica de ESIME-IPN en México. oscar.mondragon@itesm.mx

El TSP (Team Software Process) es una estrategia enfocada a procesos para ayudar a los equipos de software a mejorar su habilidad para producir software de alta calidad en los tiempos y costos comprometidos [1]. La mejora en el desempeño organizacional se logra mejorando el desempeño personal y posteriormente el del equipo asignado a un proyecto.

››Por Oscar A. Mondragón Campos

El TSP es un marco de trabajo de procesos diseñado específicamente para equipos de software. Para lograr los beneficios, TSP requiere que los miembros del equipo hayan sido entrenados en el Proceso Personal de Software (PSP, por sus siglas en inglés). El PSP es un marco de trabajo personal que ayuda a los ingenieros hacer su trabajo de desarrollo de software de manera disciplinada. El PSP incluye un conjunto de métodos, plantillas y procesos que ayudan a los ingenieros a planear, medir y administrar su trabajo. Cuando el PSP es usado en equipos de TSP, la meta es producir productos con cero defectos en el tiempo y costo planeado [2]. El PSP se desarrolló considerando los siguientes principios de calidad y planeación: • Cada ingeniero debe planear su trabajo con base en sus datos históricos personales. • Los ingenieros deben medir su trabajo y analizar los resultados para mejorar su desempeño. • Los ingenieros deben sentirse personalmente responsables de la calidad de sus productos buscando decididamente hacer trabajo de calidad. • Es más eficiente prevenir los defectos que encontrarlos y corregirlos. • La manera correcta es siempre la manera más rápida y económica de hacer el trabajo. La importancia del entrenamiento y el marco de trabajo personal del PSP es que provee a los ingenieros un proceso disciplinado, métricas de desempeño, habilidades de planeación y estimación y habilidades de administración de la calidad. El TSP es un proceso diseñado para equipos de software auto-dirigidos y de alto desempeño, ayudándolos a planear su trabajo, negociar compromisos con la gerencia, dar seguimiento cabal a sus compromisos y producir productos de calidad mientras mejoran su rendimiento. El marco de trabajo de TSP incluye roles, plantillas, procesos, guías, especificaciones y listas de chequeo. La Figura 1 muestra el marco de trabajo con algunos ejemplos de los elementos de proceso. El TSP tiene características propias que lo distinguen de otras metodologías. Por ejemplo: • Usa equipos auto-dirigidos con base en el estilo de administración de Peter Drucker (administración del conocimiento) junto con un coach que ayuda a desarrollar las habilidades de trabajo en equipo en los individuos. 38

.PRÁCTICAS

Gestión de Procesos

Figura 1. Elementos de proceso de TSP.

Figura 2. Características de PSP y TSP.

• Tiene procesos operacionales flexibles que permiten a los equipos adaptar los procesos, contando además con un marco de trabajo de métricas que soporta a su proceso e incluye técnicas para la administración de la calidad usando revisiones personales, inspecciones e índices de desempeño de la calidad. • Usa planes detallados con actividades no mayores a 10 hrs en periodos de 3-6 meses y establece juntas de cierre (postmortems) para finales de ciclo o de proyecto. • Utiliza lanzamientos de proyectos de 3.5 días para planear las actividades y para integrar a los miembros del equipo. • Cada miembro tienen asignado roles, metas y riesgos del proyecto. • Los calendarios del equipo son desglosados en calendarios personales que son ajustados con base en datos personales.

CMMI se enfoca en los procesos de la organización y considera como premisa que “la calidad de un sistema es fuertemente influenciada por la calidad de los procesos usados para adquirirlos, desarrollarlos y mantenerlos.”

Modelo de Capacidad y madurez integrado (CMMI®)

El Modelo de Capacidad y Madurez Integrado del SEI (CMMI) provee un camino para la mejora de procesos, el cual proporciona a las organizaciones con elementos esenciales para lograr procesos efectivos. El modelo puede ser usado en un proyecto o en una división dentro de la organización. CMMI [4] ayuda a integrar áreas funcionales, establecer objetivos de mejora y sus prioridades, guiar procesos de calidad e incrementar la eficiencia en el desarrollo y mantenimiento de productos y servicios.

La representación por etapas ya tiene predefinidas las áreas de proceso asignadas a cada nivel y es la representación más usada a nivel mundial. Las áreas de proceso indican características técnicas de un área de conocimiento en particular. Un proceso administrado incluye [4]: la inclusión de una política, planea sus actividades, les asigna recursos y responsables, capacita y desarrolla habilidades del personal que los ejecuta, administra los productos de trabajo que produce, considera a los involucrados relevantes, monitorea y controla los pasos del proceso, hace revisiones de adherencia a procesos y productos, y retroalimenta a la alta gerencia sobre el estatus del proceso. 39

Software Guru

El reporte del SEI “Process Maturity Profile” del año 2010, indica que 5499 organizaciones han sido evaluadas en el modelo de referencia CMMI en los continentes de Asia, Europa, África y América. El modelo CMMI tiene tres constelaciones: desarrollo, adquisiciones y servicios, las cuales son colecciones de componentes CMMI que incluyen un modelo de referencia, material de entrenamiento y materiales de evaluación relacionados a un área de interés en particular. CMMI tiene dos representaciones: continua y por etapas. Ambas representaciones incluyen 22 áreas de proceso y ayudan a las organizaciones a llevar procesos pobremente definidos a procesos controlados estadísticamente. La representación por etapas de CMMI incluye 5 niveles de madurez y cada uno de ellos tiene asignadas áreas de proceso. CMMI DEV provee guías para medir, monitorear y planear la construcción de productos. En la Figura 3 se muestran los niveles de madurez, su enfoque y las áreas de proceso asignadas (predeterminadas).

www.sg.com.mx |

La fortaleza de la técnica radica en la sinergia del equipo auto-dirigido comprometido con un calendario y un plan de calidad. La Figura 2 ilustra las principales características de ambas metodologías [3]. Las desventajas de estás metodologías están ligadas a sus fortalezas: El PSP se desarrolló para ayudar a los ingenieros de software hacer productos de calidad, sin embargo, se requiere de un cambio organizacional que no puede ser sustentado por los ingenieros (de abajo hacia arriba). Así mismo, los equipos de TSP fueron concebidos como entidades independientes careciendo de una infraestructura organizacional para la administración de las mejoras y el mantenimiento de los procesos. Una solución radica en implementar un grupo de mejora después de los pilotos de TSP para que los procesos estándares y la mejora de procesos fluyan de manera natural.

El modelo CMMI [4] ha ayudado a las organizaciones a: • Ligar explícitamente las actividades de administración e ingeniería con los objetivos de negocio. • A desarrollar funciones organizacionales adicionales que son críticas para sus productos y servicios. • Incorporar lecciones aprendidas en los proyectos a través de la mejora continua de sus procesos.

.PRÁCTICAS Gestión de

Procesos

Figura 3. Representación por etapas de CMMI.

Figura 4. Prácticas de CMMI consideradas por TSP.

El modelo CMMI es un conjunto de buenas prácticas para implementar procesos eficientes y efectivos que han sido probadas por la industria. Es importante entender que CMMI es un modelo de referencia, CMMI no es un conjunto de procesos. Lo importante de una implementación de CMMI es la interpretación del modelo a la realidad de la empresa ya que los nuevos procesos implementados deben de agregar valor y resolver los problemas operativos de la empresa. Un aspecto frecuentemente ignorado en las implementaciones del modelo es el reconocer que una implementación de procesos es en esencia un cambio organizacional. Para que la iniciativa de mejora sea exitosa, ésta se debe administrar como un proyecto de alta prioridad en la organización con recursos y presupuestos asignados desde su incepción. La metodología IDEAL del SEI puede ser usada para la administración de la mejora de procesos, la cual debe ser considerada como una actividad continua. Los costos asociados a una implementación del CMMI son altos porque se deben desarrollar nuevos procesos, plantillas, material de entrenamiento y herramientas. La larga duración de la implementación de procesos dificulta presentar reportes tempranos de retorno de inversión, principalmente en el nivel 2 de madurez. La falta de patrocinio, recursos, habilidades técnicas y asignación apropiada de responsabilidades puede terminar en falsos inicios de mejora. Con respecto al desempeño de los procesos implementados con CMMI, depende de lo siguiente: • El tipo de implementación realizada. • Experiencia de la gente involucrada. • Enfoque hacia obtener el nivel vs. mejorar la operación. • Magnitud de recursos y tiempos asignados. • La cultura de calidad de la empresa al inicio del proyecto.

to que es utilizada por equipos auto-dirigidos. Mientras CMMI considera aspectos e infraestructura organizacional, TSP se enfoca en desarrollar disciplina de procesos y una cultura de calidad a nivel personal (a través de PSP) así mismo construye equipos de alto desempeño. Una de las fortalezas de TSP, es la calidad de los productos desarrollados: El promedió de errores reportado después de la entrega del producto es de 0.06 por cada mil líneas de código (KLOC) nuevas o modificadas mientras que el promedio de empresas CMMI N5 es 1.05 [04].

Integrando TSP y CMMI

TSP y CMMI son dos tecnologías del SEI enfocadas a la mejora de procesos de las organizaciones. Ambas comparten las mismas metas: ayudar a las empresas a desarrollar productos de calidad en los tiempos y presupuestos asignados. Por un lado, CMMI es un modelo de referencia y por otro lado, TSP es una implementación de procesos de alto rendimien-

El CMMI es un cómo, mientras el TSP es un producto con elementos de procesos, materiales de entrenamiento y un marco de trabajo para métricas, planeación y calidad. Las debilidades de TSP se pueden resolver con el enfoque organizacional de CMMI. El riesgo de implementar procesos burocráticos que no aportan valor agregado a la empresa se mitiga usando TSP. En lugar de seguir considerando estas tecnologías como rivales e independientes, las tecnologías se deben combinar tomando ventaja de la sinergia que se produce [5]. La idea principal de combinar TSP y CMMI es reducir el tiempo para alcanzar CMMI nivel 3 (de 4 años a 18 meses) obteniendo la institucionalización de procesos definidos que son usados en equipos auto-dirigidos comprometidos con los planes, con un fuerte enfoque personal en la calidad, con ciclos de prueba cortos, teniendo alto desempeño, y haciendo uso de una infraestructura para administrar la mejora continua [5]. La idea de combinarlos es apoyada por el nivel de cobertura que brinda TSP sobre CMMI. La Figura 4 muestra los resultados de un mapeo de TSP con CMMI indicando el porcentaje de prácticas especificas de CMMI con el que cubre TSP: 85% para el nivel 2; 78% para el nivel 3; 54% para el nivel 4 y 25% para el nivel 5 [04]. El estudio también comenta que el 80% de las prácticas especificas de CMMI nivel 2 y 3 son implementadas por TSP. Uno de los promotores de combinar TSP y CMMI fue la Secretaria de Economía Mexicana en el 2008, a través de su programa PROSOFT 40

.PRÁCTICAS

Gestión de Procesos

En noviembre del 2009, la empresa SILAC en Zacatecas, México, iniciaron un piloto del TSP-CMMI Accelerated Improvement Method (TC AIM). La empresa había implementado TSP en algunos proyectos [5]. La primera actividad realizada fue crear el Grupo de Ingeniería de Procesos (EPG) para administrar las actividades de Mejora de Procesos de Software (SPI) a nivel organizacional. El EPG fue lanzado como equipo TSP para que las actividades de SPI fueran administradas con el mismo rigor y disciplina de un proyecto TSP, ver Figura 5. El TSPm es una versión de TSP para administrar proyectos con múltiples equipos, ver Figura 6. Los nuevos roles de TSPm definen responsabilidades para: • Crear y administrar el Conjunto Estándar de Procesos Organizacionales (OSSP, por sus siglas en inglés). • Establecer un canal para reportar y/o escalar los asuntos de no conformidad a procesos. • Establecer y mantener el entrenamiento organizacional. • Dar seguimiento a las actividades del coach. • Establecer y mantener los procesos definidos del proyecto.

Conclusiones

TSP y CMMI son estrategias complementarias que combinadas proveen una poderosa sinergia, porque a nivel personal se establece una forma de trabajo disciplinada enfocada a la calidad y con un marco de trabajo para métricas y estimaciones. A nivel equipo, se establecen equipos de desarrollo de software auto-dirigidos que se comprometen a planes de trabajo balanceados y alcanzables y que le dan seguimiento a planes agresivos de calidad. A nivel organizacional, se genera la infraestructura para administrar la mejora continua, se establece una librería con procesos estándares, y se construyen las bases para la institucionalización de procesos definidos. Combinar TSP y CMMI, sin embargo, no es una tarea fácil. Cuando un profesional de una de estas estrategias trata de asimilar la otra, podría confundirse y malinterpretar los conceptos y filosofías. Además, es muy importante tener asesoría objetiva y calificada durante la implementación porque éstos marcos de referencia han sido erróneamente percibidos como opuestos. Independientemente del riesgo arriba mencionado, vale la pena combinar TSP y CMMI para aplicar procesos de alto desempeño en equipos auto-dirigidos, que son administrados y mejorados organizacionalmente y que permiten entregar productos de alta calidad en los tiempos y costos estipulados. La versión completa de este artículo se escribió para el V Taller de Calidad en las Tecnologías de la Información y las Comunicaciones, Cuba, 2011.

Referencias:

El TSPm también incluye nuevos elementos de procesos para cubrir más prácticas de CMMI de la administración de procesos y riesgos, aseguramiento de calidad, análisis de decisión y administración de la configuración. Durante el Workshop anual de TSP en septiembre 2010, se anunció la liberación del Método Acelerado de Mejora (AIM). El SEI liberó en octubre 2010 el TSP+ a sus partners con coach TSP certificado. El TSP+ es la nueva versión del TSPm descrito en este artículo. El TSP+ es la versión de TSP usada en el AIM.

[1] Watts, H., TSP: Coaching Development Teams. Reading, MA: Addison-Wesley, 2006, ISBN: 0201731134. Disponible en: http://www.sei.cmu.edu/library/abstracts/books/201731134.cfm [2] Watts, H., PSP: A Self-Improvement Process for Software Engineers. Reading, MA: Addison-Wesley, 2005, p. 85-108, 133-162. ISBN: 0321305493. Disponible en: http://www. sei.cmu.edu/ library/abstracts/books/0321305493.cfm [3] Davis, N. and Mullaney, J., The Team Software Process (TSP) in Practice: A Summary of Recent Results. (CMU/SEI-2003-TR-014), Pittsburgh, PA: Carnegie Mellon Software Engineering Institute. 2003. Disponible en: http://www.sei.cmu.edu/reports/ 03tr014.pdf. [4] CMMI Product Team, “CMMI for Development, version 1.2” (Tech. Rep. No. CMU/SEI2006-TR-008). Pittsburgh, PA: Carnegie Mellon University. 2006, Disponible en: http:// www.sei.cmu.edu/pub/documents/06.reports/pdf/06tr008.pdf [5] Mondragón, O., and Fernández, E., “AIM Case Study: Moving from TSP to CMMI ML3”. Proceedings of the 5th Annual Software Engineering Institute Team Software Process. Sept. 2010. pp 39-44.

Software Guru

(Programa del Desarrollo del Sector de Servicios de Tecnologías de Información) quien reconoce la fortaleza de ambos modelos y le pide al SEI que desarrolle una versión extendida del TSP que cumpla con la mayoría de prácticas de CMMI nivel 3. El SEI extendió el TSP para poder cubrir con algunas de las prácticas específicas de CMM nivel 3 que no habían sido consideradas en TSP. A la versión extendida se le llamó 2008.09.TSPm.

Figura 6. Componentes de TSPm.

www.sg.com.mx |

Figura 5. Integrando TSP y CMMI.

.PRÁCTICAS Arquitectura

Evaluación de la

Arquitectura de Software

entendiendo y cuestionando el diseño arquitectónico

lo largo de las últimas entregas de ésta serie de artículos, nos hemos enfocado en tres categorías de actividades relacionadas con el desarrollo de la arquitectura de software y que (idealmente) ocurren como parte del desarrollo de cualquier sistema de software. Estas categorías de actividades han cubierto aspectos de requerimientos que influyen en el diseño arquitectónico (los drivers arquitecturales), el diseño de la arquitectura en si mismo y la documentación del diseño a través de diversas vistas. El cuidar estos aspectos como parte del desarrollo es una tarea clave que aumenta las probabilidades de tener un sistema de calidad que satisfaga requerimientos que influyen a la arquitectura. La arquitectura es, sin embargo, un aspecto tan importante dentro del desarrollo que es conveniente realizar actividades de verificación de la misma de forma temprana, con el fin de identificar problemas que podría resultar muy costoso eliminar posteriormente. La evaluación de la arquitectura de software permite justamente realizar la verificación del diseño y es la cuarta categoría de actividades que, junto con las tres categorías mencionadas previamente, cubren el conjunto de aspectos relacionados con el desarrollo de arquitectura de software.

Conceptos

Recordemos que los atributos de calidad son aquellas características medibles, tales como el desempeño o disponibilidad, que permiten expresar la calidad del sistema de un punto de vista del cliente y de la organización de desarrollo. Como se vio en columnas anteriores, un buen diseño arquitectónico es clave para poder satisfacer este tipo de requerimientos. Imaginemos, por ejemplo, que se tienen escenarios de atributos de calidad de desempeño y escalabilidad como los siguientes: • DES-1: Un usuario arranca de forma manual el proceso de validación de facturas. El sistema realiza el proceso sobre 2’000’000 de facturas en un tiempo no mayor a 8 horas. • MOD-1: Un ingeniero agrega un componente para soportar un nuevo protocolo de comunicación al sistema en tiempo de desarrollo. El componente es agregado de forma exitosa sin que esto requiera de modificar ningún componente previo del sistema. Al terminar de realizar el diseño de una arquitectura, quisiéramos estar seguros que el diseño arquitectural propuesto satisface realmente requeri.BIO mientos como los anteriores. El riesgo El Dr. Humberto Cervantes es profesor-investigador en la UAM-Izde no tener seguridad al respecto de tapalapa. Ha realizado investigación en temas relacionados con arquitecello de forma temprana en el desarrollo tura de software desde el año 2000 y en años recientes se ha enfocado puede tener consecuencias muy serias en el estudio y la aplicación de en etapas posteriores del desarrollo y métodos que apoyen al desarrollo de arquitectura de software dentro muy particularmente, si se descubren de la industria Mexicana. Obtuvo la certificación Software Architecture problemas relacionados con la arquiProfessional por parte del SEI. tectura en etapas tardías tales como la www.humbertocervantes.net implantación del sistema.

››Por Dr. Humberto Cervantes

La evaluación de la arquitectura de software es una herramienta que ayuda a mitigar riesgos como el descrito anteriormente. Para lograrlo, la evaluación busca esencialmente responder a la pregunta siguiente: ¿El diseño de la arquitectura satisface a los requerimientos que influyen a la arquitectura y, principalmente, a los atributos de calidad?

Técnicas de evaluación

Existen diversas técnicas de evaluación de arquitectura de software, que se describen a continuación:

Checklists y cuestionarios

El uso de checklists (listas de verificación) y cuestionarios para realizar revisiones e inspecciones del diseño que se ha producido. Realizarlos de forma efectiva, no es una tarea trivial. Checklists y cuestionarios deben enfocarse sobre cuestiones de fondo del diseño más que de la forma. Algunos ejemplos de preguntas y comentarios al respecto, se muestran a continuación: • ¿Todos los campos de la plantilla de vista han sido llenados? Esta pregunta es necesaria, pero se enfoca sobre la forma. • ¿Se ha definido un mecanismo de manejo de excepciones adecuado? Esta pregunta se enfoca en cuestiones de diseño, la dificultad reside en definir lo que se entiende como un mecanismo “adecuado”. • ¿Se han documentado decisiones de diseño relativas a todos los drivers arquitecturales? Es una pregunta útil, aunque una respuesta positiva no permite saber si las decisiones de diseño son adecuadas. Es complicado realizar checklists y cuestionarios genéricos que cubran todo tipo de sistemas, por ello, es conveniente enfocarlos a dominios específicos que requieran diseños arquitectónicos similares. La evaluación de arquitecturas por medio de checklists y cuestionarios deben mantenerse resguardados y controlados.

Evaluación basada en escenarios

Las evaluaciones basadas en escenarios son una técnica más efectiva que la anterior, sin embargo, se trata también de una técnica más costosa y más compleja de implantar. La evaluación basada en escenarios, toma como entrada escenarios que pueden ser de atributos de calidad (como los descritos arriba) o bien funcionales (por ejemplo, el flujo principal de algún caso de uso). Los escenarios son usados por un equipo de evaluación para cuestionar al arquitecto sobre las decisiones de diseño que tomó y el arquitecto debe ser capaz de argumentar de manera convincente que el diseño planteado satisface o no los escenarios sobre los cuales se le está cuestionando. Una evaluación basada en escenarios requiere de poder conformar un comité de evaluación. Generalmente, este comité de evaluación debe estar compuesto por gente suficientemente experimentada como para poder entender y cuestionar el diseño arquitectónico, este 42

.PRÁCTICAS

Arquitectura

[Paquete de evaluacion]

Preparar evaluación

Junta de evaluación

Presentar contexto y reqs.

[ siguiente escenario ]

Seguimiento

Evaluar escenario

Presentar escenario

[ fin de evaluación ]

Generar reporte

Atender observaciones

Figura 1. Proceso genérico de evaluación basada en escenarios.

tipo de gente generalmente son ingenieros de software experimentados o bien arquitectos de software. Un proceso genérico de evaluación basada en escenarios se muestra en la figura 1. Como se puede observar, existen tres fases distintas asociadas con la evaluación. Durante la fase de preparación, se solicita la evaluación y se envía un paquete de evaluación al comité. El paquete de evaluación generalmente debe incluir información general del sistema, detalle de los requerimientos que influyen en la arquitectura y la documentación de la misma a través de distintas vistas. El comité prepara la evaluación, incluyendo aspectos logísticos de la misma y define la fecha en que se llevará a cabo. En la fecha definida, se reúne el arquitecto junto con el comité de evaluación (y posiblemente algunos otros involucrados). La junta de evaluación comienza con una presentación del contexto del sistema, un repaso de los requerimientos que influyeron en el diseño de la arquitectura y una presentación general de la misma (por ejemplo usando la vista de implantación y otros modelos de alto nivel). Enseguida comienza la evaluación en sí. Se elige algún escenario que se desea evaluar y el arquitecto comienza a realizar la presentación del mismo. Al tiempo que el arquitecto presenta el escenario, el comité de evaluación debe tratar de identificar riesgos y problemas con el diseño que se presenta. Los riesgos pueden incluir decisiones de diseño que no se han tomado en cuenta, por ejemplo: • Las interfaces entre los componentes no han sido especificadas de forma completa. • No existen diagramas que permitan comprender la manera en que se lleva a cabo el escenario DES-1. Los problemas pueden incluir decisiones de diseño claramente erróneas o bien que no han sido tomadas, como por ejemplo: La introducción de un nuevo componente para el escenario MOD-1 requiere de modificar componentes existentes.

Es importante señalar que con frecuencia es muy complicado poder tener seguridad que un diseño puramente conceptual satisface, con seguridad, los drivers arquitecturales. Esto es particularmente relevante respecto a los atributos de calidad asociados con cuestiones en tiempo de ejecución (desempeño). Por ello, es muy conveniente que, en esos casos, el arquitecto sustente sus decisiones de diseño no sólo con diagramas sino con resultados de la ejecución de prototipos que se hayan realizado justamente con el objetivo de mitigar riesgos técnicos. Una vez que se ha terminado de evaluar un escenario, se continua con un escenario distinto hasta que se han cubierto los distintos escenarios, o bien ha terminado el tiempo de la junta. Como resultado de esta junta de evaluación, el comité debe reportar sus observaciones con el fin de que puedan ser atendidas por el arquitecto. La última fase es de seguimiento, en ella el arquitecto atiende las observaciones levantadas durante la evaluación. La evaluación basada en escenarios presenta diversas ventajas: • Es relativamente simple de realizar. • El beneficio es alto relativo al costo, sobre todo si se realiza en etapas tempranas del desarrollo. • Permite identificar problemas asociados con requerimientos (por ejemplo, si los atributos de calidad no están cuantificados). • Permite a diversos involucrados conocer la arquitectura. • Permite transferir conocimientos arquitectónicos en la organización. La desventaja principal de este tipo de evaluación es la dificultad de formar comités de evaluación efectivos, sobre todo si la organización es pequeña. Existen diversas técnicas específicas de evaluación de arquitecturas, de las cuales la más conocida es probablemente el ATAM (Architecture Tradeoff Analysis Method) del SEI [1]. ATAM tiene la particularidad de que puede realizarse sobre sistemas en los cuáles no se documentaron los atributos de calidad de forma inicial. Diversos métodos de evaluación son comparados en [2].

Otras técnicas

Otras técnicas de evaluación incluyen la generación de simulaciones, experimentos y análisis específicos. Estas técnicas son apropiadas para cierto tipo de sistemas como por ejemplo los sistemas de tiempo real. Dependiendo la criticidad del sistema, es conveniente combinar varias de las técnicas de evaluación con el fin de tener mayor seguridad sobre la pertinencia de la evaluación.

Para terminar

La arquitectura de software es un artefacto fundamental dentro del desarrollo de sistemas de calidad. El no cuidar aspectos relacionados con el desarrollo de la arquitectura puede resultar en sistemas que no cubren las expectativas de los clientes y de la organización de desarrollo; la evaluación del diseño de la arquitectura es, por lo tanto, una actividad fundamental dentro de las actividades de desarrollo. El alto costo que tienen los defectos relacionados con la arquitectura en etapas tardías de desarrollo justifica plenamente que se invierta en la realización de esta práctica como parte del desarrollo. Por último, vale la pena señalar que la evaluación de la arquitectura pone a prueba las habilidades “suaves” (soft skills) de los arquitectos, quienes deben ser capaces de hacer presentaciones efectivas de su diseño, tanto a nivel escrito como a nivel oral o bien de cuestionar diseños de otros arquitectos de forma pertinente. Referencias: [1] Clements, P., Kazman, R., Klein, M, “Evaluating Software Architectures, Methods and Case Studies”, Addison Wesley, 2002 [2] Dobrica, L., Niemelä, E., “A Survey on Software Architecture Analysis Methods”, IEEE Transactions on Software Engineering, Vol. 28, No. 7, Julio 2002

Software Guru

Solicitar evaluación

Comité de evaluación

www.sg.com.mx |

Preparación

Arquitecto

.PRÁCTICAS Agilidad

Apropiación de Lean-Agile y

Kanban

para el desarrollo de tecnologías y contenidos de la educación en línea

››Por Jorge Polo Contreras, Norma Edith Hernández, Luis Alonso Nava

na de las tareas del Centro de Alta Tecnología de Educación a Distancia de la UNAM en Tlaxcala, es desarrollar herramientas, plataformas y contenidos educativos así como la formación de recursos humanos en el desarrollo de tecnologías para la formación en línea. A través del Laboratorio de Investigación e Innovación Colaborativa en Tecnología Educativa (LIICTÉ) y con base en una metodología interdisciplinaria, perfiles técnicos y pedagógicos planean, diseñan, desarrollan y evalúan proyectos para el desarrollo de tecnologías y contenidos educativos. La adopción de principios y prácticas Lean-Agile y la adaptación de la metodología Kanban para la realización de su trabajo, ha permitido optimizar tareas y mejorar el nivel de desempeño de los mismos equipos, así como la generación de productos y servicios de calidad.

Introducción

El propósito de este artículo es explicar cómo tras el análisis del marco teórico de principios y prácticas Lean-Agile junto con la metodología Kanban, se adoptaron estos principios y metodologías para el desarrollo de proyectos que realiza el CATED en el LIICTÉ y las adaptaciones requeridas para su mejor funcionamiento y aceptación por parte de los equipos de trabajo. De igual manera se trabajó conjuntamente con el Área de Proyectos Educativos Especiales del mismo CATED para unificar criterios. Cada jefatura de departamento ha trabajado en la adaptación de Kanban a la naturaleza específica de su área.

Metodología interdisciplinaria para el desarrollo de materiales educativos

Los equipos de trabajo están conformados por los siguientes perfiles: • Líder de proyecto: experto en el diseño y gestión de proyectos educativos asistidos por tecnología. • Experto en contenidos: experto en el área de conocimiento o campo sobre el cual se trabajan los contenidos o desarrollan los sistemas. .BIO • Diseñador instruccional: experto M.C. Jorge Polo Contreras Paredez, CATED-CUAED-UNAM / en pedagogía. Jefe del Departamento de Desarrollo Tecnológico • Diseñador gráfico: experto en comunicación visual. M.C. Norma Edith Hernández Galaviz, CATED-CUAED-UNAM / • Integrador de tecnologías: proJefa del Departamento de Desarrollo Educativo gramador y administrador de tecnologías Web. M.C. Luis Alonso Nava Fernández, CATED-CUAED-UNAM / Estos equipos diseñan y desarrollan Subdirector de Docencia y Educación Contínua tres diferentes tipos de proyectos: • Desarrollo de aplicaciones: impli-

ca el análisis, diseño y desarrollo de Software Web educativo. • Formación: involucra a expertos en contenidos con el equipo interdisciplinario para el análisis, diseño y desarrollo de programas educativos para la modalidad en línea, por ejemplo, cursos de educación continua, diplomados, licenciaturas, etc. • Soporte: comprende la gestión de programas en línea, usuarios, aplicaciones, herramientas y plataformas, así como el seguimiento y apoyo a los usuarios finales de los sistemas. A primera vista no parece complicado el funcionamiento del sistema, sin embargo, un detalle especial, es que en cualquiera de sus fases, intervienen de manera no controlada diferentes perfiles que realizan procesos difícilmente sistematizables por considerarse aspectos creativos o artesanales. Además, se atienden simultáneamente varios proyectos de diferente tipo, lo que en ocasiones produce confusión en el establecimiento de prioridades.

Adopción de Lean-Agile

Los principios básicos de Lean-Agile: restricción, valor, calidad e innovación, fueron conceptos clave para entender el cambio que requería la adopción de éstas prácticas. Sin embargo, cuando se empezaron a poner en práctica los conceptos -analizar los procesos, flujos de trabajo, historias de usuario, tareas, esfuerzo (o trabajo) con valor para el cliente, etc.- se vertieron diferentes puntos de vista, sobre lo que “debería ser” y lo que “realmente es”, y decidir el punto de partida para el desarrollo de los proyectos. Pese a esta diversidad de percepciones sobre el propio trabajo y la forma de organizarlo, lo que favoreció la adopción de Lean-Agile fue: • La actitud de los equipos de trabajo: comunicación y colaboración • La disponibilidad al cambio: pensar diferente las tareas a realizar (atender a los requerimientos del cliente) • El involucramiento de los líderes de equipos de trabajo y a diferentes niveles organizacionales para permitir la autogestión • El reconocimiento de los elementos de valor (tangibles e intangibles) para el cliente: innovación de valor. Estas actitudes permitieron generar una nueva visión del CATED, reconociendo sus fortalezas y debilidades, tanto institucionales como de las personas involucradas, asumiendo el compromiso de trabajar sobre aspectos personales que repercuten en el desarrollo de los proyectos e identificando las áreas de oportunidad para tener un ambiente laboral que: 44

.PRÁCTICAS Agilidad

››El consenso sobre los procedimientos y técnicas de la metodología Kanban

fue un gran reto para los líderes de los equipos de trabajo.

El consenso sobre los procedimientos y técnicas de la metodología Kanban fue un gran reto para los líderes de los equipos de trabajo. A continuación, se explican los aspectos que inicialmente dificultaron la adopción de la metodología Kanban y como se llegó a una solución, inclusive realizando adaptaciones a la misma metodología. Establecimiento de las etapas generales por las cuales transita cualquier proyecto (o un tipo de proyecto) para especificar las columnas del Tablero Kanban. Cuando se trabajó en la elaboración del Diagrama de Flujo de Valor (DFV), se hizo obvio que debía ser el mismo proceso para el desarrollo de todos los proyectos, lo cual complicó la elaboración de flujo de tareas en el tablero Kanban, ya que se pasaron por alto varios puntos medulares para su establecimiento: • Generalmente, cada proyecto debe tener su tablero. • No hay un tablero perfecto al inicio del proyecto, éste se va perfeccionando. • La configuración del tablero debe permitir ser adaptativos a lo largo del desarrollo del proyecto. Los procedimientos en el proceso de desarrollo de cualquiera de los proyectos del CATED, no son siempre los mismos y difícilmente se puede tener control de tiempos, recursos y de la participación de los expertos en contenido en la mayoría de las fases de desarrollo. Por ello, resultaba casi imposible hacer fluir las tareas en el tablero inicial, especificado de manera general, es decir, no se definió para un tipo de proyecto en particular, por lo que se decidió crear un nuevo DFV particularizado a un tipo de proyecto que reflejara los procedimientos en cada una de las fases, de tal manera que los perfiles involucrados reconocieran de inmediato su participación en alguna de las columnas (fases) del tablero. Definición de las historias de usuario y tareas. La ambigüedad respecto a la enunciación de tareas en relación al clien-

Especificación de las Tarea/Trabajo en Proceso (TEP). En un principio no fue fácil especificar el TEP en cada una de las columnas (fases del proyecto), debido principalmente a que no se encontraron fuentes documentales que aclararan el nivel de especificidad apropiado para las tarjetas en el tablero con respecto al TEP, ya sea, por historias de usuario (no épicas por supuesto) o por tareas. Cuando se decidió especificar tareas en lugar de historias, entonces se ocupó una fórmula para asignar los TEP iniciales, resultado de multiplicar 1.5 por el número de personas involucradas en la fase correspondiente (siguiendo las recomendaciones de Kniberg y Skarin, 2010), considerando que los TEP pueden irse ajustando a lo largo del proyecto y adaptando a las circunstancias propias del desarrollo, como el surgimiento de imprevistos, el no tener información completa y la atención de requerimientos urgentes. Definición de las clases de servicio. Una vez que los tableros tenían especificadas las columnas de manera que cualquiera podía identificar su trabajo en una o más de ellas, que en las tarjetas se podía leer claramente su valor y se entendía el trabajo que implicaba, y especificados los TEP para iniciar el proyecto, el siguiente paso fue clasificar las tarjetas por clases de servicio: 1. Se identificaron diversos criterios que determinarían la prioridad de las tareas y los tipos de servicio: • Fecha de entrega • Características del proyecto / cliente • Complejidad de la tarea • Seriación de las tareas 45

Software Guru

Apropiación de Kanban

te reside en que, cada integrante del equipo es cliente de los otros pues los requerimientos se hacen de manera multidireccional entre ellos. Además, los clientes o usuarios finales de los contenidos educativos desarrollados son, generalmente: docentes, alumnos, coordinadores académicos y administradores escolares de un programa educativo. Al generar historias de usuario con base en las necesidades de estos usuarios, podemos encontrar aspectos generales, (usabilidad y accesibilidad) o específicos (ver un aviso o calificar una actividad). Ahora bien, dependiendo la fase del proyecto, para algunos miembros del equipo las historias de usuario más específicas implican la realización de muy pocas tareas, mientras que para otros involucran el desarrollo de muchas. En consecuencia, se decidió elaborar tableros con base en tareas, ya que de ese modo fue más fácil identificar a los perfiles dentro del proceso que intervienen en cada una de las fases del tablero.

www.sg.com.mx |

• Incremente la productividad • Agilice los procesos • Dé seguimiento puntual • Responda con facilidad a los cambios • Innove los procesos, productos y servicios • Asegure la calidad

.PRÁCTICAS Agilidad

También se identificaron tres estados para cualquiera de las tarjetas: • Bloqueado • En corrección • Cancelado

• Establecer tableros generales para abarcar diferentes tipos de proyectos basados en historias de usuario (tableros verticales, leídos de abajo hacia arriba respecto de los estados). • Establecer tableros específicos con base en tareas a partir de las historias de usuario (tableros horizontales, leídos de izquierda a derecha respecto de las fases). • Definir una dinámica de seguimiento a un nuevo requerimiento o historia de usuario en el tablero general para su desglose en los tableros específicos. • Con base en las características del proyecto, se establecen sus fases en el tablero.

Además se establecieron tres estados para los tableros generales (que identifican todos los proyectos) : • Pendiente • En proceso • Concluido

Especificación de las TEP en el tablero: • Se toman como base para el cálculo las tareas a desarrollar por cada perfil de los equipos • Inicialmente, se calcula con base en el número de integrantes o perfiles que intervienen en la fase o etapa y se multiplica por 1.5.

Especificación de las políticas para operar la metodología Kanban. Otro aspecto importante es la especificación de políticas al inicio de cada proyecto. En principio, las políticas simplemente se explicitaron de acuerdo a la metodología de trabajo que se sigue para cada proyecto y atendiendo a la normatividad institucional para la generación de productos y servicios, sin embargo, es importante tener ejercicios de retroalimentación que aclaren el seguimiento de políticas, o bien, la necesidad de cambio de éstas para un mejor flujo de trabajo.

Información incluida en los tableros: • En el tablero general se debe incluir el tipo de proyecto, las clases de servicio y los involucrados en cada proyecto, desglosando el tipo de responsabilidad asignada a cada participante dentro de cada proyecto.

2. A cada tarjeta se le asignó una etiqueta de color para identificar visualmente su jerarquía. Para cada tablero, dependiendo el tipo de proyecto, se implementaron diferentes clases de servicio, como son: • Tareas normales • Tareas con fecha de entrega • Tareas de soporte/servicio

Dentro de las políticas generales se identifican las siguientes: • Las fases de cada de proyecto son definidas entre todos los involucrados. • Respetar el orden jerárquico y secuencial de las tareas, al actualizar el tablero. • Asegurar los criterios de movilidad de personal en cada una de las fases del proyecto. • Establecer medidas de aseguramiento de la responsabilidad de cada uno de los involucrados en el proyecto. • Asegurar la consistencia de cada uno de los tableros específicos en relación a tableros generales de control.

Adaptaciones a la metodología Kanban

Durante el proceso de apropiación de la metodología Kanban, se realizaron adaptaciones que consistieron principalmente en los siguientes aspectos: Elaboración de Tableros de Kanban:

Información incluida en las tarjetas: • Nombre de los perfiles involucrados en la tarea para tener claro el número de recursos necesarios en el desarrollo de esas actividades. • Fechas de entrada y salida en el tablero general (cambio de estado) y fecha de entrada y salida en el tablero específico (tránsito entre fases). Otra adaptación de la metodología, en relación a la forma de trabajo, fue la elaboración de un tipo de tablero Kanban vertical que se usa para visualizar todos los tipos de servicio de soporte y al mismo tiempo cuántos se están realizando. En la primera columna, en lugar del backlog, están los nombres de los tipos de servicio de soporte (cada uno con su límite de TEP) y las siguientes tres columnas muestran las fases de atención: solicitud aceptada, en proceso y terminado.

Conclusiones

En definitiva, antes de trabajar con Lean-Agile y Kanban no se podía calcular por anticipado la cantidad de transiciones que los grupos de trabajo tenían que realizar a diario, dados los traslapes entre proyectos, servicios de soporte y análisis de nuevos requerimientos, 46

››Otra

adaptación de la metodología, en relación a la forma de trabajo, fue la elaboración de un tipo de tablero Kanban vertical. ahora es posible reducir la cantidad de transiciones en una semana lo que significa una disminución de re-trabajo significativo. Una beneficio importante es la alta visualización de todas las etapas y/o procesos en los que consiste un proyecto de educación a distancia y el desglose de las tareas, así como la posibilidad de ir analizando en cualquier momento la situación real del proyecto a través de los tableros, de los diagramas de flujo acumulado y de los diagramas de control. Ahora se cuenta con documentación ligera sobre el desarrollo de los proyectos, misma que agiliza tanto la incorporación de personal cuando se requiera, como la aceptación de cambios funcionales en cualquier momento. En particular, Lean-Agile y Kanban ha proporcionado elementos suficientes para establecer un proceso de mejora continua, el cual dista mucho de ser trivial, principalmente, por la naturaleza multidisciplinaria de los procesos de producción de la educación a distancia. No obstante los beneficios reportados, aún faltan aspectos por mejorar y aplicar, en la transición del proceso de apropiación al establecimiento de una planeación ágil para los nuevos proyectos. El reto de homogenizar el conocimiento que significó el entrenamiento para la apropiación de las metodologías Lean-Agile y Kanban, ha valido la pena tanto en el ámbito profesional como en el personal, pues la parte filosófica de trabajo ha logrado cambiar actitudes y motivaciones en todos los niveles jerárquicos del CATED.

.COLUMNA Programar es un Estilo de Vida

Identidad y Reputación en línea

esquemas de confianza

“Querido amigo: Soy la señora Mariam Abacha1, viuda del finado General Sani Abacha, ex-jefe de gobierno de Nigeria. (…) Para salvar a mi familia de una total bancarrota, estoy buscando transferir el total de US$24,000,000 a través de una institución bancaria confiable. (…) Como pago por su ayuda, le ofrezco el 30% de lo que podamos rescatar de la fortuna de mi querido esposo.”

l tema conducente del presente ejemplar de SG, Pagos en línea, cruza necesariamente por el tema de los esquemas de establecimiento de reputación en línea. Cada vez menos gente asume confiable cualquier dato que encuentra en Internet sencillamente por estar ahí. Un logro del que puede enorgullecerse la comunidad de expertos que apuntan a la necesidad de concientización en nuestro quehacer en red es que la generalidad de los usuarios, por lo menos, ya desconfía cuando le piden datos para tener acceso a su dinero. Sin embargo, ¿qué es lo que nos lleva a confiar en determinados proveedores? El problema de establecer la reputación de un tercero puede presentarse como un muy interesante ejercicio académico, con anclas en muy diversas áreas del conocimiento, desde las ciencias sociales hasta las matemáticas. En un plano mucho más aplicado, todo el problema de la reputación puede resumirse en las preguntas, ¿Puedo confiar en que la contraparte es quien dice ser? y ¿Puedo confiar en que dice la verdad? Enfocándonos a las aplicaciones actuales, podemos principalmente traducir estas preguntas en:

Confianza en la identidad

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

Seguramente habrán recibido alguna vez un correo similar a aquel cuyas primeras líneas reproduje. Afortunadamente, es poca la gente que cae en estos esquemas2. Lo primero que debe venir a nuestra mente es, ¿estoy realmente intercambiando correo con la Sra. Abacha? Hemos aprendido a desconfiar de la identidad de los extraños. Y cuando un extraño nos propone una transacción económica, nuestra primera reacción es desconfiar. Cuando efectuamos transacciones a través del navegador, nos hemos acostumbrado a buscar indicaciones de que estemos hablando con un servidor seguro. ¿Qué es esto? ¿Cómo lo valida el navegador? Más allá de aplicar el sentido común, hay dos esquemas principales que nos permiten confiar la identidad

de una entidad –individuo o empresa– con la que podamos tener un intercambio que incluya información confidencial (que requiera mantenerse a resguardo de terceros, como el número de nuestra tarjeta de crédito) o no-repudiable (que nos interese tener un comprobante de haber realizado determinada transacción¸ sea pública o privada, con la persona o entidad en cuestión; lo que se ha dado por llamar firma electrónica): El esquema centralizado, basado en autoridades certificadoras (CAs), firmas corporativas y el esquema descentralizado que está basado en llaveros de confianza y firmas personales. Ambos están basados en la criptografía de llave pública, con implementaciones derivadas de la criptografía de llave pública. No profundizaré en cómo estos pueden utilizarse para el intercambio de información, sino sobre la metainformación: Cómo apuntan a la confiabilidad sobre la identidad de un actor. Por un lado, tenemos a la infraestructura de llave pública (PKI). Este es el esquema que siguen los navegadores Web, punto de contacto que casi todos tendremos con los pagos en línea. Además de los navegadores y el ocasional cliente de correo, muchos otros servicios pueden emplear certificados de esta naturaleza para realizar autenticación o cifrado3 — Pero estos dos son los más visibles a los usuarios en general. Bajo un esquema PKI, nuestro navegador confiará ciegamente en la identidad de un conjunto de CAs centrales, definidas por el proveedor del software4. Mientras un certificado esté firmado por una autoridad conocida, el navegador mostrará la conexión como segura. Tenemos por otro lado a los esquemas basados en el esquema de llaveros de confianza. Éste esquema fue dado a conocer en los 1990 con el sistema de criptografía PGP, de Phil Zimmermann. Un llavero de confianza podría definirse como un sistema colaborativo, par a par: Cada participante del llavero firma la llave de los otros participantes a los que conoce personal48

.COLUMNA

Programar es un Estilo de Vida

Asumamos, sin embargo, que la Sra. Abacha nos convenció plenamente de ser ella. ¿Debemos por ello confiar en su oferta? Es aquí donde entra en juego la reputación: Ya que tengo certeza de estar interactuando con la entidad deseada, saber si es una entidad con la que me conviene mantener una transacción es el siguiente albur. Y, en este caso, la reputación es algo que debe establecerse bidireccionalmente. No sólo al comprador le interesa saber que el vendedor le entregará un producto genuino y a tiempo, sino que al proveedor le interesa saber si el comprador tiene cómo pagarlo. No sólo al solicitante de un préstamo le interesa que el banco confíe en su capacidad crediticia, sino que al banco le importa saber si éste no ha faltado a sus obligaciones de pago. Si entro a un sitio de intercambio entre particulares, sea de venta directa o a través de subastas (y seguramente en ambos casos todos habrán pensado en cuál sitio pensé al escribir tan amplia categoría, lo que también entra en el amplio ámbito de la reputación), los individuos participantes tienen una calificación indicando su confiabilidad basada en su comportamiento previo. O saliéndonos del árido tema de las transacciones económicas, en un foro de discusión puede interesarme filtrar los mensajes para sólo ver los que más vale la pena leer, sin recurrir a un sistema que requiera involucramiento masivo de los editores, la mayor parte de estos sitios basan este filtro dando un valor inicial dependiente de la reputación del autor. La asignación de reputación es un área completamente dependiente del campo de aplicación, por lo que resulta imposible hablar de implementaciones como en la sección anterior. Nuevamente, las restricciones de espacio me dejan apenas arañando el campo, apuntando a una gran área a tener en consideración para cualquier desarrollo que emprendamos en que pueda involucrarse el peso o la complejidad de las relaciones entre entidades complejas. Tomar estos elementos en cuenta de forma transversal a los diferentes dominios de aplicación nos llevará a variadas e interesantes consideraciones, que seguramente mejorarán no sólo la confiabilidad de nuestras transacciones, sino incluso la oportunidad y el valor de la información que presentamos a nuestros usuarios.

1 El nombre de la Sra. Abacha es el más prevalente en los fraudes de pago anticipado; tristemente, su identidad y reputación son ya demasiado bajos. Mi intención no es dañarlo más, claro está, sino señalar un fenómeno preexistente 2 Sin embargo, una pequeña proporción de una cantidad absurdamente grande de correos enviados sigue resultando en buen negocio… Y es por ello que estos defraudadores siguen saturando nuestros buzones. 3 Encontraremos referencias a estos certificados como X.509; si vamos a implementar directamente operaciones sobre los certificados, conviene hacerlo empleando la biblioteca libre openssl. 4 Por ejemplo, puede consultar la lista de CAs autorizadas por Mozilla en http://www.mozilla.org/projects/security/certs/included/index.xml 5 Es muy importante tener en cuenta que lo único que aquí se certifica es la identidad, no la confianza en la entidad en cuestión. La confianza será tratada en la siguiente sección. 6 Bruce Schneier: Fake Microsoft certificates, http://www.schneier.com/crypto-gram-0104.html#7 7 Por poner un ejemplo, si yo (llave C1DB921F) obtengo un documento firmado por Marcelo Tosatti (llave E8E1FE55), desarrollador del kernel de Linux, encuentro que (al día en que escribo este texto) estamos a tres “brincos” de distancia: http://pgp.cs.uu.nl/paths/C1DB921F/to/E8E1FE55.html, http://webware.lysator.liu.se/jc/wotsap/wots/ latest/paths/0xC1DB921F-0xE8E1FE55.png

Software Guru

Reputación del individuo

www.sg.com.mx |

mente, certificando confianza en que su identidad es verdadera 5. Cuando un usuario quiere comunicarse con otro, puede ver cuál es el camino de confianza yendo entre individuos, con base en la distancia y grado de conexión (y, por tanto, de certificación) que tiene determinada identidad, decidir el nivel de confianza que depositará en ésta. Entonces, un servidor seguro no es sólo el que implementa una conexión cifrada, sino que aquél en cuya identidad puedo confiar. Emplear cifrado sólo tiene sentido cuando podemos confiar en la identidad de nuestra contraparte. De muy poco serviría que garantizáramos que toda nuestra comunicación llega cifrada hasta nuestra contraparte si dicho sistema no es el sistema destino. Si no verificamos la identidad de nuestra contraparte, un atacante podría interponer un servidor entre nosotros y nuestro destino, descifrando y cifrando nuevamente la comunicación, modificando o guardando los datos que juzgara necesario. En un esquema PKI, basta con engañar a una CA respecto a nuestra identidad para tener la puerta abierta a interceptar las solicitudes de usuarios. Y, tristemente, esto ya hace mucho tiempo pasó del terreno del discurso académico al del mundo real: En 2001 fue detectado un certificado firmado por Verisign a nombre de Microsoft, otorgado a un individuo sin relación alguna con dicha compañía6. A diferencia de PKI, en que un conjunto de firmas se ve como una serie de árboles con raíces en cada una de las CAs certificadas, una red de firmas basada en las ideas de Zimmermann nos aparece como una red fuertemente interconectada, y nos permite validar varios caminos de confianza entre dos participantes de esta red y evaluar cada a uno de ellos basado en la confianza subjetiva que damos a los actores involucrados7. No hay un esquema indiscutiblemente mejor que el otro, solo son utilizados con fines distintos. Ambos tienen su ámbito de aplicación, y si hoy podemos confiar en la confidencialidad, integridad y seguridad de las transacciones en línea, es por estos esquemas. Nuevamente, de muy poco nos serviría cifrar nuestras transacciones en un entorno hostil sin tener confianza en que la contraparte es quien esperamos que sea.

.COLUMNA Prueba de Software

TMMi un modelo de calidad

especializado en pruebas

Sandra Berenice Ruiz Eguino es Consultora de e-Quallity en proyectos de mejora de organizaciones de prueba de software. Cuenta con certificación internacional en Pruebas por el ASTQB.

Armando Silva Alarcón es Consultor y Coordinador de proyectos de innovación en Avantare Consultores.

n ediciones anteriores, hemos hablado sobre el modelo mexicano Test Aptitude Model (TAM) de e-Quallity, el europeo Test Process Improvement (TPI) de Martin Pol y Tim Koomen, y el estadounidense Testing Maturity Model (TMM) del Illinois Institute of Technology). TMMi (Testing Maturity Model integrated) es otro modelo especializado en prueba de software, y en diciembre del 2010 se liberó su versión 3.1, la cual incluye los niveles 4 y 5 que habían quedado pendientes en la versión anterior (2.0). Conozcamos un poco más sobre él. Como podrán suponer, las raíces de TMMi provienen de TMM. Fue desarrollado como complemento del modelo de desarrollo CMMi, buscando cubrir todos los aspectos de la calidad del software, los cuales nos eran cubiertos en los modelos orientados al desarrollo. Cabe destacar que mientras que los modelos CMMi y CMM surgen del Software Engineering Institute en Estados Unidos, TMMi es administrado por TMMi Foundation en Europa, que ”heredó” el TMM del Illinois Institute of Technology.

El Modelo de Madurez de Pruebas Integrado (TMMi)

TMMi contempla 5 niveles de madurez y dentro de su estructura se definen 16 áreas clave de proceso, para las cuales existen metas generales y específicas que a su vez se basan en una serie de prácticas y sub-prácticas, las cuales podremos describir en detalle en futuras entregas de esta columna. Los modelos de calidad suelen manejar una estructura matricial, que da mayor claridad respecto a la obtención de cierto nivel de madurez, conforme se van cubriendo ciertas áreas de proceso. Eso significa que una organización se hace acreedora a cierto nivel

Nivel 1: Inicial

Nivel 2: Gestionado Política y estrategia de prueba; Planeación de prueba; Monitoreo y control de prueba; Diseño y ejecución de prueba; Ambiente de prueba

Nivel 3: Definido Organización dedicada a prueba; Entrenamiento para prueba; Ciclo de vida de prueba; Prueba no funcional; Revisión de pares

Nivel 4: Medido Medición de prueba; Evaluación de la calidad del producto; Revisiones avanzadas

Nivel 5: Optimizado Prevención de defectos; Control de calidad; Optimización de proceso de prueba Lista 1. Estructura de los niveles y áreas de TMMi

de madurez, conforme ésta va adoptando, asimilando, y madurando las prácticas correspondientes a cada área clave. La lista 1 indica las áreas de proceso que corresponden a cada nivel. Para verificar la alineación con el modelo se contempla el empleo de un método de evaluación. Sin embargo, dado que el modelo recién acaba de completarse, se tienen apenas algunos acuerdos iniciales. A inicios de este 2011, la TMMi Foundation lanzó una solicitud de propuesta para invitar a organizacio50

“TMMi fué desarrollado como complemento al modelo CMMi.”

nes interesadas a desarrollar un método de evaluación formal y documentado. Esperamos que la institucionalización de dicho método permita a la TMMi Foundation mantener un control respecto a la adopción del modelo por diversas organizaciones en el mundo, tal como el SEI lo regula en el caso de CMMI. De ser aceptado este modelo en la industria mexicana, su adopción podría acelerarse en la medida que las empresas que ya están en el camino de preparación, o aquellas que ya cuentan con una certificación en TMM o TPI hicieran una transición rápida a TMMi. En una edición posterior tocaremos puntos más específicos respecto a las novedades de la actual versión de TMMi y pondremos en perspectiva cómo una organización que ha obtenido ciertos niveles de madurez en el modelo predecesor TMM, puede migrar a TMMi.

>> Por Berenice Ruiz y Armando Silva

.TECNOLOGÍA Infraestructura

Cómputo en la Nube y Optimización de WAN

››Por Andrés Hurtado

retos para soportar los nuevos patrones de uso

a idea de los servicios en la nube ha cobrado gran popularidad, y hay una buena razón para ello, ya que el potencial que tienen los servicios de nube de recortar los costos de la infraestructura de TI para las empresas es enorme. De hecho, un reporte reciente de Merrill Lynch afirma que la migración a la nube es un “giro tectónico y disruptivo” que podría generar un mercado de 100,000 millones de dólares para el año 2013.

¿Qué es la nube?

Llegar a una definición universalmente aceptable de “la nube” es una tarea intimidante, pero hay una cosa clara: la nube aspira a trasladar los recursos y las aplicaciones de TI a un modelo de cómputo más escalable y efectivo en términos de costo. En el mundo ideal de los proveedores de servicios de nube, la empresa no maneja centros de datos; sólo el proveedor de la nube tiene centros de datos y esos recursos sirven a muchas empresas.

La nube y el desempeño

Existe una falsa creencia de que la nube elimina los cuellos de botella en el desempeño. La creencia es que si se usa un servicio de nube, el desempeño será óptimo. En realidad, la nube en sí misma no elimina los cuellos de botella en el desempeño. Las aplicaciones que se ejecutan en servicios de nube están sujetas, como otras aplicaciones, a dos limitaciones básicas: Capacidad. Cualquier red tiene limitaciones en términos de la cantidad de datos que puede transportar en un momento determinado. Si los datos provienen de una fuente interna o externa, contenderán con todos los otros datos que los usuarios soliciten. Tan sólo por tener un servicio de nube no quiere decir que automáticamente podrá poner 10 kilogramos de datos en una bolsa para 5 kg. Latencia y exceso de comandos. Conforme aumenta la distancia entre un usuario y sus datos, el tiempo para acceder a esos datos aumenta considerablemente debido a los efectos combinados de la latencia y las ineficiencias en los protocolos de las aplicaciones, o exceso de comandos. Conforme progresen los servicios de nube, habrá una evolución natural hacia aplicaciones enriquecidas y más interactivas. Hoy es el correo electrónico, CRM y la creación de documentos básicos: mañana será el diseño en colaboración, el manejo de documentos a escala completa y las aplicaciones de manejo de la producción en múltiples niveles. Como resultado, podemos ver que los servicios de nube llevarán más datos a través de la WAN para una serie de usuarios distribuidos cada vez mayor.

Optimización de la WAN

Las empresas han adoptado la infraestructura de optimización de la WAN como método clave para acelerar aplicaciones a través de la WAN y permitir la centralización de la infraestructura en uno o unos cuantos centros de datos. La optimización de la WAN otorga tres beneficios clave: • Aumenta la capacidad virtual. Gracias a la deduplicación de bytes de tráfico redundante, el usuario tiene la sensación de tener una velocidad de conexión mucho mayor a la real. • Mejoras de desempeño. Las aplicaciones tienen un desempeño de hasta 15 veces mejor eliminando las ineficiencias en los protocolos de las aplicaciones, lo que da a los usuarios la velocidad que necesitan para trabajar de manera efectiva. • Diseño flexible. Mediante el uso de una plataforma para la optimización de la WAN, las empresas ya no dependen de su proveedor de aplicaciones o de nube para ser expertos en redes.

Optimización WAN en el contexto de la nube

La experiencia reciente demuestra que, debido a que la optimización de la WAN tiene un historial de acelerar aplicaciones basadas en web, pueden ayudar efectivamente en los servicios de nube internas y externas. Un ejemplo de servicios de nube externa es una importante compañía global de pagos, redes y viajes que trabaja actualmente con un integrador de sistemas para combinar la optimización de la WAN con servicios de nube externa para que les provea el desempeño que necesitan. Con el tiempo, conforme evoluciona la nube, se espera ver que los productos para la optimización de la WAN desarrollen una serie de características adicionales que les permitan dar un mejor soporte a aplicaciones escritas para la nube, además de aplicaciones heredadas que se migren a la nube. En el futuro, los clientes simplemente elegirán la arquitectura que mejor funcione para su organización (TI interna, nube interna, proveedor de nube) y confiarán en su infraestructura de optimización de la WAN para garantizar el desempeño que su empresa requiere. .BIO Andrés Hurtado es Director para Latinoamérica en Riverbed Technology, empresa especializada en mejorar el desempeño de redes y aplicaciones de TI.

.TECNOLOGÍA Gadgets

SONY

Cyber-shot DSC-TX100V La cámara Cyber-Shot TX100V cuenta con un diseño estilizado, pantalla táctil, 16.2 megapixeles y Zoom óptico de 4x. Su pantalla OLED de alto contraste muestra una amplia gama de colores para una reproducción más fiel de colores vivos. Integra la función Air Motion que permite reproducir, navegar y hacer zoom in sin tocar la pantalla gracias a que funciona con sensor a distancia. Cuenta con tecnología GPS y brújula que permite a los usuarios ver el lugar en dónde fueron tomadas las fotografías. Esta serie permite sacar fotos y video en 3D e incorpora la tecnología de Sweep Panorama para fotografías en barrido panorámico en 3D y también en fotos fijas. Además de fotos, la cámara está equipada para grabar videos en Full HD. Proporciona Dual Rec para la toma de alta resolución de imágenes fijas. Al mismo tiempo que graba video. Tomas continuas ultra rápidas de hasta 10 cuadros por segundo con obturador mecánico de alta velocidad. Incorpora la tecnología BIONZ que ofrece un rendimiento más avanzado de mayor calidad y a la vez logra una reducción de ruido durante la grabación.

LENOVO

IdeaPad U1 Este es un precioso y un exclusivo equipo dos en uno que combina la movilidad de un dispositivo HD de gran poder multimedia proporcionando un híbrido entre una laptop y una tablet. La IdeaPad U1 es un híbrido que transforma la interfaz de usuario de la LePad en una portátil con Windows 7 y teclado completo. Son consideradas por Lenovo, herramientas perfectas para las personas que están en constante movimiento. Este dispositivo es ideal para usuarios que necesitan la funcionalidad total de una portátil convencional para la creación de contenidos con aplicaciones basadas en Windows, la LePad puede conectarse a la Base de la U1. Cuando se use lejos del teclado U1, funcionará con el sistema operativo LeOS basado en Android y podremos cambiar a Windows 7 Home cuando lo coloquemos en casa. La Lenovo IdeaPad U1 con LePad estará disponible en China a partir del primer trimestre del 2011. La LePad puede adquirirse por separado de la U1. Esperemos que después de China pronto esté a nuestro alcance, nosotros queremos una ¿tu no?

Motorola

Atrix 4G Y continuando con el concepto “2 en 1”, les presentamos un smarthphone potente que cuenta con procesador de doble núcleo a 1 GHz, memoria RAM de 1GB, pantalla qHD de 960x540 pixeles de resolución, batería de 1930mAh, Wi-Fi, Bluetooth, conexión HDMI y cámara trasera de 5 megapíxeles capaz de grabar vídeo en 720p. ¿Todavía no te sorprendes? Motorola además de incluir las características anteriores, incluye dos gadgets que hacen sumamente explotable éste dispositivo: Motorola HD Multimedia Dock y Motorola Laptop Dock. El Motorola HD Multimedia Dock, es un dock diferente a los habituales que conocemos, ya que viene con con conexiones mediante las que poder enganchar teclado, ratón y pantalla ¿ya te sorprendiste? El Motorola Laptop Dock, es un portátil con pantalla de 11.6 pulgadas, teclado, altavoces y batería de 8 horas de autonomía. ¿Y por qué no? también incorpora un sensor de huellas dactilares para bloquear, bloquear y encender el móvil. El precio y la fecha en la que podremos tenerla al alcance aún son una incógnita. 54