SG #31

Cambiando a un modelo de entrega SaaS

Anonymous — Tue, 29 Mar 2011 18:52:10 +0000

Cambiando a un modelo de entrega SaaS Anonymous Tue, 03/29/2011 - 12:52

Publicado en

SG #31

Autor

Paul Avenant

El 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.

SaaS es una opción viable para la Gestión de Servicio de TI como entrega y una opción de modelo de negocio. 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.

Bio

Paul Avenant es Software Senior Vice President, Enterprise Service Management Products and Strategy en BMC.

Certificados digitales: Panorama y posibilidades de mejora

Anonymous — Tue, 29 Mar 2011 18:51:53 +0000

Certificados digitales: Panorama y posibilidades de mejora Anonymous Tue, 03/29/2011 - 12:51

Publicado en

SG #31

Autor

Ignacio Mendivil

En 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 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 (time-stamping) 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 NOM-151. Todo parece indicar que el cambio será hacia la adopción de estándares internacionales, lo cual será muy beneficioso para nuestro país.

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”.

TMMi: Un modelo especializado en pruebas

Anonymous — Tue, 29 Mar 2011 18:35:29 +0000

TMMi: Un modelo especializado en pruebas

Anonymous Tue, 03/29/2011 - 12:35

Publicado en

SG #31

Prueba de Software

Autor

Armando Silva

En 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.

Lista 1. Estructura de los niveles y áreas de TMMi

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 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 organizaciones 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.

Bio

Armando Silva Alarcón es Consultor y Coordinador de Proyectos de Innovación en Avantare Consultores.

Identidad y Reputación en Línea

Anonymous — Tue, 29 Mar 2011 18:35:09 +0000

Identidad y Reputación en Línea Anonymous Tue, 03/29/2011 - 12:35

Publicado en

SG #31

Programar es un Estilo de Vida

Autor

Gunnar Wolf

“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.”

El 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

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 personalmente, certificando confianza en que su identidad es verdadera5. 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ñía.

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 involucrados.

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.

Reputación del individuo

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.

Bio

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

El Futuro del Centro de Cómputo

Anonymous — Tue, 29 Mar 2011 18:34:52 +0000

El Futuro del Centro de Cómputo Anonymous Tue, 03/29/2011 - 12:34

Publicado en

SG #31

Tendencias en Software

Autor

Luis Daniel Soto Maldonado.

Nos 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.
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.

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.

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.

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

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 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.

Evolución del centro de cómputo

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 desem-peñ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.

Mejora Continua vs. Mejora Perfecta

Anonymous — Tue, 29 Mar 2011 18:34:33 +0000

Mejora Continua vs. Mejora Perfecta Anonymous Tue, 03/29/2011 - 12:34

Publicado en

SG #31

Mejora continua

Autor

Luis Cuellar

El 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.

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 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.

Bio

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

Barreras para la Mejora de Procesos de Software

Anonymous — Tue, 29 Mar 2011 18:34:15 +0000

Barreras para la Mejora de Procesos de Software Anonymous Tue, 03/29/2011 - 12:34

Publicado en

SG #31

Tejiendo nuestra red

Autor

Hanna Oktaba

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

En 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:

Falta de administración de proyectos (5)
Falta de recursos (6)
Falta de patrocinio (7)
Equipo sin experiencia (1)
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:

Falta de soporte (8)
Políticas organizacionales (12)
Falta de preocupación (awareness) por SPI (2)

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 experiencia (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.

-----

Referencias

Mahmood Niazi, Muhammad Ali Babar, June M. Verner. "Software Process Improvement barriers: A cross-cultural comparison". Information and Software Technology 52 (2010), pág. 1204–1216, Editorial Elsevier.

Infraestructura: Cómputo en la nube y optimización de WAN

Anonymous — Tue, 29 Mar 2011 18:33:55 +0000

Infraestructura: Cómputo en la nube y optimización de WAN Anonymous Tue, 03/29/2011 - 12:33

Publicado en

SG #31

Infraestructura

Autor

Andrés Hurtado

La 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.

Ágil: Apropiación de Lean-Agile y Kanban

Anonymous — Tue, 29 Mar 2011 18:32:55 +0000

Ágil: Apropiación de Lean-Agile y Kanban Anonymous Tue, 03/29/2011 - 12:32

Publicado en

SG #31

Agilidad

Autor

Una 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.
Diseñador instruccional: experto en pedagogía.
Diseñador gráfico: experto en comunicación visual.
Integrador de tecnologías: programador y administrador de tecnologías Web.

Estos equipos diseñan y desarrollan tres diferentes tipos de proyectos:

Desarrollo de aplicaciones: implica 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:

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

Apropiación de Kanban

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 cliente 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.

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:

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
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
También se identificaron tres estados para cualquiera de las tarjetas:
- Bloqueado
- En corrección
- Cancelado
Además se establecieron tres estados para los tableros generales (que identifican todos los proyectos) :
- Pendiente
- En proceso
- Concluido

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.

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:

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.

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.

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.

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, 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.

Bio

M.C. Jorge Polo Contreras Paredez, CATED-CUAED-UNAM / Jefe del Departamento de Desarrollo Tecnológico.

M.C. Norma Edith Hernández Galaviz, CATED-CUAED-UNAM / Jefa del Departamento de Desarrollo Educativo.

M.C. Luis Alonso Nava Fernández, CATED-CUAED-UNAM / Subdirector de Docencia y Educación Contínua.

Evaluación de la Arquitectura de Software

Anonymous — Tue, 29 Mar 2011 18:32:36 +0000

Evaluación de la Arquitectura de Software Anonymous Tue, 03/29/2011 - 12:32

Publicado en

SG #31

Autor

Humberto Cervantes

ENTENDIENDO Y CUESTIONANDO EL DISEÑO ARQUITECTÓNICO

A 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 requerimientos como los anteriores. El riesgo de no tener seguridad al respecto de ello de forma temprana en el desarrollo puede tener consecuencias muy serias en etapas posteriores del desarrollo y muy particularmente, si se descubren problemas relacionados con la arquitectura en etapas tardías tales como la implantación del sistema.
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 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.

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

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.

Bio

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

SG #31

Cambiando a un modelo de entrega SaaS

Publicado en

Autor

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

Certificados digitales: Panorama y posibilidades de mejora

Publicado en

Autor

TMMi: Un modelo especializado en pruebas

Publicado en

Autor

El Modelo de Madurez de Pruebas Integrado (TMMi)

Identidad y Reputación en Línea

Publicado en

Autor

Confianza en la identidad

Reputación del individuo

El Futuro del Centro de Cómputo

Publicado en

Autor

Mejora Continua vs. Mejora Perfecta

Publicado en

Autor

Barreras para la Mejora de Procesos de Software

Publicado en

Autor

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

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

Infraestructura: Cómputo en la nube y optimización de WAN

Publicado en

Autor

¿Qué es la nube?

La nube y el desempeño

Optimización de la WAN

Optimización WAN en el contexto de la nube

Ágil: Apropiación de Lean-Agile y Kanban

Publicado en

Autor

Introducción

Metodología interdisciplinaria para el desarrollo de materiales educativos

Adopción de Lean-Agile

Apropiación de Kanban

Adaptaciones a la metodología Kanban

Conclusiones

Evaluación de la Arquitectura de Software

Publicado en

Autor

Tags