SG #33

Interoperabilidad: ¿A qué aspiramos cuando hablamos de ella?

Anonymous — Tue, 20 Sep 2011 18:48:09 +0000

Interoperabilidad: ¿A qué aspiramos cuando hablamos de ella? Anonymous Tue, 09/20/2011 - 13:48

Publicado en

SG #33

Programar es un Estilo de Vida

Autor

Gunnar Wolf

El pasado 2 de junio participé en el foro «Software Libre en México, reflexiones y oportunidades», organizado por la Comisión de Ciencia y Tecnología del Senado de la República. En este foro tocamos cuatro temas principales: Educación, gobierno, industria y sociedad.

Si bien el objetivo explícito central del foro fue presentar ante los legisladores y medios interesados tanto los puntos de vista que tenemos los activistas del software libre como las historias de éxito, los avances y problemas con que nos hemos encontrado en los ya más de quince años que llevamos de existencia en nuestro país, posiblemente lo más importante que nos llevamos los participantes fue la reactivación de un grupo de discusión para tratar temas políticos relacionados con la tecnología y con el factor cohesivo de estar interesados en la difusión del software libre.

Este grupo, coordinándose a través de una lista de correo pública[1], está actualmente en proceso de definir los puntos de la agenda digital a presentar; el primero de ellos es el de la interoperabilidad.

El tema coincide con la presentación de la versión preliminar de un acuerdo de la Secretaría de la Función Pública (SFP), a ser discutido y –esperamos– aprobado en las próximas semanas o meses. Nos resulta de gran importancia no sólo analizar y proponer en lo relativo a esta temática hacia el interior de nuestro grupo (y de las instancias gubernamentales involucradas), sino también hacia los demás profesionales en el tema, como lo son los lectores de esta revista.

Dada la imposibilidad de proporcionar referencias a un documento aún inexistente y motivado por el interés que seguramente ésto causará a más de uno de ustedes, coloqué a su disposición una copia de una versión preliminar de este texto en mi sitio Web[2].

¿A qué nos referimos con interoperabilidad?

Al enfrentar un desarrollo, un punto fundamental a considerar desde muy temprano es cuál será su límite o interfaz, sea un sistema, un API sobre la nube, un servicio, un componente o una biblioteca, debemos delimitar por qué mecanismo recibiremos las solicitudes de los usuarios y por cuál le entregaremos los resultados. Del mismo modo, nuestro sistema parte de un contrato con diversos elementos (nuevamente, de cualquiera de los niveles antes descritos) que le brindarán facilidades, por ejemplo, de conectividad a red o de manejo de bases de datos. Hablar de interoperabilidad significa que en cada uno de dichos puntos, en cada una de las interfaces, el intercambio de datos se realice de forma tal que evite imponer dependencia en algún paquete específico, en los designios de algún producto que a futuro pudiera –de cierto modo– mantener como rehén sea al usuario final, al desarrollador o a la entidad que requirió del desarrollo en cuestión.

En palabras del Grupo de Trabajo para la Interoperabilidad, de la Asociación Francófona de Usuarios de Software Libre[3]:
“La interoperabilidad es la capacidad que tiene un producto o un sistema, cuyas interfaces son totalmente conocidas, para funcionar con otros productos o sistemas existentes o futuros y eso sin restricción de acceso o de implementación.”

El borrador de la SFP divide la definición de interoperabilidad en cinco sub-definiciones:

Interoperabilidad - Definición del concepto global.
Interoperabilidad organizacional - Homologar criterios y procedimientos entre distintas dependencias.
Interoperabilidad semántica - Un manejo estandarizado del significado de los diversos conceptos.
Interoperabilidad técnica - A las especificaciones técnicas que garantizan que los componentes tecnológicos de los sistemas de información están preparados para interactuar de manera conjunta.
Neutralidad tecnológica - Busca que cada dependencia pueda elegir los programas y mecanismos más adecuados para su desarrollo sin que se favorezca o penalice a ninguno por criterios más allá de los puramente técnicos.

Del dicho al hecho

Quien pegue una etiqueta en una página web que diga “esta página se ve mejor con el navegador X” es un nostálgico por los días viejos y malos, antes de la Web, cuando tenías muy pocas probabilidades de leer un documento escrito en otra computadora, otro procesador de textos u otra red. — Tim Berners-Lee, Technology Review, julio 1996.

El documento presentado por la SFP nos parece muy esperanzador, está escrito de forma clara y bastante exhaustiva. El cuidado que debemos ahora poner va principalmente para que el acuerdo no quede en letra muerta, debe ser del conocimiento de las diversas dependencias y ser tomado en serio para beneficio no sólo de toda la población, sino que de cada una de dichas dependencias. Además, debe ser conocido y comprendido por la industria nacional de desarrolladores de software, dado que interoperar sin restricciones no únicamente beneficia al sector público, sino que, a fin de cuentas, a todos los implicados.

Escribir software que no dependa de implementaciones específicas es sencillamente escribir mejor software.

Al día de hoy, como usuarios, tristemente nos resulta muy común encontrar, una y otra vez, ejemplos de cosas que podrían trivialmente ser interoperables, pero resultan no serlo y lo que es peor: sin razón alguna.

Ejemplos de lo que digo son demasiado comunes. Desde la aplicación desarrollada por el SAT para presentar la declaración de impuestos (desarrollada en Java, plataforma que se popularizó al ser la primera en impulsar explícitamente la interoperabilidad como su principal promesa), que sencillamente se niega a operar al ser llamada con cualquier navegador que no sea Internet Explorer, hasta el SUA del IMSS, única manera en que una empresa puede dar de alta y administrar a su plantilla de trabajadores ante IMSS e INFONAVIT, que requiere ser ejecutada en computadoras corriendo Windows. Y al igual que estos dos casos de altísima visibilidad, seguramente ustedes podrán citar a ejemplos adicionales que obligan a sus usuarios a emplear tecnologías específicas, sin justificación técnica alguna para hacerlo.

El pretexto más frecuente que encontramos ante cualquier solicitud de que algún sistema sea utilizable desde una plataforma distinta es el ya sabido “eso es lo que hay y no podemos hacer nada al respecto” donde modificar la base de software ya desarrollado e instalado significaría una tarea titánica. Sin embargo, los servicios fundamentales que deben estar disponibles para toda la población deben ser priorizados. Resulta inaceptable que a la población en general se le imponga el requisito de emplear una tecnología específica (independientemente del papel dominante que ésta tenga actualmente en el mercado), especialmente dado el desarrollo y rápida adopción de estándares como HTML5, que permiten un despliegue extensivo de interfaces de usuario ricas y completamente multiplataforma.

Las múltiples facetas de la interoperabilidad

Hablar de interoperabilidad no se limita a permitir que usuarios con configuraciones diversas puedan usar los sistemas de gobierno, como lo mencionamos en el primer apartado, parte importante de la interoperabilidad se refiere a cómo facilitar el intercambio de información entre entidades del mismo gobierno, a la creación de modelos estandarizados (la ya citada interoperabilidad semántica) con los que puedan representarse e intercambiarse datos acerca de las estructuras más comúnmente encontradas y repetidas, las cuales posiblemente faciliten que paulatinamente se vaya creando, en vez de una colección de sistemas que conforman al e-gobierno, una nube de información con un mínimo de duplicación de información.

¿Y cómo elegir entre tantos estándares disponibles? ¿Qué formatos, protocolos y lenguajes son los más adecuados? ¿Cómo podemos determinar cuál es un estándar abierto? Este es un tema que da para largas discusiones, y motivo de los diferentes foros referidos. Si nos basamos en lo que dice el Proyecto de Acuerdo al respecto, tenemos que los estándares abiertos deberán tener, como mínimo, las características siguientes:

Disponibilidad.
Que los derechos de autor estén disponibles, libres de regalías y condiciones.
Maduros.
Internacionalmente aceptados.
De fácil distribución.
Con amplio soporte en el mercado.

El sólo hecho de reducir la cantidad de datos redundantes (y por consiguiente avanzar en la larga lucha contra los peregrinares a mil ventanillas para cualquier trámite trivial) ya por sí sólo lo valdría. Agreguemos a esto que reducirá fuertemente la dependencia de proveedores únicos y de la permanencia en el mercado de productos específicos, fomentando el crecimiento de una verdadera industria de desarrollo de software.

Sigamos entonces, la discusión que se presentará sobre estos temas en los próximos meses. Este es un tema que indudablemente impactará el trabajo de todos nosotros y en el que todos tendremos algo que aportar.

Bio

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

Es un Nuevo Mundo

Anonymous — Tue, 20 Sep 2011 18:32:33 +0000

Es un Nuevo Mundo Anonymous Tue, 09/20/2011 - 13:32

Publicado en

SG #33

Tecno-lógico

Autor

Mauricio Angulo S.

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

La administración científica

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

La división del trabajo en dirección y trabajadores.
La subdivisión de las tareas en otras más simples.
La remuneración del trabajador según su rendimiento en producción.

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

Los trabajadores del conocimiento

Si bien la administración científica proveyó de las guías y métodos que se necesitaban para suministrar la creciente demanda de bienes de consumo a las grandes ciudades, a mediados del siglo XX se crea la figura del “trabajador del conocimiento“, una especie de “obrero“ especializado cuyo trabajo no puede ser medido en el número de piezas que produce por hora, sino por la innovación que aporta a los procesos de producción. Un trabajador del conocimiento produce intangibles: ideas, información, que para que sean productivos alguien debe apropiárselos e integrarlos en una tarea. Son trabajadores del conocimiento tanto los investigadores científicos y los cirujanos, como los dibujantes, los creativos, los publicistas, los gerentes o los empleados que trabajan con una computadora.

El problema en la gestión de los trabajadores del conocimiento es que su trabajo no puede ser simplificado o sistematizado debido a la naturaleza intangible de lo que producen: una buena idea puede producir más en términos de beneficios al negocio que años de optimización de procesos. Las condiciones para que un trabajador del conocimiento pueda operar eficientemente difieren mucho a las que requiere un obrero, ser un trabajador del conocimiento implica autogestionarse, es decir, concentrarse en la tarea, administrar el tiempo, asumir responsabilidad por su propio desarrollo, crecimiento y por los resultados generados.

TI y la administración actual

A 100 años de la definición del Taylorismo las empresas, sus áreas y sub-áreas siguen siendo organizadas de la misma manera que cuando eran sólo fábricas que producían bienes de consumo, enfrentándose a serios problemas en cuanto al manejo y gestión de los trabajadores del conocimiento. Peter Drucker menciona en su libro Knowledge-Worker Productivity: The Biggest Challenge que “en términos de los conocimientos reales sobre la productividad del trabajador del conocimiento, estaremos en el año 2000 aproximadamente donde estábamos en 1900 en términos de los conocimientos sobre la productividad del trabajador manual”, lo que es indicativo de lo mal preparadas que se encuentran las empresas para manejar y gestionar sus áreas de TI de forma óptima.

Dentro de los grandes corporativos cuyo foco no es la tecnología –por ejemplo, el gobierno– las áreas de TI se encuentran englobadas dentro de las áreas de administración porque se les consideran “áreas de servicios“, limitadas a sustentar la base tecnológica del corporativo. En los corporativos cuyo foco es la tecnología, las personas especialistas en su desarrollo se encuentran en las partes bajas del organigrama dejando la toma de decisiones a ejecutivos que muchas veces no tienen la preparación ni el conocimiento de primera mano sobre la misma tecnología que se crea en las empresas para las que trabajan.

En ambos casos el problema en la administración deficiente se refleja como la burocracia alrededor de los trabajadores de TI: reportes, reglamentos, juntas, reuniones, planes, procedimientos y varios otros elementos que más que facilitar el proceso de creación e innovación son obstáculos cuyo fin es justificar el trabajo en lugar de volverlo sustentable. En un entorno así, el personal de TI se vuelve burocrático y reactivo, enfocado en llenar formatos y documentos en lugar de crear tecnología eficiente y enfocado a usuarios reales.

No digo que los elementos de administración deban ser eliminados por completo, sino que deberían ser reducidos a lo que es estrictamente necesario para dar un modelo e infraestructura que sustente a los trabajadores de información dentro de las áreas técnicas de las empresas, pero con 100 años a cuestas de administración científica en el cuerpo directivo esta no será una tarea sencilla, al menos en las empresas tradicionales. Este puede ser un indicativo de por qué cada vez hay más startups de tecnología y porqué el talento técnico empieza a preferir trabajar en empresas pequeñas o incluso en sus propias ideas.

La nueva realidad

Actualmente, cuando se trata de tecnología, todos pueden comenzar un negocio. Las herramientas y plataformas que solían estar fuera del alcance de muchos ahora son fácilmente accesibles y la tecnología de alto costo ahora se puede obtener por precios muy bajos o inclusive de manera gratuita. Una persona puede realizar el trabajo de dos o tres y en ocasiones de departamentos enteros. Cosas que hasta hace unos años eran consideradas imposibles son algo simple hoy en día.
Las tecnologías de información nos habilitan para tener acceso a prácticamente toda la información que podamos necesitar sin movernos de nuestra silla, trabajar en cualquier lugar sin necesitar de una oficina y colaborar en tiempo real con personas que se encuentran a cientos de kilómetros.

Debemos repensar los procesos y métodos con los que trabajamos basados en el nuevo mundo en el que vivimos, muy diferente de aquel en que fueron redactados los principios con los que se crearon las empresas que existen hoy en día. La verdadera mejora de procesos se encuentra en el enfoque al usuario y al mercado, no en la burocracia laboral.

Bio

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

BPM Semántico

Anonymous — Tue, 20 Sep 2011 18:18:23 +0000

BPM Semántico Anonymous Tue, 09/20/2011 - 13:18

Publicado en

SG #33

Código Innovare

Autor

La adopción de metodologías de gestión de procesos de negocio ha aumentado considerablemente en las empresas en los últimos años. En este contexto es indiscutible la necesidad de usar herramientas tecnológicas para hacer factible la gestión de los procesos. Como consecuencia, existe una gran variedad de herramientas que apoyan en las distintas fases del ciclo de vida de los procesos de negocio. Sin embargo, muchas de estas herramientas no toman en cuenta el conocimiento organizacional como directriz en el desarrollo de los procesos.

En este artículo se presenta un nuevo enfoque, basado en tecnología semántica, para las herramientas de gestión de procesos de negocio. La aplicación de tecnologías semánticas provee ventajas importantes para los dueños del negocio, ya que no sólo permiten gestionar los procesos sino también el conocimiento generado y transformado por los mismos.

Introducción a BPM

La gestión de procesos de negocio o BPM (Business Process Management) es una disciplina que considera tanto el uso de las metodologías de mejora de procesos como el uso de herramientas que soportan las fases definidas en las metodologías [1], tomando en cuenta aspectos sociales y tecnológicos. BPM tiene como objetivo, por un lado, el ayudar a automatizar, administrar y optimizar procesos; por otro lado, intenta facilitar la interacción entre los humanos y las herramientas requeridas para operar los procesos de negocio.

De manera general, el ciclo de vida de desarrollo de los procesos de negocio en BPM considera las fases de diseño, modelado, ejecución, monitoreo y optimización mostradas en la figura 1. Este ciclo permite llevar un proceso desde su descubrimiento y documentación hasta la propuesta e implantación de mejoras en la ejecución del mismo. Una buena parte del ciclo de vida se puede automatizar mediante herramientas de gestión de procesos, que implementan diversos estándares –como XPDL [2] y BPMN [3]– para el modelado y ejecución de procesos de negocio. Dichos estándares permiten: a) el intercambio de información mediante formatos que facilitan la interoperabilidad entre sistemas, y b) el entendimiento del negocio mediante la aplicación de notaciones que proporcionan un lenguaje común para todos los involucrados en los distintos niveles del proceso: administradores, analistas, operadores e incluso clientes. Ver Figura 1.

Herramientas BPM tradicionales

Las herramientas para la gestión de procesos de negocio proporcionan mecanismos para que los involucrados en el desarrollo de los procesos puedan identificar y documentar sus procesos clave, ejecutarlos y medir su efectividad. Estos mecanismos proveen información de valor para poder adecuar los procesos a las necesidades cambiantes del entorno, de sus clientes y del mercado. Actualmente existen una gran variedad de herramientas de distintos fabricantes, éstas son algunas de sus características comunes:

Independencia de alguna metodología específica de gestión de procesos, lo cual permite su adecuación de acuerdo a las necesidades de cada organización.

Acotamiento a alguna de las etapas del ciclo de vida del proceso, es decir, se tiene una herramienta específica para modelado, otra para ejecución y otra para monitoreo. Esto puede ser una desventaja ya que obliga a aprender distintas herramientas para cubrir el ciclo de vida completo.

Típicamente no se incluye mecanismos para la captura, administración y explotación del conocimiento asociado a los procesos de la organización, por lo que dicho conocimiento se encuentra disperso en cada una de las personas y técnicas utilizadas en las distintas fases del ciclo de vida.

BPM basado en tecnologías semánticas

Con la materialización de la Web Semántica (basada en el significado explícito de la información contenida en las páginas de Internet), surge un conjunto de tecnologías enfocadas al descubrimiento, representación y gestión de conocimiento. En el contexto de los procesos de negocio, estas tecnologías permiten integrar, además de la gestión de los procesos de negocio, un mecanismo para hacer explícito y concentrar el conocimiento a nivel organizacional. De este modo, las organizaciones pueden transformar su enfoque de desarrollo de procesos hacia un enfoque orientado al conocimiento organizacional que les permita una mejor toma de decisiones y una mayor flexibilidad para atender las necesidades de los clientes.

Este enfoque tiene como objetivo incorporar el conocimiento organizacional en las fases de diseño, modelado y ejecución de procesos con el desarrollo de técnicas más expresivas y formales para representar la semántica contenida en los mismos. Esto implica el cambio a una nueva manera de hacer el descubrimiento y documentación de los procesos existentes para lograr capturar el conocimiento implícito. En este sentido, es el conocimiento quien define el intercambio de información entre las actividades del proceso, en lugar de ser el flujo del proceso quien determina la ruta de la información. La figura 2 presenta un esquema de este enfoque. Ver Figura 2.

El enfoque semántico de las herramientas de gestión de procesos incorpora una etapa más en la fase de diseño, ésta consiste en el modelado del conocimiento organizacional usando ontologías (conceptualización explícita de un área de conocimiento en términos de entidades y sus relaciones) para capturar los conceptos relevantes asociados a la información manejada en la operación de los procesos. Las ontologías constituyen un repositorio de conocimiento institucional accesible por todos los miembros de la organización y facilitan la interoperabilidad de los humanos y los sistemas involucrados en el ciclo de vida de los procesos. Los conceptos en la ontología introducen nuevas restricciones y dependencias de información que deberán ser consideradas para construir el flujo de los procesos (basado en actividades, compuertas y eventos), permitiendo detectar desde un inicio rutas críticas y productos esenciales para los procesos.

En el modelado de los procesos se relaciona el conocimiento previamente descubierto con las actividades definidas, indicando las transformaciones necesarias en cada actividad para generar los productos (información) del proceso, almacenarlos y facilitar su exposición y explotación en la base de conocimiento. Estas relaciones son interpretadas por el motor de ejecución, quien utiliza el flujo y la base de conocimiento de los procesos para hacerlos operables.

Algunas de las ventajas del uso de herramientas basadas en la tecnología semántica son:

Facilitan el modelado dinámico de objetos de negocio a través de modelos ontológicos, lo cual permite que un cambio en la estructura de la información se vea reflejado de manera inmediata en la ejecución actual del proceso.
Permiten integrar en una sola herramienta el desarrollo de todas las fases del ciclo de vida, incrementando con esto la facilidad de explicitar el conocimiento generado en cada una de las fases y reducir la curva de aprendizaje necesaria para llegar a la operación de los procesos.
Permiten contextualizar los procesos de negocio para descubrir nueva información a través de inferencias realizadas sobre su base de conocimiento.
Facilitan la integración con componentes SOA por la manera en que representan la información.
Integración natural con la Web Semántica, que permite una recuperación más eficiente de la información contenida en la base de conocimiento y la incorporación de dominios tecnológicos como el procesamiento de lenguaje natural, computación en la nube y bases de datos semánticas.

Conclusiones

La gestión de procesos de negocio sigue evolucionando. El surgimiento de la web semántica y los mecanismos de representación de conocimiento asociados a la misma han permitido cambiar el enfoque de modelado de procesos hacia metodologías que toman como punto de partida la información relevante de las organizaciones para determinar el flujo de los procesos. Este enfoque ha disparado la creación de herramientas que combinan el modelado de procesos de negocio y el modelado de conocimiento organizacional mediante el uso de mecanismos de representación estándares como ontologías y notaciones de modelado de procesos. Algunas de las ventajas de estas herramientas son el modelado dinámico de la información, el manejo integral del ciclo de vida de los procesos, el descubrimiento de nuevo conocimiento y la integración de los sistemas de ejecución de los procesos con la Web semántica.

Aunque las tecnologías semánticas se han aplicado hasta ahora en ciertas fases del ciclo de vida de los procesos, se están realizando trabajos para incorporar dichas tecnologías en el resto de las etapas. El objetivo de estos trabajos es lograr definir metodologías y herramientas tecnológicas que permitan obtener de manera semi-automática el flujo de los procesos de negocio partiendo del conocimiento modelado en las primeras etapas.

Bio

Ebener Hasdai Sánchez Pacheco colabora en la Gerencia de Desarrollo de Nuevos Productos en el Infotec (http://www.infotec.com.mx/). Cuenta con una Maestría en Ciencias de la Computación con especialidad en Inteligencia Artificial por parte del Centro Nacional de Investigación y Desarrollo Tecnológico (CENIDET). ebenezer.sanchez@infotec.com.mx

El Dr. Hugo Estrada Esquivel colabora en el Departamento de Ciencias Computacionales del CENIDET. Cuenta con un Doctorado en Informática por parte de la Universidad Politécnica de Valencia. Sus áreas de especialidad son el modelado de negocios, ingeniería de requisitos y reingeniería de procesos de negocios. hestrada@cenidet.edu.mx

El Futuro de Internet

Anonymous — Mon, 19 Sep 2011 22:00:10 +0000

El Futuro de Internet Anonymous Mon, 09/19/2011 - 17:00

Publicado en

SG #33

Tendencias en Software

Autor

Luis Daniel Soto Maldonado.

Internet enlaza actualmente a 2 mil millones de personas, y anualmente se integran otros 200 millones. La red representa en la actualidad menos del 4% del producto interno bruto en países en desarrollo y 6% en economías desarrolladas, de acuerdo a McKinsey Globlal Institute.

El mismo estudio encontró un incremento en productividad de PYMES de 10% gracias al uso de Internet. Todos coinciden en los beneficios para el individuo, la empresa, el gobierno y el desarrollo económico. ¿Qué sigue, cuál es el futuro?

Los padres de Internet han deseado que sea semántico, no solo “folletería digital” o transaccional.
Hoy ya es social. De hecho, tan solo Facebook está provocando que el uso de internet haya cambiado radicalmente.
El cómputo en la nube es sin duda una nueva realidad en Internet. En mi opinión, el destino final de adoptar la nube pública es inevitable, aunque estemos artificialmente enfocados en la nube privada por limitantes en el manejo de datos.
Algunos quieren que la red sea optimizada para comunicación entre máquinas y no entre humanos, como fue en la etapa inicial. Cisco lo llama “La internet de cosas” y explica que a fines del 2010 existían 1.84 dispositivos por habitante. El aprendizaje automático será necesario ya que no hay humanos suficientes para realizar la labor.
Se ha perdido temporalmente el énfasis en interconectar empresas y procesos, pero seguramente regresará.

El diluvio de datos actual ya es alto con los videos y fotografías capturadas desde dispositivos móviles conectados. El registro de los patrones de navegación de sitios web es otro formidable generador de datos. Esto va a empeorar con muchas de esas “cosas en Internet” que serán sensores de bajo costo. Algunos pacientes hoy ya tienen en su cuerpo sensores generando información para el mejor diagnóstico y tratamiento de enfermedades.

Moore continúa haciendo de las suyas. Hoy es posible adquirir 40 núcleos con 512Gb de RAM por menos de $50 mil dólares y en 18 meses las dimms de 32Gb habilitarán sistemas de 2Tb por menos de $150 mil dólares, que es el costo total promedio de un empleado para una empresa internacional.

El bajo IQ de la Inteligencia de Negocios

La inteligencia de negocios está limitada a los escenarios donde se conocen las preguntas a contestar y continuará siendo relevante en ambientes transaccionales. Sin embargo, la “BI” es limitada porque no es predictiva, social ni accesible a todos en cualquier dispositivo. Se estima que la información estructurada representa menos del 10% de la información que se está produciendo, por lo que hay que poner los ojos en el problema mayor.

Alquimia 2.0

La gran interrogante no es sobre el futuro de la infraestructura de Internet sino la posibilidad de entender y explorar la información. Se especula que esto es posible, pero de hecho hoy ni los gigantes de internet pueden articular las preguntas que desean contestar en forma clara. Lo asocio a la era en que los alquimistas querían transformar materiales en oro.

Si esto es cierto, la mercadotecnia se transformará en algo de mayor precisión y que dependa mucho de matemáticos y actuarios. Esto no es todo: en los puntos de acceso también hay transformación. Veamos un ejemplo a continuación ...

El fin de las apps

En junio de este año el Financial Times lanzó una nueva app para leer sus contenidos desde dispositivos iOS. La peculiaridad es que no es una app que se adquiere en el app store sino que simplemente es un sitio web en HTML5. La principal razón para esto fue evitar el control que Apple impone (30% de los ingresos de suscripciones, control de los datos de los usuarios). Se reportó que 100 mil de sus 224 mil suscriptores accedieron la aplicación la semana que se hizo disponible. En el mismo mes se corrió el rumor de que el proyecto Spartan de Facebook estaría basado en HTML5. Facebook está interesado en llegar directamente al consumidor, de hecho es necesario para generar un modelo de negocios con crecimiento a largo plazo. El “cara-libro” se encuentra en una posición estratégica para competir por la distribución de contenido contra la manzana. A la última le ha costado años generar 225 millones de cuentas con tarjetas de crédito registradas, ha tenido que hacer grandes inversiones en contenido e incluso incursionar en el hardware.

HTML5 puede ser un disruptor de la misma forma que la tienda de Apps lo ha sido en 3 años. Por supuesto, las aplicaciones nativas no desaparecerán por completi ni de forma inmediata, pero el futuro está en HTML5.

Nuevamente estamos viviendo en el borde de una importante trasformación tecnológica. Después de todo, quizá no haya una Burbuja 2.0

Bio

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

El Poder de las Ideas

Anonymous — Mon, 19 Sep 2011 21:43:04 +0000

El Poder de las Ideas Anonymous Mon, 09/19/2011 - 16:43

Publicado en

SG #33

Mejora continua

Autor

Luis Cuellar

He estado leyendo un fascinante libro titulado “The Lords of Strategy” de Walter Kiechel, el cual se adentra en la historia de la consultoría y sus diferentes protagonistas, lo recomiendo ampliamente.

En el libro se hace una afirmación que llamó mucho mi atención y ha cambiado mi perspectiva: “El mundo de la consultoría es un mundo de ideas”. ¿Simple y tal vez obvio, no? Puede ser, pero a veces las cosas simples tienen implicaciones trascendentes.

Incluso en mayor medida que el mundo de la consultoría, el mundo del software también es un mundo de ideas. Todo lo que construimos en una computadora no son más que bits de información que realmente no existen en un mundo físico. Y si es un mundo de ideas, entonces ¿qué hace que una idea sea mejor que otra? Muchas de las discusiones que tenemos a diario como: ¿qué metodología utilizamos?, ¿somos ágiles o estructurados?, ¿es más importante la ingeniería de software o la administración de proyectos? pretenden manejar ideas como si fueran verdades absolutas, como si existieran en realidad en lugar de ser simples puntos de vista.

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

Regresando a nuestro punto, para cada fase, para cada decisión, existe un sinnúmero de ideas en la industria que tomamos como verdades absolutas. “Desarrollo iterativo es la mejor forma de llevar a cabo un plan”, depende, desarrollo iterativo es excelente cuando el usuario no tiene claro qué es lo que quiere lograr. Pero esto complica el cobro de los servicios ya que los clientes no necesariamente están dispuestos a pagar por una entrega parcial o el desarrollo puede irse al infinito ya que siempre habrá algo que mejorarle al sistema. Otra discusión común es la de la importancia que tiene la ingeniería de software sobre la administración de proyectos. Después de todo, la ingeniería de software es lo que utilizamos para asegurar que entregamos un producto bien hecho, de acuerdo a lo especificado. Pero este argumento asume que el desarrollo de software es únicamente la creación de un producto, olvidando la parte del servicio. Imaginemos que compramos una computadora, la mejor del mundo, pero no sabemos cuando la vamos a recibir, el vendedor no sabe decirnos qué puede hacer ni cómo usarla, tampoco tenemos soporte si falla o queremos modificarla. ¿Qué es más importante, la calidad de la computadora o que llegue a tiempo y la podamos usar?

¿A dónde voy con todo esto?, la realidad es que en un mundo de ideas ninguna es mejor que otra, unas pueden ser más completas, mas escalables, más entendibles o más fáciles de vender, pero ninguna es por definición la mejor. Lo único que diferencia una idea de otra es nuestra habilidad de implementación.

La mejor idea es la mejor implementada; la forma de trabajo, organización o estructura cuya ejecución hace que realmente sobresalgamos como organización. No podemos hablar del mejor modelo de calidad sino del que nos parece más práctico, más compatible a nuestra organización, a nuestra cultura. No podemos enfocarnos en el proceso de análisis e ignorar el de peer review; cada proceso tiene su razón de ser y hasta no entender el lugar de cada práctica en nuestro proyecto no podemos juzgar un proceso más importante que otro. Una idea no existe hasta que se ejecuta, una idea que tú puedes ejecutar excelentemente no necesariamente es una idea que toda la organización pueda ejecutar excelentemente. Cada concepto e idea tiene su lugar su tiempo y su posibilidad de existencia. Como agentes de cambio nuestra labor es encontrar las ideas, tiempos y posibilidades que unan el esfuerzo de cada individuo y lo hacen funcionar mejor que la suma de sus partes.

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

Ya Nació ISO/IEC 29110 Perfil Básico

Anonymous — Mon, 19 Sep 2011 21:35:22 +0000

Ya Nació ISO/IEC 29110 Perfil Básico Anonymous Mon, 09/19/2011 - 16:35

Publicado en

SG #33

Tejiendo nuestra red

Autor

Hanna Oktaba

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

En octubre de 2006, el WG24 tomó la decisión de presentar MoProSoft como estandar internacional.

¿Qué es MoProSoft?

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

¿Por qué se definió MoProSoft?

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

¿Para quién es MoProSoft?

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

¿Quiénes lo crearon?

MoProSoft fue creado en 2002 a solicitud de la Secretaría de Economía en México dentro del PROSOFT por el grupo editor: Hanna Oktaba (Directora), Claudia Alquicira, Angélica Su, Alfonso Martínez, Gloria Quintanilla, Mara Ruvalcaba, Francisco López Lira, Ma. Elena Rivera, Ma. Julia Orozco, Yolanda Fernández y Miguel Flores.
Para completar la norma se necesitaba definir el método de evaluación basado en MoProSoft como modelo de procesos. Para tal fin se conjuntó otro equipo en 2003, que definió EvalProSoft (el método de Evaluación de Procesos de Software). Los miembros de este equipo fueron: Hanna Oktaba (Directora), Claudia Alquicira, Angélica Su, Carlos Pérez, Francisco López Lira, Jorge Palacios, Gloria Quintanilla, Cecilia Montero y Alfredo Calvo.

Al principio de 2004 ya se tenían los elementos básicos, el modelo de procesos y el método de evaluación, para empezar los trámites de normalización. Sin embargo faltaba un “detalle”, probar que MoProSoft y EvalProSoft sirven en la práctica. Así surgió el tercer proyecto (Pruebas Controladas) con cuatro empresas que tenían el perfil promedio (18 personas) de la industria de software. El objetivo fue demostrar que en un lapso de tiempo relativamente corto, las empresas pueden elevar sus niveles de capacidad. El equipo de trabajo fue conformado por: Hanna Oktaba (Directora), Claudia Alquicira, Angélica Su, Francisco López Lira, Jorge Palacios Elizalde, Ana Vázquez y Claudia Gutiérrez.

Los tres proyectos fueron financiados por la Secretaría de Economía a través de convenios con la UNAM.

Posteriormente los esfuerzos se centraron en convertir MoProSoft en una norma mexicana. Para ello se trabajó dentro del Subcomité de Software del NYCE y el resultado fue la norma MNX-I-059-NYCE-2005 con sus 4 partes:

Definición de conceptos y productos,
Requisitos de procesos (MoProSoft),
Guía de implantación de procesos y
Directrices para la evaluación (EvalProSoft).

Dichos documentos fueron redactados de forma voluntaria por Claudia Alquicira y una servidora. La norma entró en vigor el 15 de octubre de 2005.
Cabe destacar que la gran mayoría de las personas mencionadas fueron miembros de la extinta Asociación Mexicana para la Calidad en Ingeniería de Software (AMCIS). ¡Ay, como nos hace falta!

¿Cómo se distingue MoProSoft de modelos similares?

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

MoProSoft en Iboeroamérica

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

MoProSoft como estándar ISO/IEC

En 2005, ISO/IEC JTC 1 SC7 convocó a un grupo de trabajo (WG 24) para definir procesos de software para Very Small Enterprises (VSE), de 1 a 25 personas. Una de las primeras tareas del grupo fue averiguar si ya existía alguna propuesta dirigida a este sector. Se enteraron de MoProSoft e invitaron a México a presentarlo. Ana Vázquez hizo la presentación en la reunión del WG24 de mayo 2006 en Tailiandia, y en votación unánime los representantes decidieron tomar la norma mexicana como base para su trabajo.

En octubre de 2006, el WG 24 tomó la decisión estratégica de presentar MoProSoft como estándar internacional en tres “cómodas mensualidades”, es decir en grupos de procesos divididos por las tres capas del modelo. El primer perfil a trabajarse, llamado posteriormente Perfil Básico, correspondió a los procesos de Administración de Proyectos Específicos y de Desarrollo y Mantenimiento de Software de la capa de Operación.

El ISO/IEC 29110 (Software engineering — Lifecycle profiles for Very Small Entities) consta hasta ahora de las siguientes partes y documentos: 1) Overview, 2) Framework and taxonomy, 3) Assessment guide, 4-1) Profile Specifications: Generic profile group, 5-1-2): Management and engineering guide: Generic profile group: Basic profile.

El perfil básico está incluido como Parte 5-1-2, el 1 significa que pertenece al primer grupo de perfiles genéricos, basados en MoProSoft, y el 2 es su número consecutivo (se está terminando un perfil más elemental llamado Entry, que será el número 1 en este grupo).
El perfil básico se publicó en mayo de 2011 y para promover su uso se hizo disponible de forma gratuita en http://bit.ly/sg33r1. Las partes 2 y 4-1 también están publicadas pero tienen costo.

El perfil básico se recomienda para las organizaciones pequeñas que pueden ser empresas, departamentos o proyectos de hasta 25 personas. La Guía se aplica en proyectos de desarrollo de software ya sea internos o externos (subcontratados).

Diferencia entre Perfil Básico y MoProSoft

Quienes tienen implementado MoProSoft a nivel 2 están cubriendo prácticamente el perfil básico de ISO/IEC 29110. Este último, como está dirigido a prácticas de un proyecto de software aislado tiene algunas tareas que en MoProSoft se delegan a otros procesos. Por ejemplo, a falta de la base de conocimiento de la organización se propone el uso de un repositorio local del proyecto. Algunos productos de trabajo sufrieron modificaciones a raíz de los comentarios del grupo y su apego a otros estándares ISO ya existentes, pero en general se parecen mucho.

Las editoras de las partes 4-1 y 5-1-2 fueron Ana Vázquez, Blanca Gil, Claudia González y Hanna Oktaba.

En cuanto al trabajo subsecuente, como ya comenté se está preparando el Perfil Entry (una simplificación del perfil básico), Perfil Intermedio (que incluirá los procesos de Gestión de Procesos, Recursos y Proyectos), y el Perfil Avanzado con el proceso de Gestión de Negocio. Por supuesto, estos procesos sufrirán modificaciones con respecto a sus versiones originales debido a las lecciones aprendidas de su uso y las aportaciones de la comunidad internacional.

Además, a la comunidad de sistemas les gustó el trabajo que hemos hecho y están trabajando el Perfil Básico para desarrollo de Sistemas y Software. Los que trabajan el estándar de servicios también están viendo la necesidad de generar una versión para VSEs y los “agilistas” están clamando por la modalidad ágil del Perfil Básico. Así que habrá trabajo para rato.

Espero que estas preguntas y respuestas les ayuden a ubicar el nuevo estándar en su justa dimensión. De ninguna manera es una revolución en el área de procesos. Es una aportación mexicana a la forma en que se presentan las prácticas a los lectores.

Ni más, ni menos.

Bio

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

Complementando CMMi con TMMI: Analizando el retorno de la inversión

Anonymous — Mon, 19 Sep 2011 18:41:38 +0000

Complementando CMMi con TMMI: Analizando el retorno de la inversión Anonymous Mon, 09/19/2011 - 13:41

Publicado en

SG #33

Prueba de Software

Autor

Sandra Berenice Ruiz Eguino

A propósito del fuerte impulso a la capacitación y certificación de organizaciones e individuos en nuestro país, vale la pena poner en perspectiva los logros obtenidos, por ejemplo, en áreas de mejora de procesos de software, donde la meta es alcanzar cierto nivel de madurez ya sea en Moprosoft o CMMI.

En el caso de éste último, abundaremos particularmente sobre algunos elementos que apoyarían en el análisis del retorno de la inversión, desde el punto de vista de las pruebas, a través de la aplicación de un proceso basado en algún Modelo Especializado en Pruebas como TMMi (Test Maturity Model integration), el cual podría visualizarse como una opción natural para cubrir principalmente las áreas de Validación y Verificación contempladas en el nivel 3 de CMMI.

Recordando que en Diciembre del 2010 se liberó finalmente la versión 3.1, versión ya completa, de TMMi es muy reciente su liberación y por ende las empresas no podían certificarse en TMMi, pues al no estar completamente definido (faltaban por desarrollar los niveles 4 y 5), tampoco existía un proceso formal para realizar assessments. Sin embargo esas posibilidades están cada vez más cerca.

Para aquellas organizaciones que han optado por buscar la mejora de sus procesos de prueba basándose en TMMi, les hago énfasis en la importancia de que luego de realizar un assessment, un consultor los ayude a trazar un plan de mejora tomando en consideración no sólo aspectos técnicos sino también el retorno de la inversión que ese plan requerirá. Esto hará más rentable y viable el esfuerzo de mejora de procesos.

Aún cuando TMM (Testing Maturity Model) ha sido su principal fuente, TMMi se basa además en aspectos de CMMI y en estándares internacionales tal como el de la IEEE[3], entre otras fuentes, incluso una parte importante de la terminología de pruebas empleada se basa en el ISTQB.

Como ya hemos comentado anteriormente, el modelo TMMi se basa en una estructura de 5 niveles que son:

Inicial. No existe como tal un proceso definido para pruebas, éstas son concebidas como parte del debugging. La organización no cuenta con un entorno estable para el soporte de los procesos.

Administrado. Las pruebas se convierten en un proceso administrado y claramente independiente del debugging. Considera las siguientes áreas clave: políticas y estrategia de prueba, planeación de prueba, monitoreo y control de prueba, diseño y ejecución de prueba, ambiente de prueba.

Definido. Las pruebas se encuentran totalmente integradas en el ciclo de vida de desarrollo del software, dejando de representar una fase aislada posterior a la codificación. Considera: organización de prueba, programa de entrenamiento para prueba, ciclo de vida de prueba, prueba no funcional, revisiones de pares (peer review).

Medido. En este nivel, las pruebas ya son un proceso perfectamente definido y medible. Aquí entran áreas como: medición de prueba, evaluación de la calidad del software y revisiones de pares avanzada.

Optimizado. La organización es capaz de llevar un control sistemático de costos y efectividad del proceso de pruebas, es capaz de continuar mejorando sus procesos. Se apoya en áreas como prevención de defectos, optimización del proceso de prueba, y control de calidad.

La relación de TMMi con CMMI hace a este modelo especializado en pruebas especialmente interesante para aquellas empresas que cuentan con cierto nivel de madurez en CMMI y que desean ya sea subcontratar las pruebas o bien, implantar su propio proceso basados en TMMi.

Como bien sabemos, entre algunas de las áreas de proceso que habría que implantar para alcanzar por ejemplo, el nivel 3 de CMMI, se encuentran primordialmente la de Verificación y la de Validación, (e incluso la de Integración de Producto), las cuales podrían alcanzarse mediante el desarrollo de un proceso basado en algún Modelo Especializado en Pruebas, como TMMi, el cual a su vez debiera contemplar la definición de métricas de producto.

Estas métricas que se obtienen de las pruebas pueden ser de gran utilidad para medir el retorno de la inversión (trátese de la inversión hecha para implantar tanto un modelo de mejora de desarrollo o uno especializado en pruebas). Es decir, podemos contar con elementos que nos lleven a definir cuánto tiempo nos llevará recuperar lo invertido en mejorar nuestros procesos de desarrollo. Para ello debemos conocer:

¿Cómo estamos?
¿Qué tanto nos cuesta hacer las cosas como las hemos venido haciendo?
¿Qué problemas tenemos y cuánto tiempo y costo nos implica resolverlos?
¿Cuánto esfuerzo hay que aplicar para corregir problemas (re-trabajo)?
¿Quienes cometen más errores?
¿Cuánta capacitación necesitamos para mejorar?

Por otro lado, como resultado de la evaluación de varios productos de software que realizamos durante los concursos llevados a cabo en 2007 y 2008 sobre productos de software mexicanos, mostramos en ediciones anteriores, cómo el no probar adecuadamente incrementa los costos de mantenimiento, lo cual a su vez merma las utilidades y dificulta la inversión en otros rubros estratégicos para las organizaciones.

Es importante por lo tanto, poner especial énfasis en las métricas de pruebas, de manera que podamos realizar las actividades necesarias para bajar costos, mejorar la productividad, mejorar la calidad del software y los procesos que permitieron desarrollarlo, asegurando así un notorio retorno de la inversión en el corto plazo.

Algunos ejemplos de métricas de pruebas que pudieran ser de utilidad son:

Cantidad de defectos potenciales.

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

Densidad de defectos

Densidad = Cantidad de defectos / tamaño del software (ya sea que se mida en líneas de código, puntos de función, etc.)

Cantidad de defectos removidos

Por etapa en la que fueron removidos- antes o después de las pruebas, durante el deployment, etc.
Por causa raíz (código, base de batos, ambiente, datos de prueba, etc.)
Eficiencia en la remoción de defectos
Tasa de remoción de defectos por desarrollador/por período
Tasa de remoción de defectos por ciclo de prueba
Tiempos de respuesta en la corrección de defectos
Cantidad de defectos por severidad (1. Muy Alta, 2.Alta, 3.Media, 4.Baja, 5.Mejora)
Cantidad de defectos por desarrollador
Cantidad de defectos pospuestos

Comportamiento del producto comparando resultados de pruebas regresivas y progresivas

Esfuerzo empleado en remoción de defectos y costos asociados (correcciones, re-trabajo, análisis de defectos, etc.)
Cantidad y costo de errores que pasan a producción
Ahorros estimados en mantenimiento

Una expectativa natural al implantar un modelo como CMMI, es que permita mejorar el proceso de desarrollo, y que implícitamente mejore además la calidad del producto. Sin embargo, aún cuando esto pareciera tener cierta lógica, no siempre ocurre así. Quizás en buena medida porque el principal objetivo oculto que ciertas organizaciones persiguen, no se focaliza en obtener una mejora como tal de sus procesos, sino simplemente en obtener mejores credenciales para vender. Lo cual no es precisamente malo, pero sí nos debiera llevar a evaluar qué tan bien estamos aplicando nuestras estrategias corporativas, en relación a lo que buscamos en el mediano y largo plazo.

Por lo anterior, se esperaría entonces que la aplicación sistemática de un Modelo de Calidad Especializado en Pruebas, contribuya en alto grado a la mejora de calidad de un producto de software; y si este modelo de pruebas (TMMi) a su vez es uno que contiene áreas y prácticas alineadas a las manejadas por el modelo de desarrollo que nosotros o nuestros clientes hemos adoptado (CMMI), nos allanará el camino, incluso aún cuando se trate de la aplicación de algún proceso de pruebas basado en su modelo predecesor TMM, o hasta en algún otro modelo de pruebas que maneje áreas semejantes.

Bio

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. A lo largo de su trayectoria profesional ha actuado como Ingeniero de Pruebas Senior, Líder de Proyectos, Administradora de Proyectos nacionales e internacionales, y Directora de Operaciones. Ha sido profesora de la Universidad Autónoma de Guadalajara, donde realizó sus estudios de Maestría en Ciencias Computacionales.

Ágil: ¿Cómo innovar colaborativamente?

Anonymous — Mon, 19 Sep 2011 18:40:52 +0000

Ágil: ¿Cómo innovar colaborativamente? Anonymous Mon, 09/19/2011 - 13:40

Publicado en

SG #33

Agilidad

Autor

Gustavo Quiroz

Tradicionalmente se ha considerado a la creatividad y la innovación como características o actividades primordialmente individuales. Sin embargo, existe una cantidad interesante de evidencia que nos demuestra que, en realidad, muchas de las producciones artísticas y científicas que vemos en la actualidad son el resultado de un esfuerzo que se apoya en la interacción de diversos agentes, los cuales intercambian fluidamente información y conocimiento para crear cosas tales como: una canción, una novela, una nueva teoría científica o todo un movimiento artístico.

En el libro Artful Making, de Lee Devin y Robert Austin, se presenta una serie de principios y casos reales que pueden ayudar a comprender mejor este escenario dentro un contexto empresarial. El año pasado, Lee Devin dictó una conferencia en nuestro país (Perú) [2] y nos brindó su visión sobre cómo crear una cultura de innovación sostenible y que funcione.

El modelo teatral

Devin parte del ejemplo de cómo un elenco de actores gesta una obra de teatro y lo utiliza de modelo para ilustrar cómo funciona el proceso innovador dentro del contexto de un equipo.

Una compañía teatral crea un nuevo producto, es decir la obra, y lo comienza a vender anticipadamene. Dicho de otra forma, consigue financiamiento y vende entradas antes de la fecha de estreno. Quizás lo que resulta más interesante es que logra vender el producto antes de que esté terminado y nadie sepa exactamente cómo va a ser. Y también es interesante que, en la gran mayoría de casos, se logre terminar el producto a tiempo y dentro del presupuesto para presentarlo durante la noche del estreno.

Toda obra se basa en un guión. Sin embargo, cada representación posee características únicas que la hacen distinta de todas las anteriores. Una puesta en escena de Hamlet en Lima en el año 2011 es distinta de una puesta en escena en la misma ciudad en el 2008 y también es distinta de una en Buenos Aires en el mismo año, de una en Nueva York en el 2005 y, por supuesto, de todas las anteriores puestas en escena de Hamlet desde hace más de 400 años.

La razón de esto se basa en el proceso artístico de construcción de la obra basado en los ensayos que realiza el elenco. Si bien cada actor debe llegar debidamente preparado al ensayo, es durante el mismo que se producen interacciones impredecibles que desafían cualquier concepción previa por parte de los actores o del director. Un actor debe pues estar preparado para responder a estas interacciones, aunque esto implique, inevitablemente, desechar ideas y planes sobre cómo debería interpretarse tal o cual personaje.

La obra puede verse, entonces, como el resultado emergente de un proceso iterativo y colaborativo ejecutado por los actores con la supervisión del director. Son precisamente estas características (producto emergente, iteración y colaboración) las que forman parte de cualquier proceso innovador ejecutado en equipo.
¿Y cómo trasladamos estos conceptos a un entorno empresarial? Para entenderlo, examinemos primero las cualidades esenciales que deben estar presentes en una cultura que fomente la innovación, las cuales forman parte integral de la perspectiva de los actores y artistas respecto a su trabajo.

Cualidades esenciales

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

La tercer cualidad es reconocer y celebrar la diferencia entre problemas y dificultades. Un problema se resuelve y entonces termina. Tiene límites definidos. Las dificultades, por el contrario, no se resuelven. Debemos enfrentarlas continuamente. Si tratamos una dificultad como problema, malentendiendo su naturaleza, nuestras estrategias y tácticas serán inadecuadas y albergaremos sentimientos de futilidad y fracaso por la falta de progreso. Justamente, una consecuencia provechosa de emplear el enfoque de las dificultades es minimizar la amenaza del fracaso. La sensación de fracaso nos paraliza y nos impide innovar pues, para hacerlo, requerimos cometer errores y aprender de ellos.

Otra cualidad es emplear la imaginación como herramienta. En muchos entornos se considera a la imaginación como desbocada y poco confiable. Para los artistas, sin embargo, es esencial. Una cultura de innovación privilegia la imaginación. Es decir, encuentra maneras de alimentarla y protegerla. Es conocido que varias de las empresas más innovadoras permiten un tiempo específico para proyectos que no tienen aplicación directa o valor comercial, como es el caso de Google.

La quinta y última cualidad es la consideración del trabajo como valioso y digno de hacerse en sí mismo. Esto debe asumirse como una decisión consciente y no cómo una característica variable según el tipo de trabajo. Es decir, para innovar debemos concentrar nuestra atención en el proceso, en el propio acto creativo en lugar de en el producto o destino final. Esta también es una característica distintiva de los grandes artistas. No les importa la fama, el dinero o lo que pensamos de ellos. Les interesa su trabajo y hacerlo bien. Incluso, si alguno de sus trabajos es percibido como fallido por el público, están convencidos de que valió la pena hacerlo y de que influirá todo trabajo posterior.

Caso: Moonshine en Boeing

Veamos, a continuación, un caso que muestra cómo se plasman algunas de estas cualidades en la práctica.

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

Boeing escogió alrededor de 30 de sus mejores trabajadores para conformar el grupo. Ellos recibieron considerable autonomía para desenvolverse, no tenían un lugar formal en el organigrama ni un espacio dedicado, podían recorrer la planta de ensamblaje, hablar con cualquier persona y revisar cualquier proceso para encontrar cosas que mejorar. Su método era el siguiente: ante cualquier problema o situación, proponer siete diferentes soluciones, sin preocuparse por la factibilidad o los recursos disponibles. Esto, por supuesto, requería deshacerse del miedo al fracaso.

Al principio, nadie sabía que pensar de este grupo de “locos” y eran vistos con recelo. Su primer gran desafío fue enfrentarse al problema de cargar y fijar los asientos en una nueva línea de montaje. El método existente para cargar y fijar una fila de asientos para pasajeros en un avión requería 2 turnos completos de 16 personas cada uno, 256 horas-hombre en total.

El grupo decidió salir de la planta a buscar cosas que les pudieran ser útiles. Uno de lo miembros encontró un cargador de heno en un corral y le pareció que algo así podría funcionar así que convenció al granjero para que le construyera uno de acuerdo a sus especificaciones. Realizó algunos ajustes y le agregó un motor que encontró en un sótano. Al día siguiente lo llevaron a la planta para mostrarlo. La burla inicial por parte de los trabajadores se convirtió en interés al comprobar que funcionaba. Les tomó dos años refinar el dispositivo, pero cuando terminaron el tiempo de instalación de una fila de asientos era de 30 minutos y sólo requería de 4 personas. Es decir, 2 horas-hombre en lugar de 256, lo cual representó millones de dólares de ahorro anual. Posteriormente esta mejora se aplicó en la línea de ensamble de otros aviones de Boeing, y moonshine ha contribuido a diversas mejoras en la empresa.

Bio

Gustavo Quiroz es consultor y director en Open Edge Technologies, empresa basada en Lima, Perú. Gustavo ha dedicado los últimos 4 años de su carrera a dirigir y asesorar equipos ágiles en algunos de los corporativos más importantes del Perú. gustavo@openedgetech.com

El Rol del Arquitecto de Software

Anonymous — Mon, 29 Aug 2011 21:40:07 +0000

El Rol del Arquitecto de Software Anonymous Mon, 08/29/2011 - 16:40

Publicado en

SG #33

Arquitectura

Autor

Humberto Cervantes

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

Actividades del arquitecto

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

Requerimientos. Durante la fase de requerimientos, el arquitecto de software se involucra con los requerimientos que influyen en la arquitectura (“drivers”) y particularmente con respecto a los atributos de calidad del sistema. El arquitecto debe preocuparse por que se identifiquen atributos de calidad pertinentes para el sistema (alineados a los objetivos de negocio) y que las métricas asociadas estén justificadas. En caso de que el cliente solicite atributos de calidad con métricas muy demandantes (por ejemplo una disponibilidad del 99.99%) debe ser capaz de entender la justificación de esas métricas y, en caso necesario, debe poder negociar con el cliente para establecer métricas adecuadas. Nuevamente, el arquitecto debe emplear aquí una combinación de habilidades “duras” y “suaves” con el fin de lograr una identificación adecuada de los requerimientos que influirán sobre el diseño arquitectónico.

Diseño del sistema. La etapa de diseño del sistema es aquella donde el arquitecto de software juega el papel principal, particularmente al momento de diseñar la arquitectura. Aquí el arquitecto debe hacer uso de todas sus habilidades técnicas con el fin de establecer una solución técnica pertinente que satisfaga, en la medida de lo posible, los requerimientos que influyen en la arquitectura (ver Figura 1. La realización del diseño requiere de muchos conocimientos técnicos.

Durante la etapa de diseño, el arquitecto debe también hacer uso de muchas habilidades no-técnicas. La comunicación durante esta etapa es fundamental, ya que el arquitecto debe ser capaz de comunicar el diseño, y las decisiones que lo llevaron al mismo, ya sea de forma escrita, como parte de la documentación de la arquitectura, o bien de forma oral al explicar el diseño de la arquitectura al equipo de desarrollo. Durante la evaluación del diseño de la arquitectura, el arquitecto debe ser capaz de presentar el contexto del problema y el diseño de la arquitectura al comité de evaluación, y debe ser capaz de responder a las preguntas de dicho comité, o bien de aceptar las observaciones que se hacen al diseño.

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

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

Categorías de arquitectos

Dependiendo del tamaño del sistema, es posible que no haya un solo arquitecto que participe a lo largo de todo el proyecto y que, más bien, existan distintos arquitectos especializados que intervienen a distintos momentos del desarrollo. Así, frecuentemente, el arquitecto que participa en la concepción de un proyecto es conocido como el “Arquitecto de Soluciones” mientras que el arquitecto que participa durante el desarrollo es conocido como el “Arquitecto de Software”. Pueden haber otras especializaciones tales como el “Arquitecto de Sistemas”, que se encarga de tomar decisiones de diseño que van más allá del software y que involucran hardware, o bien el “Arquitecto Empresarial” que, como su nombre indica, se especializa en el diseño de una arquitectura empresarial. Existen también ciertas especializaciones a nivel tecnológico, como por ejemplo el “Arquitecto SOA”. Cualquiera que sea la especialidad del arquitecto, en general, un aspecto común es que su rol involucra la toma de decisiones que tienen un fuerte impacto sobre el sistema.

Conclusión

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

Frecuentemente se considera que el rol de arquitecto de software es un rol extremadamente técnico y que personas que son muy buenas para la tecnología automáticamente pueden ocupar este papel. La realidad es que el rol de arquitecto de software es un rol complejo que requiere de una combinación equilibrada de habilidades técnicas y no-técnicas que son indispensables en las distintas etapas del desarrollo de un sistema.

Bio

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

Paquetes de Puesta en Operación ISO/IEC 29110

Anonymous — Thu, 25 Aug 2011 21:07:50 +0000

Paquetes de Puesta en Operación ISO/IEC 29110 Anonymous Thu, 08/25/2011 - 16:07

Publicado en

SG #33

Procesos de desarrollo de software

Autor

Erick Serratos

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

¿Para qué definir DPs?

Un Paquete de Puesta en Operación (DP, Deployment Package) es un conjunto de artefactos que son propuestos para facilitar la implementación o puesta en operación de un conjunto de prácticas. Es importante aclarar que un DP no es una norma ni un modelo de procesos, simplemente son artefactos de soporte o guía. Los elementos típicos de un DP son: descripción de la parte del proceso que se pretende implantar, actividades a realizar, referencias a normas y modelos reconocidos, plantillas, listas de verificación, ejemplos, material de soporte y una lista de herramientas.

El proyecto de definición de DPs tiene los siguientes objetivos:

Desarrollar DPs que faciliten la adopción de la Norma ISO/IEC 29110, en particular para las actividades de arquitectura de software y diseño detallado.
Incorporar en estos DPs los métodos y herramientas propuestos por el Software Engineering Institute (SEI) para la arquitectura de software y diseño detallado.
Probar los DPs en pequeñas organizaciones de desarrollo de software.

Para este trabajo se analizó el contenido de la Norma ISO/IEC 29110 así como los métodos que propone el SEI para el ciclo de vida de la arquitectura de software, tales como: QAW (Quality Attribute Workshop), ADD (Attribute Driven Design), V&B (Views and Beyond), ARID (Active Reviews for Intermetidate Designs) y ATAM (Architecture Tradeoff Analysis Method). En este análisis se verificó que los métodos del SEI cumplieran con las actividades de Arquitectura de Software y Diseño Detallado del ISO/IEC 29110.

Como resultado, se han generado dos Paquetes de Puesta en Operación cuyo método concluye hasta que se logra una arquitectura que satisface los principales requerimientos de atributos de calidad. Se decidió complementar los DP con plantillas, ejemplos sencillos, listas de verificación y autoevaluación, una lista de herramientas y matrices de cobertura con las normas ISO/IEC 29110, ISO/IEC 12207, ISO 9001-2000 y el modelo CMMI. Cabe señalar que se puso especial atención en la redacción de tal manera que sean fáciles de entender.

En ambas guías, se indican las tareas que hay que realizar, para cada una se plantea: el objetivo, fundamento para realizarla, rol principal involucrado, artefactos producidos, pasos que la componen con su descripción detallada y una nota adicional que ofrece sugerencias, recomendaciones, información adicional o bibliografía útil.
Algunos beneficios que pueden esperar las organizaciones que utilicen los DPs son:

Facilitar el diseño, documentación y evaluación de la arquitectura de software en su organización.
Incrementar la productividad y competitividad de su organización.
Incrementar la confianza y satisfacción del cliente.
Ayudar y acelerar la adopción de buenas prácticas de normas internacionales.
Acercar a la organización a una certificación o evaluación por el uso de normas internacionales.
Reconocimiento por desarrollar productos de alta calidad.

Los DP ya fueron probados dando como resultado la identificación de los principales requerimientos de atributos de calidad y un diseño arquitectónico que satisface dichos requerimientos. De esta manera se puede ofrecer un producto de software de alta calidad pues satisface los requerimientos que los clientes precisaron importantes para ellos.

Como trabajo a futuro se considerará la posibilidad de aplicar los DPs en pequeñas empresas de desarrollo de software. También se verá la posibilidad de poder publicar los DPs aquí mencionados, en un repositorio dedicado a DPs para todas las etapas del desarrollo de software. Finalmente se buscará traducir al inglés dichos DPs para que puedan ser publicados como reportes técnicos ISO/IEC.

Si estás interesado en participar en este proyecto y aplicar los DPs en tu organización, por favor comunícate con los involucrados: Lic. Erick Serratos Álvarez (prop@xanum.uam.mx), Mtro. Alfonso Martínez Martínez (almm@xanum.uam.mx), Dra. Hanna Oktaba (ho@fciencias.unam.mx).

Bio

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