Camino hacia la calidad superlativa - Marcelo Corpucci

Camino hacia la Calidad Superlativa

La ingeniería de Software posee un rol protagónico dentro del circuito productivo de las compañías. Lo que implica que el software, como producto, debe estar a la altura de las más altas exigencias del negocio. A continuación reflexionamos sobre cómo, a través de la historia, los distintos modelos de Calidad buscaron satisfacer estas exigencias.

www.globallogic.com.ar

Marcelo Corpucci, QA Practice Leader

Buenos Aires, Argentina

Camino hacia la calidad superlativa

Marcelo Corpucci QA Practice Leader Buenos Aires, Argentina

La ingeniería de Software posee un rol protagónico dentro del circuito productivo de las compañías. Lo que implica que el software, como producto, debe estar a la altura de las más altas exigencias del negocio. A continuación reflexionamos sobre cómo, a través de la historia, los distintos modelos de Calidad buscaron satisfacer estas exigencias.

www.globallogic.com.ar

Camino hacia la calidad superlativa Marcelo Corpucci, QA Practice Leader

GlobalLogic Inc. www.globallogic.com.ar

ÍndiceIntroducción ...........................................................................................................................................................................................

Modelo de calidad tradicionalista....................................................................................................................................................

Nada es permanente a excepción del cambio..............................................................................................................................

Modelo de calidad ágil .........................................................................................................................................................................

Algunas conclusiones..........................................................................................................................................................................

Notas .........................................................................................................................................................................................................

Bibliografía...............................................................................................................................................................................................

3

3

4

5

6

6

7



Introducción

En la actualidad el Software, como producto, se ha transformado en un elemento crítico para la concreción de cualquier objetivo de negocio. Compañías de todos los rubros apuntalan la totalidad de sus procedimientos en el uso de aplicaciones informáticas. Lo cual, posiciona a estas últimas como un elemento transversal a todo el mapa de los procesos corporativos. Hablamos de sistemas de misión crítica, ya que sin ellos sencillamente no es posible operar.

Estas exigencias, inherentes a la necesidades actuales, presionan al Software a cumplir estándares de Calidad cada vez más altos. Requieren que el Software tenga un nivel superlativo de Calidad.

Ocurre que el nivel de criticidad ya descrito es tan alto como los riesgos de potenciales fallas. Entonces, si bien la eficiencia de los sistemas de informáticos es cada vez mayor, cuando los mismos colapsan el impacto lo es en la misma medida.

Por ejemplo, un pequeño error de cálculo dentro en cualquier sistema bancario puede desencadenar cuantiosas pérdidas económicas[1]. En otros casos, los defectos de Software pueden provocar daños a la vida humana[2].

Históricamente, organizaciones de toda índole (compañías, universidades, investigadores, etc) han buscado modelar distintos principios y prácticas que permitan asegurar que el Software cumpla eficientemente con su propósito. Llamémosle a esto modelo de Calidad.

En este artículo nos proponemos repasar (y comparar, sobre todo) distintos modelos de Calidad de Software.

Para empezar, podemos decir que no todos los modelos son iguales. Cada uno ha ido surgiendo en lugares y en momentos históricos distintos, con la impronta humana y económica de cada época. Veámos puntualmente en qué forma los distintos modelos han cambiado a lo largo del tiempo.

Modelo de calidad tradicionalista

Las primeras consideraciones sobre Calidad de Software surgieron luego de la segunda mitad del siglo XX. Se dieron en un contexto internacional complejo en lo tecnológico y conflictivo en lo político, con la Crisis del Software[3] y la Guerra Fría[4]. Fue a principio de los años 70 cuando vió la luz, formalmente, el primer modelo de Calidad. No tuvo una denominación específica, pero fue identificado como parte del modelo de desarrollo de Software en Cascada[5][6].

Este modelo de Calidad, que por extensión recibió el nombre de la metodología donde surgió, heredó muchos principios de otras ramas de la ingeniería. Principalmente, de la ingeniería civil y, sobre todo, de la ingeniería automotriz. Recordemos que el paradigma productivo reinante en ese momento era el de la producción masiva, con el fordismo a la cabeza[7]. Y aunque pueda parecer extraño, podemos apreciar esta influencia en muchas características del modelo.

Básicamente, el modelo de Calidad del desarrollo de Software en Cascada propone que la misma es un atributo del producto. Atributo que suele medirse, por determinados especialistas, en una etapa determinada del ciclo de desarrollo. Generalmente, todo esto ocurre luego de contar con el producto construído.

Es decir, un equipo de programadores crea un artefacto determinado (en base a un diseño detallado previamente) y en algún momento en particular un tercero mide qué tanto se “adecúa” este artefacto a las especificaciones del negocio.

En ciertos contextos de esta naturaleza, la etapa de pruebas tiene mucha influencia en el proceso de desarrollo. Ya que es en ese punto donde se decide si el producto es aceptado o rechazado. Antes, no existen certezas del estado del producto respecto de las expectativas del negocio.



Podemos ilustrar este modelo de Calidad con una reseña histórica. James Womack y Daniel Jones son dos reconocidos investigadores del MIT. Durante muchas de sus investigaciones (luego documentadas en libros como Lean Thinking) ellos encontraron que en varias plantas automotrices de Europa, a mediados de los 80, la Calidad del automóvil era “asegurada” luego de que éste fuera construído. Se realizaba un minucioso ajuste y reconfiguración de piezas, por parte de personal especializado, una vez que el auto salía de la línea de montaje. Antes de este proceso, aunque el vehículo estuviera completamente ensamblado, no se tenía certezas sobre su funcionamiento. De hecho, se gastaba más de un tercio del esfuerzo total de construcción sólo en corregir defectos[8].

Lo que Womack y Jones opinan es que, amparado bajo la política de “dedicación a la Calidad”, este modelo en realidad tenía una contracara mucho menos eficiente de lo que podríamos suponer. Así, la constante reconfiguración (¡O descarte, lo que es peor!) de piezas que fueron ideadas sólo para ser puestas a punto luego de instalarse, empujaba exponencialmente el costo de fabricar un automóvil.

Artesanos Alemanes de Mercedes-Benz trabajando en la puesta a punto de sus automóviles. Esta forma de implementar prácticas de “Atención a la Calidad” se mantuvieron durante casi un siglo[9].

Pensemos, un minuto, cuántas veces en el modelo de Calidad del desarrollo en Cascada pasamos por situaciones similares. En ese contexto, participamos de la construcción de productos que buscan la más “alta calidad” a partir de varios ciclos de pruebas de regresión. Lo cual es un objetivo inalcanzable en algunos casos; ya que con cada nueva iteración, nuevos

defectos se propagan o cambian su ubicación en el código fuente[10]. Entonces, tras una supuesta filosofía de “orientación al detalle”, lo que en realidad realizamos es una cantidad desmedida de retrabajo. Esto tiene una relación directa con el costo del producto. Ya sea impactando en el calendario planificado, o en la cantidad de recursos humanos requeridos.

Por esta razón, dado que el modelo de Calidad del desarrollo en Cascada tolera el retrabajo (es más, ¡Lo fomenta!) existen mecanismos, heredados del Fordismo, creados para lidiar con las restricciones de recursos. De este modo, podemos distinguir cómo la idea de los cuellos blancos[11] y cuellos azules[12] cobra fuerza nuevamente en el ámbito del Software.

A partir de esta renovada noción de castas de especialización, podemos observar cómo ciertos especialistas diseñan los procesos y herramientas que luego otra clase de especialistas utilizarán. Un ejemplo común se da en el caso de las herramientas de administración del testing.

Las herramientas de administración de testing, en el modelo de Calidad del desarrollo en Cascada, en general son puestas en marcha por ciertos especialistas. Éstos poseen un nivel de conocimiento muy alto sobre cómo customizarla, de acuerdo a los procesos de cada proyecto. Así, se configuran diferentes secciones para llevar adelante la administración de toda tarea relativa al testing: Creación de casos de prueba, ejecución de ciclos de prueba, reporting, etc. Luego de esta puesta en marcha, la herramienta quedará lista para que otros especialistas la puedan operar; quienes oficiarán de operadores de la misma. Dichos operadores, por su parte, no cuentan con el grado de conocimiento de quienes realizaron la puesta a punto. De hecho, son recursos fácilmente reemplazables por el management del proyecto, quienes los asignan o desvinculan en la medida que se requiera. Así como muchas otras cuestiones dentro del contexto del desarrollo en Cascada, en este caso valen más los procesos y las herramientas, que el aporte de los individuos.

Nada es permanente a excepción del cambio

Pidiéndole la frase prestada a Heráclito, podemos decir que el modelo de Calidad del desarrollo de Software



en Cascada fue el modelo predominante durante años; así como lo fue el paradigma de producción masiva del fordismo en las industrias occidentales. Hasta que las cosas cambiaron.

Entre las décadas del 80 y 90, comenzaron a darse ciertos avances en la tecnología[13], la economía[14] y por ende en la sociedad misma. Así, la maduración de las herramientas de desarrollo de Software, el surgimiento de internet, y una economía regida por el desempeño de los trabajadores del conocimiento[15] hicieron que el modelo de Calidad descrito fuera perdiendo efectividad paulatinamente.

Esta situación no fue inédita. Varios años antes, situándonos nuevamente en la década del 70, la industria automotriz estadounidense pasó por una crisis similar[16]. En esa época adelantos que empezaban a ser comunes en Europa, como el aire acondicionado o sistemas de suspensión más sofisticados, eran complejos de integrar en las cadenas de ensamblaje americanas, tal como estaban diseñadas. Además, y por sobre todo, la Crisis del Petróleo[17] golpeaba duramente a la economía estadounidense. Lo que presionaba a las automotrices a cambiar la tecnología de sus motores. Todos estos eventos pusieron en jaque al paradigma de producción masiva. Así fue como el sistema de producción de Toyota[18], también conocido como Lean[19], llegó a la industria automotriz estadounidense; para luego comenzar a propagarse al resto de las industrias del mundo occidental.

Pero volvamos a fines del siglo XX. El escenario global comenzaba a pugnar por reducir el costo y el time to market de las aplicaciones. Al mismo tiempo la Calidad del Software, como producto, empezaba a ganar preponderancia dada su criticidad en el circuito de negocio. Durante esos años surgieron algunas iniciativas aisladas de profesionales que, siendo conscientes de este contexto, comenzaron a idear nuevos principios y nuevas prácticas de desarrollo basándose en gran medida en Lean. En los primeros años del siglo XXI estos profesionales decidieron coordinar sus iniciativas bajo un mismo movimiento. Así, dieron forma a las metodologías ágiles de desarrollo de Software[20].

Modelo de calidad ágil

El modelo de Calidad de las metodologías ágiles promueve, esencialmente, dos cosas. La primera es que la Calidad es responsabilidad de todo el equipo. La segunda es que la Calidad es un atributo intrínseco del producto, incorporado al mismo desde su concepción.

Estos principios se materializan mediante diversas prácticas que invierten el orden de las tareas típicas de desarrollo.

Podemos citar como ejemplos de tales prácticas el caso de TDD[21], BDD[22], y Continuous Integration[23]. Veamos un breve resumen de cada una.

TDD son las siglas de Test Driven Development. En esta práctica los programadores escriben las pruebas técnicas a las que someterán a su código, aún antes de escribirlo. Mediante este ciclo las pruebas también son parte del diseño del código. De modo que los tests van guiando qué debe hacer el código para que, una vez construído, pueda pasar exitosamente cada prueba previamente definida.

BDD son las siglas de Behaviour Driven Development. Su filosofía es muy parecida a la de TDD. De hecho, se complementan. Sólo que, en este caso, se apunta a que el equipo construya primeramente las pruebas funcionales del producto. Es decir, se busca definir colectivamente una guía sobre el comportamiento del Software. Luego, la ejecución de esta guía es automatizada. Lo que define un set de escenarios funcionales a seguir. Finalmente, la conjunción de las especificaciones automatizadas propias del negocio (mediante los escenarios funcionales de BDD) pero que también tienen componentes técnicos (con ciclos TDD embebidos) guían la implementación del Software. Al inicio del ciclo de desarrollo, cuando todavía no hay código productivo, la totalidad de escenarios ejecutados



En el modelo de Calidad del desarrollo en Cascada se busca asegurar la calidad del producto. Este aseguramiento se basa en la aplicación de férreos procesos, diseñados por especialistas. Dicho aseguramiento se vuelve más concreto, cuanto más madura es la etapa del ciclo de desarrollo donde sucede. De este modo, el grueso de las pruebas del Software ocurren cuando éste ya se encuentra construído.

En el caso del modelo de Calidad ágil se busca construir la calidad como una parte fundamental del producto. Se realizan pruebas exhaustivas, en algunos casos sin intervención humana, para medir qué tanto se ajusta el Software a los diseños técnicos y funcionales incluso cuando la implementación del mismo está inconclusa. También se busca amplificar la oportunidad de conocimiento sobre el negocio, basándose en el valor de las personas en lugar del valor de los procedimientos. Algo que es coordinado por todo el equipo de desarrollo.

Si comparamos ambos modelos, y hacemos un repaso histórico del camino recorrido por otras ramas de la ingeniería de más trayectoria, podemos observar que el impacto del modelo de Calidad ágil es, como alternativa a la problemática tecnológica actual y sus implicancias económicas, un hito en la ingeniería informática.

El presente plantea desafíos sin precedentes. Nuestro pasado y el camino que hemos recorrido, como profesión, es escaso. Apenas estamos siendo conscientes de que para lidiar con nuevos problemas necesitamos nuevas herramientas. Sin dudas, el futuro inmediato es muy prometedor.

Notas(*)Por versión candidata nos referimos a una versión del producto que cumple con los requerimientos definidos, sobre lo cual poseemos evidencia documentada, y que puede estar lista para ser entregada al Cliente.

da error. Progresivamente, a medida de que el equipo va implementando la funcionalidad, la ejecución de los escenarios comienza a mostrar un porcentaje de éxito; que también es muestra del porcentaje de avance en la construcción del producto.

Continuous integration (o CI) es una práctica que nos permite, como equipo, poder disponer de una versión candidata de nuestro producto con cada nuevo incremento que se realiza sobre el mismo(*). Esto implica tener una serie de procedimientos implementados automáticamente. Por ejemplo, los procesos de building y testing. Cada vez que un integrante del equipo haga un agregado al código fuente del producto, nuestro servidor de CI disparará los eventos de compilación, ejecución de los distintos niveles de tests definidos, y generación de las métricas de cada proceso. Esto es una fuente de datos objetivos sobre el estado del producto, como así también es un mecanismo extremadamente eficiente para disminuir el costo de implementación del mismo.

Todas estas prácticas están alineadas con el principio Lean de construir productos con Calidad integrada[24]. De este modo es posible asegurar la Calidad, tanto interna como externa, de cualquier incremento del producto mientras el mismo todavía está siendo desarrollado.

Como puede vislumbrarse en todos estos temas, otro de los pilares fundamentales del modelo de Calidad ágil (así como lo es en Lean) es la automatización de procesos[25]. De este modo, toda tarea propensa a error o que requiera mucho tiempo de ejecución debe ser llevada a cabo sin intervención humana. En caso de ocurrir una falla, el proceso automatizado debe detenerse para que el equipo pueda atacar el problema originario. Esto último, que más que un procedimiento o práctica es una cultura de trabajo, es conocido en Lean como stop the line[26].

Algunas conclusiones

Es interesante comparar cómo ambos modelos de Calidad, hoy descritos, buscan que el producto de Software pueda satisfacer los objetivos del negocio.



Bibliografía[1]http://www.smartcompany.com.au/growth/economy/12681-20100104-businesses-hit-by-bank-of-queensland-eftpos-bug.html

[2]http://www.nytimes.com/2008/03/12/business/12heart-web.html?_r=0

[3]http://en.wikipedia.org/wiki/Software_crisis

[4]http://en.wikipedia.org/wiki/Cold_War_(1962%E2%80%9379)

[5]Managing the development of large Software System, Dr Winston W. Royce - IEEE WESCON, August 1970, pages 1-9. Copyright © 1970 by The Institute of Electrical and Electronics Engineers

[6]Bell, Thomas E., and T. A. Thayer. Software requirements: Are they really a problem? Proceedings of the 2nd international conference on Software engineering. IEEE Computer Society Press, 1976.

[7]http://es.wikipedia.org/wiki/Fordismo

[8] The Machine that changed the world, Cap. 4 Running the Factory, pag. 90/91 - Copyright © 1990 by James P. Wormack, Daniel T. Jones, Daniel Roos, and Donna Sammons Carpenter.

[9]http://www.emercedesbenz.com/May08/14_001142_Celebrating_100_Years_At_The_Mercedes_Benz_Manheim_Plant_Mercedes_Benz_Plant_In_Manheim_Waldorf.html

[10] http://www.softwaretestingclub.com/profiles/blogs/defect-clustering-pesticide-paradox

[11] http://es.wikipedia.org/wiki/Trabajador_de_cuello_blanco

[12] http://es.wikipedia.org/wiki/Trabajador_de_cuello_azul

[13] http://en.wikipedia.org/wiki/Object-oriented_programming#History

[14]http://es.wikipedia.org/wiki/Nueva_econom%C3%ADa

[15]http://es.wikipedia.org/wiki/Peter_F._Drucker#Drucker_y_las_sociedades_de_la_informaci.C3.B3n_y_el_conocimiento

[16]The Machine that changed the world, Cap. 2 The rise and

[17]http://es.wikipedia.org/wiki/Crisis_del_petr%C3%B3leo_de_1973 - Copyright © 1990 by James P. Wormack, Daniel T. Jones, Daniel Roos, and Donna Sammons Carpenter.

[18]http://www.toyota-global.com/company/vision_philosophy/toyota_production_system/

[19]Implementing Lean Software Development From Concept to Cash, Cap. 1 History, pag. 9. - Copyright © 2007 Poppendieck LLC.

[20]http://agilemanifesto.org/iso/es/

[21]http://martinfowler.com/bliki/TestDrivenDevelopment.html

[22]http://dannorth.net/introducing-bdd/

[23]http://martinfowler.com/articles/originalContinuousIntegration.html

[24]The Toyota Way, Cap. 11 Principle 5: Build a Culture of Stopping to Fix Problems, to Get Quality Right the First Time, pag. 43. Copyright © 2004 by McGraw-Hill.

[25]http://www.toyota-global.com/company/vision_philosophy/toyota_production_system/jidoka.html

[26]http://leanbuilds.wordpress.com/tag/stop-the-line/

Escrito por Marcelo Corpucci para GlobalLogic, bajo licencia Creative Commons Atribución-NoComercial-CompartirIgual 4.0 Internacional.Registrado en SafeCreative. Nro. de Registro: 1407091429304

Sobre GlobalLogic

GlobalLogic es una empresa líder en el desarrollo completo del ciclo de vida de los productos de software. Combinando su experiencia en diversas industrias y su expertise en nuevas tecnologías ayuda a sus clientes a conectar ideas innovadoras con resultados de negocio. A partir del conocimiento obtenido en la creación de productos de software innovadores con tecnologías de vanguardia, GlobalLogic provee servicios de consultoría y desarrollo en areas como Mobile, Cloud Computing, SaaS, UX Design, Rich Internet Applications, Social Media, SOA&BPM, entre otros. A través de una estrecha colaboración. con sus clientes, GlobalLogic los ayuda a responder a las exigencias del time to market y a lograr costos competitivos en cada fase del ciclo de vida del desarrollo.Para obtener más información, visite www.globallogic.com.ar

Contacto

Daniela Castelli+54.11.5533.8300 x [email protected]

Technology

Camino hacia la calidad superlativa - Marcelo Corpucci