1. Introducción

El software cada vez es más fundamental para el funcionamiento y la supervivencia de las organizaciones, debido al valor que tiene el procesamiento de la información; por lo que uno de los principales intereses de los directivos y profesionales relacionados con el software es comprender este valor y abordar los aspectos económicos relacionados con el mismo (Boehm and Sullivan, 2000). Nótese además que temas como este han provocado grandes diferencias entre la teoría y la práctica en la ingeniería del software; y también han confirmado el peligro que supone convertirse en un “lemming del software” (Davis, 2004), siguiendo últimas tendencias en ingeniería del software sin percatarse de los efectos económicos que pueden producir en nuestro entorno de trabajo.

Como afirma (Harrison, 2005), si no se entienden los principios básicos de la economía muchas decisiones de gestión pueden parecernos caprichos de los “dioses”. La gestión económica, y del valor, es uno de los aspectos más importantes a contemplar en la gestión del desarrollo de productos software, importancia que puede apreciarse incluso en destacados modelos de gobierno de las TIC, como el CobIt o el ValIT (ITGI, 2006)(Garzás et al., 2007) (Garzás and Cabrero, 2007b), que la contemplan entre sus pilares fundamentales (ver Figura 1) para un correcto gobierno.

Y esta preocupación por el valor se empieza a notar también con fuerza en los ámbitos más técnicos, en la propia ingeniería del software, en la que se está abriendo paso una nueva disciplina que se ha identificado bajo el nombre de ingeniería del software basada en valor o value-based software engineering (VBSE) (Garzás et al., 2007) y cuyo objetivo es integrar las diferentes aproximaciones que tratan conceptos económicos aplicados al desarrollo. Y que está haciendo que a pesar su dificultad, herramientas como el retorno de la inversión (ROI o Return Of Investment) o la productividad (Garzás and Cabrero, 2007a) se estén convirtiendo en indicadores esenciales e indispensables para la creación de software.

Son estas las motivaciones el artículo que aquí se presenta discute diferentes aspectos relacionados con las consideraciones económicas en el desarrollo software desde varios ámbitos. Para ello presentamos dos casos de estudio, simplificaciones de problemas reales, y que recorren diferentes problemáticas asociadas al tratamiento de cuestiones económicas asociadas al desarrollo software. El primer caso de estudio, el más técnico, se centra en la mejora del producto; y el tercero, con un planeamiento más de futuro, revisará desde un punto de vista económico la selección de la estrategia de producción de un departamento o fábrica software.

2. Caso de Estudio I: Planificación de la mejora de la calidad de un producto software

“Nada es veneno, todo es veneno: la diferencia está en la dosis”, determinó Paracelso, médico naturalista y alquimista del siglo XV, cita que sirve par ilustrar el principio de que todo puede ser tóxico si no se lo administra en la dosis adecuada. En la misma línea, una pequeña “dosis” de mejoras de diseño puede ser beneficiosa para un software, pero en dosis muy altas, puede ser fatal.

En ingeniería del software, hoy en día, nos sucede un problema del estilo. Tenemos acceso a una gran cantidad de buenas prácticas o conocimiento sobre mejoras pero no conocemos el grado en que aplicarlas, el valor que aporta cada una. La mayoría de las prácticas y mejoras se han desarrollado sin tener en consideración el valor que aportan al caso concreto en que se aplican, y así encontramos como numerosas metodologías y modelos tratan con la misma importancia a todos los requisitos, casos de prueba, casos de uso, etc. (Boehm, 2005).

Un caso destacado es el de las buenas prácticas para mejorar el diseño software. Los ingenieros software utilizan la enorme cantidad de conocimiento práctico acumulado por la comunidad de diseñadores (Garzás and Piattini, 2005) para mejorar sus diseños. Este conocimiento, entre el que podríamos destacar patrones, heurísticas, principios o malos olores, etc., ha probado ser muy valioso y útil a lo largo de los años. El problema es que no sabemos qué cantidad de patrones es la óptima, ni el valor que aporta cada uno de ellos al diseño global.

Los patrones de diseño (Gamma et al., 1995) son uno de los elementos más utilizados para la mejora de la calidad de un diseño software, a priori su incorporación es sinónimo de incremento en la calidad de la mantenibilidad del diseño. Y sin embargo en los últimos años han aparecido estudios que revelan como el sobrecargar de patrones nuestro diseño produce efectos contrarios a los previstos, disminuyendo la calidad del mantenimiento (Wendorff, 2001) (Reibing, 2001).

El problema viene en parte de considerar de modo simplista el concepto calidad y el supuesto valor aportado a la misma por los patrones de diseño. Según el estándar ISO 9126 sobre la calidad del producto software la calidad de la mantenibildiad del mismo puede descomponerse, principalmente, en analizabildiad y cambiabilidad. Cuantos más patrones de diseño se introducen más fácil de cambiar es el software, pero esta mayor flexibilidad no es gratuita: implica introducir un mayor número de clases, módulos y estructuras complejas que hacen menos comprensible o analizable el diseño software. De ahí que afirmar que la introducción de patrones incrementa la calidad de la mantenibilidad es una afirmación sesgada, la Figura 2 ilustra estos efectos.

Aún tendríamos que ir más allá para determinar el valor que cierto patrón aporta al diseño, ya que ¿cuál sería éste si añadimos patrones, con su consabida complejidad y disminución de la analizabilidad, en lugares que rara vez van a necesitar ser cambiados en el diseño? O ¿si añadimos patrones cuyo conste de introducción es superior al coste de cambiar el diseño sin haberlo introducido?

Consideremos lo anterior con un ejemplo. Existe un proceso tipo “cron” que envía diariamente mensajes a cinco objetos. Esta suele considerarse una mala práctica, ya que puede generar un problema de mantenimiento porque cada vez que quiera añadir un nuevo objeto para ser informado por el cron tendremos que modificar (y recompilar) la clase con el cron, donde se almacena a quién informar y con qué periodicidad. En este momento, observamos que la aplicación de un patrón “observer” (Gamma et al., 1995) puede aportar un gran valor, porque modificaría la estrategia tipo cro por una estrategia “publicar-suscribir”, que permite ahorrar tiempo cada vez que añadamos un nuevo objeto para ser informado. Sin embargo, y con respecto al valor que aportaría incorporar estrategias tipo observer:

• ¿Qué ocurre si la clase cron nunca debe ser cambiada? Nunca se incrementará el número de objetos a ser informados

• ¿Cuál es el coste de refactorización de nuestro diseño para introducir dicho patrón observer?

• ¿Es esta solución más valiosa que cualquier otra?, y ¿en qué medida?

• Si se aplicara este mismo patrón en otros lugares del diseño, ¿aportaría el mismo valor?

Contestar estas preguntas es fundamental si planeamos un rediseño a gran escala. Planear la aplicación de patrones de diseño sin conocer el valor aportado por cada uno puede llevarnos a soluciones contraproducentes.

Los patrones de diseño pueden ayudarnos a mejorar un diseño, pero los diseñadores no disponen de herramientas para analizar la situación cuantitativamente, o de proponer la solución más alineada con las decisiones de negocio o estratégicas de la compañía.

Podemos concluir que no conocemos ni el valor de los patrones de diseño, ni la cantidad de patrones que es razonable introducir en un diseño. En otras palabras, no podemos saber “qué dosis no son venenosas”. En la mayoría de las ocasiones, cuando se detectan posibilidades de mejora de un diseño, la manera de proceder es detectar las deficiencias y solucionar un porcentaje de las mismas. Esta aproximación independiente de valor no es la más eficiente. Desde una perspectiva basada en valor, necesitamos saber qué patrones de diseño son los más caros de aplicar, qué patrones proporcionan más valor y el retorno de inversión de cada opción. Es necesario tener en cuenta que un mismo patrón de diseño puede aportar un valor diferente dependiendo de dónde y cómo sea aplicado.

Estas consideraciones son fundamentales si deseamos calcular el retorno de inversión del rediseño de una aplicación.

2.1 Un método para calcular el valor de un patrón

En la realidad el cálculo del valor que aporta un patrón es aún más complejo que el que muestra la Figura 2, ya que el mismo patrón pueden aportar distintos tipos de valor dependiendo del lugar en que se apliquen, y en la mayoría de las ocasiones nos encontraremos con situaciones como la que describe la Figura 3.

En este contexto, y de manera más formalizada, podemos definir el valor que aporta un patrón de diseño (llamemos patron_n) a partir de los siguientes y que dependen del lugar lugar_m, en que ha sido introducido:

• PROBABILIDAD DE CAMBIO (lugar_m). Se trata de la probabilidad de que un cambio afecte a una parte específica del diseño, lugar_m, donde una mejora del diseño puede ser llevada a cabo mediante la introducción de un patrón. Este parámetro es importante porque la introducción de un patrón en un lugar que no vaya a cambiar consumirá recursos, y no aportará ningún beneficio a la mantenibilidad.

• COSTE DE INTRODUCCIÓN (patron_n, lugar_m). Este es el coste estimado de implementación de un patrón de diseño (pattern_n) en un lugar específico del diseño (place_m). Este coste es normalmente medido en esfuerzo o horas/hombre.

• COSTE DE PÉRDIDA SI OCURRE UN CAMBIO (lugar_m). Este es el coste del impacto si un cambio tiene lugar. Esto servirá para calcular la cantidad de esfuerzo, expresada en horas/hombre, que puede ser salvada si introducimos el patrón.

Una vez completado el coste de introducción, probabilidad de cambio y coste de pérdida, podemos conocer el valor de introducción de un patrón. La ecuación expresada en la Tabla 1 es una adaptación del concepto de exposición de riesgo tradicional aplicada el diseño software y al valor. En términos generales, la exposición de un riesgo dado es igual a la probabilidad de que ocurra ese riesgo multiplicado por la perdida total que éste produce. Cuanto mayor sea el valor de introducción de un patrón, mayor prioridad debe darse a la refactorización sobre otras posibles mejoras.

Cuando hay varios patrones que pueden ser aplicados, surge el problema de elegir cuál de ellos será el que más valor aporte. Este método de cálculo proporciona un valor numérico que puede ayudar a decidir al diseñador de entre las distintas alternativas.

2.2 Caso de estudio

VNI S.A. es una factoría software especializada en el sector público español. La compañía está especializada en el desarrollo, implantación y mantenimiento de soluciones de gestión integradas. El año 2006 arranco un proceso integral de mejora de la calidad, que incluye la mejora de varias aplicaciones. UCO es uno de los principales productos de VNI. Su propósito es simplificar la gestión de las actividades que realizan cotidianamente los investigadores. Técnicamente, el proyecto UCO ha sido desarrollado bajo el paradigma J2EE, utilizando Active Server Pages (JSP) como capa de presentación, Java para implementar la lógica de negocio y Oracle 9i como gestor de base de datos.

Los responsables de UCO estaban preocupados por el mantenimiento del proyecto. Se había detectado un incremento importante del coste de mantenimiento de la aplicación. Los ingenieros del software apuntaban a que necesitaban mucho tiempo para hacer modificaciones en el diseño software, ya que muchos comportamientos relacionados con el negocio de la aplicación habían sido diseñados utilizando estructuras rígidas, como complejas sentencias “if” o de tipo “swith”.

La primera propuesta de mejora fue planear un proyecto de refactorización para sustituir el código que contuviera sentencias condicionales por patrones State (Gamma et al., 1995), los cuales introducen ciertas indirecciones que posibilitan extender la funcionalidad del diseño con un impacto mínimo, y que suele ser aplicado cuando hay “operaciones que tienen largas sentencias condicionales [...] este patrón se representa habitualmente como constantes enumeradas”.

Sin embargo, tras la asesoría de varios consultores externos se constató el coste y riesgo de esta operación, que pretendía la sustitución de 20 sentencias condicionales cada mes, hasta llegar al 80% de las mismas a lo largo de un año. Teniendo en cuenta lo anterior, se propuso una aproximación al problema orientada a Valor, que planearía la refactorización de acuerdo a los conceptos discutidos en este artículo.

El primer paso fue el análisis y cuantificación de la situación. UCO tenía 153.535 clases y unos 4 millones de líneas de código. Se procedió a estudiar la complejidad ciclomática (CC) del sistema para identificar las clases que poseían sentencias condicionales más complejas. La métrica CC se eligió como un buen elemento para analizar la complejidad de la lógica condicional. La Tabla 2 muestra los resultados obtenidos.

De esta forma se localizó que la mayoría de los problemas se localizaban en el 23,51 % de las clases (curiosamente muy cercano a la distribución 80 – 20 de Pareto), es decir, las clases cuya complejidad ciclomática era mayor de 25. Este porcentaje puede parecer pequeño, pero representaba un total de 1337 clases. Teníamos la posibilidad de aplicar el patrón State a dichas clases, y evitar una aproximación por objetivos porcentuales que considerase el mismo valor para cada refaztorización. Se optó entonces por utilizar el cálculo del valor de introducción de un patrón (en este caso el State) para priorizar los trabajos, y para calcular dicho valor se tuvieron en cuenta las siguientes consideraciones.

PROBABILIDAD DE CAMBIO (por clase)

La probabilidad de cambio para cada clase fue calculada estudiando el histórico de cambios almacenado en la herramienta de control de versiones, en este caso CVS. Haciendo uso de dicho histórico, y mediante el cruce de datos con la herramienta “trouble ticket management” (en este caso, una herramienta propietaria) para ver que cambios se debían a peticiones de nueva funcionalidad, se pudo extraer la información que se presenta en la Tabla 4. De esta manera, se pudo estimar la probabilidad de cambio de cada clase.

COSTE DE INTRODUCCIÓN (patrón State, por clase).

El coste de refactorizar el diseño para la introducción del patrón State fue estimado en horas/hombre con la ayuda de la CC de cada clase. De esta forma, después de estudiar trabajos similares y aplicando la experiencia de los jefes de proyecto, se determinó una estimación del coste de cambio de acuerdo con los rangos de CC. La Tabla 4 muestra dichas estimaciones.

COSTE DE PÉRDIDA EN CASO DE CAMBIO (por clase).

De igual forma, utilizando la herramienta “trouble ticket management”, podemos averiguar el coste de cambio en las modificaciones en el pasado. Y así calcular la media de coste por clase y rango de CC expuesto en la Tabla 5.

PLANIFICACIÓN DE LA REFACTORIZACIÓN SEGÚN EL VALOR

Con los anteriores datos es sencillo calcular el valor de introducción del patrón State en cada clase del diseño (ver Tabla 6). Una consideración importante a tener en cuenta es que se propone refactorizar algunas clases de acuerdo con el patrón State para evitar sentencias condicionales complejas, y de esta manera reducir los tiempos de mantenimiento”, pero, sin embargo, no siempre existe una relación uno a uno entre las clases y el patrón State; algunas clases podrían necesitar varios patrones State y por esta razón lo más correcto es hablar del valor de introducción de un “conjunto de patrones State”.

3 Caso de Estudio II: Selección de la estrategia de desarrollo

Uno de los principales retos a la hora de dirigir un departamento o fábrica de software es comprender el valor de las estrategias de desarrollo software y aprender a tratar con los aspectos económicos relacionados con el desarrollo (Boehm and Sullivan, 2000) (Garzás and Piattini, 2007). De manera intuitiva sabemos que por lo general un incremento en la madurez de los procesos software de las organizaciones (como el que proporciona el modelo CMMI), proporciona un impacto más que significativo en la creación de valor, si bien este impacto es difícil de medir.

Existen diversas estrategias para organizar a nivel de departamento o fábrica el desarrollo o mantenimiento de productos software, que pueden combinarse y entre las que destacan tres grandes grupos (Garzás and Piattini, 2007):

• El desarrollo tradicional, considerando en este contexto que cada producto se desarrolla con independencia del resto, con su propio equipo, ciclo de vida, etc., ya sea con una aproximación estructurada o con una aproximación orientada a objetos; acompañada por prácticas básicas de ingeniería y gestión de proyectos.

• La generación, bien sea siguiendo un desarrollo dirigido por modelos, o mediante programación generativa, lo que permite automatizar la generación de código; estrategia bajo la que podemos encontrar otras más concretas como el MDA, MDD, etc.

• La reutilización, que se puede conseguir por varias estrategias, desde modelos de gestión de la configuración, del propio conocimiento (Garzás and Piattini, 2005), desarrollo basado en componentes, o, yendo a tendencias más actuales, mediante líneas de productos software.

En nuestro contexto es importante tener en cuenta que la selección de una u otra estrategia para la constitución de una fábrica software o departamento de desarrollo debe venir guiada por los objetivos de negocio de la misma. En el caso de las estrategias de reutilización, por ejemplo, lo importante debe ser demostrar si la reutilización es coherente con los objetivos de negocio (Devanbu et al., 1996) y para ello las empresas que utilicen programas de reutilización sistemática deben ser capaces de medir sus progresos económicos (Frakes and Terry, 1996).

Un concepto que en la actualidad se asocia frecuentemente con el desarrollo software es el ya mencionado como línea de producto. Y de ahí que en muchos de los proyectos de mejora suele surgir algún debate sobre su adopción como estrategia de desarrollo: “…si vamos a mejorar podríamos implantar una línea de productos”. E igualmente, de nuevo, uno de los aspectos más importantes a tener en cuenta antes de embarcarse en la implantación de una línea de productos es el impacto términos económicos que esta estrategia tendrá en la empresa. Incluso en muchas ocasiones las fábricas de software se han asociado con estrategias de reutilización o líneas de productos (como ocurre en la definición de (Greenfield et al., 2004)), si bien estas estrategias pueden ser aplicables a fábricas cuyo modelo de negocio se adecue a las mismas y no ser de aplicación en otros casos, siendo incluso contraproducentes.

De manera muy resumida, una línea de productos viene a ser, parafraseando la definición de (Clements et al., 2001), un conjunto de software que comparte características comunes (más conocidas como “features”), que satisfacen las necesidades específicas de un dominio o segmento particular de mercado y que se desarrollan a partir de un sistema común de activos base (más conocidos como “core assets”, y que pueden ser elementos como los requisitos, diseño, arquitecturas, componentes, código, etc.) de una manera preestablecida.

Se han desarrollado modelos económicos para líneas de producto, entre los que destaca el modelo SIMPLE (Structured Intuitive Model for Product Line Economics) desarrollado por el SEI (Software Engineering Institute) para poder calcular los costes y beneficios (y por lo tanto el ROI) a la hora de implantar líneas de producto.

Si bien el modelo SIMPLE es el más conocido existen otros y que citamos a continuación por si el lector quisiera ampliar este punto; en (Böckle et al., 2004) se presentan siete escenarios diferentes a la hora de implantar una línea de productos y en (Clemens et al., 2006) se profundiza en el modelo SIMPLE, presentando además COPLIMO, una extensión de COCOMO adaptada a las líneas de productos. Otros informes de interés del SEI son (Kazman et al., 2002) que presenta el método CBAM (Cost Benefit Analysis Method) que analiza las decisiones arquitectónicas desde las perspectivas de coste, beneficios, planificación y riesgo; y (Cohen, 2003) en el que se presentan los factores clave para adoptar una aproximación incremental a las líneas de producto basada en un enfoque “ABC” (Applications-Benefits-Costs). También pueden resultar de interés los trabajos de (Wesselius, 2006) que propone realizar una serie de escenarios, tanto arquitectónicos como estratégicos, estimando su probabilidad; el Modelo de reducción de costes en ingeniería de líneas de producto de (Peterson, 2003); el Modelo de coste e inversión para el desarrollo de familias de producto (Schmid, 2003a) y el modelo cuantitativo del valor de la arquitectura en la adopción de líneas de producto (ADOPTION) de (Schmid, 2003b)

Para simplificar podemos enumerar que de manera general los costes asociados a la implantación de una línea de productos que contempla este modelo de costes contempla:

• Corg: el coste de adoptar la aproximación de líneas de productos (reorganización, mejora de procesos, formación etc.).

• Ccab: el coste de desarrollar una base de activos adecuados para soportar la línea de productos (análisis de comunalidad/variabilidad, arquitectura genérica de software, infraestructura de pruebas, etc.).

• Cunique: el coste de desarrollar software único que no está basado en la plataforma de líneas de producto.

• Creuse: el coste de desarrollo a la hora de utilizar los activos de la base de activos (localización, extracción, adaptación de los activos; pruebas de integración adicionales, etc.).

Y donde el coste de implantar una línea de productos con n1 productos es:

Corg, Ccab, Cunique, y Creuse son funciones de coste que descomponen el problema en componentes más fáciles de abordar. Por ejemplo, Ccab puede obtenerse a partir de casos de estudio de líneas de producto o reutilización, y Cunique puede obtenerse mediante modelos como COCOMO o con datos históricos de la propia organización.

Para el ejemplo que nos ocupa, de una breve observación de la anterior ecuación podemos observar que si la línea de negocio de nuestro departamento o fábrica de desarrollo software contempla desarrollar pocos productos o varios productos con muy pocas partes comunes la implantación de una línea de productos en vez de proporcionar una economía de escala creará el efecto contrario, como puede observarse en la Figura 4 (Díaz and Trujillo, 2007).

La generalización del anterior ejemplo nos lleva a la conclusión de que debe ser el objetivo de negocio el que nos guíe la estrategia de desarrollo. A este respecto, de forma similar al caso anterior, existen cuatro grandes grupos de estrategias de negocio:

• Único producto para varios entornos, empresas que desarrollan software que luego debe ejecutarse en entornos de producción muy heterogéneos; el ejemplo más típico son las empresas que desarrollan aplicaciones para dispositivos móviles donde la misma aplicación debe ejecutarse en dispositivos hardware muy diferentes, con sistemas operativos diversos, etc.

• Único producto, empresas que evolucionan un único producto y que, a diferencia de caso anterior, no suelen tener grandes variaciones en los entornos de explotación, ejemplo típico son las empresas que desarrollan software de gestión, aplicaciones ofimáticas, etc.

• Plataforma, empresas que desarrollan un producto que no se pone en explotación en el entorno del cliente ni se distribuye, es software que se ejecuta en un servidor remoto al que los usuarios acceden por una interfaz, bien sea grafica o programática, ejemplo son las aplicaciones vía Web o las APIs como las que ofrecen muchos de los productos de Google.

• ­ Productos diferentes a medida, empresas que desarrollan productos “llave en mano” o bajo petición de sus clientes, que muchas veces no mantienen durante toda la vida del producto y que pueden ser muy diversos.

Por las razones expuestas a la hora de hablar de las líneas de producto, para cada una de las anteriores líneas de negocio existirán estrategias de desarrollo que se adecuen más o menos. Como puede observarse en la Figura 5 si la línea de negocio de nuestra empresa es “único producto para varios entornos” lo más adecuado puede ser una línea de productos, frente a un desarrollo tradicional; al contrario que si son “productos diferentes a medida”; por otro lado las estrategias de generación, tipo MDA, de adecuan más a “único producto” o “plataforma”.

4 Conclusiones

La motivación de este artículo ha sido profundizar en la importancia que tienen los aspectos económicos en todos los ámbitos de la mejora del desarrollo o los productos software. Como ingenieros software debemos conocer cómo medir la mejor “dosis” de patrones para nuestros diseños, prácticas para los equipos o estrategias para los departamentos o fábricas de desarrollo, y el coste de dichas dosis. Considerar los aspectos económicos y el valor de las acciones de ingeniería es fundamental para poder tomar decisiones más racionales, con éxito y que se alineen con los objetivos de negocio.

5 Referencias

Böckle G, Clements P, McGregor JD, Muthig D, Schmid K. 2004. Calculating ROI for Software Product Lines. IEEE Software 21(3):23-31.

Boehm B. 2005. Value-Based Software Engineering: Overview and Agenda. Value-Based Software Engineering Springer. p 3-14.

Boehm B, Sullivan KJ. Software economics: a roadmap; 2000; Limerick, Ireland. p 319-343.

Clemens PC, McGregor JD, Cohen SG. 2006. The Structured Intuitive Model for Product Line Economics (SIMPLE).

Clements P, Northrop L, Northrop LM. 2001. Software Product Lines : Practices and Patterns. Addison-Wesley Professional.

Cohen SG. 2003. Predicting When Product Line Investment Pays.

Davis A. 2004. Great Software Debates. Wiley-IEEE Computer Society Press.

Devanbu P, Karstu S, Melo W, Thomas W. Analytical and Empirical Evaluation of Software Reuse Metrics; 1996. p 189-199.

Díaz Ó, Trujillo S. 2007. Líneas de producto software. In: Garzás J, Piattini M, editors. Fábricas de software: Experiencias, tecnologías y organización: Ra-ma.

Frakes W, Terry C. 1996. Software Reuse: Metrics and Models. ACM Computings Surveys 28(2):415-435.

Gamma E, Helm R, Johnson R, Vlissides J. 1995. Design Patterns. Addison-Wesley Professional.

Garzás J, Cabrero D. 2007a. ---COMPROBAR TODO INCLUIDO AUTORES El valor y el retorno de la inversión de las TSI. In: Piattini M, Hervada F, editors. El Gobierno de las TSI. Madrid: Ra-ma.

Garzás J, Cabrero D. 2007b. El valor y el retorno de la inversión de las TSI. In: Piattini M, Hervada F, editors. El Gobierno de las TSI. Madrid: Ra-ma.

Garzás J, Cabrero D, Piattini M. 2007. La ingeniería del software basada en valor.

Garzás J, Piattini M. 2005. An ontology for micro-architectural design knowledge. IEEE Software Magazine 22(2):28-33.

Garzás J, Piattini M. 2007. Visión general de las fábricas software. In: Garzás J, Piattini M, editors. Factorias Software: Experiencias, Tecnología y Organización: Ra-Ma.

Greenfield J, Short K, Cook S, Kent S, Crupi J. 2004. Software Factories: Assembling Applications with Patterns, Models, Frameworks, and Tools. 1st ed: Wiley.

Harrison W. 2005. What Do Software Developers Need to Know about Business? IEEE Software 22(5):5-7.

ITGI. 2006. The Val IT Framework. IT Governance Institute. Val IT - Enterprise Value: Governance of IT Investments. ITGI.

Kazman R, Asundi J, Klein M. 2002. Making Architecture Design Decisions: An Economic Approach.

Peterson DR. Economics of software product lines. In: 3014 L, editor; 2003. p 381-402.

Reibing R. The impact of Pattern Use on Design Quality; 2001 October 14-18; Tampa Bay, Florida, USA.

Schmid K. 2003a. Integrated Cost- and Investmentmodels for Product Family Development. Fraunhofer Institut Experimentelles Software Engineering.

Schmid K. 2003b. A Quantitative Model of the Value of Architecture in Product Line Adoption. Fraunhofer Institut Experimentelles Software Engineering.

Wendorff P. Assessment of Design Patterns during Software Reengineering: Lessons Learned from a Large Commercial Project; 2001; Lisbon, Portugal. IEEE Computer Society.

Wesselius JH. 2006. Strategic Scenario-Based Valuation of Product Lines Roadmaps. In: Käkölä T, Dueñas JC, editors. Software Product Lines, Research issues in engineering and management book: Springer.

Artículo publicado por Garzás, J. (2008). Consideraciones económicas del desarrollo software. Revista CUORE (Circulo de usuarios de Oracle), Febrero(37).