CAPÍTULO 12

ECONOMÍA INGENIERÍA DE SOFTWARE

SIGLAS los objetivos de negocio de la organización. En todos los tipos de

organizaciones-sea “con fines de lucro”, “sin fines de lucro,” o
EVM Gestión de Valor Ganado TIR gubernamental, esto se traduce en forma sostenible permanecer en el
Tasa Interna de Retorno TREMA negocio. En las organizaciones con fines de lucro “” Esto, además, se

mínima tasa aceptable de relaciona con achiev- ing un retorno tangible de los invertidos en capital

Volver los activos y el capital empleado. Esta KA ha sido formulado de una

manera para hacer frente a todo tipo de organizaciones independientes
SDLC La vida de desarrollo de software de ciclo SPLC
de foco, cartera de productos y servicios, o la propiedad del capital y
El software del producto ROI del Ciclo de
las restricciones de la tributación.
Vida Retorno de la Inversión ROCE retorno

sobre el capital empleado TCO

Decisiones como “¿Hay que utilizar un compo- nente específico?”
Costo total de la propiedad
Puede parecer fácil desde el punto de vista técnico, pero pueden tener

graves consecuencias sobre la viabilidad empresarial de un proyecto de

INTRODUCCIÓN software y el producto resultante. A menudo, los ingenieros se preguntan

si estas preocupaciones se aplican en absoluto, ya que son “sólo los

la economía de ingeniería de software se trata de decisiones de ING ingenieros.” Análisis económico y la toma de decisiones son importantes

MAK- relacionados con la ingeniería de software en un contexto consideraciones de ingeniería porque los ingenieros son capaces de

empresarial. El éxito de un software PRODUCIRSE UCT, el servicio, evaluar las decisiones tanto técnicamente como desde un punto de vista

y la solución depende de una buena gestión de Em- presas. Sin comercial. El contenido de esta área de conocimiento son importantes ics

embargo, en muchas empresas y organizaciones, las relaciones de alta para los ingenieros de software a tener en cuenta, incluso si nunca

comerciales de software para el desarrollo de software e ingeniería realmente están involucrados en concreto de Em- presas de decisiones;

siguen siendo vagos. Esta área de conocimiento (KA) proporciona van a tener una visión cabal de las cuestiones de negocios y el papel racio

una visión general sobre la economía de ingeniería de software. La técnicos consideraciones juegan en la toma de decisiones de negocio.

economía es el estudio de los valores, costos, recursos, y su relación Muchas de las propuestas y decisiones de ingeniería, tales como hacer

en un contexto o situación dada. En la disciplina de la niería de frente a comprar, tienen profundos impactos económicos intrínsecos que

software niería, actividades tienen costos, pero el software resultante deben ser considerados de manera explícita. Esta KA cubre primero las

tiene atributos económicos. la economía de ingeniería de software fundaciones, minology clave ter-, conceptos básicos y las prácticas

proporciona una manera de estudiar los atributos de los procesos de comunes de la economía de ingeniería de software para indicar la forma

software y software de una manera sistemática que los relaciona con en la toma de decisiones en ingeniería de software incluye o debe incluir

las medidas económicas. Estas medidas económicas pueden ser un negocio perspec- tiva. A continuación, proporciona una perspectiva del

pesados ​y analizados al tomar las decisiones que están dentro del ciclo de vida, destaca la gestión del riesgo y la incertidumbre, y muestra

alcance de un software de orga- nización y los que están dentro del cómo se utilizan los métodos de análisis económico. Algunas

alcance integral de toda una producción o adquisición de negocios. la consideraciones prácticas terminar el área El conocimiento. destaca la

economía de ingeniería de software se ocupa de la alineación de las gestión del riesgo y la incertidumbre, y muestra cómo se utilizan los

decisiones técnicas de software con métodos de análisis económico. Algunas consideraciones prácticas

terminar el área El conocimiento. destaca la gestión del riesgo y la

incertidumbre, y muestra cómo se utilizan los métodos de análisis

económico. Algunas consideraciones prácticas terminar el área El

conocimiento.

12-1
12-2 Guía SWEBOK® V3.0

Figura 12.1. Desglose de temas para la Ingeniería de Software Economía KA


DISTRIBUCIÓN DE TEMAS PARA ECONOMÍA
INGENIERÍA DE SOFTWARE
El desglose de temas para el Software Inge- niería
Economía KA se muestra en la figura 12.1.
1. Fundamentos de Ingeniería de Software
Economía
1.1. Financiar
[1 *, c2]
Finanzas es la rama de la economía que se ocupan de cuestiones
tales como la asignación, administración, adquisición, y la inversión de
los recursos. La financiación es un elemento de todas las
organizaciones, incluidas las organizaciones de ingeniería de software.
El campo de las finanzas se ocupa de los conceptos de tiempo,
dinero, riesgo, y cómo se relacionan entre sí. También se ocupa de cómo
se gasta el dinero y geted presu-. finanzas corporativas se ocupa de pro-
Viding los fondos para las actividades de una organización. En general,
se trata de equilibrar el riesgo y la capacidad de utilidades, al intentar
maximizar la riqueza de una organiza- ción y el valor de sus acciones.
Esto es válido sobre todo para las organizaciones “con fines de lucro”,
pero también se aplica a los “sin fines de lucro” organizaciones. Este
último necesita recursos financieros para garantizar la sostenibilidad,
aunque no es la orientación de beneficio tangible. Para ello, una
organización debe
• identificar los objetivos de la organización, los horizontes de tiempo,
factores de riesgo, consideraciones de impuestos, y las limitaciones
financieras;
• identificar e implementar la estrategia de Ness Busi-
apropiado, como el que las decisiones de cartera y de
inversión a tomar, cómo gestionar el flujo de caja, y dónde
obtener los fondos;
• medir el desempeño financiero, tales como el flujo de caja y el
retorno de la inversión (véase la sección 4.3, Retorno de la
Inversión), y tomar acciones correctivas en caso de desviación
de los objetivos y la estrategia.
1.2. Contabilidad
[1 *, c15]
La contabilidad es parte de las finanzas. Permite a las personas cuyo
dinero está siendo utilizado para dirigir una organización
Ingeniería de Software Economía 12-3
para conocer los resultados de su inversión: sacaron los beneficios que
se esperaban? En las organizaciones “con fines de lucro”, esto se
relaciona con el retorno de la inversión tangible (ver sección 4.3,
Retorno de la Inversión), mientras que en “sin fines de lucro” y las
organizaciones gubernamentales, así como organizaciones “con fines
de lucro”, que se traduce en forma sostenible permanecer en el
negocio. La función principal de la contabilidad es medir el rendimiento
financiero real de la organiza- ción y para com- municar información
financiera sobre una entidad de negocio para las partes interesadas,
como los accionistas, auditores financieros e inversores. La
comunicación es generalmente en la forma de estados financieros que
muestran en términos monetarios los recursos económicos que deben
ser controlados. Es importante seleccionar la información adecuada
que sea relevante y fiable para el usuario. La información y su
distribución están parcialmente rigen por las políticas de gestión de
riesgos y de gobierno. Los sistemas de contabilidad son también una
rica fuente de datos históricos para estimar.
1.3. Controlador
[1 *, c15]
El control es un elemento de las finanzas y una contabilidad.
Controladora implica medir y correcta- ing el desempeño de las
finanzas y la contabilidad. Se asegura de que los objetivos y planes
de la organización se llevan a cabo. El control de costos es una
rama especia- espe- de controlar utilizado para detectar varianzas
de los costes reales de los costes previstos.
1.4. Flujo de fondos
[1 *, c3]
El flujo de caja es el movimiento de dinero que entra o sale de un
negocio, proyecto o producto financiero durante un período determinado.
Los conceptos de instancias de flujo de caja y las corrientes de flujo de
efectivo se utilizan para describir la perspectiva de negocio de una
propuesta. Para tomar una decisión de negocios significativa sobre
cualquier propuesta específica, tendrá que ser evaluado desde una
perspectiva empresarial dicha propuesta. En una propuesta para
desarrollar y poner en marcha el producto X, el pago por nuevas licencias
de software es un ejemplo de una instancia de flujo de caja ing outgo-.
tendría que ser gastado para llevar a cabo esa propuesta dinero. Los
ingresos por ventas de producto X en el mes 11 después de su
lanzamiento al mercado es un ejemplo de un flujo de caja entrante
12-4 Guía SWEBOK® V3.0

Figura 12.2. Un Diagrama de Flujo de Caja

ejemplo. El dinero iba a venir a causa de la realización de la soluciones. A,, producto intermediario comercial off-the-shelf objeto-

propuesta. El termino flujo de efectivo se refiere al conjunto de petición puede costar varios miles de dólares, pero el esfuerzo para

instancias de flujo de efectivo con el tiempo que son causadas por la desarrollar un servicio de cosecha propia que da la misma funcionalidad

realización de alguna propuesta determinada. El flujo de caja es, en fácilmente podría costar varios cientos de veces esa cantidad. Si las

efecto, el cuadro financiero completo de esa propuesta. ¿Cuánto soluciones candidatas resolver todos adecuadamente el problema desde

dinero se apaga? ¿Cuándo se apaga? ¿Cuánto dinero entra? un punto de vista técnico, la selección de la alternativa más adecuada

¿Cuándo se presenta? Simplemente, si la corriente de flujo de efectivo debe basarse en factores comerciales tales como la optimización de coste

de Propuesta A es más deseable que la corriente de flujo de caja para total de propiedad (TCO) o maximizar el rendimiento a corto plazo de la

la Propuesta B, entonces todas las demás cosas son iguales, la inversión (ROI) . los costos del ciclo de vida tales como la corrección de

organización es ter BET de la realización de la propuesta A de la defectos, servicio de campo, y la duración de apoyo son también

Propuesta B. Por lo tanto, el flujo de efectivo stream es un insumo consideraciones Evant rel. Estos costos deben ser fac- reada en la hora de

importante para las decisiones de inversión. Un ejemplo de flujo de elegir entre los enfoques Nical gías aceptables, ya que son parte del

efectivo es una cantidad específica de dinero que fluye hacia dentro o retorno de la inversión de por vida (ver sección 4.3, Retorno de la

fuera de la organización en un momento específico, como Inversión). Un proceso sistemático para la toma de decisiones será lograr

consecuencia directa de alguna actividad. la transparencia y permitir ción posterior justificación. criterios de gobierno

en muchas organizaciones exigen la selección de al menos dos

alternativas. Un proceso sistemático se muestra en la figura 12.3. Se inicia

con un desafío de negocios a la mano y se describen los pasos para

Un diagrama de flujo de caja es una imagen de una corriente de flujo identificar solu- ciones alternativas, definir los criterios de selección,

de efectivo. Se le da al lector una visión general de la situación financiera evaluar las solu- ciones, implementar una solución seleccionada, y moni-

de la organización tema o proyecto. La figura 12.2 muestra un ejemplo de tor el desempeño de esa solución. La figura 12.3 muestra el proceso como

un diagrama de flujo de caja para una propuesta. en su mayoría paso- sabia y serie. El proceso real es más fluido. A veces,

los pasos se pueden realizar en un orden diferente y con frecuencia varios

de los pasos se pueden realizar en paralelo. Lo importante es estar seguro

1.5. Proceso de toma de decisiones de que criterios de gobierno en muchas organizaciones exigen la selección

[1 *, c2, c4] de al menos dos alternativas. Un proceso sistemático se muestra en la

figura 12.3. Se inicia con un desafío de negocios a la mano y se describen

Si asumimos que las soluciones candidatas a resolver un los pasos para identificar solu- ciones alternativas, definir los criterios de

problema técnico determinado igualmente bien, ¿por qué se selección, evaluar las solu- ciones, implementar una solución

elige el cuidado organización cuál? La respuesta es que por lo seleccionada, y moni- tor el desempeño de esa solución. La figura 12.3

general hay una gran diferencia en los costes e ingresos de los muestra el proceso como en su mayoría paso- sabia y serie. El proceso

diferentes real es más fluido. A veces, los pasos se pueden realizar en un orden diferente y con frecuencia v

Figura 12.3. El proceso de toma de decisiones de negocio básico
ninguno de los pasos se omiten o reducirse. También es importante
entender que este mismo proceso se aplica a todos los niveles de toma de
decisiones: a partir de una decisión tan grande como la determinación de
si un proyecto de software se debe hacer en absoluto, a una decisión
sobre una estructura de algoritmo o de datos a utilizar en un módulo de
software. La diferencia es la forma económicamente sig- sig- es la decisión
y, por lo tanto, la cantidad de esfuerzo debe ser invertido en la toma de
esa decisión. La decisión a nivel de proyecto es económicamente sig-
SIG-y probablemente justifica un nivel relativamente alto de esfuerzo para
tomar la decisión. La selección de un algoritmo es a menudo mucho
menos financieramente no puede signifi- y garantiza un nivel mucho más
bajo de lo posible para tomar la decisión, a pesar de que el mismo proceso
de toma de decisiones básica está siendo utilizado. Más a menudo que no,
una organización podría llevar a cabo más de una propuesta si así lo
quisiera, y por lo general no son relaciones importantes entre las
propuestas. Tal vez Propuesta Y sólo puede llevarse a cabo si la
propuesta X también se lleva a cabo. O tal vez Propuesta P no puede
llevarse a cabo si Propuesta Q se lleva a cabo, ni podía Q llevarse a cabo
si P fuera. Las opciones son mucho más fáciles de hacer cuando hay
caminos -por ejemplo que se excluyen mutuamente, ya sea A o B o C o lo
que sea que se elija. En decisiones previas pelado, se recomienda
convertir cualquier conjunto de propuestas, junto con sus diversas
interrelaciones, en un conjunto de alternativas sive excluyen mutuamente.
La elección puede hacerse entonces entre estas alternativas. O tal vez
Propuesta P no puede llevarse a cabo si Propuesta Q se lleva a cabo, ni
podía Q llevarse a cabo si P fuera. Las opciones son mucho más fáciles de
hacer cuando hay caminos -por ejemplo que se excluyen mutuamente, ya
sea A o B o C o lo que sea que se elija. En decisiones previas pelado, se
recomienda convertir cualquier conjunto de propuestas, junto con sus
diversas interrelaciones, en un conjunto de alternativas sive excluyen
mutuamente. La elección puede hacerse entonces entre estas alternativas. O tal vez Propuesta P no puede llevarse a cabo si Propuesta Q se lleva a cabo, ni podía Q
Ingeniería de Software Economía 12-5
1.6. Valuación
[1 *, C5, C8]
En un sentido abstracto, el Cess -sea decisiones financieras pro de
toma de toma de decisiones o de otro- se trata de maximizar el
valor. La alternativa que maximiza el valor total siempre debe ser
elegido. Una base financiera para la comparación basada en valores
se comparan dos o más flujos de efectivo. Varias bases de
comparación están disponibles, incluyendo
• valor actual
• valor futuro
• anual equivalente
• tasa interna de retorno
• (Descuento) periodo de recuperación.
Basado en el tiempo-valor del dinero, dos o más flujos de caja son
equivalentes sólo cuando son iguales a la misma cantidad de dinero en
un punto común en el tiempo. La comparación de los flujos de caja sólo
tiene sentido cuando se expresan en el mismo período de tiempo.
Tenga en cuenta que el valor no siempre se puede expresar en
términos de dinero. Por ejemplo, si un elemento es un nombre de
marca o no puedan alterar significativamente su valor percibido. Los
valores relevantes que no se pueden expresar en términos de dinero
todavía tienen que ser expresado en términos similares para que
puedan ser evaluados objetivamente.
12-6 Guía SWEBOK® V3.0
1.7. Inflación
[1 *, c13]
La inflación se describen las tendencias a largo plazo de los precios.
La inflación significa que las mismas cosas cuestan más que antes. Si
el horizonte de planificación de una decisión de negocios es más de
unos pocos años, o si la tasa de inflación es más de un par de puntos
porcentuales por año, puede causar cambios notables en el valor de
una propuesta. Por lo tanto, el valor del tiempo actual necesita ser
ajustado por inflación y las tasas también para las fluctuaciones del
tipo de cambio.
1.8. Depreciación
[1 *, c14]
La depreciación implica la difusión del costo de un activo
tangible a través de una serie de períodos de tiempo; que se
utiliza para determinar cómo las inversiones en activos talized
capi- se cargan contra los ingresos durante varios años. La
depreciación es una parte importante de la determinación
después de impuestos de flujo de caja, que es criti- cal para
abordar con precisión los beneficios y los impuestos. Si un
producto de software se va a vender después de que los
costes de desa- rrollo se incurren, los costos deben ser
activadas y depreciadas durante períodos de tiempo
posteriores. El gasto de depreciación para cada período de
tiempo es el costo capitalizado de desarrollar el software
dividida a través del número de periodos en los que se
venderá el software. Una propuesta de proyecto de software
puede ser comparado con otras propuestas de software y
nonsoftware o para opciones alternativas de inversión,
1.9. Impuestos
[1 *, c16, c17]
Los gobiernos cobran impuestos para financiar los gastos que la sociedad
necesita, pero que ninguna organiza- ción invertiría en. Las empresas
tienen que pagar impuestos sobre la renta, que puede tomar una parte
sustancial de la utilidad bruta de una corporación. Un análisis de decisión
que no tiene en cuenta los impuestos puede conducir a una mala elección.
Una propuesta con una alta ganancia antes de impuestos no se parecerá
casi tan rentable en términos posttax. Sin tener en cuenta los impuestos
también puede conducir a unre- alistically altas expectativas sobre la
rentabilidad podría ser un producto propuesto.
1.10. Valor temporal del dinero
[1 *, c5, c11]
Uno de los conceptos más fundamentales en las finanzas y, por tanto,
en los negocios decisiones- es que el dinero tiene valor temporal: su
valor cambia con el tiempo. Una cantidad específica de dinero en este
momento casi siempre tiene un valor diferente que la misma cantidad
de dinero en algún otro momento. Este con- cepto ha estado presente
desde la historia humana registrada más temprana y es comúnmente
conocido como valor del tiempo. Con el fin de comparar las propuestas
o elementos lio portfo-, deben ser normalizados en el costo, valor, y el
riesgo para el valor actual neto. variaciones de cambio de divisas a
través del tiempo hay que tener en cuenta sobre la base de los datos
históricos. Esto es Particularmente importante en la evolución
transfronteriza de todo tipo.
1.11. Eficiencia
[2 *, c1]
La eficiencia económica de un proceso, actividad o tarea que es la relación
entre los recursos consumidos efectivamente a los recursos previstos para
ser consumidos o deseado para ser consumidos en el cumplimiento del
proceso, actividad o tarea. Eficiencia significa “hacer las cosas bien.” Un
comportamiento eficiente, como un comportamiento efectivo, entrega
resultados, pero mantiene el esfuerzo necesario a un mínimo. Los factores
que pueden afectar la eficiencia en ingeniería de software incluyen dad
producto complejidad, requisitos de calidad, la presión del tiempo, la
capacidad del proceso, la distribución de equipo, interrupciones, la rotación
característica, las herramientas y lenguaje de programación.
1.12. Eficacia
[2 *, c1]
La eficacia es acerca de tener impacto. Es la relación
entre los objetivos alcanzados a objetivos definidos.
Eficacia significa “hacer las cosas bien.” La eficacia sólo
se fija en si se alcanzan los objetivos definidos, y no en
la forma en que se alcanzan.
1.13. Productividad
[2 *, c23]
La productividad es la relación de la salida sobre la entrada desde una
perspectiva económica. La salida es el valor

entregado. Entrada abarca todos los recursos (por ejemplo,
esfuerzo) pasaron a generar la salida. Productividad com- eficiencia
y eficacia combina desde una perspectiva orientada de valor: la
maximización de la productividad es sobre la generación de mayor
valor con menor consumo de recursos.
2. La vida de ciclo Economía
2,1. Producto
[2 *, c22] [3 *, c6]
Un producto es un bien económico (o de salida) que se crea en un
proceso que transforma fac- tores de productos (o entradas) a una
salida. Cuando se vende, un pro- ducto es un entregable que crea un
valor y una experiencia para sus usuarios. Un producto puede ser una
combinación de sistemas, soluciones, materiales, y servicios
entregados internamente (por ejemplo, en casa de la solución IT) o
externamente (por ejemplo, software aplicabilidad ción), ya sea tal cual
o como un componente para otro producto (por ejemplo, , software
embebido).
2.2. Proyecto
[2 *, c22] [3 *, c1]
Un proyecto es “un esfuerzo temporal emprendido para crear un
único producto, servicio o resultado”. 1
En la ingeniería de software, diferentes tipos de proyectos se distinguen
(por ejemplo, el desarrollo de productos, servicios externalizados,
mantenimiento de software, la creación de ser- vicio, y así
sucesivamente). Durante su ciclo de vida, un producto de software puede
requerir muchos proyectos. Por ejemplo, durante la fase de concepción
del producto, un proyecto podría llevarse a cabo para determinar los
requisitos de necesidad del cliente y del mercado; durante el
mantenimiento, un proyecto podría llevarse a cabo para producir una
próxima versión de un producto.
2.3. Programa
Un programa es “un grupo de proyectos relacionados, subprogramas y
actividades del programa gestionado de manera coordinada para obtener
beneficios que no están disponibles
1 Project Management Institute, Inc., PMI Léxico de Proyecto
Términos de gestión, 2012, www.pmi.org/
PMBOK-Guía-y-Normas / ~ / media / registro /
PMI_Lexicon_Final.ashx .
Ingeniería de Software Economía 12-7
desde la gestión de ellos de forma individual “. 2 Los programas se
utilizan a menudo para identificar y gestionar las diferentes entregas a
un solo cliente o mercado en un horizonte de tiempo de varios años.
2.4. portafolio
Los portafolios son “proyectos, programas, subcarteras y operaciones
gestionadas como un grupo para alcanzar los objetivos estratégicos.” 3 Las
carteras se utilizan para agrupar y gestionar simultáneamente todos los
activos dentro de una línea de negocio o de la organización. Mirando a
una cartera completa se asegura de que los impactos de las decisiones
son consideradas, tales como la asignación de recursos a un proyecto
específico, lo cual significa que los mismos recursos no están disponibles
para otros proyectos.
2.5. Ciclo de vida del producto
[2 *, c2] [3 *, c2]
Un ciclo de vida del producto de software (SPLC) incluye todas
las actividades necesarias para definir, construir, operar,
mantener y retirar un producto de software o servicio y sus
variantes. Las actividades de SPLC “oper- comió”, “mantener” y
“retirarse” suelen ocurrir en un período de tiempo mucho más
largo que el desarrollo de software inicial (el software de vida de
desarrollo del ciclo de SDLC-ver els Software del ciclo de vida
en el mo- Ingeniería de Software proceso KA). También las
actividades de operación y mantenimiento-retirarse de un SPLC
consumen típicamente más esfuerzo total y otros recursos de
las actividades SDLC (ver La mayoría de los costos de
mantenimiento en el KA Mantenimiento de Software). El valor
aportado por un producto de software o servicios asociados
puede determinarse objetivamente durante el marco de “operar
y mantener” tiempo. Nomics de software de ingeniería eco
deben preocuparse por todas las activi- dades SPLC,
2.6. Ciclo de Vida del Proyecto
[2 *, c2] [3 *, c2]
las actividades del ciclo de vida del proyecto implican típicamente
cinco grupos de iniciación de procesos, planificación, Execut- ción,
seguimiento y control, y cierre [4]
2 Ibídem.
3 Ibídem.
12-8 Guía SWEBOK® V3.0
(Ver el KA Software Engineering Management). Las actividades dentro
de un ciclo de vida del proyecto de software son a menudo intercalada,
se superponen, y reiterada en diversas formas [3 *, c2] [5] (ver la
Ingeniería de Procesos de Software KA). Por ejemplo, el desarrollo de
productos ágil dentro de un SPLC implica múltiples iteraciones que
producen incrementos de software entregable. Un SPLC debe incluir la
gestión del riesgo y la sincronización con los proveedores dife- rentes
(si los hay), al tiempo que proporciona información audit- poder de
toma de decisiones (por ejemplo, comply- ing con las necesidades de
responsabilidad por productos o las reglas de gobierno). El ciclo de
vida del proyecto de software y el software de ciclo de vida del
producto están relacionados entre sí; un SPLC puede incluir varios
SDLCs.
2.7. propuestas
[1 *, c3]
De tomar una decisión de negocios comienza con la noción de una propuesta.
económicos de la propuesta, ya sea de corte de seis años por dos años
Propuestas se refieren a alcanzar un objetivo de negocio, en el
proyecto, producto o nivel de cartera. Una propuesta es una opción
única, separada que se está considerando, como llevar a cabo un
proyecto de desarrollo de software en particular o no. Otra propuesta
podría ser para mejorar un componente de software existen- tes, y
todavía podría ser otra que volver a desarrollar mismo software
desde cero. Cada propuesta representa una unidad de elección, ya
sea que usted puede elegir para llevar a cabo esa propuesta o
puede optar por no hacerlo. Todo el propósito de la toma de
decisiones de negocio es averiguar, dadas las circunstancias
actuales de negocios, que las propuestas deben llevarse a cabo y
cuáles no.
2.8. Decisiones de inversión
[1 *, c4]
Los inversores a tomar decisiones de inversión para gastar dinero y
recursos en la consecución de un objetivo obje- tivo. Los inversores están
ya sea en el interior (por ejemplo, las finanzas, la placa) o fuera (por
ejemplo, bancos) de la organización. El objetivo se relaciona con algunos
criterios económicos, tales como el logro de un alto retorno de la
inversión, el fortalecimiento de las capacidades de la organización, o de
mejorar el valor de la empresa. aspectos Intangi- bles tales como la
buena voluntad, la cultura y competen- cias deben ser considerados.
2.9. Planeando el horizonte
[1 *, c11]
Cuando una organización decide invertir en una propuesta cular
par-, el dinero se hace atar en esa propuesta, los llamados “activos
congelados.” El impacto económico de los bienes congelados tiende
a comenzar y disminuye con el tiempo. Por otra parte, ING y
mantenimiento operat- costes de los elementos asociados con la
propuesta tienden a empezar con poco, pero aumentará con el
tiempo. El costo total de la propuesta, es decir, poseer y operar un
producto es la suma de estos dos costos. Al principio, los costos de
los activos congelados dominan; más tarde, los costos de operación
y mantenimiento dominan. Hay un punto en el tiempo que se
minimiza la suma de los costos; esto se llama el
tiempo de vida mínimo costo.
Para comparar adecuadamente una propuesta con una vida útil de
cuatro años a una propuesta con una vida útil de seis años, los efectos
o invertir los beneficios de la propuesta de cuatro años por otros dos
años deben ser abordados. El horizonte de planificación, a veces
conocido como el período de estudio, es el marco de tiempo constante
durante los cuales se consideran propues- tas. tendrán que tenerse en
cuenta en el establecimiento de un horizonte de planificación efectos
tales como el software vida tiempo. Una vez establecido el horizonte de
planificación, varias técnicas están disponibles para presentar
propuestas de vida diferentes períodos en que el horizonte de
planificación.
2.10. Precio y precios
[1 *, c13]
Un precio es lo que se paga a cambio de un bien o servicio. El precio es
un aspecto fundamental de la modelización financiera y es una de las
cuatro P de la comercialización
mezcla. Los otros tres son Sal producto, promoción y lugar. El precio es
el ele- mento única generadora de ingresos entre las cuatro P; el resto
son costes. El precio es un elemento de finanzas y marketing. Es el
proceso de determinar lo que es una empresa recibirá a cambio de sus
productos. factores de fijación de precios incluyen el coste de
fabricación, colo- cación mercado, la competencia, las condiciones del
mercado, y la calidad del producto. La fijación de precios se aplica a los
precios de productos y servicios basados ​en factores tales como
cantidad fija, ruptura cantidad, promoción o campaña de ventas,

cotización específica del proveedor, embarque o factura fecha,
combinación de varios pedidos, ofertas de servicios, y muchos otros. Las
necesidades del consumidor se pueden convertir en la demanda sólo si el
consumidor tiene la voluntad y la capacidad para comprar el pro- ducto.
Por lo tanto, el precio es muy importante en la comercialización. La fijación
de precios se realiza inicialmente durante la fase ción iniciativa del
proyecto y es una parte de la toma de decisiones “ir”.
2.11. Costo y costeo
[1 *, c15]
Un coste es el valor del dinero que se ha utilizado para producir algo
y, por lo tanto, no está disponible para su uso más. En economía, un
coste es una alter- nativa que se da como resultado de una decisión.
Un costo hundido es los gastos antes de un cierto tiempo,
normalmente se utiliza para decisiones abstractas de los gastos en
el pasado, lo que puede causar obstáculos emocionales en el futuro.
Desde un punto de vista económico tradicional, los costos hundidos
no deben ser considerados en la toma de decisiones. El costo de
oportunidad es el costo de una alternativa que debe ser ido lucro
con el fin de seguir otra alternativa. Cálculo del coste forma parte de
las finanzas y manage- ment producto. Es el proceso para
determinar el costo basado en los gastos (por ejemplo, producción,
ingeniería de software, distribución, retrabajo) y sobre el costo
objetivo de ser competitivos y exitosos en un mercado. El costo de
destino puede estar por debajo del costo estimado real. La
planificación y el control de estos costos (llamado manejo de costos) es
importante y siempre debe ser incluido en los costos.
Un concepto importante en el costeo es el coste total de propiedad
(TCO). Esto es válido especialmente para el software, ya que hay
muchos costos no tan obvias relacionadas con las actividades SPLC
después del desarrollo de pro- ducto inicial. TCO para un producto de
software se define como el costo total de la adquisición, activar y
mantener ese producto en funcionamiento. Estos costos se pueden
agrupar como los costes directos e indirectos. TCO es un método de
contabilidad que es crucial en la toma de decisiones económicas.
2.12. Medición del desempeño
[3 *, C7, C8]
La medición del desempeño es el proceso mediante el cual
una organización establece y mide la
Ingeniería de Software Economía 12-9
parámetros utilizados para determinar si los programas,
inversiones y adquisiciones están logrando los resultados
deseados. Se utiliza para evaluar si realmente se logran los
objetivos de rendimiento; para controlar los presupuestos, los
recursos, el progreso y las decisiones; y para mejorar el
rendimiento.
2.13. Gestion del valor ganado
[3 *, c8]
gestión del valor ganado (EVM) es una técnica de gestión de
proyectos para medir el progreso basado en el valor creado. En un
momento dado, los resultados obtenidos hasta la fecha en un proyecto
se Comparado con el presupuesto proyectado y el progreso calendario
previsto para esa fecha. El progreso se refiere recursos consumidos
ya-y ha logrado resultados en un punto dado en el tiempo con los
valores planificados respectivos de la misma fecha. Ayuda a identificar
los posibles problemas de rendimiento en una etapa temprana. Un
principio clave en EVM es el seguimiento de las variaciones de costos
y programas a través de la comparación de horario programado versus
real y el presupuesto frente a los costos reales. EVM da seguimiento
mucho más temprano vis bilidad a las desviaciones y por lo tanto
permite correcciones antes de lo clásico y el costo de seguimiento
horario que sólo se basa en documentos y productos entregados.
2.14. Las decisiones de terminación [ 1 *, c11, c12] [2 *, c9]
El cese significa poner fin a un proyecto o producto. La terminación
puede ser planificada de antemano para el final de un curso de la vida
del producto largo (por ejemplo, cuando previendo que un producto
alcanzará su vida) o puede venir en lugar espontáneamente durante el
desarrollo de productos (por ejemplo, cuando no se consiguen los
objetivos de rendimiento del proyecto). En ambos casos, la decisión debe
ser cuidadosamente preparado, teniendo en cuenta siempre las
alternativas de continuidad versus terminación. Los costos de las
diferentes alternativas deben ser temas de ING como el reemplazo, la
información lección COL-, los proveedores, las alternativas, los activos y
recursos de ING utiliz- para otras oportunidades cubierta- estima. Los
costos hundidos no deben ser considerados en dicha toma de
decisiones, ya que se han gastado y no Reap, pera como un valor.
12-10 Guía SWEBOK® V3.0
Figura 12.4. Metas, estimaciones, y Planes
2.15. Las decisiones de reemplazo y jubilación  Uno de los objetivos de negocio se relaciona necesidades empresariales
[1 *, c12] [2 *, c9]
Una decisión de reemplazo se hace cuando una organiza- ción ya
tiene un activo en particular y que están considerando reemplazar
con otra cosa; por ejemplo, decidir entre el mantenimiento de y
apoyar un producto de software heredado o volver a desarrollar
desde el principio. las decisiones de reemplazo utilizan el mismo
proceso de decisión de negocios como se describió anteriormente,
pero hay retos adicionales: costo hundido y valor de rescate. las
decisiones de retiro son también de salir de una actividad por
completo, como cuando una compañía de software no considera la
venta de un producto de software más o un fabricante de hardware
no considera la construcción y venta de un determinado modelo de
ordenador por más tiempo. jubi- lación decisión puede estar
influenciada por fac- tores lock-in, tales como la dependencia de la
tecnología y los altos costos de salida.
3. Riesgo e Incertidumbre
3.1. Metas, estimaciones, y Planes
[3 *, c6]
Goles en la economía de ingeniería de software son en su mayoría los
objetivos de negocio (u objetivos de negocio).
(como el aumento de la rentabilidad) a los recursos de inversión (tales
como iniciar un proyecto o el lanzamiento de un pro- ducto con un
presupuesto dado, contenido y el tiempo). Objetivos se aplican a la
planificación operativa (por ejemplo, para llegar a un determinado hito en
una fecha determinada o para ampliar las pruebas de software por un
cierto tiempo para lograr un nivel de calidad deseado, ver cuestiones clave
de la Prueba KA Cesión de Software) y al nivel estratégico ( tales como
alcanzar una cierta rentabilidad o cuota de mercado en un período de
tiempo establecido).
Una estimación es una evaluación fundada de recursos y el tiempo
que se necesita para lograr los objetivos planteados (ver Esfuerzo,
Calendario, y Estimación de Costos de la Ingeniería de Software de
Gestión de KA y Estimación de Costos de Mantenimiento en el KA
Mantenimiento de Software). Una estimación de software se utiliza para
determinar si los objetivos del proyecto se puede lograr dentro de las
restricciones sobre los atributos programación, presupuesto,
características y calidad. Las estimaciones son típicamente generados
internamente y no son necesariamente visibles externamente. Las
estimaciones no deben ser conducidos exclusivamente por los objetivos
del proyecto, ya que esto podría hacer una estimación excesivamente
opti- mista. La estimación es una actividad periódica; estimaciones
deben ser revisados ​continuamente durante un proyecto. Un plan
describe las actividades e hitos que son necesarias para alcanzar los
objetivos de

un proyecto (véase el software de planificación en el KA Software
Engineering Management). El plan debe estar en línea con la meta
y el compañero de estimación, que no es necesariamente fácil y
obvi- ous-por ejemplo, cuando un proyecto de software con los
requisitos dados tomaría más tiempo que la fecha límite prevista por
el cliente. En tales casos, los planes exigen una revisión de los
objetivos iniciales, así como Las estimaciones y las incertidumbres
subyacentes y las inexactitudes. soluciones creativas con los
fundamentos del sistema de alcanzar una posición de ganar-ganar
se aplican para resolver conflictos.
Para ser de valor, la planificación debe involucrar consideración con-
de las restricciones del proyecto y los compromisos a los interesados. La
figura 12.4 muestra cómo se definen inicialmente objetivos. Los cálculos
se realizan sobre la base de los objetivos iniciales. El plan intenta hacer
coincidir los objetivos y las estimaciones. Este es un proceso iterativo,
debido a una estimación inicial normalmente no cumple con los objetivos
iniciales.
3.2. Las técnicas de estimación
[3 *, c6]
Las estimaciones se utilizan para analizar y prever los recursos o el
tiempo necesarios para implementar los requisitos (ver Esfuerzo,
Calendario, y Estimación de Costos de la Ingeniería de Software de
Gestión de KA y Estimación de Costos de Mantenimiento en el KA
Mantenimiento de Software). Existen cinco familias de técnicas de
estimación:
• Juicio experto
• Analogía
• Estimación por piezas
• métodos paramétricos
• Métodos de estadística.
Sin sola técnica de estimación es perfecto, por lo que el uso de la
técnica de estimación múltiple es útil. La convergencia entre las
estimaciones producidas por diferentes técnicas indica que las
estimaciones son probablemente exacta. Difundir entre los
compañeros estimación indica que ciertos factores podrían haber sido
pasados ​por alto. La búsqueda de los factores que causaron la
propagación y luego volver a estimar de nuevo para pro- ducir
resultados que convergen podría conducir a una mejor estimación.
Ingeniería de Software Economía 12-11
3.3. La incertidumbre abordar
[3 *, c6]
Debido a los muchos factores desconocidos durante la iniciación y
planificación de proyectos, las estimaciones son inciertas; que la
incertidumbre debe tratarse de decisiones de negocio. Las
técnicas para hacer frente a la incertidumbre incluyen
• considerar rangos de estimaciones
• analizar la sensibilidad a los cambios de las hipótesis
• retrasar las decisiones finales.
3.4. priorización
[3 *, c6]
Priorización implica alternativas clasificación basada en criterios
comunes para ofrecer el mejor valor posible. En los proyectos de
ingeniería de software, requisitos de software a menudo se
priorizan con el fin de ofrecer el mayor valor al cliente dentro de
straints con- de programación, presupuesto, recursos y tecno-
logía, o para proporcionar para la construcción de incrementos de
productos, donde los primeros incrementos proporcionar el mayor
valor para el cliente (ver requisitos de clasificación y requisitos de
la Negociación en los requisitos de software KA y del ciclo de vida
del software los modelos de la Ingeniería de procesos de Software
KA).
3.5. Las decisiones en riesgo
[1 *, c24] [3 *, c9]
Las decisiones técnicas de bajo riesgo se utilizan cuando el
tomador de decisiones puede asignar probabilidades a los
diferentes resultados posibles (véase Gestión de Riesgos en el KA
Software Engineering Management). Las técnicas específicas
incluyen
• la toma de decisiones valor esperado
• varianza expectativa y la toma de decisiones
• El análisis de Monte Carlo
• árboles de decisión
• valor esperado de la información perfecta.
12-12 Guía SWEBOK® V3.0

Figura 12.5. El proceso de toma de decisiones con fines de lucro

3.6. Las decisiones bajo incertidumbre [ 1 *, c25] [3 *, c9] 4. Métodos de Análisis Económico

4.1. Con fines de lucro Análisis de Decisiones

Las decisiones bajo incertidumbre técnicas se utilizan cuando el [1 *, c10]
tomador de decisiones no puede asignar probabili- dades a los
diferentes resultados posibles porque la información necesaria no Figura 12.5 se describe un procedimiento para la identificación de la mejor

está disponible (véase Gestión de Riesgos en el KA Software alternativa de un conjunto de alternativas sivos mutuamente exclusiones.

Engineering Management). Las técnicas específicas incluyen Los criterios de decisión dependen de los objetivos de negocio y por lo

general incluyen retorno de la inversión (véase la sección 4.3, Retorno de

la Inversión) o Retorno sobre el capital empleado (ROCE) (ver sección 4.4,

• Regla de Laplace rendimiento del capital invertido). Para fines de lucro técnicas de toma no

• Regla Maximin se aplican a las organizaciones gubernamentales y sin fines de lucro. En

• Regla maximax estos casos, las organizaciones tienen diferentes objetivos, lo que significa

• Regla Hurwicz que se necesita un conjunto diferente de las técnicas de toma, como el

• Regla arrepentimiento minimax. coste-beneficio o el análisis coste-efectividad Ness.


4.2. Tasa aceptable de retorno mínima [ 1 *, c10]
La tasa mínima aceptable de rendimiento (TREMA) es la más baja
tasa interna de retorno de la organiza- ción consideraría como una
buena inversión. En términos generales, no sería inteligente para
invertir en una actividad con un rendimiento del 10% cuando no hay
otra actividad que se sabe que devolver el 20%. La TREMA es una
declaración de que una organización confía en que puede lograr al
menos que la tasa de rendimiento. La TREMA representa el costo
de oportunidad de la organización para las inversiones. Al elegir a
invertir en algún tipo de actividad, la organización está decidiendo
explícitamente a no invertir ese mismo dinero en otro lugar. Si la
organización es ya confía en que puede conseguir un poco de
velocidad conocida de retorno, otras alternativas deben elegirse sólo
si su tasa de rendimiento es al menos tan alto. Una manera sencilla
para dar cuenta de que el coste de oportunidad es utilizar la TREMA
como la tasa de interés en las decisiones empresariales. valor
actual de una alternativa evaluada en la TREMA muestra cuánto
más o menos (en términos de caja actuales) que vale la pena
alternativa es que la inversión en el Marr.
4.3. Retorno de la inversión
[1 *, c10]
Retorno de la inversión (ROI) es una medida de la rentabilidad de
una empresa o unidad de negocio. Se define como la relación entre
el dinero ganado o perdido (realizadas o no realizadas) en una
inversión con respecto a la cantidad de dinero invertido. El
propósito de retorno de la inversión varía e incluye, por ejemplo,
proporcionando una base para futuras inversiones y decisiones de
adquisición.
4.4. Rendimiento del capital invertido
El retorno sobre el capital empleado (ROCE) es un seguro de medi- de la
rentabilidad de una unidad de empresa o negocio. Se define como la
relación de un beneficio bruto antes de impuestos e intereses (EBIT) para
el total de activos menos pasivos corrientes. En él se describe el
rendimiento del capital utilizado.
Ingeniería de Software Economía 12-13
4.5. Análisis coste-beneficio
[1 *, c18]
Análisis coste-beneficio es uno de los métodos más utilizados para
la evaluación de ALS propues- individuales. Cualquier propuesta
con una relación beneficio-costo de menos de 1,0 por lo general
puede ser rechazada sin análisis adicional porque costaría más
que el beneficio. Las propuestas con una necesidad mayor
proporción de con- Sider el riesgo asociado de una inversión y
comparar los beneficios con la opción de invertir el dinero a una
tasa de interés garantizada (ver sec- ción 4.2, aceptable tasa de
retorno mínima).
4.6. Análisis coste-efectividad
[1 *, c18]
Análisis coste-efectividad es similar al análisis de
coste-beneficio. Hay dos versiones de análisis
coste-eficacia: la Costo fijo Versión maximiza el beneficio
dado alguna cota superior en el precio; el -Efectividad fijo Versión
minimiza el costo necesario para lograr un objetivo fijo.
4.7. Punto de equilibrio de analisis
[1 *, c19]
análisis de equilibrio identifica el punto en el que los costos de
desarrollo de un producto y los ingresos que se generen son
iguales. Tal análisis se puede utilizar para elegir entre diferentes
propuestas a diferentes costos estimados y los ingresos.
estimación dada acoplado costes e ingresos de dos o más ALS
propues-, análisis de equilibrio ayuda a la hora de elegir entre
ellos.
4.8. Business Case
[1 *, c3]
El modelo de negocio es la información consolidada resumir y
explicar una propuesta de negocio desde diferentes perspectivas para
un tomador de decisiones (costo, beneficios, riesgos, y así
sucesivamente). A menudo se utiliza para evaluar el valor potencial
de un producto, que puede ser utilizado como base en la inversión
proceso de decisión. A diferencia de un simple cálculo de la pérdida
de utilidades, el modelo de negocio es un “caso” de los planes y
análisis que es propiedad del producto
12-14 Guía SWEBOK® V3.0
gerente y utilizada en apoyo de la consecución de los objetivos de
negocio.
4.9. Evaluación Atributo múltiple
[1 *, c26]
Los temas tratados hasta ahora se utilizan para hacer las
decisiones sobre la base de un único criterio de decisión: el
dinero. La alternativa con el mejor valor actual, la mejor ROI, y
así sucesivamente es la seleccionada. Aparte de viabilidad
técnica, el dinero es casi siempre el criterio de decisión más
importante, pero no es siempre el único. Muy a menudo hay otros
criterios, otros “atributos”, que deben tenerse en cuenta, y esos
atributos no se pueden colar en términos de dinero. de toma de
atributos múltiples técnicas permiten otros criterios no financieros,
que sean fac- reada en la decisión.
Hay dos familias de múltiples técnicas de toma de atributos que
difieren en cómo utilizan los atributos en la decisión. Una familia
es la “compensación”, o, técnicas-dimensionada individuales. Esta
familia se derrumba todos los atributos en un único factor de
mérito. La familia está llamada compensatoria, ya que, para
cualquier alternativa dada, una puntuación más baja en un atributo
puede ser compensada por-o-objeto de comercio frente una
puntuación más alta en otros atributos. Las técnicas de
compensación incluyen
• escala adimensional
• de ponderación aditiva
• proceso analítico jerárquico.
Por el contrario, la otra familia es la “compensatorio no
transmisibles”, o totalmente dimensionada, técnicas. Esta familia
no permite concesiones entre los atributos. Cada atributo es
tratada como una entidad separada en el proceso de decisión. Las
técnicas tory noncompensa- incluyen
• dominio
• satisficing
• lexicografía.
4.10. Análisis de optimización
[1 *, c20]
El uso típico de análisis de optimización es el estudio de una
función de coste en un rango de valores para
encontrar el punto en el rendimiento general es mejor. clásica disyuntiva
espacio-tiempo de software es un ejemplo de optimización; un algoritmo
que se ejecuta más rápido con frecuencia utiliza más memoria.
Optimización equilibra el valor del tiempo de ejecución más rápida contra
el costo de la memoria adicional. El análisis de opciones reales se puede
usar para cuantificar el valor de opciones de proyectos, incluyendo el
valor de retrasar una decisión. Estas opciones son difíciles de calcular
con precisión. Sin embargo, la conciencia de que las opciones tienen un
valor monetario proporciona la penetración en el calendario de las
decisiones tales como el personal del proyecto ING increas- o alargando
el tiempo de comercialización para mejorar la calidad.
5. Consideraciones prácticas
5.1. El “suficientemente bueno” Principio
[1 *, c21]
A menudo los proyectos de ingeniería de software y productos no son
precisos acerca de los objetivos que deben alcanzarse. Requisitos de
software se expresan, pero el valor marginal de agregar un poco más de
funciona- lidad no se pueden medir. El resultado podría ser la entrega
tarde o demasiado-alto costo. El “suficientemente bueno” principio se
relaciona valor marginal al coste marginal y proporciona orientación para
determinar los criterios cuando un entregable es “suficientemente bueno”
para ser entregados. Estos criterios dependen de los objetivos del
negocio y en la priorización de las distintas alternativas, tales como la
clasificación de los requisitos de software, atributos medibles cali- dad, o
relativas a la programación con- tenido y coste del producto.
El principio RACE (reducir los accidentes y la esencia de control) es
un gobierno popular hacia un buen software suficiente. Los accidentes
implican gastos generales innecesarios tales como la sobrerregulación y
retrabajo debido a la eliminación de defectos tarde o demasiado muchos
cambios requisitos. Esencia es lo que pagan los clientes por.
Soft-economía de ingeniería cerámica ofrece los meca- nismos para
definir los criterios que determinan cuándo un entregable es
“suficientemente bueno” para ser entregados. También destaca que
ambas palabras son relevantes: “suficiente” “bueno” y la insuficiente
calidad o cantidad insuficiente no es lo suficientemente bueno. Los
métodos ágiles son ejemplos de “suficientemente bueno” que tratan de
optimizar el valor mediante la reducción de la cabeza excesiva de
retrabajo retrasado y el chapado de oro que

resulta de la adición de características que tienen valor marginales
bajos para los usuarios (ver Métodos ágiles en los modelos de
ingeniería de software y métodos KA y Vida Software Modelos de
Ciclo de la Ingeniería de Procesos de Software KA). En ods met
ágiles, planificación detallada y las largas fases de desarrollo se
sustituyen por la planificación incrementales y entrega frecuente de
pequeños incrementos de un producto erable deliv- que se prueba y
evaluadas por representantes de los usuarios.
5.2. Economía-Friction Free
la fricción económica es todo lo que mantiene merca- dos de tener la
competencia perfecta. Se trata de distancia, el costo de la entrega, las
regulaciones restrictivas, y / o información imperfecta. En los mercados
de alta fricción, los clientes no tienen muchos proveedores entre los que
elegir. Después de haber sido en un negocio por un tiempo o ser
propietario de una tienda en una buena ubicación determina la posición
económica. Es difícil para los nuevos competidores para iniciar negocios
y competir. El mercado se mueve lentamente y de manera previsible.
mercados libres de fricción son justo lo contrario. Surgen nuevos
competidores y los clientes son rápidos en responder. El mercado es
cualquier cosa menos capaces predecible. En teoría, el software y TI son
rozamientos. Las nuevas empresas pueden crear fácilmente los
productos y a menudo lo hacen a un costo mucho más bajo que
blecimientos empresas cado, ya que no tendrá que considerar cualquier
legado. Marketing y ventas se pueden hacer a través de Internet y las
redes sociales, y los mecanismos de distribución bási- camente libres
pueden permitir una rampa hasta un negocio global. Software Engineer-
economía ing tiene como objetivo proporcionar bases para juzgar cómo
un negocio de software lleva a cabo y cómo libre de fricción un mercado
que realmente es. Por ejemplo, la competencia entre los desarrolladores
de aplicaciones de software se inhibe cuando las aplicaciones deben ser
vendidos a través de una tienda de aplicaciones y cumplen con las
normas de esa tienda.
5.3. ecosistemas
Un ecosistema es un entorno compuesto por todas las partes
mutuamente dependientes, unidades de negocio y empresas que
trabajan en un área particular.
Ingeniería de Software Economía 12-15
En un ecosistema típico, hay productores y consumidores, en los que
los consumidores agregan valor a los recursos consumidos. Tenga en
cuenta que un consumidor no es el usuario final, sino una
organización que utiliza el producto para mejorarla. Un ecosistema de
software es, por ejemplo, un proveedor de una aplicación trabajando
con las empresas que hacen la instalación y el puerto SUP- en
diferentes regiones. Ninguno de los dos puede existir sin el otro. Los
ecosistemas pueden ser permanentes o temporales. la economía de
ingeniería de software proporciona los mecanismos para evaluar
alternativas en el establecimiento o la ampliación de una instancia
ecosistema para, evaluar si trabajar con un distribuidor espe- CIFIC o
tiene la distribución realizada por una empresa que realiza el servicio
en un área.
5.4. La deslocalización y la externalización
La deslocalización significa la ejecución de una actividad de negocio
más allá de ventas y comercialización fuera del país de origen de una
empresa. Las empresas típicamente tienen sus ramas de
deslocalización en países de bajos costes o que piden las empresas
especializadas en el extranjero para ejecutar la actividad respectiva.
ING Offshor- tanto, no debe confundirse con la externalización. La
deslocalización dentro de una empresa se llama deslocalización
cautiva. La subcontratación es la relación entados resultado-ori- con
un proveedor que ejecuta actividades de negocio para una empresa
cuando, tradicional- mente, esas actividades fueron ejecutadas dentro
de la empresa. La externalización es un sitio independiente. El
proveedor puede residir en la vecindad de la empresa o en alta mar
(subcontratado offshor- ing). la economía de ingeniería de software
proporciona los criterios básicos y herramientas de negocio para
evaluar diferentes mecanismos de aprovisionamiento y controlar su
rendimiento. Por ejemplo, el uso de un proveedor de externalización
de desarrollo de software y el mantenimiento podría reducir el coste
por hora de desarrollo de software, pero aumentar el número de
horas y los gastos de capital debido a una mayor necesidad de
seguimiento y comunicación. (Para más infor- mación sobre la
deslocalización y la externalización, consulte “externalización” en
cuestiones de gestión en el mantenimiento del software KA).
12-16 Guía SWEBOK® V3.0

MATRIZ DE TEMAS VS. MATERIAL DE REFERENCIA

Sommerville 2011
Tockey 2005

Fairley 2009
[3 *]
[2 *]
[1 *]
1. Fundamentos de Ingeniería de Software
Economía

1.1. Financiar c2

1.2. Contabilidad c15

1.3. Controlador c15

1.4. Flujo de fondos c3

1.5. Proceso de toma de decisiones c2, c4

1.6. Valuación C5, C8

1.7. Inflación c13

1.8. Depreciación c14

1.9. Impuestos c16, c17

1.10. Valor temporal del dinero C5, C11

1.11. Eficiencia c1

1.12. Eficacia c1

1.13. Productividad c23

2. La vida de ciclo Economía

2,1. Producto c22 c6

2.2. Proyecto c22 c1

2.3. Programa

2.4. portafolio

2.5. Ciclo de vida del producto c2 c2

2.6. Ciclo de Vida del Proyecto c2 c2

2.7. propuestas c3

2.8. Decisiones de inversión c4

2.9. Planeando el horizonte c11

2.10. Precio y precios c13

2.11. Costo y costeo c15

2.12. Medición del desempeño C7, C8

2.13. Gestion del valor ganado c8

2.14. Las decisiones de terminación c11, c12 C9

2.15. Las decisiones de reemplazo y jubilación c12 C9

 Ingeniería de Software Economía 12-17

Sommerville 2011
Tockey 2005

Fairley 2009
[3 *]
[2 *]
[1 *]
3. Riesgo e Incertidumbre

3.1. Metas, estimaciones, y Planes c6

3.2. Las técnicas de estimación c6

3.3. La incertidumbre abordar c6

3.4. priorización c6

3.5. Las decisiones en riesgo c24 C9

3.6. Las decisiones bajo incertidumbre c25 C9

4. Métodos de Análisis Económico

4.1. Con fines de lucro Análisis de Decisiones c10

4.2. Tasa de retorno mínima aceptable c10

4.3. Retorno de la inversión c10

4.4. Rendimiento del capital invertido

4.5. Análisis coste-beneficio c18

4.6. Análisis coste-efectividad c18

4.7. Punto de equilibrio de analisis c19

4.8. Business Case c3

4.9. Evaluación Atributo múltiple c26

4.10. Análisis de optimización c20

5. Consideraciones prácticas

5.1. El “suficientemente bueno” Principio c21

5.2. Economía-Friction Free

5.3. ecosistemas

5.4. La deslocalización y la externalización

12-18 Guía SWEBOK® V3.0

LECTURAS ADICIONALES Referencias

Una guía para la Dirección de Proyectos  [1 *] S. Tockey, Retorno de software: Maximizar 

Conocimiento (Guía PMBOK®) [ 4].
los Guía del PMBOK® proporciona directrices para la gestión de
proyectos individuales y define conceptos relacionados con la gestión
de proyectos. También describe el ciclo de vida de gestión de proyectos
y sus procesos relacionados, así como el ciclo de vida del proyecto. Es
una guía reconocida a nivel mundial para la profesión agement el
proyecto hombre-.
Software de la extensión de la Guía para el Proyecto 
Cuerpo de Gestión del Conocimiento (SWX) [ 5].
SWX proporciona adaptaciones y ampliaciones de las prácticas
genéricas de gestión de proyectos documentado en el Guía del
PMBOK® para la gestión de proyectos de software. La principal
contribución de esta extensión a la Guía del PMBOK® es descrip- ción [5] Instituto de Gestión de Proyectos e IEEE
de los procesos que son aplicables para la gestión de proyectos de
software de ciclo de vida de adaptación.
el retorno de su inversión en software,
Addison-Wesley, 2004.
[2 *] JH Allen et al., software de Seguridad 
Ingeniería: Guía para los gerentes de
proyecto, Addison-Wesley, 2008.
[3 *] RE Fairley, La gestión y líder 
Los proyectos de software, Wiley-IEEE Computer Society
Press, 2009.
[4] Instituto de Gestión de Proyectos, Una guía 
para la Dirección de Proyectos del Conocimiento
(PMBOK (R) Guía), 5ª ed., Project Management
Institute, 2013.
Computer Society, Software de la extensión de la Guía
del PMBOK® quinta edición, ed: Project Management
Institute, 2013.

BW Boehm, Economía Ingeniería de Software  [6] BW Boehm, Ingeniería de software 

[6]. Ciencias económicas, Prentice-Hall, 1981.

Este libro es la lectura clásica en la economía de ingeniería de [7] C. Ebert y R. Dumke, Software 
software. Proporciona una visión general del pensamiento Medición, Springer, 2007.
empresarial en ingeniería de software. Aunque los ejemplos y
figuras son anticuadas, todavía vale la pena leer. [8] DJ Reifer, Haciendo la Business Software 
Caso: Mejoramiento por los números,
Addison Wesley, 2002.
C. Ebert y R. Dumke, Medición de software 
[7].

Este libro ofrece una visión general sobre los métodos

cuantitativas en la ingeniería de software, comenzando con la
teoría de la medición y procediendo a la gestión del rendimiento y
la toma de decisiones empresariales.

DJ Reifer, Haciendo el caso Business Software: 

Mejora por los números [ 8].

Este libro es una lectura clásica en la fabricación de un caso

Ness Busi- en el software y las empresas. Muchos ejemplos útiles
ilustran cómo el caso de negocio se formula y se cuantificó.