Camino hacia la calidad superlativa - Marcelo Corpucci

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

2. Camino hacia la calidad superlativa Marcelo Corpucci, QA Practice Leader
GlobalLogic Inc. www.globallogic.com.ar
Índice
Introducció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

3. Camino hacia la calidad superlativa Marcelo Corpucci, QA Practice Leader
GlobalLogic Inc. www.globallogic.com.ar
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.

4. Camino hacia la calidad superlativa Marcelo Corpucci, QA Practice Leader
GlobalLogic Inc. www.globallogic.com.ar
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

5. Camino hacia la calidad superlativa Marcelo Corpucci, QA Practice Leader
GlobalLogic Inc. www.globallogic.com.ar
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

6. Camino hacia la calidad superlativa Marcelo Corpucci, QA Practice Leader
GlobalLogic Inc. www.globallogic.com.ar
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.

7. Camino hacia la calidad superlativa Marcelo Corpucci, QA Practice Leader
GlobalLogic Inc. www.globallogic.com.ar
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

8. 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 1016
daniela.castelli@globallogic.com