UNIVERSIDAD

TECNOLOGICA
INDOAMERICA
FACULTAD DE INGENIERIA EN SISTEMAS

DE LA
NOMBRES: FUNDAMENTOS
Eduardo Masaquiza
INGENIERIA
Diego
Ocampo DE SOFTWARE
Nicolas Ramos
Franklin Yucailla
Tutor.: Ing. Sergio Montes
TEMA: Estimacin de Proyectos de Software
NIVEL: Sexto Sistemas
2016

ESTIMACION PARA PROYECTOS DE SOFTWARE TIPOS, MODELO,

TECNICAS Y MODELO COCOMO
ESTIMACION
Estimar: cunto dinero, esfuerzo, recursos y tiempo supondr construir
un sistema o producto especfico de SW.

Antes de que el proyecto comience el gestor del proyecto y el equipo

de software deben estimar el trabajo que habr de realizarse, los recursos
que se requieran y el tiempo que transcurrir desde el principio hasta el
final.
ESTIMACION DE RECURSOS
Necesarios para completar el esfuerzo de desarrollo del software. En
figura 1 muestra las tres grandes categoras de los recursos de IS.

la

Cada recurso especifica cuatro caractersticas: Descripcin del recurso,

Un informe de disponibilidad, cuando se requerir el recurso, y tiempo
durante el cual el recurso se aplicar.

Recursos Humanos

El nmero de persona que requiere un proyecto de software solo se

determina despus de que se ha hecho una estimacin del esfuerzo de
desarrollo ejemplo (persona-mes).

Recurso de Software Reutilizable

La creacin y reutilizacin de bloques de construccin, tales bloques,

llamados componentes.
Bennatan sugiere cuatro categoras de recursos de software que deben
considerarse:
1.
2.
3.
4.

Componentes ya desarrollados
Componentes experimentados
Componentes
de
experiencia parcial
Componentes nuevos

RECURSOS DEL ENTORNO

Entorno de ingeniera del software (EIS) incorpora hardware y software.

Tcnicas de Estimacin de costos

Modelado algortmico del costo: Se desarrolla un modelo

informacin histrica relacionada a alguna mtrica de software.
Juicio Experto: Se consultan varios expertos en el dominio
aplicacin y en la tcnica de desarrollo de software escogida.

usando
de la

Estimacin por analoga: Esta tcnica es til si se han realizado otros

proyectos en el mismo dominio de la aplicacin.
La Ley de Parkinson: estable que el trabajo se expande hasta llenar el
tiempo disponible.
Precio a ganar: El costo se estima de acuerdo a lo que el consumidor
esta dispuesto a gastar.

Tcnicas de Descomposicin

Tamao de Software: se refiere a un resultado cuantificable del proyecto

de software. Enfoque directo: El tamao se puede medir en lneas de
cdigo (LDC). Enfoque indirecto: el tamao se representa como puntos de
funcin (PF).
La descomposicin basada en el problema implica el uso de KLOC y PF.
La descomposicin basada en el proceso incluye divisin basada en las
tareas involucradas, en casos de uso.

Estimacin basada en el problema

El planificador del proyecto comienza con un enfoque acotado del

mbito del software y a partir de ah intenta descomponer el software en
funciones problema que puedan estimarse individualmente.
Entonces se
cada funcin.

estima

las

LDC

PF

(las variables de estimacin) para

Se calcula un valor de tres puntos o uno esperado. El valor esperador

para la variable de estimacin. (Tamao), S, se calcula como un
promedio ponderado de las estimaciones optimista.

S=(S opt+ 4Sm+ Spes)/6

Por ejemplo, el rango de las estimaciones LDC para la funcin de anlisis

geomtrico 3D es:
optimist Mas
pesimist Valor
a
probabl a
esperad
e
4600 ldc 6900 ldc 8600 ldc o
6800

Se centra en los valores de dominio de informacin

funciones de software.

ms

que

en las

El planificador del proyecto estima entradas externas, salidas externas,

consultas externas, archivos lgicos internos y archivos de interfaz
externos para el software CAD.
Finalmente se deriva el nmero estimado de PF.

Estimacin Basada en el Proceso

Tcnica ms comn es basar la estimacin en el proceso que se empleara.

Este se descompone en tareas y estima el esfuerzo para lograr cada tarea.

Modelos Empricos de Estimacin

Basados en datos estadisticos

La mayora tiene una estructura con la forma:
Hay varios de estos modelos, uno de los mas populares ha sido el
creado por Bohem, COCOMO (Constructive Cost Model). Apareci en los
aos 80, y desde entonces ha sido muy popular.

Tipos de Modelos
1. Bsico
2. Intermedio
3. Avanzado
Tipos de Proyectos en COCOMO
Dentro de cada modelo COCOMO los proyectos se pueden clasificar de 3
tipos. Los tipos son:
Orgnico
(Fcil): Proyectos
desarrollados con grupos de trabajo
pequeos, en un ambiente familiar y construyendo aplicaciones que les son
familiares.
Semi-independiente (Intermedio):
orgnicos y de modo incorporado.

Etapa intermedia entre proyectos

De modo incorporado (Avanzado): Proyectos que deben operar dentro

de limitaciones estrictas. Dependiendo del tipo de proyecto, sern los
valores de las constantes que utilizar la frmula de COCOMO involucrada.
MODELO BASICO COCOMO
El modelo calcula 3 valores para estimar el costo del proyecto, esto
utilizando como entrada las lneas de cdigo estimadas. Los valores
estimados son:
1. MP: Meses-persona
2. TDES: Tiempo de desarrollo
3. N: Nmero de personas necesarias
Las frmulas utilizadas para realizar esta estimacin, dependern del tipo
de proyecto en cuestin.
Tecnicas de estimacion del IFPUG. Esta metodologa de medicin puede
resumirse en los siguientes siete pasos. Para profundizar mas sobre la
misma refierase a .
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 aplicacion que se esta
estimando). La frontera es el lmite entre el proyecto o aplicacion que esta
siendo medida y las aplicaciones externas o el dominio del usuario. Se
puede observar como los usuarios y las aplicaciones externas pueden
interactuar con la aplicacion a traves 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 Logicos Internos (en ingles
Internal Logical Files, ILF) y Archivos de Interfaz Externos (en ingles External
Interface Files, EIF).
El conteo fsico de ILF y EIF, junto con la complejidad relativa de cada uno,
determina la contribucion a los PF desajustados. Esta complejidad esta
determinada por el Numero 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 (tambien conocidos como entidades debiles de una tabla).
Paso 4 (Identificar todas las funciones transaccionales y su complejidad).
Las transacciones transaccionales se clasifican en Entradas Externas (en
ingles External Inputs, EI), Salidas Externas (en ingles External Outputs,
EO) y Consultas Externas (en ingles External Inquiries, EQ). El conteo fsico
de EI, EO y EQ, junto con la complejidad relativa de cada uno, determina la
contribucion a los PF desajustados. Esta complejidad esta determinada
por el numero de DET y de Archivos Referenciados (en ingles File Types
Referenced, FTR) asociados a cada transaccion.
Paso 5 (Determinar los Puntos de Funcion Sin Ajustar (PFSA)). Con la
informacion 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 transaccion 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 traves de 14
caractersticas generales, con el fin de adaptar la estimacion 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 analisis. El peso del
valor asignado esta entre 0 y 5: cero cuando el factor no presenta alguna
influencia en la aplicacion y cinco cuando el factor influye fuertemente.

BIBLIOGRAFIA
E. Mills. Software Metrics SEI Curriculum Module SEICM121.1,
ftp://ftp.sei.cmu.edu/pub/education/cm12.pdf, diciembre 1988. Referenciado
en 125
Roger S. Pressman. Ingeniera de software: un enfoque practico, 6ta edici
on, ISBN 9701054733. McGrawHill, 2005. Referenciado en 125, 126,
129, 136 |142 Ingeniera y Ciencia, ISSN 17949165 Gabriela SalazarB.
William A. Florac and Anita D. Carleton. Measuring the software process:
statistical process control for software process improvement, ISBN 0201
604442. AddisonWesley Professional, 1999. Referenciado en 125, 126
Stephen H. Kan. Metrics and models in software quality engineering, second
edition, ISBN 0201729156. Adisson wesley, 95456 (2002). Referenciado
en 126, 128, 135
Garmus and David Herron. Measuring the software process. A practical
guide to funcional measurements, ISBN 0201699443. Addison wesley,
2001. Referenciado en 128, 129, 130, 131, 135
Richard D. Stutzke. Estimating softwareintensive systems, ISBN 0201
70312 2. AddisonWesley Professional, 2005. Referenciado en 128
R. Lawrie. Using functional sizing in software projects estimating.
http://www.charismatek.com, Charismatek software metrics, Australia, 2002.
Referenciado en 132, 134