Marco Teórico BPM

2 Marco Terico
2.1
Procesos
Los procesos, en el mundo moderno, son el patrn de trabajo de la gran

mayora de las empresas formalmente estructuradas. Los procesos le
aportan a las empresas el poder de conocerse y de ver cmo estn
evolucionando. Esto lo logran a travs de los indicadores que se pueden
obtener, los cuales pueden medir el grado de efectividad que se est
obteniendo por realizar las actividades de negocio de la manera como fueron
planteadas.
Para la industria de desarrollo de software a la medida, no es diferente el uso
de procesos organizaciones. Una de las actividades crticas para el
desarrollo de software a la medida es la estimacin. Esta macro-actividad
est sujeta a un gran nmero de variables y que, dependiendo como se
realice, puede obtenerse grandes diferencias del resultado de la ejecucin
cada vez que se lleve a cabo. Es por esto que la macro-actividad de
estimacin de proyectos de software a la medida se hace necesario incluirla
dentro de un proceso organizacional para poder controlarla y saber si el
proceso planteado se esta realizando de la manera adecuada o necesita
ajustes.
2.1.1
Definicin

Un proceso de negocio es un conjunto de tareas relacionadas
lgicamente llevadas a cabo para lograr un resultado de negocio
definido. Cada proceso de negocio tiene sus entradas, funciones y
salidas. Las entradas son prerrequisitos que deben tenerse antes de
que una funcin pueda ser aplicada. Cuando una funcin es aplicada a
las entradas de un mtodo, tendremos ciertas salidas resultantesi.
2.2
Metodologas Para el Modelamiento De Procesos
2.2.1
IDEF0
La traduccin literal de las siglas IDEF es Integration Definition for
Function Modeling (Definicin de la integracin para la modelizacin de
las funciones). IDEF consiste en una serie de normas que definen la
metodologa para la representacin de funciones modelizadas.
Estos modelos consisten en una serie de diagramas jerrquicos junto
con textos y referencias cruzadas entre ambos que se representan
mediante rectngulos o cajas y una serie de flechas. Uno de los
aspectos de IDEF0 ms importantes es que como concepto de
modelizacin va introduciendo gradualmente ms y ms niveles de
detalle a travs de la estructura del modelo. De esta manera, la
comunicacin se produce dando al lector un tema bien definido con
una cantidad de informacin detallada disponible para profundizar en el
modelo.
http://es.wikipedia.org/wiki/Proceso_de_negocio
2.2.2
Bussines Process Modeling Notation
El Business Process Management Initiative fue desarrollado como el

estndar BMPN. La especificacin del BPMN 1.0 fue liberada al
pblico en mayo del 2004. El principal objetivo del BPMN es proveer
una notacin que est disponible para ser entendida por todos los
usuarios del negocio, desde los analistas, que crean los primeros
borradores de los procesos, hasta los desarrolladores tcnicos
responsables de la implementacin de la tecnologa que ejecutar
dichos procesos.
Un diagrama BPM define un diagrama BPD (Diagrama de Procesos de
Negocio), el cual es basado en una tcnica de diagrama de flujo que
conduce a la creacin de las operaciones de los procesos de negocios
a travs de modelos grficos.
Un BDP est constituido por un conjunto de elementos grficos, los
cuales permiten el fcil desarrollo de diagramas que sern familiares
para la mayora de los analistas de negocios. Los elementos que
constituyen el diagrama fueron diseados para ser distinguibles unos
de otros y utilizan figuras que son familiares para la mayora de los
modeladores de procesos. Esto enfatiza que uno de los objetivos del
desarrollo de BPMN es crear un simple mecanismo para la creacin de
modelos de procesos, mientras que al mismo tiempo pueden manejar
la complejidad inherente en los procesos de negocio. Esta
aproximacin permite manejar conflictos entre los requisitos en la
organizacin y los aspectos de modelamiento de los procesos que
estos generan.
2.2.2.1
Alcance de BPMN
El alcance de BPMN est direccionado a soportar los conceptos de

modelamiento aplicado a los procesos de negocios. Con esto se
quiere decir que otros tipos de diagramas realizados por las
empresas que no representen procesos de negocio, estn por fuera
del alcance de BPMN. Un ejemplo claro para lo que est por fuera
del alcance de BPMN son los diagramas de:
Estructuras organizacionales
Modelos de informacin
Estrategia
Adicionalmente, aunque en los diagramas de BPMN se presentan

mensajes, y la asociacin de estos mensajes a artefactos, los
diagramas de BPMN no son diagramas de flujo de datos.
2.2.2.2
Usos de BPMN
La modelacin de procesos de negocio es usada para comunicarse

a una gran variedad de audiencias. BPMN es diseado para cubrir
muchos tipos de modelados y permite la creacin de procesos de
negocio de "principio a fin" (end-to-end). La estructura de los
elementos de BPMN permite a los lectores que fcilmente
diferencien las secciones de un diagrama BPMN. Existen
bsicamente tres tipos de sub-modelos y un BPMN de "principio a
fin".
Proceso de Negocio Privado (de uso interno): Son aquellos cuyo
uso es interno a las organizaciones, y estos son generalmente
llamados flujos de trabajo. Un ejemplo de un proceso privado se

puede ver en la Figura 2.
Figura 2. Proceso Privado. Fuente. Introduction to BPMN, Stephen

A. White, IBM Corporation
Proceso Abstracto (pblico): Este representa las interacciones entre
un proceso de negocio privado y otros procesos o participantes.
Estas actividades son usadas slo para comunicar hacia afuera de
los procesos de negocios privados, incluyendo los mecanismos de
control de flujo. Todas las actividades "internas" de un proceso de
negocio no son mostradas en los procesos abstractos. As, los
procesos abstractos muestran la secuencia de mensajes con el
exterior, que son los que requieren interactuar con el proceso de
negocio. Un ejemplo de un proceso abstracto se puede ver en la
Figura 3
Figura 3. Proceso abstracto. Introduction to BPMN, Stephen A.

White, IBM Corporation
Proceso de Colaboracin (global): Este representa la interaccin

entre dos o ms entidades de negocio. Estas interacciones son
definidas como una secuencia de actividades que representan un
patrn de intercambio de mensajes entre las entidades involucradas.
Un proceso de colaboracin puede se mostrado como dos o ms
procesos abstractos que se comunican entre s. Un ejemplo de este
tipo de proceso se puede ver en la Figura 4
Figura 4. Proceso colaborativo. Introduction to BPMN, Stephen A.

White, IBM Corporation
2.2.2.3
Tipos de Diagramas BPD
Dentro de estos tres tipos de submodelos, muchos diagramas

pueden ser creados. Los siguientes diagramas son los que pueden
ser modelados con BPMN:
Proceso privado de actividades de alto nivel.
Proceso de negocio privado detallado.
Viejos procesos de negocios
Nuevos procesos de negocio
Procesos de negocios detallados con interaccin a una o ms

entidades externas (o procesos cajas negras).
2.2.2.4
Conjunto de Elementos de BPD
El objetivo de BPMN es crear un mecanismo simple para la creacin

de modelos de procesos de negocio, mientras que al mismo tiempo
permita manejar la complejidad inherente a los procesos de
negocio. Esta aproximacin entra en conflicto entre s para organizar
grficamente.
Existen cuatro categoras bsicas para los elementos (Ver ejemplo
de estos elementos en la Tabla 2:
Objetos de Flujo (Eventos, Actividades, Entradas)
Objetos de Conexin (Flujo de Secuencia, Flujo de Mensaje,

Asociacin)
Swimlanes (Pools, Lanes)
Artefactos (Objetos de Datos, Grupos, anotaciones).
Elemento
Evento
Descripcin
Smbolo
Un evento es algo
que pasa durante la
ejecucin
de
un
proceso de negocio.
Estos eventos afectan
el flujo del proceso y
usualmente tienen un
impacto. Hay tres
tipos
de
eventos
establecidos cuando
afectan el flujo:
Iniciales
Intermedios
Finales.
Actividad
Control
Una Actividad es un
trmino genrico para
cualquier trabajo que
se realice dentro de la
compaa. Una
actividad puede ser o
no atmica. Los tipos
de actividades que
son parte del modelo
de procesos son:
Procesos
sub.-Procesos
Tareas
.
Una
decisin
es
usada para controlar
la
divergencia
y
convergencia de un
flujo. Esto determina
la ramificacin de los
hilos y la unin de los
caminos.
Tabla 2. Elementos Bsicos BPD. Fuente: Introduction to BPM,

Stephen A. White, IBM Corporation
2.2.2.5
Procesos
En BPMN un proceso es definido como un grfico de flujo de
objetos, los cuales son un conjunto de actividades y de controles
que muestran una secuencia de pasos. El concepto de proceso es
intrnsecamente jerrquico. Los procesos pueden ser definidos a
cualquier nivel organizacional para ser ejecutados por una simple
persona.
2.2.2.6
Beneficios del uso de BPMN
Facilidad para el entendimiento y la Comunicacin:

La definicin de procesos formales y bien definidos han demostrado
que aumentan dramticamente el entendimiento de los mismos.
Suficiente Informacin: Los procesos bien definidos proveen
suficiente informacin para que alguien o un equipo de trabajo
ejecute un proceso descrito, as agilizan el aprendizaje de lo que se
est haciendo.
2.3
Conceptos Crticos de Estimacin
2.3.1
Qu es una estimacin?
En trminos generales, una estimacin es una prediccin de cunto va

a durar un proyecto o cunto va a costar. Esto incluye la planeacin
asociada que se debe realizar para la inversin de esfuerzo, la
duracin en tiempo y los recursos necesarios para llevarlo a cabo. Una
estimacin es siempre un clculo aproximado, realizado con algn tipo
de mtodo, por lo tanto tiene implcito un margen error posible frente al
resultado real sobre lo que se estim.
De acuerdo con esta definicin, para proyectos de software la
estimacin se presenta en trminos de duracin del proyecto, esfuerzo
del personal que integra el desarrollo del proyecto (diferenciados por
roles, como programadores) y otros costos logsticos, como equipos de
cmputo, licencias de software, transporte, entre otros.
A pesar que por definicin, la estimacin de un proyecto es una
prediccin que siempre cuenta con un grado de incertidumbre, en la
industria de software el concepto de estimacin en proyectos de
software se entrelaza frecuentemente con los conceptos de metas del

negocio y con el establecimiento de compromisos. Para establecer
claridad entre los conceptos se plantea, que:
o Una meta es una declaracin de un objetivo del negocio.
Ejemplo: Necesitamos tener lista en Junio la versin 2.0
del sistema X para cumplir con la nueva legislacin
o Un compromiso es una promesa de entregar una
funcionalidad definida, con un nivel especfico de calidad,
en una fecha establecida.
2.3.2
Consecuencias de una mala estimacin

La mala estimacin de un proyecto de software puede traer varias
consecuencias:
Efectividad reducida de la planeacin del proyecto: Las

estimaciones pobres impiden poder realizar planeaciones
efectivas, ya que introducen supuestos errneos para las
actividades especficas. Esto causa errores en el clculo del
tamao del equipo de trabajo, dificulta la coordinacin de los
diferentes roles dentro del proyecto y reduce la capacidad de
integrar el trabajo entre los diversos grupos al interior del
proyecto con un nivel de calidad garantizado.
Reduce las probabilidades de entregar el proyecto a tiempo:

Cada estimacin est asociada con una probabilidad de que
sta sea cierta. Una mala estimacin tiene muy bajas
probabilidades de que el proyecto sea finalizado en el tiempo
que se estipula.
10
Limita el tiempo para realizar fases crticas del ciclo de vida:

Una estimacin demasiado baja provoca que el tiempo que
se dedica en las primeras fases, como el anlisis de
requerimientos y el diseo, se vea reducido. Si este
escenario se produce, es muy factible que estas etapas sean
reprocesadas una y otra vez en subsecuentes etapas, a un
costo superior al que se hubiese incurrido inicialmente
hacindolas bien desde el principio. Teniendo esto como
consecuencia final, retrasos notables en la duracin del
proyecto.
Prcticas destructivas en las etapas finales del proyecto:

Una vez un proyecto entra en el estado de atrasado, es
usual que los equipos incurran en numerosas actividades que
no son necesarias en proyectos que cumplen con sus
cronogramas y que adems son poco deseables para los
miembros del grupo de trabajo:
o Frecuentes reuniones con la alta gerencia para discutir
cmo desatrasar el proyecto.
o Frecuentes reestimaciones tardas en el proyecto, slo
para saber cundo ser terminado definitivamente.
o Disculpas frecuentes ante los clientes por no cumplir
con las fechas comprometidas.
o Creacin de versiones no completamente funcionales
para demostrar algn tipo de progreso, pero bajo el
riesgo de evidenciar pblicamente problemas de
calidad.
11
o Discusiones frecuentes acerca de los requerimientos

que obligatoriamente deban ser adicionados, porque el
proyecto se ha demorado demasiado.
o Depuracin difcil de defectos introducidos por malas
prcticas de desarrollo en que se incurren por la
premura de las entregas.
2.3.3 Beneficios de Estimaciones Exactas
Una vez las organizaciones realizan estimaciones lo suficientemente

exactas, obtienen un conjunto de beneficios adicionales a la
exactitud en s:
Visibilidad mejorada en el estatus de los proyectos: Una de

las mejores formas de hacer seguimiento de un proyecto es
comparar el progreso real contra el progreso planeado. Si las
planeaciones son realistas es posible hacer un seguimiento
de acuerdo con los planes. Si las planeaciones se realizan
con base en malas estimaciones, los proyectos tpicamente
son ejecutados sin prestar mucha atencin a sus planes
originales y estos pronto pierden significancia para comparar
los progresos reales contra los planeados.
Mejor Calidad: De acuerdo con Glass en [26], el 40% de los

defectos en todos los proyectos de software son causados
por
el
estrs
en
los
desarrolladores,
causado
por
cronogramas apretados. Si se puede evitar imponer esta

presin a los desarrolladores a travs de una planeacin
12
basada con mejores estimaciones, la calidad de los

productos entregados se debe ver incrementada.
Mejor coordinacin con roles no relacionados con software:

Los proyectos de software por lo general deben ser
coordinados con otros roles como pruebas, documentacin
tcnica, campaas de mercadeo, capacitacin, entre otros. Si
el cronograma del proyecto no es confiable, ocasionar que
la planeacin de los recursos para estas otras actividades se
vea afectada, lo que incrementar la duracin y el costo
global de los proyectos.
Mejores presupuestos: Estimaciones ms exactas ayudan a

realizar mejores presupuestos. Las organizaciones que no
cuentan con buenas estimaciones no pueden predecir con
exactitud el costo de sus proyectos.
Informacin temprana acerca de los posibles riesgos:

Realizar estimaciones exactas presenta la oportunidad de
que se conozcan de antemano los riesgos en que se incurre
cuando las estimaciones no concuerdan con las metas del
negocio. Si un proyecto tiene como meta ejecutarse en 4
meses y de antemano se sabe por su buena estimacin que
solo es posible realizarlo en mnimo 6 meses, las
organizaciones tendrn el poder de tomar las decisiones
necesarias para llegar a que las metas del negocio y la
estimaciones proyectadas converjan en algn punto, o por lo
menos, se tenga contabilizado los riesgos en los que se
incurre.
13
2.3.4
Relacin entre la Estimacin y la Planeacin
Crear una estimacin precisa y analtica no garantiza que la estimacin

sea aceptada ni que el proyecto se planifique de una forma que apoye
el desarrollo eficiente.
Independiente de las tcnicas de estimacin que se utilicen para
predecir cunto va a durar un proyecto, en esfuerzo o en tiempo, la
planeacin de un proyecto es un factor que afecta enormemente la
ejecucin del mismo.
Planear es una actividad que involucra a la gerencia de proyectos,
donde son tomadas las decisiones corporativas, y la estimacin
realizada puede verse afectada, debido a que planear es un proceso
sesgado y orientado al alcance de objetivos. Muchas veces, los
objetivos del sistema son los que direccionan la estimacin de los
proyectos. La estimacin de proyectos de software debe ser un
proceso analtico y objetivo, libre del sesgo que introducen los
conceptos de planeacin.
2.3.5
Estimaciones de punto-nico (single-point)
Cuando se realizan las estimaciones, hay que tener presente que la

estimacin es una prediccin a futuro de lo que puede durar o costar
un proyecto. Las predicciones no suelen ser exactas, sin embargo
cuando se estima se es altamente optimista, dando la sensacin que la
estimacin realizada es exacta (0% de error de desviacin). Cuando se
presenta una estimacin exacta a los interesados en el proyecto, se les
14
vende la idea que el proyecto tiene un 100% de probabilidad de

terminar en el tiempo que se indica, y que tiene 0% de probabilidad de
no terminar en el tiempo indicado.
Es importante, cuando se da una estimacin de un proyecto,
determinar los rangos de probabilidad de falla o de error que tiene
asociada la estimacin, para no establecer supuestos que confundan
las expectativas de finalizacin del proyecto.
2.3.6
Qu es una buena estimacin?

Una buena estimacin es aquella que proporciona una vista lo
suficientemente clara de la realidad de un proyecto, la cual le permita a
sus lderes tomar buenas decisiones acerca de cmo planear y
controlar el proyecto para cumplir con sus metas [3]
Realizar estimaciones constantemente no asegura que se estn
realizando
buenas
estimaciones.
Para
lograr
realizar
buenas
estimaciones se debe contar con procesos organizacionales bien

definidos e institucionalizados, donde el objetivo de estos sea el de
minimizar las ambigedades e incertidumbres que se presentan ante la
realizacin de un proyecto de software a la medida.
La Figura 5 muestra como Boeing mejor notablemente el error de la
estimacin una vez comenz con la implantacin del modelo de
capacidad de madurez (CMM). Cada vez que aument de nivel en
CMM, disminuy su porcentaje de error de la estimacin de sus
proyectos.
15
Figura 5. Mejoras en la estimacin de proyectos en la Boeing Company.

La previsibilidad de los proyectos mejora dramticamente a niveles
superiores de CMM. Fuente: Benefits of CMM Based Software Process
Improvement
2.3.7
El cono de la incertidumbre
La Figura 6 presenta el cono de la incertidumbre, que representa el

nivel de incertidumbre que se presenta durante las fases de un
proyecto, y afecta directamente el nivel de confianza de la estimacin
efectuada. Para cada fase del desarrollo del producto, donde ste se
va refinando, la estimacin misma se va refinando tambin,
aumentando el nivel de confiabilidad.
16
Figura 6. Cono de la Incertidumbre Basado en tiempo de calendario.

Fuente: Software Estimation: Desmystifying the Black Art, Steve
McConnell.
A medida que transcurren las etapas de desarrollo, la apertura del
cono de la incertidumbre empieza a cerrarse, volvindose tan delgado
como una flecha, indicando que la incertidumbre va desapareciendo.
Esto tiene que ver con que cada vez que se realizan o se tienen ms
elementos tangibles (Definicin del producto, Diseo de interfaz
grfica, diseo detallado), la incertidumbre disminuye, pudiendo as
realizar una estimacin con ms exactitud.
2.3.8
Causales generales de error en las estimaciones
Los siguientes causales son los principales errores que se tienen en

los procesos de estimacin:
Proceso de desarrollo catico
Requerimientos Inestables
Actividades o caractersticas omitidas
17
Optimismo infundado: reduccin de las estimaciones de los

desarrolladores, frases clebres:
Seremos ms productivos en este proyecto comparado con
el proyecto anterior
Muchas cosas salieron mal en el anterior proyecto, en este
saldrn menos.
Empezamos el proyecto lentamente y fuimos escalando
nuestra curva de aprendizaje. Aprendimos de la forma dura,
pero todas las lecciones nos permitirn terminar el proyecto
ms rpido de lo que lo empezamos.
2.3.9
Subjetividad y Sesgo.
Estimaciones a vuelo de pjaro
Influencias en la Estimacin de un Proyecto de Software
2.3.9.1
Tamao
El tamao del software es uno de los principales clasificadores de

proyectos. Para medir el tamao de un proyecto de software existen
varios criterios, dentro de los cuales se encuentran:
Nmero de lneas de cdigo.
Nmero de pantallas.
Nmero de Interfaces con otros sistemas.
Nmero de casos de uso.
18
En la Figura 7 se ilustra el esfuerzo invertido en meses por el

nmero de lneas de cdigo que tiene un proyecto. Como se puede
observar, tiene una tasa de crecimiento lineal.
Figura 7. Crecimiento en esfuerzo de un proyecto tpico de un

sistema de negocio. Calculado usando datos del modelo de
estimacin Fuente: Computed using data from the Cocomo II
2.3.9.2
Deseconomas de escala
El nmero de integrantes de un proyecto es otro de los factores que

afectan la estimacin de un proyecto. Con el nmero de integrantes
de un proyecto ocurre un fenmeno contrario a lo que normalmente
se cree. Si se incrementa el nmero de participantes de un proyecto,
no necesariamente disminuir la fecha de finalizacin del proyecto.
Esto se debe bsicamente a las desconomas de escalas, las cuales
implican que a mayor nmero de participantes, los canales de
comunicacin aumentan en orden exponencial de estos, dando
19
como trabajo adicional un esfuerzo en la coordinacin de todos los

recursos. En la Figura 8 se puede ver grficamente el aumento del
nmero de canales a medida que los nodos aumentan.
Figura 8. Las lneas de comunicacin crecen proporcionalmente al

cuadrado del nmero de personas en el equipo. Fuente: The
Mythical Man-Month; Essays on software Engineering, Anniversary
Edition (2d Ed).
2.3.9.3
Tipos de Software
Todos los tipos de software llevan consideraciones diferentes para

su desarrollo, ya que las especificaciones entre cada uno vara y
afecta de una manera importante la duracin de un proyecto. Por
ejemplo, para los sistemas de aviacin, las pruebas son procesos
ms extensivos que implican que el tiempo dedicado a estos sea
mayor, comparado con otros tipos de software.
Tipos de Software
Lneas de Cdigo / Por Mes Hombre

Superior-Inferior (Nominal)
10,000-LOC 100,000-LOC 250,000-LOC
Project
Project
Project
20
Aviacin
1001,000
(200)
Sistemas
de 80018,000
Negocio
(3,000)
Comando y Control 2003,000
(500)
Sistemas
1002,000
Embebidos
(300)
Sistemas de Cara a 60010,000
Internet
(1,500)
20300
(50)
2007,000
(600)
50600
(100)
30500
(70)
1002,000
(300)
20200
(40)
1005,000
(500)
40500
(80)
20400
(60)
1001,500
(200)
Sistemas diseados 1,500

para intranets
18,000
(4,000)
Micro cdigo
100800
(200)
Control de procesos 5005,000
(1,000)
Tiempo Real
1001,500
(200)
Sistemas Cientficos 5007,500
/ Investigacin de (1,000)
Ingeniera
Productos
de 4005,000
Software Licenciado (1,000)
Sistemas
de 2005,000
Software / Drivers
(600)
Telecomunicaciones 2003,000
(600)
3007,000
(800)
2005,000
(600)
20200
(40)
1001,000
(300)
20300
(50)
1001,500
(300)
20100
(30)
80900
(200)
20300
(40)
801,000
(200)
1001,000
(200)
501,000
(100)
50600
(100)
70800
(200)
40800
(90)
40500
(90)
Tabla 3. Tipos de Software. Fuentes: Measures for Excellence

(Putnam and Meyers 1992), Industrial Strength Software (Putnam
and Meyers 1997), and Five Core Metrics (Putnam and Meyers
2003).
La Tabla 3 muestra el rango promedio de lneas de cdigo que se
requiere invertir por cada recurso por mes, para los diferentes tipos
de sistemas. Esta mtrica indica que dependiendo del tipo de
sistema a realizar, el nivel de complejidad vara y que es importante
tenerlo en cuenta como un parmetro, al momento de realizar una
estimacin.
21
2.3.9.4
Factores del Personal
Las habilidades del personal son otras de las principales influencias

que tiene la estimacin de los proyectos de software. Las
competencias encontradas en un equipo de trabajo pueden
disminuir o incrementar el esfuerzo requerido para realizar una tarea
dentro del ciclo de desarrollo de un proyecto de software. La Figura
9 presenta el resumen de los porcentajes de influencia que tienen
los factores de personal, cuantificados por el modelo COCOMO II.
Por ejemplo, si el analista de requisitos recibe la peor calificacin
posible, la estimacin debe ser ajustada en un 42%, de acuerdo con
este modelo.
Figura 9. Efectos de factores personales en el esfuerzo de los

proyectos. Dependiendo de la fortaleza o debilidad de cada factor, el
proyecto puede variar la cantidad indicada. Fuente: Peopleware:
Productive Projects and Teams.
ii
http://www.ldc.usb.ve/~teruel/ci4713/clases2001/cocomo2.html
22
2.3.9.5
Lenguaje de programacin
El conocimiento de un equipo de desarrollo acerca de los lenguajes

y de las herramientas sobre las cuales se pueden trabajar, es un
factor a tener en cuenta en la estimacin de un proyecto si el equipo
de trabajo no cuenta con la suficiente experiencia, dado que afecta
el tiempo esperado en construccin.
Tambin es necesario revisar, dependiendo del tipo de sistema, las
bondades que ofrece el lenguaje seleccionado, ya que los diferentes
lenguajes de programacin son enfocados a la productividad,
logrando un objetivo (funcionalidad especfica) con un menor
nmero de lneas de cdigo.
En el entorno de hoy da, es importante resaltar el impacto que
tienes los IDE (Integrated Development Enviroment) en la variacin
de la productividad de construccin. Hoy da se encuentran IDEs
que facilitan operaciones tales como, deteccin de errores,
seguimientos a variables dentro del cdigo, generacin y despliegue
del producto, comunicacin con otros sistemas, control detallado de
las operaciones realizadas, entre otras, afectando positivamente la
productividad misma.
A medida que las tecnologas han evolucionado, los lenguajes de
programacin tambin lo han hecho y se ha vuelto para los
desarrolladores, mas fcil programar en ellos. En la Tabla 4 se
puede observar la comparacin de diferentes lenguajes contra el
lenguaje C. En esta tabla podemos observar que mientras en C se
23
realiza una instruccin, en C# podramos realizar 2.5 instrucciones,

esto es un aumento del 250% de productividad final (en
instrucciones). Tambin podemos ver que en Visual Basic se puede
construir 4.5 veces ms rpido (sentencias) que en el lenguaje C.
Esto da pie a considerar que el lenguaje de programacin es un
factor importante a tener en cuenta en la estimacin de proyectos de
software; sin embargo, existen inconveniente sobre el uso de este
factor, ya que no todos los desarrolladores logran obtener el mejor
provecho sobre los lenguajes de programacin.
Lenguaje
C
C#
C++
Cobol
Fortran 95
Java
Macro Assembly
Perl
Smalltalk
SQL
Visual Basic
Nivel Relativo al Lenguaje iiiC

1 to 1
1 to 2.5
1 to 2.5
1 to 1.5
1 to 2
1 to 2.5
2 to 1
1 to 6
1 to 6
1 to 10
1 to 4.5
Tabla 4. Funcionalidad por sentencia alcanzable con el lenguaje

respecto al lenguaje C. Adaptada de: Estimating Software Cost y
Software Cost Estimation with Cocomo II
2.3.10 Bases de las tcnicas de estimacin
2.3.10.1
Contar, calcular y en ltima instancia, juzgar
Las diferentes tcnicas de estimaciones ofrecen las herramientas

necesarias para que se realicen los conteos y clculos necesarios.
iii
Lenguaje de programacin creado en 1969 por Ken Thompson y Dennis M. Ritchie
24
Sin embargo, no siempre se puede realizar un conteo o un clculo

que permita estimar el esfuerzo necesario para realizar un proyecto;
siempre existir la opcin de juzgar.
Juzgar es una percepcin humana de lo que se considera va a
tomar realizar el proyecto en esfuerzo, pero este juicio es parcial y
sesgado, ya que es realizado por un proceso cognoscitivo no
estructurado que tiende altamente al error, por eso se debe evitar en
lo posible juzgar.
2.3.10.2
Calibracin y Datos Histricos
La informacin histrica expresada en indicadores relacionados con

la industria de desarrollo de software constituye el insumo
fundamental de la mayora de las tcnicas de estimacin. Por lo
tanto, en la mayora de las tcnicas, la calibracin es usada para
convertir lo conteos realizados en estimados. Existen tres tipos de
datos con los cuales se puede calibrar una estimacin:
Datos
de
Industria:
datos
de
organizaciones
que
desarrollan el mismo tipo de software que est siendo

estimado.
Datos Histricos: Informacin recolectada dentro de la

organizacin que desarrollar el proyecto.
Datos
del
Proyecto:
Indicadores
de
desempeo
recolectados en las primeras etapas del proyecto y que

deben ser usados para calibrar las siguientes fases.
2.3.10.3
Mtricas de Software
25
Los siguientes indicadores proporcionan suficientes datos para

calibrar la mayora de herramientas comerciales de estimacin,
tambin permiten calcular tasas de productividad sencillas como
nmero de lneas de cdigo por mes-hombre:
Tamao (lneas de cdigo, Puntos de Funcin o algo que sea

contable, una vez finalizado el proyecto)
Esfuerzo (dado en meses/persona de personal o la cifra ms

cmoda de contabilizar)
2.4
Tiempo (meses calendario)
Defectos (clasificados por severidad)
Tcnicas Fundamentales
2.4.1
Clasificacin de las tcnicas de estimacin
2.4.1.1
Basadas en Modelos
Son tcnicas que poseen un modelo matemtico como su punto

clave. Involucran un algoritmo que es derivado la mayora de las
veces del estudio de datos puntuales sobre proyectos conocidos.
2.4.1.2
Basadas en Expertos
Se basan en las opiniones de personas que tienen experiencia en

las tcnicas de desarrollo de software a ser utilizadas y en el
dominio de la aplicacin.
26
2.4.1.3
Orientadas al aprendizaje
Los mtodos de estimacin de esta categora van desde las

estimaciones que se realizan manualmente por analoga con
proyectos, hasta las que usan tcnicas de inteligencia artificial como
las redes neuronales.
La Tabla 5 presenta ejemplos de tcnicas de estimacin clasificadas
en estas categoras
Clasificacin
Tcnicas
Basadas en Modelos
SLIM
COCOMO 81
Checkpoint
SEER
Basadas en Expertos
Delphi
Rule-Based
Neural
Orientadas al aprendizaje Case-based (Estimacin por
analoga)
Compuestas
Composite Bayesian
COCOMO II
Tabla 5. Ejemplos de tcnicas de estimacin clasificadas en estas

categoras. K. Kavoussanakis, Terry Sloan, "UKHEC Report on
Software Estimation" University of Edinburgh - UK High-End
Computing Publications, December 2001
2.4.2
Juicio de Expertos
Las tcnicas basadas en la experiencia son tiles cuando no se

poseen datos cuantificados. stas capturan el conocimiento y la
27
experiencia de las personas con amplio dominio de un rea de inters,

las cuales proveen estimaciones basadas en la sntesis de los eventos
conocidos en proyectos anteriores, con los cuales el experto ha estado
asociado o ha participado directamente. La desventaja obvia de estos
mtodos es que la estimacin slo es tan buena como lo sea la opinin
del experto, y usualmente no hay forma de probar dicha opinin hasta
que es demasiado tarde para corregir el dao si la opinin fue errada.
Los aos de experiencia no necesariamente se convierten en altos
niveles de competencia en estimacin. Incluso, el ms competente de
los individuos puede simplemente suponer de forma errnea. Algunas
tcnicas han sido desarrolladas para capturar el juicio de expertos,
pero tambin toman medidas para mitigar la posibilidad que el juicio de
un solo experto afecte el resultado. Estas tcnicas se conocen como:
2.4.3
Juicio Experto Individual
La Tcnica Delphi
WSB.
Juicio Experto Estructurado
El juicio de expertos individual no tiene por qu ser informal o intuitivo,

puede utilizarse procedimientos definidos para que los expertos se
basen en ellos y tener mayor control de lo estimado.
La tcnica de juicio de expertos estructurado es similar a la tcnica
juicios de expertos, solo que en este se define los pasos para realizar
la estimacin, para que los expertos los sigan y se obtengan resultados
ms controlados.
28
Para crear las estimaciones a nivel de cada tarea, se debe pedir a las
personas que las ejecutan que hagan la estimacin de cada una.
Uso de Rangos:
El uso de rangos para la estimacin de cada tarea permite que el
estimador se ponga en tres situaciones:
Probable:
cuando
todo
el
ambiente
se
desenvuelve
normalmente. Esta situacin es la que por defecto usan los

estimadores.
Optimista: Cuando todo sale mejor de lo esperado y dan para

que los tiempos de ejecucin de la tarea disminuyan. Estas
circunstancias suelen suceder poco y los estimadores estn
predispuestos a dar tiempos en estos escenarios, sin embargo
para el modelo de PERT se hace necesario ponerse en esta
situacin optimista.
Pesimista: Cuando todo sale mal y se generan problemas para

la ejecucin de la tarea. Una de las circunstancias para que
suceda esto es que los riesgos planteados para el proyecto se
materialicen. El estimador debe considerar que uno o varios
riesgos se materialicen para este escenario.
La Tabla 6 muestra una estimacin por rangos, teniendo en cuenta

las situaciones de optimista, probable y pesimista. Tambin se
ilustra dos esfuerzos
Esperado 1: Este esfuerzo es calculado con la Ecuacin 1

original de PERT.
Esperados 2: Este esfuerzo es calculado con la Ecuacin 1

de PERT, ajustada para estimacin de tareas de desarrollo
de software.
29
Tareas
Tarea 1
Tarea 2
Tarea 3
Tarea 4
Tarea 5
TOTAL
Optimista
0,5
1
3
1
3
8,5
Probable
1
1,5
4
1,5
4
12
Pesimista
1,5
2
5
2,5
5
16
Esfuerzo
Esperado1
1
1,5
4
1,58333333
4
12,0833333
Esfuerzo
Esperado2
1,083333333
1,583333333
4,166666667
1,75
4,166666667
12,75
Tabla 6. Esfuerzo por rangos. Adaptado de: Software Estimation: Desmystifying the
black art, Steve McConnell
Como se observa, el Esfuerzo Esperado 1 no difiere mucho del
Esfuerzo Probable; sin embargo s existe una diferencia notoria con el
Esfuerzo Esperado 2 (PERT AJUSTADO).
Frmula PERT ivoriginal:
[MejorCaso + (Caso Pr evisto 4) + PeorCaso]

6
Ecuacin 1. PERT Original. Fuente: Project Manager's PERT/CPM
Handbook
Frmula PERT ajustada:
MejorCaso + (Caso Pr evisto 3) + ( PeorCaso 2)
6
Ecuacin 2. PERT Ajustada. Fuente: Estimating Software- Intensive
Systems
2.4.4
iv
Lista de chequeo
Program Evaluating and Review Technique
30
Incluso los expertos en estimacin ocasionalmente olvidan considerar

elementos que deberan incluir en una estimacin. As como se
realizan verificaciones de cdigo antes de ser liberado, es necesario
realizar verificaciones a las estimaciones; esto puede realizarse
siguiendo una lista de chequeo. A continuacin se presenta un
ejemplo:
Lo que est siendo estimado est claramente definido?
La estimacin incluye todos los tipos de trabajo necesarios

para completar la tarea?
La estimacin incluye todas las reas funcionales necesarias

para completar la tarea?
La estimacin est descompuesta en un nivel de suficiente

detalle, de tal modo que exponga tareas escondidas? trabajo
escondido?
Se tomaron en cuenta hechos documentados de proyectos

anteriores en vez de estimar con base en recuerdos?
La estimacin fue aprobada por la persona que REALMENTE

har el trabajo?
Se asume en la estimacin que la productividad ser similar a

la alcanzada en asignaciones similares?
La
estimacin
incluye
casos
optimistas,
pesimistas
probables?
Es (o son) el caso optimista, realmente el peor de los casos?

Necesita plantearse alguno an peor?
El esfuerzo esperado fue calculado apropiadamente a partir de

los casos propuestos?
Los supuestos en los que se bas la estimacin fueron

documentados?
31
Ha cambiado la situacin desde que la estimacin fue

preparada?
2.4.5
Comparar los estimados con los resultados
Aplicar las tcnicas para evitar las estimaciones de punto nico en los
juicios expertos realmente no es suficiente. Una vez obtenidos los
esfuerzos reales tras la ejecucin de las tareas estimadas se debe
realizar un anlisis que permita comparar cuantitativamente los
resultados reales con los estimados para as tener un parmetro que
permita medir la exactitud de los expertos y calibrar las estimaciones
para futuros proyectos. Para esto se debe calcular la magnitud del
error relativo (MRE) usando la Ecuacin 3 para cada tarea.
Ecuacin 3. Magnitud del Error Relativo (MRE). Fuente: Estimation: Desmystifying

the black art, Steve McConnell
La Tabla 7 presenta el anlisis del clculo de la MRE para el
ejemplo presentado en la tabla 6 luego de haberse ejecutado las
tareas estimadas.
Dentro
Resultado MRE del
Rango?
Tareas
Optimista Probable Pesimista
Esfuerzo
Esperado
Tarea 1
Tarea 2
Tarea 3
0,5
1
3
1,08333 (1) 1
1,583 (1.6) 2
4,167 (4.2) 4.5
1
1,5
4
1,5
2
5
0%
Si
20% Si
6.6% Si
32
Tarea 4
Tarea 5
TOTAL
1
3
8,5
1,5
4
12
2,5
5
16
1,75 (2)
2
4,167 (4.5) 6
12,08(13.3) 13.5
Promedio
0%
Si
25% No
80% Si
10.3
%
Tabla 7. Esfuerzo por rangos con magnitud del error relativo. Adaptado de Software
Estimation: Desmystifying the black art, Steve McConnell
2.4.6 Descomposicin y Recomposicin WBS (Work Breakdown Structure)
El WBS ha sido un estndar por mucho tiempo en la prctica de

ingeniera para el desarrollo tanto de hardware como software y en
general de cualquier prctica de ingeniera y se trata de la clsica
estrategia de Divide y vencers. El WBS es una forma de organizar
los elementos de un proyecto en una jerarqua que simplifica las tareas
de estimacin y el control sobre el proyecto. Ayuda a determinar
exactamente qu costos estn siendo estimados. An ms, si hay
probabilidades asociadas a los costos relacionados con cada elemento
individual de la jerarqua, puede determinarse un valor esperado total
del costo del proyecto desde la visin general [8]. La labor de los
expertos entra en juego en este mtodo en la determinacin de las
especificaciones de componentes ms tiles dentro de la estructura y
las probabilidades asociadas a cada componente.
Los mtodos basados en juicios de expertos son buenos para
proyectos que no tienen precedentes dentro de la empresa, pero se
presentan problemas de calibracin entre los juicios y problemas de
escalabilidad para anlisis extensivos. Por otro lado, las tcnicas
basadas en WBS son buenas para la planeacin y control de
proyectos.
33
El WSB de un proyecto de software consiste en dos jerarquas, una

que representa el producto de software como tal, y otra que representa
las actividades necesarias para construir el proyecto [7]. La jerarqua
del producto describe la estructura fundamental del software,
mostrando cmo encajan los diversos componentes en el sistema
general. La jerarqua de actividades indica las actividades que pueden
estar asociadas con un componente de software dado.
Adems de ayudar a la estimacin, otro de los usos que se le da a la
tcnica WBS es la contabilidad de costos. Cada elemento del WBS
puede ser asignado con su propio presupuesto y nmero de control de
costos, permitiendo al personal reportar la cantidad de tiempo que han
invertido trabajando en una tarea o componente del proyecto; la
informacin puede ser resumida para propsitos de control del
presupuesto.
Finalmente, si una organizacin usa consistentemente un WBS para
todos sus proyectos, con el transcurso del tiempo se construir una
valiosa base de datos que refleja los costos de su produccin de
software. Estos datos pueden ser usados para desarrollar un modelo
de estimacin de software ajustado a la propia experiencia y prcticas
de la organizacin.
2.4.6.1
Ventajas
Aplicable a proyectos de dominio muy especfico
Inherente a la calibracin local
Puede conllevar a procesos bien documentados.
34
2.4.6.2
Desventajas
Los estimadores tienden a dar la estimacin de el mejor de

los casos
Tendencia a estimaciones Single-point
Alta dependencia de las habilidades de los expertos
Alta dependencia a la presencia de los expertos.
Debido a la Ley de los Grandes nmeros, la cual dice que la frecuencia

relativa de un proceso se aproxima cada vez ms a la probabilidad
terica a medida que aumentan el nmero de experiencias que se
realizan, indica que a mayor historial de informacin sobre la
estimacin de proyectos realizados con un WBS planteado, la
generacin de la prxima estimacin basada en estos datos estar
ms cercana a la verdad que la anterior.
La Tabla 8 presenta una lista de tareas genrica que se puede utilizar
para definir la WBS de un proyecto. La columna de la izquierda lista las
categoras de actividades y las otras columnas listan el tipo de trabajo
realizado en cada categora. Para utilizarla se combinan los tipos de
trabajo con cada categora y as obtener tareas tales como
Crear/Hacer
Planeacin,
Administrar
Procesos,
Planear
preparacin del personal. Guas como la Tabla 8, son valiosas para la

metodologa WBS, ya que la exactitud de una estimacin a realizar
depende de lo detallado que est la jerarqua de tareas.
WBS genrica para proyectos de software de tamao pequeos a
medianos
Categora
Administracin
Crear
/
Hacer
Planear
Administrar
Revisar
Reprocesar
Reporte
de
Defectos
35
General
Planeacin
Actividades
Corporativas
Configuracin
del HardWare
/Configuracin
del Software/
Mantenimiento
Preparacin
del personal
Procesos
Tcnicos/
Practicas
Trabajo en
requerimientos
Coordinacin
con otros
proyectos
Cambio de
Administracin
Prototipo de
interfaces de
usuarios
Trabajo de
Arquitectura
Diseo
detallado
Codificacin
Adquisicin de
Componentes
Generacin
Automtica
Integracin
Sistema de
Pruebas
Manuales
Sistema de
pruebas
automticas
Liberacin del
Software
(interim, alpha,
beta, and final
releases)
Documentos
(usuarios,
documentos,
Tcnicas)
Tabla 8. Cuadro de actividades que componen un WBS. Fuente:

Discipline for software Engineering
36
2.4.6.3
Cmo hacer una estimacin WBS ms precisa?
Una de las principales tendencias en la elaboracin de estimaciones

usando una WBS es la creacin de estimaciones de punto nico
(single-point), y por lo tanto la introduccin de los problemas de
exactitud asociados a stas.
Al igual que en el juicio experto estructurado, cada tarea de una
WBS debe ser estimada emitiendo el estimado del peor, ms
probable y peor de los casos. Una vez planteados estos rangos, se
debe aplicar las ecuaciones Ecuacin 1 y Ecuacin 2 y totalizar los
esfuerzos esperados para cada frmula y elegir alguno de los
totales bajo criterio de los expertos que realizaron la estimacin.
2.4.7
Estimacin por Analoga
Esta tcnica es generalmente aplicable cuando otros proyectos en el

mismo dominio de aplicacin han sido completados. El costo del nuevo
proyecto es estimado por analoga con estos proyectos. McConnell[3],
afirma que los estimados basados en datos histricos recolectados
dentro de la misma organizacin tienden a ser ms precisos que los
estimados basados en reglas empricas o suposiciones estructuradas.
Sin embargo, no todas las organizaciones tienen suficientes datos
histricos para utilizar satisfactoriamente las tcnicas de analogas
como forma de estimacin.
Para poder obtener una estimacin ms exacta utilizando la tcnica de
estimacin por analoga, es necesario contar con algn tipo de
estructura que de mayor garanta sobre el proceso de estimacin. A
37
continuacin se enumeran los pasos sugeridos para utilizar este

mtodo:
Obtenga datos detallados del tamao, esfuerzo y costos

resultantes de proyectos previos. Si es posible, obtenga la
informacin descompuesta por caractersticas, por categora del
WBS o por algn otro esquema de descomposicin.
Compare el tamao del nuevo proyecto, pieza por pieza, con el

anterior proyecto.
Construya el estimativo del nuevo proyecto con base en un

porcentaje del tamao del anterior.
Cree un estimado del esfuerzo comparado con el esfuerzo

invertido en el anterior proyecto.
Verifique que los supuestos entre el proyecto viejo y nuevo sean

consistentes.
2.4.7.1
2.4.7.2
Ventajas
Simple y exacta si la organizacin repite trabajo similar.
Las estimaciones estn disponibles inmediatamente.
Promueve la documentacin detallada
Desventajas
Puede resultar poco confiable si no se cuenta con

experiencia documentada.
38
Es bastante difcil establecer las diferencias entre proyectos

debido a la agrupacin de los datos histricos y as
establecer la precisin de la estimacin.
2.4.8
Estimaciones Basadas en Referencias
Para la mayora de estimadores resulta complejo determinar el tamao

de una caracterstica en un proyecto de software. Un conjunto de
tcnicas conocidas como basadas en referencias ayudan a
determinar el tamao tomando puntos de referencia.
En una estimacin basada en referencias primero se identifica una
referencia que se relacione con lo que realmente se desea estimar y
que es ms fcil de estimar o contar (o que est disponible de un
anterior proyecto). Una vez se haya definido la referencia a utilizar, se
estima o se cuenta el nmero de los tems de la referencia y despus
se realiza un clculo basado en datos histricos para convertir el
conteo de la referencia a la estimacin que realmente se desea.
2.4.8.1
Componentes Estndar
Si se desarrollan programas que son de similar arquitectura, puede

usarse esta tcnica para estimar el tamao. Primero deben definirse
los elementos relevantes en los sistemas previos. Tpicamente un
sistema puede incluir pginas Web, archivos, tablas, reglas de
negocio, grficos, pantallas, dilogos, reporte, etc. Luego de tener
identificados cules son los componentes estndar, se calcula el
promedio de lneas de cdigo por componente en los proyectos
anteriores. Con base en esto, se puede realizar el clculo para un
39
nuevo proyecto. El uso de lneas de cdigo en estos casos resulta

mejor que cualquier otra mtrica, ya que resulta mucho ms fcil
recolectarla para cada tipo de componente en proyectos que ya han
sido finalizados.
2.4.8.2
Lgica Difusa
Consiste en clasificar las caractersticas requeridas para un proyecto

de software en cinco tamaos: Muy pequea, pequea, mediana,
grande y muy grande. Se realiza el conteo de caractersticas por
cada categora y luego se calcula el esfuerzo con base en datos
histricos. La Tabla 9 muestra un ejemplo de estimacin del tamao
de un proyecto usando lgica difusa:
Tamao
Muy
pequea
Pequea
Mediana
Grande
Muy Grande
TOTAL
Promedio LOC Nmero

de LOC
por Categora
Caractersticas estimadas
127
22
2,794
253
500
1,014
1,998
-
15
10
30
27
104
3,795
5,000
30,420
53,946
95,955
Tabla 9. Estimacin de tamao usando lgica difusa. %. Fuente

2.4.8.3
Tallaje de Camisetas
Esta tcnica es similar a la lgica difusa. Se asignan tallas (XS, S,

M, L, XL) a las diferentes caractersticas de un proyecto y se
relacionan stas con datos histricos para estimar el tamao en
lneas de cdigo. Esta tcnica resulta til para ilustrar a los actores
40
no tcnicos de un proyecto sobre la complejidad de cada

caracterstica y posiblemente darle tambin una valoracin, usando
la misma escala del valor agregado que da cada caracterstica. De
este modo los actores del negocio pueden decidir si vale la pena el
esfuerzo que se invertira en cada aspecto del proyecto.
2.4.9
Juicio Experto Grupal
2.4.9.1
Revisiones Grupales
Las revisiones grupales son una buena forma de obtener mayores

niveles de exactitud en la estimacin si estas se realizan de manera
estructurada. Para obtener resultados adecuados en una estimacin
por revisiones grupales, se deben seguir las siguientes reglas:
Haga que cada miembro del equipo estime las piezas del
proyecto individualmente, luego renalos para comparar las
diferencias. Trabajar hasta que se alcance un consenso en
los rangos de estimacin
No se debe hacer promedios de los estimados.
Llegar a un consenso que todo el grupo acepte.
La Figura 10 muestra la diferencia de efectividad de las revisiones

grupales respecto de las estimaciones individuales de 24 proyectos
estimados con las dos tcnicas.
41
Figura 10. MRE(Individuales) = 55% MRE(Grupales) = 30%. Fuente

2.4.9.2
Wideband Delphi
La tcnica Delphi fue elaborada en la Rand Corporation a finales de

los aos 40, originalmente como una forma de realizar predicciones
acerca de futuros eventos. Ms recientemente, la tcnica ha sido
usada como una forma de guiar a un grupo de individuos hacia un
consenso de opinin sobre un problema. Se solicita a los
participantes que hagan una afirmacin respecto a un problema, de
forma individual en la primera ronda, sin consultar a los otros
participantes del ejercicio. Los resultados de la primera ronda son
recolectados y tabulados, y luego retornados a cada participante
para una segunda ronda, durante la cual los participantes se les
solicita de nuevo hacer su afirmacin sobre el problema, pero en
esta ocasin conociendo lo que hicieron los otros participantes en la
42
primera ronda. La segunda ronda usualmente resulta en un

estrechamiento
del
rango
en
las
afirmaciones
del
grupo,
acercndose a un punto medio respecto al problema en cuestin. La

tcnica original evitaba la discusin grupal; la tcnica Wideband
Delphi [7] incluye la discusin grupal entre las rondas. Esta es una
tcnica til para llegar a alguna conclusin cuando la nica
informacin disponible est basada ms en la opinin de expertos
que en datos histricos.
El procedimiento del mtodo Delphi se describe a continuacin:
1. El coordinador de Delphi presenta a cada estimador un
formato de la estimacin.
2. Los
estimadores
preparan
estimaciones
iniciales
individualmente. (Opcionalmente, este paso se puede realizar

despus del paso 3.)
3. El coordinador convoca una reunin de grupo en la cual los
estimadores discuten las valoraciones realizadas.
4. Si el grupo conviene en una sola estimacin sin mucha
discusin, el coordinador asigna a alguien como abogado del
diablo.
5. Los estimadores dan sus estimaciones individuales al
coordinador, de forma annima.
6. El coordinador prepara un resumen de las estimaciones una
forma de iteracin y presenta el resultado de la iteracin a los
estimadores,
de
modo
que
puedan
ver
cmo
sus
estimaciones se comparan con las estimaciones de otros.

7. El coordinador realiza una reunin con los estimadores para
discutir variaciones en sus estimaciones.
8. Los estimadores votan annimamente si desean aceptar la
estimacin media. Si alguno de ellos vota no, vuelven al
paso 3.
43
La efectividad de la tcnica Delphi se puede apreciar en la Figura 11
Figura 11. Tiene un mejor MRE en 8 de cada 10 casos. Fuente:

Ventajas
Efectiva para sistemas poco familiares a la organizacin.
til cuando deben involucrarse personas de diversas

disciplinas en el proyecto.
Desventajas
Requiere de varias reuniones haciendo costoso el proceso de

estimacin.
No es apropiada para estimar tareas detalladas.
2.4.10 Modelos de Estimacin COCOMO
44
2.4.10.1
COCOMO 81 [1]
Barry Boehm, en [7], introduce una jerarqua de modelos de

estimacin de software con el nombre de COCOMO (Constructive
Cost Model - COCOMO) Modelo Constructivo de Costeo. La
jerarqua de modelos de Boehm est constituida por las siguientes
categoras:
Modelo Bsico: Se calcula el esfuerzo del desarrollo de

software en funcin del tamao del programa, expresado en
las lneas estimadas de cdigo (SLOC).
Modelo Intermedio: Se calcula el esfuerzo en funcin del

tamao del programa y de un conjunto de "conductores de
coste" que incluyen la evaluacin subjetiva del producto, del
hardware, del personal y de los atributos del proyecto.
Modelo Avanzado: Incorpora todas las caractersticas de la

versin intermedia y lleva a cabo una evaluacin del impacto
de los conductores de coste en cada fase (anlisis, diseo,
etc.) del proceso de Ingeniera de Software.
Los modelos COCOMO estn definidos para tres tipos de proyectos

de software:
Orgnicos: Proyectos que son relativamente pequeos y

sencillos en los que trabajan equipos con pocas personas,
con buena experiencia, sobre un conjunto de requisitos poco
rgidos.
45
Semiacoplados: Proyectos de software intermedios en

tamao y complejidad, en los que equipos con variados
niveles de experiencia, deben satisfacer requisitos poco o
medianamente rgidos.
Empotrados: Son proyectos que deben ser desarrollados en

un conjunto de hardware, software y restricciones operativas
muy restringidos.
Las ecuaciones COCOMO bsico tienen la siguiente forma:

E = ai * KLOCbi
D = ci * Edi
Donde E es el esfuerzo aplicado, en meses hombre, D es el tiempo
de desarrollo en meses cronolgicos y KLDC es el nmero estimado
de lneas de cdigo (en miles) para el proyecto. Los coeficientes ai y
ci y los exponentes bi y di se muestran en la Tabla 10
Proyecto
software
de ai
Bi
ci
di
Orgnico
2,4 1,05
2,5 0,38
Semiacoplado
3,0 1,12
2,5 0,35
Empotrado
3,6 1,2
2,5 0,32
46
Tabla 10. Coeficientes para clculo de esfuerzo y duracin del

modelo COCOMO. Fuente: Cost Models For Future Software life
Cycle Processes: COCOMO 2.0
El modelo se ampla para considerar un conjunto de "atributos,
conductores de coste" que pueden agruparse en cuatro categoras
principales: atributos del producto, atributos del hardware, atributos
del personal y atributos del proyecto. Cada uno de los 15 atributos
definidos para el modelo es valorado en una escala de 6 puntos que
va desde "muy bajo" hasta "extra alto" (en importancia o valor). De
acuerdo con la evaluacin, se determina un multiplicador de
esfuerzo a partir de las tablas publicadas en [7] y, con el producto de
todos los multiplicadores de esfuerzo, se obtiene un factor de ajuste
del esfuerzo (FAE). Los valores tpicos para el FAE varan de 0,9 a
1,4.
La ecuacin entonces del modelo COCOMO toma la forma:
bi
E
a
=
KDLC
iFAE
Donde E es el esfuerzo aplicado en meses-hombre y LDC es el

nmero estimado de lneas de cdigo. Los valores para el
coeficiente ai y el exponente bi se muestran en la Tabla 11.
Proyecto de
Software
Orgnico
3,2 1,05
Semiacoplado
3,0 1,12
Empotrado
2,8 1,2
ai
bi
Tabla 11. Coeficientes de la frmula de ajuste para el modelo

COCOMO 81. Cost Models For Future Software life Cycle
Processes: COCOMO 2.0
47
2.4.10.2
COCOMO II [4]
El principal problema con el modelo COCOMO 81 es que las

tcnicas modernas de Ingeniera de Software volvieron obsoletas la
terminologa usada por ste y, ms importante an, sus conceptos
fundamentales. Por ejemplo, el uso de modelos de desarrollo
iterativo hace que la definicin del inicio y del final de un proyecto
sea difusa, y los algoritmos simples basados en cascada del modelo
COCOMO 81 no pueden ser tenidos en cuenta en estos escenarios.
La clasificacin de proyectos como Orgnicos, Empotrados y
Semiacoplados
ha
sido
reemplazada
con
parmetros:
Precedencia, Flexibilidad del Desarrollo, arquitectura o Riesgo de

Resolucin, Cohesin del Equipo y Madurez del Proceso tomando
as en cuenta factores ms relevantes, los proyectos modernos,
permitiendo una afinacin ms detallada de los exponentes y los
coeficientes de las frmulas.
El modelo COCOMO II[15] emplea una jerarqua de modelos en la
siguiente forma: Composicin de Aplicacin, Diseo Temprano y
Pos-Arquitectura, en lugar de los modelos bsicos, intermedios y
avanzados, diferenciando as las diferentes etapas del proyecto en
las cuales cada uno de los modelos sera ms adecuado. El modelo
Composicin de Aplicacin tambin permite que tcnicas actuales
como la del uso de prototipos de interfaz (GUI) sean tenidas en
cuenta.
Este mtodo representa un avance frente a su predecesor respecto
al tema de la medicin del tamao de los proyectos. El nmero de
lneas de cdigo no es til cuando se utilizan lenguajes de
48
programacin visuales y el clculo por puntos de funcin resulta

muy engorroso. El modelo COCOMO II opta por el uso de Puntos
Objetuales (PO) [16]. Los PO son el conteo de pantallas, reportes y
mdulos desarrollados en un lenguaje de tercera generacin que
hacen parte de la aplicacin, al que cada uno se le asigna uno de
tres factores de complejidad (simple, medio, difcil). Para el propsito
de COCOMO II esta mtrica fue renombrada como "Puntos de
Aplicacin".
Ventajas de los modelos COCOMO:
Altamente soportados por la industria.
Recopilan y estn calibrados con informacin histrica de

varios aos atrs.
Existe una amplia gama de herramientas de apoyo.
Desventajas de los modelos COCOMO:
Resultan muy engorrosos de utilizar en empresas de

desarrollo que no tienen personal asignado exclusivamente a
las labores de estimacin.
Son difciles de calibrar con datos de la organizacin.
Exige muchos datos de ajuste donde se introducen valores

de calificacin subjetiva que pueden sesgar la estimacin si
son ingresados por un estimador inexperto.
2.4.11 Modelo de Estimacin de Putnam
El modelo de Putnam al igual que los modelos COCOMO, es un

modelo emprico de estimacin de esfuerzo en proyectos software. Lo
49
cual quiere decir que trabaja con datos recolectados de proyectos (por
ejemplo, esfuerzo y tamao) y ajustndolos a una curva estadstica.
Las estimaciones futuras de esfuerzo son hechas proporcionando el
tamao y calculando el esfuerzo asociado usando la ecuacin
calibrada con los datos del modelo.
Creado por Lawrence Putnam, el describe el tiempo y el esfuerzo
requeridos para acabar un proyecto del software de un tamao
especificado. Comercialmente es conocido como SLIM (Software
LIfecycle Management) el cual es el nombre dado por Putnam al
conjunto propietario de herramientas producidas por su compaa
QSM, Inc.
Mientras gerenciaba proyectos de investigacin y desarrollo para el
ejrcito de Estados Unidos y luego para General Electrics, Putnam
not que los perfiles de asignacin de recursos para proyectos de
software seguan la distribucin Rayleigh. Putnam us estas
observaciones acerca de los niveles de productividad para derivar la
siguiente ecuacin:
Ecuacin 4. Ecuacin de Software Modelo de Putnam. Fuente

http://en.wikipedia.org/wiki/Putnam_model
Donde:
50
Tamao: Es el tamao del producto. Putnam usa lneas de cdigo para

la medicin del tamao, sin embargo se puede usar la mtrica ms
adecuada para medirlo en la organizacin.
El trmino , es un escalar y est en funcin del tamao
Productividad: es la productividad del proceso en una organizacin de
desarrollo en particular a una tasa de defectos generados especfica.
Esfuerzo es el total de esfuerzo aplicado al proyecto, en aos/hombre.
Tiempo es el calendario total de implementacin, dado en aos.
En trminos prcticos, para estimar una tarea de software la ecuacin
se resuelve de la siguiente forma:
Ecuacin 5. Ecuacin del Esfuerzo Modelo Putman.

http://en.wikipedia.org/wiki/Putnam_model
Este mtodo de estimacin es bastante sensible y ajustable a la
incertidumbre relacionada con el tamao y la productividad del
proceso. Su creador recomienda que la productividad sea siempre
calibrada a la realidad de la organizacin y el proyecto. Por esto, una
de las principales ventajas del modelo Putnam es su simplicidad para
ser calibrado.
2.4.11.1
Ventajas
Es uno de los mtodos que mayor exactitud presenta frente al resto.

Es uno de los pocos modelos de estimacin que tiene presente la
incertidumbre dentro de sus clculos.
51
2.4.11.2
Desventajas
Es un modelo comercial y existe poca documentacin disponible

para utilizarlo de forma manual.
2.4.12 Herramientas de Software de Estimacin
El uso de herramientas de software de estimacin resulta conveniente,
ya que introduce el concepto de la ciencia de la estimacin dentro de
los proyectos de Software. Dichas herramientas permiten realizar
clculos que son difciles de hacer a mano y que tienden a realizarse
con errores, incluso utilizando calculadoras sofisticadas u hojas de
clculo. Adicionalmente, las herramientas de software de estimacin
suelen estar soportadas por datos histricos de la industria, que
permiten calibrar el proceso, adems de la capacidad que tienen para
ser calibradas con datos de la organizacin o el proyecto en curso.
2.4.12.1
Cosas que no se pueden hacer manualmente
Simular los posibles resultados de un proyecto:
52
Figura 12. Simulacin de los posibles resultados de un proyecto

usando la simulacin Monte Carlo. Fuente: Imagen extrada de la
herramienta Construx Estimate
La herramienta de estimacin toma en cuenta varias fuentes de
variabilidad:
Variacin en la productividad.
Variacin en el tamao del proyecto.
Variacin en las tasas de productividad/staff
La Figura 12 muestra un diagrama de dispersin el cual es el

resultado de la ejecucin de la tcnica de simulacin Monte Carlo,
con la cual se obtienen 1000 posibles resultados modificando
aleatoriamente estas tres categoras de variables. La herramienta de
estimacin usada utiliza como base los modelos de estimacin
COCOMO II y el modelo de Putnam (SLIM); los factores de ajuste
de cada uno de estos modelos son las variables que el software
simula.
Anlisis de probabilidad: Las herramientas de estimacin de

software pueden brindar una grfica de probabilidad como la
presentada en la Figura 13, en la cual se puede leer
53
claramente la relacin entre el esfuerzo estimado y la

probabilidad de que esta estimacin resulte exacta.
Figura 13. Anlisis de probabilidad respecto al esfuerzo estimado

Fuente: Imagen extrada de la herramienta Construx Estimate
Ajustar la estimacin a las deseconomas de escala: Los

modelos matemticos contenidos en las herramientas
incluyen factores de ajuste, acorde con este criterio.
Ajustar la estimacin a requerimientos inestables: De acuerdo

con los datos de calibracin y el punto en que se encuentre el
proyecto
respecto
al
cono
de
la
incertidumbre,
las
herramientas de estimacin ajustan las estimaciones.
Estimacin de aspectos poco comunes: Las herramientas

contabilizan actividades poco estimadas y costeadas, como
son la gerencia de proyecto, el proceso de calidad,
54
elaboracin de la documentacin, etc.

Clculo de opciones de planeacin e integracin con herramientas
de planeacin.
Anlisis Qu pasa si?: Por medio del uso de

herramientas de estimacin es posible ajustar rpidamente
los datos de entrada o supuestos del proyecto y obtener una
vista previa de cmo resulta la estimacin si se cambian los
parmetros.
Arbitrar expectativas poco realistas: Es usual que el cliente o

un gerente de proyecto debata la estimacin argumentando
metas del negocio. La simulacin presentada en la Figura 12,
muestra
qu
poblacin
de
resultados
tienen
menos
probabilidades de ser ciertas. Presentando el anlisis

arrojado
por
el
grfico,
se
puede
informar
de
las
probabilidades reales de cumplir con fechas deseadas por

actores del proyecto de este tipo.
Actuar como autoridad objetiva cuando se reajustan los

supuestos de la estimacin: Es posible realizar el anlisis del
impacto que se introduce al modificar los supuestos iniciales;
uno de los ms comunes es la suposicin que se hace bajo la
teora de que adicionar ms recursos a un proyecto
disminuye su duracin. La Figura 14 muestra el clculo del
efecto en el cronograma que tendra incrementar el esfuerzo
invertido. Sin embargo, respecto a este aspecto siempre hay
que tener en cuenta la influencia de las deseconomas de
escala al momento de introducir una nueva persona a un
proyecto.
55
Figura 14. Anlisis del efecto en duracin al incrementar el esfuerzo.

Fuente: Imagen extrada de la herramienta Construx Estimate
Estimar proyectos grandes: La estimacin de proyectos

grandes resulta complicada por medio de tcnicas manuales
y se tiende siempre a inexactitudes. Las herramientas de
estimacin ayudan a procesar mejor la informacin con la
que se cuenta para estimar y permite que el resultado del
proceso sea ms exacto.
2.4.13 Uso de Mltiples Tcnicas
Una de las mejores prcticas es utilizar mltiples tcnicas de

estimacin y buscar convergencia o dispersin entre estimaciones
resultantes. La convergencia indica que probablemente se tiene una
buena estimacin y la dispersin indica que probablemente se
obviaron factores. La Figura 15 presenta los resultados obtenidos por
varios mtodos de estimacin.
56
Figura 15. Comparacin de resultados de diferentes tcnicas de

estimacin. Fuente: Estimation: Desmystifying the black art, Steve
McConnell
2.5
Flujo de una buena estimacin
En proyectos pobremente estimados, la estimacin se enfoca directamente

en estimar el costo, el esfuerzo y el cronograma, con poco o sin ningn
inters en estimar el tamao del software que ser construido. En un
proyecto bien estimado, el foco de la estimacin y las reestimaciones que se
realizan en el transcurso de ste es diferente.
Dentro de un buen proceso de estimacin, el principal factor que debe ser
estimado es el tamao. El esfuerzo debe ser calculado a partir del tamao
estimado del proyecto usando datos histricos. El costo y el cronograma del
proyecto son calculados a partir del esfuerzo estimado. La Figura 16
muestra este flujo.
57
Figura 16. Flujo de un buen proceso de estimacin. Fuente:

2.5.1
Consideraciones para la estimacin del tamao
2.5.1.1
Tcnicas de medicin del tamao
Existen diversas tcnicas para la estimacin o medicin del tamao

de un proyecto de software. Entre ellas estn:
Caractersticas
Historias de Usuarios
Puntos de Historias
Requisitos
Casos de Uso
Puntos de Casos de Uso
Puntos de Funcin
Formularios
Componentes de Interfaz Grfica
Tablas de base de datos
Definicin de interfaces con otros sistemas
Clases
58
Funciones / Sub-Rutinas
Lneas de Cdigo
Las dos tcnicas que mayor acogida poseen actualmente son la

medicin del tamao por lneas de cdigo y el anlisis por puntos de
funcin. Otra tcnica que tiene bastante acogida tambin es la de
puntos de casos de uso, debido al creciente uso del modelamiento
de requisitos con este tipo de diagramas dentro de las metodologas
de desarrollo modernas.
2.5.1.2
Estimacin del Tamao por LOC
El uso de las lneas de cdigo como parmetro para medir el

tamao es un tema controversial dentro de la comunidad de la
Ingeniera de Software. He aqu algunas ventajas y desventajas:
Ventajas:
Los datos histricos de las LOC de proyectos anteriores se

pueden recolectar automticamente con herramientas.
Datos histricos de muchas organizaciones se encuentran en

trminos de LOC
Mtricas en LOC permiten la comparacin entre proyectos y

la estimacin basada en datos histricos.
La mayora de las herramientas de estimacin basan el

clculo del esfuerzo y del cronograma en las LOC.
Desventajas:
59
Modelos simplistas como LOC por mes/staff son tendientes

al error debido a las deseconomas de escala y a las
diferencias en mtricas de productividad para diferentes tipos
de software.
Las LOC no pueden ser usadas como la base para la

estimacin de tareas individuales, debido a las diferencias en
productividad entre diferentes programadores.
Un proyecto que requiera una mayor complejidad en el

cdigo que los proyectos usados para calibrar los supuestos
de productividad, puede afectar la exactitud de la estimacin.
Los
indicadores
basados
en
LOC
son
altamente
dependientes del lenguaje, lo cual implica que un proyecto

que se va a implementar utilizando un lenguaje de
programacin diferente al medido por los datos histricos, no
puede usar stos como base para la calibracin.
Usar la medida de LOC como base para estimar el esfuerzo

en requerimientos, diseo y otras actividades no relacionadas
con la codificacin, parece no intuitivo.
Las LOC son difciles de estimar directamente y deben

normalmente ser estimadas por referencia (Ver Estimaciones
Basadas en Referencias ).
La definicin de lo que constituye una lnea de cdigo debe

ser detallado y documentado para evitar problemas.
El debate respecto al uso de las lneas de cdigo para la medicin

del tamao se concentra principalmente alrededor del concepto de
que la Ingeniera de Software tiene demasiadas complejidades
asociadas para reducir sus indicadores a una sola medida. Sin
embargo, las lneas de cdigo son el principal caballo de batalla
entre las tcnicas para registrar la historia de anteriores proyectos y
60
las estimaciones tempranas de los nuevos. Conservando un manejo

consistente en la recoleccin de esta mtrica es un activo valioso y
fcilmente mantenible para la calibracin del modelo de la
estimacin dentro de una organizacin
2.5.1.3
Estimacin del Tamao por Puntos de Funcin (FP)
Una alternativa a la mtrica LOC es el uso de puntos de funcin. Un

punto de funcin es una medida del tamao del programa en
funcin de las caractersticas que deben ser implementadas
(Albrecht 1979). Los puntos de funcin son ms fciles de calcular
de una especificacin de requisitos que estimar las lneas del
cdigo, y proporcionan una base para calcular el tamao en lneas
del cdigo. Existen diversos mtodos para calcular los puntos de
funcin. El estndar para el conteo de puntos de funcin es
mantenido por el Grupo de Usuarios Internacional de puntos de
funcin (IFPUG) y se puede encontrar en su sitio Web en
www.ifpug.org. El nmero de los puntos de funcin en un programa
se basa en el nmero y la complejidad de cada uno de los puntos
siguientes:
Las entradas externas: Pantallas, formas, cajas de dilogo, o las
seales de control a travs de las cuales el usuario final u otro
programa agregan, eliminan, o cambian los datos de un programa.
Incluyen cualquier entrada que tenga un formato nico o una lgica
de proceso nica.
Salidas externas: Pantallas, informes, grficos, o seales de control
que el programa genera para uso del usuario final o de otro
61
programa. Incluyen cualquier salida que tenga un diverso formato o

requiera una diversa lgica de proceso que otros tipos de la salida.
Consultas externas: Normalmente se refiere a los queries realizados
a la base de datos; estos pueden ejecutar operaciones de entrada y
de salida.
Archivos lgicos internos: Grupos lgicos importantes de los datos
del usuario final o de la informacin de control que son controlados
totalmente por el programa. Un archivo lgico puede consistir en un
solo archivo plano o una sola tabla en una base de datos.
Interfaces externas: Son archivos generados o recibidos por otros
programas, con los cuales el sistema intercambia informacin.
La Tabla 12 muestra cmo se realiza el conteo de los puntos de
funcin y los multiplicadores asociados con cada complejidad. La
cifra resultante se conoce como conteo de puntos de funcin
desajustado.
Puntos de Funcin
Caractersticas del
programa
Entradas externas
Complejidad
Baja
_A_ 3
Complejidad
Media
_B_ 4
Complejidad
Alta
_C_ 6
Salidas Externas
_A_ 4
_B_ 5
_C_ 7
Queries Externas
_A_ 3
_B_ 4
_C_ 6
Archivos
internos
_A_ 4
_B_ 10
_C_ 15
Lgicos
Desajuste
Sumatoria
del total
entradas
externas
Sumatoria
del total
salidas
externas
Sumatoria
del total
Queries
Externas
Sumatoria
del total
Archivos
Lgicos
Internos
de
de
de
de
62
Archivos
de
Interfase externos
_A_ 5
_B_ 7
_C_ 10
Sumatoria
del total de
Archivos de
Interfase
externos
Tabla 12 . Formato general para el conteo de puntos de funcin.

Fuente: Puntos por Funcin. Una mtrica estndar para establecer el
tamao del software.
Ventajas:
Permiten tener una estimacin temprana bastante exacta del
tamao del proyecto.
Desventajas:
Obliga realizar una revisin exhaustiva de los requerimientos y
literalmente contar cada entrada, salida, archivo, etc.
2.5.1.4
Clculo de Puntos de Funcin Ajustados

La tcnica de Puntos de Funcin incluye un paso de ajuste que
puede resultar opcional, de acuerdo con el criterio de las personas
que realizan las estimaciones dentro de la organizacin. sta etapa
de la tcnica consiste en la valoracin de catorce factores que
completan la visin externa de la aplicacin; en otras palabras,
valoran el conjunto de caractersticas del sistema que no hacen
parte de la especificacin funcional de ste, pero que de todos
modos pueden influir en el esfuerzo en el que se incurre para
completar el proyecto.
Cada uno de estos factores de ajuste toman valores de 0 a 5, de
acuerdo con su nivel de influencia sobre el proyecto en particular. Al
igual que con cualquier tcnica de estimacin, la subjetividad es un
factor presente tambin en los puntos de funcin; el uso de los
factores de ajuste introduce esta subjetividad a la estimacin del
63
tamao del proyecto. Por lo tanto, estos factores, si se decide

ajustar el conteo de puntos de funcin, deben ser valorados con
cuidado y por personas que tengan la suficiente experiencia y
criterio para ponerle los pesos adecuados a cada factor, con el fin
de
evitar
posibles
subestimaciones
sobre
estimaciones
innecesarias.
A continuacin se presenta una descripcin de cada factor y cmo
pueden ser evaluados:
Factor 1. Comunicacin de Datos:
Los datos usados en el sistema se envan o reciben por lneas de
comunicaciones. Aunque los avances en las telecomunicaciones
han logrado que el desarrollo de la mayora de proyectos se
abstraiga del problema de la transmisin de datos, hay ciertos
aspectos que deben ser tenidos en cuenta.
Valoracin:
0: Sistema aislado del exterior
1: En lotes, usa perifricos de entrada o salida remotos
2: En lotes, usa perifricos de entrada o salida remotos
3: Captura de datos en lnea o teleproceso que pasa los datos o
sistema de consulta
4: Varios teleprocesos con mismo protocolo
5: Varios protocolos. Sistema Abierto y con interfaces de todo tipo al
exterior.
Factor 2. Proceso Distribuido:
64
Existen procesos o datos distribuidos, y el control de estos forma

parte del sistema.
Valoracin:
0: Sistema totalmente centralizado
1: Sistema realiza procesos en un equipo, salidas usadas va
Software por otros equipos
2: Sistema captura, los trata en otro
3: Proceso distribuido, transacciones de una sola direccin.
4: dem, transferencia en ambas direcciones.
5: procesos cooperantes ejecutndose en distintos equipos.
Factor 3. Objetivos de Rendimiento.
Si el rendimiento es un requisito del sistema, es decir, es crtico,
algn factor como tiempo de respuesta o cantidad de operaciones
por hora, se tendr que hacer consideraciones especiales durante el
diseo, codificacin y mantenimiento.
Valoracin:
0: Rendimiento normal (no se da nfasis )
1: Se indican requisitos, no medida especial.
2: Crtico en algunos momentos. Procesos acabados antes de
prxima sesin de trabajo.
3: Tiempo de respuesta es crtico.
4: El proyecto requiere en diseo hacer anlisis de rendimiento en
tiempo respuesta o cantidad operaciones/hora
65
5: El proyecto requiere el uso de herramientas para alcanzar el

rendimiento demandado por el usuario
Factor 4. Configuracin de Explotacin Usada por Otros
Sistemas.
El sistema tendr que ejecutarse en un equipo en el que coexistir
con otros, compitiendo por los recursos, debiendo tenerse en cuenta
en las fases de diseo.
Valoracin:
0: No se indican restricciones
1: Existen las restricciones usuales
2: Caractersticas de seguridad o tiempos.
3: Restricciones en algn procesador
4: El sistema deber funcionar con restricciones de uso en algn
procesador.
5: Restricciones especiales para aplicacin en los componentes
distribuidos del sistema
Factor 5. Tasa de Transacciones.
La tasa de transacciones ser elevada. Se tendr que hacer
consideraciones especiales durante el diseo, codificacin e
instalacin.
Valoracin:
0: No se prevn picos
66
1: Se prevn picos poco frecuentes (mensual)

2: Se prevn picos semanales
3: Se prevn horas punta, diarias
4: Tasa de transacciones tan elevada que en diseo se hace
anlisis de rendimiento
5: Anlisis de rendimiento en diseo, implementacin e instalacin.
Factor 6. Entrada de Datos en Lnea.
La entrada de datos ser directa desde el usuario a la aplicacin, de
forma interactiva.
Valoracin:
0: Todo es en lote
1: 1%<entradas interactivas <7%
5: Entradas interactivas >30%
Factor 7. Eficiencia con el Usuario Final.
Se demanda eficiencia para el usuario en su trabajo, es decir se
tiene que disear e implementar la aplicacin con interfaces fciles
de usar y con ayudas integradas.
Valoracin:
0: No se da nfasis al tema
67
1: 1 a 3 de los factores
2: 4 a 5 de los factores
3: 6 ms factores, sin requerir eficiencia
4: El proyecto cuenta con requerimientos que implican estudio de los
factores humanos en el diseo
5: En el proyecto se demandan prototipos y herramientas para
verificar que se alcanzarn los objetivos
Factor 8. Actualizaciones en Lnea.

Los archivos maestros y las Bases de Datos son modificadas
directamente de forma interactiva.
Valoracin:
0: No hay
1: De 1 a 3 archivos con informacin de control. Cantidad baja y
archivos recuperables
2: 4 ms Archivos de control
3: Actualizacin de archivos importantes
4: El proyecto define como esencial la proteccin ante prdidas
5: Gran cantidad de actualizaciones interactivas. Sistemas de
recuperacin muy automatizados
Factor 9. Lgica de Proceso Interno Compleja.
La complejidad interna en un proceso est en funcin de las
siguientes caractersticas:
68
Especificados algoritmos matemticos complejos.
Proceso con lgica compleja.
Se han especificado muchas excepciones, consecuencia de

transacciones incompletas, que debern tratarse.
Manejar mltiples dispositivos de entrada/salida.
Se incorporaran sistemas de seguridad y control.
Valoracin:
0: Ninguna de las caractersticas
1: 1 Caracterstica
2: 2 Caractersticas
...
5: Las 5 caractersticas
Factor 10. Reutilizacin del Cdigo.
Se tendr que hacer consideraciones especiales durante el diseo,
codificacin y mantenimiento para que el cdigo se reutilice en otras
aplicaciones o lugares.
Se habla de reutilizacin en los siguientes entornos:
Dentro de la propia aplicacin.
Por varios sistemas
Parametrizable.
Valoracin:
69
0: No se prev
1: Reutilizar cdigo en la misma aplicacin
2: Menos de un 10% de la aplicacin tiene en cuenta las
necesidades de + de 1 usuario
3: El 10 % o ms ...
4: Aplicacin preparada para ser reutilizable. Nivel de cdigo
5: Aplicacin preparada para ser reutilizable. Por medio de
parmetros
Factor 11. Contempla la Conversin e Instalacin.

Se proveern facilidades de conversin en el sistema, se tendr que
hacer consideraciones especiales durante el diseo, codificacin y
pruebas para que la conversin del sistema antiguo sean fciles de
realizar durante la puesta en marcha del sistema nuevo.
Valoracin:
0: No se requiere conversin.
1: Se solicita facilidad de instalacin
2: Se solicitan procesos de conversin e instalacin, no importantes
para el proyecto
3: Se solicitan procesos de conversin e instalacin importantes
para el proyecto
4: 2, y herramientas conversin e instalacin
5: 3, y herramientas conversin e instalacin. Sistema crtico para la
empresa
Factor 12. Facilidad de Operacin.
70
Operacin del sistema: los trabajos asignados al centro de proceso

de datos:
Arranque
Detencin
Recuperacin ante fallos
Copias de seguridad
Minimizacin de las actividades manuales en el CPD.
Se valora cuando ha sido descrita desde las primeras fases,

dedicndose especial atencin durante el diseo, codificacin y
pruebas.
Valoracin:
0: Nada, solamente back-up
1 a 4: Suma de tems:
Arranque, back-up y recuperacin
dem, sin intervencin operador ( X2 )
Minimizar
necesidad
de
dispositivos
externos
de
almacenamiento.
Minimiza necesidad de manejar papel
5: Sistema automtico sin intervencin humana

Factor 13. Instalaciones Mltiples
El sistema ha de incluir los requerimientos de diversas empresas o
departamentos en donde se ejecutar (incluso plataformas). Estas
71
caractersticas estarn presentes durante el diseo, codificacin y

pruebas.
Valoracin:
0: 1 solo lugar
1: Mltiples lugares, mismo Hardware y Software
2: En diseo se tiene en cuenta el caso (1)
3: En diseo se tiene en cuenta mltiples entornos Hardware y
Software
4: Se documenta y planea para (1) y (2)
5: dem, para (3)
Factor 14. Facilidad de Cambios
Se tendr que hacer consideraciones especiales durante el diseo,
codificacin y mantenimiento para que en el sistema sea fcil de
introducir cambios y fcil de adaptar al usuario.
tems a tener en cuenta:
Consultas flexibles del usuario:

o Simples, con condiciones lgicas And/Or que implican
un nico archivo lgico (A.L.)
o Medias, con condiciones lgicas sobre ms de 1 A.L.
(x2)
o Complejas, con condiciones lgicas complejas que
afectan a varios A.L. (x3)
Parmetros de la aplicacin con tablas ajenas al cdigo:

o El cambio se hace efectivo al arrancar el sistema
72
o El cambio es interactivo (x2)

Valoracin:
0: No se especifica nada
1: Un tem de valor 1
2: Items por valor 2
3: ...
5: tems por valor 5
Una vez sean valorados cada uno de los factores de ajuste, se

realiza la sumatoria de stos y se utiliza la siguiente frmula para
calcular los puntos de funcin ajustados:
PFA = PFSA * (0,65 + (0.01 * FA))
Donde:
PFA: Puntos de funcin ajustados
PFSA: Puntos de funcin sin ajustar
FA: Factor de ajuste. Obtenido realizando la sumatoria de las
valoraciones de todos los factores de ajuste.
2.5.1.5
Conversin de puntos de funcin a lneas de cdigo
Con base en datos promedio de la industria, es posible realizar un

clculo del nmero de lneas de cdigo a partir de los puntos de
funcin para un conjunto de lenguajes de programacin.
73
Es apropiado tener una mtrica relacionada con las lneas de cdigo

resultantes por cada punto de funcin en los proyectos realizados a
travs del tiempo, en cada organizacin
Lenguaje
Ada 83
Ada 95
C
C#
C++
Cobol
Fortran 90
Fortran 95
Java
Macro
Assembly
Perl
Second
generation
default
(Fortran 77,
Cobol,
Pascal, etc.)
Smalltalk
SQL
Microsoft
Visual Basic
Programacin de Sentencias por

Funcin
Mnimo (Menos Moda (Mayor
una
desviacin Valor Comn)
estndar)
Puntos de
45
30
60
40
40
65
45
30
40
130
80
50
128
55
55
107
80
71
55
213
Mximo
(mas
una
desviacin
estndar)
125
70
170
80
140
150
125
100
80
300
10
65
20
107
30
160
10
7
15
20
13
32
40
15
41
Tabla 13. Promedios de la Industria de lneas de cdigo por punto de

funcin. Adaptada de: software Costs(1998), Software Cost
Estimation with Cocomo II(Boehm 200), y estimate Software
Intensive Systems(Stutzke 1995).
2.5.1.6
Estimacin del Tamao por Puntos de Casos de Uso
74
La estimacin mediante el anlisis de Puntos de Casos de Uso es

un
mtodo
propuesto
originalmente
por Gustav Karner,
posteriormente refinado por muchos otros autores. Se trata de un

mtodo de estimacin del tiempo de desarrollo de un proyecto
mediante la asignacin de "pesos" a un cierto nmero de factores
que lo afectan, para finalmente contabilizar el tiempo total estimado
para el proyecto a partir de esos factores. A continuacin, se
detallan los pasos a seguir para la aplicacin de este mtodo.
El primer paso para la estimacin consiste en el clculo de los
Puntos de Casos de Uso sin ajustar. Este valor, se calcula a partir
de la siguiente ecuacin:
Donde,
UUCP: Puntos de Casos de Uso sin ajustar
UAW: Factor de Peso de los Actores sin ajustar
UUCW: Factor de Peso de los Casos de Uso sin ajustar
Factor de Peso de los Actores sin ajustar (UAW)
Este valor se calcula mediante un anlisis de la cantidad de Actores
presentes en el sistema y la complejidad de cada uno de ellos. La
complejidad de los Actores se establece teniendo en cuenta, en
primer lugar, si se trata de una persona o de otro sistema, y en
segundo lugar, la forma como el actor interacta con el sistema.
Los criterios se muestran en la Tabla 14.
Tipo de
Actor
Descripcin
Factor
de Peso
75
Simple
Medio
Complejo
Otro sistema que interacta con el 1

sistema a desarrollar mediante una
interfaz
de
programacin
(API,
Application Programming Interface)
Otro sistema que interacta con el 2
sistema a desarrollar mediante un
protocolo o una interfaz basada en
texto.
Una persona que interacta con el 3
sistema mediante una interfaz grfica.
Tabla 14. Criterios de peso para la clasificacin de actores en UCP.

Fuente: Mtricas de Estimacin de Tamao Puntos de Casos de
Uso, Sigifredo E. Bandai Hernndez (2002)
Factor de Peso de los Casos de Uso sin ajustar (UUCW)

Este valor se calcula mediante un anlisis de la cantidad de Casos
de Uso presentes en el sistema y la complejidad de cada uno de
ellos. La complejidad de los Casos de Uso se establece teniendo en
cuenta la cantidad de transacciones efectuadas en el mismo, donde
una transaccin se entiende como una secuencia de actividades
atmica, es decir, se efecta la secuencia de actividades completa,
o no se efecta ninguna de las actividades de la secuencia. Los
criterios se muestran en la Tabla 15:
Tipo de
Caso de
Uso
Simple
Medio
Complejo
Descripcin
Factor de Peso
El Caso de Uso contiene de 1 5

a 3 transacciones
El Caso de Uso contiene de 4 10
a 7 transacciones
El Caso de Uso contiene ms 15
de 8 transacciones
76
Tabla 15. Criterios de peso para la clasificacin de casos de uso en

UCP. Fuente: Mtricas de Estimacin de Tamao Puntos de Casos
de Uso, Sigifredo E. Bandai Hernndez (2002)
Clculo de Puntos de Casos de Uso ajustados

Una vez que se tienen los Puntos de Casos de Uso sin ajustar, se
debe ajustar este valor mediante la siguiente ecuacin:
UCP = UUCP TCF EF

Donde,
UCP: Puntos de Casos de Uso ajustados
UUCP: Puntos de Casos de Uso sin ajustar
TCF: Factor de complejidad tcnica
EF: Factor de ambiente
Factor de complejidad tcnica (TCF)
Este coeficiente se calcula mediante la cuantificacin de un conjunto
de factores que determinan la complejidad tcnica del sistema.
Cada uno de los factores se cuantifica con un valor de 0 a 5, donde
0 significa un aporte irrelevante y 5 un aporte muy importante. En la
Tabla 16 se muestra el significado y el peso de cada uno de estos
factores.
Factor
Descripcin
T1
T2
Sistema distribuido
Objetivos de rendimiento
tiempo de respuesta
Peso
2
o 10
77
T3
T4
T5
T6
T7
T8
T9
T10
T11
T12
T13
Eficiencia del usuario final

Procesamiento interno complejo
El cdigo debe ser reutilizable
Facilidad de instalacin
Facilidad de uso
Portabilidad
Facilidad de cambio
Concurrencia
Incluye objetivos especiales de
seguridad
Provee acceso directo a
terceras partes
T13 Se requieren facilidades
especiales de entrenamiento
a usuarios
15
1
1
0.5
0.5
2
1
1
1
1
1
Tabla 16. Factores de peso de complejidad tcnica en UCP.

El Factor de complejidad tcnica se calcula mediante la siguiente

ecuacin:
TCF = 0.6 + 0.01 x (Peso x Valor asignado )
Factor de ambiente (EF)
Las habilidades y el entrenamiento del grupo involucrado en el
desarrollo tienen un gran impacto en las estimaciones de tiempo.
Estos factores son los que se contemplan en el clculo del Factor de
ambiente. El clculo del mismo es similar al clculo del Factor de
complejidad tcnica, es decir, se trata de un conjunto de factores
que se cuantifican con valores de 0 a 5. En la Tabla 17 se muestra
el significado y el peso de cada uno de estos factores.
78
Factor
Descripcin
Peso
E1
Familiaridad con el modelo de proyecto

utilizado
Experiencia en la aplicacin
Experiencia en orientacin a objetos
Capacidad del analista lder
Motivacin
Estabilidad de los requerimientos
Personal part-time
Dificultad del lenguaje de programacin
1.5
E2
E3
E4
E5
E6
E7
E8
0.5
1
0.5
1
2
-1
-1
Tabla 17. Factores de peso en condiciones del ambiente en UCP.

Para los factores E1 al E4, un valor asignado de 0 significa sin

experiencia, 3 experiencia media y 5 amplia experiencia (experto).
Para el factor E5, 0 significa sin motivacin para el proyecto, 3
motivacin media y 5 alta motivacin.
Para el factor E6, 0 significa requerimientos extremadamente
inestables, 3 estabilidad media y 5 requerimientos estables sin
posibilidad de cambios.
Para el factor E7, 0 significa que no hay personal part-time (es decir
todos son full-time), 3 significa mitad y mitad, y 5 significa que todo
el personal es part-time (nadie es full-time).
Para el factor E8, 0 significa que el lenguaje de programacin es
fcil de usar, 3 medio y 5 que el lenguaje es extremadamente difcil.
El Factor de ambiente se calcula mediante la siguiente ecuacin:
EF = 1.4 0.003 ( Pesoi ValorAsignado
2.5.2
Consideraciones para la estimacin del esfuerzo
79
2.5.2.1
Principales influencias de la estimacin del esfuerzo

La principal influencia en la estimacin del esfuerzo de un proyecto
es el tamao del software a ser construido. Debido a esto, las
tcnicas de estimacin normalmente estn orientadas a calcular el
esfuerzo como una funcin del tamao.
La segunda influencia ms importante es la productividad de la
organizacin, por lo cual resulta importante recolectar indicadores
dentro de la organizacin, que proporcionen datos histricos sobre
la productividad. Si no se cuenta con informacin histrica, puede
utilizarse datos de industria, pero hay que tener en cuenta que la
productividad en el desarrollo de software est directamente
relacionada con el tipo de software y la industria a la cual est
orientado, por lo tanto es importante elegir con qu conjunto de
datos se calibra el modelo de estimacin y as no introducir
variaciones peligrosas en la estimacin del esfuerzo.
2.5.2.2
Clculo del Esfuerzo a partir del tamao
Comparacin Informal
Si se cuenta con datos histricos de proyectos que no difieren en
ms de tres veces del tamao del proyecto al cual se le est
realizando un proceso de estimacin, es probablemente seguro
utilizar un modelo lineal para calcular el esfuerzo estimado de ste,
basndose en el esfuerzo real de los proyectos similares anteriores.
Uso de Herramientas de Estimacin
80
El uso de herramientas de estimacin permite realizar un proceso

formal del clculo del esfuerzo del proyecto, agregndole una
agilidad al mismo, obteniendo as mejores resultados.
En el medio se encuentran diversas herramientas que apoyan esta
labor, como ya se ha enunciando anteriormente en este documento.
Grficos de promedios de industria
Si no se cuenta con datos histricos propios, se puede realizar una
estimacin, con mediana probabilidad de error, usando grficos de
esfuerzo de la industria del software.
La Figura 17 muestra los promedios de la industria acerca del
esfuerzo invertido segn el tamao en lneas de cdigo; la lnea
inferior representa el promedio de esfuerzo total de los proyectos
reportados y la lnea superior representa el nivel de esfuerzo que
est a una desviacin estndar del promedio. Una estimacin
prudente utilizando este mtodo debe asumir productividad
promedio de la industria o menor que sta.
81
Figura 17. Grficos de promedios de esfuerzo en la Industria.

Fuente: http://www.isbsg.org/
2.5.2.3
Mtodo ISBSG
El Grupo Internacional de Medicin de Estndares de Software

(International Software Benchmarking Standards Group - ISBSG) ha
desarrollado un mtodo til para calcular el esfuerzo con base en
tres factores: El tamao del proyecto en puntos de funcin, el tipo de
ambiente de desarrollo y el tamao mximo del equipo de
desarrollo. La Ecuacin 6 es la frmula de propsito general de
proyectos de software, est calibrada con datos de alrededor de 600
proyectos. El grupo emite tambin frmulas para diferentes tipos de
proyectos, cuyas calibraciones se realizan con datos de entre 63 a
363 proyectos; entre las categoras de frmulas se encuentran:
Aplicaciones
Desktop,
desarrollo
con
lenguajes
de
tercera
generacin, desarrollo mainframe, entre otras.
82
Ecuacin 6. Frmula para proyectos de software de negocios segn

el ISBSG. Fuente ISBG
2.5.2.4
Conversin de Puntos de Caso de Uso a esfuerzo

Karner originalmente sugiri que cada Punto de Casos de Uso
requiere
20
horas-hombre.
Posteriormente,
surgieron
otros
refinamientos que proponen una granularidad algo ms fina, segn

el siguiente criterio:
Se contabilizan cuntos factores de los que afectan al factor

de ambiente estn por debajo del valor medio (3), para los
factores E1 a E6.
Se contabilizan cuntos factores de los que afectan al factor

de ambiente estn por encima del valor medio (3), para los
factores E7 y E8.
Si el total es 2 menos, se utiliza el factor de conversin 20

horas-hombre/Punto de Casos de Uso, es decir, un Punto de
Caso de Uso toma 20 horas-hombre.
Si el total es 3 4, se utiliza el factor de conversin 28 horashombre/Punto de Casos de Uso, es decir, un Punto de Caso
de Uso toma 28 horas-hombre.
Si el total es mayor o igual que 5, se recomienda efectuar

cambios en el proyecto, ya que se considera que el riesgo de
fracaso del mismo es demasiado alto.
El esfuerzo en horas-hombre viene dado por:
E = UCP CF
Donde,
83
E: esfuerzo estimado en horas-hombre

UCP: Puntos de Casos de Uso ajustados
CF: factor de conversin
Se debe tener en cuenta que este mtodo proporciona una
estimacin del esfuerzo en horas-hombre, contemplando slo el
desarrollo de la funcionalidad especificada en los casos de uso.
Comparacin de Estimaciones de Esfuerzo
Para realizar una valoracin de la realidad de los estimativos de
esfuerzo, es recomendable realizar una comparacin de los cuatro
mtodos descritos en esta seccin. Se debe dar una valoracin a
cada mtodo, segn el tipo de calibracin con que se realiz (Datos
de Industria, Empresa), dando mayor peso a las calibradas
localmente y analizar la convergencia o divergencia que suceda
entre estos. La Figura 18 presenta de una forma grfica la
comparacin entre diferentes mtodos de estimacin de esfuerzo,
dando mayor peso al clculo realizado con una herramienta y luego
a la comparacin informal, debido a que ambos mtodos utilizan
datos de la organizacin para calibrar una estimacin.
84
Figura 18. Comparacin de mtodos de estimacin del esfuerzo.

Fuente: Software Estimation: Desmytifiying the Black Art.
2.6
Clasificacin de Proyectos de Software
Como se enuncia en la seccin 1.3.8, el orden de importancia de las

influencias en la estimacin de proyectos de software se clasifica de la
siguiente manera:
Tamao del proyecto
Tipo de proyecto
Factores del personal
Lenguaje de programacin
Esto se ve reflejado en las tcnicas de estimacin, en donde la mayora de

stas hace nfasis en el tamao del proyecto. Las influencias asociadas al
tipo de software a desarrollar se ven ms reflejadas en la calibracin de
datos efectuada, siempre y cuando la informacin histrica que se utilice sea
85
de la organizacin o por lo menos pertenezca a datos de la industria de

software, restringidos al tipo de software especfico.
La industria local de desarrollo de software a la medida de Medelln ha
presentado inclinacin hacia el desarrollo alrededor de las siguientes
categoras de software: Sistemas transaccionales, Aplicaciones Web
(Intranet/Extranet) y Sistemas de Control o Gestin de Procesos (BPM).
Esta tendencia es en realidad coherente con la forma como han
evolucionado los paradigmas en sistemas informticos y las tecnologas
emergentes a nivel global. En esta seccin se realiza una definicin de estas
categoras.
2.6.1
Sistemas Transaccionales
Para definir qu es un sistema transaccional se debe entender primero

lo que significa una transaccin: Una transaccin es una operacin en
un sistema que cumple con los criterios conocidos como ACID. ACID
es un acrnimo de Atomicity, Consistency, Isolation and Durability:
Atomicidad, Consistencia, Aislamiento y Durabilidad en espaol, los
cuales se definen a continuacin.
Atomicidad: es la propiedad que asegura que la operacin se ha
realizado o no, y por lo tanto ante un fallo del sistema no puede quedar
a medias.
Consistencia: es la propiedad que asegura que slo se empieza
aquello que se puede acabar. Por lo tanto se ejecutan aquellas
operaciones que no van a romper las reglas y directrices de integridad
de la base de datos.
86
Aislamiento: es la propiedad que asegura que una operacin no puede

afectar a otras. Esto garantiza que la realizacin de dos transacciones
sobre la misma informacin, nunca generar ningn tipo de error.
Durabilidad: es la propiedad que asegura que una vez realizada la
operacin, sta persistir y no se podr deshacer aunque falle el
sistema.
Los sistemas transaccionales son implementados para facilitar varios
procesos
de
registro
de
operaciones de
negocio.
Presentan
requerimientos intensivos en los procesos de entrada y salida de

informacin, sus clculos o procesos suelen ser simples y poco
sofisticados. Estos sistemas requieren usualmente de mucho manejo
de datos para poder realizar sus operaciones, y como resultado
generan tambin grandes volmenes de informacin. Tienen la
propiedad de ser grandes recolectores de informacin, lo que quiere
decir que en estos sistemas se cargan las grandes bases de
informacin para su explotacin posterior. Son fciles de justificar ante
la direccin general, ya que sus beneficios son visibles y palpables. En
corto tiempo se pueden evaluar los resultados y las ventajas que se
tienen al implementarlo.
87
Figura 19. Ejemplo de interaccin de sistemas transaccionales con

otros sistemas. Fuente: http://iteso.mx/~abby/transaccional.htm
Los sistemas transaccionales tambin pueden ser vistos como
soluciones de tecnologas de informacin que permitan integrar los
procesos de competencias de las empresas, los cuales pueden ofrecer
capacidades para logsticas integradas, planeacin financiera, ventas,
procesos de rdenes, produccin y planeacin de los recursos
materiales.
Los sistemas transaccionales son los que usualmente se denominan
como sistemas ncleos de las compaas, que son los que soportan
los principales procesos de negocios, donde se realizan las principales
transacciones del mismo, sobre los cuales se construyen sistemas de
apoyo a tomas de decisiones.
88
Estos sistemas son necesarios para toda compaa y de estos

depende el desarrollo organizacional de las mismas. Debido al
volumen que se genera en cada una de las operaciones del negocio,
las transacciones se convierten en informacin relevante para la
compaa para el apoyo a toma de decisiones.
2.6.2
Aplicaciones Web
Una aplicacin Web es un sistema informtico que los usuarios utilizan

accediendo a un servidor Web a travs de Internet (Extranet) o de una
Intranet. Las aplicaciones Web son populares debido a la practicidad
del navegador Web como cliente liviano. La habilidad para actualizar y
mantener aplicaciones Web sin distribuir e instalar software en miles de
potenciales clientes es otra razn de su popularidad.
2.6.2.1
Historia
En los primeros tiempos de la computacin cliente-servidor, cada

aplicacin tena su propio programa cliente y su interfaz de usuario,
los cuales deban ser instalados separadamente en cada estacin
de trabajo de los usuarios. Una mejora al servidor, como parte de la
aplicacin, requera tpicamente una mejora de los clientes
instalados en cada una de las estaciones de trabajo, aadiendo un
costo de soporte tcnico y disminuyendo la eficiencia del personal.
En contraste, las aplicaciones Web generan dinmicamente una
serie de pginas en un formato estndar, soportado por
navegadores Web comunes como HTML o XHTML. Se utilizan
lenguajes interpretados del lado del cliente, tales como JavaScript,
89
para aadir elementos dinmicos a la interfaz de usuario.

Generalmente cada pgina Web individual es enviada al cliente
como un documento esttico, pero la secuencia de pginas provee
de una experiencia interactiva.
2.6.2.2
Interfaz
Las interfaces Web tienen ciertas limitantes en la funcionalidad del

cliente. Mtodos comunes en las aplicaciones de escritorio como
dibujar en la pantalla o arrastrar-y-soltar no estn soportadas por las
tecnologas Web estndar. Los desarrolladores Web comnmente
utilizan lenguajes interpretados del lado del cliente para aadir ms
funcionalidad, especialmente para crear una experiencia interactiva
que no requiera recargar la pgina cada vez (cosa que suele
molestar a los usuarios). Recientemente se han desarrollado
tecnologas para coordinar estos lenguajes con tecnologas del lado
del servidor, como por ejemplo PHP. AJAX es una tcnica de
desarrollo Web que usa una combinacin de varias tecnologas para
crear lo que se conoce como "Rich Internet Applications" (RIA),
aplicaciones de Internet con mayor riqueza en la interfaz grfica.
2.6.2.3
Uso en negocios
Una
estrategia
que
est
emergiendo
para
las
empresas
proveedoras de software, es proveer acceso va Web al software.

Para aplicaciones previamente distribuidas como de escritorio, esto
puede requerir el desarrollo de una aplicacin totalmente nueva o
simplemente adaptar la aplicacin para usar una interfaz Web. Estos
programas permiten al usuario pagar una cuota mensual o anual
90
para usar la aplicacin, sin necesidad de instalarla en la

computadora del usuario. Las compaas que siguen esta estrategia
son llamadas Proveedores de Aplicaciones de Servicio (ASP por sus
siglas en ingls), este modelo de negocios est atrayendo la
atencin de la industria del software.
En el mundo corporativo, la proliferacin de las aplicaciones Web
como estrategia para las soluciones informticas cada vez es
mayor. Las posibilidades de acceso que brindan este tipo de
aplicativos, permiten que fcilmente puedan implementarse en una
organizacin a travs de una Intranet, sistemas como: Sistemas de
apoyo, herramientas de capacitacin, soluciones de inteligencia de
negocios, herramientas colaborativas, entre otros. Adicional a las
posibles soluciones basadas en aplicaciones Web que son
accedidas por la Intranet, las empresas mediante esta estrategia
tambin han logrado expandir la interaccin que tienen con sus
clientes, proveedores y socios estratgicos, creando aplicaciones
Web para suplir las necesidades de interaccin que cada una de las
empresas tendran con estas contrapartes, dndole vida a
conceptos tales como comercio electrnico, negocios electrnicos,
sistemas B2B y sistemas B2C.
2.6.3
Sistemas de Control o Gestin de Procesos (Business Process
Management - BPM)
2.6.3.1
Descripcin General
91
Los sistemas BPM surgen a partir de una metodologa empresarial

cuyo objetivo es mejorar la eficiencia a travs de la gestin
sistemtica de los procesos de negocio (BPM), que se deben
modelar, automatizar, integrar, monitorizar y optimizar de forma
continua.
Como
su
nombre
lo
sugiere,
Business
Process
Management (BPM) se enfoca en la administracin de los procesos

del negocio.
A travs del modelado de las actividades y procesos se logra un
mejor entendimiento del negocio y muchas veces esto presenta la
oportunidad de mejorarlos. La automatizacin de los procesos
reduce errores, asegurando que los mismos se comporten siempre
de la misma manera y dando elementos que permitan visualizar el
estado de los mismos. La administracin de los procesos permite
asegurar que los mismos estn ejecutndose eficientemente y
obtener informacin que luego puede ser usada para mejorarlos. Es
a travs de la informacin que se obtiene de la ejecucin diaria de
los procesos que se pueda identificar posibles ineficiencias en los
mismos y de esta forma optimizarlos.
Para soportar esta estrategia es necesario contar con un conjunto
de herramientas que den el soporte necesario para cumplir con el
ciclo de vida de BPM. Este conjunto de herramientas son llamadas
Business Process Management System y con ellas se construyen
aplicaciones BPM.
Existen diversos motivos que promueven la gestin de Procesos de
Negocio (BPM); dichos motivos son:
Extensin del programa institucional de calidad
92
Cumplimiento de legislaciones
Crear nuevos y mejores procesos
Entender qu se est haciendo bien o mal a travs de la

compresin de los procesos
Documentar procesos para outsourcing y definicin de SLA

(Service Level Agreement)
Automatizacin de procesos
Crear y mantener las cadenas de valor
La gerencia de proceso del negocio (BPM) es un campo del

conocimiento que est en la interseccin entre la gerencia y la
tecnologa de informacin. El trmino procesos operacionales del
negocio refiere a los procesos repetitivos del negocio realizados por
organizaciones en el contexto de sus operaciones cotidianas, en
comparacin con los procedimientos de toma de decisin
estratgicos que son realizados por la alta gerencia. BPM cubre las
actividades realizadas por organizaciones para manejar y, en caso
de ser necesario, para mejorar sus procesos del negocio; las
herramientas de software BPM han hecho tales actividades ms
rpidas y ms baratas. Los sistemas de BPM supervisan la
ejecucin de los procesos del negocio de modo que los encargados
puedan analizar y cambiar procesos en respuesta a las mtricas
resultante de la ejecucin de stos.
2.6.3.2
Actividades de la gerencia de proceso del negocio
Las actividades que constituyen la gerencia de proceso del negocio

se pueden agrupar en tres categoras: diseo, ejecucin y
supervisin.
93
Diseo de procesos
El diseo de procesos abarca el diseo y la captura de los procesos
existentes del negocio, as como la simulacin de nuevos. El
software usado para hacer esto incluye a redactores grficos que
documentan los procesos, los repositorios que almacenan modelos
de procesos, y las herramientas de simulacin de procesos del
negocio, para ejecutar un proceso una gran cantidad de veces y
ajustar su parametrizacin orientado a la optimizacin del tiempo y
costo del proceso.
Ejecucin de procesos
La manera tradicional de automatizar procesos es desarrollar o
comprar una aplicacin que permita ejecutar los pasos requeridos
del proceso. Sin embargo, en la prctica, stas permiten ejecutar
raramente todos los pasos del proceso exacta o totalmente. Debido
a la complejidad de desarrollar software, la documentacin de un
proceso implementado en una aplicacin a la medida es compleja.
Esto hace difcil cambiar o mejorar el proceso.
Como respuesta a estos problemas, se han desarrollado sistemas
que permiten al proceso completo del negocio (segn lo convertido
en la actividad de diseo de proceso). El sistema utilizar servicios
en aplicaciones conectadas para realizar operaciones de negocio
(Ejemplo, calculando un plan del reembolso para un prstamo) o,
cuando un paso es demasiado complejo de automatizar, requiere
una interaccin con el usuario. Comparado con cualquiera de los
acercamientos anteriores, directamente ejecutar una definicin de
proceso es mucho ms directo y por lo tanto ms fcil de mejorar.
94
Sin embargo, la automatizacin de una definicin de proceso

requiere la infraestructura flexible y comprensiva.
El mercado comercial del software de BPM se ha centrado en el
desarrollo de modelos de procesos grficos, en lugar de modelos de
proceso basados en texto, como una forma de reducir la
complejidad del desarrollo de modelos. Las reglas de negocio han
sido utilizadas por los sistemas para proporcionar las definiciones
para el comportamiento que los gobierna, y un motor de reglas de
negocio se puede utilizar para conducir la ejecucin del proceso y la
resolucin del mismo.
Supervisin de proceso
El monitoreo de procesos abarca el seguimiento de procesos
individuales para que la informacin de su estado pueda ser
fcilmente vista y se puedan proveer estadsticas de uno o ms
procesos. Adems, esta informacin se puede utilizar para trabajar
con los clientes y los proveedores para mejorar sus procesos
conectados. Las mtricas de monitoreo se clasifican en tres
categoras: duracin de ciclo, tasa de defectos y productividad.
2.6.3.3
Progresos futuros
Los BPMS son productos de software flexible, con los cuales es

posible automatizar integralmente y en forma paramtrica cualquier
tipo de proceso empresarial. El objetivo principal consiste en
automatizar los procesos de negocios, integrando alrededor de una
nica plataforma a todos los posibles actores o participantes de la
cadena de valor de un proceso, como son los clientes, los
95
funcionarios internos, los proveedores, etc., estimulando el trabajo

colaborativo y permitiendo la integracin entre aplicaciones
empresariales existentes (EAI: Enterprise Application Integration).
Este tipo de soluciones permiten la integracin de diferentes reas
de la misma organizacin o de otras organizaciones alrededor de
cada proceso, aunque estn geogrficamente dispersas, pero
manteniendo
un
control
centralizado.
La
mayora
BPMS
proporcionan las funciones para gestionar todos los componentes

que abarca cualquier proceso, como son: actividades, tareas, pasos,
rutas, lugares, roles, recursos humanos y fsicos, documentos
digitales y electrnicos, clculos, datos y formas electrnicas, de
acuerdo con las reglas y polticas de cada proceso. Deben tambin
incluirse herramientas de gestin, tales como consultas y reportes
para asegurar el mejoramiento continuo de los procesos y
mecanismos de control, tales como alarmas y dilogos, para
asegurar que se haga el trabajo por las personas responsables, en
la secuencia correcta, en el tiempo justo y con los recursos
adecuados.
Con los BPMS, cambia notablemente la forma como se automatizan
los procesos organizacionales, pues a diferencia de los sistemas
tradicionales verticales, estas plataformas los automatizan en forma
horizontal, independiente de a quin o a cul rea de la empresa
pertenecen las actividades o tareas que se deben realizar,
promoviendo as el trabajo colaborativo, compartido y en equipo.
Acordes con las tendencias en tecnologas de informacin actuales,
la mayora de BPMS brindan la posibilidad que un cliente desde
cualquier lugar y a travs de la Web inicie un proceso, que este
transite por todos los responsables de ejecutar las tareas necesarias
96
para atenderlo y que todos los interesados puedan conocer en

cualquier momento en qu estado se encuentra cada proceso.
Dentro de las posibilidades existentes para disear y poner en
ejecucin en la Web, se cuentan procesos tales como:
Atencin y Seguimiento de Preguntas, Quejas y Reclamos

(PQRs)
2.7
Procesos de compras y contratacin
Mesas de ayuda
Procesos jurdicos y trmites legales
Inicio y Seguimiento de ordenes de trabajo o de servicio
Procesos de cobro coactivo
Gestin y trmite de documentos
Logstica de comercio nacional e internacional
Procesos de evaluacin y cotizacin
Seguimiento a pedidos y rdenes de compra.
Trmites con Proveedores.
Procesos de ventas y rea comercial
Gestin documental automatizada
Trmites de toda ndole
Estado del Arte en la Industria Local
Se realiz un sondeo entre 6 empresas locales dedicadas al desarrollo de

software a la medida, en el cual se indag sobre tres aspectos centrales:
Tcnicas de estimacin utilizadas, exactitud obtenida y consideraciones
adicionales sobre el tema de estimacin en cada empresa. Las empresas
son todas de tamao mediano (entre 51 y 200 empleados segn la
clasificacin dada por la Ley Mipyme), y todas superan los 8 aos de
97
existencia. Debido a la naturaleza confidencial de la informacin, no se

detallan los nombres de las empresas investigadas. Estas empresas fueron
seleccionadas ya que son las ms representativas en el medio de desarrollo
de software a la medida en la ciudad de Medelln.
Para la obtencin de la informacin, se realiz una entrevista no
estructurada, con las personas responsables de estimacin de proyectos de
software de cada empresa, indagando principalmente sobre el proceso que
usan para la estimacin de proyectos.
Los resultados de la investigacin se presentan en la Tabla 18
Empresa
Tcnica
Empresa 1
WBS
no
estandarizado.
Juicios
expertos
no
estructurados
Empresa 2
Empresa 3
Para proyectos
grandes:
Puntos
de
funcin.
El
clculo
del
esfuerzo
a
partir de los
puntos
de
funcin
es
calibrado
mediante
datos
de
industria
y
tambin
con
datos de la
organizacin.
Para proyectos
pequeos:
Juicio experto
no
estructurado.
Tallaje
de
Camisetas.
Juicios
Expertos
no
Exactitud
Manifestada
Errores
de
estimacin que
oscilan entre el
320%
y
el
1200%
No se cuenta
con informacin
que permita dar
cifras de la MRE
en estimaciones
de la compaa.
Herramientas
de Estimacin
Excel
Hoja de Excel
con
macros
para el apoyo
al clculo de
puntos
de
funcin.
Para proyectos
grandes
se
cuenta con la
nocin general
de tener buenos
niveles
de
exactitud gracias
a
la
tcnica
usada.
Los
proyectos
pequeos sufren
normalmente de
grandes
desfases.
Errores entre el
180% y el 200%
para proyectos
grandes.
Excel
Observaciones
Histricamente
las
estimaciones han sido
siempre
de
"punto
nico.
Alto ndice de tareas
ocultas.
No existe un proceso
estandarizado
de
estimacin.
Para
proyectos
grandes, el nivel de
anlisis y diseo al que
obliga la tcnica de
puntos
de
funcin
aparenta
tener
un
proceso. Sin embargo,
la estimacin emitida
por la tcnica no se
revala formalmente a
travs del proyecto.
No se utilizan las
mtricas de proyectos
de la empresa para
calibrar
las
98
estructurados
WBS intuitivos
Empresa 4
Juicios
Expertos
no
estructurados
WBS intuitivos
Empresa 5
Estimaciones
basadas
en
referencias por
lgica difusa.
Puntos
Funcin
Empresa 6
Errores entre el
10% y el 13%
para el resto de
los proyectos.
Errores del 10%
sobre
las
estimaciones
realizadas
por
las tcnicas.
No se posee
informacin.
de
Puntos
de
Casos de Uso.
estimaciones.
Errores entre el
30% y el 50%
para proyectos
no ajustados a
los
procesos
estandarizados
de la empresa.
No se posee
informacin.
Excel
Hoja de Excel
con
macros
para el apoyo
al clculo de
puntos
de
funcin.
Hoja de Excel
con
macros
para
la
estimacin de
esfuerzo
basados en las
referencias
(proxy).
Herramienta de
estimacin
basada
en
Puntos
de
Casos de Uso.
Las
estimaciones
resultantes
de
las
tcnicas no resultaban
ser las usadas para la
planeacin.
Las
estimaciones
son
modificadas por el rea
comercial.
Calibracin
de
las
tcnicas con datos de
industria.
Calibracin
de
las
tcnicas con datos de
industria.
Tabla 18. Tcnicas de estimacin evidenciadas en 6 empresas de la industria

de software local
El sondeo realizado, muestra que aunque existe mucha documentacin de
tcnicas de estimacin de software, realmente se encuentra que la industria
local realiza la estimacin de proyectos de software de forma muy
"artesanal", siendo evidencia de esto que la mayora de las empresas
encuestadas utiliza el juicio de expertos no estructurado como tcnica
predominante y aquellas que usan algn mtodo ms formal de estimacin,
99
utilizan principalmente datos histricos de la industria mundial para la

calibracin de sus modelos. Con esto se puede concluir que la forma de
realizar las estimaciones de los proyectos de software estn muy atadas a la
subjetividad de las personas que trabajan en ellas. Sin embargo, es evidente
que la industria del software en Colombia es una industria donde su
crecimiento ha ido aumentando en los ltimos aos. Parece contradictorio
que la industria de software tenga un crecimiento pero que uno de los
principales procesos que afectan la rentabilidad del negocio no est
formalizado y que aun siga siendo artesanal.
100

Marco Teórico BPM

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Marco Teórico BPM

Enviado por

Direitos autorais:

Formatos disponíveis

2 Marco Terico

Los procesos, en el mundo moderno, son el patrn de trabajo de la gran

Metodologas Para el Modelamiento De Procesos

Bussines Process Modeling Notation

El Business Process Management Initiative fue desarrollado como el

El alcance de BPMN est direccionado a soportar los conceptos de

Adicionalmente, aunque en los diagramas de BPMN se presentan

La modelacin de procesos de negocio es usada para comunicarse

llamados flujos de trabajo. Un ejemplo de un proceso privado se

Figura 2. Proceso Privado. Fuente. Introduction to BPMN, Stephen

Figura 3. Proceso abstracto. Introduction to BPMN, Stephen A.

Proceso de Colaboracin (global): Este representa la interaccin

Figura 4. Proceso colaborativo. Introduction to BPMN, Stephen A.

Tipos de Diagramas BPD

Dentro de estos tres tipos de submodelos, muchos diagramas

Proceso privado de actividades de alto nivel.

Proceso de negocio privado detallado.

Viejos procesos de negocios

Nuevos procesos de negocio

Procesos de negocios detallados con interaccin a una o ms

Conjunto de Elementos de BPD

El objetivo de BPMN es crear un mecanismo simple para la creacin

Objetos de Flujo (Eventos, Actividades, Entradas)

Objetos de Conexin (Flujo de Secuencia, Flujo de Mensaje,

Swimlanes (Pools, Lanes)

Artefactos (Objetos de Datos, Grupos, anotaciones).

Tabla 2. Elementos Bsicos BPD. Fuente: Introduction to BPM,

Beneficios del uso de BPMN

Facilidad para el entendimiento y la Comunicacin:

Conceptos Crticos de Estimacin

En trminos generales, una estimacin es una prediccin de cunto va

software se entrelaza frecuentemente con los conceptos de metas del

Consecuencias de una mala estimacin

Efectividad reducida de la planeacin del proyecto: Las

Reduce las probabilidades de entregar el proyecto a tiempo:

Limita el tiempo para realizar fases crticas del ciclo de vida:

Prcticas destructivas en las etapas finales del proyecto:

o Discusiones frecuentes acerca de los requerimientos

Una vez las organizaciones realizan estimaciones lo suficientemente

Visibilidad mejorada en el estatus de los proyectos: Una de

Mejor Calidad: De acuerdo con Glass en [26], el 40% de los

cronogramas apretados. Si se puede evitar imponer esta

basada con mejores estimaciones, la calidad de los

Mejor coordinacin con roles no relacionados con software:

Mejores presupuestos: Estimaciones ms exactas ayudan a

Informacin temprana acerca de los posibles riesgos:

Relacin entre la Estimacin y la Planeacin

Crear una estimacin precisa y analtica no garantiza que la estimacin

Estimaciones de punto-nico (single-point)

Cuando se realizan las estimaciones, hay que tener presente que la

vende la idea que el proyecto tiene un 100% de probabilidad de

Qu es una buena estimacin?

estimaciones se debe contar con procesos organizacionales bien

Figura 5. Mejoras en la estimacin de proyectos en la Boeing Company.

La Figura 6 presenta el cono de la incertidumbre, que representa el

Figura 6. Cono de la Incertidumbre Basado en tiempo de calendario.

Causales generales de error en las estimaciones

Los siguientes causales son los principales errores que se tienen en

Proceso de desarrollo catico

Actividades o caractersticas omitidas

Optimismo infundado: reduccin de las estimaciones de los

Estimaciones a vuelo de pjaro

Influencias en la Estimacin de un Proyecto de Software