Modelo Simple

Machine Translated by Google
El intuitivo estructurado
Modelo para línea de productos
Economía (SIMPLE)
Paul C. Clements
John D. McGregor
Sholom G. Cohen
febrero de 2005
REPORTE TÉCNICO
CMU/SEI2005TR003
ESCTR2005003
Pittsburgh, Pensilvania 152133890
El modelo intuitivo estructurado para la
economía de la línea de productos
(SIMPLE)
CMU/SEI2005TR003
ESCTR2005003
Pablo C. Clemente
John D. McGregor
Sholom G. Cohen
febrero de 2005
Iniciativa de práctica de línea de productos
Ilimitada distribución sujeta al derecho de autor.
Este informe fue preparado para el
Oficina del Programa Conjunto SEI
ESC/XPK
Calle Eglin, 5
Base de la Fuerza Aérea Hanscom, MA 017312100
Las ideas y hallazgos de este informe no deben interpretarse como una posición oficial del Departamento de Defensa. Se publica en interés del
intercambio de información científica y técnica.
PARA EL COMANDANTE
Cristos Scondras
Jefe de Programas, XPK
Este trabajo está patrocinado por el Departamento de Defensa de los Estados Unidos. El Instituto de Ingeniería de Software es un centro
de investigación y desarrollo financiado con fondos federales y patrocinado por el Departamento de Defensa de los Estados Unidos.
Derechos de autor 2005 Universidad Carnegie Mellon.
SIN GARANTÍA
ESTE MATERIAL DEL INSTITUTO DE INGENIERÍA DE SOFTWARE Y LA UNIVERSIDAD CARNEGIE MELLON ES
AMUEBLADO "TAL CUAL". LA UNIVERSIDAD CARNEGIE MELLON NO OFRECE GARANTÍAS DE NINGÚN
AMABLE, YA SEA EXPRESA O IMPLÍCITA, EN CUANTO A CUALQUIER ASUNTO, INCLUYENDO, ENTRE OTROS,
GARANTÍA DE IDONEIDAD PARA EL PROPÓSITO O COMERCIABILIDAD, EXCLUSIVIDAD O RESULTADOS OBTENIDOS
DEL USO DEL MATERIAL. LA UNIVERSIDAD CARNEGIE MELLON NO OFRECE NINGUNA GARANTÍA DE
CUALQUIER TIPO CON RESPECTO A LA LIBERTAD DE VIOLACIÓN DE PATENTES, MARCAS COMERCIALES O DERECHOS DE AUTOR.
El uso de cualquier marca comercial en este informe no pretende de ninguna manera infringir los derechos del titular de la marca comercial.
Uso interno. Se otorga permiso para reproducir este documento y preparar obras derivadas de este documento para uso interno, siempre que se incluyan
las declaraciones de derechos de autor y "Sin garantía" con todas las reproducciones y obras derivadas.
Uso externo. Las solicitudes de permiso para reproducir este documento o preparar trabajos derivados de este documento para uso externo y comercial
deben dirigirse al Agente de licencias de SEI.
Este trabajo fue creado en cumplimiento del Contrato del Gobierno Federal Número F1962800C0003 con la Universidad Carnegie Mellon para la
operación del Instituto de Ingeniería de Software, un centro de investigación y desarrollo financiado con fondos federales. El Gobierno de los Estados
Unidos tiene una licencia con fines gubernamentales libre de regalías para usar, duplicar o divulgar el trabajo, en su totalidad o en parte y de cualquier
manera, y para tener o permitir que otros lo hagan, para fines gubernamentales de conformidad con la licencia de derechos de autor bajo la cláusula en
252.2277013.
Para obtener información sobre la compra de copias impresas de los informes de SEI, visite la sección de publicaciones de nuestro sitio web
(http://www.sei.cmu.edu/publications/pubweb.html).
Tabla de contenido
Expresiones de gratitud................................................. ............................................vii
Abstracto................................................. .................................................... ............ix
1 Introducción................................................. ..........................................................1
2 Introducción a SIMPLE ............................................... ....................................5
2.1 Funciones de costo y beneficio ............................................... ......................6
2.2 Las cuatro funciones básicas de costos de SIMPLE ........................................... .6
2.3 Cprod : El costo de construir productos de manera independiente ............ 8 2.4 Cevo
y Ccabu : Modelando el costo de desarrollar un producto ........... .............8 2.5 Expresando
Períodos de Tiempo en el Modelo ............................... ......................9 2.6 Contabilización
de los beneficios económicos de la línea de productos .................. ..............10
3 escenarios.................................................. .................................................... ..13
3.1 El costo de construir una línea de productos de software ..........................13 3.2 El
costo de construir una línea de productos de software vs. Construyendo el
Productos de forma independiente................................................. .......................13
3.3 Costo de lanzar una nueva versión de un miembro de la línea de productos ...............
.14 3.4 Comparación del costo de conversión a una línea de productos vs. Continuando a
Evolucionar un conjunto existente de productos independientes...................15 3.5
Retorno de la inversión (ROI) ) .................................................. ...............18 3.6
Construcción y desarrollo de una línea de productos ........................... ..........18 3.7
Redistribución de productos entre las líneas de productos existentes ...............19 3.8
Adición Nuevos productos para las líneas de productos existentes...................20 3.9
Construcción vs. Comprar................................................. ..........................................21
4 Enfoques para implementar las funciones de costo y beneficio ..................23 4.1 Uso de los
datos históricos propios de una organización ............... ..........................23 4.2 Puntos de
referencia de la comunidad .................. .............................................23 4.3 Utilidad
Funciones.................................................. ..................................24 4.4 Cuantificación de
valores no numéricos ......... .............................................26 4.5 Divide y
conquistaras............................................... .............................26
CMU/SEI2005TR003 i
4.6 Inferencia................................................... ............................................. 26
4.7 Aproximación bruta.................................................... ............................ 27 4.8 Implementación
de la función de beneficio .................. .......................................... 27 4.9 Implementación de la
métrica de homogeneidad.... ............................................. 29
5 Aplicación de SIMPLE en la práctica ............................................... ....................... 31
6 Relación con el marco SEI para la línea de productos de software
Práctica ................................................. .................................................... ... 33
6.1 Áreas de práctica relacionadas con la línea de productos de software .................. 34
6.2 Patrones para la práctica de la línea de productos de software ......... 37
7 Trabajo relacionado.................................................. ............................................... 41
7.1 Reutilización del software de medición de Poulin.................................... ....... 41
7.2 COPLIMO.................................................. .......................................... 43
7.2.1 Desarrollo de la línea de productos en COPLIMO ........................... 43 7.2.2 Modelo
de ciclo de vida anualizado en COPLIMO ....................................... 45
8 Trabajo Futuro .............................................................. ............................................. 47 8.1 Validando
SIMPLE .............................................. ............................. 47 8.2 Ampliación y organización del
conjunto de escenarios SIMPLE .......... ......... 48 8.3 Exploración de dependencias y sensibilidades
dentro del modelo ......... 48 8.4 Problemas de presentación: hacer que SIMPLE esté disponible y
utilizable ............... 49
Apéndice A: análisis de homogeneidad de la métrica de pregunta de objetivo (GQM)
Métrico................................................. ............................................. 51
Apéndice B – Tabla de Símbolos Usados en SIMPLE ........................................... .. 57
Apéndice C – Lista de siglas ............................................... ............................. 59
Referencias .................................................. .................................................... ..... 61
yo CMU/SEI2005TR003
Lista de Figuras
Figura 1: El escenario general ............................................... ..........................5
Figura 2: Curva de utilidad uniforme ............................................... ..........................24
Figura 3: Función de utilidad ................................................ ..........................................25
Figura 4: Función de utilidad de paso ........................................... ....................................25
CMU/SEI2005TR003 iii
IV CMU/SEI2005TR003
Lista de tablas
Tabla 1: Datos iniciales................................................ .............................................28
Tabla 2: Satisfacción después de la línea de productos ............................................... ...........28
Tabla 3: Cálculo de beneficios ................................................ ..........................28
Tabla 4: Áreas de práctica de la línea de productos .................................. .......................33
Tabla 5: Relación de SIMPLE con las prácticas de la línea de productos ..................34
Tabla 6: Relación de SIMPLE con patrones para la práctica de la línea de productos
de software .................................. .................................................... .......38
CMU/SEI2005TR003 v
vi CMU/SEI2005TR003
Expresiones de gratitud
Este trabajo surgió de un grupo de discusión sobre la economía de la línea de productos en el
seminario Dagstuhl de 2003 sobre desarrollo de familias de productos. Además de McGregor y
Clements, ese grupo incluía a Dirk Muthig y Klaus Schmid de Fraunhofer IESE y Günter Böckle de Siemens.
Ese grupo publicó dos artículos sobre su trabajo: uno sobre el modelo básico [Böckle 04b] y el otro
que muestra cómo usar el modelo económico para calcular el retorno de la inversión en un enfoque
de línea de productos de software [Böckle 04a]. Aunque este informe es el trabajo de los autores
enumerados, no habríamos tenido nada sobre lo que escribir sin las contribuciones de nuestros
colegas alemanes, con quienes seguimos reuniéndonos y colaborando para avanzar en el trabajo.
A ellos expresamos nuestra gratitud y reconocemos sus útiles comentarios sobre este informe.
También estamos agradecidos con Charles Krueger de BigLever Software, Inc., quien hizo muchas
sugerencias útiles durante discusiones recientes y con Gary Chastek y Lawrence Jones del
Carnegie Mellon® Software Engineering Institute (SEI) por sus útiles revisiones. Y finalmente,
agradecemos a Dale Peterson de Convergys y John Gaffney de Lockheed Martin por sus interesantes
revisiones y comentarios. El artículo de Dale Peterson, “Economía de las líneas de productos de
software” [Peterson 04], del cual hemos citado generosamente en esta publicación, fue especialmente
esclarecedor.
®
Carnegie Mellon está registrado en la Oficina de Marcas y Patentes de EE. UU. por la Universidad
Carnegie Mellon.
CMU/SEI2005TR003 viii
viii CMU/SEI2005TR003
Abstracto
La práctica de la línea de productos de software es una estrategia efectiva para desarrollar familias de
productos intensivos en software. El modelado de negocios es una práctica fundamental que proporciona
información sobre una serie de decisiones que toman las organizaciones que usan o consideran usar la
estrategia de línea de productos. Este informe presenta el Modelo intuitivo estructurado de la economía de
la línea de productos (SIMPLE), un modelo comercial de propósito general que respalda la estimación
de costos y beneficios en una organización de desarrollo de línea de productos. El modelo respalda
decisiones tales como si utilizar una estrategia de línea de productos en una situación específica, la
estrategia específica a aplicar y la idoneidad de adquirir o construir activos específicos. Este informe
ilustra el alcance del modelo al presentar varios escenarios y su utilidad al integrarlo en varios patrones de
práctica de línea de productos. El informe finaliza con una descripción del trabajo futuro destinado a
hacer que el modelo sea utilizable por los profesionales de la línea de productos.
CMU/SEI2005TR003 ix
X CMU/SEI2005TR003
1. Introducción
La práctica de la línea de productos se ha convertido en un enfoque importante y ampliamente utilizado para
el desarrollo eficiente de carteras completas de productos de software [McGregor 02]. La idea fundamental del
enfoque es emprender el desarrollo de un conjunto de productos como una tarea de desarrollo única y coherente.
Los productos se crean a partir de una base de activos básicos, una colección de artefactos que se han diseñado
específicamente para su uso en toda la cartera. Este enfoque ha producido mejoras económicas de orden de
magnitud en comparación con el desarrollo de sistemas de software uno a la vez [Clements 02b]. El enfoque de
línea de productos es una estrategia integral de desarrollo de productos intensivos en software. Incluye no solo
enfoques técnicos para resolver el problema en cuestión, sino también consideraciones comerciales, incluidas
las características económicas del desarrollo. La naturaleza estratégica de estas características afecta
cómo se lleva a cabo el modelado de negocios en la organización.
El enfoque de línea de productos no siempre es la mejor opción económica para desarrollar una familia de
sistemas relacionados. Por ejemplo, los sistemas pueden ser prohibitivamente diferentes entre sí, o la familia
puede contener muy pocos sistemas para recuperar el costo de desarrollar los activos principales.
Los tomadores de decisiones deben poder predecir los costos y beneficios de desarrollar y evolucionar una línea
de productos en comparación con los enfoques de desarrollo tradicionales. Incluso cuando se ha adoptado un
enfoque de línea de productos, hay enfoques alternativos disponibles y sus implicaciones económicas deben
sopesarse antes de elegir uno de esos enfoques. Peterson escribe
Los costos y riesgos de la inversión, así como los beneficios posteriores, pueden ser
significativos. Obtener la aceptación de los accionistas ejecutivos para realizar la inversión
requiere un caso de negocios que traduzca los beneficios cualitativos citados tan a menudo para
las líneas de productos de software en beneficios comerciales concretos. El proceso de caso de
negocio puede ser una herramienta eficaz para la toma de decisiones no solo para decidir
si una organización debe hacer la transición a una SPL [línea de productos de software], sino
también cuál es la mejor manera de hacer que la transición sea un éxito. Una comprensión del
tamaño y el momento de los flujos de efectivo permitirá a la organización evaluar su estrategia
de transición y determinar el grado en que debe adoptar un enfoque incremental e iterativo
[Peterson 04].
La mayoría de los argumentos económicos actuales se basan en puntos de datos singulares derivados de
estudios de casos [Clements 02a, Knauber 02, Clements 02b, Cohen 04, SPL 05a] o argumentos
convincentes que apelan a la razonabilidad y curvas de costos simplistas [Weiss 99, Cohen 03].
Los modelos existentes de costos de desarrollo en el contexto de la reutilización solo se pueden aplicar
de manera restringida, ya que el desarrollo de la línea de productos implica algunos supuestos fundamentales
que no se reflejan en estos modelos. Actualmente, solo existen unos pocos modelos económicos específicamente
CMU/SEI2005TR003 1
para la ingeniería de línea de productos y, por lo general, no abordan los efectos del mantenimiento y la evolución a lo
largo del tiempo [Favaro 96, Mili 00, Schmid 02, Wiles 02]. Otros limitan la reutilización solo al software oa los
artefactos cercanos al software, tratando el costo como una función de las líneas de código [Gaffney 92]. La
mayoría no tiene en cuenta los costos de realizar cambios en la organización para que pueda crear y mantener de manera
más efectiva una línea de productos de software [Cruickshank 93].
Se necesita un modelo que pueda usarse para predecir los costos y beneficios de la línea de productos de software en una
variedad de situaciones del mundo real y que pueda ser usado fácilmente por los tomadores de decisiones de la línea
de productos que no son expertos en teorías económicas complejas. Este informe sugiere un modelo de este tipo
denominado Modelo intuitivo estructurado para la economía de la línea de productos (SIMPLE), que fue desarrollado por
el Carnegie Mellon® Software Engineering Institute (SEI).
Tenemos varios objetivos para SIMPLE:
1. Debe modelar situaciones reales de manera completa y correcta para que pueda dar respuestas de alta fidelidad
a los problemas reales de las organizaciones.
2. Debe ser lo suficientemente intuitivo para que el personal de la línea de productos produzca fácilmente
respuestas cuya derivación pueda ser mostrada y entendida por otros.
3. Debe ser comprensible tanto para los gerentes como para los técnicos.
4. Debe ser lo suficientemente flexible para ayudar a responder una amplia gama de preguntas. De hecho, nuestro
modelo está estructurado en partes para permitir que el modelador seleccione los niveles apropiados de detalle
y elementos del modelo para responder una pregunta específica.
5. No debe suponer ningún enfoque particular para la ingeniería de la línea de productos de software más allá
de los principios básicos implícitos en la definición de una línea de productos de software: “un conjunto de
sistemas intensivos en software que comparten un conjunto común y administrado de características que
satisfacen las necesidades específicas de un usuario en particular”. segmento de mercado o misión y que se
desarrollan a partir de un conjunto común de activos básicos de una manera prescrita” [Clements 02b].
SIMPLE comprende un conjunto de funciones de costo y beneficio que se pueden usar para construir ecuaciones que
pueden responder una serie de preguntas, como si el enfoque de línea de productos es la mejor opción para el desarrollo
y cuál es el retorno de la inversión (ROI) para este enfoque. En este informe, definimos estas funciones y describimos
algunas implementaciones posibles para ellas. También ilustramos la utilidad de estas funciones usándolas para construir
las ecuaciones para varios escenarios.
Por supuesto, incluso un modelo económico completo puede no proporcionar todos los datos necesarios para tomar
la decisión correcta entre las alternativas. Por ejemplo, SIMPLE no aborda el riesgo, es decir, no ayuda a evaluar los
riesgos relativos de diferentes alternativas ni a incluirlos en sus fórmulas.1 Ningún modelo económico reemplazará la
experiencia o los instintos de un gerente ni tendrá en cuenta intangibles como la lealtad del cliente. , cultura organizacional,
influencias políticas y
®
Carnegie Mellon está registrado en la Oficina de Marcas y Patentes de EE. UU. por la Universidad Carnegie Mellon.
1
Para ver un ejemplo de un modelo de costos de software que aborda el riesgo, consulte el trabajo de Verhoef [Verhoef 04].
2 CMU/SEI2005TR003
factores de personalidad Sin embargo, constituirá una herramienta importante en el conjunto de herramientas de toma de
decisiones de un gerente inteligente.
El resto de este informe está organizado de la siguiente manera. En la Sección 2, presentamos el modelo completo y brindamos
especificaciones para las cuatro funciones básicas de costos en su núcleo. Luego, en la Sección 3, presentamos escenarios que
ilustran el uso del modelo. Estos escenarios representan un espectro de decisiones comerciales a las que se puede aplicar
el modelo. La sección 4 analiza las formas de implementar las funciones de costo y beneficio. Proporcionamos un esquema general
y técnicas específicas para implementar diferentes partes de las ecuaciones. En la Sección 6, relacionamos el modelo con
varias áreas de práctica en el marco SEI para la práctica de la línea de productos de softwareSM [Clements 04], así como varios
patrones aplicables para la práctica de la línea de productos de software [Clements 02b]. En la Sección 6, esbozamos un proceso
sencillo para usar SIMPLE.
En la Sección 7, relacionamos el modelo con trabajos previos en el campo. Finalmente, en la Sección 8, presentamos las
direcciones futuras para continuar el trabajo. El Apéndice A analiza una métrica de homogeneidad para una familia de productos,
mientras que el Apéndice B enumera y define los símbolos utilizados en SIMPLE.
SM
Framework for Software Product Line Practice es una marca de servicio de la Universidad Carnegie Mellon.
CMU/SEI2005TR003 3
4 CMU/SEI2005TR003
2 Introducción a SIMPLE
En términos generales, SIMPLE se puede utilizar para calcular estimaciones de varias medidas económicas
relacionadas con la construcción, el mantenimiento y la evolución de las líneas de productos de software. El problema
de los cálculos de costobeneficio para la ingeniería de línea de productos que condujo a SIMPLE se puede reducir
al problema (general) de modelar la siguiente situación:
Una organización tiene líneas de productos p_init, cada una de las cuales comprende un conjunto de
productos y productos independientes s_init. Durante un período de tiempo, la organización desea
hacer la transición al estado en el que tiene p_líneas de productos finales, cada una de las cuales
comprende un conjunto (quizás diferente) de productos, y s_productos independientes finales. En el
camino, la organización tiene la intención de agregar k productos o eliminar d productos.2
La Figura 1 ilustra este escenario y cómo es solo una parte de un proceso en curso.
Figura 1: El escenario general
Es fácil imaginar casos especiales de este escenario que reflejen situaciones de interés de productos del mundo real,
por ejemplo
• Una organización tiene cero líneas de productos y 12 productos independientes. Desea tener una línea de
productos y cero productos independientes, es decir, desea convertir su colección de productos en una línea
de productos. SIMPLE se puede utilizar para sopesar el costobeneficio de hacerlo, en lugar de dejar que los
productos continúen evolucionando por separado.
• Una organización tiene dos líneas de productos (quizás como resultado de adquirir otra
compañía). Desea fusionarlos en una sola línea de productos y eliminar aquellos productos que son duplicados.
SIMPLE se puede utilizar para estimar el costobeneficio de fusionar las líneas de productos, en lugar de
mantenerlas separadas.
2
Un diccionario de notación aparece en el Apéndice B.
CMU/SEI2005TR003 5
• Una organización tiene tres líneas de productos y desea agregar un producto y saber
qué línea de productos es la mejor candidata para recibirla. SIMPLE se puede usar para estimar el costo y el
beneficio de agregar el producto a cada una de las tres líneas de productos, lo que ayuda a determinar la
mejor opción.
En cada caso (y muchos otros), los tomadores de decisiones organizacionales querrán saber cuánto costará su plan,
qué beneficios traerá y cómo se compara con otras alternativas. Como ilustran estos ejemplos, SIMPLE se puede usar
para sopesar los costos y beneficios de una o más alternativas relacionadas con la línea de productos, de modo
que se pueda elegir la más oportuna.
No todos los escenarios en los que SIMPLE puede ayudar pueden expresarse como un caso especial del
escenario general descrito anteriormente; sin embargo, la mayoría de los escenarios que hemos tratado hasta la fecha
pueden serlo. La Sección 3 ilustrará el rango de escenarios para los cuales SIMPLE es aplicable.
2.1 Funciones de costo y beneficio
SIMPLE se construye utilizando un enfoque de "divide y vencerás" a la pregunta de cuánto le costará a una organización
una estrategia de línea de productos de software en particular y cuánto gana en comparación con otras
alternativas. Para expresar estas cantidades, SIMPLE introduce funciones de costo y funciones de beneficio
que describen estos aspectos constituyentes de la cuestión económica general. Estas funciones se introducen a partir
de la Sección 2.2. En lugar de funciones matemáticas rigurosamente definidas, deben considerarse como una
invitación a realizar un experimento mental para llegar a una estimación de costo (o beneficio monetario) razonable
en cada área.
Cada función se puede "implementar" a través de una variedad de enfoques que incluyen el uso de datos históricos de
una organización, modelos de costos generalizados como el Modelo de Costos Constructivos (COCOMO) II [Boehm
00], o una descomposición adicional en funciones más detalladas.
Nota: En este informe, podemos hablar de estas funciones como "devolver" un valor, pero esto pretende invocar la
imagen de un oráculo en lugar de una subrutina matemática en un lenguaje de programación. Algunos lectores
pueden sentirse más cómodos sustituyendo "significa" por "devoluciones".
La Sección 4 analiza las estrategias de implementación para las funciones de costos con más detalle.
2.2 Las cuatro funciones básicas de costos de SIMPLE
SIMPLE se basa en cuatro funciones básicas de costos:
1. Corg() es una función que, dados los parámetros relevantes, devuelve cuánto cuesta un
organización a adoptar el enfoque de línea de productos para sus productos. Dichos costos pueden incluir
reorganización, mejora de procesos, capacitación y cualquier otro remedio organizacional que sea
necesario.
2. Ccab() es una función que, dados los parámetros relevantes, devuelve cuánto cuesta
Desarrollar una base de activos básicos adecuada para satisfacer un alcance particular. Ccab tiene en cuenta la
6 CMU/SEI2005TR003
costos de realizar un análisis de similitud/variabilidad; definir el alcance de la línea de productos [Clements 04]; diseñar
y luego evaluar una arquitectura de software genérica (a diferencia de una única); y desarrollar el software así
diseñado. Ccab también incluye la construcción del plan de producción, el establecimiento del entorno de
desarrollo y la producción de una arquitectura de prueba y otros artefactos que son reutilizables en toda la
familia. Se puede invocar a Ccab para decirnos el costo de desarrollar una base de activos básicos donde
actualmente no existe o el costo de derivar una base de activos central deseada de una o más bases ya existentes.
Tenga en cuenta que la base de activos principales puede (y debe) incluir también activos que no son de software,
como planes, cronogramas, presupuestos, la definición del alcance y varios tipos de documentación. También
incluye los artefactos que le indican cómo producir productos a partir de activos básicos; un ejemplo de tal
artefacto es un plan de producción [Clements 04].
3. Cunique() es una función que, dados los parámetros relevantes, devuelve cuánto cuesta desarrollar las partes
únicas (tanto software como no software) de un producto que no se basan en activos en la base de activos
principales. El resultado podría ser un producto completo (es decir, uno que no sea miembro de una línea de
productos) o la parte única de un producto cuyo resto se construya sobre la base de activos centrales de una línea
de productos.
4. Creuse() es una función que, dados los parámetros relevantes, devuelve cuánto cuesta crear un producto
reutilizando los activos principales a partir de una base de activos principales. Creuse incluye el costo de ubicar
un activo central, sacarlo del repositorio, adaptarlo para su uso en la aplicación prevista y realizar las pruebas
adicionales asociadas con la reutilización3 de activos centrales.
En algunos enfoques de línea de productos, cada activo se administra como un activo central. Un activo como una pieza
de software, un plan o una especificación de diseño que solo se usa en un solo producto no se trata de manera diferente
que un artefacto correspondiente que se usa en dos o más productos. Bajo este enfoque, Cunique() simplemente será
cero, y Creuse() asumirá el costo total de construir un producto .
A medida que avanzamos, se agregarán algunas funciones de costo más al modelo, pero estas cuatro representan el
enfoque básico.
Para mostrar estas cuatro funciones de costo en acción, las usamos en una expresión muy simple que describe el
costo de construir una sola línea de productos que contiene n productos. Este costo se puede expresar mediante la
Ecuación 1.
ecuación 1
Costo de construir una línea de productos =
norte
() + Ccab +∑ C(unique producti )+ C producto
Corg ( () (i )) reutilizar
i=1
3
John Gaffney sugiere el término multiuso en lugar de reutilización para cubrir la situación en la que el material se
desarrolla específicamente para incorporarlo a un conjunto de productos de software, no solo una nueva versión
de uno existente. Esa es una buena distinción, pero continuaremos empleando reutilizar en este informe
porque en la mayoría de los casos lo usamos como verbo.
CMU/SEI2005TR003 7
Esta ecuación dice que el costo de desplegar una línea de productos es el costo de adopción organizacional
más el costo de construir la base de activos básicos más el costo de construir cada uno de los n productos. El
costo de construir un producto es el costo de construir la parte única de ese producto más el costo de incorporar los
activos principales al producto.
Esta ecuación no analiza el costo de funcionamiento o mantenimiento de la línea de productos, ni compara el costo
con otros métodos de desarrollo. Estas preocupaciones surgirán en breve.
La ecuación es agnóstica con respecto a si la base de activos principales y los productos se construyen completamente
desde cero, se compran listos para usar o se recuperan de productos heredados. Las funciones de costo
"devolverán" diferentes valores dependiendo de la situación.
2.3 Cprod : El costo de los productos de construcción en un standalone
Moda
Una pregunta común sobre el costo de una línea de productos es la siguiente: si planeamos construir n productos,
¿es mejor que los construyamos como una línea de productos de software o de forma independiente sin
compartir los activos principales? Responder a esta pregunta requiere conocer el costo de construirlos de forma
independiente. Presentamos Cprod (producto) como una función de costo que devuelve el costo de construir un
producto de manera independiente.4 Esta función de costo puede basarse en datos históricos o modelos generales
de costos de ingeniería de software para su evaluación. El costo de construir n productos de forma independiente,
entonces, se expresa en la Ecuación 2.
ecuación 2
norte
Costo de construir n productos de chimenea = ( producti )
Cprod
∑=
i 1
El ahorro de costos (pérdida) por construir n productos como una línea de productos versus construirlos
de forma independiente es simplemente [Ecuación 2] – [Ecuación 1].
2.4 Cevo y Ccabu : modelado del costo de la evolución de un producto Para dar cuenta de
un ciclo de evolución del producto, es decir, el momento en que un producto aparece en una nueva
versión, probablemente con características nuevas o al menos mejoradas, bajo el no producto
régimen de línea, el modelo introduce una nueva función de coste, Cevo(). Esta función se parametriza
con números de producto y versión y devuelve el costo de producir esa versión. Los modeladores podrían
4
Esta nueva función de costo Cprod se puede implementar, al menos conceptualmente, invocando Cunique para
un producto que es 100% único. En otras palabras, la introducción de Cprod no hace que nuestro modelo sea más
difícil de calcular y puede considerarse simplemente como una conveniencia notacional.
8 CMU/SEI2005TR003
haga una primera aproximación suponiendo que el costo de producir una nueva versión es un porcentaje de
producir el producto original; Por ejemplo
Cevo() = 20% * Cprod()
Para calcular el costo análogo bajo un régimen de línea de producto, introducimos una nueva función, Ccabu().
Esta función devuelve una medida de cuánto cuesta actualizar la base de activos principales como resultado del
lanzamiento de una nueva versión de un producto. Los cambios en la base de activos principales pueden ocurrir
porque la nueva versión requirió cambios o expuso errores en los activos principales existentes.
Los cambios también pueden ocurrir cuando las nuevas características exponen nuevos puntos en común con otros
productos que hasta ahora se consideraban únicos pero que ahora pueden refactorizarse en puntos en común.
2.5 Expresión de períodos de tiempo en el modelo El modelado de ciclos
evolutivos ha dejado en claro que SIMPLE debe ser capaz de manejar períodos de tiempo o al menos tener una
forma de expresar períodos de tiempo en los que ocurren eventos particulares (como una actualización). Las funciones
de costo deben interpretarse como la devolución del costo incurrido durante el período de interés.
Por ejemplo, hasta ahora, Corg() se ha aplicado como si devolviera el costo completo de la transición organizacional.
Sin embargo, los gerentes que estén interesados en incorporar líneas de productos a lo largo del tiempo pueden
realizar el trabajo organizativo por etapas. Por lo tanto, Corg() necesita contabilizar el costo durante un período de tiempo
de interés. Si todo se hace por adelantado, Corg(período_1) representa el costo total y Corg(t), para todos los
demás períodos de tiempo, devuelve cero.
De manera similar, Ccab() tiene que dar cuenta del costo de construir la base de activos básicos durante un período
de interés. Esto es especialmente relevante en el desarrollo de la línea de productos reactivos [Clements 02c,
Clements 04], que esencialmente prescribe el desarrollo de activos centrales justo a tiempo, a diferencia de un enfoque
proactivo todo a la vez en el que se construye la base completa de activos centrales. frente.
La necesidad de contabilizar los períodos de tiempo también se aplica a Ccabu(), el costo de actualizar la base de
activos básicos como resultado de producir o evolucionar un producto. Bajo un régimen de línea de productos reactivos
en el que la base de activos básicos se construye a partir de productos existentes o nuevos, Ccabu() será alta
inicialmente, pero luego bajará a medida que la base de activos básicos se estabilice y se complete. Bajo un régimen
proactivo, la base de activos básicos se estabilizará antes y Ccabu() se mantendrá más bajo y variará menos con
el tiempo. Bajo cualquiera de los dos regímenes, si el período de interés es uno en el que los productos están cambiando
sustancialmente, Ccabu() probablemente será mayor a medida que la base de activos básicos evolucione para
adaptarse a ellos.
La solución, obviamente, es parametrizar las funciones de coste de SIMPLE con el periodo de interés, para que
su implementación pueda devolver valores ajustados a ese periodo. Agregar un período de interés permite que el
modelo se vuelva mucho más flexible y tenga más fidelidad. Por ejemplo,
CMU/SEI2005TR003 9
uno puede implementar fácilmente las funciones de costo para tener en cuenta el costo del dinero en el tiempo5 , lo
que a su vez puede influir en la decisión de si incurrir en gastos de línea de productos por adelantado o eliminarlos
gradualmente con el tiempo.
En este informe, usamos t para indicar un período de tiempo de interés que podría ser un período de calendario o
corresponder a un hito o ciclo de lanzamiento de producto. Otro aspecto del tiempo que es útil para modelar tiene
que ver con los tiempos vinculantes que se aplican a las variabilidades incorporadas. El costo de proporcionar y
ejercitar las variabilidades es un factor importante para decidir qué mecanismos de variabilidad elegir. SIMPLE
se puede utilizar para ayudar a tomar estas decisiones, haciendo que los períodos de tiempo de interés correspondan a
intervalos de tiempo limitados por tiempos vinculantes aplicables, como los que se enumeran en la Web [SPL 05b].
2.6 Contabilización de los beneficios económicos de la línea de productos
Las líneas de productos de software otorgan beneficios a la organización en desarrollo además de ahorros de costos
directos. Por ejemplo, a menudo permiten que una organización lleve un producto al mercado mucho más rápido.
Podemos acomodar estos otros factores usando funciones de beneficio que son similares a las funciones de costo
introducidas en el modelo básico. A diferencia de las funciones de costo, no hay un número fijo de funciones de beneficio.
Una línea de productos puede estar destinada a (1) reducir el tiempo requerido para llevar los productos al mercado
y (2) aumentar la productividad. Solo se puede esperar que otra línea de productos aumente la satisfacción del cliente.
Otro más puede estar destinado a aumentar las ventas capturando una participación de mercado.
Agregamos funciones de beneficio al modelo como una colección de tamaño variable como se muestra en la Ecuación 3.
Ecuación 3
nbrBeneficios
Beneficios obtenidos del enfoque de línea de productos = segundo
∑ j ( )
ben
j =1
Bben es lben es un
dbe
a función eneficio
específico
beneficio yb
para ese deneficio.
onde Cada beneficio
j j
La función está parametrizada por el período de tiempo de interés ya que los beneficios pueden variar con el tiempo.
Las funciones de beneficio devuelven el valor económico de lograr ese beneficio durante el período de tiempo indicado.
Por ejemplo, lograr una alta satisfacción del cliente durante un período de implementación puede resultar en un
aumento de las ventas durante el período de formación de una línea de productos, lo que genera un beneficio económico
cuantitativo.
Las contribuciones de los beneficios se suman y luego se utilizan para construir una ecuación modelo según sea
necesario. Por ejemplo, recuerde que para expresar los ahorros (o pérdidas) en costos de desarrollo al usar el enfoque de
línea de productos en lugar del desarrollo único para cada producto, escribimos
5
Esto se refiere al costo de mantener el dinero, es decir, la pérdida de rendimiento e interés de la inversión.
10 CMU/SEI2005TR003
[Ecuación 2] – [Ecuación 1]. Una imagen más completa del costobeneficio de usar un enfoque de línea de productos agrega la
Ecuación 3 a ese resultado.
El pronosticador económico que construye ecuaciones a partir de estas funciones debe tener cuidado de no contar dos veces
algunos beneficios. Primero, muchos beneficios dan como resultado cambios en las cuatro funciones de costos y, por lo tanto,
se contabilizan allí. Por ejemplo, el aumento de la productividad a menudo se menciona como un beneficio de la ingeniería
de la línea de productos, pero el aumento de la productividad es esencialmente un costo reducido que ya se reflejará en el
costo de construir la base de activos básicos y en la suma del costo de reutilización y el valor único. porción del producto. Luego,
agregar una función de beneficios que mida los ahorros debido al aumento de la productividad daría como resultado un modelo
que exagera los ahorros.
En segundo lugar, muchos beneficios diferentes pueden conducir al mismo ahorro de costos. Por ejemplo, una mayor productividad
también podría resultar en un menor tiempo de comercialización, lo que, a su vez, podría resultar en una mayor satisfacción del
cliente. Pero una alineación más estricta del producto o una mayor calidad del producto también pueden conducir a una
mayor satisfacción del cliente. Todas estas cosas pueden conducir a un aumento de las ventas y los ingresos. Sería muy fácil
contabilizar un beneficio cuyos ahorros de costos ya se hayan contabilizado en otro beneficio. Cuidado con el modelador.
En la Sección 4.7, proporcionamos algunos ejemplos de cómo se pueden implementar las funciones de beneficio.
Por ahora, se puede considerar que las funciones de beneficio brindan una respuesta a la pregunta "¿Cuánto valdría para su
organización lograr este beneficio durante este período de tiempo?"
En un análisis de costobeneficio, el beneficio más visible es el ingreso derivado de la venta de los productos. Si el modelador se
está concentrando en los costos de desarrollo de software, es posible que la cifra de ingresos deba ajustarse en función de la
parte del producto proporcionada por el software. El modelo debe reflejar cuándo se generan estos ingresos. En la Sección 2.5,
analizamos cómo hacer esto haciendo que las fórmulas sean específicas para un período de tiempo.
Peterson proporciona una sólida lista de beneficios (varios de los cuales no se citan con frecuencia) al describir por qué su
empresa (Convergys) eligió el enfoque de línea de productos de software [Peterson 04]. Su lista puede servir como un buen
punto de partida para producir un conjunto útil de funciones de beneficio:
• inversión en investigación y desarrollo (I+D): la capacidad de aprovechar la inversión en I+D en toda la familia de
productos mediante la reutilización de un conjunto común de componentes
• experiencia en la materia: la capacidad de aprovechar a los expertos en la materia en todo el
familia de productos mediante la concentración de expertos en la materia del dominio con habilidades y conocimientos
similares en grupos centralizados que sirven a todos los productos
• productividad y calidad: mejorar la productividad y la calidad rompiendo grandes,
aplicaciones monolíticas en proyectos más pequeños y manejables y mediante el uso de componentes que encapsulan la
funcionalidad de las aplicaciones
• tiempo de comercialización: aumentar la tasa de entrega de nuevas capacidades al mercado y
permitir que los nuevos productos se entreguen más rápido mediante la reutilización de componentes bien establecidos
CMU/SEI2005TR003 11
• movilidad de las personas: proporcionar a los empleados más oportunidades de desarrollo profesional
estandarizar el entorno y los procesos de desarrollo, reduciendo así la curva de aprendizaje asociada con el paso a un
nuevo proyecto
• relaciones con los proveedores: estandarización de las plataformas y el entorno de desarrollo
permite un aprovechamiento más eficaz de las relaciones con los proveedores
• flexibilidad geográfica: la estandarización del desarrollo basado en componentes facilita la distribución de las
responsabilidades de desarrollo entre ubicaciones
• flexibilidad de abastecimiento: usar una arquitectura modular para permitir una mayor flexibilidad para construir,
licenciar o adquirir software
• actualización del producto: uso de una arquitectura modular para facilitar el proceso de actualización de la familia de
productos a medida que se encuentran disponibles nuevas tecnologías y/o componentes de software
12 CMU/SEI2005TR003
3 escenarios
Con SIMPLE ahora completamente introducido, esta sección brindará ejemplos de su uso para resolver un conjunto de
escenarios que representan situaciones de la vida real en organizaciones de línea de productos.
3.1 El costo de construir una línea de productos de software
Escenario: una organización desea conocer el costo de producir un conjunto de productos como una línea de
productos de software.
El costo se puede expresar mediante la Ecuación 4:
ecuación 4
Costo de construir una línea de productos =
norte
Ct C( )
t ( ) ( ( , ) C
taxi ( + ∑ úp roducto t t , ))
organización nico
C producto i ++ reutilizar i
i=1
El parámetro de tiempo t se refiere al período de tiempo completo durante el cual se construyen la base de activos principales
y los primeros lanzamientos de cada producto. Como se señaló en la Sección 2, esta ecuación no tiene en cuenta ninguna
evolución.
3.2 El costo de construir una línea de productos de software vs. Construyendo los
productos de forma independiente
Escenario: Una organización desea elegir entre construir un conjunto de productos como una línea de productos de
software y construirlos como un conjunto de productos independientes que no comparten
activos básicos.
El ahorro de costos (pérdida) por construir n productos como una línea de productos versus construirlos como productos
independientes es simplemente [Ecuación 2] – [Ecuación 1]:
Ecuación 5
Ahorro de costos de construir una línea de productos frente a productos independientes =
norte
C producto
( , )
pinchar
t –i
∑=
i 1
Ct
norte
C t + ( ( )
único taxi ( )
+
( ( , )
C ∑ C (producto
producto t t , )))
i + reutilizar i
organización
i=1
CMU/SEI2005TR003 13
Ejemplo 1: Suponga que hay cinco productos, todos aproximadamente del mismo tamaño y complejidad, y cada
uno cuesta alrededor de tres añospersona (PY) para construir como un proyecto independiente. Desde Cprod()
= 3PY, la Ecuación 2 arroja 15PY como el costo de construir la familia por separado.
Supongamos que se necesitan alrededor de 2PY para construir la base de activos básicos para estos cinco productos:
Ccab() = 2PY
Y supongamos que se necesita alrededor de 1 PY para cambiar la organización:
Corg() = 1 año
Supongamos además que cada producto tiene aproximadamente la mitad de activos principales y la mitad de
contenido único y, por lo tanto, Cunique() = 50% * 3PY = 1.5PY. Debido a que la literatura sobre reutilización6
sugiere que el uso de software reutilizable puede costar alrededor del 15% de su construcción, Creuse() = 15%
de la mitad de 3PY, o 0.225PY.7 Por lo tanto, la Ecuación 1 arroja 1PY + 2PY + 5(1.5PY + . 225PY) = 11.625PY.
El ahorro de costos del enfoque de línea de productos en este caso, entonces, es 15PY – 11.625PY =
3.375PY. Este ahorro se calcula sobre un solo período de tiempo (el período de creación de los productos), y
el escenario no tiene en cuenta ningún cambio en los productos o los activos principales a lo largo del tiempo.
3.3 Costo de lanzar una nueva versión de un miembro de la línea de productos
Escenario: una organización desea saber el costo de lanzar una nueva versión de un producto en una línea de
productos de software que ya existe.
El costo de lanzar una nueva versión de un producto en una línea de productos viene dado por la Ecuación 6
(que supone que ya se han asumido todos los costos de creación de activos centrales originales y de la organización):
Ecuación 6
Costo de lanzar una nueva versión de un producto en una línea de productos ya existente = () ()
Ccabu + Cunique + Creuse ()
donde todos los términos están adecuadamente parametrizados para dos propósitos: (1) para designar el
producto específico y la versión de interés, así como el período de tiempo durante el cual se realizará la
actualización y (2) para señalar que la versión es una actualización y no es un nuevo desarrollo. Esta ecuación
dice que el costo de una actualización es el costo de actualizar la base de activos básicos más el
6
Este valor es el valor aceptado para la reutilización oportunista. Una línea de productos tendrá un valor menor
al 15% porque no hay costo de búsqueda o calificación. El modelo COPLIMO de Boehm utiliza una cifra de
alrededor del 5%. Usamos 15% como una estimación muy conservadora en este ejemplo, pero sugerimos que
cada empresa mida su costo local.
7
Observe que Cunique y Creuse son funciones de la fracción de cada producto que proporciona la base de
activos básicos. A medida que esa fracción aumenta, la primera disminuye y la segunda aumenta.
14 CMU/SEI2005TR003
costo de la parte única del cambio más el costo de usar la base de activos principales actualizada para realizar el
cambio.
Si todos los productos en una línea de productos se actualizan al mismo tiempo, esta ecuación se puede sumar sobre el
conjunto de productos para calcular el costo total de una actualización evolutiva.
Ejemplo 2: Suponga que cada vez que se actualiza un producto de la línea de productos del Ejemplo 1, alrededor del 20 %
es nuevo. Suponga también que bajo un régimen de línea de productos, aproximadamente el 5% de la base de activos
básicos (que, recuerde, representa una inversión de 2PY) se actualiza como resultado de una actualización del producto.
Suponga que dado que la base de activos básicos representa aproximadamente la mitad del producto (como se postula en
el Ejemplo 1), también representará aproximadamente la mitad de la parte nueva del producto. Por lo tanto, la actualización
de nuestro producto (que consiste en una adición de aproximadamente un 20 % del tamaño del original) consta de la
mitad de código nuevo y la mitad de código de activos principales. Por lo tanto
• Ccabu() = .05 * Ccab()
• Ccab() = 2PY
• Cunique() = 1.5PY para un producto completo, y por lo tanto 10% * 1.5PY para una actualización
• Creuse() = .225PY para un producto completo, y así 10% * .225PY para una actualización
Entonces la Ecuación 6 regresa
.05*2PY + 10%*1.5PY + 10% *.225PY = 0.2725PY
Esto se compara favorablemente con Cevo() = 20% * Cprod() = 20%*3PY = 0.6PY, que es lo que tomaría una actualización
de producto bajo el régimen independiente.
Sin embargo, la Ecuación 6 no tiene en cuenta el costo de configurar la línea de productos para poder realizar
actualizaciones económicas. La siguiente sección se ocupará de eso.
3.4 Comparación del costo de conversión a una línea de productos vs.
Continuar con la evolución de un conjunto existente de productos independientes
Escenario: una organización tiene un conjunto de productos independientes existentes que se someten a actualizaciones
evolutivas periódicas. Sus gerentes podrían desear saber cuál es más barato:
• Opción A: convertirlos en una línea de productos y continuar su evolución en esa
forma
• Opción B: continuar desarrollándolos por separado y renunciar al costo de establecer el
línea de producto
El costo de la opción A para un ciclo evolutivo es el costo de establecer la línea de productos más el costo de evolucionar
los productos una vez que se utiliza la base de activos básicos. En otras palabras, el costo de la opción A es la Ecuación 4
más la Ecuación 6 sumados a los productos de la línea de productos:
CMU/SEI2005TR003 15
Ecuación 7
Costo de establecer una línea de productos y evolucionarla a través de un ciclo =
() (i )) +
norte
Corg ( reutilizar
=
i 1
norte
( cabu ( C + Producto
∑ Producto i ) C (+ Producto
único i ) C reutilizar
( i ))
=
i 1
Sin embargo, cuando configuramos la base de activos básicos y rediseñamos los productos para este
ejemplo, podríamos tomar un atajo. Podríamos apuntar a producir activos centrales y rediseñar los productos
para respaldar su próximo ciclo evolutivo. Bajo esta opción, la Ecuación 6 desaparece, ya que el costo de
instalación dado por la Ecuación 4 apuntará al próximo paso en la trayectoria evolutiva de los
productos. Así que simplemente tenemos
ecuación 8
Costo de montar una línea de productos que apunte al primer ciclo evolutivo =
norte
Corg ( () (i )) reutilizar
=
i 1
El costo de la opción B para un ciclo evolutivo es simplemente Cevo() sumando cada producto en el portafolio:
ecuación 9
norte
Costo de evolucionar un grupo de productos independientes a través de un ciclo = ( producti )
cevo
∑=
i 1
El ahorro de costos (si lo hay) de convertir los productos en una línea de productos y llevarlos a través de un
ciclo evolutivo es la Ecuación 9 Ecuación 8:
ecuación 10
Ahorro de costos de configurar y desarrollar una línea de productos una vez
frente a un grupo en evolución de productos independientes una vez =
norte norte
( () + Ccab +∑ C(unique producti )+ C producto
Cevo producti – [ ()
Corg ( ( ) i )) ] reutilizar
∑=
i 1
=
i 1
Los ahorros de costos por pasar del primer paso evolutivo al segundo se pueden expresar de manera similar:
simplemente como Ecuación 9 – Ecuación 6 sumando todos los productos, porque en este punto la línea de
productos ya se habrá configurado:
dieciséis CMU/SEI2005TR003
Ecuación 11
Ahorro de costos del segundo paso evolutivo con una línea de productos =
norte
cevo
( ) producti –
∑=
i 1
norte
∑ C( cabu
( producti )+ C p (
roducto
único
) roducto(
+ Ci p reutilizar i ))
i=1
Aquí, las funciones se invocan para devolver los costos asociados con las actualizaciones de productos, no productos
completos.
La misma ecuación expresa el ahorro de costos al pasar del paso p al paso (p+1) st, siempre que p>1 y la línea de
productos ya esté configurada. Para sumar los ahorros de costos de establecer la línea de productos y evolucionarla
en p rondas, agregue la Ecuación 10 a la suma de la Ecuación 11 para cada una de las próximas (p1) rondas.8
Ejemplo 3: Suponga que p es 5. Entonces los ahorros en costos son iguales a
4
Ecuación 11 o
Ecuación 10 + ∑t 1=
norte norte
( () + Ccab +∑ C(unique producti
Cevo producti – [ ()
Corg )+ C producto
( ( )i )) ] + reutilizar
∑=
i 1 i=1
4 norte
( cevo
( ) producti –
∑=
i 1 ∑=
i 1
norte
∑ C( cabu
( producti )+ C p
único
((
) roducto
roducto + Ci p reutilizar i ))
i=1
Sustituyendo los valores anteriores da
5 5 4 5
2 – [1 py p
3
PY y+∑
PY
+ PY+ (1.5 .225 ) ( .6 –
∑=
i 1 i=1
] + ∑i =1 ∑=
i 1
5
+.0225)) = 9.925 PY
∑ (.05) * 2 PY + 0.15
i=1
8
Si los costos de cada ronda son los mismos, la Ecuación 8 puede simplemente multiplicarse por (p1).
CMU/SEI2005TR003 17
3.5 Retorno de la inversión (ROI)9 Escenario: una
organización desea conocer el ROI logrado al establecer una línea de productos de software y
utilizarla como base para la evolución del producto. Se desea conocer el ROI tras la primera ronda
de evolución y tras rondas posteriores.
Muchas organizaciones desean comprender los costos de adopción y mantenimiento de la línea de productos en
términos del ROI, que generalmente se define como
ROI = ahorro de costos / costo de inversión El costo
de inversión de una línea de productos es el costo organizacional más el costo de establecer la base de activos
principales: Corg() + Ccab().
El ahorro de costos depende del escenario específico. Supongamos que continuamos con el ejemplo de la
sección anterior: una organización desea elegir entre continuar con la evolución de un conjunto de productos
independientes y convertirlos en una línea de productos. El ROI después de una ronda de actualizaciones es
la Ecuación 10 dividida por el costo de inversión:
Ecuación 12
ROI logrado después de una ronda de evolución de una línea de productos =
norte norte
Cevo ( () + Ccab +∑ C( unique producti

( )producti – [ ()
Corg ) + C producto
( i
)) ] reutilizar
∑=
i 1 i =1
Corg() + Ccab()
El ROI después de p rondas de actualizaciones (p>1) es la Ecuación 10 más (p1) iteraciones de la Ecuación 11,
todas divididas por Corg() + Ccab().
Ejemplo 4: Continuando con el Ejemplo 3 de la sección anterior, vemos que el costo de inversión de Corg() + Ccab()
es 3PY, por lo que el ROI a través del inicio y cuatro rondas de actualizaciones es 9.925/3 = 331%.
3.6 Construcción y evolución de una línea de productos Escenario: una
organización no tiene líneas de productos y desea producir s1 productos. La organización desea saber
los ahorros de costos (si los hay) que se acumularán durante los períodos de tiempo de "nbr_periods" de
la construcción de los productos s1 utilizando una línea de productos en comparación con la construcción
y evolución de ellos de manera independiente.
9
Se utilizan varias medidas financieras para las decisiones de inversión, como el valor actual neto (NPV) y el
período de recuperación. Cualquiera de ellos se puede calcular utilizando la información de las funciones
de costo y beneficio. En este informe, lo ilustramos usando un cálculo de ROI simple.
18 CMU/SEI2005TR003
Hay dos maneras de procesar este escenario. La primera es traduciendo "nbr_periods" en el escenario a un número p de
actualizaciones evolutivas y luego usando las Ecuaciones 7 y 8 como se discutió anteriormente, es decir, sumando el
resultado de la Ecuación 7 a (p1) veces el resultado de aplicar la Ecuación 8 .
La segunda forma es utilizar las funciones de costo parametrizadas con el período de tiempo de interés e interpretadas en
consecuencia. La creación y evolución de una línea de productos en unidades de tiempo "nbr_periods" se puede
expresar de la siguiente manera:
Ecuación 13
Costo de construir y evolucionar la línea de productos durante períodos de tiempo de "nbr_periods" =
n n
nbr _períodos j j
∑ C t C( )
t + cabu + ∑Punto
+único Ci ( , )
∑ ( ) ( , ) Punto C
organización
i
reutilizar
t=1 i=1 i=1
La ecuación 13 requiere que el modelador determine lo siguiente en cada período: cuánto costo organizacional
se incurrió, cuánto se actualizó la base de activos principales,10 cuánto costo de desarrollo único del producto se
incurrió y cuánto costo de reutilización se incurrió. Los dos últimos términos devuelven los costos de evolución para
aquellos períodos de tiempo en los que se está produciendo la evolución.
A continuación, calculamos el costo de construir y evolucionar los productos s1 de manera independiente (usando la
Ecuación 2) y lo sumamos durante los mismos períodos de tiempo:
Ecuación 14
nbr _períodos ∑ ∑
s1
Costo de uno a la vez = C producto
( t , )
i
pinchar
t= 1 i=1
Este escenario se “resuelve” tomando la diferencia de estas dos expresiones.
El uso de períodos de tiempo permite a los modeladores experimentar con diferentes esquemas para construir la base de
activos básicos y (por ejemplo) ver qué tan pronto pueden lograr un ahorro de costos positivo.
3.7 Redistribución de productos entre líneas de productos existentes
Escenario: una organización tiene n líneas de productos, cada una de las cuales comprende un conjunto de productos, y
también tiene s1 productos independientes. La organización desea hacer la transición al estado en el que tiene m líneas
de productos, cada una de las cuales comprende un conjunto de productos (quizás diferente), y también s2
productos independientes. La organización desea determinar la división óptima de productos entre el número
óptimo de líneas de productos para minimizar el costo de construcción inicial y mantenimiento para la vida
esperada de cinco años.
10
Como se mencionó anteriormente, la mayor parte de la base de activos básicos podría haberse construido por adelantado o se podría haber incorporado gradualmente a
lo largo del tiempo.
CMU/SEI2005TR003 19
Este es un problema de optimización que requiere una búsqueda del espacio de solución posible (es decir, todas
las asignaciones posibles de productos a líneas de productos) para identificar el valor óptimo. Cada punto en el
espacio de búsqueda tiene una cantidad específica de líneas de productos, cada una con un conjunto específico
de productos y una cantidad específica de productos independientes. A medida que cambia la colección de productos
en cada línea de productos, también cambia la cantidad de elementos comunes u homogeneidad. Esto, a su vez,
cambia el valor devuelto por Ccab (dado que la base de activos básicos es responsable de proporcionar
esa característica común) y las sumas de los valores de Cunique y Creuse . La diferencia entre las líneas de
productos es el tamaño de la base de activos básicos en relación con el tamaño de las partes únicas de los productos.
El costo de cada solución posible para este escenario está dado por
Ecuación 15
numeroDePeriodos npl
Ct ( )
Ct
s2 _
, jxn, s C t ( )
Nueva Jersey
COSTO
( npl ( ( )
= ∑ ∑ + +∑ ) ( ( , ) cabu
Punto
C
p t Ci
único
+
reutilizar
∑ i ( , )) )
+
1 1 1 prod
organización
t=
j = i= i=1
dónde
• Sx es el número de productos independientes y varía en todos los valores de s1+ sum(nj)
productos
•
nj = número de productos en la jésima línea de productos.
• npl, el número de líneas de productos, está entre 0 y s1+ sum(nj) productos.
• númeroDePeríodos = 5.
La solución para el escenario es encontrar m y mj para los cuales se minimiza el costo (m, mj, sx) .
Eso define un espacio de búsqueda grande pero finito. El trabajo futuro explorará cómo una métrica de
homogeneidad, una medida de cuánto se parecen los productos en una línea de productos, ayudaría a reducir este
espacio de búsqueda.
3.8 Adición de nuevos productos a líneas de productos existentes Escenario: una organización
tiene n líneas de productos, cada una de las cuales comprende un conjunto de productos, y también tiene s1 productos
independientes. La organización pretende sumar productos k. Desea determinar la asignación óptima de los k
productos sobre las líneas de productos existentes en función de los costos de mantenimiento previsibles durante los
próximos períodos de tiempo "nbr_periods".
Este escenario se puede resolver agregando un producto a la línea de "mejores" productos, uno a la vez. Para
calcular la "mejor" línea de productos a la que asignar un producto independiente, calculamos el costo de agregar
ese producto a cada línea de productos y el costo de mantener esa línea de productos con el nuevo producto
agregado. La línea de productos con los costos más bajos en estas dos áreas es la “mejor”.
20 CMU/SEI2005TR003
El costo de agregar un producto a una línea de productos (suponiendo que esto se haga en un solo período de tiempo t) es
Ecuación 16
Corg(t) + Ccab(t, PL, producto) + Creuse(t, PL, producto) + Cunique(t, PL, producto)
donde el parámetro PL indica la línea de productos candidata a la que estamos agregando el producto. Esta
parametrización nos recuerda calcular las funciones de coste de forma diferente en función de las distintas líneas de productos.
El costo de mantener esa línea de productos con el nuevo producto en ella durante períodos de tiempo de "nbr_periods" es la
ecuación del escenario n.º 2 anterior.
Repetir la aplicación de la Ecuación 16 y la Ecuación 2 para cada uno de los k productos produce la asignación óptima de
productos a las líneas de productos.
En la práctica, sin embargo, el orden puede ser importante. Es decir, colocar los tres primeros productos en la línea de productos
n.° 2 podría dar como resultado que la línea de productos n.° 2 esté mucho mejor posicionada para aceptar el producto n.° 4.
Sin embargo, si hubiéramos comenzado con el producto #4, podría haber sido asignado a la línea de productos #1.
En teoría, podemos abordar este problema calculando el costo de todas las asignaciones posibles de los productos k en todos
los pedidos posibles y obtener los costos mínimos. En la práctica, esto será insostenible, pero probablemente querremos probar
solo unas pocas hipótesis de asignación específicas, en lugar de todas las posibles.
3.9 Construir vs. Escenario
de compra : una organización tiene n líneas de productos, cada una de las cuales comprende un conjunto
de productos, y también tiene s1 productos independientes. La organización pretende sumar
productos k. Desea determinar la división óptima entre construir y comprar los activos adicionales
necesarios para los k productos. Los productos se construirán en el primer año y se mantendrán
durante cuatro años adicionales.
Este escenario se basa en el escenario de la Sección 3.7. Al agregar k productos, la cantidad de líneas de productos, la
cantidad de productos en cada línea de productos y la cantidad de productos independientes pueden cambiar. Una vez que
se ha determinado el arreglo óptimo como en el cuarto escenario, se identifican los nuevos activos necesarios. El problema
ahora es cómo optimizar el costo de los nuevos activos.
El costo de conducción es Ccab(t). En la mayoría de los escenarios, Ccab(t) devuelve el costo original de todos los activos.
En el caso de que se deban realizar pagos de arrendamiento o regalías y t > 1, Ccab(t) devuelve el costo adicional por
los pagos de ese año. En el caso de que los activos sean de creación propia y t > 1, Ccab(t) devuelve el importe previsto para el
mantenimiento.
CMU/SEI2005TR003 21
La solución para el escenario es la combinación de nuevos activos que requiere el menor gasto.
Esta solución está por debajo del nivel de visibilidad de la ecuación de la línea de productos y se
manejaría en la implementación de Ccab(t). La Sección 4 presenta algunas ideas sobre la
implementación de las funciones de costos.
22 CMU/SEI2005TR003
4 Enfoques para Implementar Costo y Beneficio
Funciones
El nombre de nuestro modelo, SIMPLE, indica dos atributos por los que nos esforzamos: estructurado
e intuitivo. Definimos intencionalmente el modelo en términos de un conjunto de funciones de costo y
beneficio para permitir que los usuarios proporcionen capas de implementaciones. Esta estructura permite al
modelador conducir el modelo hasta el nivel de detalle para el cual se pueden proporcionar datos suficientemente
precisos. Esta estructura permite que el modelo sea intuitivo para una amplia gama de personas al permitirles
ver el nivel del modelo que les resulta más útil. En esta sección, describimos algunas formas de implementar
las funciones descritas en la Sección 2.2.
Los modeladores comienzan su trabajo con diferentes niveles de información. Algunos tendrán datos de
proyectos anteriores que no pertenecen a la línea de productos, algunos tendrán datos de proyectos anteriores
de la línea de productos y otros no tendrán ningún dato anterior. SIMPLE permite diferentes enfoques basados
en el conocimiento disponible.
4.1 Uso de los datos históricos propios de una organización El caso más simple de
implementación de funciones es cuando el usuario tiene estimaciones para cada costo.
Algunos de los datos pueden provenir de información histórica, como el costo promedio de construir un producto
único. Como ejemplo, las cuatro funciones de costos de la Ecuación 1 se reemplazan con estimaciones de costos
(CE) en la Ecuación 17:
Ecuación 17
norte
( CEproducti único
CEorg + CEcab +∑ ) + CE producto
( (i )) reutilizar
i=1
El uso de datos históricos es el enfoque más simple, pero quizás no el más fácil. El modelador debe tener una
amplia experiencia cuantificada con los procesos de desarrollo de la organización y ser capaz de predecir los
costos futuros en función de la experiencia pasada. Eso no siempre es posible si los productos futuros son
diferentes a los productos anteriores.
4.2 Puntos de referencia de la comunidad La
literatura sobre la línea de productos está construyendo lentamente una intuición sobre muchos de los
costos. Estos valores se pueden utilizar como punto de partida para las organizaciones que no tienen registro de desarrollo
CMU/SEI2005TR003 23
historia propia. Por ejemplo, el costo de fabricar un componente que sea reutilizable se estima ampliamente en
el 150 % del costo de construir el componente para un solo uso, mientras que el costo de reutilizar el software
reutilizable se cree que es menos del 5 % del costo de construyéndolo nuevo (si no hay que ir a buscarlo)
[Boehm 04]. Gaffney y Cruickshank muestran cómo usar líneas de código estimadas y puntos de referencia
de esfuerzo estándar de la industria para producir estimaciones de costos [Gaffney 92].
Boehm ha revisado los controladores de costos en COCOMO para definir un nuevo conjunto para el Constructivo
Modelo de Inversión en Línea de Producto (COPLIMO) [Boehm 04]. Teniendo en cuenta el costo de construir
productos desde cero en una línea de productos, los datos de COPLIMO muestran que entre dos y tres
productos es el punto de equilibrio, como lo respalda gran parte de la literatura sobre líneas de
productos [Clements 02b]. COPLIMO se discutirá en la Sección 7.2.
4.3 Funciones de utilidad Las
funciones de utilidad se pueden usar para ayudar a estimar un costo en cada uno de varios períodos de
tiempo consecutivos. Una acción o activo tiene un costo (o valor). Ese costo puede incurrirse en todos a la vez o
con el tiempo. Un modelador puede asignar un valor a cada uno de un conjunto de resultados. La función de
utilidad tiene un mínimo, generalmente 0, y un máximo que a menudo se toma como 1 o 100%. Una
función de utilidad, u(t), devuelve la cantidad de utilidad (costo o valor) para un período de tiempo t.
Por ejemplo, si el costo esperado de un activo es c dólares, a pagar en cuatro cuotas iguales durante
cuatro períodos de tiempo, la curva de utilidad se parece a la que se muestra en la Figura 2, y u(t) = 1/4 para
t= 1, 2, 3 o 4. El costo esperado se calcula mediante: c*u(t) o c/4 para cada período.
4/4
3/4
valor
1/2
1/4
1 2 3 4
periodo de tiempo
Figura 2: Curva de utilidad uniforme
Los modeladores pueden usar una función de utilidad para traducir sus suposiciones sobre un escenario
en una cantidad. Por ejemplo, una función de utilidad que tenga la forma dada en la Figura 3 proporcionaría
el comportamiento de todos los costos asignados en el primer período y cero a partir de entonces. El
modelador puede seleccionar una curva cuya forma coincida con las suposiciones sobre el escenario.
24 CMU/SEI2005TR003
1.0
valor
123
periodo de tiempo
Figura 3: Función de utilidad
Estas funciones de utilidad se pueden usar para ayudar a definir las funciones de costo. Por ejemplo, Corg se puede
definir estimando el costo total y luego asociándolo con una función de utilidad como la de la Figura 4, donde se
incurre en dos tercios del costo en el primer período de tiempo y un tercio en el segundo período de tiempo.
1.0
valor
0,67
0.33
123
periodo de tiempo
Figura 4: Función de utilidad de paso
Las funciones de utilidad se utilizan con mayor frecuencia como un multiplicador de un costo estimado o previsto. En
una ecuación, un modelador puede incluir un término de esta forma:
costo*u(t)
Este término producirá el valor del costo de cada iteración. Por ejemplo, considere un escenario en el que el
costo total de mover una organización, Corg, es de $150 000. En este escenario, el modelador selecciona la función de
utilidad que se muestra en la Figura 4. El término de costo costo*u(t) produce
CMU/SEI2005TR003 25
valores de $100,000 en el primer período, $50,000 en el segundo período y cero para cualquier período posterior. El
modelador cambia los supuestos cambiando la función de utilidad.
4.4 Cuantificación de valores no numéricos El método de análisis
de costobeneficio (CBAM) de SEI es una técnica para realizar un análisis de costo/beneficio en las decisiones de
arquitectura [Kazman 02]. Incluye un enfoque para cuantificar los beneficios de las decisiones de arquitectura.
4.5 Divide y vencerás Las definiciones de
las funciones de costo pueden definirse descomponiendo su definición en otras funciones. Por ejemplo, un factor
que contribuye a Ccab() es el costo de establecer la arquitectura de software de la línea de productos. Este costo
puede, a su vez, descomponerse más. Peterson sugiere la siguiente lista [Peterson 04]:
• análisis de dominio: el análisis de dominio se ocupa de comprender y documentar
las similitudes y variaciones de los requisitos.
• arquitectura de destino: la arquitectura de destino especifica los límites, el alcance, las interfaces y los
puntos de variación de los componentes comunes.
• estándares tecnológicos: se debe acordar un conjunto común de estándares tecnológicos que se ocupen de los
sistemas operativos, los lenguajes de programación, los sistemas de administración de bases de datos, las
tecnologías de interfaz gráfica de usuario y los estándares de “aspecto y sensación” de la interfaz de usuario.
• arquitectura actual: Para establecer planes de migración de arquitectura realistas, se
es necesario comprender las arquitecturas actuales empleadas en toda la familia de productos.
• estrategia y plan de migración: la estrategia y el plan de migración de la arquitectura conforman la hoja de ruta para
hacer evolucionar la familia de productos existente hacia la arquitectura de destino.
De manera similar, Corg() se puede descomponer en el costo de capacitación, el costo de recopilación de datos, el
costo de reorganización, el costo de establecer los procesos necesarios, etc. Por supuesto, todo el enfoque de función
de costos de SIMPLE se basa en una técnica de "divide y vencerás" que simplemente amplía la idea.
4.6 Inferencia
A veces es posible inferir el valor de una función de costo si conoce la información clave que se relaciona con ella. Por
ejemplo, se puede estimar Ccab() si conoce el nivel de reutilización en una línea de productos, es decir, cuánto de
cada producto en promedio proviene de la base de activos básicos.
Por ejemplo, si el nivel de reutilización es del 70 % (una cifra modesta para una línea de productos de software), la
base de activos principales asumirá la carga, en promedio, del 70 % de cada producto. Si cada producto cuesta
aproximadamente lo mismo para construir de forma independiente (es decir, tiene el mismo valor de Cprod() ),
26 CMU/SEI2005TR003
la base de activos básicos asumirá alrededor del 70% * Cprod() del costo. Pero el costo de hacer que el software
sea reutilizable es aproximadamente el 150 % de hacerlo en primer lugar, por lo que Ccab será 150 % * 70 % * Cprod().11
Ahora tenemos dos nuevas funciones para calcular: (1) cuánto cuesta construir software reutilizable (la función
Freusable ) y (2) qué tan comunes son los productos (la función Fcommon ).
Sin embargo, estas funciones pueden ser más fáciles de proyectar que Ccab por sí mismo.
Del mismo modo, Creuse es el costo de reutilizar artefactos reutilizables, que según la literatura puede representar hasta
un 15% del costo de construirlos desde cero. Dado que la base de activos básicos soporta una parte de la carga de cualquier
producto igual a Fcommon, para obtener esa proporción de un producto se requiere una inversión de Fcommon
*
base de activos básicos es el 15 % del 70 Cprod * 15%. Entonces, si Fcommon es 70%, el costo de reutilizar el
% del costo independiente del producto.
4.7 Aproximación bruta Si las aproximaciones
de primer orden revelan una preferencia abrumadora entre las alternativas sobre la mesa, es posible que no sea
necesario realizar más modelos. Un ejemplo de una aproximación aproximada es suponer que Ccabu es una
fracción fija de Ccab. Esta aproximación dice que el costo de actualizar la base de activos principales después de cada
lanzamiento del producto es (por ejemplo) el 10 % del costo de crearlo, lo que no es una suposición irrazonable. De
manera similar, un modelador podría establecer Cevo en una fracción fija de Cprod, diciendo que evolucionar un
producto cuesta (por ejemplo) el 15% de construirlo en primer lugar.
4.8 Implementación de la Función de Beneficios Está más allá del
alcance de este informe discutir en detalle cómo se implementan las funciones de beneficios; sin embargo,
proporcionaremos un ejemplo. Considere el beneficio de una mayor satisfacción del cliente. Una técnica para
cuantificarlo seguiría estos pasos:
• Desarrollar una clasificación de clientes para que formen grupos homogéneos con
con respecto a las dimensiones de los productos para los que estamos midiendo la satisfacción (por ejemplo, precio o
conjuntos de características).
• Recopilar datos sobre la satisfacción de los clientes y la probabilidad de que vuelvan a comprar en la empresa.
• Mantener datos sobre el nivel de compra promedio para cada clasificación.
• Después de implementar la línea de productos, mida el aumento (disminución) en
satisfacción del cliente por grupo. Multiplicar el aumento de la satisfacción, en porcentaje, por
11
Esta aproximación está llena de suposiciones, como (a) todos los productos tienen aproximadamente el mismo
costo independiente y (b) la base de activos básicos representa el mismo 70% en cada producto. Si
esos supuestos no se cumplen, Ccab tendría que calcularse utilizando los costos de producto por producto.
CMU/SEI2005TR003 27
la compra promedio por grupo. Sume todas las clases para determinar el beneficio de satisfacción del
cliente.
Considere un fabricante de automóviles que desea agregar un controlador personalizable en masa
sistema de informacion. La compañía monitorea tres categorías de clientes: uso personal, uso comercial interno y
uso de alquiler. El nivel de satisfacción se registra en la Tabla 1 como el porcentaje de clientes que probablemente
volverán a comprar.
Tabla 1: Datos iniciales
Categoría Nivel de Satisfacción Compra Anual Promedio $25,000

Uso personal 95%
negocio interno 80% $200,000

usar
uso de alquiler 85% $2,000,000
Una vez que se produce la línea de productos, los datos del cliente se recopilan nuevamente (o se pronostican a
través de encuestas de marketing). Los nuevos datos se muestran en la tercera columna de la Tabla 2.
Tabla 2: Satisfacción Después de la Línea de Productos
Categoría Nivel de Nuevo nivel de Promedio anual

Satisfacción Satisfacción Compra
Uso personal 95% 95% $25,000

negocio interno 80% 90% $200,000
usar
uso de alquiler 85% 90% $2,000,000
El beneficio se calcula en la Tabla 3. Los $120,000, en la última línea, es el resultado devuelto por la función de
beneficio.
Tabla 3: Cálculo de beneficios
Categoría Nivel de Nuevo nivel de Aumentar Promedio Aumento esperado en

Satisfacción Satisfacción en Satis Anual las ventas debido a
facción Compra Aumento de clientes
Satisfacción
Uso personal 95% 95% 0 $25,000 0
Uso 80% 90% .1 $200,000 20,000

comercial interno
uso de alquiler 85% 90% .05 $2,000,00 0 100,000
Total $120,000
Hay otras formas de cuantificar la satisfacción del cliente y una amplia gama de enfoques para cuantificar otros beneficios
intangibles.
28 CMU/SEI2005TR003
4.9 Implementación de la métrica de homogeneidad La métrica
de homogeneidad proporciona una indicación del grado en que una línea de productos es
homogénea, teniendo en cuenta el hecho de que no todos los productos exhiben las
mismas similitudes. La métrica varía de 0 a 1, donde 0 indica que todos los productos son totalmente
únicos y 1 indica que los productos son exactamente iguales. El análisis de la métrica de la
pregunta de la meta (GQM) utilizado para derivar esta métrica se muestra en el Apéndice A.
La premisa fundamental de GQM es que existe una relación directa entre los elementos comunes a nivel de características
y los elementos comunes a nivel de activos básicos. No siempre es así, pero es suficiente para nuestros propósitos. También
normalizamos los requisitos para que cada requisito represente la misma cantidad de esfuerzo que los demás.
Los requisitos para un producto Pi es la unión de los requisitos de la línea de productos que se aplican a
Pi y los requisitos exclusivos del producto Pi:
Rp = Rpl
i Pi
RuPi
Definimos la métrica de homogeneidad de la siguiente manera:
número de productos
R ∑ | tu
yo
|
− i=1
homogeneidad = 1
| RT |
Notación:
PL = línea de productos
U = único
R = un requisito funcional de un producto
RT = el conjunto de todos los requisitos
| RT |= el número total de requisitos diferentes
Esta métrica mide el porcentaje del conjunto total de requisitos que son únicos. Si todos los requisitos son únicos, la
homogeneidad es cero. Si son iguales, la homogeneidad es una.
CMU/SEI2005TR003 29
30 CMU/SEI2005TR003
5 Aplicación de SIMPLE en la práctica
La experiencia con la aplicación de SIMPLE en un entorno industrial es limitada hasta la fecha, pero a través
de un compromiso temprano ha surgido el siguiente esquema de proceso:
1. Realice un taller. Este paso reúne a las personas de la organización que tienen
preguntas que desean responder vía SIMPLE. El objetivo del taller es establecer respuestas de
referencia a las siguientes preguntas:
a. ¿Cuáles son las líneas de productos de interés?
b. ¿Qué productos están actualmente involucrados o planeados para el futuro?
C. ¿Cuáles son los escenarios para los que deseamos construir un modelo?
d. ¿Qué alternativas se están considerando?
mi. ¿Cuáles son los beneficios anticipados de cada uno?
F. ¿Cuáles son los costes previstos de cada uno?
gramo. ¿Cuáles son los horizontes temporales relevantes? (por ejemplo, fechas de lanzamiento, fechas de prueba)
2. Formule el modelo SIMPLE. Los modeladores construyen fórmulas basadas en la
escenario y las alternativas que representa, asegurándose de tener en cuenta los costos y beneficios
anticipados de cada alternativa.
3. Revisar y validar el modelo. Los modeladores presentan el modelo a las partes interesadas para asegurarse
de que se aborden sus inquietudes y que el modelo construido, de hecho, responda las preguntas clave
de interés.
4. Establecer la “lista de la compra” de datos. Los modeladores y las partes interesadas deben calcular los
datos organizacionales (como el costo de construir productos anteriores o el costo de establecer un
programa de capacitación) que proporcionarán información para las fórmulas.
5. Rellene el modelo. Los datos se recopilan y se insertan en las fórmulas, y los resultados
se calculan.
6. Revise los resultados. Los modeladores hacen una presentación a las partes interesadas y se planifican los
próximos pasos.
Esperamos que haya una iteración entre los pasos anteriores, especialmente 2, 4 y 5. Como se mencionó
anteriormente, puede resultar que un resultado de primer orden de grano grueso revele una clara
preferencia entre las alternativas contenidas en el escenario. Si es así, el trabajo del modelo está hecho y
no se requiere ningún esfuerzo adicional. Sin embargo, si no es así, es posible que el modelo deba reformularse
utilizando estimaciones de costos más detalladas o más sofisticadas, lo que, a su vez, dará como resultado la
recopilación y el uso de datos más precisos o detallados para completar las fórmulas.
CMU/SEI2005TR003 31
Esperamos utilizar este esquema de proceso en compromisos futuros, donde refinaremos, elaboraremos y
desarrollaremos el proceso según corresponda.
32 CMU/SEI2005TR003
6 Relación con el marco SEI para software
Práctica de línea de productos
El Marco para la práctica de la línea de productos de software, versión 4.2 [Clements 04] cumple una serie de
propósitos al identificar y definir
• conceptos fundamentales que subyacen a las líneas de productos de software y las actividades esenciales a
considerar antes de desarrollar una línea de productos
• áreas de práctica que una organización que desarrolla líneas de productos de software debe dominar
• orientación necesaria para una organización sobre cómo pasar a un enfoque de línea de productos para
software
El Marco organiza las prácticas de la línea de productos en tres categorías, como se muestra en la Tabla
4.
Tabla 4: Áreas de práctica de la línea de productos
Ingeniería de software Manejo tecnico Gestión organizacional

Areas de práctica Areas de práctica Areas de práctica
Definición de arquitectura Gestión de la configuración Construcción de un caso de negocios

Evaluación de Arquitectura Recopilación de datos, métricas y Interfaz de cliente
Desarrollo de componentes Seguimiento Gestión
COTS12 Utilización Hacer/Comprar/Mina/Comisionar Desarrollo de una adquisición
Minería de Activos Existentes Análisis Estrategia
Ingeniería de requisitos Definición de proceso Fondos
Integración de sistemas de software Alcance Lanzamiento y
Pruebas Planificación Técnica institucionalizando
Entendimiento Relevante Gestión de riesgos técnicos Análisis de mercado
Dominios Soporte de herramientas Operaciones
Planificación Organizacional
Riesgo Organizacional
Gestión
Estructuración de la Organización
Pronóstico tecnológico
Capacitación
La economía de la línea de productos, tal como se define en este informe, respalda directa o indirectamente muchas
de estas áreas de práctica. El área de práctica "Creación de un caso de negocio" aplica directamente los resultados
del cálculo del ROI o la comparación entre la línea de productos y los costos de tubería de estufa. En otras áreas
de práctica, los modelos económicos pueden proporcionar información al área de práctica en forma de necesidades
de información. Los modelos informan el área de práctica de datos "Recopilación de datos, métricas y seguimiento".
12 Comercial listo para usar
CMU/SEI2005TR003 33
necesidades de recopilación, como costos históricos, crecimiento (en tamaño, características, usuarios) o
distribuciones de esfuerzo.
Incluso cuando los costos y los cálculos de ROI no son una parte esencial de la práctica, quienes toman las decisiones deben
tener en cuenta las preocupaciones económicas. Hoy en día, estas decisiones a menudo se toman con estimaciones
insostenibles, pero los modelos permiten agregar cierto grado de rigor a las estimaciones. Por ejemplo, una evaluación exhaustiva
de la arquitectura requerirá compensaciones entre cualidades como la usabilidad y el nivel de seguridad. Una pregunta que se
hace a menudo es: ¿Cuánta seguridad puede permitirse dado el potencial de pérdida? En el contexto de una línea de
productos, el poder de los modelos económicos que se muestran en este informe podrían presentar los costos de crear
activos en varios niveles de seguridad, su impacto en la usabilidad y los costos de los productos creados con esos activos. Estos
costos podrían compararse con los costos de desarrollar estas capacidades a través de un producto de chimenea. La
organización de desarrollo podría usar esta comparación, junto con las cuestiones técnicas de los atributos de calidad, como
parte de la evaluación de la arquitectura.
6.1 Áreas de práctica relacionadas con la línea de productos de software
La siguiente tabla proporciona una lista de las áreas de práctica en las que los modelos SIMPLE desempeñan un papel.
Tabla 5: Relación de prácticas SIMPLE con la línea de productos
Área de práctica Papel de los modelos SIMPLE
Evaluación de arquitectura Las compensaciones de costos pueden ser un aspecto de una evaluación de arquitectura [Kazman
02]. El modelo de línea de productos proporciona la ecuación básica a partir de la cual el
evaluador puede construir un perfil de costos basado en opciones u opciones de
arquitectura.
Recopilación de datos, métricas y El modelo económico se basa en buenos datos actuales e históricos para estimaciones
seguimiento
y proyecciones de costos. Los modelos brindan a los planificadores los indicadores básicos
que pueden usar tanto para realizar un seguimiento de los esfuerzos actuales como para
determinar los datos que se recopilarán para generar estimaciones.
Hacer/Comprar/Mío/ Este análisis se basa en gran medida en las comparaciones de costos, tanto a corto como
Análisis de comisiones
a largo plazo. Por ejemplo, si bien una organización puede encontrar
económicamente ventajoso construir un activo central internamente, también se deben
considerar los costos a largo plazo de mantener ese activo.
Existen compensaciones similares en los otros aspectos de la adquisición de activos
básicos o incluso de una línea completa de productos. SIMPLE ofrece modelos para
hacer frente a cada una de estas circunstancias y así puede contribuir a
todos los aspectos del análisis, especialmente cuando se comparan los costos totales de
desarrollo de la línea de productos con los costos de puesta en marcha de activos o un
producto, o el desarrollo de una línea de productos completa.
34 CMU/SEI2005TR003
Tabla 5: Relación de SIMPLE con las prácticas de la línea de productos (continuación)
Alcance Así como el alcance proporciona límites sobre lo que está dentro o fuera de la línea de
productos, el alcance también limitará la validez de los modelos económicos. Una línea de
productos de alcance limitado generalmente producirá una mayor precisión en las
proyecciones de costos: todos los productos tienden a compartir los mismos puntos en
común. En una línea de productos de alcance amplio, los productos individuales
de la línea de productos tendrán menos superposición y las estimaciones de costos
anteriores tendrán menos relevancia para un nuevo producto.
SIMPLE también se puede utilizar para determinar el ROI en función de un alcance
variado de la línea de productos o la partición alternativa de productos en una o más
líneas de productos.
Planificación Técnica La toma de decisiones juega un papel importante en la planificación de cualquier aspecto
de la línea de productos: desarrollo de activos, desarrollo de productos o mantenimiento a
largo plazo. Las comparaciones de costos brindan información para el proceso de toma
de decisiones, junto con otras consideraciones.
SIMPLE puede ayudar a los planificadores a justificar elementos del plan como la
planificación del alcance de los activos de la línea de productos, la elección de
enfoques de desarrollo de activos, la elección de enfoques de prueba y la
programación de la introducción de activos. También ayuda a los planificadores a llevar a
cabo todos los aspectos de la planificación de productos.
Riesgo Técnico
En varias etapas de la madurez de una línea de productos, SIMPLE puede ser una fuente
Gestión
de riesgo técnico o usarse para mitigar el riesgo.
Cuando se aplica por primera vez para evaluar la viabilidad de la línea de productos,
SIMPLE utiliza suposiciones sobre costos y mercados de líneas de productos proyectados.
Solo los resultados dentro de los límites de estos supuestos se consideran
confiables. Una vez que se establece una línea de productos, la confiabilidad de
los costos para desarrollar un nuevo producto o para ampliar el alcance de la línea
de productos se basará en la experiencia y puede ser una fuente de mitigación de
riesgos: la existencia de la línea de productos proporciona estimaciones de costos
de productos mucho más confiables. que las técnicas tradicionales de estimación
de tubo de estufa.
Soporte de herramientas SIMPLE puede influir y justificar la selección de herramientas de apoyo a la línea de
productos. El costo de la reutilización de activos (Creuse) se puede reducir sustancialmente
mediante la elección y el uso efectivo de herramientas. Sin embargo, puede haber un
aumento en los costos de organización (Corg).
Las tecnologías generativas también pueden reducir sustancialmente Creuse, pero a un
mayor costo de desarrollo de activos (Ccab).
CMU/SEI2005TR003 35
construyendo un negocio El caso de negocio de la línea de productos se basa en gran medida en los
Caso
análisis de costobeneficio que utilizan el ROI como base de comparación.
SIMPLE proporciona al caso comercial los resultados de una variedad
de enfoques para evaluar y defender los enfoques de línea de productos.
El caso de negocios utiliza costos y datos históricos como puntos de
comparación con las proyecciones para la línea de productos. Con SIMPLE, el
desarrollador de casos de negocios puede variar la definición del alcance
de la línea de productos, el costo de construir activos, el costo de usar
activos y los beneficios potenciales para demostrar la validez de un enfoque
de línea de productos.
Desarrollando un Una organización puede utilizar SIMPLE para evaluar y comparar estrategias de
Estrategia de adquisición
adquisición alternativas. Los enfoques de adquisición pueden dividir las
actividades de desarrollo de activos y desarrollo de productos entre el
proveedor y el adquirente o confiar completamente en el proveedor para todos los
aspectos del desarrollo de la línea de productos. En cualquier caso, SIMPLE ofrece
modelos para respaldar los análisis de costobeneficio a través de un
conjunto de estrategias, basadas en consideraciones a corto o largo plazo.
El adquirente también puede usar SIMPLE para hacer comparaciones entre
proveedores potenciales o exigir a los proveedores que usen SIMPLE como
base para sus propuestas.
Fondos Si bien las fuentes y los modelos de financiamiento varían según
la cultura organizacional y la naturaleza del producto de software que se
está desarrollando, los modelos de costos precisos son esenciales tanto
para generar como para justificar el financiamiento. A nivel empresarial, SIMPLE
ofrece proyecciones a través de un conjunto de líneas de productos
que pueden abarcar el conjunto completo de líneas de productos de la
organización. Al tomar decisiones de financiamiento para la línea de
productos individual, SIMPLE ofrece estimaciones para enfoques alternativos de líneas de productos.
Finalmente, las restricciones de financiamiento pueden requerir elecciones tales
como qué activos desarrollar o qué mejoras financiar. SIMPLE también admite
modelos para ayudar en estas decisiones.
36 CMU/SEI2005TR003
Área de práctica Rol de SIMPLE
Lanzamiento y Si bien estas áreas de práctica en realidad se aplican a otras áreas de práctica,
institucionalizando
según corresponda a las necesidades y capacidades de una organización, los
Operaciones
modelos SIMPLE se pueden aplicar especialmente aquí. Los modelos SIMPLE
Planificación Organizacional
pueden predecir los costos de transición cuando una organización pasa a un
estado más alto de sofisticación de la línea de productos, ya sea iniciando
un esfuerzo de línea de productos (lanzamiento) o tratando de expandir y/o mejorar
el alcance de un esfuerzo de línea de productos en curso (institucionalización).
Los costos organizacionales de una línea de productos, Corg, abarcan estos
costos como el impacto en toda la organización, y los costos de activos y
productos (Ccab, Creuse y Cunique) abarcan los costos de desarrollo
reales para financiar la transición. Sin estimaciones precisas, la
organización no puede planificar adecuadamente el lanzamiento o la
institucionalización.
Análisis de mercado Mientras que el análisis de mercado examina los factores externos que
determinan el éxito de un producto en el mercado, SIMPLE ofrece modelos
que pueden calcular el ROI al ingresar a ese mercado. Un ingrediente clave de
SIMPLE es el cálculo de NP (número de productos) y "nbr períodos". El análisis
de mercado juega un papel clave en ambos cálculos. Además, usando diferentes
parámetros dentro de SIMPLE, una organización puede desarrollar análisis de
costobeneficio para una variedad de estrategias de mercado.
Pronósticos tecnológicos Los pronósticos tecnológicos examinan las tendencias futuras que pueden afectar a un
línea de producto. Las tecnologías centrales, así como las herramientas, técnicas,
métodos y procesos utilizados para desarrollar los productos y llevarlos al
mercado, afectan los costos y pueden convertirse en factores en los
modelos SIMPLE. En una línea de productos en rápida evolución, los costos de
mantener la base de activos básicos deben tener en cuenta este cambio
rápido. Estos costos se capturarán en Ccab (donde se requieren nuevos activos
para adaptarse a la evolución de la tecnología) y Creuse (donde es posible
que se requiera la modificación de activos).
De manera similar, las mejoras en las técnicas y herramientas de desarrollo
pueden reducir Creuse pero pueden incurrir en costos organizacionales, Corg,
como los costos de incorporar estas herramientas en el entorno de
desarrollo.
6.2 Patrones para la práctica de la línea de productos de software
Los patrones para la práctica de la línea de productos de software [Clements 02b] ayudan a las organizaciones a
aplicar adecuadamente las áreas de práctica descritas en el Marco. Los modelos SIMPLE pueden soportar muchos de
CMU/SEI2005TR003 37
estos patrones siempre que los patrones requieran decisiones basadas en consideraciones económicas. Los
patrones representan un contexto común y problemas/soluciones comunes, y el uso de SIMPLE proporciona un
medio estándar para abordar la decisión económica de la línea de productos.
Tabla 6: Relación de SIMPLE con patrones para la práctica de la línea de productos de software
Patrón Contribución de SIMPLE
Qué construir SIMPLE proporciona modelos para apoyar el "Análisis de mercado",
Áreas de práctica de "Previsión de tecnología", "Alcance" y
"Creación de un caso de negocio" dentro del patrón. Al aplicar
los modelos de manera consistente en todas las prácticas, la
organización obtendrá una imagen clara de las fuerzas externas del
mercado y el impacto de sus decisiones. Además, los resultados
no son solo ahorros de costos estáticos o ROI, sino que pueden
incluir la dinámica del mercado y los impactos tecnológicos durante la
vida útil de la línea de productos.
Partes del producto Este patrón relaciona las decisiones del área de práctica “Hacer/
comprar/minar/comisionar análisis” con otras prácticas y patrones que
se utilizan para construir o adquirir activos. SIMPLE proporciona los
fundamentos para las decisiones en el área de práctica "Hacer/
Comprar/Mina/Comisionar Análisis" y también puede establecer
necesidades de datos como se producen en otros patrones y prácticas.
Monitor Si bien SIMPLE se usa con mayor frecuencia para desarrollar análisis
de costobeneficio o casos comerciales antes del desarrollo de
la línea de productos, los modelos también deben usarse para
rastrear el desempeño de la línea de productos. Muchas de las
estimaciones utilizadas como parámetros en los cálculos SIMPLE pueden,
durante el curso del desarrollo de la línea de productos, convertirse en
números duros a medida que se recopilan y rastrean los resultados
reales. En Monitor Pattern, el "grupo de escucha" en las áreas de práctica
"Recopilación de datos, métricas y seguimiento" y "Gestión de riesgos
técnicos" puede proporcionar datos concretos al "grupo de respuesta"
para mejorar la precisión de las predicciones SIMPLE. Dichas
mejoras pueden ser parte de planes de producción revisados y nuevos.
38 CMU/SEI2005TR003
Tabla 6: Relación de SIMPLE con patrones para la práctica de la línea de productos de software (continuación)
Patrón Contribución de SIMPLE
Inicio fresco En ambos patrones, el área de práctica de “Financiación” juega un papel
importante. Las fuentes de financiamiento requieren la justificación y
En movimiento validación de los enfoques de la línea de productos, ya sea que se inicie
una línea de productos o se continúe apoyándola. Los modelos
SIMPLE brindan información a estos tomadores de decisiones al
proporcionar imágenes precisas de las líneas de productos actuales y proyectadas.
Estas imágenes se utilizan en el patrón para respaldar opciones tales
como: ampliar el alcance de la línea de productos; si dividir la línea de
productos o combinar líneas de productos; en qué activos invertir;
y, en algunos casos, si terminar la línea de productos.
CMU/SEI2005TR003 39
40 CMU/SEI2005TR003
7 Trabajo relacionado
SIMPLE modela los efectos de la reutilización sistemática también cubiertos por otras técnicas, algunas de las cuales ya
hemos mencionado.
Dale Peterson propuso un modelo a destacar basado en la experiencia de su empresa, Convergys, al optar por adoptar un
enfoque de línea de productos de software [Peterson 04]. Basado en una comprensión de las similitudes y variabilidades
de los requisitos, así como en la arquitectura de componentes, el modelo de Peterson intenta cuantificar cosas
tales como
• qué parte del trabajo de desarrollo será realizada por los grupos de componentes frente a los grupos de productos
• los beneficios asociados con la mejora de la productividad y el uso de componentes comunes,
basado en el concepto de superposición de las necesidades del mercado
• los ahorros en mano de obra asociados con la eliminación del desarrollo de software redundante y
Incrementando la productividad
• los beneficios asociados con el aumento del rendimiento de la fábrica de software (es decir, por
hacer más trabajo con el mismo número de personas)
Otros dos enfoques de modelado se analizan en detalle a continuación: la reutilización del software de medición de Poulin
[Poulin 97a] y COPLIMO [Boehm 04]. Poulin considera el uso de activos en el desarrollo de productos individuales
y el potencial de ahorro de costos, pero sus modelos no tienen en cuenta las implicaciones más amplias de las líneas de
productos. COPLIMO se basa en el ampliamente utilizado COCOMO II [Boehm 00] y proporciona un enfoque
algorítmico para los cálculos de costos de las líneas de productos.
7.1 Medición de la reutilización del software de Poulin Poulin usa dos
parámetros para estimar los efectos de una estrategia de reutilización sistemática: (1) el costo relativo de la reutilización
(RCR) y (2) el costo relativo de escribir para la reutilización (RCWR) [Poulin 97a, Poulin 97b ]. El RCR es una relación
que compara el esfuerzo necesario para reutilizar el software sin modificarlo con los costos normalmente asociados
con el desarrollo de ese mismo software para un solo uso. Un RCR de 0,1 para un activo, o conjunto de activos, indica que el
costo de usar ese activo es una décima parte del costo de desarrollar software equivalente para un solo uso. Los costos de
crear ese activo se reflejan en el RCWR. Este valor relaciona los costos de crear software reutilizable con el costo de escribir
software de un solo uso. Por ejemplo, un RCWR de 1,5 representa la adición del 50 % al esfuerzo de crear software
de un solo uso: si cuesta $10 000 crear un componente para un solo uso, una versión reutilizable costaría $15
000, lo que representa un mayor tiempo de diseño, prueba , documentación, etc.
CMU/SEI2005TR003 41
El modelo de Poulin usa el RCR y el RCWR para calcular dos valores más que predicen ahorros en todo un proyecto:
1. La evitación de costos de reutilización (RCA) compara los ahorros de reutilizar activos frente a escribir el software
equivalente para un solo uso. El RCA incorpora dos valores: la evitación de costos de desarrollo
(DCA) y la evitación de costos de servicio (SCA). Para calcular estos valores, Poulin utiliza las instrucciones de
origen reutilizadas (RSI). El valor RSI proviene del nivel de reutilización en un proyecto donde
instrucciones
_ fuente reutilizadas
_ *100%
% reutilizar =
instrucciones
_ de fuente
_ total
Dado el RSI, Poulin calcula el DCA calculando la evitación de costos en función del software total reutilizado y
el costo de reutilizar ese software:
DCA = RSI * (1RCR) * (Coste de código de un solo uso/líneas de código [LOC])
Por ejemplo, si el RCR es 0.1, y el software reutilizado es de 10 mil líneas de código (KLOC), y el costo
típico por LOC es de $40
DCA = 10000 * (10.1) * ($40) = $360,000
El SCA representa los ahorros de mantenimiento acumulados a través de la eliminación de la reparación
costos:
SCA = RSI * (Tasa de error) * (Coste de error)
Por ejemplo, si las tasas de error son 1.5 errores/KLOC y los costos de error son $1000/error
SCA = 10000 LOC * 1,5 errores/KLOC * $1000/error
15 errores * $1000/error =
= $15,000
El RCA en este ejemplo es DCA + SCA, o $375,000.
2. El costo de desarrollo adicional (ADC) es el costo de escribir software para su reutilización y es
basado en el RCWR y el código real escrito para su reutilización. El ADC refleja el costo de
escribir el software reutilizable, reflejado en el RSI, sobre el costo de escribir para un solo uso y se expresa
como
ADC = (RCWR 1) * RSI * (costo del nuevo código)
Por ejemplo, usando los números anteriores
ADC = (1.5 – 1) * 10 KLOC * ($40/LOC) = $200,000
Bajo este enfoque, Poulin calcula el ROI como
norte
ROI RCAi ADC −
∑−
=
i 1
42 CMU/SEI2005TR003
donde i representa los usos sucesivos del software reutilizable. Suponiendo una serie de 3 esfuerzos de desarrollo
utilizando estos 10 KLOC para su reutilización
ROI = ($375 000 * 3) $200 000 = $925 000
Poulin solo analiza los ahorros de costos en función de los costos estimados de desarrollo y reutilización.
Debido a que el método de Poulin implica un modelo de reutilización y no un modelo de línea de productos, se puede utilizar de
forma muy limitada en comparación con SIMPLE. Además, el método de Poulin no analiza los efectos del tiempo en la reutilización
de activos y los cambios necesarios en esos activos ni considera estrategias alternativas para desarrollar y usar una línea de
productos.
7.2 COPLIMO
COPLIMO es una consecuencia de COCOMO. Ambos modelos estiman el esfuerzo en función del tamaño del código más
una combinación de factores de desarrollo. Para COCOMO, el tamaño representa KLOC. Para COPLIMO, el modelo aplica
una serie de ecuaciones para generar un “tamaño de código equivalente”, es decir, dado el uso de activos en una línea de
productos, hay algún valor que representa un tamaño de código para un producto. Este tamaño de código de línea de productos
tiene en cuenta los costos de generar los activos, la complejidad de los activos, el esfuerzo de usar los activos y otros
factores.
COCOMO produce un esfuerzo nominal para el desarrollo del producto que se define como
esfuerzo nominal = a* (tamaño)b
En esta ecuación, los factores a y b dependen de la complejidad relativa de un producto de software: un producto más
complejo requiere un esfuerzo adicional, siendo iguales todos los demás factores.
Un cálculo de esfuerzo final en COCOMO requiere la inclusión de un conjunto de multiplicadores de esfuerzo, es decir, factores
que influyen en el costo. Los ejemplos de estos multiplicadores incluyen la experiencia de la organización de desarrollo, el
nivel de documentación, el uso de herramientas y otros factores de desarrollo. Dados estos multiplicadores, el esfuerzo de
desarrollo en COCOMO se define como
norte
_ multiplicador
esfuerzo = esfuerzo nominal * ∏ esfuerzo
i=1
COPLIMO usa una ecuación similar pero debe desarrollar dos componentes para poder aplicar la ecuación:
• un modelo de costos para el desarrollo de la línea de productos
• una extensión anualizada del ciclo de vida posterior al desarrollo
7.2.1 Desarrollo de línea de productos en COPLIMO El modelo de costos
para el desarrollo de líneas de productos calcula valores similares al RCWR y RCR de Poulin. Para el RCWR, COPLIMO
utiliza multiplicadores de COCOMO, a saber
CMU/SEI2005TR003 43
desarrollo para reutilización (RUSE) y dos restricciones de COCOMO: (1) confiabilidad requerida (RELY) y
(2) grado de documentación (DOCU). Estos factores representan los costos adicionales de desarrollar
activos de línea de productos. COPLIMO usa 1520% como el esfuerzo adicional de desarrollar activos para
su reutilización (un esfuerzo que es menor que el de Poulin porque COCOMO elimina otros factores
contribuyentes) y luego aplica las otras restricciones:
costo estimado = (1 + RUSE) * costo de confiabilidad * costo de documentación
COPLIMO calcula el RCR como un tamaño de código equivalente utilizando un factor conocido
como evaluación y asimilación (AA). Los cálculos de RCR consideran dos casos:
1. La reutilización de caja negra aplica el factor AA en el rango de 0,02 < factor AA < 0,08, basado en el
esfuerzo de reutilización del código. Cuando se multiplica por la cantidad de código reutilizado, este
factor genera un tamaño equivalente. Por ejemplo, si no se hace ningún esfuerzo por reutilizar el
código, excepto para encontrarlo, el código total se multiplica por 0,2. Cuando se requieran pruebas y
evaluación, el factor puede ser tan alto como 0,08. Para 10 KLOC reutilizados, el tamaño equivalente
podría oscilar entre 200 y 800, dependiendo del factor AA.
2. El software adaptado (reutilización de caja blanca) incluye varios factores:
la cantidad de diseño modificado (DM) y código modificado (CM)
el esfuerzo de integración (IM)
el factor de comprensión del sistema (SU) y la falta de familiaridad del programador (UNFM)
La fórmula primero da cuenta de la modificación (factor de ajuste de adaptación [AAF]) como la
modificación del diseño y el código más el esfuerzo de integración:
• AAF = (.4*DM) + (.3*CM) + (.3*IM)
• COPLIMO calcula un multiplicador de ajuste de adaptación (AAM). Donde AAF es <= 50,
AM =
AA + AAF(1+ (0.02 * SU *UNFM ))
100
Donde AAF > 50, AAM =
AA + AAF+ (SU *UNFM )
100
En estas fórmulas, la comprensión del sistema será menor en función de la claridad de la arquitectura, una
clara coincidencia entre los activos y el producto, y el nivel de documentación; la falta de familiaridad será
menor en función de la frecuencia de uso de los activos.
Luego, el AAM se multiplica por el LOC reutilizado para obtener un tamaño de código equivalente para
el cálculo posterior de COPLIMO. Para niveles moderados (25 %) de modificación y altos niveles de
comprensión y desconocimiento del sistema, la AAM será de aproximadamente 30 %. Modificar 10 KLOC en
estas condiciones sería el equivalente a crear 3 KLOC desde cero.
44 CMU/SEI2005TR003
COPLIMO luego toma tamaños equivalentes y aplica multiplicadores COCOMO estándar. Si el producto consta
de 30 KLOC, 10K de los cuales son nuevos, 10K se reutilizan tal cual y 10K se reutilizan con modificaciones,
las líneas de código equivalentes serían iguales
• 10.000 (para las nuevas líneas) +
• 10 000 * 8/100 = 800 líneas de reutilización de caja negra (donde 8/100 representa el costo AAF)
• 10,000 * .3 = 3000 líneas de reutilización modificada (donde .3 es el AAM como se muestra arriba)
Las líneas equivalentes sumarían 13.800. Dado este valor, COCOMO se puede aplicar como se indicó anteriormente:
norte
esfuerzo = A * (PSIZE)B * ∏ multiplicador d_e esfuerzo 1
i=
Puede comparar el costo de desarrollo desde cero con PSIZE = 30 (COCOMO usa KLOC para el tamaño) versus
13.8 para el enfoque basado en la reutilización. Usando valores típicos de COCOMO para A (p. ej., 2,94) y 1,0 para
B y todos los multiplicadores de esfuerzo, esta fórmula da valores de aproximadamente 90 personasmes
(PM) y 40PM respectivamente para desarrollo desde cero versus línea de productos. Los ahorros de costos
también deben tener en cuenta los costos de desarrollo de la línea de productos, que cubrirán los 20 KLOC que
se reutilizarán. Dados los valores típicos (p. ej., 1,2) para RUSE, DOCU y RELY, los costos de desarrollo de activos
podrían ser 1,2*1,2*1,2 = 1,7 veces los del desarrollo desde cero. COCOMO pronosticaría aproximadamente 100PM
de esfuerzo para desarrollar los activos. Después de tres aplicaciones similares de la base de activos, el modelo
COPLIMO mostraría aproximadamente 50 PM de retorno, 270 (90 * 3) PM para desarrollar tres productos desde cero,
versus 220 PM (100 + 40 + 40 + 40) utilizando los activos de la línea de productos.
7.2.2 Modelo de ciclo de vida anualizado en COPLIMO COMPLIO hace
algunos supuestos simplificadores al observar el ciclo de vida de mantenimiento de la base de activos y
productos básicos. Tres factores deben permanecer relativamente constantes:
1. las fracciones de un producto que son nuevas, reutilizadas o adoptadas
2. todos los multiplicadores de esfuerzo (p. ej., AA, RUSE, AAM)
3. el tráfico de cambio anual (ACT) o la fracción del software de un producto que cambia por
año
Al calcular los costos del ciclo de vida, COPLIMO utiliza el enfoque básico de COCOMO: agregue el costo de
desarrollo inicial (en PM) a los costos de mantenimiento en función de la cantidad de años en
mantenimiento. Los costos de mantenimiento utilizan un tamaño de mantenimiento anual basado en el tamaño del
producto, el ACT y los factores de comprensión y desconocimiento del sistema. La fórmula real para el tamaño es
SU
AMSIZE = PSIZE * ACT (1 + *UNFM) 100
CMU/SEI2005TR003 45
COCOMO factoriza el AMSIZE en una fórmula de mantenimiento como
PM (N, L) = PM (N) + L * N [A ∏ (EM) ] * (TAMAÑO AM)B *
En esta fórmula, N es el número de productos en mantenimiento y L es el número de años.
Para la línea de productos, COPLIMO aplica esta misma fórmula una vez para cada una de las tres
categorías de activos nuevos, reutilizados y adoptados. Los resultados se suman para dar un valor de
mantenimiento total.
Al igual que con Poulin, COPLIMO es esencialmente un modelo basado en la reutilización: COPLIMO asume el uso de
un conjunto de activos para construir un conjunto de productos relacionados. COPLIMO va más allá que Poulin al
considerar las variaciones en el costo de la reutilización (Creuse en SIMPLE) y al considerar el mantenimiento, pero
también hace algunas suposiciones simplificadoras. Por otro lado, COPLIMO depende de la disponibilidad de un rango
de valores paramétricos que deben calibrarse con precisión, lo que lo hace menos adecuado para una audiencia no
técnica.
46 CMU/SEI2005TR003
8 Trabajo futuro
SIMPLE es todavía en gran medida un trabajo en progreso, con cuatro esfuerzos principales restantes:
1. validando el modelo
2. agregar nuevos escenarios y decidir cómo organizarlos
3. exploración de dependencias y sensibilidades dentro del modelo
4. hacer que SIMPLE esté ampliamente disponible y sea utilizable
Cada esfuerzo se describe a continuación.
8.1 Validación de SIMPLE ¿Cómo
sabremos que las predicciones devueltas por SIMPLE son correctas? El hecho es que lo más probable es que no lo
sean. Todos los modelos están sujetos a preocupaciones de exactitud y precisión, especialmente SIMPLE.
Entonces, la pregunta apropiada es: "¿Cómo sabremos si las respuestas de SIMPLE son lo suficientemente
buenas?"
¿Qué significa que una predicción sea lo suficientemente buena? Si un modelo predice 42 y la respuesta real es 142,
¿el modelo es lo suficientemente bueno o no? Es una pregunta que sólo puede responderse en el contexto de los objetivos
del modelo. Si un modelo que es preciso dentro de un orden de magnitud es bueno (es decir, si arroja resultados útiles), el
modelo que arroja 42 es realmente bueno.
Pero si solo las respuestas dentro del 5% de la realidad son útiles, el modelo no es bueno.
Prevemos que SIMPLE será utilizado por los campeones de la línea de productos como una herramienta para
proporcionar resultados de viabilidad de primer orden de magnitud relacionados con los escenarios de la línea de
productos previstos. Como dijo un revisor: “Si una organización puede lograr un aumento de la productividad del
200500 % a través de un enfoque de línea de productos, no debe preocuparse si su modelo se desvía por algún
factor de número entero pequeño. No estás tratando de convencer a alguien que está preocupado por si algún valor es
12% o 13%”.
Con esto en mente, nuestra tarea se convierte en ganar confianza en el modelo, no en validarlo en sentido estricto. Con
este fin, estamos haciendo arreglos con una organización para formular cooperativamente varios escenarios de interés,
hacer predicciones SIMPLES y luego comparar esas predicciones con los resultados reales a lo largo del tiempo.
También estamos buscando otras organizaciones con las que repetir este proceso. Mientras hacemos esto,
publicaremos los resultados para que los usuarios potenciales de SIMPLE puedan ver qué tan bien les fue a esas
organizaciones piloto y decidir por sí mismos si los resultados justifican su uso.
CMU/SEI2005TR003 47
8.2 Expansión y organización del conjunto de escenarios SIMPLE Este informe ha
presentado una serie de escenarios que SIMPLE puede calcular. Por supuesto, muchos más
son posibles. Nos gustaría probar escenarios adicionales que
• Explorar los beneficios a corto plazo pero los costos a largo plazo del enfoque de "clonar y poseer" para explotar
los elementos comunes
• Expresar opciones basadas en el tiempo, como elegir entre construir activos centrales en gran medida desde el
principio o extender el proceso a lo largo del tiempo. Este tipo de escenario abordaría el desarrollo
incremental de la línea de productos [Clements 04].
• expresar opciones entre diferentes estrategias de producción, como usar un generador para
producir productos en lugar de usar enfoques más tradicionales de comprobación/parametrización/
compilación/construcción. Este tipo de escenario permitiría a una organización investigar la viabilidad de un
enfoque de programación generativa para su línea de productos [Czarnecki 00].
• permitir que los usuarios investiguen la diferencia entre los enfoques reactivo y proactivo del producto
ingeniería de línea [Clements 02c]
• permitir que los usuarios investiguen diferentes enfoques para proporcionar variabilidad en sus activos principales.
Una forma de hacerlo es preguntar: "¿Qué tan bien está respaldado un producto previsto por la
variabilidad proporcionada?"
• investigar diferentes estrategias para las pruebas de línea de productos
• permitir que los usuarios elijan a cuál de los cientos de solicitudes de cambio se le debe dar la mayor prioridad
También nos gustaría proporcionar un medio sistemático para organizar escenarios de modo que los usuarios de
SIMPLE puedan encontrar los escenarios que desean fácilmente sin tener que buscar al azar en una larga lista
no estructurada.
8.3 Exploración de dependencias y sensibilidades intramodelo Las dependencias ciertamente existen
entre las variables que constituyen un modelo SIMPLE para una línea de productos. Por ejemplo, proporcionar
una base de activos básicos cuyos activos vengan equipados con asistentes para guiar la creación de instancias
y la instalación aumentará Ccab pero reducirá Creuse. Y si Ccab proporciona activos básicos que cubren la mayor
parte de un producto, Cunique será bajo, pero Ccab bien puede ser algo alto. Descubrir y cuantificar estas
dependencias ayudará a un creador de modelos a configurar el modelo, comprobar si es razonable y realizar varias
investigaciones hipotéticas.
Además, puede darse el caso de que un modelo para una línea de productos particular que aborde un escenario
particular sea mucho más sensible al valor de algunas variables que a otras. Saber eso le dirá a un modelador
qué variables son importantes para tener estimaciones precisas y qué variables se pueden completar con más
conjeturas de "dedo en el viento". Peterson describe un buen ejemplo de análisis de un modelo para sus
sensibilidades de entrada [Peterson 04].
48 CMU/SEI2005TR003
8.4 Problemas de presentación: hacer que SIMPLE esté disponible y sea utilizable
Visualizamos una interfaz de usuario basada en la Web para SIMPLE. Tomadores de decisiones de línea de productos que
desee utilizar el modelo visitará un sitio web donde se le presentarán varios escenarios para los cuales se han
desarrollado fórmulas SIMPLES. Después de elegir el que mejor describa su situación de interés, se les pedirá que completen
los valores estimados de los parámetros relevantes para ese escenario. Se ejecutarán las fórmulas y se
proporcionarán las respuestas.
Los planes a más largo plazo pueden incluir
• mostrar una serie de gráficos, cada uno de los cuales muestra cómo una de las salidas es una función de una
o más de los parámetros de entrada
• aceptar una variedad de insumos, como protección contra la incertidumbre, con el resultado de tener
SIMPLE calcular un rango de salidas
• usar esquemas esqueléticos existentes para un caso de negocios [Cohen 01] para producir informes de casos de
negocios preempaquetados a pedido que incorporen los resultados de elegir el escenario y ejecutar el modelo
• preparar una lista de suposiciones (algunas inherentes al modelo, algunas inherentes al escenario seleccionado y algunas
inherentes a las entradas proporcionadas) que abarcan los resultados
• abordar las inquietudes sobre el envío de datos confidenciales a un sitio web, por ejemplo,
proporcionar formas de permitir que los usuarios descarguen el software computacional
• permitir que los usuarios suspendan y reanuden una sesión de modelado con el tiempo
• agricultura de datos, o recopilación (sin retener ninguna identificación del usuario) ingresada
perfiles, a fin de obtener información sobre los tipos de escenarios y valores de la línea de productos que se
experimentan en el mundo real
• mostrando beneficios basados en roles
Los planes a más largo plazo podrían incluir una sección del sitio web donde los visitantes puedan proponer nuevos
escenarios y luego proponer formulaciones SIMPLES que expresen esos escenarios. Al igual que el software de código
abierto, la comunidad de usuarios crearía y mantendría estos escenarios y sus fórmulas, quienes podrían decidir si las
formulaciones eran lo suficientemente confiables para su uso.
CMU/SEI2005TR003 49
50 CMU/SEI2005TR003
Apéndice A: Análisis de métricas de preguntas de objetivos (GQM) de
Métrica de homogeneidad
Varias actividades en la gestión de línea de productos dependen de las características de los productos en la línea de
productos. El grado de reutilización entre los productos de la línea de productos depende de cuán homogéneos sean
los productos. En este informe, proponemos una métrica que caracteriza la homogeneidad de un conjunto de
productos. Esta métrica se puede utilizar para diversas actividades de estimación y planificación, como el
alcance de la línea de productos.
Usamos el enfoque GQM [Basili 92] para describir el contexto y la definición básica de la métrica. Luego damos
una definición completa e ilustramos su uso con varios escenarios.
Meta
Nuestro objetivo es poder caracterizar una línea de productos, de modo que podamos comparar una línea de
productos con otra. Una línea de productos compuesta por dispositivos inalámbricos que se diferencian entre sí solo
por los tipos de dispositivos periféricos que se conectan a ellos es diferente de una línea de productos
compuesta por terminales portátiles que realizan diversas tareas, como la emisión de multas de tráfico o el control
de inventario de mercancías. Se anticiparía un mayor nivel de reutilización de componentes en la primera línea
de productos que en la última.
Preguntas
La declaración del objetivo plantea varias preguntas:
1. ¿Cuántos productos hay en cada línea de productos?
2. ¿Cuál es el tamaño de cada producto en la línea de productos?
3. ¿Qué tan complejo es cada producto y, por inferencia, la línea de productos?
4. ¿Qué tan similares son los productos dentro de una sola línea de productos? Cuanto más parecido sea el
productos, mayor será el grado de reutilización y más rápido el tiempo de comercialización de la línea de
productos.
CMU/SEI2005TR003 51
Métrico
Para responder a la pregunta planteada anteriormente sobre la similitud de los productos en una línea de
productos, necesitamos definir una medida que caracterice qué tan homogéneos son los productos. Para hacer
eso, debemos abordar los temas discutidos a continuación.
Unidades
El primer problema es la selección de la unidad que se utilizará en el cálculo de la métrica. La mayoría de las
veces se piensa en un producto en términos de sus requisitos; sin embargo, diferentes escritores dividirán las
responsabilidades de un sistema de manera diferente, lo que dará como resultado valores potencialmente
diferentes de la métrica para el mismo producto. Dos requisitos pueden tener impactos muy diferentes en el
sistema, sin embargo, un esquema de conteo puede contar cada uno como un solo requisito. No existe una
técnica uniforme para los requisitos de escritura.
Otras dos unidades candidatas son las características y los casos de uso. Una característica es tan
nebulosa como un requisito, pero técnicas como el análisis de dominio orientado a características (FODA) [Kang
90] pueden reducir la variación entre las personas que definen el mismo sistema. Del mismo modo, los casos
de uso pueden ser vagos, pero existen técnicas específicas [Major 98, Cockburn 01] que resultan en un uso más uniforme
casos.
Siguiendo el enfoque utilizado por McGregor [McGregor 95], la definición conceptual de la métrica puede
permanecer sin cambios, mientras se seleccionan diferentes unidades de medida. Este enfoque permite definir
medidas de homogeneidad muy temprano en el ciclo de vida de la línea de productos y en la implementación de
los productos. Así que al principio, las características o los casos de uso pueden considerarse las unidades,
mientras que más tarde, los componentes únicos pueden ser las unidades.
Precisión Al
definir la medida, surgirán una serie de problemas que afectarán la precisión de la medida.
Por ejemplo, ¿todos los requisitos, características u otras unidades son igualmente importantes? ¿Qué pasa si un
requisito es un derivado de otro?
Estamos adoptando un enfoque iterativo. Los resultados iniciales del uso de la métrica generarán
modificaciones en la definición.
Definición de métrica
Considere la definición de la siguiente medida:
Notación:
NP = número de productos en la línea de productos
R = un requisito funcional de un producto
52 CMU/SEI2005TR003
RT = el conjunto de todos los requisitos
| RT |= el número total de requisitos diferentes
Supuesto: Un requisito “único” es aquel que es utilizado por un solo producto.
Escenario: suponga que hay 10 productos en la línea de productos y un total de 100 requisitos separados. Hay
varias posibilidades:
a) Todos los requisitos se aplican a todos los productos.
b) Se aplican diez requisitos a cada producto, y cada producto es diferente.
c) Algunos productos comparten requisitos, pero no los mismos requisitos.
Los requisitos para un producto Pi son la unión de los requisitos de la línea de productos que se aplican a Pi y los
requisitos exclusivos del producto Pi.
R p yo
= R pl Pi
R tu
ip
Entonces necesitamos una medida para la homogeneidad de la línea de productos. Considere la medida
|
R ∑ | tu
yo
i=1
homogeneidad = 1 −
| RT |
CMU/SEI2005TR003 53
Hay tres casos a considerar:
1. En el caso degenerado donde cada producto es totalmente único
| |= 0 Rpl y
= R
| RT | | | entonces
∑=
i 1
tu pi
R T
homogeneidad = | 1−
| | = 0
RT |
Cuando cada producto es único, la cantidad de productos que utilizan cualquier requisito es 1. Cada
1 1 T
término en la suma es , la suma es , y el resultado es 1 .
notario público notario público notario público
2. Si todos los productos son idénticos, | y| | | RT = Rpl ∑ = |Rupi
| 0 y
i=1
homogeneidad = 1 – 0 = 1.
Cuando los productos son idénticos, cada término del numerador es un 1. La suma es T,
el cociente es 1 y la homogeneidad es 1 – 1 = 0.
3. Queda aún el tercer caso en el que un requisito se aplica a más de un producto pero no a todos. Este
sigue siendo un requisito de la línea de productos, pero las variables de diversidad y factor de
reutilización aún pueden variar en amplios rangos. Consideramos un caso promedio donde todos
los requisitos son usados por más de un producto, pero ninguno es usado por todos los productos.
Una posibilidad es ponderar cada requerimiento por la fracción del número total de
productos que lo utilizan.
T
número de productos que satisfacen R i
∑=
i 1 notario público
homogeneidad =
RT |
|
Considere estos escenarios:
• Suponga que hay 100 requisitos y 10 productos y un conjunto básico de 10 requisitos
común a todos los productos. Cada producto tiene nueve requisitos únicos. En este caso, la
suma es 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 90(.1) = 19, y la homogeneidad es 1 19/100
= .81
54 CMU/SEI2005TR003
• Supongamos que hay 100 requisitos y 10 productos y un núcleo de 50 requisitos
común a todos los productos. Cada producto tiene cinco requisitos únicos. En este caso, la
suma es 50(1) + 50(.1) = 55 y la homogeneidad es 1 55/100 o .45.
• Supongamos que hay 100 requisitos y 10 productos y un núcleo de 80 requisitos
común a todos los productos. Cada producto tiene dos requisitos únicos. En este caso, la
suma es 80(1) + 20(.1) = 82 y la homogeneidad es 1 82/100 o .18.
CMU/SEI2005TR003 55
56 CMU/SEI2005TR003
Apéndice B: tabla de símbolos utilizados en SIMPLE
Símbolo Definición
ben Una función de beneficio que devuelve el valor económico del beneficio de la línea de productos
j
( como
j
un tiempo de comercialización más rápido)
ccab() Una función de costo que, dados los parámetros relevantes, devuelve el costo de desarrollar
una base de activos básicos adecuada para satisfacer un alcance particular. Ccab tiene en
cuenta los costos de realizar un análisis de similitud/variabilidad, definir el alcance de la
línea de productos, diseñar y luego evaluar una arquitectura de software genérica (a diferencia de
una única) y desarrollar el software así diseñado. Se puede invocar a Ccab para decirnos el
costo de desarrollar una base de activos básicos donde actualmente no existe o derivar
una base de activos básicos deseada de uno o más ya existentes.
Ccabú() El costo de actualizar la base de activos básicos tiene que cambiar como resultado del
lanzamiento de una nueva versión de un
Cevo() producto. Una función de costo que se parametriza con números de producto y versión y
devuelve el costo de producir esa versión sin utilizar una base de activos básicos.
Corg () Una función de costo que, dados los parámetros relevantes, devuelve cuánto le cuesta a una
organización adoptar el enfoque de línea de productos para sus productos.
Dichos costos pueden incluir reorganización, mejora de procesos, capacitación y cualquier
otro remedio organizacional que sea necesario.
Cprod (producto) Una función de costo que devuelve el costo de construir un producto de manera independiente
Creuse() Una función de costo que, dados los parámetros relevantes, devuelve el costo de
desarrollo de reutilizar los activos principales de una base de activos principales para construir un
producto. Creuse incluye el costo de ubicar un activo principal, retirarlo del repositorio, adaptarlo
para su uso en la aplicación prevista y realizar las pruebas adicionales asociadas con
la reutilización de activos principales.
Cunique() Una función de costo que, dados los parámetros relevantes, devuelve el costo de desarrollar
las partes únicas (tanto software como no software) de un producto que no se basan en
los activos de la base de activos básicos. El resultado podría ser un producto completo (es decir,
uno que no sea miembro de una línea de productos) o la parte única de un producto cuyo resto
se construya sobre la base de activos centrales de una línea de productos.
común Un factor que describe qué fracción de un producto (o, en promedio, un conjunto de productos)
se construye a partir de activos básicos (p. ej., 70 %).
freusable Un factor que describe cuánto más cuesta crear software de usos múltiples que software de un
solo propósito (por ejemplo, 150 %).
ROI retorno de la inversión, calculado como ahorro de costes/coste de la inversión
t Un período de tiempo de interés, utilizado como parámetro para las funciones de costo y beneficio.
CMU/SEI2005TR003 57
58 CMU/SEI2005TR003
Apéndice C – Lista de siglas
Acrónimo Definición
Automóvil club británico evaluación y asimilación
FAA factor de ajuste de adaptación
AAM multiplicador de ajuste de adaptación
ACTO cambio anual tráfico costo
ADC de desarrollo adicional
CBAM Método de análisis de costobeneficio
CM código modificado
COCOMO Modelo de construcción de costos
COPLIMO Modelo de inversión de línea de productos constructivos
CUNAS comercial listo para usar
DCA diseño de evitación de costos de
MD desarrollo grado
DOCU modificado de documentación
GQM Meta Pregunta Esfuerzo de
FODA integración de análisis de dominio orientado
SOY a características métricas
KLOC mil líneas de código
LOC líneas de código
PM mesespersona
py añospersona
I+D investigación y desarrollo
ROI Retorno de la inversión
rca evitar costes de reutilización
RCR costo relativo de reutilización
RCWR costo relativo de escribir para reutilizar
CONFIAR confiabilidad requerida
RSI instrucciones fuente reutilizadas
ARDID desarrollo para la reutilización
CMU/SEI2005TR003 59
Acrónimo Definición
SCA evitación de costos de servicio
SEI Instituto de Ingeniería de Software
SIMPLE Modelo intuitivo estructurado de la economía de la línea de productos
SU comprensión del sistema
UNFM desconocimiento del programador
60 CMU/SEI2005TR003
Referencias
Las URL son válidas a partir de la fecha de publicación de este documento.
[Basilio 92] Basili, Victor R. Modelado y medición de software: la meta/pregunta/
paradigma métrico (CSTR2956, UMIACSTR9296). College Park, MD:
Universidad de Maryland, septiembre de 1992.
[Böckle 04a] Böckle, Günter; Clemente, Pablo; McGregor, John D.; Muthig, Dirk; y Schmid,
Klaus. "Cálculo del ROI para líneas de productos de software".
IEEE Software 21, 3 (mayo/junio de 2004): 2331.
[Böckle 04b] Böckle, Günter; Clemente, Pablo; McGregor, John D.; Muthig, Dirk; y Schmid,
Klaus. “Un modelo de costos para las líneas de productos de software”,
310316. Actas del 5º Taller Internacional sobre Ingeniería de Familias de
Productos (PFE 2003), Lecture Notes in Computer Science (LNCS)
3014. Siena, Italia, noviembre de 2003. Berlín, Alemania: Springer,
2004.
[Boehm 04] Boehm, Barry; Marrón, A. Winsor; Madachi, Ray; y Ye Yang. “A Software
Product Line Life Cycle Cost Estimation Model,” 156164. Actas del
Simposio Internacional 2004 sobre Ingeniería Empírica de Software.
Redondo Beach, CA, 19 y 20 de agosto de 2004. Los Alamitos, CA: IEEE
Computer Society, 2004.
[Boehm 00] Boehm, Barry W. Estimación de costos de software con Cocomo II. Upper
Saddle River, Nueva Jersey: Prentice Hall, 2000.
[Clements 04] Clements, Paul y Northrop, Linda. Un marco para la práctica de la línea
de productos de software, versión 4.2.
http://www.sei.cmu.edu/productlines/framework.html (2004)
[Clements 02a] Clements, Paul y Northrop, Linda. Salion, Inc.: Estudio de caso de una línea de
productos de software (CMU/SEI2002TR038, ADA412311).
Pittsburgh, PA: Instituto de Ingeniería de Software, Universidad Carnegie
Mellon, 2002. http://www.sei.cmu.edu/publications/documents/02.reports/
02tr038.html
CMU/SEI2005TR003 61
[Clements 02b] Clements, Paul y Northrop, Linda. Líneas de productos de software:
prácticas y patrones. Boston, MA: AddisonWesley, 2002.
[Clements 02c] Clements, Paul y Kruger, Charles. “Inicio de líneas de productos de
software: punto/contrapunto: ser proactivo vale la pena”. IEEE Software
19, 4 (julio/agosto de 2002): 28.
[Quemadura de gallo 01] Cockburn, Alistair. Escritura de casos de uso efectivos. Boston, MA:
AddisonWesley, 2001.
[Cohen 04] Cohen, Sholom; Zubrow, Dave; y Dunn, Ed. Estudio de Caso: Un
Programa de Medición de Líneas de Producto (CMU/SEI2004TN 023).
Pittsburgh, PA: Instituto de Ingeniería de Software, Universidad Carnegie
Mellon, 2004. http://
www.sei.cmu.edu/publications/documents/04.reports/04tn023.html
[Cohen 03] Cohen, Sholom. Predecir cuándo paga la inversión en la línea de
productos (CMU/SEI2003TN017, ADA418466). Pittsburgh, PA: Instituto
de Ingeniería de Software, Universidad Carnegie Mellon, 2003.
http://www.sei.cmu.edu/publications/documents/03.reports/
03tn017.html
[Cohen 01] Cohen, Sholom. Estudio de caso: creación y comunicación de un
caso comercial para una línea de productos del Departamento de Defensa
(CMU/SEI2001TN020, ADA395155). Pittsburgh, PA: Instituto de
Ingeniería de Software, Universidad
Carnegie Mellon, 2001. http://www.sei.cmu.edu/publications/
documents/01.reports/01tn020.html
[Cruickshank 93] Cruickshank, RD y Gaffney, JE "Un modelo económico de reutilización
de software", 99137. Métodos analíticos en la economía de la
ingeniería del software. Editado por T. Gulledge y W. Hutzler. Nueva York,
NY: SpringerVerlag, 1993.
[Czarnecki 00] Czarnecki, K. & Eisenecker, U. Programación generativa: métodos,
herramientas y aplicaciones. Boston, MA: AddisonWesley, 2000.
62 CMU/SEI2005TR003
[Fávaro 96] Fávaro, Juan. "Una comparación de enfoques para reutilizar el análisis
de inversiones", 136145. Actas de la Cuarta Conferencia Internacional
IEEE sobre Reutilización de Software. Orlando, FL, 2326 de abril de
1996. Los Alamitos, CA: IEEE Computer Society Press, 1996.
[Gaffney 92] Gaffney, JE, Jr. y Cruickshank, RD "Un modelo económico general
de reutilización de software", 327337. Actas de la Conferencia
Internacional sobre Ingeniería de Software. Melbourne, Australia, del
11 al 15 de mayo de 1992. Nueva York, NY: ACM, 1992.
[ISO9126 01] Organización Internacional de Normalización (ISO) y
Comisión Electrotécnica Internacional (IEC). Ingeniería de
software—Calidad del producto = Genie du Logiciel—Qualite des
Produits [ISO/IEC 91261:2001(E)]. Ginebra, Suiza: ISO/IEC,
2001.
[Kang 90] Kang, K.; Cohen, S.; Hess, J.; Novak, W.; & Peterson, A. Estudio de
viabilidad del análisis de dominio orientado a características (FODA)
(CMU/SEI 90TR021, ADA235785). Pittsburgh, PA: Instituto de
Ingeniería de Software, Universidad Carnegie
Mellon, 1990. http://www.sei.cmu.edu/publications/documents/
90.reports/90.tr.021.html
[Kazmán 02] Kazman, Rick; Asundi, Jai; y Klein, Mark. Toma de decisiones de
diseño de arquitectura: un enfoque económico (CMU/SEI2002TR
035, ADA408740). Pittsburgh, PA: Instituto de Ingeniería de Software,
Universidad Carnegie Mellon, 2002.
http://www.sei.cmu.edu/publications/documents/02.reports/
02tr035.html
[Knauber 02] Knauber, Peter; Bermejo, Jesús; Böckle, Günter; Leite, Julio; van der
Linden, Frank; Northrop, Linda; Stark, Michael; y Weiss, David.
“Cuantificación de los beneficios de la línea de productos”, 155163.
Actas del 4.º Taller internacional de ingeniería de familias de
productos de software (PFE 2001), Apuntes de conferencias sobre informática (LNCS)
2290. Bilbao, España, 35 de octubre de 2001. Berlín, Alemania: Springer
Verlag, 2002.
CMU/SEI2005TR003 63
[Mayor 98] Major, Melissa & McGregor, John D. Un análisis cualitativo de dos técnicas de
captura de requisitos para estimar el tamaño de los proyectos de software
orientados a objetos (Informe técnico del Departamento de Ciencias
de la Computación 98002). Clemson, Carolina del Sur: Universidad
de Clemson, 1998.
[McGregor 02] McGregor, John D.; Northrop, Linda M.; Jarrad, Salah; y Pohl, Klaus.
“Inicio de líneas de productos de software Introducción del editor
invitado”. IEEE Software 19, 4 (julio/agosto de 2002): 2427.
[McGregor 95] McGregor, John D. "Gestión de métricas en un entorno
iterativo". Revista Object 5, 6 (1995): 6571.
[mili 00] Milli, A.; Chmiel, SF; Gottumukkala, R.; y Zhang. L. "Un modelo de
costos integrado para la reutilización de software", 157166. Actas de la
Conferencia Internacional de Ingeniería de Software de 2000.
Limerick, Irlanda, 4 al 11 de junio de 2000. Nueva York, NY: ACM, 2000.
[Peterson 04] Peterson, Dale. “Economía de las líneas de productos de software”, 381402.
Actas del 5º Taller Internacional sobre Ingeniería de Familias de Productos
(PFE 2003). Siena, Italia, noviembre de 2003. Berlín, Alemania: Springer,
2004.
[Poulin 97a] Poulin, Jeffrey S. Reutilización de software de medición. Reading,
MA: AddisonWesley, 1997.
[Poulin 97b] Poulin, Jeffrey S. "Alimentando la reutilización de software con métricas".
Revista Object 7, 7 (septiembre de 1997): 4247.
[Schmid 02] Schmid, Klaus. “An Initial Model of Product Line Economics,” 3850. Actas del
4º Taller Internacional de Ingeniería de Familias de Productos de Software
(PFE 2001), Lecture Notes in Computer Science (LNCS) 2290. Bilbao,
España, 35 de octubre de 2001. Berlín, Alemania: SpringerVerlag, 2002.
[SPL 05a] Casos de Éxito en Líneas de Productos de
Software. http://www.softwareproductlines.com/successes/successes.html
(URL válida a partir de marzo de 2005)
64 CMU/SEI2005TR003
[SPL 05b] Tiempos
vinculantes. http://www.softwareproductlines.com/introduction/binding.html
(URL válida a partir de marzo de 2005)
[Verhoef 04] Verhoef, C. Cuantificación del valor de las inversiones en
TI. http:www.cs.vu.nl/~x/val/val.pdf (agosto de 2004)
[Weiss 99] Weiss, David y Lai, Chi Tau Robert. Ingeniería de línea de productos
de software. Reading, MA: AddisonWesley, 1999.
[Astucias 02] Wiles, Ed. "Modelos económicos de reutilización de software: una
comparación y validación". Tesis doctoral, Universidad de Gales. 2002.
CMU/SEI2005TR003 sesenta y cinco
66 CMU/SEI2005TR003
INFORME DOCUMENTACIÓN PÁGINA Formulario Aprobado OMB
No. 07040188
La carga de informes públicos para esta recopilación de información se estima en un promedio de 1 hora por respuesta, incluido el tiempo para revisar las
instrucciones, buscar fuentes de datos existentes, recopilar y mantener los datos necesarios y completar y revisar la recopilación de información. Envíe comentarios
sobre esta estimación de carga o cualquier otro aspecto de esta recopilación de información, incluidas sugerencias para reducir esta carga, a Servicios de la
sede central de Washington, Dirección de operaciones e informes de información, 1215 Jefferson Davis Highway, Suite 1204, Arlington, VA 222024302, y a la
Oficina de Administración y Presupuesto, Proyecto de Reducción de Trámites (07040188), Washington, DC 20503.
1. SOLO PARA USO DE LA AGENCIA 2. FECHA DEL INFORME 3. TIPO DE INFORME Y FECHAS CUBIERTAS
(Dejar en blanco) febrero de 2005 Final
4. TÍTULO Y SUBTÍTULO 5. NÚMEROS DE FINANCIACIÓN
El modelo intuitivo estructurado para la economía de la línea de productos (SIMPLE) F1962800C0003
6. AUTOR(ES)
Paul C. Clements, John D. McGregor, Sholom G. Cohen 7. NOMBRE(S) Y DIRECCIÓN(ES) DE LA
ORGANIZACIÓN EJECUTORA 8. ORGANIZACIÓN REALIZADORA
NUMERO DE REPORTE
Software Engineering Institute Carnegie Mellon University
CMU/SEI2005TR003
Pittsburgh, PA 15213 9. NOMBRE(S) Y
DIRECCIÓN(ES) DE LA AGENCIA
PATROCINADORA/DE SUPERVISIÓN 10. AGENCIA PATROCINADORA/DE SEGUIMIENTO
Sede ESC/XPK 5 NUMERO DE REPORTE
Eglin Street ESCTR2005003
Hanscom AFB, MA 017312116
11. NOTAS COMPLEMENTARIAS
DECLARACIÓN DE DISTRIBUCIÓN/DISPONIBILIDAD 12A 12B CÓDIGO DE DISTRIBUCIÓN
Sin clasificar/Ilimitado, DTIC, NTIS 13. RESUMEN (MÁXIMO 200
PALABRAS)
La práctica de la línea de productos de software es una estrategia efectiva para desarrollar familias de productos intensivos en software.
El modelado de negocios es una práctica fundamental que proporciona información sobre una serie de decisiones que toman las organizaciones
que usan o consideran usar la estrategia de línea de productos. Este informe presenta el Modelo intuitivo estructurado de la economía de la línea
de productos (SIMPLE), un modelo comercial de propósito general que respalda la estimación de costos y beneficios en una organización de
desarrollo de línea de productos. El modelo respalda decisiones tales como si utilizar una estrategia de línea de productos en una situación
específica, la estrategia específica a aplicar y la idoneidad de adquirir o construir activos específicos. Este informe ilustra el alcance
del modelo al presentar varios escenarios y su utilidad al integrarlo en varios patrones de práctica de línea de productos.
El informe finaliza con una descripción del trabajo futuro destinado a hacer que el modelo sea utilizable por los profesionales de la
línea de productos.
14. TÉRMINOS DE LA MATERIA 15. NÚMERO DE PÁGINAS
línea de productos de software, modelo de costos, retorno de la inversión, ROI, economía de la 80
línea de productos, caso de negocios de la línea de productos
16. CÓDIGO DE PRECIO
17. CLASIFICACIÓN DE SEGURIDAD 18. CLASIFICACIÓN DE SEGURIDAD DE 19. CLASIFICACIÓN DE SEGURIDAD DE 20. LIMITACIÓN DEL RESUMEN
DE INFORME ESTA PÁGINA ABSTRACTO

UL
Desclasificado Desclasificado Desclasificado
NSN 7540012805500 Formulario estándar 298 (Rev. 289) Prescrito por ANSI Std. Z3918 298102

Modelo Simple

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Modelo Simple

Cargado por

Copyright:

Formatos disponibles

Machine Translated by Google

Cevo ( () + Ccab +∑ C( unique producti

t=1 i=1 i=1

Categoría Nivel de Satisfacción Compra Anual Promedio $25,000

negocio interno 80% $200,000

uso de alquiler 85% $2,000,000

Categoría Nivel de Nuevo nivel de Promedio anual

Uso personal 95% 95% $25,000

uso de alquiler 85% 90% $2,000,000

Categoría Nivel de Nuevo nivel de Aumentar Promedio Aumento esperado en

Uso personal 95% 95% 0 $25,000 0

Uso 80% 90% .1 $200,000 20,000

uso de alquiler 85% 90% .05 $2,000,00 0 100,000

Ingeniería de software Manejo tecnico Gestión organizacional

Definición de arquitectura Gestión de la configuración Construcción de un caso de negocios

(Dejar en blanco) febrero de 2005 Final

17. CLASIFICACIÓN DE SEGURIDAD 18. CLASIFICACIÓN DE SEGURIDAD DE 19. CLASIFICACIÓN DE SEGURIDAD DE 20. LIMITACIÓN DEL RESUMEN

DE INFORME ESTA PÁGINA ABSTRACTO

También podría gustarte