5. marco teórico bpm
DESCRIPTION
Marco teorico de BPMTRANSCRIPT
1
2 Marco Teórico
2.1 Procesos
Los procesos, en el mundo moderno, son el patrón de trabajo de la gran
mayoría de las empresas formalmente estructuradas. Los procesos le
aportan a las empresas el poder de conocerse y de ver cómo están
evolucionando. Esto lo logran a través 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 críticas para el
desarrollo de software a la medida es la estimación. Esta macro-actividad
está sujeta a un gran número de variables y que, dependiendo como se
realice, puede obtenerse grandes diferencias del resultado de la ejecución
cada vez que se lleve a cabo. Es por esto que la macro-actividad de
estimación 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 Definición
2
“
Un proceso de negocio es un conjunto de tareas relacionadas
lógicamente 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 función pueda ser aplicada. Cuando una función es aplicada a
las entradas de un método, tendremos ciertas salidas resultantesi”.
2.2 Metodologías Para el Modelamiento De Procesos
2.2.1 IDEF0
La traducción literal de las siglas IDEF es Integration Definition for
Function Modeling (Definición de la integración para la modelización de
las funciones). IDEF consiste en una serie de normas que definen la
metodología para la representación de funciones modelizadas.
Estos modelos consisten en una serie de diagramas jerárquicos junto
con textos y referencias cruzadas entre ambos que se representan
mediante rectángulos o cajas y una serie de flechas. Uno de los
aspectos de IDEF0 más importantes es que como concepto de
modelización va introduciendo gradualmente más y más niveles de
detalle a través de la estructura del modelo. De esta manera, la
comunicación se produce dando al lector un tema bien definido con
una cantidad de información detallada disponible para profundizar en el
modelo.
i http://es.wikipedia.org/wiki/Proceso_de_negocio
3
2.2.2 Bussines Process Modeling Notation
El Business Process Management Initiative fue desarrollado como el
estándar BMPN. La especificación del BPMN 1.0 fue liberada al
público en mayo del 2004. El principal objetivo del BPMN es proveer
una notación 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 técnicos
responsables de la implementación de la tecnología que ejecutará
dichos procesos.
Un diagrama BPM define un diagrama BPD (Diagrama de Procesos de
Negocio), el cual es basado en una técnica de diagrama de flujo que
conduce a la creación de las operaciones de los procesos de negocios
a través de modelos gráficos.
Un BDP está constituido por un conjunto de elementos gráficos, los
cuales permiten el fácil desarrollo de diagramas que serán familiares
para la mayoría de los analistas de negocios. Los elementos que
constituyen el diagrama fueron diseñados para ser distinguibles unos
de otros y utilizan figuras que son familiares para la mayoría de los
modeladores de procesos. Esto enfatiza que uno de los objetivos del
desarrollo de BPMN es crear un simple mecanismo para la creación de
modelos de procesos, mientras que al mismo tiempo pueden manejar
la complejidad inherente en los procesos de negocio. Esta
aproximación permite manejar conflictos entre los requisitos en la
organización y los aspectos de modelamiento de los procesos que
estos generan.
4
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, están 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 información
� Estrategia
Adicionalmente, aunque en los diagramas de BPMN se presentan
mensajes, y la asociación de estos mensajes a artefactos, los
diagramas de BPMN no son diagramas de flujo de datos.
2.2.2.2 Usos de BPMN
La modelación de procesos de negocio es usada para comunicarse
a una gran variedad de audiencias. BPMN es diseñado para cubrir
muchos tipos de modelados y permite la creación de procesos de
negocio de "principio a fin" (end-to-end). La estructura de los
elementos de BPMN permite a los lectores que fácilmente
diferencien las secciones de un diagrama BPMN. Existen
básicamente 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
5
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 (público): Este representa las interacciones entre
un proceso de negocio privado y otros procesos o participantes.
Estas actividades son usadas sólo 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
6
Proceso de Colaboración (global): Este representa la interacción
entre dos o más entidades de negocio. Estas interacciones son
definidas como una secuencia de actividades que representan un
patrón de intercambio de mensajes entre las entidades involucradas.
Un proceso de colaboración puede se mostrado como dos o más
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
7
• Nuevos procesos de negocio
• Procesos de negocios detallados con interacción a una o más
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 creación
de modelos de procesos de negocio, mientras que al mismo tiempo
permita manejar la complejidad inherente a los procesos de
negocio. Esta aproximación entra en conflicto entre sí para organizar
gráficamente.
Existen cuatro categorías básicas para los elementos (Ver ejemplo
de estos elementos en la Tabla 2:
• Objetos de Flujo (Eventos, Actividades, Entradas)
• Objetos de Conexión (Flujo de Secuencia, Flujo de Mensaje,
Asociación)
• Swimlanes (Pools, Lanes)
• Artefactos (Objetos de Datos, Grupos, anotaciones).
Elemento Descripción Símbolo Evento Un evento es algo
que pasa durante la ejecución 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.
8
Actividad Una Actividad es un término genérico para cualquier trabajo que se realice dentro de la compañía. Una actividad puede ser o no atómica. Los tipos de actividades que son parte del modelo de procesos son: Procesos sub.-Procesos Tareas .
Control Una decisión es usada para controlar la divergencia y convergencia de un flujo. Esto determina la ramificación de los hilos y la unión de los caminos.
Tabla 2. Elementos Básicos BPD. Fuente: Introduction to BPM, Stephen A. White, IBM Corporation
2.2.2.5 Procesos
En BPMN un proceso es definido como un gráfico 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
intrínsecamente jerárquico. 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
9
Facilidad para el entendimiento y la Comunicación:
La definición de procesos formales y bien definidos han demostrado
que aumentan dramáticamente el entendimiento de los mismos.
Suficiente Información: Los procesos bien definidos proveen
suficiente información 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 Críticos de Estimación
2.3.1 ¿Qué es una estimación?
En términos generales, una estimación es una predicción de cuánto va
a durar un proyecto o cuánto va a costar. Esto incluye la planeación
asociada que se debe realizar para la inversión de esfuerzo, la
duración en tiempo y los recursos necesarios para llevarlo a cabo. Una
estimación es siempre un cálculo aproximado, realizado con algún tipo
de método, por lo tanto tiene implícito un margen error posible frente al
resultado real sobre lo que se estimó.
De acuerdo con esta definición, para proyectos de software la
estimación se presenta en términos de duración del proyecto, esfuerzo
del personal que integra el desarrollo del proyecto (diferenciados por
roles, como programadores) y otros costos logísticos, como equipos de
cómputo, licencias de software, transporte, entre otros.
A pesar que por definición, la estimación de un proyecto es una
predicción que siempre cuenta con un grado de incertidumbre, en la
industria de software el concepto de estimación en proyectos de
10
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 declaración de un objetivo del negocio.
Ejemplo: “Necesitamos tener lista en Junio la versión 2.0
del sistema X para cumplir con la nueva legislación”
o Un compromiso es una promesa de entregar una
funcionalidad definida, con un nivel específico de calidad,
en una fecha establecida.
2.3.2 Consecuencias de una mala estimación
La mala estimación de un proyecto de software puede traer varias
consecuencias:
• Efectividad reducida de la planeación del proyecto: Las
estimaciones pobres impiden poder realizar planeaciones
efectivas, ya que introducen supuestos erróneos para las
actividades específicas. Esto causa errores en el cálculo del
tamaño del equipo de trabajo, dificulta la coordinación 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 estimación está asociada con una probabilidad de que
ésta sea cierta. Una mala estimación tiene muy bajas
probabilidades de que el proyecto sea finalizado en el tiempo
que se estipula.
11
• Limita el tiempo para realizar fases críticas del ciclo de vida:
Una estimación demasiado baja provoca que el tiempo que
se dedica en las primeras fases, como el análisis de
requerimientos y el diseño, 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
haciéndolas bien desde el principio. Teniendo esto como
consecuencia final, retrasos notables en la duración del
proyecto.
• Prácticas “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 además son poco deseables para los
miembros del grupo de trabajo:
o Frecuentes reuniones con la alta gerencia para discutir
cómo desatrasar el proyecto.
o Frecuentes reestimaciones tardías en el proyecto, sólo
para saber cuándo será terminado definitivamente.
o Disculpas frecuentes ante los clientes por no cumplir
con las fechas comprometidas.
o Creación de versiones no completamente funcionales
para demostrar algún tipo de progreso, pero bajo el
riesgo de evidenciar públicamente problemas de
calidad.
12
o Discusiones frecuentes acerca de los requerimientos
que obligatoriamente deban ser adicionados, porque el
proyecto se ha demorado demasiado.
o Depuración difícil de defectos introducidos por malas
prácticas 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 típicamente
son ejecutados sin prestar mucha atención 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 estrés en los desarrolladores, causado por
cronogramas apretados. Si se puede evitar imponer esta
presión a los desarrolladores a través de una planeación
13
basada con mejores estimaciones, la calidad de los
productos entregados se debe ver incrementada.
• Mejor coordinación con roles no relacionados con software:
Los proyectos de software por lo general deben ser
coordinados con otros roles como pruebas, documentación
técnica, campañas de mercadeo, capacitación, entre otros. Si
el cronograma del proyecto no es confiable, ocasionará que
la planeación de los recursos para estas otras actividades se
vea afectada, lo que incrementará la duración y el costo
global de los proyectos.
• Mejores presupuestos: Estimaciones más exactas ayudan a
realizar mejores presupuestos. Las organizaciones que no
cuentan con buenas estimaciones no pueden predecir con
exactitud el costo de sus proyectos.
• Información 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 estimación que
solo es posible realizarlo en mínimo 6 meses, las
organizaciones tendrán el poder de tomar las decisiones
necesarias para llegar a que las metas del negocio y la
estimaciones proyectadas converjan en algún punto, o por lo
menos, se tenga contabilizado los riesgos en los que se
incurre.
14
2.3.4 Relación entre la Estimación y la Planeación
Crear una estimación precisa y analítica no garantiza que la estimación
sea aceptada ni que el proyecto se planifique de una forma que apoye
el desarrollo eficiente.
Independiente de las técnicas de estimación que se utilicen para
predecir cuánto va a durar un proyecto, en esfuerzo o en tiempo, la
planeación de un proyecto es un factor que afecta enormemente la
ejecución del mismo.
Planear es una actividad que involucra a la gerencia de proyectos,
donde son tomadas las decisiones corporativas, y la estimación
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 estimación de los
proyectos. La estimación de proyectos de software debe ser un
proceso analítico y objetivo, libre del sesgo que introducen los
conceptos de planeación.
2.3.5 Estimaciones de punto-único (single-point)
Cuando se realizan las estimaciones, hay que tener presente que la
estimación es una predicción 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 sensación que la
estimación realizada es exacta (0% de error de desviación). Cuando se
presenta una estimación exacta a los interesados en el proyecto, se les
15
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 estimación de un proyecto,
determinar los rangos de probabilidad de falla o de error que tiene
asociada la estimación, para no establecer supuestos que confundan
las expectativas de finalización del proyecto.
2.3.6 ¿Qué es una buena estimación?
“Una buena estimación es aquella que proporciona una vista lo
suficientemente clara de la realidad de un proyecto, la cual le permita a
sus líderes tomar buenas decisiones acerca de cómo planear y
controlar el proyecto para cumplir con sus metas” [3]
Realizar estimaciones constantemente no asegura que se estén
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 ambigüedades e incertidumbres que se presentan ante la
realización de un proyecto de software a la medida.
La Figura 5 muestra como Boeing mejoró notablemente el error de la
estimación una vez comenzó con la implantación del modelo de
capacidad de madurez (CMM). Cada vez que aumentó de nivel en
CMM, disminuyó su porcentaje de error de la estimación de sus
proyectos.
16
Figura 5. Mejoras en la estimación de proyectos en la Boeing Company.
La previsibilidad de los proyectos mejora dramáticamente 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 estimación
efectuada. Para cada fase del desarrollo del producto, donde éste se
va refinando, la estimación misma se va refinando también,
aumentando el nivel de confiabilidad.
17
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, volviéndose 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 más
elementos tangibles (Definición del producto, Diseño de interfaz
gráfica, diseño detallado), la incertidumbre disminuye, pudiendo así
realizar una estimación con más 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 estimación:
• Proceso de desarrollo caótico
• Requerimientos Inestables
• Actividades o características omitidas
18
• Optimismo infundado: reducción de las estimaciones de los
desarrolladores, frases célebres:
• “Seremos más productivos en este proyecto comparado con
el proyecto anterior”
• “Muchas cosas salieron mal en el anterior proyecto, en este
saldrán menos”.
• “Empezamos el proyecto lentamente y fuimos escalando
nuestra curva de aprendizaje. Aprendimos de la forma dura,
pero todas las lecciones nos permitirán terminar el proyecto
más rápido de lo que lo empezamos”.
• Subjetividad y Sesgo.
• Estimaciones “a vuelo de pájaro”
2.3.9 Influencias en la Estimación de un Proyecto de Software
2.3.9.1 Tamaño
El tamaño del software es uno de los principales clasificadores de
proyectos. Para medir el tamaño de un proyecto de software existen
varios criterios, dentro de los cuales se encuentran:
• Número de líneas de código.
• Número de pantallas.
• Número de Interfaces con otros sistemas.
• Número de casos de uso.
19
En la Figura 7 se ilustra el esfuerzo invertido en meses por el
número de líneas de código que tiene un proyecto. Como se puede
observar, tiene una tasa de crecimiento lineal.
Figura 7. Crecimiento en esfuerzo de un proyecto típico de un sistema de negocio. Calculado usando datos del modelo de estimación Fuente: Computed using data from the Cocomo II
2.3.9.2 Deseconomías de escala
El número de integrantes de un proyecto es otro de los factores que
afectan la estimación de un proyecto. Con el número de integrantes
de un proyecto ocurre un fenómeno contrario a lo que normalmente
se cree. Si se incrementa el número de participantes de un proyecto,
no necesariamente disminuirá la fecha de finalización del proyecto.
Esto se debe básicamente a las desconomías de escalas, las cuales
implican que a mayor número de participantes, los canales de
comunicación aumentan en orden exponencial de estos, dando
20
como trabajo adicional un esfuerzo en la coordinación de todos los
recursos. En la Figura 8 se puede ver gráficamente el aumento del
número de canales a medida que los nodos aumentan.
Figura 8. Las líneas de comunicación crecen proporcionalmente al cuadrado del número 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 varía y
afecta de una manera importante la duración de un proyecto. Por
ejemplo, para los sistemas de aviación, las pruebas son procesos
más extensivos que implican que el tiempo dedicado a estos sea
mayor, comparado con otros tipos de software.
Líneas de Código / Por Mes Hombre
Superior-Inferior (Nominal) Tipos de Software 10,000-LOC
Project 100,000-LOC Project
250,000-LOC Project
21
Aviación 100–1,000 (200)
20–300 (50)
20–200 (40)
Sistemas de Negocio
800–18,000 (3,000)
200–7,000 (600)
100–5,000 (500)
Comando y Control 200–3,000 (500)
50–600 (100)
40–500 (80)
Sistemas Embebidos
100–2,000 (300)
30–500 (70)
20–400 (60)
Sistemas de Cara a Internet
600–10,000 (1,500)
100–2,000 (300)
100–1,500 (200)
Sistemas diseñados para intranets
1,500–18,000 (4,000)
300–7,000 (800)
200–5,000 (600)
Micro código
100–800 (200)
20–200 (40)
20–100 (30)
Control de procesos 500–5,000 (1,000)
100–1,000 (300)
80–900 (200)
Tiempo Real 100–1,500 (200)
20–300 (50)
20–300 (40)
Sistemas Científicos / Investigación de Ingeniería
500–7,500 (1,000)
100–1,500 (300)
80–1,000 (200)
Productos de Software Licenciado
400–5,000 (1,000)
100–1,000 (200)
70–800 (200)
Sistemas de Software / Drivers
200–5,000 (600)
50–1,000 (100)
40–800 (90)
Telecomunicaciones 200–3,000 (600)
50–600 (100)
40–500 (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 líneas de código que se
requiere invertir por cada recurso por mes, para los diferentes tipos
de sistemas. Esta métrica indica que dependiendo del tipo de
sistema a realizar, el nivel de complejidad varía y que es importante
tenerlo en cuenta como un parámetro, al momento de realizar una
estimación.
22
2.3.9.4 Factores del Personal
Las habilidades del personal son otras de las principales influencias
que tiene la estimación 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 calificación
posible, la estimación 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
23
2.3.9.5 Lenguaje de programación
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 estimación de un proyecto si el equipo
de trabajo no cuenta con la suficiente experiencia, dado que afecta
el tiempo esperado en construcción.
También es necesario revisar, dependiendo del tipo de sistema, las
bondades que ofrece el lenguaje seleccionado, ya que los diferentes
lenguajes de programación son enfocados a la productividad,
logrando un objetivo (funcionalidad específica) con un menor
número de líneas de código.
En el entorno de hoy día, es importante resaltar el impacto que
tienes los IDE (Integrated Development Enviroment) en la variación
de la productividad de construcción. Hoy día se encuentran IDEs
que facilitan operaciones tales como, detección de errores,
seguimientos a variables dentro del código, generación y despliegue
del producto, comunicación con otros sistemas, control detallado de
las operaciones realizadas, entre otras, afectando positivamente la
productividad misma.
A medida que las tecnologías han evolucionado, los lenguajes de
programación también lo han hecho y se ha vuelto para los
desarrolladores, mas “fácil” programar en ellos. En la Tabla 4 se
puede observar la comparación de diferentes lenguajes contra el
lenguaje C. En esta tabla podemos observar que mientras en C se
24
realiza una instrucción, en C# podríamos realizar 2.5 instrucciones,
esto es un aumento del 250% de productividad final (en
instrucciones). También podemos ver que en Visual Basic se puede
construir 4.5 veces más rápido (sentencias) que en el lenguaje C.
Esto da pie a considerar que el lenguaje de programación es un
factor importante a tener en cuenta en la estimación 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 programación.
Lenguaje Nivel Relativo al Lenguaje iiiC C 1 to 1 C# 1 to 2.5 C++ 1 to 2.5 Cobol 1 to 1.5 Fortran 95 1 to 2 Java 1 to 2.5 Macro Assembly 2 to 1 Perl 1 to 6 Smalltalk 1 to 6 SQL 1 to 10 Visual Basic 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 técnicas de estimación
2.3.10.1 Contar, calcular y en última instancia, juzgar
Las diferentes técnicas de estimaciones ofrecen las herramientas
necesarias para que se realicen los conteos y cálculos necesarios. iii Lenguaje de programación creado en 1969 por Ken Thompson y Dennis M. Ritchie
25
Sin embargo, no siempre se puede realizar un conteo o un cálculo
que permita estimar el esfuerzo necesario para realizar un proyecto;
siempre existirá la opción de juzgar.
Juzgar es una percepción 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 Calibración y Datos Históricos
La información histórica expresada en indicadores relacionados con
la industria de desarrollo de software constituye el insumo
fundamental de la mayoría de las técnicas de estimación. Por lo
tanto, en la mayoría de las técnicas, la calibración es usada para
convertir lo conteos realizados en estimados. Existen tres tipos de
datos con los cuales se puede calibrar una estimación:
� Datos de Industria: datos de organizaciones que
desarrollan el mismo tipo de software que está siendo
estimado.
� Datos Históricos: Información recolectada dentro de la
organización que desarrollará el proyecto.
� Datos del Proyecto: Indicadores de desempeño
recolectados en las primeras etapas del proyecto y que
deben ser usados para calibrar las siguientes fases.
2.3.10.3 Métricas de Software
26
Los siguientes indicadores proporcionan suficientes datos para
calibrar la mayoría de herramientas comerciales de estimación,
también permiten calcular tasas de productividad sencillas como
número de líneas de código por mes-hombre:
• Tamaño (líneas de código, Puntos de Función o algo que sea
contable, una vez finalizado el proyecto)
• Esfuerzo (dado en meses/persona de personal o la cifra más
cómoda de contabilizar)
• Tiempo (meses calendario)
• Defectos (clasificados por severidad)
2.4 Técnicas Fundamentales
2.4.1 Clasificación de las técnicas de estimación
2.4.1.1 Basadas en Modelos
Son técnicas que poseen un modelo matemático como su punto
clave. Involucran un algoritmo que es derivado la mayoría 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 técnicas de desarrollo de software a ser utilizadas y en el
dominio de la aplicación.
27
2.4.1.3 Orientadas al aprendizaje
Los métodos de estimación de esta categoría van desde las
estimaciones que se realizan manualmente por analogía con
proyectos, hasta las que usan técnicas de inteligencia artificial como
las redes neuronales.
La Tabla 5 presenta ejemplos de técnicas de estimación clasificadas
en estas categorías
Clasificación Técnicas
Basadas en Modelos
SLIM COCOMO 81 Checkpoint SEER
Basadas en Expertos Delphi Rule-Based
Orientadas al aprendizaje Neural Case-based (Estimación por analogía)
Compuestas Composite Bayesian COCOMO II
Tabla 5. Ejemplos de técnicas de estimación clasificadas en estas categorías. 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 técnicas basadas en la experiencia son útiles cuando no se
poseen datos cuantificados. Éstas capturan el conocimiento y la
28
experiencia de las personas con amplio dominio de un área de interés,
las cuales proveen estimaciones basadas en la síntesis de los eventos
conocidos en proyectos anteriores, con los cuales el experto ha estado
asociado o ha participado directamente. La desventaja obvia de estos
métodos es que la estimación sólo es tan buena como lo sea la opinión
del experto, y usualmente no hay forma de probar dicha opinión hasta
que es demasiado tarde para corregir el daño si la opinión fue errada.
Los años de experiencia no necesariamente se convierten en altos
niveles de competencia en estimación. Incluso, el más competente de
los individuos puede simplemente suponer de forma errónea. Algunas
técnicas han sido desarrolladas para capturar el juicio de expertos,
pero también toman medidas para mitigar la posibilidad que el juicio de
un solo experto afecte el resultado. Estas técnicas se conocen como:
• Juicio Experto Individual
• La Técnica Delphi
• WSB.
2.4.3 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 técnica de juicio de expertos estructurado es similar a la técnica
juicios de expertos, solo que en este se define los pasos para realizar
la estimación, para que los expertos los sigan y se obtengan resultados
más controlados.
29
Para crear las estimaciones a nivel de cada tarea, se debe pedir a las
personas que las ejecutan que hagan la estimación de cada una.
Uso de Rangos:
El uso de rangos para la estimación de cada tarea permite que el
estimador se ponga en tres situaciones:
• Probable: cuando todo el ambiente se desenvuelve
normalmente. Esta situación es la que por defecto usan los
estimadores.
• Optimista: Cuando todo sale mejor de lo esperado y dan para
que los tiempos de ejecución de la tarea disminuyan. Estas
circunstancias suelen suceder poco y los estimadores están
predispuestos a dar tiempos en estos escenarios, sin embargo
para el modelo de PERT se hace necesario ponerse en esta
situación optimista.
• Pesimista: Cuando todo sale mal y se generan problemas para
la ejecución 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 estimación por rangos, teniendo en cuenta
las situaciones de optimista, probable y pesimista. También se
ilustra dos esfuerzos
• Esperado 1: Este esfuerzo es calculado con la Ecuación 1
original de PERT.
• Esperados 2: Este esfuerzo es calculado con la Ecuación 1
de PERT, ajustada para estimación de tareas de desarrollo
de software.
30
Tareas Optimista Probable Pesimista Esfuerzo Esperado1
Esfuerzo Esperado2
Tarea 1 0,5 1 1,5 1 1,083333333 Tarea 2 1 1,5 2 1,5 1,583333333 Tarea 3 3 4 5 4 4,166666667 Tarea 4 1 1,5 2,5 1,58333333 1,75 Tarea 5 3 4 5 4 4,166666667 TOTAL 8,5 12 16 12,0833333 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).
Fórmula PERT ivoriginal:
[ ]6
)4Pr( PeorCasoevistoCasoMejorCaso +×+
Ecuación 1. PERT Original. Fuente: Project Manager's PERT/CPM Handbook
Fórmula PERT ajustada:
×+×+
6
)2()3Pr( PeorCasoevistoCasoMejorCaso
Ecuación 2. PERT Ajustada. Fuente: Estimating Software- Intensive Systems
2.4.4 Lista de chequeo
iv Program Evaluating and Review Technique
31
Incluso los expertos en estimación ocasionalmente olvidan considerar
elementos que deberían incluir en una estimación. Así como se
realizan verificaciones de código antes de ser liberado, es necesario
realizar verificaciones a las estimaciones; esto puede realizarse
siguiendo una lista de chequeo. A continuación se presenta un
ejemplo:
• ¿Lo que está siendo estimado está claramente definido?
• ¿La estimación incluye todos los tipos de trabajo necesarios
para completar la tarea?
• ¿La estimación incluye todas las áreas funcionales necesarias
para completar la tarea?
• ¿La estimación 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 estimación fue aprobada por la persona que REALMENTE
hará el trabajo?
• ¿Se asume en la estimación que la productividad será similar a
la alcanzada en asignaciones similares?
• ¿La estimación incluye casos optimistas, pesimistas y
probables?
• ¿Es (o son) el caso optimista, realmente el peor de los casos?
¿Necesita plantearse alguno aún peor?
• ¿El esfuerzo esperado fue calculado apropiadamente a partir de
los casos propuestos?
• ¿Los supuestos en los que se basó la estimación fueron
documentados?
32
• ¿Ha cambiado la situación desde que la estimación fue
preparada?
2.4.5 Comparar los estimados con los resultados
Aplicar las técnicas para evitar las estimaciones de punto único en los
juicios expertos realmente no es suficiente. Una vez obtenidos los
esfuerzos reales tras la ejecución de las tareas estimadas se debe
realizar un análisis que permita comparar cuantitativamente los
resultados reales con los estimados para así tener un parámetro 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 Ecuación 3 para cada tarea.
Ecuación 3. Magnitud del Error Relativo (MRE). Fuente: Estimation: Desmystifying the black art, Steve McConnell
La Tabla 7 presenta el análisis del cálculo de la MRE para el
ejemplo presentado en la tabla 6 luego de haberse ejecutado las
tareas estimadas.
Tareas Optimista Probable Pesimista Esfuerzo Esperado
Resultado MRE Dentro del Rango?
Tarea 1 0,5 1 1,5 1,08333 (1) 1 0% Si Tarea 2 1 1,5 2 1,583 (1.6) 2 20% Si Tarea 3 3 4 5 4,167 (4.2) 4.5 6.6% Si
33
Tarea 4 1 1,5 2,5 1,75 (2) 2 0% Si Tarea 5 3 4 5 4,167 (4.5) 6 25% No TOTAL 8,5 12 16 12,08(13.3) 13.5 80% Si
Promedio 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 Descomposición y Recomposición – WBS (Work Breakdown Structure)
El WBS ha sido un estándar por mucho tiempo en la práctica de
ingeniería para el desarrollo tanto de hardware como software y en
general de cualquier práctica de ingeniería y se trata de la clásica
estrategia de “Divide y vencerás”. El WBS es una forma de organizar
los elementos de un proyecto en una jerarquía que simplifica las tareas
de estimación y el control sobre el proyecto. Ayuda a determinar
exactamente qué costos están siendo estimados. Aún más, si hay
probabilidades asociadas a los costos relacionados con cada elemento
individual de la jerarquía, puede determinarse un valor esperado total
del costo del proyecto desde la visión general [8]. La labor de los
expertos entra en juego en este método en la determinación de las
especificaciones de componentes más útiles dentro de la estructura y
las probabilidades asociadas a cada componente.
Los métodos basados en juicios de expertos son buenos para
proyectos que no tienen precedentes dentro de la empresa, pero se
presentan problemas de calibración entre los juicios y problemas de
escalabilidad para análisis extensivos. Por otro lado, las técnicas
basadas en WBS son buenas para la planeación y control de
proyectos.
34
El WSB de un proyecto de software consiste en dos jerarquías, una
que representa el producto de software como tal, y otra que representa
las actividades necesarias para construir el proyecto [7]. La jerarquía
del producto describe la estructura fundamental del software,
mostrando cómo encajan los diversos componentes en el sistema
general. La jerarquía de actividades indica las actividades que pueden
estar asociadas con un componente de software dado.
Además de ayudar a la estimación, otro de los usos que se le da a la
técnica WBS es la contabilidad de costos. Cada elemento del WBS
puede ser asignado con su propio presupuesto y número de control de
costos, permitiendo al personal reportar la cantidad de tiempo que han
invertido trabajando en una tarea o componente del proyecto; la
información puede ser resumida para propósitos de control del
presupuesto.
Finalmente, si una organización 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 producción de
software. Estos datos pueden ser usados para desarrollar un modelo
de estimación de software ajustado a la propia experiencia y prácticas
de la organización.
2.4.6.1 Ventajas
• Aplicable a proyectos de dominio muy específico
• Inherente a la calibración local
• Puede conllevar a procesos bien documentados.
35
2.4.6.2 Desventajas
• Los estimadores tienden a dar la estimación 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 números, la cual dice que la frecuencia
relativa de un proceso se aproxima cada vez más a la probabilidad
teórica a medida que aumentan el número de experiencias que se
realizan, indica que a mayor historial de información sobre la
estimación de proyectos realizados con un WBS planteado, la
generación de la próxima estimación basada en estos datos estará
más cercana a la verdad que la anterior.
La Tabla 8 presenta una lista de tareas genérica que se puede utilizar
para definir la WBS de un proyecto. La columna de la izquierda lista las
categorías de actividades y las otras columnas listan el tipo de trabajo
realizado en cada categoría. Para utilizarla se combinan los tipos de
trabajo con cada categoría y así obtener tareas tales como
“Crear/Hacer Planeación”, “Administrar Procesos”, “Planear
preparación del personal”. Guías como la Tabla 8, son valiosas para la
metodología WBS, ya que la exactitud de una estimación a realizar
depende de lo detallado que esté la jerarquía de tareas.
WBS genérica para proyectos de software de tamaño pequeños a medianos Categoría Crear
/ Hacer
Planear Administrar Revisar Reprocesar Reporte de Defectos
Administración • • • •
36
General Planeación • • • • Actividades Corporativas
•
Configuración del HardWare /Configuración del Software/ Mantenimiento
• • • • • •
Preparación del personal
• • • •
Procesos Técnicos/ Practicas
• • • • • •
Trabajo en requerimientos
• • • • • •
Coordinación con otros proyectos
• • • •
Cambio de Administración
• • • • • •
Prototipo de interfaces de usuarios
• • • • • •
Trabajo de Arquitectura
• • • • • •
Diseño detallado
• • • • • •
Codificación • • • • • •
Adquisición de Componentes
• • • • • •
Generación Automática
• • • • • •
Integración • • • • • •
Sistema de Pruebas Manuales
• • • • • •
Sistema de pruebas automáticas
• • • • • •
Liberación del Software (interim, alpha, beta, and final releases)
• • • • • •
Documentos (usuarios, documentos, Técnicas)
• • • • • •
Tabla 8. Cuadro de actividades que componen un WBS. Fuente: Discipline for software Engineering
37
2.4.6.3 ¿Cómo hacer una estimación WBS más precisa?
Una de las principales tendencias en la elaboración de estimaciones
usando una WBS es la creación de estimaciones de punto único
(single-point), y por lo tanto la introducción 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, más
probable y peor de los casos. Una vez planteados estos rangos, se
debe aplicar las ecuaciones Ecuación 1 y Ecuación 2 y totalizar los
esfuerzos esperados para cada fórmula y elegir alguno de los
totales bajo criterio de los expertos que realizaron la estimación.
2.4.7 Estimación por Analogía
Esta técnica es generalmente aplicable cuando otros proyectos en el
mismo dominio de aplicación han sido completados. El costo del nuevo
proyecto es estimado por analogía con estos proyectos. McConnell[3],
afirma que los estimados basados en datos históricos recolectados
dentro de la misma organización tienden a ser más precisos que los
estimados basados en reglas empíricas o suposiciones estructuradas.
Sin embargo, no todas las organizaciones tienen suficientes datos
históricos para utilizar satisfactoriamente las técnicas de analogías
como forma de estimación.
Para poder obtener una estimación más exacta utilizando la técnica de
estimación por analogía, es necesario contar con algún tipo de
estructura que de mayor garantía sobre el proceso de estimación. A
38
continuación se enumeran los pasos sugeridos para utilizar este
método:
• Obtenga datos detallados del tamaño, esfuerzo y costos
resultantes de proyectos previos. Si es posible, obtenga la
información descompuesta por características, por categoría del
WBS o por algún otro esquema de descomposición.
• Compare el tamaño del nuevo proyecto, pieza por pieza, con el
anterior proyecto.
• Construya el estimativo del nuevo proyecto con base en un
porcentaje del tamaño 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 Ventajas
• Simple y exacta si la organización repite trabajo similar.
• Las estimaciones están disponibles inmediatamente.
• Promueve la documentación detallada
2.4.7.2 Desventajas
• Puede resultar poco confiable si no se cuenta con
experiencia documentada.
39
• Es bastante difícil establecer las diferencias entre proyectos
debido a la agrupación de los datos históricos y así
establecer la precisión de la estimación.
2.4.8 Estimaciones Basadas en Referencias
Para la mayoría de estimadores resulta complejo determinar el tamaño
de una característica en un proyecto de software. Un conjunto de
técnicas conocidas como “basadas en referencias” ayudan a
determinar el tamaño tomando puntos de referencia.
En una estimación basada en referencias primero se identifica una
referencia que se relacione con lo que realmente se desea estimar y
que es más fácil 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 número de los ítems de la referencia y después
se realiza un cálculo basado en datos históricos para convertir el
conteo de la referencia a la estimación que realmente se desea.
2.4.8.1 Componentes Estándar
Si se desarrollan programas que son de similar arquitectura, puede
usarse esta técnica para estimar el tamaño. Primero deben definirse
los elementos relevantes en los sistemas previos. Típicamente un
sistema puede incluir páginas Web, archivos, tablas, reglas de
negocio, gráficos, pantallas, diálogos, reporte, etc. Luego de tener
identificados cuáles son los componentes estándar, se calcula el
promedio de líneas de código por componente en los proyectos
anteriores. Con base en esto, se puede realizar el cálculo para un
40
nuevo proyecto. El uso de líneas de código en estos casos resulta
mejor que cualquier otra métrica, ya que resulta mucho más fácil
recolectarla para cada tipo de componente en proyectos que ya han
sido finalizados.
2.4.8.2 Lógica Difusa
Consiste en clasificar las características requeridas para un proyecto
de software en cinco tamaños: Muy pequeña, pequeña, mediana,
grande y muy grande. Se realiza el conteo de características por
cada categoría y luego se calcula el esfuerzo con base en datos
históricos. La Tabla 9 muestra un ejemplo de estimación del tamaño
de un proyecto usando lógica difusa:
Tamaño Promedio LOC
por Categoría Número de Características
LOC estimadas
Muy pequeña
127 22 2,794
Pequeña 253 15 3,795 Mediana 500 10 5,000 Grande 1,014 30 30,420 Muy Grande 1,998 27 53,946 TOTAL - 104 95,955
Tabla 9. Estimación de tamaño usando lógica difusa. %. Fuente Estimation: Desmystifying the black art, Steve McConnell
2.4.8.3 Tallaje de Camisetas
Esta técnica es similar a la lógica difusa. Se asignan tallas (XS, S,
M, L, XL) a las diferentes características de un proyecto y se
relacionan éstas con datos históricos para estimar el tamaño en
líneas de código. Esta técnica resulta útil para ilustrar a los actores
41
no técnicos de un proyecto sobre la complejidad de cada
característica y posiblemente darle también una valoración, usando
la misma escala del valor agregado que da cada característica. De
este modo los actores del negocio pueden decidir si vale la pena el
esfuerzo que se invertiría 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 estimación si estas se realizan de manera
estructurada. Para obtener resultados adecuados en una estimación
por revisiones grupales, se deben seguir las siguientes reglas:
• Haga que cada miembro del equipo estime las piezas del
proyecto individualmente, luego reúnalos para comparar las
diferencias. Trabajar hasta que se alcance un consenso en
los rangos de estimación
• 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 técnicas.
42
Figura 10. MRE(Individuales) = 55% MRE(Grupales) = 30%. Fuente Estimation: Desmystifying the black art, Steve McConnell
2.4.9.2 Wideband Delphi
La técnica Delphi fue elaborada en la Rand Corporation a finales de
los años 40, originalmente como una forma de realizar predicciones
acerca de futuros eventos. Más recientemente, la técnica ha sido
usada como una forma de guiar a un grupo de individuos hacia un
consenso de opinión sobre un problema. Se solicita a los
participantes que hagan una afirmación 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 afirmación sobre el problema, pero en
esta ocasión conociendo lo que hicieron los otros participantes en la
43
primera ronda. La segunda ronda usualmente resulta en un
estrechamiento del rango en las afirmaciones del grupo,
acercándose a un punto medio respecto al problema en cuestión. La
técnica original evitaba la discusión grupal; la técnica Wideband
Delphi [7] incluye la discusión grupal entre las rondas. Esta es una
técnica útil para llegar a alguna conclusión cuando la única
información disponible está basada más en la opinión de expertos
que en datos históricos.
El procedimiento del método Delphi se describe a continuación:
1. El coordinador de Delphi presenta a cada estimador un
formato de la estimación.
2. Los estimadores preparan estimaciones iniciales
individualmente. (Opcionalmente, este paso se puede realizar
después del paso 3.)
3. El coordinador convoca una reunión de grupo en la cual los
estimadores discuten las valoraciones realizadas.
4. Si el grupo conviene en una sola estimación sin mucha
discusión, el coordinador asigna a alguien como “abogado del
diablo”.
5. Los estimadores dan sus estimaciones individuales al
coordinador, de forma anónima.
6. El coordinador prepara un resumen de las estimaciones una
forma de iteración y presenta el resultado de la iteración a los
estimadores, de modo que puedan ver cómo sus
estimaciones se comparan con las estimaciones de otros.
7. El coordinador realiza una reunión con los estimadores para
discutir variaciones en sus estimaciones.
8. Los estimadores votan anónimamente si desean aceptar la
estimación media. Si alguno de ellos vota “no,” vuelven al
paso 3.
44
La efectividad de la técnica Delphi se puede apreciar en la Figura 11
Figura 11. Tiene un mejor MRE en 8 de cada 10 casos. Fuente: Estimation: Desmystifying the black art, Steve McConnell
Ventajas
• Efectiva para sistemas poco familiares a la organización.
• Útil cuando deben involucrarse personas de diversas
disciplinas en el proyecto.
Desventajas
• Requiere de varias reuniones haciendo costoso el proceso de
estimación.
• No es apropiada para estimar tareas detalladas.
2.4.10 Modelos de Estimación COCOMO
45
2.4.10.1 COCOMO 81 [1]
Barry Boehm, en [7], introduce una jerarquía de modelos de
estimación de software con el nombre de COCOMO (Constructive
Cost Model - COCOMO) Modelo Constructivo de Costeo. La
jerarquía de modelos de Boehm está constituida por las siguientes
categorías:
• Modelo Básico: Se calcula el esfuerzo del desarrollo de
software en función del tamaño del programa, expresado en
las líneas estimadas de código (SLOC).
• Modelo Intermedio: Se calcula el esfuerzo en función del
tamaño del programa y de un conjunto de "conductores de
coste" que incluyen la evaluación subjetiva del producto, del
hardware, del personal y de los atributos del proyecto.
• Modelo Avanzado: Incorpora todas las características de la
versión intermedia y lleva a cabo una evaluación del impacto
de los conductores de coste en cada fase (análisis, diseño,
etc.) del proceso de Ingeniería de Software.
Los modelos COCOMO están definidos para tres tipos de proyectos
de software:
• Orgánicos: Proyectos que son relativamente pequeños y
sencillos en los que trabajan equipos con pocas personas,
con buena experiencia, sobre un conjunto de requisitos poco
rígidos.
46
• Semiacoplados: Proyectos de software intermedios en
tamaño y complejidad, en los que equipos con variados
niveles de experiencia, deben satisfacer requisitos poco o
medianamente rígidos.
• Empotrados: Son proyectos que deben ser desarrollados en
un conjunto de hardware, software y restricciones operativas
muy restringidos.
Las ecuaciones COCOMO básico 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 cronológicos y KLDC es el número estimado
de líneas de código (en miles) para el proyecto. Los coeficientes ai y
ci y los exponentes bi y di se muestran en la Tabla 10
Proyecto de software
ai Bi ci di
Orgánico 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
47
Tabla 10. Coeficientes para cálculo de esfuerzo y duración del modelo COCOMO. Fuente: Cost Models For Future Software life
Cycle Processes: COCOMO 2.0
El modelo se amplía para considerar un conjunto de "atributos,
conductores de coste" que pueden agruparse en cuatro categorías
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 evaluación, 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 típicos para el FAE varían de 0,9 a
1,4.
La ecuación entonces del modelo COCOMO toma la forma:
FAEKDLCa Eib
i××=
Donde E es el esfuerzo aplicado en meses-hombre y LDC es el
número estimado de líneas de código. Los valores para el
coeficiente ai y el exponente bi se muestran en la Tabla 11.
Proyecto de
Software ai bi
Orgánico 3,2 1,05
Semiacoplado 3,0 1,12
Empotrado 2,8 1,2
Tabla 11. Coeficientes de la fórmula de ajuste para el modelo COCOMO 81. Cost Models For Future Software life Cycle
Processes: COCOMO 2.0
48
2.4.10.2 COCOMO II [4]
El principal problema con el modelo COCOMO 81 es que las
técnicas modernas de Ingeniería de Software volvieron obsoletas la
terminología usada por éste y, más importante aún, sus conceptos
fundamentales. Por ejemplo, el uso de modelos de desarrollo
iterativo hace que la definición 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 clasificación de proyectos como Orgánicos, Empotrados y
Semiacoplados ha sido reemplazada con 5 parámetros:
Precedencia, Flexibilidad del Desarrollo, arquitectura o Riesgo de
Resolución, Cohesión del Equipo y Madurez del Proceso tomando
así en cuenta factores más relevantes, los proyectos modernos,
permitiendo una afinación más detallada de los exponentes y los
coeficientes de las fórmulas.
El modelo COCOMO II[15] emplea una jerarquía de modelos en la
siguiente forma: Composición de Aplicación, Diseño Temprano y
Pos-Arquitectura, en lugar de los modelos básicos, intermedios y
avanzados, diferenciando así las diferentes etapas del proyecto en
las cuales cada uno de los modelos sería más adecuado. El modelo
Composición de Aplicación también permite que técnicas actuales
como la del uso de prototipos de interfaz (GUI) sean tenidas en
cuenta.
Este método representa un avance frente a su predecesor respecto
al tema de la medición del tamaño de los proyectos. El número de
líneas de código no es útil cuando se utilizan lenguajes de
49
programación visuales y el cálculo por puntos de función 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
módulos desarrollados en un lenguaje de tercera generación que
hacen parte de la aplicación, al que cada uno se le asigna uno de
tres factores de complejidad (simple, medio, difícil). Para el propósito
de COCOMO II esta métrica fue renombrada como "Puntos de
Aplicación".
Ventajas de los modelos COCOMO:
• Altamente soportados por la industria.
• Recopilan y están calibrados con información histórica de
varios años atrás.
• 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 estimación.
• Son difíciles de calibrar con datos de la organización.
• Exige muchos datos de ajuste donde se introducen valores
de calificación subjetiva que pueden sesgar la estimación si
son ingresados por un estimador inexperto.
2.4.11 Modelo de Estimación de Putnam
El modelo de Putnam al igual que los modelos COCOMO, es un
modelo empírico de estimación de esfuerzo en proyectos software. Lo
50
cual quiere decir que trabaja con datos recolectados de proyectos (por
ejemplo, esfuerzo y tamaño) y ajustándolos a una curva estadística.
Las estimaciones futuras de esfuerzo son hechas proporcionando el
tamaño y calculando el esfuerzo asociado usando la ecuación
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 tamaño
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 compañía
QSM, Inc.
Mientras gerenciaba proyectos de investigación y desarrollo para el
ejército de Estados Unidos y luego para General Electrics, Putnam
notó que los perfiles de asignación de recursos para proyectos de
software seguían la distribución Rayleigh. Putnam usó estas
observaciones acerca de los niveles de productividad para derivar la
siguiente ecuación:
Ecuación 4. Ecuación de Software Modelo de Putnam. Fuente http://en.wikipedia.org/wiki/Putnam_model
Donde:
51
Tamaño: Es el tamaño del producto. Putnam usa líneas de código para
la medición del tamaño, sin embargo se puede usar la métrica más
adecuada para medirlo en la organización.
El término β, es un escalar y está en función del tamaño
Productividad: es la productividad del proceso en una organización de
desarrollo en particular a una tasa de defectos generados específica.
Esfuerzo es el total de esfuerzo aplicado al proyecto, en años/hombre.
Tiempo es el calendario total de implementación, dado en años.
En términos prácticos, para estimar una tarea de software la ecuación
se resuelve de la siguiente forma:
Ecuación 5. Ecuación del Esfuerzo Modelo Putman. http://en.wikipedia.org/wiki/Putnam_model
Este método de estimación es bastante sensible y ajustable a la
incertidumbre relacionada con el tamaño y la productividad del
proceso. Su creador recomienda que la productividad sea siempre
calibrada a la realidad de la organización 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 métodos que mayor exactitud presenta frente al resto.
Es uno de los pocos modelos de estimación que tiene presente la
incertidumbre dentro de sus cálculos.
52
2.4.11.2 Desventajas
Es un modelo comercial y existe poca documentación disponible
para utilizarlo de forma manual.
2.4.12 Herramientas de Software de Estimación
El uso de herramientas de software de estimación resulta conveniente,
ya que introduce el concepto de la “ciencia de la estimación” dentro de
los proyectos de Software. Dichas herramientas permiten realizar
cálculos que son difíciles de hacer a mano y que tienden a realizarse
con errores, incluso utilizando calculadoras sofisticadas u hojas de
cálculo. Adicionalmente, las herramientas de software de estimación
suelen estar soportadas por datos históricos de la industria, que
permiten calibrar el proceso, además de la capacidad que tienen para
ser calibradas con datos de la organización o el proyecto en curso.
2.4.12.1 Cosas que no se pueden hacer manualmente
Simular los posibles resultados de un proyecto:
53
Figura 12. Simulación de los posibles resultados de un proyecto usando la simulación Monte Carlo. Fuente: Imagen extraída de la
herramienta Construx Estimate
La herramienta de estimación toma en cuenta varias fuentes de
variabilidad:
• Variación en la productividad.
• Variación en el tamaño del proyecto.
• Variación en las tasas de productividad/staff
La Figura 12 muestra un diagrama de dispersión el cual es el
resultado de la ejecución de la técnica de simulación Monte Carlo,
con la cual se obtienen 1000 posibles resultados modificando
aleatoriamente estas tres categorías de variables. La herramienta de
estimación usada utiliza como base los modelos de estimación
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.
• Análisis de probabilidad: Las herramientas de estimación de
software pueden brindar una gráfica de probabilidad como la
presentada en la Figura 13, en la cual se puede leer
54
claramente la relación entre el esfuerzo estimado y la
probabilidad de que esta estimación resulte exacta.
Figura 13. Análisis de probabilidad respecto al esfuerzo estimado Fuente: Imagen extraída de la herramienta Construx Estimate
• Ajustar la estimación a las deseconomías de escala: Los
modelos matemáticos contenidos en las herramientas
incluyen factores de ajuste, acorde con este criterio.
• Ajustar la estimación a requerimientos inestables: De acuerdo
con los datos de calibración y el punto en que se encuentre el
proyecto respecto al cono de la incertidumbre, las
herramientas de estimación ajustan las estimaciones.
• Estimación de aspectos poco comunes: Las herramientas
contabilizan actividades poco estimadas y costeadas, como
son la gerencia de proyecto, el proceso de calidad,
55
elaboración de la documentación, etc.
Cálculo de opciones de planeación e integración con herramientas
de planeación.
• Análisis “¿Qué pasa si…?”: Por medio del uso de
herramientas de estimación es posible ajustar rápidamente
los datos de entrada o supuestos del proyecto y obtener una
vista previa de cómo resulta la estimación si se cambian los
parámetros.
• Arbitrar expectativas poco realistas: Es usual que el cliente o
un gerente de proyecto debata la estimación argumentando
metas del negocio. La simulación presentada en la Figura 12,
muestra qué población de resultados tienen menos
probabilidades de ser ciertas. Presentando el análisis
arrojado por el gráfico, 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 estimación: Es posible realizar el análisis del
impacto que se introduce al modificar los supuestos iniciales;
uno de los más comunes es la suposición que se hace bajo la
teoría de que adicionar más recursos a un proyecto
disminuye su duración. La Figura 14 muestra el cálculo del
efecto en el cronograma que tendría incrementar el esfuerzo
invertido. Sin embargo, respecto a este aspecto siempre hay
que tener en cuenta la influencia de las deseconomías de
escala al momento de introducir una nueva persona a un
proyecto.
56
Figura 14. Análisis del efecto en duración al incrementar el esfuerzo. Fuente: Imagen extraída de la herramienta Construx Estimate
• Estimar proyectos grandes: La estimación de proyectos
grandes resulta complicada por medio de técnicas manuales
y se tiende siempre a inexactitudes. Las herramientas de
estimación ayudan a procesar mejor la información con la
que se cuenta para estimar y permite que el resultado del
proceso sea más exacto.
2.4.13 Uso de Múltiples Técnicas
Una de las mejores prácticas es utilizar múltiples técnicas de
estimación y buscar convergencia o dispersión entre estimaciones
resultantes. La convergencia indica que probablemente se tiene una
buena estimación y la dispersión indica que probablemente se
obviaron factores. La Figura 15 presenta los resultados obtenidos por
varios métodos de estimación.
57
Figura 15. Comparación de resultados de diferentes técnicas de estimación. Fuente: Estimation: Desmystifying the black art, Steve
McConnell
2.5 Flujo de una buena estimación
En proyectos pobremente estimados, la estimación se enfoca directamente
en estimar el costo, el esfuerzo y el cronograma, con poco o sin ningún
interés en estimar el tamaño del software que será construido. En un
proyecto bien estimado, el foco de la estimación y las reestimaciones que se
realizan en el transcurso de éste es diferente.
Dentro de un buen proceso de estimación, el principal factor que debe ser
estimado es el tamaño. El esfuerzo debe ser calculado a partir del tamaño
estimado del proyecto usando datos históricos. El costo y el cronograma del
proyecto son calculados a partir del esfuerzo estimado. La Figura 16
muestra este flujo.
58
Figura 16. Flujo de un buen proceso de estimación. Fuente:
Estimation: Desmystifying the black art, Steve McConnell
2.5.1 Consideraciones para la estimación del tamaño
2.5.1.1 Técnicas de medición del tamaño
Existen diversas técnicas para la estimación o medición del tamaño
de un proyecto de software. Entre ellas están:
• Características
• Historias de Usuarios
• Puntos de Historias
• Requisitos
• Casos de Uso
• Puntos de Casos de Uso
• Puntos de Función
• Formularios
• Componentes de Interfaz Gráfica
• Tablas de base de datos
• Definición de interfaces con otros sistemas
• Clases
59
• Funciones / Sub-Rutinas
• Líneas de Código
Las dos técnicas que mayor acogida poseen actualmente son la
medición del tamaño por líneas de código y el análisis por puntos de
función. Otra técnica que tiene bastante acogida también es la de
puntos de casos de uso, debido al creciente uso del modelamiento
de requisitos con este tipo de diagramas dentro de las metodologías
de desarrollo modernas.
2.5.1.2 Estimación del Tamaño por LOC
El uso de las líneas de código como parámetro para medir el
tamaño es un tema controversial dentro de la comunidad de la
Ingeniería de Software. He aquí algunas ventajas y desventajas:
Ventajas:
• Los datos históricos de las LOC de proyectos anteriores se
pueden recolectar automáticamente con herramientas.
• Datos históricos de muchas organizaciones se encuentran en
términos de LOC
• Métricas en LOC permiten la comparación entre proyectos y
la estimación basada en datos históricos.
• La mayoría de las herramientas de estimación basan el
cálculo del esfuerzo y del cronograma en las LOC.
Desventajas:
60
• Modelos simplistas como “LOC por mes/staff” son tendientes
al error debido a las deseconomías de escala y a las
diferencias en métricas de productividad para diferentes tipos
de software.
• Las LOC no pueden ser usadas como la base para la
estimación de tareas individuales, debido a las diferencias en
productividad entre diferentes programadores.
• Un proyecto que requiera una mayor complejidad en el
código que los proyectos usados para calibrar los supuestos
de productividad, puede afectar la exactitud de la estimación.
• 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
programación diferente al medido por los datos históricos, no
puede usar éstos como base para la calibración.
• Usar la medida de LOC como base para estimar el esfuerzo
en requerimientos, diseño y otras actividades no relacionadas
con la codificación, parece no intuitivo.
• Las LOC son difíciles de estimar directamente y deben
normalmente ser estimadas por referencia (Ver Estimaciones
Basadas en Referencias ).
• La definición de lo que constituye una línea de código debe
ser detallado y documentado para evitar problemas.
El debate respecto al uso de las líneas de código para la medición
del tamaño se concentra principalmente alrededor del concepto de
que la Ingeniería de Software tiene demasiadas complejidades
asociadas para reducir sus indicadores a una sola medida. Sin
embargo, las líneas de código son el principal caballo de batalla
entre las técnicas para registrar la historia de anteriores proyectos y
61
las estimaciones tempranas de los nuevos. Conservando un manejo
consistente en la recolección de esta métrica es un activo valioso y
fácilmente mantenible para la calibración del modelo de la
estimación dentro de una organización
2.5.1.3 Estimación del Tamaño por Puntos de Función (FP)
Una alternativa a la métrica LOC es el uso de puntos de función. Un
punto de función es una medida del tamaño del programa en
función de las características que deben ser implementadas
(Albrecht 1979). Los puntos de función son más fáciles de calcular
de una especificación de requisitos que estimar las líneas del
código, y proporcionan una base para calcular el tamaño en líneas
del código. Existen diversos métodos para calcular los puntos de
función. El estándar para el conteo de puntos de función es
mantenido por el Grupo de Usuarios Internacional de puntos de
función (IFPUG) y se puede encontrar en su sitio Web en
www.ifpug.org. El número de los puntos de función en un programa
se basa en el número y la complejidad de cada uno de los puntos
siguientes:
Las entradas externas: Pantallas, formas, cajas de diálogo, o las
señales de control a través 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 lógica
de proceso única.
Salidas externas: Pantallas, informes, gráficos, o señales de control
que el programa genera para uso del usuario final o de otro
62
programa. Incluyen cualquier salida que tenga un diverso formato o
requiera una diversa lógica 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 lógicos internos: Grupos lógicos importantes de los datos
del usuario final o de la información de control que son controlados
totalmente por el programa. Un archivo lógico 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 información.
La Tabla 12 muestra cómo se realiza el conteo de los puntos de
función y los multiplicadores asociados con cada complejidad. La
cifra resultante se conoce como “conteo de puntos de función
desajustado”.
Puntos de Función Características del programa
Complejidad Baja
Complejidad Media
Complejidad Alta
Desajuste
Entradas externas
_A_ × 3 _B_ × 4 _C_ × 6 Sumatoria del total de entradas externas
Salidas Externas _A_ × 4 _B_ × 5 _C_ × 7 Sumatoria del total de salidas externas
Queries Externas _A_ × 3 _B_× 4 _C_ × 6 Sumatoria del total de Queries Externas
Archivos Lógicos internos
_A_ × 4 _B_ × 10 _C_ × 15 Sumatoria del total de Archivos Lógicos Internos
63
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 función. Fuente: Puntos por Función. Una métrica estándar para establecer el
tamaño del software.
Ventajas:
Permiten tener una estimación temprana bastante exacta del
tamaño del proyecto.
Desventajas:
Obliga realizar una revisión exhaustiva de los requerimientos y
literalmente contar cada entrada, salida, archivo, etc.
2.5.1.4 Cálculo de Puntos de Función Ajustados
La técnica de Puntos de Función incluye un paso de ajuste que
puede resultar opcional, de acuerdo con el criterio de las personas
que realizan las estimaciones dentro de la organización. Ésta etapa
de la técnica consiste en la valoración de catorce factores que
completan la visión externa de la aplicación; en otras palabras,
valoran el conjunto de características del sistema que no hacen
parte de la especificación 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 técnica de estimación, la subjetividad es un
factor presente también en los puntos de función; el uso de los
factores de ajuste introduce esta subjetividad a la estimación del
64
tamaño del proyecto. Por lo tanto, estos factores, si se decide
ajustar el conteo de puntos de función, 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 o sobre estimaciones
innecesarias.
A continuación se presenta una descripción de cada factor y cómo
pueden ser evaluados:
Factor 1. Comunicación de Datos:
Los datos usados en el sistema se envían o reciben por líneas de
comunicaciones. Aunque los avances en las telecomunicaciones
han logrado que el desarrollo de la mayoría de proyectos se
abstraiga del problema de la transmisión de datos, hay ciertos
aspectos que deben ser tenidos en cuenta.
Valoración:
0: Sistema aislado del exterior
1: En lotes, usa periféricos de entrada o salida remotos
2: En lotes, usa periféricos de entrada o salida remotos
3: Captura de datos en línea 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:
65
Existen procesos o datos distribuidos, y el control de estos forma
parte del sistema.
Valoración:
0: Sistema totalmente centralizado
1: Sistema realiza procesos en un equipo, salidas usadas vía
Software por otros equipos
2: Sistema captura, los trata en otro
3: Proceso distribuido, transacciones de una sola dirección.
4: ídem, transferencia en ambas direcciones.
5: procesos cooperantes ejecutándose en distintos equipos.
Factor 3. Objetivos de Rendimiento.
Si el rendimiento es un requisito del sistema, es decir, es crítico,
algún factor como tiempo de respuesta o cantidad de operaciones
por hora, se tendrá que hacer consideraciones especiales durante el
diseño, codificación y mantenimiento.
Valoración:
0: Rendimiento normal (no se da énfasis )
1: Se indican requisitos, no medida especial.
2: Crítico en algunos momentos. Procesos acabados antes de
próxima sesión de trabajo.
3: Tiempo de respuesta es crítico.
4: El proyecto requiere en diseño hacer análisis de rendimiento en
tiempo respuesta o cantidad operaciones/hora
66
5: El proyecto requiere el uso de herramientas para alcanzar el
rendimiento demandado por el usuario
Factor 4. Configuración de Explotación 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 diseño.
Valoración:
0: No se indican restricciones
1: Existen las restricciones usuales
2: Características de seguridad o tiempos.
3: Restricciones en algún procesador
4: El sistema deberá funcionar con restricciones de uso en algún
procesador.
5: Restricciones especiales para aplicación 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 diseño, codificación e
instalación.
Valoración:
0: No se prevén picos
67
1: Se prevén picos poco frecuentes (mensual)
2: Se prevén picos semanales
3: Se prevén horas punta, diarias
4: Tasa de transacciones tan elevada que en diseño se hace
análisis de rendimiento
5: Análisis de rendimiento en diseño, implementación e instalación.
Factor 6. Entrada de Datos en Línea.
La entrada de datos será directa desde el usuario a la aplicación, de
forma interactiva.
Valoración:
0: Todo es en lote
1: 1%<entradas interactivas <7%
2: 8%<entradas interactivas <15%
3: 16%<entradas interactivas <23%
4: 24%<entradas interactivas <30%
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 diseñar e implementar la aplicación con interfaces fáciles
de usar y con ayudas integradas.
Valoración:
0: No se da énfasis al tema
68
1: 1 a 3 de los factores
2: 4 a 5 de los factores
3: 6 ó más factores, sin requerir eficiencia
4: El proyecto cuenta con requerimientos que implican estudio de los
factores humanos en el diseño
5: En el proyecto se demandan prototipos y herramientas para
verificar que se alcanzarán los objetivos
Factor 8. Actualizaciones en Línea.
Los archivos maestros y las Bases de Datos son modificadas
directamente de forma interactiva.
Valoración:
0: No hay
1: De 1 a 3 archivos con información de control. Cantidad baja y
archivos recuperables
2: 4 ó más Archivos de control
3: Actualización de archivos importantes
4: El proyecto define como esencial la protección ante pérdidas
5: Gran cantidad de actualizaciones interactivas. Sistemas de
recuperación muy automatizados
Factor 9. Lógica de Proceso Interno Compleja.
La complejidad interna en un proceso está en función de las
siguientes características:
69
• Especificados algoritmos matemáticos complejos.
• Proceso con lógica compleja.
• Se han especificado muchas excepciones, consecuencia de
transacciones incompletas, que deberán tratarse.
• Manejar múltiples dispositivos de entrada/salida.
• Se incorporaran sistemas de seguridad y control.
Valoración:
0: Ninguna de las características
1: 1 Característica
2: 2 Características
...
5: Las 5 características
Factor 10. Reutilización del Código.
Se tendrá que hacer consideraciones especiales durante el diseño,
codificación y mantenimiento para que el código se reutilice en otras
aplicaciones o lugares.
Se habla de reutilización en los siguientes entornos:
• Dentro de la propia aplicación.
• Por varios sistemas
• Parametrizable.
Valoración:
70
0: No se prevé
1: Reutilizar código en la misma aplicación
2: Menos de un 10% de la aplicación tiene en cuenta las
necesidades de + de 1 usuario
3: El 10 % o más ...
4: Aplicación preparada para ser reutilizable. Nivel de código
5: Aplicación preparada para ser reutilizable. Por medio de
parámetros
Factor 11. Contempla la Conversión e Instalación.
Se proveerán facilidades de conversión en el sistema, se tendrá que
hacer consideraciones especiales durante el diseño, codificación y
pruebas para que la conversión del sistema antiguo sean fáciles de
realizar durante la puesta en marcha del sistema nuevo.
Valoración:
0: No se requiere conversión.
1: Se solicita facilidad de instalación
2: Se solicitan procesos de conversión e instalación, no importantes
para el proyecto
3: Se solicitan procesos de conversión e instalación importantes
para el proyecto
4: 2, y herramientas conversión e instalación
5: 3, y herramientas conversión e instalación. Sistema crítico para la
empresa
Factor 12. Facilidad de Operación.
71
Operación del sistema: los trabajos asignados al centro de proceso
de datos:
• Arranque
• Detención
• Recuperación ante fallos
• Copias de seguridad
• Minimización de las actividades manuales en el CPD.
Se valora cuando ha sido descrita desde las primeras fases,
dedicándose especial atención durante el diseño, codificación y
pruebas.
Valoración:
0: Nada, solamente back-up
1 a 4: Suma de ítems:
• Arranque, back-up y recuperación
• Ídem, sin intervención operador ( X2 )
• Minimizar necesidad de dispositivos externos de
almacenamiento.
• Minimiza necesidad de manejar papel
5: Sistema automático sin intervención humana
Factor 13. Instalaciones Múltiples
El sistema ha de incluir los requerimientos de diversas empresas o
departamentos en donde se ejecutará (incluso plataformas). Estas
72
características estarán presentes durante el diseño, codificación y
pruebas.
Valoración:
0: 1 solo lugar
1: Múltiples lugares, mismo Hardware y Software
2: En diseño se tiene en cuenta el caso (1)
3: En diseño se tiene en cuenta múltiples 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 diseño,
codificación y mantenimiento para que en el sistema sea fácil de
introducir cambios y fácil de adaptar al usuario.
Ítems a tener en cuenta:
• Consultas flexibles del usuario:
o Simples, con condiciones lógicas And/Or que implican
un único archivo lógico (A.L.)
o Medias, con condiciones lógicas sobre más de 1 A.L.
(x2)
o Complejas, con condiciones lógicas complejas que
afectan a varios A.L. (x3)
• Parámetros de la aplicación con tablas ajenas al código:
o El cambio se hace efectivo al arrancar el sistema
73
o El cambio es interactivo (x2)
Valoración:
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 fórmula para
calcular los puntos de función ajustados:
PFA = PFSA * (0,65 + (0.01 * FA))
Donde:
PFA: Puntos de función ajustados
PFSA: Puntos de función sin ajustar
FA: Factor de ajuste. Obtenido realizando la sumatoria de las
valoraciones de todos los factores de ajuste.
2.5.1.5 Conversión de puntos de función a líneas de código
Con base en datos promedio de la industria, es posible realizar un
cálculo del número de líneas de código a partir de los puntos de
función para un conjunto de lenguajes de programación.
74
Es apropiado tener una métrica relacionada con las líneas de código
resultantes por cada punto de función en los proyectos realizados a
través del tiempo, en cada organización
Programación de Sentencias por Puntos de Función
Lenguaje Mínimo (Menos una desviación estándar)
Moda (Mayor Valor Común)
Máximo (mas una desviación estándar)
Ada 83 45 80 125 Ada 95 30 50 70 C 60 128 170 C# 40 55 80 C++ 40 55 140 Cobol 65 107 150 Fortran 90 45 80 125 Fortran 95 30 71 100 Java 40 55 80 Macro Assembly
130 213 300
Perl 10 20 30 Second generation default (Fortran 77, Cobol, Pascal, etc.)
65 107 160
Smalltalk 10 20 40 SQL 7 13 15 Microsoft Visual Basic
15 32 41
Tabla 13. Promedios de la Industria de líneas de código por punto de función. Adaptada de: software Costs(1998), Software Cost Estimation with Cocomo II(Boehm 200), y estimate Software
Intensive Systems(Stutzke 1995).
2.5.1.6 Estimación del Tamaño por Puntos de Casos de Uso
75
La estimación mediante el análisis de Puntos de Casos de Uso es
un método propuesto originalmente por Gustav Karner, y
posteriormente refinado por muchos otros autores. Se trata de un
método de estimación del tiempo de desarrollo de un proyecto
mediante la asignación de "pesos" a un cierto número de factores
que lo afectan, para finalmente contabilizar el tiempo total estimado
para el proyecto a partir de esos factores. A continuación, se
detallan los pasos a seguir para la aplicación de este método.
El primer paso para la estimación consiste en el cálculo de los
Puntos de Casos de Uso sin ajustar. Este valor, se calcula a partir
de la siguiente ecuación:
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 análisis 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 interactúa con el sistema.
Los criterios se muestran en la Tabla 14.
Tipo de Actor
Descripción Factor de Peso
76
Simple Otro sistema que interactúa con el sistema a desarrollar mediante una interfaz de programación (API, Application Programming Interface)
1
Medio Otro sistema que interactúa con el sistema a desarrollar mediante un protocolo o una interfaz basada en texto.
2
Complejo Una persona que interactúa con el sistema mediante una interfaz gráfica.
3
Tabla 14. Criterios de peso para la clasificación de actores en UCP. Fuente: Métricas de Estimación de Tamaño Puntos de Casos de
Uso, Sigifredo E. Bandai Hernández (2002)
Factor de Peso de los Casos de Uso sin ajustar (UUCW)
Este valor se calcula mediante un análisis 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 transacción se entiende como una secuencia de actividades
atómica, es decir, se efectúa la secuencia de actividades completa,
o no se efectúa ninguna de las actividades de la secuencia. Los
criterios se muestran en la Tabla 15:
Tipo de Caso de
Uso
Descripción Factor de Peso
Simple El Caso de Uso contiene de 1 a 3 transacciones
5
Medio El Caso de Uso contiene de 4 a 7 transacciones
10
Complejo El Caso de Uso contiene más de 8 transacciones
15
77
Tabla 15. Criterios de peso para la clasificación de casos de uso en UCP. Fuente: Métricas de Estimación de Tamaño Puntos de Casos
de Uso, Sigifredo E. Bandai Hernández (2002)
Cálculo 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 ecuación:
EFTCFUUCPUCP ××=
Donde,
UCP: Puntos de Casos de Uso ajustados
UUCP: Puntos de Casos de Uso sin ajustar
TCF: Factor de complejidad técnica
EF: Factor de ambiente
Factor de complejidad técnica (TCF)
Este coeficiente se calcula mediante la cuantificación de un conjunto
de factores que determinan la complejidad técnica 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 Descripción Peso
T1 Sistema distribuido 2 T2 Objetivos de rendimiento o
tiempo de respuesta 10
78
T3 Eficiencia del usuario final 15 T4 Procesamiento interno complejo 1 T5 El código debe ser reutilizable 1 T6 Facilidad de instalación 0.5 T7 Facilidad de uso 0.5 T8 Portabilidad 2 T9 Facilidad de cambio 1 T10 Concurrencia 1 T11 Incluye objetivos especiales de
seguridad 1
T12 Provee acceso directo a terceras partes
1
T13 T13 Se requieren facilidades especiales de entrenamiento a usuarios
1
Tabla 16. Factores de peso de complejidad técnica en UCP. Fuente: Métricas de Estimación de Tamaño Puntos de Casos de
Uso, Sigifredo E. Bandai Hernández (2002)
El Factor de complejidad técnica se calcula mediante la siguiente
ecuación:
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 cálculo del Factor de
ambiente. El cálculo del mismo es similar al cálculo del Factor de
complejidad técnica, 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.
79
Factor Descripción Peso
E1 Familiaridad con el modelo de proyecto utilizado
1.5
E2 Experiencia en la aplicación 0.5 E3 Experiencia en orientación a objetos 1 E4 Capacidad del analista líder 0.5 E5 Motivación 1 E6 Estabilidad de los requerimientos 2 E7 Personal part-time -1 E8 Dificultad del lenguaje de programación -1
Tabla 17. Factores de peso en condiciones del ambiente en UCP. Fuente: Métricas de Estimación de Tamaño Puntos de Casos de
Uso, Sigifredo E. Bandai Hernández (2002)
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 motivación para el proyecto, 3
motivación media y 5 alta motivación.
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 programación es
fácil de usar, 3 medio y 5 que el lenguaje es extremadamente difícil.
El Factor de ambiente se calcula mediante la siguiente ecuación:
∑ ××−= adoValorAsignPesoiEF (003.04.1
2.5.2 Consideraciones para la estimación del esfuerzo
80
2.5.2.1 Principales influencias de la estimación del esfuerzo
La principal influencia en la estimación del esfuerzo de un proyecto
es el tamaño del software a ser construido. Debido a esto, las
técnicas de estimación normalmente están orientadas a calcular el
esfuerzo como una función del tamaño.
La segunda influencia más importante es la productividad de la
organización, por lo cual resulta importante recolectar indicadores
dentro de la organización, que proporcionen datos históricos sobre
la productividad. Si no se cuenta con información histórica, 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 estimación y así no introducir
variaciones peligrosas en la estimación del esfuerzo.
2.5.2.2 Cálculo del Esfuerzo a partir del tamaño
Comparación Informal
Si se cuenta con datos históricos de proyectos que no difieren en
más de tres veces del tamaño del proyecto al cual se le está
realizando un proceso de estimación, es probablemente seguro
utilizar un modelo lineal para calcular el esfuerzo estimado de éste,
basándose en el esfuerzo real de los proyectos similares anteriores.
Uso de Herramientas de Estimación
81
El uso de herramientas de estimación permite realizar un proceso
formal del cálculo del esfuerzo del proyecto, agregándole 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.
Gráficos de promedios de industria
Si no se cuenta con datos históricos propios, se puede realizar una
estimación, con mediana probabilidad de error, usando gráficos de
esfuerzo de la industria del software.
La Figura 17 muestra los promedios de la industria acerca del
esfuerzo invertido según el tamaño en líneas de código; la línea
inferior representa el promedio de esfuerzo total de los proyectos
reportados y la línea superior representa el nivel de esfuerzo que
está a una desviación estándar del promedio. Una estimación
prudente utilizando este método debe asumir productividad
promedio de la industria o menor que ésta.
82
Figura 17. Gráficos de promedios de esfuerzo en la Industria. Fuente: http://www.isbsg.org/
2.5.2.3 Método ISBSG
El Grupo Internacional de Medición de Estándares de Software
(International Software Benchmarking Standards Group - ISBSG) ha
desarrollado un método útil para calcular el esfuerzo con base en
tres factores: El tamaño del proyecto en puntos de función, el tipo de
ambiente de desarrollo y el tamaño máximo del equipo de
desarrollo. La Ecuación 6 es la fórmula de propósito general de
proyectos de software, está calibrada con datos de alrededor de 600
proyectos. El grupo emite también fórmulas para diferentes tipos de
proyectos, cuyas calibraciones se realizan con datos de entre 63 a
363 proyectos; entre las categorías de fórmulas se encuentran:
Aplicaciones Desktop, desarrollo con lenguajes de tercera
generación, desarrollo mainframe, entre otras.
83
Ecuación 6. Fórmula para proyectos de software de negocios según el ISBSG. Fuente ISBG
2.5.2.4 Conversión 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 más fina, según
el siguiente criterio:
• Se contabilizan cuántos factores de los que afectan al factor
de ambiente están por debajo del valor medio (3), para los
factores E1 a E6.
• Se contabilizan cuántos factores de los que afectan al factor
de ambiente están por encima del valor medio (3), para los
factores E7 y E8.
• Si el total es 2 ó menos, se utiliza el factor de conversión 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 conversión 28 horas-
hombre/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:
CFUCPE ×=
Donde,
84
E: esfuerzo estimado en horas-hombre
UCP: Puntos de Casos de Uso ajustados
CF: factor de conversión
Se debe tener en cuenta que este método proporciona una
estimación del esfuerzo en horas-hombre, contemplando sólo el
desarrollo de la funcionalidad especificada en los casos de uso.
Comparación de Estimaciones de Esfuerzo
Para realizar una valoración de la realidad de los estimativos de
esfuerzo, es recomendable realizar una comparación de los cuatro
métodos descritos en esta sección. Se debe dar una valoración a
cada método, según el tipo de calibración 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 gráfica la
comparación entre diferentes métodos de estimación de esfuerzo,
dando mayor peso al cálculo realizado con una herramienta y luego
a la comparación informal, debido a que ambos métodos utilizan
datos de la organización para calibrar una estimación.
85
Figura 18. Comparación de métodos de estimación del esfuerzo. Fuente: Software Estimation: Desmytifiying the Black Art.
2.6 Clasificación de Proyectos de Software
Como se enuncia en la sección 1.3.8, el orden de importancia de las
influencias en la estimación de proyectos de software se clasifica de la
siguiente manera:
• Tamaño del proyecto
• Tipo de proyecto
• Factores del personal
• Lenguaje de programación
Esto se ve reflejado en las técnicas de estimación, en donde la mayoría de
éstas hace énfasis en el tamaño del proyecto. Las influencias asociadas al
tipo de software a desarrollar se ven más reflejadas en la calibración de
datos efectuada, siempre y cuando la información histórica que se utilice sea
86
de la organización o por lo menos pertenezca a datos de la industria de
software, restringidos al tipo de software específico.
La industria local de desarrollo de software a la medida de Medellín ha
presentado inclinación hacia el desarrollo alrededor de las siguientes
categorías de software: Sistemas transaccionales, Aplicaciones Web
(Intranet/Extranet) y Sistemas de Control o Gestión de Procesos (BPM).
Esta tendencia es en realidad coherente con la forma como han
evolucionado los paradigmas en sistemas informáticos y las tecnologías
emergentes a nivel global. En esta sección se realiza una definición de estas
categorías.
2.6.1 Sistemas Transaccionales
Para definir qué es un sistema transaccional se debe entender primero
lo que significa una transacción: Una transacción es una operación en
un sistema que cumple con los criterios conocidos como ACID. ACID
es un acrónimo de Atomicity, Consistency, Isolation and Durability:
Atomicidad, Consistencia, Aislamiento y Durabilidad en español, los
cuales se definen a continuación.
Atomicidad: es la propiedad que asegura que la operación 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 sólo 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.
87
Aislamiento: es la propiedad que asegura que una operación no puede
afectar a otras. Esto garantiza que la realización de dos transacciones
sobre la misma información, nunca generará ningún tipo de error.
Durabilidad: es la propiedad que asegura que una vez realizada la
operación, é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
información, sus cálculos 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 también grandes volúmenes de información. Tienen la
propiedad de ser grandes recolectores de información, lo que quiere
decir que en estos sistemas se cargan las grandes bases de
información para su explotación posterior. Son fáciles de justificar ante
la dirección 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.
88
Figura 19. Ejemplo de interacción de sistemas transaccionales con otros sistemas. Fuente: http://iteso.mx/~abby/transaccional.htm
Los sistemas transaccionales también pueden ser vistos como
soluciones de tecnologías de información que permitan integrar los
procesos de competencias de las empresas, los cuales pueden ofrecer
capacidades para logísticas integradas, planeación financiera, ventas,
procesos de órdenes, producción y planeación de los recursos
materiales.
Los sistemas transaccionales son los que usualmente se denominan
como sistemas núcleos de las compañías, 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.
89
Estos sistemas son necesarios para toda compañía 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 información relevante para la
compañía para el apoyo a toma de decisiones.
2.6.2 Aplicaciones Web
Una aplicación Web es un sistema informático que los usuarios utilizan
accediendo a un servidor Web a través 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 razón de su popularidad.
2.6.2.1 Historia
En los primeros tiempos de la computación cliente-servidor, cada
aplicación tenía su propio programa cliente y su interfaz de usuario,
los cuales debían ser instalados separadamente en cada estación
de trabajo de los usuarios. Una mejora al servidor, como parte de la
aplicación, requería típicamente una mejora de los clientes
instalados en cada una de las estaciones de trabajo, añadiendo un
costo de soporte técnico y disminuyendo la eficiencia del personal.
En contraste, las aplicaciones Web generan dinámicamente una
serie de páginas en un formato estándar, soportado por
navegadores Web comunes como HTML o XHTML. Se utilizan
lenguajes interpretados del lado del cliente, tales como JavaScript,
90
para añadir elementos dinámicos a la interfaz de usuario.
Generalmente cada página Web individual es enviada al cliente
como un documento estático, pero la secuencia de páginas provee
de una experiencia interactiva.
2.6.2.2 Interfaz
Las interfaces Web tienen ciertas limitantes en la funcionalidad del
cliente. Métodos comunes en las aplicaciones de escritorio como
dibujar en la pantalla o arrastrar-y-soltar no están soportadas por las
tecnologías Web estándar. Los desarrolladores Web comúnmente
utilizan lenguajes interpretados del lado del cliente para añadir más
funcionalidad, especialmente para crear una experiencia interactiva
que no requiera recargar la página cada vez (cosa que suele
molestar a los usuarios). Recientemente se han desarrollado
tecnologías para coordinar estos lenguajes con tecnologías del lado
del servidor, como por ejemplo PHP. AJAX es una técnica de
desarrollo Web que usa una combinación de varias tecnologías para
crear lo que se conoce como "Rich Internet Applications" (RIA),
aplicaciones de Internet con mayor riqueza en la interfaz gráfica.
2.6.2.3 Uso en negocios
Una estrategia que está emergiendo para las empresas
proveedoras de software, es proveer acceso vía Web al software.
Para aplicaciones previamente distribuidas como de escritorio, esto
puede requerir el desarrollo de una aplicación totalmente nueva o
simplemente adaptar la aplicación para usar una interfaz Web. Estos
programas permiten al usuario pagar una cuota mensual o anual
91
para usar la aplicación, sin necesidad de instalarla en la
computadora del usuario. Las compañías que siguen esta estrategia
son llamadas Proveedores de Aplicaciones de Servicio (ASP por sus
siglas en inglés), este modelo de negocios está atrayendo la
atención de la industria del software.
En el mundo corporativo, la proliferación de las aplicaciones Web
como estrategia para las soluciones informáticas cada vez es
mayor. Las posibilidades de acceso que brindan este tipo de
aplicativos, permiten que fácilmente puedan implementarse en una
organización a través de una Intranet, sistemas como: Sistemas de
apoyo, herramientas de capacitación, 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
también han logrado expandir la interacción que tienen con sus
clientes, proveedores y socios estratégicos, creando aplicaciones
Web para suplir las necesidades de interacción que cada una de las
empresas tendrían con estas contrapartes, dándole vida a
conceptos tales como comercio electrónico, negocios electrónicos,
sistemas B2B y sistemas B2C.
2.6.3 Sistemas de Control o Gestión de Procesos (Business Process
Management - BPM)
2.6.3.1 Descripción General
92
Los sistemas BPM surgen a partir de una metodología empresarial
cuyo objetivo es mejorar la eficiencia a través de la gestión
sistemática 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 administración de los procesos
del negocio.
A través del modelado de las actividades y procesos se logra un
mejor entendimiento del negocio y muchas veces esto presenta la
oportunidad de mejorarlos. La automatización 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 administración de los procesos permite
asegurar que los mismos estén ejecutándose eficientemente y
obtener información que luego puede ser usada para mejorarlos. Es
a través de la información que se obtiene de la ejecución 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 gestión de Procesos de
Negocio (BPM); dichos motivos son:
• Extensión del programa institucional de calidad
93
• Cumplimiento de legislaciones
• Crear nuevos y mejores procesos
• Entender qué se está haciendo bien o mal a través de la
compresión de los procesos
• Documentar procesos para outsourcing y definición de SLA
(Service Level Agreement)
• Automatización 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 intersección entre la gerencia y la
tecnología de información. El término “procesos operacionales del
negocio” refiere a los procesos repetitivos del negocio realizados por
organizaciones en el contexto de sus operaciones cotidianas, en
comparación con los procedimientos de toma de decisión
estratégicos 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 más
rápidas y más baratas. Los sistemas de BPM supervisan la
ejecución de los procesos del negocio de modo que los encargados
puedan analizar y cambiar procesos en respuesta a las métricas
resultante de la ejecución 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 categorías: diseño, ejecución y
supervisión.
94
Diseño de procesos
El diseño de procesos abarca el diseño y la captura de los procesos
existentes del negocio, así como la simulación de nuevos. El
software usado para hacer esto incluye a redactores gráficos que
documentan los procesos, los repositorios que almacenan modelos
de procesos, y las herramientas de simulación de procesos del
negocio, para ejecutar un proceso una gran cantidad de veces y
ajustar su parametrización orientado a la optimización del tiempo y
costo del proceso.
Ejecución de procesos
La manera tradicional de automatizar procesos es desarrollar o
comprar una aplicación que permita ejecutar los pasos requeridos
del proceso. Sin embargo, en la práctica, éstas permiten ejecutar
raramente todos los pasos del proceso exacta o totalmente. Debido
a la complejidad de desarrollar software, la documentación de un
proceso implementado en una aplicación a la medida es compleja.
Esto hace difícil cambiar o mejorar el proceso.
Como respuesta a estos problemas, se han desarrollado sistemas
que permiten al proceso completo del negocio (según lo convertido
en la actividad de diseño de proceso). El sistema utilizará servicios
en aplicaciones conectadas para realizar operaciones de negocio
(Ejemplo, calculando un plan del reembolso para un préstamo) o,
cuando un paso es demasiado complejo de automatizar, requiere
una interacción con el usuario. Comparado con cualquiera de los
acercamientos anteriores, directamente ejecutar una definición de
proceso es mucho más directo y por lo tanto más fácil de mejorar.
95
Sin embargo, la automatización de una definición 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 gráficos, 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 ejecución del proceso y la
resolución del mismo.
Supervisión de proceso
El monitoreo de procesos abarca el seguimiento de procesos
individuales para que la información de su estado pueda ser
fácilmente vista y se puedan proveer estadísticas de uno o más
procesos. Además, esta información se puede utilizar para trabajar
con los clientes y los proveedores para mejorar sus procesos
conectados. Las métricas de monitoreo se clasifican en tres
categorías: duración 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 paramétrica 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
96
funcionarios internos, los proveedores, etc., estimulando el trabajo
colaborativo y permitiendo la integración entre aplicaciones
empresariales existentes (EAI: Enterprise Application Integration).
Este tipo de soluciones permiten la integración de diferentes áreas
de la misma organización o de otras organizaciones alrededor de
cada proceso, aunque estén geográficamente dispersas, pero
manteniendo un control centralizado. La mayoría BPMS
proporcionan las funciones para gestionar todos los componentes
que abarca cualquier proceso, como son: actividades, tareas, pasos,
rutas, lugares, roles, recursos humanos y físicos, documentos
digitales y electrónicos, cálculos, datos y formas electrónicas, de
acuerdo con las reglas y políticas de cada proceso. Deben también
incluirse herramientas de gestión, tales como consultas y reportes
para asegurar el mejoramiento continuo de los procesos y
mecanismos de control, tales como alarmas y diálogos, 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 quién o a cuál á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 tecnologías de información actuales,
la mayoría de BPMS brindan la posibilidad que un cliente desde
cualquier lugar y a través de la Web inicie un proceso, que este
transite por todos los responsables de ejecutar las tareas necesarias
97
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 diseñar y poner en
ejecución en la Web, se cuentan procesos tales como:
• Atención y Seguimiento de Preguntas, Quejas y Reclamos
(PQR’s)
• Procesos de compras y contratación
• Mesas de ayuda
• Procesos jurídicos y trámites legales
• Inicio y Seguimiento de ordenes de trabajo o de servicio
• Procesos de cobro coactivo
• Gestión y trámite de documentos
• Logística de comercio nacional e internacional
• Procesos de evaluación y cotización
• Seguimiento a pedidos y órdenes de compra.
• Trámites con Proveedores.
• Procesos de ventas y área comercial
• Gestión documental automatizada
• Trámites de toda índole
2.7 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:
Técnicas de estimación utilizadas, exactitud obtenida y consideraciones
adicionales sobre el tema de estimación en cada empresa. Las empresas
son todas de tamaño mediano (entre 51 y 200 empleados según la
clasificación dada por la Ley Mipyme), y todas superan los 8 años de
98
existencia. Debido a la naturaleza confidencial de la información, no se
detallan los nombres de las empresas investigadas. Estas empresas fueron
seleccionadas ya que son las más representativas en el medio de desarrollo
de software a la medida en la ciudad de Medellín.
Para la obtención de la información, se realizó una entrevista no
estructurada, con las personas responsables de estimación de proyectos de
software de cada empresa, indagando principalmente sobre el proceso que
usan para la estimación de proyectos.
Los resultados de la investigación se presentan en la Tabla 18
Empresa Técnica Exactitud Manifestada
Herramientas de Estimación
Observaciones
Empresa 1 WBS no estandarizado. Juicios expertos no estructurados
Errores de estimación que oscilan entre el 320% y el 1200%
Excel Históricamente las estimaciones han sido siempre de "punto único. Alto índice de tareas ocultas.
Empresa 2 Para proyectos grandes: Puntos de función. El cálculo del esfuerzo a partir de los puntos de función es calibrado mediante datos de industria y también con datos de la organización. Para proyectos pequeños: Juicio experto no estructurado.
No se cuenta con información que permita dar cifras de la MRE en estimaciones de la compañía. Para proyectos grandes se cuenta con la noción general de tener buenos niveles de exactitud gracias a la técnica usada. Los proyectos pequeños sufren normalmente de grandes desfases.
Hoja de Excel con macros para el apoyo al cálculo de puntos de función.
No existe un proceso estandarizado de estimación. Para proyectos grandes, el nivel de análisis y diseño al que obliga la técnica de puntos de función aparenta tener un proceso. Sin embargo, la estimación emitida por la técnica no se revalúa formalmente a través del proyecto.
Empresa 3 Tallaje de Camisetas. Juicios Expertos no
Errores entre el 180% y el 200% para proyectos grandes.
Excel No se utilizan las métricas de proyectos de la empresa para calibrar las
99
estructurados WBS intuitivos
Errores entre el 30% y el 50% para proyectos no ajustados a los procesos estandarizados de la empresa. Errores entre el 10% y el 13% para el resto de los proyectos.
estimaciones.
Empresa 4 Juicios Expertos no estructurados WBS intuitivos
Errores del 10% sobre las estimaciones realizadas por las técnicas.
Excel Las estimaciones resultantes de las técnicas no resultaban ser las usadas para la planeación. Las estimaciones son modificadas por el área comercial.
Empresa 5 Estimaciones basadas en referencias por lógica difusa. Puntos de Función
No se posee información.
Hoja de Excel con macros para el apoyo al cálculo de puntos de función. Hoja de Excel con macros para la estimación de esfuerzo basados en las referencias (proxy).
Calibración de las técnicas con datos de industria.
Empresa 6 Puntos de Casos de Uso.
No se posee información.
Herramienta de estimación basada en Puntos de Casos de Uso.
Calibración de las técnicas con datos de industria.
Tabla 18. Técnicas de estimación evidenciadas en 6 empresas de la industria de software local
El sondeo realizado, muestra que aunque existe mucha documentación de
técnicas de estimación de software, realmente se encuentra que la industria
local realiza la estimación de proyectos de software de forma muy
"artesanal", siendo evidencia de esto que la mayoría de las empresas
encuestadas utiliza el juicio de expertos no estructurado como técnica
predominante y aquellas que usan algún método más formal de estimación,
100
utilizan principalmente datos históricos de la industria mundial para la
calibración de sus modelos. Con esto se puede concluir que la forma de
realizar las estimaciones de los proyectos de software están 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 años. 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.