UNIVERSIDAD PRIVADA SAN JUAN BAUTISTA

FACULTAD DE INGENIERÍAS
PROGRAMA ACADÉMICO DE INGENIERÍA
DE COMPUTACIÓN Y SISTEMAS
INGENIERÍA DE SOFTWARE I

EJEMPLO DE ESTIMACIÓN 02
SISTEMA DE PLANILLAS DE PERSONAL DE LA DIRECCIÓN REGIONAL DE TRANSPORTES Y
COMUNICACIONES

Requerimientos
Requerimientos funcionales
Código Descripción
RF1 Registro de empleados
RF2 Mantenimiento de conceptos de retención y bonificación
RF3 Registro de retenciones y bonificaciones al empleado en un periodo específico
RF4 Generación de la planilla y boletas por periodo contable

RF5 Mantenimientos de Contratos.

RF6 Apertura y cierre de periodos contables

Ing. Carlos Fernando Oliva Ramos Página 1

 • RF1: Registro de empleados
Parámetros por requerimiento funcional
Tipo de parámetro Código Descripción
Entradas E1_RF1 Registro de Empleado: Información básica, de familiares, etc.
Ficha de Empleado
Salidas S1_RF1
Pagos realizados.
Consulta de empleado
Consultas
Boletas por empleado.
Archivos internos AI1_RF1 Empleado, boleta de Pago, planilla.

• RF2: Mantenimiento de conceptos de retención y bonificación.

Parámetros por requerimiento funcional
Tipo de parámetro Código Descripción
Módulo de mantenimiento de conceptos por retención o
Entradas E21_RF2
bonificaciones.
Salidas S1_RF2 Listado de conceptos por bonificación y retención.
Consulta de conceptos por bonificación y retención.
Consultas Consulta de empleados por concepto para un periodo
especifico.
Archivos internos AI1_RF2 Retenciones/bonificaciones, empleado, periodo contable.

• RF3: Registro de retenciones y bonificaciones al empleado en un periodo específico.

Parámetros por requerimiento funcional
Tipo de parámetro Código Descripción
Formularios de retención/bonificación por periodo para un
Entradas E21_RF3
empleado.
Listado de retenciones y bonificaciones por empleado en un
periodo contable.
Salidas S1_RF3
Consolidados de conceptos de retención o bonificaciones por
periodo contable.
Consulta de retenciones y bonificaciones por empleado en un
periodo contable.
Consultas
Consolidados de conceptos de retención o bonificaciones por
periodo contable.
Retenciones/bonificaciones, boleta de Pago, planilla,
Archivos internos AI1_RF3
empleado.

Ing. Carlos Fernando Oliva Ramos Página 2

 • RF4: Generación de la planilla y boletas por periodo contable.
Parámetros por requerimiento funcional
Tipo de parámetro Código Descripción
Modulo para la generación de boletas de pago de los
Entradas E21_RF4
empleados, así como la planilla de ese periodo.
Planilla
Salidas S1_RF4 Boletas de pago.
Consolidados por concepto.
Planilla
Consultas Boletas de pago.
Consolidados por concepto.
Retenciones/bonificaciones, boleta de Pago, planilla,
Archivos internos AI1_RF4
empleado.

• RF5: Mantenimientos de Contratos.

Parámetros por requerimiento funcional
Tipo de parámetro Código Descripción
Entradas E21_RF5 Módulo de mantenimiento de contratos para un empleado.
Listado de contrato por criterio.
Salidas S1_RF5
Listado de pagos por contrato.
Consulta de contrato por criterio.
Consultas
Consulta de pagos por contrato.
Archivos internos AI1_RF5 Contrato, empleado, boleta de pago.

• RF6: Apertura y cierre de periodos contables.

Parámetros por requerimiento funcional
Tipo de parámetro Código Descripción
Entradas E21_RF6 Modulo para el cierre y apertura de un periodo contable.
Boletas por periodo.
Salidas S1_RF6
Consolidados de planilla por periodo.
Boletas por periodo.
Consultas
Consolidados de planilla por periodo.
Archivos internos AI1_RF6 Planilla, periodo.

Ing. Carlos Fernando Oliva Ramos Página 3

 1.1.1. Clasificación de parámetros según complejidad

Código Salida Campos Entidades Complejidad

Ficha de Empleado 30 3 Baja
S1_RF1
Pagos realizados. 6 3 Baja
S1_RF2 Listado de conceptos por bonificación y retención. 4 2 Baja
Listado de empleados por concepto de retención y bonificación para un
10 4 Media
periodo especifico.
S1_RF3
Consolidados de conceptos de retención o bonificaciones por periodo
6 7 Alta
contable.
Planilla 15 7 Alta
S1_RF4 Boletas de pago. 12 6 Media
Consolidados por concepto. 4 5 Media
Listado de contrato por criterio. 6 3 Baja
S1_RF5
Listado de pagos por contrato. 12 3 Baja
Boletas por periodo. 6 4 Media
S1_RF6
Consolidados de planilla por periodo. 6 3 Baja

Ing. Carlos Fernando Oliva Ramos Página 4

 Complejidad de parámetros Archivos Internos (AI)
Código Descripción Campos Subgrupos Complejidad
AI1_RF1 Panilla 15 04 Media
AI1_RF2 Periodo 6 02 Baja
AI1_RF3 Contrato 12 01 Media
AI1_RF4 Empleado 25 02 Alta
AI1_RF5 boleta de pago 15 02 Media
AI1_RF6 retenciones/bonificaciones 10 Media

Complejidad de parámetros Entradas (E)

Código Descripción Campos Entidades Complejidad
E1_RF1 Registro de Empleado: Información básica, de familiares 30 04 Media
Módulo de mantenimiento de conceptos por retención o
E1_RF2 6 02 Baja
bonificaciones.
E1_RF3 Formularios de retención/bonificación por periodo para un empleado. 7 04 Media
Módulo para la generación de boletas de pago de los empleados, así
E1_RF4 4 06 Media
como la planilla de ese periodo.
E1_RF5 Módulo de mantenimiento de contratos para un empleado. 12 04 Media
E1_RF6 Módulo para el cierre y apertura de un periodo contable. 6 01 Baja

Ing. Carlos Fernando Oliva Ramos Página 5

Complejidad de parámetros Consultas (C)
.
Código Consulta Campos Entidades Complejidad
Consulta de empleado 30 3 Baja
C1_RF1
Boletas por empleado. 6 3 Baja
Consulta de conceptos por bonificación y retención. 4 2 Baja
C 1_RF2
Consulta de empleados por concepto para un periodo especifico. 4 2 Baja
Consulta de retenciones y bonificaciones por empleado en un periodo
10 4 Media
contable.
C 1_RF3
Consolidados de conceptos de retención o bonificaciones por periodo
6 7 Alta
contable
Planilla 15 7 Alta
C 1_RF4 Boletas de pago. 12 6 Media
Consolidados por concepto 4 5 Media
Consulta de contrato por criterio. 6 3 Baja
C 1_RF5
Consulta de pagos por contrato. 12 3 Baja
Boletas por periodo. 6 4 Media
C 1_RF6
Consolidados de planilla por periodo. 6 3 Alta

Ing. Carlos Fernando Oliva Ramos Página 6

En general, se evalúan los archivos de interfaz externa considerados en el sistema:

Parámetros generales
Tipo de
Código Descripción
Parámetro
Archivos externos AE1 No se interactúa con otro sistema.

1. Puntos de funcionalidad no ajustados

Parámetro de
Clasificación Ocurrencias
medida
BAJA 2
Entradas MEDIA 4
ALTA 0
BAJA 6
Salidas MEDIA 4
ALTA 2
BAJA 6
Consultas MEDIA 4
ALTA 3
BAJA 1
Archivos internos MEDIA 4
ALTA 1
BAJA 0
Archivos externos MEDIA 0
ALTA 0

Ing. Carlos Fernando Oliva Ramos Página 7

Las ocurrencias clasificadas en el paso anterior se registran y consolidan en el siguiente
cuadro:

Factor de Peso
Parámetros de Medida
BAJA MEDIA ALTA

Entradas de Usuario 2 3 4 4 0 6
Salidas de Usuario 6 4 4 5 2 7
Consultas de Usuario 6 3 4 4 3 6
Archivos Lógicos 1 7 4 10 1 15
Archivos de Interfaces 0 5 0 7 0 10

PFNA =2*3 + 4*4 + 0*6 +6*4 + 4*5 +2*7 + 6*3 +4*4 + 3*6 + 1*7 + 4*10 + 1*15 + 0*5 + 0*7
+0*10

PFNA = 6 + 16+ 0+ 24 + 20+ 14 + 18 + 16 + 18 + 7 + 40 + 15 + 0+ 0 + 0

PFNA = 194

Ing. Carlos Fernando Oliva Ramos Página 8

 2. Multiplicador de Influencia
Los 14 parámetros de ajuste considerados para el proyecto, se registran en el
siguiente cuadro:
Valor Parámetro
Explicación
asignado de ajuste
Comunicación
1 La aplicación utiliza 3 computadoras.
de datos
Funciones
0 No existen funciones distribuidas en la aplicación.
distribuidas
3 Rendimiento Los objetivos de rendimiento no necesitan de diseño especial
Configuraciones
Existen restricciones al tiempo de procesamiento, pues el sistema
2 fuertemente
funcionará en una computadora Pentium Dual Core.
utilizadas
Frecuencia de
2 No existen periodos punta
transacciones
Entrada de
2 La mayoría de transacciones son en línea
datos en línea
Actualización en
1 Generalmente se actualizan los datos de las unidades catastrales
línea
Eficiencia del
3 Se consideran menús, ayuda en línea y teclas de función
usuario final
Procesos Se consideran controles de seguridad, la lógica del registro de la
3
complejos unidad catastral es compleja
Diseño para La aplicación ha sido diseñada para ser fácilmente reutilizable. No
2
reutilización existen parámetros de mantenimiento.
Facilidad de El proceso de conversión no se considera importante y el ingreso
2
instalación de datos será manual.
Facilidad de
3 No existen requerimientos especiales de operación
operación
Instalación en La aplicación se diseñará para funcionar en diferentes
0
distintos lugares municipalidades, bajo el sistema operativo Windows.
Facilidad de No existen datos de control, las consultas son de complejidad
2
cambios media y se han diseñado para facilitar el cambio.

Ing. Carlos Fernando Oliva Ramos Página 9

 MI = ( 0.01 *  VA ) + 0.65
MI = ( 0.01 * 26) + 0.65

MI = 0.91 Valor

3. Puntos de funcionalidad ajustados

PFA = PFNA * MI

PFA = 194 * 0.91

PFA = 176.54

4. Líneas de código
El lenguaje de programación que se utilizará para codificar la aplicación es Microsoft Visual
Studio 2005.

Tomando como referencia los valores de la tabla cantidad de LDC por punto de función,
para desarrollar un punto de función en lenguaje Visual Basic se necesitan 25 LDC.
KLDC= (PF * Líneas de código por cada PF)/1000
KLDC = (176.54* 25)/1000

KLDC = 4.4135

5. Esfuerzo
La aplicación ejemplo se considera dentro del modo orgánico, debido a que tiene menos
de 50 KLDC, y el grupo tiene experiencia en desarrollos similares.

Modo de desarrollo Esfuerzo (persona – mes)

Orgánico 2.4 (KLDC) 1.05

ESF = 2.4 (4.4135) 1.05

ESF = 11.4086309 personas – mes

Ing. Carlos Fernando Oliva Ramos Página 10

 6. Ajuste de esfuerzo

En la siguiente tabla se muestran los 15 factores de costo considerados en el COCOMO

intermedio, indicando su ponderación y las razones de su valor.

Factor Descripción Clasificación Valor

El efecto de las fallas del sistema no tiene
RELY
consecuencias graves
Muy Alto 1,40
El tamaño de la base de datos se estima en
alrededor de 3000 registros, si
consideramos un promedio de 100
DATA caracteres por registro, tenemos un Alto 1,08
tamaño de la base expresado en
caracteres de 300000, lo que determina
una proporción de 90.91
Los procesos son simples en mayoría,
CPLX existiendo complejidad sólo en el registro Bajo 0,85
de unidades catastrales
TIME No se considera restricciones de hardware Medio 1
STOR No se considera restricciones de hardware Medio 1
VIRT No se considera restricciones de hardware Bajo 0,87
TURN No se considera restricciones de hardware Alto 1,07
ACAP El equipo de análisis está capacitado Muy Alto 0,71
El equipo de desarrollo tiene 2 años de
AEXP
experiencia en aplicaciones informáticas
Alto 0,91
Es la primera oportunidad en la que el
PCAP
grupo de programación trabajará junto.
Bajo 1,17
El equipo de desarrollo ha diseñado
durante 2 años aplicaciones para hardware
VEXP
y software similares a los utilizados en el
Alto 0,90
sistema.
Se han seleccionado programadores con al
LEXP menos 2 años de experiencia en lenguaje Alto 0,95
Visual Studio.
Se utiliza revisiones de diseño y código,
MODP programación orientada a objetos y Medio 1.00
algunas librerías de código
Se utiliza herramientas CASE sólo para el
TOOL
modelo de datos y las etapas de análisis
Bajo 1,10
El proyecto se estima en 11800 p-m
SCED aproximadamente, pero el cliente necesita Bajo 1,08
el producto en un máximo de 4 meses

PFA = 1,40*1,08*0,85*1*1*0,87*1,07*0,71*0.91*1,17*0,90*0,95*1*1*1,08
PFA = 0,92

Ing. Carlos Fernando Oliva Ramos Página 11

ESF ajustado = ESF * Producto de los factores de costo

ESF ajustado = 11.4086309 *0,92

ESF ajustado = 10.4959404 personas – mes

Td = 2.5 * (10.4959404)0.38
Td = 6.10849022 meses

7. Total de horas – hombre – Costo Proyecto

Número Personas = 10.4959404 / 6.10849022 = 1.71827722 personas

Número Personas = 2 personas

Según el mercado el precio promedio de un analista/programador es de: 100 soles día x

persona

Costo del Proyecto = 100*20*2*6.10849022

Costo del Proyecto = 24 433,64 nuevos soles.

Ing. Carlos Fernando Oliva Ramos Página 12