Estimacion Costos PDF

2 Métodos de estimación y costos de SW
Gestión del El proceso de gestión del proyecto comienza con un conjunto de actividades
proyecto que globalmente, se denominan planificación del proyecto.
La gestión eficaz de un proyecto de software se centra en las cuatro P’s:
personal, producto, proceso y proyecto. El orden no es arbitrario. El gestor
que se olvida de que el trabajo de ingeniería de software es un esfuerzo
humano intenso nunca tendrá éxito en la gestión de proyectos. Un gestor que
no fomenta una minuciosa comunicación con el cliente al principio de la
evolución del proyecto corre el riesgo de construir una elegante solución para
un problema equivocado.
Producto
Características Condiciones del

del cliente negocio
Proceso
Entorno de Tecnología
Personas desarrollo
Determinantes de la calidad del software y de la

efectividad de organización
Estimación La estimación de recursos, costos y agendas para el esfuerzo de desarrollo de

Software requiere experiencia, acceso a una buena información histórica y
coraje para confiar en medidas cuantitativas cuando todo lo que existe son
datos cualitativos.
Grado de estructuración definición

Ámbito de bajo riesgo y variabilidad
Complejidad basada
en esfuerzos pasados Tamaño del
esfuerzo
Continúa en la siguiente página
2 Universidad Tecnológica de Jalisco

Manual de Análisis y diseño II. Maestro
Planificación, Continuación
En la figura anterior se ilustran los factores que aumentan el riesgo. Los ejes
de la figura corresponden a las características del proyecto a estimar.
La complejidad Tiene efecto sobre la incertidumbre, que es inherente a la planificación. La

del proyecto complejidad es una medida relativa que se ve afectada por la familiaridad con
anteriores esfuerzos (dependiendo de qué tipo de aplicaciones haya
desarrollado un equipo de trabajo anteriormente “tiempo real”, no
interactivas, etc).
Tamaño del Afecta la precisión y la eficacia de las estimaciones. Al aumentar el tamaño,

proyecto aumenta la interdependencia entre los módulos. La técnica de descomposición
de los módulos no se aplica fácilmente porque pueden seguir siendo
demasiado grandes.
Grado de La estructuración se refiere a la facilidad con la que las funciones pueden

estructuración compartirse y la naturaleza jerárquica de la información que debe ser
procesada. A medida que aumenta la estructuración, la posibilidad de estimar
con precisión aumenta.
La disponibilidad de información histórica también determina el riesgo de la

estimación. Mejorar antes de que surjan los problemas.
El riesgo Se mide por el grado de incertidumbre de las estimaciones cuantitativas

establecidas para los recursos, los costos y las agendas. (Especificación del
sistema: se debe tener en cuenta que cualquier cambio en los requisitos de
Software significa inestabilidad en los costos y en la agenda de trabajo).
Objetivos de la Es proporcionar un marco de trabajo que permita al gestor hacer estimaciones

planificación de razonables de recursos, coste y planificación temporal. Se hacen dentro de un
proyectos marco de tiempo limitado al comienzo de un proyecto de software, y deberían
actualizarse regularmente a medida que progresa el proyecto.
Academia de Ingeniería de Software 3

Ana E. Romo González
Recursos Estimación de recursos requeridos para acometer el esfuerzo del desarrollo de
Software. Cada recurso queda especificado mediante 4 características:
• Descripción del recurso

• Informe de disponibilidad
• Fecha cronológica en la que se requiere
Tiempo durante el que será aplicado
Especificar
• Habilidades requeridas
• Disponibilidad
Gente • Duración de las tareas
• Fecha de comienzo
Herramientas Especificar
HW/SW • Descripción
• Disponibilidad
• Duración del uso
• Fecha de distribución
Recursos Se evalúa el ámbito y se seleccionan las habilidades técnicas que se requieren

humanos para el desarrollo.
Especificar:
1. Posición dentro de la organización (ing. de Software, señor, etc),
2. Especialidad (Telecomunicaciones, bases de datos, etc.)
El número de personas requerido para el proyecto de Software, sólo puede ser

determinado después de hacer una estimación del esfuerzo de desarrollo.
Recursos de Considerar:
hardware 1. Sistema de desarrollo
2. Máquina objetivo
3. Demás elementos del nuevo sistema
Sistema de desarrollo: Llamado sistema anfitrión está compuesto por la

computadora que se empleará durante el desarrollo y sus periféricos.
Máquina objetivo: En que tipos de máquina se ejecutará el sistema.
Demás elementos del nuevo sistema: Lectores de código de barras,

impresoras térmicas, etc.

¡Error! No hay texto con el estilo especificado en el documento.
Métricas de El proceso del software y las métricas del producto son una medida
estimación y cuantitativa que permite a la gente del software tener una visión profunda de
costos la eficacia del proceso del software y de los proyectos que dirigen utilizando
el proceso como un marco de referencia.
La productividad en un sistema de manufactura se mide contando el número

de unidades que se producen y dividiendo éste entre el número de personas-
hora requeridas para producirlas. Sin embargo, para cualquier problema de
software, existen muchas soluciones diferentes con distintos atributos.
Sin embargo, los administradores tienen que estimar la productividad de los

ingenieros en el proceso de desarrollo de software. Estas estimaciones son
necesarias para la estimación del proyecto y para valorar si los procesos o las
mejoras tecnológicas son efectivas.
Para realizar estimaciones seguras de costes y esfuerzos tenemos varias

opciones posibles:
1. Dejar la estimación para más adelante

2. Basar las estimaciones en proyectos similares ya terminados
3. Utilizar técnicas de descomposición relativamente sencillas para
generar las estimaciones de coste y de esfuerzo del proyecto.
4. Utilizar uno o más modelos empíricos para la estimación del coste
y esfuerzo del software.
La primera opción no es practica las estimaciones deben ser a priori. La

segunda opción e razonable si el proyecto es bastante similar, las opciones
restantes con métodos viables para la estimación del proyecto de software,
utilizan un enfoque de divide y vencerás y se pueden utilizar los modelos
empíricos de estimación como complemento de las técnicas de
descomposición.
Mediciones de Métricas orientadas al tamaño

SW Métricas orientadas a la función
Métricas ampliadas de puntos de función
Técnicas de descomposición
o Tamaño del SW
o Basada en el problema
o Basada en el proceso
Modelos empíricos de estimación (COCOMO)
Desarrollar/comprar

1. Métricas Éstas se relacionan con el tamaño de alguna salida de una actividad. La
orientadas al medida más común relacionada con el tamaño son las líneas de código fuente
entregadas.
tamaño
Provienen de la normalización de las medidas de calidad y/o productividad
considerando el “tamaño” del SW que se ha producido. Crear una tabla:
P ro y ecto LDC E sfu erzo C o sto P a g.D o c. E rrores D efecto s P erson al

$ (0 00 )
A lfa 12 ,10 0 24 168 3 65 1 34 29 3
B eta 27 ,20 0 62 440 12 24 3 21 86 5
G am m a 20 ,20 0 43 314 10 50 2 56 64 6
.
.
.
Proyecto Alfa: desarrollaron 12,100 líneas de código con 24 personas-mes, con un costo 168,000
(A,D,C,P), 365 páginas de documentación, registraron 134 errores de SW y 29 después de entregarse
dentro del 1er. Año de utilización, 3 personas. Para desarrollar métricas se comparan de distintos
proyectos y se sacan normalización.
Comparar la productividad de los diferentes lenguajes de programación

también da impresiones engañosas de productividad del programador. Entre
más expresivo sea un lenguaje de programación, más baja es la productividad
aparente.
Una alternativa a la utilización del tamaño del código como atributo estimado
del producto es utilizar alguna medida de la funcionalidad del código.
Métricas Fueron propuestos por Albrecht (1979) y refinados por Albrecht y Gaffney
orientadas a la (1983). Los puntos de función son independientes del lenguaje por lo que se
función puede comparar la productividad en los diversos lenguajes de programación.
Utilizan una medida de funcionalidad entregada por la aplicación como un

valor de normalización. Ya que la funcionalidad no se puede medir
directamente. Los PDF se derivan con una relación empírica según las
medidas contables (directas) del dominio de información y las evaluaciones
de la complejidad del Software

Métricas orientadas a la función, Continuación
Se determinan 5 características del dominio de la información y se

proporcionan las cuentas en la posición apropiada de la tabla.
• Número de entradas del usuario. Se cuenta cada entrada del usuario

que proporciona diferentes datos orientados a la aplicación. Las
entradas se deben diferenciar de peticiones.
• Número de salidas. Se cuenta cada salida que proporciona al usuario

información orientada a la aplicación. En este contexto la salida se
refiere a informes, pantallas, mensajes de error, etc. Los elementos de
datos de particulares dentro de un informe se cuentan de forma
separada.
• Número de peticiones del usuario. Se define como una entrada

interactiva que produce la generación de alguna respuesta del
Software inmediata en forma de salida interactiva.
• Numero de archivos. Se cuenta cada archivo maestro lógico de datos

que puede ser una parte de una gran base de datos o un archivo
independiente.
• Número de interfaces externas. Se cuentas todas las interfaces

legibles por la máquina (Archivos o cintas) que se utilizan para
transmitir información a otro sistema.
Una vez que se han recopilado los datos anteriores, a la cuenta se asocia un
valor de complejidad y se le asigna un valor de peso que varía desde 3 (para
las entradas externas sencillas) hasta 15 (para archivos internos complejos).
Las organizaciones que utilizan métodos de puntos de función desarrollan
criterios para determinar si una entrada en particular es simple, media o
compleja. No obstante la determinación de la complejidad es algo subjetiva.

Tabla de Factor de ponderación
puntos de Parámetros Cuenta Simple Medio Complejo
función de medici ón
Número de
entradas de X 3 4 6 =
usuario
Número de
salidas de X 4 5 7 =
(Problema usuario
abierto) Número de
peticiones de X 3 4 6 =
usuario
Número de
Ejercicio 1 archivos X 7 10 15 =
Número de
interfaces X 5 7 10 =
externas
Cuenta total
Cálculos de Para calcular puntos de función se utiliza la siguiente relación:

puntos de PF = cuenta total X [0.65 + 0.01 X ∑ ( Fi )]
función en donde, cuenta total es la suma de todas las entradas PF obtenidas.
Fi (i = 1 a 14) son “Valores de ajuste de la complejidad” según las respuestas de las siguientes preguntas:
1.¿Requiere el sistema copias de seguridad y de recuperación fiables?
2.¿Se requiere comunicación de datos?
3.¿Existen funciones de procesamiento distribuido?
4.¿Es crítico el rendimiento?
5.¿Se ejecutará el sistema en un entrono operativo existente y fuertemente utilizado?
6.¿Requiere el sistema entrada de datos interactiva?
7.¿Requiere la entrada de datos interactiva que las transacciones de entrada se lleven a cabo sobre múltiples pantallas
u operaciones?
8.¿Se actualizan los archivos maestros en forma interactiva?
9.¿Son complejas las entradas, las salidas, los archivos o las peticiones?
10.¿Es complejo el procesamiento interno?
11.¿Se ha diseñado el código para ser reutilizable?
12.¿Están incluidas en el diseño la conversión y la instalación?
13.¿Se ha diseñado el sistema permitir múltiples instalaciones en diferentes organizaciones?
14.¿Se ha diseñado la aplicación para facilitar los cambios y para ser fácilmente utilizada por el usuario?
Cada una de las preguntas anteriores es respondida usando una escala con rangos desde 0 (no importante o
aplicable) hasta 5 (absolutamente esencial) .
0: Sin influencia, 1: Incidental, 2: Moderado, 3: Medio, 4: Significativo, 5: Esencial
Resultado del PF =
ejercicio 1
Los valores constantes de la ecuación y los factores de peso que se aplican a
las cuentas de los dominios de información se determinan empíricamente.
Una vez que se han calculado los puntos de función, se utilizan de forma análoga a
las LDC como forma de normalizar las medidas de productividad, calidad y otros
atributos del software.

Métricas orientadas a la función, Continuación
Puntos de La medida de punto de función Enfatiza la dimensión de datos (los valores de

función dominios de información de PF) para la exclusión de dimensiones (control)
ampliados funcionales y de comportamiento.
Una extensión se denomina puntos de característica (alta complejidad en los

algoritmos), los valores de dominio de información se cuentan otra vez y se
pesan como en el modelo anterior. Además cuenta otra característica del
Software – los algoritmos – Un algoritmo se define como: un problema de
cálculo limitado que se incluye dentro de un programa de computadora
específico, ejem. Invertir una matriz, manejar una interrupción, etc.
Otra extensión propuesta por Boeing se denomina Punto de función 3D
adecuada a aplicaciones que enfatizan las capacidades de control y función.
Evalúa la dimensión de datos exactamente igual al modelo anterior. Las
cuentas de datos retenidos (ejem. Archivos), y los datos externos (entradas,
salidas, peticiones).
La dimensión funcional: se mide considerando el número de operaciones
internas requeridas para transformar datos de entrada en datos de salida.
La dimensión de control: se mide contando el número de transiciones entre
estados.
La siguiente tabla proporciona estimaciones del número medio de líneas de
código que se requieren para construir un punto de función
Lenguaje de programación LDC / PF (media)

Ensamblador 320
C 128
COBOL 106
FORTRAN 106
Pascal 90
C++ 64
Ada95 53
Visual Basic 32
Small Talk 22
PowerBuilder (generador de código) 16
SQL 12
Los conteos de los puntos de función se pueden utilizar junto con las técnicas
de estimación de líneas de código. Se utiliza para estimar el tamaño final del
código como el número promedio de líneas de código (LCP):
Tamaño del código = LCP x Número de puntos de función.
Productividad = PF / personas-mes
Calidad = errores / PF
Costo = pesos / PF
Documentos = Pag. Doc. / PF
Esfuerzo = PF / ProdMedia (personas-mes)
Técnicas de Consisten en descomponer el problema, volviéndolo a definir como un
descomposición conjunto de pequeños problemas. Ya que en la mayoría de los casos el
problema a resolver es demasiado complejo, para considerarlo como un todo.
Tamaño del El tamaño representa el primer reto importante del planificador de proyectos.
software En el contexto de la planificación de proyectos, el tamaño se refiere a una
producción cuantificable del proyecto de software. Si se toma un enfoque
directo, el tamaño se puede medir en LDC. Si se selecciona un enfoque
indirecto, el tamaño se representa como PF.
Varios métodos combinan estadísticamente para crear una estimación de tres

puntos o del valor esperado. Esto se lleva a cabo desarrollando valores de
tamaño optimista (bajos), y más probables, y pesimistas (bajos), y se
combinan utilizando la ecuación de PF.
VE = ( S opt + 4 S m + S pess ) / 6
NOTA: Ver la Técnica de descomposición Estimación basada en el problema
Calcular tamaño del software con Puntos de Función
Ejercicio 2 Parámetros Optimista Más probable Pesimista VE

de medición
Número. de
entradas
Número de
salidas
Número de
peticiones
Número de
archivos
Número de
interfaces
externas
Emplear la tabla de Puntos de función del problema 1, sustituyendo
PF =

Estimación El planificador de proyecto comienza con un enfoque limitado para el ámbito del
basada en el software y desde este estado intenta descomponer el software en funciones que se
problema pueden estimar individualmente. Estimando para cada función las LDC y PF. En
general, el dominio del proyecto debería calcular las medias de LDC/pm o PF/pm,
agrupando los proyectos por tamaño, área de aplicación o complejidad y otros
parámetros relevantes.
El planificador estima un valor de tamaño optimista, más probable y

pesimista para cada función. Entonces se calcula un valor de tres puntos o
esperado. El valor esperado de la variable de estimación (tamaño), VE, se
puede calcular como una media ponderada:
siendo S opt = Estimaciones optimistas
Sm = Estimaciones probables
S pess = estimaciones pesimistas
Una vez determinado el valor esperado de la variable de estimación, se aplican datos

históricos de productividad y LDC y PF.
Ámbito del Desarrollo de un paquete de software para una aplicación de diseño asistido por computadora CAD.
El software de CAD aceptará del ingeniero de datos de geometría bi – y tri-dimensional. El ingeniero controlará e
problema interactuará con el sistema CAD a través de una interfaz de usuario que exhibirá características de un buen diseño
hombre-máquina. Todos los datos geométricos y cualquier información adicional se mantendrán en una base de datos
de CAD. Los módulos de análisis del diseño se desarrollarán de forma que produzcan la salida requerida en una forma
que pueda ser mostrada en una gran variedad de dispositivos gráficos. El software estará diseñado para poder
Ejercicio 3 controlar e interactuar con dispositivos periféricos tales como un ratón, un digitalizar, una impresora láser y un
trazador.
Tabla de estimación de LDC
Función OP MP PES $/L Costo Mes

L/mes
VE
es
Control de interfaz de
usuario
Análisis geométrico
bidimensional
Análisis geométrico
tridimensional
Gestión de estructura de
datos
Visualización de gráficos
Control de periféricos
Análisis de diseño
Total * * *

Estimación La técnica más común para estimar un proyecto es basar la estimación en el
basada en el proceso que se va a utilizar. Descomponer el proceso en un conjunto de
proceso actividades o tareas, y en el esfuerzo requerido para llevar a cabo la
estimación de cada tarea.
Esta técnica comienza con un esbozo de las funciones del software obtenidas
a partir del ámbito del proyecto. Para cada función se debe llevar a cabo una
serie de actividades del proceso de software. Las funciones y las actividades
del proceso de software relacionadas se pueden representar como parte de una
tabla similar a la siguiente:
El planificador estima el esfuerzo (personas/mes) que se requerirá para llevar

a cabo cada una de las actividades del proceso de software en cada función.
Tabla de estimación basada en el

proyecto
Actividad Análisis
Construcción
CC Planificación de Ingeniería EC Totales
entrega
riesgo
Tarea Análisis Diseño Código Prueba
Función
IUFC 0.50 2.50 0.40 5.00 n/a 8.40

AG2D 0.75 4.00 0.60 2.00 n/a 7.35
AG3D 0.50 4.00 1.00 3.00 n/a 8.50
FPGC 0.50 3.00 1.00 1.50 n/a 6.00
GBD 0.50 3.00 0.75 1.50 n/a 5.75
CP 0.25 2.00 0.50 1.50 n/a 4.25
MAD 0.50 2.00 0.50 2.00 n/a 5.00
Totales 0.25 0.25 0.25 3.50 20.50 4.75 16.50 45.25
%Esfuerz 1% 1% 1% 8% 45% 10% 36%

o
CC = Comunicación cliente EC= Evaluación cliente

Como último paso se calculan los costes y el esfuerzo de cada función, y la
actividad del proceso de software. Si la estimación basada en el proceso se
realiza independientemente de la estimación de LDC o PF, ahora tendremos
dos o tres estimaciones del coste y del esfuerzo que se pueden comparar y
evaluar.
Modelos Un modelo de estimación para el software de computadora utiliza fórmulas

empíricos de derivadas empíricamente para redecir el esfuerzo como una función de LDC
estimación o PF.
Un modelo común de estimación se extrae utilizando el análisis de regresión

sobre los datos recopilados de proyectos de software anteriores.
La mayoría de los modelos de estimación tienen algún componente de ajuste

del proyecto que permite ajustar el esfuerzo en personas-mes (E), por
ejemplo, la complejidad del problema, experiencia del personal, entorno de
desarrollo).
El modelo Barry Boehm, en su libro sobre economía de la ingeniería de software, introduce

COCOMO una jerarquía de modelos de estimación de software con el nombre de
COCOMO (Constructive Cost Model). El modelo COCOMO original (conocida
como COCOMO 81) se ha convertido en uno de los modelos de estimación
de coste del software más utilizados y estudiados de la industria. La primera
versión del modelo COCOMO fue un modelo de tres niveles donde éstos
reflejaban el detalle del análisis de la estimación del costo. El primer nivel
(básico) provee una estimación inicial burda, el segundo nivel la modifica
utilizando varios multiplicadores del proyecto y del proceso, y el nivel más
detallado produce estimaciones para las diferentes fases del proyecto.
Tipos de 1. Modo Orgánico. Proyectos de software relativamente pequeños y

proyectos en sencillos en los que trabajan pequeños equipos, con buena
COCOMO experiencia en la aplicación, sobre un conjunto de requisitos poco
rígidos.
2. Modo semiacoplado. Proyectos de software intermedios (en tamaño y
complejidad) en los que equipos, con variados niveles de experiencia,
deben satisfacer requisitos poco o medio rígidos.
3. Modo empotrado. Proyectos de software que deben ser desarrollados
en un conjunto de hardware, software y restricciones operativas muy
restringido.

Ecuaciones de COCOMO (Constructive Cost MOdel)
COCOMO E=ab(KLDC)exp(bb)
básico D=cb(E) exp (db)
N=E/D
Tabla de
COCOMO
básico Proyecto ab bb cb db
Orgánico 2.4 1.05 2.5 0.38
Semi
acoplado 3.0 1.12 2.5 0.35
Empotrado 3.6 1.20 2.5 0.32
Calcular COCOMO básico para el problema del sistema CAD del ejercicio 3
Ejercicio 4 E=
D=
N=
El punto objeto Es una medida indirecta de software (cuando se utilizan 4GLs o lenguajes
comparables para el desarrollo de software) que se calcula utilizando el total
de (1) pantallas (de la interfase de usuario), (2) informes, y (3) componentes
que probablemente se necesiten para construir la aplicación. Son una
estimación con peso:
1. El número de pantallas independientes que se despliegan. Pantallas

sencillas cuentan como 1 PO (Punto de objeto), las
moderadamente complejas como 2 PO y las muy complejas como
3 PO.
2. El número de informes que se producen. Para informes simples,
cuentan como 2 PO, para informes moderadamente complejos 5
PO y para informes difíciles de producir 8 PO.
3. El número de módulos 3GL que deben desarrollarse para
complementar el código 4GL. Cada módulo 3GL cuenta como 10
PO.

Tabla para el
cálculo del PO Tipo de objeto Peso de la complejidad
Básico Intermedio Avanzado
Pantalla 1 2 3
Informe 2 5 8
Componente 3GL 10
Una vez que se ha determinado la complejidad, se valora el número de

pantallas, informes y componentes. La cuenta de punto objeto se determina
multiplicando el número original de instancias de objeto por el factor de peso
y se suman para obtener la cuenta total del punto objeto.
Calcular PO para el Sistema CAD del ejercicio 3
Ejercicio 5 PO =
Punto objeto Cuando se va a aplicar el desarrollo basado en componentes o la

nuevo reutilización de software en general, se estima el porcentaje de reutilización
(% reutilización) y se ajusta la cuenta del punto objeto:
PON = (puntos objeto) x [(100 - % reutilización) /100]

Donde PON = Puntos objeto nuevos
Esfuerzo con Para obtener una estimación del esfuerzo basado en el valor PON calculado.
punto objeto Se debe calcular la proporción de productividad para los diferentes niveles de
nuevo experiencia del desarrollador y de madurez del entorno de desarrollo. Una
vez determinada la proporción de productividad, se puede obtener una
estimación del esfuerzo del proyecto. Mediante la siguiente tabla:
Experiencia / Muy Baja Normal Alta Muy alta

capacidad del baja
desarrollador
Madurez/
Muy
capacidad del Baja Normal Alta Muy alta
baja
entorno
PROD 4 7 13 25 50
Esfuerzo estimado = PON / PROD

Donde PROD = es la productividad.

Calcular PON tomando en cuenta el ejercicio 5
Ejercicio 6 PON =
La decisión de En muchas áreas de aplicación del software, a menudo es más rentable

desarrollar- adquirir el software de computadora que desarrollarlo. En una decisión de
comprar desarrollarlo o comprarlo se pueden complicar aún más con las opciones de
adquisición: (1) el software se puede comprar (con licencia) ya desarrollado;
(2) se pueden adquirir componentes de software totalmente experimentado o
parcialmente experimentado y modificarse e integrarse para cumplir las
necesidades especificas. O (3) el software puede ser construido de forma
personalizada por una empresa externa.

Proyecto 1 La Universidad Tecnológica de Jalisco, aplica diferentes Test psicométricos a los alumnos que
ingresan a la institución, con la intención de definir un perfil que permita apoyar el programa de
tutorias y la colocación de alumnos en estadías.
El sistema actual permite dar de alta alumnos de manera externa mediante el código del alumno,
proporcionado por servicios escolares, pero no cuenta con facilidades para el mantenimiento debido
a que los requerimientos originales especificaba que la información la proporcionaría servicios
escolares mediante un acceso a su base de datos.
La herramienta (SEP) Sistema de Evaluación Psicométrica, permite realizar la calificación
automatizada de 3 test psicométricos, una vez que se ha presentado la aplicación. Estos son:
Sistema SEP o Dominos. Mide CI

o 16 FP. Mide 16 factores de personalidad
o Terman. Mide CI y capacidad de aprendizaje
Éste último no se aplica debido a que no aporta información relevante para la institución. El sistema
genera reportes que son resultado de la evaluación. Fue desarrollado en Cbuilder.
Del sistema actual solamente se cuenta con el código ejecutable por lo que se necesita reingeniería.
Los nuevos requerimientos especifican que se permita el mantenimiento de alumnos (altas, bajas,
modificaciones, consultas), seguridad en el sistema, así como el cálculo automatizado de otros 2
test:
o Raven (inteligencia)
o Encuesta de hábitos y actitudes hacia el estudio.
Del primero aún no se realiza la aplicación manualmente. No se cuenta con documentación que
permita darle mantenimiento.
Proyecto 2 El Sistema Estadístico de Ingreso a Exposiciones (SIEI) genera estadísticas de visitantes a

exposiciones. Debe permitir la captura de datos fijos (nombre, domicilio, teléfono, correo
electrónico, etc.) de los visitantes y la captura de datos variables (preguntas específicas de cada
exposición, las cuales podrán ser abiertas ¿XYZ? o de selección múltiple.
El sistema deberá contar con un módulo de configuración para cada expo, y uno de mantenimiento
para preguntas, solicitando la pregunta y las posibles opciones. Deberá generar gráficas de cada
pregunta con un resumen de respuestas de las que hayan sido abiertas. El Software recibe
información de entrada de las capturistas que deberán entregar un formato a cada visitante e
Sistema SEIE imprimirá una etiqueta de acceso a la exposición con el nombre del visitante y un folio. Podrá
interrumpirse la captura de datos para continuar posteriormente con las repuestas del visitante.
Se mantendrá el control de acceso de usuarios con 3 categorías:
1. Mantenimiento. Instala el sistema y puede dar de alta preguntas

2. Capturista
3. Empresario. Verifica estadísticas e imprime.

Factor de ponderación
Parámetros Cuenta Simple Medio Complejo

de medici ón
Número de
Calcular PF entradas de X 3 4 6 =
usuario
Número de
salidas de X 4 5 7 =
usuario
Número de
peticiones de X 3 4 6 =
usuario
Número de
archivos X 7 10 15 =
Número de
interfaces X 5 7 10 =
externas
Cuenta total
Para calcular puntos de función se utiliza la siguiente relación:

PF = cuenta total X [0.65 + 0.01 X ∑ ( Fi )]
en donde, cuenta total es la suma de todas las entradas PF obtenidas.
Fi (i = 1 a 14) son “Valores de ajuste de la complejidad” según las respuestas de las siguientes preguntas:
1.¿Requiere el sistema copias de seguridad y de recuperación fiables?
2.¿Se requiere comunicación de datos?
3.¿Existen funciones de procesamiento distribuido?
4.¿Es crítico el rendimiento?
5.¿Se ejecutará el sistema en un entrono operativo existente y fuertemente utilizado?
6.¿Requiere el sistema entrada de datos interactiva?
7.¿Requiere la entrada de datos interactiva que las transacciones de entrada se lleven a cabo sobre múltiples pantallas
u operaciones?
8.¿Se actualizan los archivos maestros en forma interactiva?
9.¿Son complejas las entradas, las salidas, los archivos o las peticiones?
10.¿Es complejo el procesamiento interno?
11.¿Se ha diseñado el código para ser reutilizable?
12.¿Están incluidas en el diseño la conversión y la instalación?
13.¿Se ha diseñado el sistema permitir múltiples instalaciones en diferentes organizaciones?
14.¿Se ha diseñado la aplicación para facilitar los cambios y para ser fácilmente utilizada por el usuario?
Cada una de las preguntas anteriores es respondida usando una escala con rangos desde 0 (no importante o
aplicable) hasta 5 (absolutamente esencial) .
0: Sin influencia, 1: Incidental, 2: Moderado, 3: Medio, 4: Significativo, 5: Esencial
PF=

VE = ( S opt + 4 S m + S pess ) / 6
Calcular
tamaño del Parámetros Optimista Más probable Pesimista VE
software con de medición
PF Número. de
entradas
Número de
salidas
Número de
peticiones
Número de
archivos
Número de
interfaces
externas
PF =

Divida el ámbito del proyecto en por lo menos 6 funciones y calcule LDC
Calcular LDC
Función OP MP PES $/L Costo Mes

L/mes
VE
es
Total * * *

Seleccione un tipo de proyecto, tome los valores de la tabla y calcule
COCOMO básico
Calculo de
COCOMO E=ab(KLDC)exp(bb)
D=cb(E) exp (db)
N=E/D
E=
D=
N=
Tipo de objeto Peso de la complejidad

Calcule Punto Básico Intermedio Avanzado
objeto y punto Pantalla 1 2 3
objeto nuevo Informe 2 5 8
Componente 3GL 10
PO =
PON = (puntos objeto) x [(100 - % reutilización) /100]
PON =

3. Reingeniería de Software e ingeniería de reversa
Sistemas Son sistemas de SW tradicionales esenciales para el apoyo a negocios. Las

heredados compañías de apoyan en estos sistemas por lo que conviene mantenerlos en
operación.
Antecedentes La cantidad de código en los sistemas heredados es inmensa. En 1990, se

estimó que existían 120 mil millones de líneas de código. Se escribieron en
COBOL, o FORTRAN.
Desde 1990, ha habido un gran incremento en la utilización de las
computadoras para el apoyo de los procesos de negocios. Por lo tanto, se
estima que debe haber alrededor de 250 mil millones de líneas de código
fuente en existencia que requieren mantenimiento. Muchas de estas líneas no
están escritas en lenguajes orientados a objetos y aún se ejecutan en
computadoras mainframe.
Reingeniería Se refiere a reimplementar sistemas heredados para hacerlos más
de SW mantenibles.
La reingeniería comprende la redocumentación del sistema, la organización

y reestructura del sistema, la traducción del sistema a un lenguaje de
programación más moderno y la modificación y actualización de la estructura
y los valores de los datos del sistema. La funcionalidad del software no se
cambia y, normalmente, la arquitectura del sistema también permanece igual.
Ventajas de la a. Riesgo reducido Existe un alto riesgo en volver a desarrollar software

reingeniería esencial para una organización. Se cometen errores en la
especificación del sistema, existen problemas en el desarrollo,
etcétera.
b. Costo reducido El costo de la reingeniería es mucho menor que los

costos de desarrollar nuevo software. Puede ser 4 veces menos costoso
que reescribir el sistema.
Ingeniería
directa y
reingeniería

Posible proceso de
reingeniería
El proceso de 1.- Traducción del código fuente El programa se convierte de un lenguaje de

reingeniería programación antiguo a una versión más moderna del mismo lenguaje o a un
lenguaje diferente.
2. Ingeniería inversa Se analiza el programa y se extrae información de él, la
cual ayuda a documentar su organización y funcionalidad.
3. Mejora de la estructura del programa Se analiza y modifica la estructura de
control del programa para hacerlo más fácil de leer y comprender.
4. Modularización del programa Donde sea apropiado, se agrupan las partes
relacionadas del programa y la redundancia se elimina. En algunos casos, esta
etapa comprende la transformación arquitectónica.
5. Reingeniería de datos Se cambian los datos procesados por el programa
para reflejar los cambios en él.
Enfoques de la
reingeniería

Factores 1. La calidad del software al que se aplica reingeniería. Entre más baja sea la
principales que calidad del software y de su documentación asociada (si existe), más altos
afectan los serán los costos de la reingeniería.
costos 2. Las herramientas de apoyo disponibles para la reingeniería. Normalmente
no es costeable hacer reingeniería a un sistema de software a menos que se
utilicen herramientas CASE para automatizar muchos de los cambios en el
programa.
3. La amplitud de la conversión de datos requerida Si la reingeniería requiere
que se conviertan grandes volúmenes de datos, entonces los costos del
proceso se incrementan significativamente.
4. La disponibilidad de personal experto Si el personal responsable de
dar mantenimiento al sistema no se involucra en el proceso de
reingeniería, esto incrementará los costos. Los ingenieros
encargados de la reingeniería tienen que invertir gran cantidad de
tiempo para comprender el sistema.
1. Traducción del código fuente
Traducción 1. Actualización de la plataforma de hardware. La organización desea

cambiar su plataforma estándar de hardware. Los compiladores para el
del código lenguaje original pueden no estar disponibles para el nuevo hardware.
fuente por 2. Debilidad en las habilidades del personal. Existe una falta de personal de
niveles mantenimiento capacitado para el lenguaje original. Este problema es muy
importante cuando los programas se escribieron en un lenguaje no estándar
que está fuera de circulación.
3. Cambios en las políticas organizacionales. Una organización decide
adoptar un estándar para un lenguaje de programación con el fin de minimizar
los costos del software de ayuda. Dar mantenimiento a muchas versiones de
los compiladores antiguos es muy costoso.
4. Falta de software de apoyo. Los proveedores del compilador de lenguaje
están fuera de circulación de los negocios o no existe continuidad en el apoyo
de este producto.

2. Ingeniería La ingeniería inversa es el proceso de analizar el software con el objetivo de
inversa recuperar su diseño y especificación. El programa mismo no cambia por el
proceso de ingeniería inversa.
1.Se puede aplicar ingeniería inversa al diseño y a la especificación de un

sistema existente por lo que éstos pueden servir como una entrada a la
especificación de requerimientos para la sustitución del programa.
2.De forma alternativa, se puede aplicar ingeniería inversa al diseño y a la

especificación para que sirvan como ayuda al mantenimiento del programa.
Con esta información adicional, no es necesario aplicar la reingeniería al
código del sistema.
El proceso de ingeniería
inversa
3. Mejora de la La necesidad de optimizar la utilización de la memoria y la falta de

estructura del comprensión de la ingeniería de software por varios programadores han
programa generado que muchos sistemas heredados no estén bien estructurados.
Su estructura de control está enmarañada con muchas ramas no condicionales
y lógica de control no intuitiva. Esta estructura también se ha degradado por
el mantenimiento regular.
Los cambios al programa han hecho que algún código no sea alcanzable, pero
esto sólo se descubre después de un análisis profundo.
A menudo, los programadores del mantenimiento no se atreven a remover el
código en el caso de que se acceda a él de forma indirecta.
Simplificación Condición compleja

de la condición
if not (A > B and (C < D or not E > F) ) )...
Condición simplificada

Reestructuración automatizada
de programas
Problemas de la 1.Pérdida de comentarios Si el programa tiene líneas de comentarios,

reestructuració invariablemente éstas se pierden como parte del proceso de reestructuración.
n automatizada
de programas 2. Pérdida de documentación De forma similar, se pierde la correspondencia
entre la documentación de programas externos y el programa. Sin embargo,
en muchos casos los comentarios y la documentación de un programa no
están actualizados, por lo que esto no es un factor importante.
3. Demandas de computación pesadas Los algoritmos incrustados en las

herramientas de reestructuración son complejos. Aun con el hardware
moderno y rápido se puede llevar mucho tiempo completar el proceso de
reestructuración para programas grandes.
Métricas para o la tasa de caídas;

identificar
programas
candidatos a
o el porcentaje de código fuente que cambia por año;
reestructuración
o la complejidad del componente.
Otros factores, como el grado de cumplimiento de los estándares actuales de

los programas o componentes, se deben tomar en cuenta al tomar las
decisiones sobre reestructuración.
4. La modularización del programa es el proceso de reorganizar un programa
Modularización con el fin de que las partes relacionadas se ubiquen conjuntamente y se
del programa consideren como un solo módulo.
Una vez hecho esto, es más fácil eliminar las redundancias en estos
componentes relacionados, optimizar sus interacciones y simplificar su
interfaz con el resto del programa.
Si el sistema se distribuye, los módulos creados se encapsulan como objetos y
se acceden a través de una interfaz común.

Tipos de 1.Abstracciones de datos Éstos son tipos de datos abstractos creados al
módulos que se asociar los datos con componentes del procesamiento.
crean durante
el proceso de 2.Módulos de hardware Éstos están fuertemente relacionados con las
modularización abstracciones de datos y recolectan conjuntamente todas las funciones
del programa
utilizadas para controlar un dispositivo particular de hardware.
3.Módulos funcionales Éstos son módulos que recolectan conjuntamente

funciones que llevan a cabo tareas similares o muy relacionadas. Este tipo de
modularización se considera cuando no es práctico recuperar las abstracciones
de datos del programa.
4.Módulos de apoyo al proceso Éstos son módulos donde se agrupan todas las
funciones y elementos de datos específicos requeridos para apoyar un proceso
de negocios en particular.
Recuperación Para reducir costos del cambio a áreas de datos compartidas, el proceso de
de modularización del programa se centra en la identificación de abstracciones
abstracciones de datos. Los pasos involucrados en convertir áreas de datos globales
de datos compartidas en objetos o tipos de datos abstractos son:
1. Analizar áreas de datos comunes para identificar las abstracciones lógicas

de datos.
2. Crear un tipo de datos abstracto o un objeto para cada una de estas

abstracciones. Si el lenguaje de programación no tiene características para
ocultar datos, simular un tipo de datos abstracto suministrando funciones para
actualizar y acceder a todos los campos de los datos.
3. Utilizar un sistema de navegación de programas o un generador de

referencia cruzada para encontrar todas las referencias a los datos.
Reemplazar éstas con llamadas a las funciones apropiadas.


Estimacion Costos PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Estimacion Costos PDF

Cargado por

Copyright:

Formatos disponibles

2 Métodos de estimación y costos de SW

Características Condiciones del

Determinantes de la calidad del software y de la

Estimación La estimación de recursos, costos y agendas para el esfuerzo de desarrollo de

Grado de estructuración definición

Continúa en la siguiente página

2 Universidad Tecnológica de Jalisco

La complejidad Tiene efecto sobre la incertidumbre, que es inherente a la planificación. La

Tamaño del Afecta la precisión y la eficacia de las estimaciones. Al aumentar el tamaño,

Grado de La estructuración se refiere a la facilidad con la que las funciones pueden

La disponibilidad de información histórica también determina el riesgo de la

El riesgo Se mide por el grado de incertidumbre de las estimaciones cuantitativas

Objetivos de la Es proporcionar un marco de trabajo que permita al gestor hacer estimaciones

Academia de Ingeniería de Software 3

• Descripción del recurso

Recursos Se evalúa el ámbito y se seleccionan las habilidades técnicas que se requieren

El número de personas requerido para el proyecto de Software, sólo puede ser

Sistema de desarrollo: Llamado sistema anfitrión está compuesto por la

Máquina objetivo: En que tipos de máquina se ejecutará el sistema.

Demás elementos del nuevo sistema: Lectores de código de barras,

4 Universidad Tecnológica de Jalisco

La productividad en un sistema de manufactura se mide contando el número

Sin embargo, los administradores tienen que estimar la productividad de los

Para realizar estimaciones seguras de costes y esfuerzos tenemos varias

1. Dejar la estimación para más adelante

La primera opción no es practica las estimaciones deben ser a priori. La

Mediciones de Métricas orientadas al tamaño

Academia de Ingeniería de Software 5

P ro y ecto LDC E sfu erzo C o sto P a g.D o c. E rrores D efecto s P erson al

Comparar la productividad de los diferentes lenguajes de programación

Utilizan una medida de funcionalidad entregada por la aplicación como un

Continúa en la siguiente página

6 Universidad Tecnológica de Jalisco

Se determinan 5 características del dominio de la información y se

• Número de entradas del usuario. Se cuenta cada entrada del usuario

• Número de salidas. Se cuenta cada salida que proporciona al usuario

• Número de peticiones del usuario. Se define como una entrada

• Numero de archivos. Se cuenta cada archivo maestro lógico de datos

• Número de interfaces externas. Se cuentas todas las interfaces

Academia de Ingeniería de Software 7

Cálculos de Para calcular puntos de función se utiliza la siguiente relación:

Continúa en la siguiente página

8 Universidad Tecnológica de Jalisco

Puntos de La medida de punto de función Enfatiza la dimensión de datos (los valores de

Una extensión se denomina puntos de característica (alta complejidad en los

Lenguaje de programación LDC / PF (media)

Varios métodos combinan estadísticamente para crear una estimación de tres

NOTA: Ver la Técnica de descomposición Estimación basada en el problema

Calcular tamaño del software con Puntos de Función

Ejercicio 2 Parámetros Optimista Más probable Pesimista VE

Emplear la tabla de Puntos de función del problema 1, sustituyendo

10 Universidad Tecnológica de Jalisco

El planificador estima un valor de tamaño optimista, más probable y

S pess = estimaciones pesimistas

Una vez determinado el valor esperado de la variable de estimación, se aplican datos

Función OP MP PES $/L Costo Mes

Academia de Ingeniería de Software 11

El planificador estima el esfuerzo (personas/mes) que se requerirá para llevar

Tabla de estimación basada en el

IUFC 0.50 2.50 0.40 5.00 n/a 8.40

Totales 0.25 0.25 0.25 3.50 20.50 4.75 16.50 45.25

%Esfuerz 1% 1% 1% 8% 45% 10% 36%

CC = Comunicación cliente EC= Evaluación cliente