Llegamos a ustedes gracias a:



Reportajes y análisis

Insensatez 3.0

SEPG 2011 Latin América en Perú

[08/11/2011] Recientemente se produjo la reunión de la cual habíamos hablado ya hace un tiempo. Fueron dos días en los que se reunieron diversos expertos del mundo de la ingeniería del software para conversar sobre diversos tópicos de su industria.
De esas dos jornadas tomamos un par de presentaciones pertenecientes al segundo día -el primero fue dedicado a los Seminarios Tutoriales- que nos dieron luces, en general, sobre cómo se ha desarrollado hasta el momento el mercado de la ingeniería de software, y cómo éste se integra con una tendencias bastante actual, la cloud computing.
La reunión, que se llevó a cabo en el auditorio de la Sociedad Nacional de Industrias (SNI), fue bastante nutrida e interesante, y comenzó con una crítica al actual modelo de creación de software. La mañana se mostraba bastante auspiciosa.
El título de nuestro artículo
Tan solo bastaba con leer el título para sentir mucha curiosidad con respecto a la primera exposición. Jorge Aramburo, CEO de la firma de desarrollo de software PSL de Colombia, llamó nuestra atención con respecto a cómo se desarrolla el software en la actualidad, y las críticas que levanta esta práctica.
Sin duda, el título de Insensatez nos daba una buena pista con respecto a la opinión que tiene Aramburo y no nos equivocamos. Es más, nos proporcionó argumentos bastante sólidos como para demoler cualquier defensa del modelo mayoritariamente utilizado en la actualidad en la industria del software. Su exposición fue bastante clara y contundente.
¿Por qué se hace el software como se hace en la actualidad? Es decir, sujeto a cronogramas y, sobre todo, a un precio fijo. La explicación que dio Aramburo es que todo se remonta a los años setenta, década en la cual grandes compañías como GE, AT&T, Hitachi, y otras, impulsaron la adopción de las técnicas de manufactura tradicional a la producción de software, de ahí que con el tiempo también se adoptara el nombre de fábricas de software.
Posteriormente, el Software Engineering Institute (SEI), el modelo CMM, CMMI y muchos lead assessors, terminaron de posicionar aún más esta ingeniería tradicional.
El CMM fue desarrollado para cumplir las exigencias del Departamento de Defensa de Estados Unidos en proyectos a precio fijo, de alta complejidad y altísimo riesgo, para desarrollar el componente de software de sistemas mayores, sostuvo Aramburo.
Luego los lead assessors fueron educados para proceder de acuerdo con el modelo; es decir, de acuerdo con las exigencias del Departamento de Defensa. Las prácticas sugeridas se convirtieron en obligatorias y las áreas de proceso en procesos. Además el SEI también permitió que el CMM y el CMMI, incorrectamente aplicados, se difundieran.
Aramburo también identifica a otros influenciadores que ayudaron a que se cimentara este modelo. Las normas ISO 9000, especialmente en Europa y América Latina, ayudaron en este sentido; mientras que por otra parte el cuerpo de conocimientos del PMI (Project Management Institute) ha contribuido a que se trate el desarrollo de software como un proyecto predecible.
Solo el SEI, a finales del 2008, comenzó a prestarle atención a las aproximaciones ágiles de desarrollo de software, y recién en octubre del 2010, en la versión 1.3 de esta organización se incorporan estas aproximaciones.
Desde el lado de los compradores algo similar ha ocurrido. Como señala Aramburo, con pocas excepciones, el comprador latinoamericano acude al mercado de desarrollo de software con RFP (request for proposal) con requerimientos de alto nivel.
En ocasiones son elaborados pero nunca completos y no contienen realmente lo que el cliente necesita, sostuvo el expositor.
En estas condiciones se exigen precios y costos fijos por adelantado, e incluso desagregados del proyecto a nivel de fase, etapa, persona, horas, valor, etcétera.
Por supuesto, casi todo RFP serio a precio fijo viene acompañado de una serie de absurdos y de multas, agregó Aramburo.
Las razones para comprar de esta forma son varias, pero el expositor sostuvo que principalmente se debe a que, por décadas, la ingeniería de software tradicional aconsejó desarrollar requerimientos y diseños por adelantado, al igual que planes formales predictivos con compromisos de costo y tiempo.
Esto obviamente ayuda a la empresa a tener la sensación de un presupuesto controlado, además ayuda en la selección del proveedor pues así se pueden comparar precios.
Pero ¿qué se pierde trabajando así?
Aramburo mostró un cuadro del Chaos Report del Standish Group en el que puede ver que hasta un 45% de los requerimientos desarrollados no se utilizan nunca. Otro 19% se utilizan raras veces y otro grupo de 16% algunas veces. Solo el 13% se utilizan a menudo, y 7% siempre.
Así se pierde una gran parte del software desarrollado, se incrementa el tiempo y costo del desarrollo, se entrega el software contratado pero no el que se necesita, y se generan relaciones conflictivas.
Ante los problemas que causa el actual modelo de creación de software, Aramburo propone el modelo sustentado en el SEMAT (Software Engineering Method and Theory). Este enfoque propone la refundación de la ingeniería de software en base a una teoría sólida, principios probados y buenas prácticas.
Entre las buenas prácticas se incluye el establecimiento de un kernel de elementos, ampliamente aceptados, pero extensible para usos específicos; la inclusión tanto de temas tecnológicos como aquellos de las personas; el soporte por parte de la industria, la academia, los investigadores y los usuarios.
A mi juicio, tras la iniciativa SEMAT existen además un mea culpa de quienes contribuyeron al estado actual de la ingeniería de software y las aproximaciones tradicionales; y una aceptación de los enfoques básicos de las aproximaciones ágiles. Si bien existen en ellas cosas que es necesario tomar con precaución, en general, han sido un paso muy grande en la evolución del desarrollo de software, sostuvo el expositor.
¿Qué ha aprendido Aramburo con respecto al desarrollo de software? Que en la generalidad de los casos, el negocio se encuentra repleto de negociaciones absurdas que en muchos casos son imposibles de cumplir y que, aunque aparentemente satisfacen la necesidad del cliente, terminan ocasionando el resultado contrario.
Por ello, las aproximaciones al desarrollo de software que se utilicen en el futuro serán una variante de las aproximaciones ágiles.
Inclusive los creadores de métodos tradicionales y formales como el Departamento de Defensa, IBM y muchos otros, han adoptado paradigmas nuevos, mucho más ágiles, señaló Aramburo.
Finalmente, aconsejó a las empresas dedicadas al desarrollo de software, aprender a lidiar con clientes conflictivos, irrazonables y mal preparados.
Es necesario aprender a decir no a tiempo, no acepten proyectos que saben que van a ser un problema, indicó.
La arquitectura de la nube
Otra de las exposiciones de aquella mañana fue la que realizó Grace Lewis, del SEI, en torno a la arquitectura de software y las implicaciones para el proceso de desarrollo de software.
Lewis sostuvo, luego de recordarnos los conceptos básicos de la computación en la nube, que existen decisiones en el diseño de la nube, dependiendo de la forma que ella adopte para nosotros.
En el caso de la IaaS (Infrastructure as a Service) señaló que hay una serie de cuestionamiento que debemos hacernos al momento de pensar en el diseño. El primero de ellos tiene que ver con los mecanismos de comunicación que se tendrán entre el consumidor y el recurso cloud, ¿cuáles serán? De ello dependerá que la infraestructura funcione correctamente.
Otro de los cuestionamientos tiene que ver con el tipo de computación que se realizará en la nube. ¿Será una aplicación completa o solo una funcionalidad? También es necesario pensar en los mecanismos que se tendrán para detectar y comunicar las fallas que se presenten en el recurso de nube, es decir, como se monitorean los parámetros del SLA.
Finalmente, en el caso de la IaaS, es necesario determinar qué tipos de datos se encontrarán almacenados en la nube y si estos se sincronizarán con otros conjuntos de datos, algo esencial desde el punto de vista de la seguridad.
En el caso del PaaS, Lewis sostuvo que también se tienen algunas preguntas que se deben responder al realizar el diseño. La primera de ellas es bastante simple: ¿dónde se autentican los usuarios externos? Parece una pregunta frívola pero al plantearla con seguridad generará más de una inquietud.
Igualmente, Lewis sostuvo que es necesario preguntarse qué datos serán manejados por las aplicaciones de nube.
¿Es posible que la aplicación ejecute en la nube y los datos permanezcan locales?, se preguntó la presentadora, ofreciendo una alternativa que ayudaría en la seguridad de la nube.
También hizo hincapié en que es necesario determinar si todos los elementos del sistema son compatibles con la plataforma de nube, o si se requiere de adaptadores.
¿Cuáles son las implicancias de estas preguntas para la arquitectura de software?
La arquitectura de software es esencial para poder empezar a razonar sobre atributos de calidad al inicio del ciclo de vida. En los sistemas de nube, el diseño y la arquitectura deben implementar aquellos atributos de calidad importantes sobre los cuales no hay control completo, sostuvo la expositora.
En general, existen dos premisas fundamentales. La primera nos dice que es imposible controlar todos los elementos del sistema, la segunda nos indica que los recursos de nube son servicios, y deben ser adquiridos y administrados como tales.
Si bien es cierto que no se puede controlar totalmente los elementos de un sistema, existen ciertas prácticas que nos pueden ayudar. Una de ellas es realizar el monitoreo en los tiempos de ejecución. No se puede controlar el comportamiento del sistema, pero al menos sí se le puede establecer límites. Otra práctica es realizar una programación defensiva.
Un ejemplo que dio Lewis para mostrar la utilidad de estas prácticas es Netflix. Este portal que hace streaming de películas estableció que si, por ejemplo, su sistema de búsquedas se caía, ello no ocasionaría que el streaming de películas se detuviera. Es más, si no funciona su sistema de búsquedas, el portal le presenta a uno las películas más recientes, o más votadas o más comentadas, pero ofrecía algo, no se detenía simplemente en señalar que un servicio no se encontraba operativo.
Netflix incluso estableció como política que, pase lo que pase, nunca se caería el sistema de streaming, todos los servicios pueden caerse pero no éste. Y para probar la fortaleza de su arquitectura, de los límites establecidos y de su programación defensiva, creó un programa denominado Chaos Monkey. Éste se encarga de matar instancias y servidores dentro de la arquitectura de la nube y observar cómo responde el sistema.
Para la segunda premisa -el manejo de los servicios- Lewis indicó que lo mejor que se puede hacer es proteger la relación mediante un acuerdo de nivel de servicio (SLA, por sus siglas en inglés).
Como forma de concluir, Lewis sostuvo que la nube es en esencia un modelo económico, una manera diferente de adquirir y administrar recursos TI.
Lo que aprendamos sobre la nube ahora nos va a preparar para el Internet de servicios del futuro; es decir, nos preparará para manejar la imposibilidad de tener todo bajo control, finalizó la expositora.
Jose Antonio Trujillo, CIO Perú