Trabajo investigativo No.

06

Ingeniera de software

Presentado por:

Hasbleydi Yurani Reyes Saldaa

Camilo Esteban Rodriguez Forero

Marlon Sebastian Castaeda Aponte

Presentado a:

Juan Carlos Guevara Bolaos

Universidad Distrital Francisco Jos de Caldas, Facultad Tecnolgica

Bogot D.C.

2017
Contenido

1. Definicin de Estimacin
2. Caractersticas de Estimacin
3. Ventajas del uso de estimacin
4. Tipos de estimacin
4.1. Estimacin del tamao del software
4.2. Estimacin del esfuerzo
4.3. Estimacin Del tiempo
4.4. Estimacin Del costo
5. Organizacin de un taller sobre el uso de una herramienta de Estimacin
6. Estudio de caso donde se analice la aplicacin de la estimacin del software
7. Explicacin del uso de una herramienta para estimacin de software

ESTIMACIN DE SOFTWARE

1. Definicin estimacin de software

La estimacin de software, no es ms un proceso de "prediccin", o acercamiento
a las variables que intervienen en el desarrollo de software. Estos mtodos tienen
como fin apoyar todo el proceso de desarrollo, optimizndolo en un porcentaje. Sin
las estimaciones, los objetivos planteados quedan de manera subjetiva y nos
encontraremos en un margen mayor de caer en errores o falencias que
perjudicaran todo el proceso. La estimacin al igual que las mtricas, son unas
potentes herramientas en la planificacin y evaluacin de un proyecto de software.

Importancia de la estimacin

La estimacin como anteriormente se menciona es una potente y sencilla

herramienta que permite prevenir errores a futuros, tambin debemos partir de que
en la prctica las estimaciones no lograran abarcar un 100% lo que se quiere
controlar, ya que existen diferentes variables que en el momento no son
detectables, pero con el desarrollo del software aparecen en muchos casos de
forma repentina. Por eso realizar un buen proceso de estimacin, se puede
prevenir un alto porcentaje mejorando la rentabilidad del proyecto.

2. Caractersticas

La estimacin requiere de un gran proceso de anlisis especialmente cuando los

proyectos tienen una gran longitud o tamao, la estimacin no es tarea fcil,
identificar todos los factores que pueden alterar o desviar los objetivos, no es de
una manera muy repentina, se tiene que abarcar muchsima informacin y
especialmente usar mucho conocimiento y evaluacin de experiencias que
requieren ms tiempo y compresin.

"La estimacin de un proyecto software requiere:

Experiencia.
Buena informacin histrica.
Confianza en las mtricas y la experiencia."
"Algunos de los principios que hay que tener presentes:

Retrasar la estimacin lo mximo posible. Cuanto ms se retrase, ms

precisa ser.

Hacer estimacin por analoga. Utilizar el coste de proyectos similares.

Ley de Parkinson. El trabajo se extiende para rellenar el tiempo disponible.

Precio para ganar. El coste se estima en todo el dinero que el cliente puede
gastar en el proyecto.

Existen tcnicas de descomposicin. Estimas el coste descomponiendo el

producto y/o el proceso.

Existen modelos empricos. Modelos de regresin que relacionan esfuerzo

con tamao o funcionalidad."

3. Ventajas del uso de estimacin

Los factores crticos de xito son los descritos a continuacin:

Definir funciones y responsabilidades.

Planificacin detallada y sistemtica.
Definir el alcance del proyecto.
Definir calendario y cronograma para definir tiempos o fechas.
Retroalimentacin detallada de actividades y resultados.
Integracin, cooperacin y disposicin del equipo de trabajo.
Gestin de Cambios.
Gestin de Riesgos.
Gestin de mejores prcticas por reas.
Evaluacin y desempeo proyecto/equipo.
Aprender dela experiencia.
 o Desventajas

Los errores ms comunes en estimacin de costes Software:

Desestimar el tiempo y esfuerzo necesario para hacer una buena estimacin.
Requisitos imprecisos. Requisitos van creciendo.
No reconocimiento de que los proyectos actuales sern y son diferentes que los
anteriores.
El tamao suele ser estimado a la baja.
Estimaciones forzadas por los recursos disponibles (Si hay que acabar el
proyecto en 12 meses y se dispone de 5 tcnicos, se estima en esfuerzo como 60
tcnicos-da). (NO ACEPTABLE)
Usar la estimacin del precio ganador (NO ACEPTABLE).

4. Tipos de estimacin
o Estimacin del tamao del Software

La precisin en una estimacin de proyectos de software se predice basndose en

una serie de cosas, el grado en el que el planificador ha estimado adecuadamente
el tamao del producto a construir, la habilidad de traducir la estimacin del
tamao en esfuerzo humano, tiempo y dinero, el grado en el que el plan de
proyecto refleje las habilidades del equipo de software, la estabilidad de los
requisitos de software y el entorno que soporta el esfuerzo de la ingeniera de
software.
Como una estimacin de proyecto es tan buena como la estimacin del tamao
del trabajo que va a llevarse a cabo, el tamao representa el primer reto
importante del planificador de proyectos.
A diferencia de los objetos palpables, obtener el tamao en proyectos de software
resulta complicado, los profesionales del rea no han llegado a un consenso en
cmo medirlo. Las lneas de cdigo (LOC) a pesar de ser la medida ms utilizada
dependen del ambiente de programacin, del lenguaje y de la habilidad del
programador. Las medidas de funcionalidad son otras de las ms frecuentes estas
dependen mucho del juicio de expertos.
Actualmente existen tcnicas de estimacin muy utilizadas alguna de ellas son las
que se basan en Lneas de cdigo Fuente, en Puntos de Funciones, y Casos de
Uso.

o Estimacin de esfuerzo

Es importante diferenciar estos de las entidades, relaciones, las tablas o los

ficheros resultantes del diseo fsico. Se identifican a las agrupaciones de datos
que el usuario ya conoce como relevantes para el sistema, por ejemplo: Clientes,
Artculos, Facturas, Proveedores, etc.

Los ficheros se cuentan una sola vez independientemente del nmero de procesos
o frecuencia con que sean accedidos. Por supuesto de las veces que aparezcan
en los DFD para mejorar la legibilidad.

No hay que contar los ficheros de ndices ni los ficheros intermedios creados
durante el diseo para simplificar el desarrollo, por ejemplo ficheros de spool por
no disponer de impresora dedicada, etc.. Los ficheros intermedios inherentes a la
filosofa de la aplicacin s que se cuentan, por ejemplo matrcula-curso-97-98 que
es actualizado por la aplicacin y que el usuario ha solicitado su existencia hasta
que se cierre la matrcula del curso y que ms tarde se consolida en el fichero de
alumnos UPV, etc.

o Estimacin de tiempo

La gestin de tiempos se encarga de administrar los procesos necesarios para

asegurar el correcto desarrollo de las distintas tareas, dentro del tiempo
especificado, utilizando las herramientas para el control, planificacin y
programacin del proyecto.

Los procesos para la gestin de tiempo se componen de la siguiente manera:

Definicin de tareas: Determinar las tareas especficas para cumplir con el

desarrollo del proyecto como resultado de lo que se pretenda realizar.
 Secuencia de actividades: Teniendo en cuenta las tareas que ya se tenan
planeadas, en este paso se interrelacionan para definir las actividades que se van
a realizar en un orden determinado en la programacin del proyecto.

Estimacin de la duracin de tareas: Las personas definidas para cada

una de las tareas, determinan la duracin para cumplir con el trabajo teniendo en
cuenta los objetivos, su alcance, los recursos necesarios y disponibles. Por lo que
el proyecto depende de la elaboracin de cada una de las tareas necesarias y que
se trabajen en un tiempo acorde con los dems trabajos.

Establecimiento de calendario: Teniendo definida la duracin de cada una

de las tareas, en este paso se establece la fecha de inicio y fin para cumplirlas en
la fecha que se tenan planeadas.

Control de calendario: Se realiza un seguimiento en la elaboracin de cada

tarea, para determinar el cambio que se debe realizar como mtodo y solucin
para finalizarla en la fecha estipulada. Por lo que este proceso se debe cumplir
hasta la finalizacin del producto o proyecto.

El nmero de procesos depende del proyecto que se vaya a realizar, por esta
razn existen algunos proyectos de menor tamao que los elementos
anteriormente llegan a ser evaluados en un mismo proceso.

El control del calendario que definimos entre los componentes de la gestin del
tiempo, tambin lo podemos nombrar como cronograma para determinar el inicio y
final de cada tarea para la planificacin del proyecto. De tal forma el cronograma
cuenta tanto con unas entradas como unas salidas en el proceso de desarrollo, las
entradas son:

1. Activos de los procesos de la organizacin, como calendario del proyecto

2. Enunciado del alcance de los proyectos, para determinar la fecha de inicio y

finalizacin del proyecto, y poder cumplir con el trabajo estipulado por el cliente.
3. Lista de actividades

4. Atributo de las actividades

5. Diagramas de red del cronograma del proyecto

6. Requisitos de los recursos de las actividades

7. Calendario de los recursos

8. Estimaciones de duracin de la actividad

9. Plan de gestin del proyecto, contiene el plan de gestin del cronograma, el

plan de gestin de costes, el plan de gestin de alcance del proyecto y el plan de
gestin de riesgos.

Y como salida se tiene:

Cronograma del proyecto, para controlar el tiempo de duracin.

Datos del modelo del cronograma

Lnea base del proyecto.

Requisitos de recursos

Atributos de la actividad

Calendario del proyecto

Cambios solicitados

Plan de gestin de proyectos.

De los anteriores elementos como salida, los que se repitieron en comparacin
con los de entrada, en este caso, vienen siendo su actualizacin para la solucin y
cumplir con la finalidad del proyecto.

De tal modo, es necesario plantear la distribucin del tiempo de las actividades y

el proyecto como puede ser visto en la siguiente grfica:

De acuerdo con la grfica, se puede determinar la siguiente formula:

Donde,

te= tiempo valorado de actividad promedio

a= tiempo optimista de la actividad

b= tiempo pesimista de la actividad

m= tiempo ms probable de la actividad

Y la variabilidad de tiempo necesaria tanto para las actividades como para el

proyecto se define de la siguiente manera:
Adems, para conocer la duracin total del proyecto se tiene en cuenta la
distribucin normal con los valores relacionados, reemplazo por la letra Z con el
nmero de desviaciones estndar que demuestran los valores de la distribucin
para determinar si el proyecto se puede cumplir en el tiempo planeado.

Donde,

TE= Duracin de la ruta critica

TS= Duracin programada del proyecto

Z= probabilidad que debe ser localizada en la tabla que muestra los valores de la
distribucin normal.

o Estimacin de costo

Esta estimacin consiste en aproximar el costo de los recursos necesarios para

desarrollar el proyecto. Para lo cual se debe tener en cuenta no solo los costos
sino tambin los riesgos para decidir si fabricar en lugar de comprar o comprar en
lugar de alquilar.

Adems, normalmente la estimacin de costos se representa con las unidades

monetarias (peso, euro, dlar, yen, etc.), pero en otros casos se tienen en cuenta
las horas o los das de trabajo personal, para realizar la comparacin y descripcin
del proyecto en esta estimacin.
Las entradas que se caracterizan en esta estimacin son las siguientes:

Lnea base del alcance

Cronograma del proyecto

Planificacin de los recursos humanos

Registro de riesgos

Factores ambientales de la empresa

Activos de proceso de la organizacin

Lnea base del alcance: Es necesario conocer del proyecto si los estimados son
solamente costos directos o si tambin cuenta con costos indirectos, siendo
aquellos que no se puedan asignar a un proyecto especfico y por lo tanto se
repartir entre varios proyectos con un procedimiento establecido aprobado y
documentado.

Otros aspectos que se establecen en la lnea base del alcance son: la salud, la
seguridad, el desempeo, el medioambiente, los seguros, los derechos de
propiedad intelectual, las licencias y los permisos, en la estimacin de costos.

Cronograma del proyecto: Los factores principales para determinar el costo del
proyecto son el tipo y la cantidad de recursos, como tambin la cantidad de
tiempo. De este modo, la estimacin de duracin de las actividades tambin puede
afectar la estimacin de los costos, es decir, se tienen en cuenta los costos de las
variables en funcin del tiempo como los sindicatos de trabajadores con convenios
colectivos de trabajo.

Planificacin de los recursos humanos: Para desarrollar la estimacin del costo

del proyecto son necesarios los atributos de los recursos humanos como: salarios
y compensaciones.
Registro de riesgos: Los riesgos del proyecto pueden traer amenazas u
oportunidades para los costos de las actividades. Cuando ocurren los riesgos
negativos, se incrementa el costo a corto plazo del proyecto y el cronograma de
las actividades se retrasa.

Factores ambientales de la empresa: Para la estimacin de los costos se tienen

en cuenta las condiciones del mercado y la informacin comercial publicada.

Activos de los procesos de la organizacin: En la estimacin de los costos se

incluye las polticas de estimacin de costos, las plantillas de estimacin de
costos, la informacin histrica y las lecciones aprendidas.

Adems de las entradas de la estimacin de costos que ya se han nombrado, en

la siguiente imagen se pueden encontrar las herramientas y salidas que son
importantes para esta estimacin.

Entre las herramientas que se pudieron visualizar en la anterior imagen, la

estimacin por tres valores al igual que la estimacin de duracin de las
actividades, lo que tambin podemos llamar estimacin de tiempo, el PERT utiliza
tres estimados para definir un rango aproximado de costos de una actividad:

Ms probable (como)
 Optimista (cO)

Pesimista (cP)

Esperada (cE)

La estructura de descomposicin del trabajo (EDT) es una estructura formada por

los entregables y las tareas necesarias para desarrollar un proyecto. La EDT es
una herramienta muy comn y crtica en la gestin de proyectos.

El propsito principal de la EDT es entregar una base para la estimacin de los

recursos del proyecto, entre estos estn:

Subcontratos

Proveedores y sus productos

Servicios

Cualquier otro recurso identificable

Un ejemplo de una EDT para una habitacin lo podemos encontrar a continuacin:

Preparar materiales

Comprar pintura

Comprar una escalera

Comprar brochas y rodillos

 Comprar removedor de papel tapiz

Preparar la habitacin

Quitar el papel tapiz viejo

Quitar la decoracin desmontable

Cubrir el piso con papel peridico viejo

Cubrir los switches de luz con cinta

Cubrir los muebles con sbanas

Pintar la habitacin

Limpiar la habitacin

Desechar o guardar la pintura sobrante

Limpiar las brochas y rodillos

Desechar los peridicos

Quitar las sbanas

En el ejemplo anterior, pudimos encontrar los recursos necesarios para cumplir

con el objetivo, entre estos estn los materiales, el lugar para pintar y los pasos
para la culminacin de lo estimado.

o Estimacion de recursos

Los recursos pueden estimarse como personas, componentes software

reutilizables y las herramientas de hardware/software necesarios para realizar el
proyecto.
Cada recurso se especifica con cuatro caractersticas (las dos ltimas se
denominan ventana temporal):

Descripcin.

Informe de disponibilidad.

Fecha cronolgica en la que se requiere.

Tiempo durante el que ser aplicado.

Respecto al personal hay que especificar su posicin en la organizacin y su

especialidad.

Los componentes software, por su parte, pueden estar:

Ya desarrollados.

Ya experimentados.

Con experiencia parcial.

Nuevos.

o Estimaciones Top-Down y Bottom-Up

En la estimacin top-down (de arriba a abajo) una estimacin de conjunto para

los costes del proyecto es extrada de las propiedades generales del producto a
desarrollar. El coste total es despus distribuido, repartido entre los distintos
componentes. (ii)
Esta tcnica (y tambin la bottom-up) puede ser llevada a cabo en conjuncin con
otro de los mtodos tratados anteriormente. (ii)
Como ventajas:

Enfoque a nivel de sistema. Debido a que la estimacin se basa en la

experiencia previa en proyectos completados, tendr en cuenta todos
los subsistemas a implementar del proyecto.

Como inconvenientes:

No suele identificar problemas a bajo nivel para los que sera conveniente
emplearse a fondo en la estimacin.

Se olvida de pequeos subsistemas que no estn previstos en principio a

desarrollar.

Tiene menos estabilidad que una estimacin por componentes.

En la estimacin bottom-up (de abajo a arriba), el coste de cada componente se

estima por un individuo distinto, frecuentemente por la persona que ser el
responsable de su desarrollo. Despus, esos costes son sumados para conseguir
el total del producto.
Esta estimacin es complementaria al top-down, siendo las debilidades de esta
ltima las virtudes de la primera, y viceversa. Debido a que la estimacin bottom-
up se centra en cada uno de los componentes, pierde de vista costes globales
como la integracin, gestin de calidad, etc.; que estn asociados al desarrollo de
un proyecto. Por todo esto, estas estimaciones suelen ser un poco optimistas.

Se ha de aadir que este tipo de estimacin requiere un mayor esfuerzo que

la top-down, siendo esto en muchos aspectos una ventaja.
Adems, una estimacin bottom-up tiende a ser bastante ms estable en el
sentido de que los errores posibles en la estimacin de varios componentes
pueden compensarse mutuamente.
5. TALLER

6. CASO DE USO

7. HERRAMIENTAS

o Albrecht

Para proceder al clculo de los puntos funcin de un sistema han de realizarse

tres etapas:

Identificacin de los componentes necesarios para el calculo.

Calculo de los Puntos Funcin no ajustados.
Ajuste de los Puntos Funcin.
Identificacin de los componentes

En esta etapa se identifican los elementos a tener en cuenta para el clculo de los
puntos funcin. Primeramente se enumeran todos los componentes de cada tipo
(entradas externas, salidas externas, grupos lgicos de datos internos, grupos
lgicos de datos de interfaz y consultas externas); seguidamente, se evala
individualmente la complejidad de cada uno de ellos, utilizando unas tablas ya
establecidas que proporcionan el factor de complejidad de cada componente
individual, siendo estos factores: COMPLEJO, MEDIO o SENCILLO.

A continuacin se describen los distintos componentes que han de tenerse en

cuenta para el clculo y la forma de determinar su complejidad en cada caso.

Entradas externas

Son todos aquellos grupos de datos o mandatos de control de usuario que

entran en la aplicacin y aaden o cambian informacin en un grupo lgico de
datos interno.
Una entrada es nica si difiere en su formato o si arranca procesos
diferentes.
Para el anlisis de este componente se utiliza la siguiente matriz de complejidad:

Los tipos de entrada aplicables son los siguientes:

Documento tecleado.
Documento de lectura ptica.
Pantalla.
Disquete / CD.
Cinta magntica.
Interruptor.
Sensor digital.
Sensor analgico.
Tecla de funcin.
Puntero electrnico.

Salidas externas

Son todos aquellos grupos lgicos de datos o mandatos de control de

usuario que salen de la aplicacin.
Una salida es nica si difiere en su formato o si es generada por procesos
lgicos diferentes.
Para el anlisis de este componente se utiliza la siguiente matriz de complejidad:

Los tipos de salida aplicables son los siguientes:

Informe por pantalla.

Informe por impresora.
Informe por lotes.
Transaccin automtica.
Escritura en disquete.
Escritura en soporte magntico / ptico.
Mensaje por pantalla.
Accionamiento digital.
Accionamiento analgico.
Factura, recibo, albarn, etc.

Grupos logicos de datos internos

Son aquellos grupos lgicos de datos o informacin de control interna que

se generan, son usados y mantiene la aplicacin.
No deben incluirse aquellos grupos lgicos de datos que no sean
accesibles por el usuario a travs de entradas o salidas externas, ficheros de
interfaz o consultas.
Para el anlisis de este componente se utiliza la siguiente matriz de complejidad:

Los tipos de datos internos o ficheros aplicables son los siguientes:

Fichero lgico interno.

Base de datos.
Tabla de usuario.
Fichero de control o proceso secuencial por lotes.
Fichero de query de usuario.

Grupos logicos de datos de interfaz

Son aquellos grupos lgicos de datos compartidos con otra aplicacin,

recibidos o enviados a ella.
Los grupos lgicos internos que son a su vez interfaz, deben contarse en
ambos grupos.

Para el anlisis de este componente se utiliza la siguiente matriz de complejidad:

Los tipos de datos o ficheros de interfaz aplicables son los siguientes:

Fichero lgico interno accesible desde otra aplicacin.

Fichero lgico interno accesible para otra aplicacin.
Bases de datos compartidas.

Consultas externas

Son entradas de usuario u otra aplicacin que generan una salida

inmediata.
Son consecuencia de una bsqueda y no una actualizacin de un grupo
lgico de datos interno.
Se utilizar la matriz de Entradas Externas para calificar la parte
correspondiente a la entrada.
Se utilizar la matriz de Salidas Externas para calificar la parte
correspondiente a la salida.
Se seleccionar la ms compleja.

Los tipos de consultas aplicables son los siguientes:

Consulta de usuario sin actualizacin de ficheros.

Pantalla o mensaje de ayuda.
Men de seleccin.
 o IFPUG

Paso 1 (Determinar el tipo de conteo de PF). Se determina el tipo de conteo de

acuerdo a tres posibilidades: para proyectos en desarrollo, para mejora de
proyectos y para aplicaciones ya desarrolladas.

Paso 2 (Identificar el alcance y las fronteras de la aplicacin que se est

estimando). La frontera es el lmite entre el proyecto o aplicacin que est siendo
medida y las aplicaciones externas o el dominio del usuario. En la figura 4 se
muestra grficamente la funcionalidad reconocida para el conteo. Se puede
observar como los usuarios y las aplicaciones externas pueden interactuar con la
aplicacin a travs de las entradas externas, consultas externas y salidas
externas.

Paso 3 (Identificar todas las funciones de datos y su complejidad). Las

funciones de datos se clasifican en Archivos Lgicos Internos (en ingls Internal
Logical Files, ILF) y Archivos de Interfaz Externos (en ingls External Interface
Files, EIF). El conteo fsico de ILF y EIF, junto con la complejidad relativa de cada
uno, determina la contribucin a los PF desajustados. Esta complejidad est
determinada por el Nmero de Elementos de Datos (en ingles Data Element
Types, DET) y de Tipos de Registros (en ingles Record Element Types, RET)
asociados a cada uno. Los DET son los campos o atributos del archivo. Los RET
son los grupos o subgrupos que constituyen una parte de un archivo (tambin
conocidos como entidades dbiles de una tabla).

Paso 4 (Identificar todas las funciones transaccionales y su

complejidad). Las transacciones transaccionales se clasifican en Entradas
Externas (en ingls External Inputs, EI), Salidas Externas (en ingls External
Outputs, EO) y Consultas Externas (en ingls External Inquiries, EQ). El conteo
fsico de EI, EO y EQ, junto con la complejidad relativa de cada uno, determina la
contribucin a los PF desajustados. Esta complejidad est determinada por el
nmero de DET y de Archivos Referenciados (en ingles File Types Referenced,
FTR) asociados a cada transaccin.

Paso 5 (Determinar los Puntos de Funcin Sin Ajustar (PFSA)). Con la

informacin obtenida de los archivos ILF y EIF, y de las transacciones EI, EO y
EQ, identificados en los pasos anteriores, se obtiene el total de PFSA. Para esto
se debe emplear la tabla 1 y aplicar el peso correspondiente a la complejidad de
cada transaccin o archivo. Paso 6 (Determinar el valor del Factor de Ajuste (FA)-
basado en las 14 caractersticas generales del sistema). Una vez obtenidos los
PFSA, se deben ajustar a travs de 14 caractersticas generales, con el fin de
adaptar la estimacin a las condiciones de trabajo bajo las que el sistema va a ser
desarrollado. A cada una de esas caractersticas se le asigna un factor de peso
que indica la importancia de la caracterstica para el sistema bajo anlisis. El peso
del valor asignado esta entre 0 y 5: cero cuando el factor no presenta alguna
influencia en la aplicacin y cinco cuando el factor influye fuertemente.

o COCOMO II

Cuando profesionales inmersos en el desarrollo, mantenimiento o gestin de

software, se enfrentan a la solicitud de ofrecer una estimacin tcnica de plazo o
esfuerzo necesarios para una nueva iniciativa, evitan al mximo dar una
respuesta.

Eso sucede por la confusin que existe entre una estimacin tcnica y la
determinacin de una meta o de un compromiso. Cuando hay una respuesta, lo
mas comn es que contenga un nico punto, una fecha o una cantidad de horas.
Respuestas como la anterior, slo aumentan la confusin entre estimacin, meta o
compromiso. Las consecuencias de tratar un acto como otro, no son positivas y
traen graves prejuicios a todos los involucrados en el proceso.
COCOMO II (Constructive Cost Model) surge como una alternativa para incluir
componentes de incerteza en las estimacins conforme al nivel de informacin
disponible. Este es un modelo paramtrico que establece ecuaciones matemticas
para describir las relaciones entre el tamao del software - factor primario de costo
usualmente representado en trminos de puntos de funcin - y otros factores
secundarios que buscan capturar particularidades de producto, proceso, personas
y plataforma. Esos factores son denominados Cost Drivers, siendo algunos de
efecto proporcional y otros de efecto exponencial.

El modelo ofrece un framework completo para determinar factores de

productividad locales (Constantes de productividad) a partir de datos como el
plazo y el esfuerzo de proyectos pasados. Una de las principales virtudes de
COCOMO II es ofrecer una estimacin de plazo y esfuerzo, y a partir de estos
sugerir el tamao del equipo y no lo opuesto; como sucede generalmente.

Objetivos

El objetivo de este curso en cuanto al usuario operador del modelo, es que sea
capaz de:
Establecer la diferencia entre los actos de estimar, asumir un compromiso y
establecer una meta y con eso, adoptar una postura de quien ofrece una
estimacin en contraste con la postura de quien lleva ms tiempo o recursos.
Presentar las opciones y escenarios para que los responsables puedan
establecer las metas o asumir compromisos con base en fundamentos slidos
y en instrumentos de gerencia del conocimiento.
Diferenciar una estimacin directa y un modelo de estimacin paramtrica.
Especficamente sobre sos ltimos, discutimos las particularidades entre
aquellas basadas en modelos determinsticos y aquellas basadas en modelos
estocsticos.
 Transformar los rangos de esfuerzo y plazo optimistas, ms probables y
pesimistas ofrecidas por modelos de estimacin estocsticas o por la
estimacin directa en una determinada cantidad de horas o de meses
acompaados de la respectiva probabilidad.
Diferenciar entre los tres modelos que componen el COCOMOII:
Composicin de Aplicacin (Application Composition), Proyecto Preliminar
(Early Design) y Pos arquitectura (Post-Architecture) y seleccionar aquellos
ms adecuados conforme al nivel de informacin disponible durante la
elaboracin de la estimacin.
Utilizar el punto de funcin como parmetro de costo primario del modelo y
realizar la evaluacin de los dems parmetros de costo secundarios relativos
al producto, al proceso, al personal.
Interpretar los resultados del modelo en trminos de cules actividades y en
qu fases del ciclo de vida de desarrollo estn siendo includas en las
estimaciones generadas; cules categoras de trabajo son consideradas en
los resultados; en qu puntos el modelo debe ser ledo como una referencia
de mercado y cules puntos deben necesariamente ser calibrados a las
condiciones locales de donde sern aplicados.

El curso no se limita a la operacin del modelo, permitiendo abordar asuntos sobre

su administracin. Por ello, al final del curso el participante debe ser capaz de:
Calibrar los porcentajes de esfuerzo y de plazo conforme la fase de
acompaamiento gerencial.
Escoger la mejor mtrica de calidad para evaluar y calibrar el modelo
considerando sus particularidades y cuales mtricas son ms adecuadas a la
poltica de la organizacin donde el modelo ser utilizado.
Calibrar el modelo utilizando como gua el libro "Software Cost Estimation
With COCOMO II" o complemento del Microsoft Excel "Solver".
Definir una poltica local con orientaciones para evaluacin cualitativa de
costo de personal, producto, plataforma y proceso.
 o QSM- SLIM

Software de gestin del ciclo de vida (SLIM) herramientas de QSM son el estndar
de oro en la industria y la mejor opcin para ms de 37 aos de Fortune 1000
empresas y gobiernos de todo el mundo. A partir de una base de datos de ms
de 13.000 proyectos de software verificar (el ms grande base de datos de este
tipo), nuestro software permite una mejor toma en cada etapa del proyecto de vida
de desarrollo del ciclo de estimacin, el seguimiento de la toma y anlisis de
mtricas. Cada herramienta est diseada para ofrecer resultados de gran
alcance, ya sea como una aplicacin independiente o como parte de la suite
integrada de QSM.
Con SLIM-Estimacin, sabr inmediatamente el costo, el tiempo y el esfuerzo
necesarios para adaptarse a cualquier conjunto de requisitos, y las mejores
estrategias para el diseo e implementacin de su proyecto.

SLIM-Estimacin utiliza un enfoque de arriba hacia abajo demostrado que reduce

al mnimo la informacin de entrada requerida para producir las estimaciones
defendibles, basada en hechos. Adems de la estimacin de costos de software,
de alto nivel de capacidad de configuracin de SLIM-Estimacin aloja diversos
procesos de diseo utilizados por los desarrolladores de hoy, incluyendo el
desarrollo gil, inteligencia de negocios, implementacin de paquetes, hardware,
desarrollo de centro de llamadas, la infraestructura, el desarrollo basado en
modelos, ingeniera y diseo de la arquitectura, la arquitectura orientada a
servicios, SAP, Oracle, y mucho ms.

EJERCICIO

Dentro de la realizacin de la modificacin de una aplicacin actual realizada

en Cobol se han contabilizado los siguientes parmetros significativos:

2 entradas de complejidad baja y una entrada de complejidad media

1 salida de complejidad media y dos salidas de complejidad alta
3 tipos de consultas de complejidad baja y dos tipos de consulta de
complejidad media
 Existe un fichero de interface externa de complejidad media Se utilizan
dos tablas internas de complejidad baja

Adems, existe una entrada online de datos; su atributo tiene un factor de

complejidad valorado como 4 en una escala de 0 a 5 y tambin existe una
Actualizacin online de datos cuyo atribuyo tiene un factor de complejidad
valorado en 3.