Un caso para la fábrica de software
Julio 2004
Traducido por Victor Garcia Aprea
Este artículo no ha sido traducido por Microsoft
Este artículo y la veracidad de su traducción no ha sido revisado o verificado por Microsoft.
Microsoft no acepta responsabilidades sobre la veracidad o la información de este artículo que se proporciona tal cual por la comunidad.
Sumario: Se presenta sintéticamente la motivación para las Fábricas de Software, una metodología desarrollada en Microsoft. Una Fábrica de Software es un ambiente de desarrollo configurado para soportar el desarrollo rápido de un tipo específico de aplicación. Las Fábricas de Software son el próximo paso lógico en la continua evolución de los métodos y prácticas de desarrollo de software y prometen cambiar el carácter de la industria de software mediante la introducción de patrones de industrialización.
En esta página
Escalando el desarrollo de software
El desarrollo de software, como se practica actualmente, es lento, costoso y sujeto a errores, usualmente obteniendo productos con un gran número de defectos, causando serios problemas de usabilidad, disponibilidad, performance, seguridad y otras calidades de servicio.
De acuerdo al Standish Group [Sta94], se gastan en EEUU alrededor de US$250 billones en desarrollo de software cada año en aproxidamente 175.000 proyectos. Sólo el 16% de estos proyectos finaliza en tiempo y bajo el presupuesto planeado. Un 31% son cancelados, principalmente debido a problemas de calidad, lo que produce una pérdida de US$ 81 billones. El otro 53% excede su presupuesto original por un promedio de 189%, produciendo pérdidas por alrededor de US$59 billones. Los proyectos que logran completarse terminan conteniendo sólo un 42% de las prestaciones planeadas originalmente.
Estos números confirman objetivamente lo que ya conocemos por experiencia, que el desarrollo de software es un trabajo intensivo, consumiendo más capital humano por dólar de valor producido de lo que esperariamos de una industria moderna.
Por supuesto, fuera de estos problemas, los productos del desarrollo de software obviamente ofrecen un valor significante a los consumidores, lo que queda demostrado por una demanda creciente a largo plazo. Esto no significa que los consumidores queden totalmente satisfechos, bien con el software que les es entregado, o con la manera en que se lo entregamos. Sólo significa que ellos valoran tanto el software que están dispuestos a soportar grandes riesgos y pérdidas en orden de intentar alcanzar los beneficios que el mismo produce. Mientras que el estado actual descrito esta obviamente lejos de ser el ideal, parecería que no esta forzando ningún cambio significativo en los métodos y prácticas de desarrollo de software a nivel industrial como queda demostrado por la creciente popularidad del outsourcing.
Sólo beneficios modestos en productividad han sido alcanzados durante la última década, los más importantes quizás siendo los lenguajes código byte, patrones y métodos ágiles. Aparte de estos avances, seguimos desarrollando software de la misma manera que lo hacíamos diez años atrás. Nuestros métodos y prácticas no han cambiado mucho, y tampoco lo han hecho los costos y riesgos asociados.
Sin embargo, esta situación esta a punto de cambiar. La demanda global total de software esta proyectada en aumento por un orden de magnitud durante la próxima década –dirigida por nuevas fuerzas de la economía global- como el avance de China y el creciente rol del software en la infraestructura social, y por nuevas tecnologías de plataforma como Servicios web, dispositivos móviles, e artefactos inteligentes.
Sin un aumento comparable en capacidad, parece inevitable que la capacidad total de desarrollo de software esta destinada a no poder satisfacer la demanda total para finales de la década. Por supuesto, esto no debería pasar mientras el mercado pueda hacer algo al respecto, ya que el propio interés de los proveedores de software debería lograr la capacidad requerida para satisfacer la demanda.
Enfrentando los Futuros Cambios, Nuevamente
Qué es lo que deberá cambiar para proveer la capacidad adicional? No se requiere de mucho análisis para darnos cuenta que los métodos y prácticas de desarrollo de software deberán cambiar dramáticamente.
Dado que la capacidad de la industria depende del tamaño de la base de desarrolladores competentes y la productividad de los mismos, aumentar la capacidad de la industria requiere o bien más desarrolladores utilizando los métodos y prácticas actuales, ó un número de desarrolladores similar al actual utilizando métodos y prácticas diferentes.
Mientras que la cultura de aprendizaje cultivada durante los últimos diez años parecería haber aumentado el número de desarrolladores competentes y la competencia del desarrollador promedio, esta no podrá equipar a la industria para satisfacer el nivel de demanda esperado debido -al menos- a dos razones:
| • | Conocemos por experiencia que nunca habrá más de unos pocos programadores extremos. Los mejores desarrolladores son miles de veces más productivos que los peores desarrolladores, y estos últimos superan en cantidad a los primeros por un margen similar. [Boe81]. |
| • | Como lo menciona Brooks [Bro95], continuar sumando gente a un proyecto ofrece márgenes de retorno eventualmente en disminución. La cantidad de capacidad obtenida por la búsqueda y el entrenamiento de desarrolladores caerá asintótico. |
La solución debe incluir por lo tanto el cambio de nuestros métodos y prácticas. Debemos encontrar maneras de hacer a los desarrolladores mucho más productivos.
Curvas de Innovación y Cambios de Paradigmas
Como industria, hemos estado colectivamente en este punto antes. La historia del desarrollo del software es un asalto contra la complejidad y el cambio, con ganancias contadas por pérdidas, mientras el progreso crea cada vez demanda. Mientras que gran progreso se ha alcanzado en meramente media centuria, no ha sido continuo. Al contrario, ha seguido el conocido patrón de curvas de innovación, como se ilustra en la Figura 1 [Chr97].
Figura 1. Curvas de Innovación
Típicamente, una innovación discontinua establece los cimientos para una nueva generación de tecnologías. El progreso de la nueva fundación es inicialmente rápido, pero luego comienza gradualmente a desacelerarse, mientras la fundación se estabiliza y madura. Eventualmente, la fundación pierde su habilidad para mantener la innovación, y un punto es alcanzado. En este punto, otra innovación discontinua establece otra fundación para otra generación de nuevas tecnologías, y el patrón se repite. Kuhn denomina a estas fundaciones paradigmas, y a las transiciones entre las mismas, cambios de paradigmas [Kuh70]. Estos ocurren cuando los cambios son requeridos para mantener el avance. Hoy estamos en este punto.
Aumentando el Nivel de Abstracción
Históricamente, los cambios de paradigma han aumentado el nivel de abstracción para los desarrolladores, proveyendo conceptos más poderosos para capturar y reusar conocimiento en plataformas y lenguajes. Con respecto a la plataforma, por ejemplo, hemos progresado de procesamiento en lotes, a través de terminales/huéspedes, cliente/servidor, computadores personales, sistemas de múltiples capas e integración de aplicaciones empresariales hacia servicios asincrónicos y de bajo acoplamiento. Con respecto al lenguaje, hemos progresado de codificación numérica, a través de lenguajes ensamblador, estructurados y orientados a objetos hacia lenguajes de byte-code y patrones que pueden ser considerados como abstracciones basadas en lenguajes. Smith y Stotts sumarizan esta progresión elocuentemente [SS02]:
La historia de la programación es un ejercicio en abstracción jerárquica. En cada generación, los diseñadores de lenguajes producen constructores para las lecciones aprendidas en la generación anterior, y luego los arquitectos usan estos lenguajes para construir abstracciones más complejas y poderosas.
Ellos también apuntan que las nuevas abstracciones tienden a aparecer primero en plataformas, y luego son migradas a los lenguajes. Estamos ahora en un punto de esta progresión donde las abstracciones basadas en lenguajes han estado retrasadas con respecto a las abstracciones basadas en la plataforma por mucho tiempo. O, para decirle de otra manera, estamos ahora en un punto donde las herramientas han estado atrasadas con respecto a las plataformas por mucho tiempo. Utilizando la última generación de tecnologías de plataforma, por ejemplo, podemos ahora automatizar procesos que incluyan varios negocios ubicados en cualquier parte del planeta utilizando servicios compuestos por orquestación, pero todavía debemos unir cada una de estas aplicaciones manualmente, como si fuera la primera de su especie. Construimos grandes conceptos abstractos
Construimos grandes conceptos abstractos como reclamos de seguro y acciones de seguridad a partir de pequeños conceptos como bucles, cadenas, y enteros. Cuidadosa y laboriosamente componemos millones de piezas de código fuente y recursos interrelacionados para formar estructuras masivamente complejas. Si la industria de semiconductores usará un enfoque similar, construiría los procesadores masivamente complejos mediante transistores soldados manualmente. En cambio, ellos ensamblan componentes predefinidos denominados Circuitos Integrados de Aplicación Específica (ASICs) utilizando herramientas como la demostrada en la Figura 2, y luego generan las implementaciones.
Figura 2. Herramientas de diseño basadas en ASIC
Podemos automatizar el desarrollo de software de manera similar? Por supuesto que sí, y de hecho ya lo hemos hecho. Lo sistemas de manejo de base de datos, por ejemplo, automatizan el acceso a datos utilizando SQL, proveyendo beneficios como integración de datos e independencia que hacen que las aplicaciones dirigidas por datos sean mas fáciles de desarrollar y mantener. Similarmente, los marcos de interfase de usuario y editores WYSIWYG facilitan el desarrollo y mantenimiento de interfaces gráficas de usuario proveyendo beneficios como independencia de dispositivos y ensamblado visual. Atendiendo con detenimiento a como esto fue realizado encontramos un patrón recurrente:
| • | Luego de desarrollar un número de sistemas para un dominio de problema determinado, identificamos un conjunto de abstracciones reusables para el mismo, y luego documentamos un conjunto de patrones para dichas abstracciones. |
| • | Luego desarrollamos un motor de ejecución, como un marco o servidor, para codificar las abstracciones y patrones. Esto nos permite construir sistemas del dominio mediante la creación, adaptación, configuración y ensamblado de componentes definidos por el motor de ejecución. |
| • | Luego definimos un lenguaje y construimos las herramientas para soportar dicho lenguaje, como editores, compiladores, y depuradores, para automatizar el proceso de ensamblado. Esto nos permite responder rápidamente a requerimientos cambiantes, debido a que parte de la implementación esta generada, y puede ser fácilmente modificada. |
Este es el conocido patrón Marco de Lenguaje descrito por Roberts y Johnson [RJ96]. Un marco puede reducir el costo de construcción de una aplicación por un orden de magnitud, pero su utilización puede no ser sencilla. Un marco define un arquetipo de producto, como una aplicación o subsistema, que puede ser completa o especializado de distintas maneras para satisfacer las variaciones en requerimientos. El reracionamiento de los requerimientos de cada variante de producto al marco es un problema nada trivial que generalmente requiere de la experiencia de un arquitecto o desarrollador experimentado. Las herramientas basadas en lenguajes puede automatizar este paso mediante la captura de variaciones en requerimientos usando expresiones de lenguaje, y generado código que complete el marco.
Industrializando el Desarrollo de Software
Otras industrias han incrementado su capacidad mediante el cambio desde artesanía, donde productos enteros son creados desde cero por individuos o equipos muy pequeños, hacia fabricación, donde un rango de variantes de producto es rápidamente ensamblado a partir de componentes reusables creados por múltiple proveedores, y donde las máquinas automatizan las tareas de memoria o repetitivas. Ellas han estandarizados los procesos, diseños y empaquetados, usando líneas de producto para facilitar el reuso sistemático, y cadenas de provisión para reducir costos y riesgos. Algunas son ahora capaces de ajustes en masa, donde las variantes de productos son producidos rápidamente, a un menor costo y bajo demanda para satisfacer los requerimientos específicos de clientes individuales.
¿Puede Industrializarse el Software?
Analogías entre bienes de software y bienes físicos han sido acaloradamente debatidas. Pueden estos patrones de industrialización ser aplicados a la industria de software? No es la industria del software algo especial o diferente de las otras industrias debido a la naturaleza de sus productos? Peter Wegner expone las similitudes y contradicciones de esta manera [Weg78]:
Los productos de software son en alguna medida como los productos de disciplinas de ingeniería convencional como puentes, construcciones y computadores. Pero hay también ciertas diferencias importantes que le dan al desarrollo de software un sabor único. Debido a que el software es lógico y no físico, sus costos están concentrados en el desarrollo en lugar de producción, y ya que el software no se viste, su buen funcionamiento depende de calidades lógicas como su robustez y correcta programación, en lugar de calidades físicas como dureza y maleabilidad.
Algunas de las discusiones han involucrado comparaciones del tipo “manzanas con naranjas” entre la producción de bienes físicos, por un lado, y el desarrollo de software, por otro. La clave para aclarar la confusión es entender las diferencias entre producción y desarrollo, y entre economías de escala y economías de alcance.
Para poder ofrecer ROI, los componentes reusables deben ser reutilizados lo suficiente para recuperar el costo que tuvo su desarrollo, bien directamente mediante la reducción de costos o indirectamente, mediante la reducción de riesgos, de tiempo de mercadeo o mejores de calidad. Los componentes reusables son activos financieros desde una perspectiva de inversión. Debido a que el costo de desarrollar un componente reusable es generalmente alto, obtener niveles de ganancia de reuso no es algo tan sencillo. Un enfoque sistemático sobre reuso es entonces requerido. Esto generalmente involucra identificar un dominio en el cual múltiples sistemas van a ser desarrollados, identificar problemas recurrentes en ese dominio, desarrollar conjuntos de activos integrados de producción que resuelvan estos problemas, y luego aplicarlos mientras los sistemas son desarrollados en ese dominio.
Economías de Escala y Alcance
El reuso sistemático puede brindar puede brindar tanto economías de escala como economías de alcance. Estos dos efectos son ampliamente conocidos en otras industrias. Mientras los dos reducen tiempo y costos, y mejoran la calidad del producto, mediante la producción colectiva de múltiples productos en lugar de la producción individual, difieren en la forma en la que producen estos beneficios.
Las economías de escala aparecen cuando múltiple instancias idénticas de un mismo diseño son producidas colectivamente, en lugar de individualmente, como se ilustra en la Figura 3. Aparecen en la producción de cosas como, donde los activos de producción como máquinas de herramientas son utilizadas para producir múltiples instancias idénticas de producto. Un diseño es creado, en conjunto con instancias iniciales, denominadas prototipos, mediante un proceso intensivo en recursos, denominado desarrollo, llevado a cabo por ingenieros. Varias instancias adicionales, denominadas copias, son luego producidas por otro proceso, denominado producción, realizado por máquinas y/o fuerza de trabajo de bajo coste, para satisfacer la demanda del mercado.
Figura 3. Economías de Escala
Las economías de alcance aparecen cuando múltiples diseños similares pero no idénticos y prototipos son construidos colectivamente, en lugar de individualmente, como se ilustra en la Figura 4. En la fabricación de automotores, por ejemplo, múltiples diseños de automotores similares pero no idénticos son comúnmente desarrollados a partir de la composición de diseños existentes de subcomponentes, como chasis, cuerpo, interior y variantes o modelos son creados mediante la variación de las prestaciones como potencia del motor, de diseños existentes. En otras palabras, las mismas prácticas, procesos, herramientas, y materiales son usados para diseñar y prototipar múltiples productos similares pero diferentes. Lo mismo es cierto en la construcción comercial, donde varios puentes o edificios raramente comparten un diseño en común. Sin embargo, una particularidad interesante de la construcción comercial es que usualmente solo una o dos instancias son producidas de cada diseño exitoso, por lo que las economías de escala son raras de encontrar en estos casos. En la fabricación de automotores, donde varias instancias idénticas son producidas de cada diseño exitoso, las economías de alcance son complementadas por las de escala, como se ilustra por las copias de cada prototipo mostrado en la Figura 4.
Figura 4. Economías de Alcance
Por supuesto, hay importantes diferencias entre software y la fabricación de automotores o la construcción comercial, pero en algunos puntos encuentra similitudes.
| • | En mercados como el consumidor de escritorio, donde copias de los productos como sistemas operativos y aplicaciones de productividad son producidas en masas, el software exhibe una economía de escala, como la fabricación de automotores. |
| • | En mercados como el empresarial, donde las aplicaciones de negocios desarrolladas para obtener ventajas competitivas no son prácticamente nunca desarrolladas en masa, el software exhibe sólo economías de alcance, como la construcción comercial. |
Ahora podemos entender como las manzanas han sido comparadas con naranjas. La producción en industrias físicas ha sido erróneamente comparada con desarrollo en software. No tiene ningún sentido buscar economías de escala en el desarrollo de cualquier naturaleza, sea de software o de bienes físicos. Sí podemos, sin embargo, esperar que la industrialización del desarrollo de software explote las economías de alcance
¿Cómo Será La Industrialización?
Asumiendo que la industrialización puede ocurrir en la industria del software, que forma tendrá la misma? No podemos conocer esto hasta que suceda. Sin embargo, podemos arriesgar respuestas basándonos en el modo que la industria del software ha evolucionado y en la forma que ha tomado la industrialización en otras industrias. Sin lugar a dudas, el desarrollo de software nunca será reducido a un proceso puramente mecánico conducido por robots. Al contrario, la clave para satisfacer la demanda global es acabar con la perdida de tiempo de los desarrolladores avanzados en tareas de memoria y repetitivas. Debemos encontrar maneras de hacer mejor uso de los escasos recursos en lugar de consumirlos en la construcción manual de productos finales que va a requerir mantenimiento o bien un reemplazo completo en sólo unos pocos meses o años, cuando una próxima plataforma aparezca, o cuando las cambiantes condiciones del mercado hagan que los requerimientos de negocios también cambien.
Una manera de lograr esto es darle a los desarrolladores opciones para que puedan encapsular sus conocimientos como activos reusables que otros puedan reutilizar. Los patrones han demostrado un reuso de conocimiento efectivo (sin bien algo limitado). El próximo paso es movernos desde la documentación a la automatización, usando lenguajes, marcos, y herramientas para automatizar la aplicación de patrones.
El desarrollo de semiconductores ofrece un avance sobre como lucirá el desarrollo de software cuando la industrialización haya ocurrido. Esto no significa que los componentes de software van a ser sencillamente ensamblados como lo son hoy los ASICs.; estos últimos son producto de dos décadas de innovación y estandarización en tecnologías de empaquetado e interface. Sin embargo, podría tomarnos menos de 20 años llegar a este punto. Nosotros tenemos la ventaja de tener que lidiar solamente con bits, mientras que la industria de semiconductores tiene también que lidiar con los materiales físicos utilizados para implementar los componentes. Al mismo tiempo, la efímera naturaleza de los bits crea nuevos desafíos como los derechos de propiedad digitales, que hoy vemos en la industria de cine y de música.
Conclusión
Este artículo ha descrito la imposibilidad de la industria del software para satisfacer la demanda proyectada utilizando los métodos y prácticas actuales. Varios de los inconvenientes son discutidos brevemente en este artículo, sin dudas dejando al lector en busca de más evidencia y una discusión más detallada; esta es provista en el libro Software Factories: Assembling Applications with Patterns, Models, Frameworks and Tools, por Jack Greenfield y Keith Short, de la editorial John Wiley and Sons. Más información puede ser obtenida en: http://msdn.microsoft.com/architecture/overview/softwarefactories y http://www.softwarefactories.com/, incluyendo artículos que describen los problemas crónicos que previenen la transición desde artesanía a fabricación, las innovaciones críticas que ayudarán a la industria a superarlos, y la metodología de Fábricas de Software, que integra estas innovaciones críticas.
Declaración de Derechos de Autor
Copyright © 2004 por Jack Greenfield. Portions copyright © 2003 por Jack Greenfield y Keith Short, y reproducido con permiso de Wiley Publishing, Inc. Todos los derechos quedan reservados.
Referencias
1. [Boe81] B Boehm. Software Engineering Economics. Prentice Hall PTR, 19812. [Bro95] F Brooks. The Mythical Man-Month. Addison-Wesley, 19953. [Chr97] C Christensen. The Innovator's Dilemma, Harvard Business School Press, 19974. [Kuh70] T Kuhn. The Structure Of Scientific Revolutions. The University Of Chicago Press, 19705. [RJ96] D Roberts and R. Johnson. Evolving Frameworks: A Pattern Language for Developing Object-Oriented Frameworks. Proceedings of Pattern Languages of Programs, Allerton Park, Illinois, September 19966. [SS02] J. Smith and D Stotts. Elemental Design Patterns – A Link Between Architecture and Object Semantics. Proceedings of OOPSLA 20027. This illustration featuring Virtuoso® Chip Editor and Virtuoso® XL Layout Editor has been reproduced with the permission of Cadence Design Systems, Inc. © 2003. Cadence Design Systems, Inc. All rights reserved. Cadence and Virtuoso are the registered trademarks of Cadence Design Systems, Inc.8. [Sta94] The Standish Group. The Chaos Report. http://www.standishgroup.com/sample_research/PDFpages/chaos1994.pdf9. [Weg78] P Wegner. Research Directions In Software Technology. Proceedings Of The 3rd International Conference On Software Engineering. 1978
Acerca del autor
Jack Greenfield es un Arquitecto del equipo Enterprise Frameworks and Tools de Microsoft Corporation. Anteriormente se desempeño como Arquitecto en Jefe, Practitioner Desktop Group, en Rational Software Corporation, y Fundador y CTO de InLine Software Corporation. En NeXT, desarrolló el Enterprise Objects Framework, hoy denominado Apple Web Objects. Es un orador y escritor muy reconocido, que también contribuyo a las especificaciones de UML, J2EE, y otras relacionadas con OMG y JSP. Tiene un B.S. en Física de la Universidad de George Mason University. Jack puede ser contactado en jackgr@microsoft.com