You are on page 1of 26

2 Mtodos de estimacin y costos de SW

Gestin del El proceso de gestin del proyecto comienza con un conjunto de actividades
proyecto que globalmente, se denominan planificacin del proyecto.
La gestin eficaz de un proyecto de software se centra en las cuatro Ps:
personal, producto, proceso y proyecto. El orden no es arbitrario. El gestor
que se olvida de que el trabajo de ingeniera de software es un esfuerzo
humano intenso nunca tendr xito en la gestin de proyectos. Un gestor que
no fomenta una minuciosa comunicacin con el cliente al principio de la
evolucin del proyecto corre el riesgo de construir una elegante solucin para
un problema equivocado.
Producto

Caractersticas Condiciones del


del cliente negocio
Proceso

Entorno de Tecnologa
Personas desarrollo

Determinantes de la calidad del software y de la


efectividad de organizacin

Estimacin La estimacin de recursos, costos y agendas para el esfuerzo de desarrollo de


Software requiere experiencia, acceso a una buena informacin histrica y
coraje para confiar en medidas cuantitativas cuando todo lo que existe son
datos cualitativos.

Grado de estructuracin definicin


mbito de bajo riesgo y variabilidad

Complejidad basada
en esfuerzos pasados Tamao del
esfuerzo

Contina en la siguiente pgina

2 Universidad Tecnolgica de Jalisco


Manual de Anlisis y diseo II. Maestro
Planificacin, Continuacin

En la figura anterior se ilustran los factores que aumentan el riesgo. Los ejes
de la figura corresponden a las caractersticas del proyecto a estimar.

La complejidad Tiene efecto sobre la incertidumbre, que es inherente a la planificacin. 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).

Tamao del Afecta la precisin y la eficacia de las estimaciones. Al aumentar el tamao,


proyecto aumenta la interdependencia entre los mdulos. La tcnica de descomposicin
de los mdulos no se aplica fcilmente porque pueden seguir siendo
demasiado grandes.

Grado de La estructuracin se refiere a la facilidad con la que las funciones pueden


estructuracin compartirse y la naturaleza jerrquica de la informacin que debe ser
procesada. A medida que aumenta la estructuracin, la posibilidad de estimar
con precisin aumenta.

La disponibilidad de informacin histrica tambin determina el riesgo de la


estimacin. 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. (Especificacin 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


planificacin de razonables de recursos, coste y planificacin temporal. Se hacen dentro de un
proyectos marco de tiempo limitado al comienzo de un proyecto de software, y deberan
actualizarse regularmente a medida que progresa el proyecto.

Academia de Ingeniera de Software 3


Ana E. Romo Gonzlez
Recursos Estimacin de recursos requeridos para acometer el esfuerzo del desarrollo de
Software. Cada recurso queda especificado mediante 4 caractersticas:

Descripcin del recurso


Informe de disponibilidad
Fecha cronolgica en la que se requiere
Tiempo durante el que ser aplicado

Especificar
Habilidades requeridas
Disponibilidad
Gente Duracin de las tareas
Fecha de comienzo

Herramientas Especificar
HW/SW Descripcin
Disponibilidad
Duracin del uso
Fecha de distribucin

Recursos Se evala el mbito y se seleccionan las habilidades tcnicas que se requieren


humanos para el desarrollo.

Especificar:
1. Posicin dentro de la organizacin (ing. de Software, seor, etc),
2. Especialidad (Telecomunicaciones, bases de datos, etc.)

El nmero de personas requerido para el proyecto de Software, slo puede ser


determinado despus de hacer una estimacin del esfuerzo de desarrollo.

Recursos de Considerar:
hardware 1. Sistema de desarrollo
2. Mquina objetivo
3. Dems elementos del nuevo sistema

Sistema de desarrollo: Llamado sistema anfitrin est compuesto por la


computadora que se emplear durante el desarrollo y sus perifricos.

Mquina objetivo: En que tipos de mquina se ejecutar el sistema.

Dems elementos del nuevo sistema: Lectores de cdigo de barras,


impresoras trmicas, etc.

4 Universidad Tecnolgica de Jalisco


Manual de Anlisis y diseo II. Maestro
Error! No hay texto con el estilo especificado en el documento.
Mtricas de El proceso del software y las mtricas del producto son una medida
estimacin y cuantitativa que permite a la gente del software tener una visin 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 nmero


de unidades que se producen y dividiendo ste entre el nmero 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 estimacin del proyecto y para valorar si los procesos o las
mejoras tecnolgicas son efectivas.

Para realizar estimaciones seguras de costes y esfuerzos tenemos varias


opciones posibles:

1. Dejar la estimacin para ms adelante


2. Basar las estimaciones en proyectos similares ya terminados
3. Utilizar tcnicas de descomposicin relativamente sencillas para
generar las estimaciones de coste y de esfuerzo del proyecto.
4. Utilizar uno o ms modelos empricos para la estimacin del coste
y esfuerzo del software.

La primera opcin no es practica las estimaciones deben ser a priori. La


segunda opcin e razonable si el proyecto es bastante similar, las opciones
restantes con mtodos viables para la estimacin del proyecto de software,
utilizan un enfoque de divide y vencers y se pueden utilizar los modelos
empricos de estimacin como complemento de las tcnicas de
descomposicin.

Mediciones de  Mtricas orientadas al tamao


SW  Mtricas orientadas a la funcin
 Mtricas ampliadas de puntos de funcin
 Tcnicas de descomposicin
o Tamao del SW
o Basada en el problema
o Basada en el proceso
 Modelos empricos de estimacin (COCOMO)
 Desarrollar/comprar

Academia de Ingeniera de Software 5


Ana E. Romo Gonzlez
1. Mtricas stas se relacionan con el tamao de alguna salida de una actividad. La
orientadas al medida ms comn relacionada con el tamao son las lneas de cdigo fuente
entregadas.
tamao
Provienen de la normalizacin de las medidas de calidad y/o productividad
considerando el tamao 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 lneas de cdigo con 24 personas-mes, con un costo 168,000
(A,D,C,P), 365 pginas de documentacin, registraron 134 errores de SW y 29 despus de entregarse
dentro del 1er. Ao de utilizacin, 3 personas. Para desarrollar mtricas se comparan de distintos
proyectos y se sacan normalizacin.

Comparar la productividad de los diferentes lenguajes de programacin


tambin da impresiones engaosas de productividad del programador. Entre
ms expresivo sea un lenguaje de programacin, ms baja es la productividad
aparente.

Una alternativa a la utilizacin del tamao del cdigo como atributo estimado
del producto es utilizar alguna medida de la funcionalidad del cdigo.

Mtricas Fueron propuestos por Albrecht (1979) y refinados por Albrecht y Gaffney
orientadas a la (1983). Los puntos de funcin son independientes del lenguaje por lo que se
funcin puede comparar la productividad en los diversos lenguajes de programacin.

Utilizan una medida de funcionalidad entregada por la aplicacin como un


valor de normalizacin. Ya que la funcionalidad no se puede medir
directamente. Los PDF se derivan con una relacin emprica segn las
medidas contables (directas) del dominio de informacin y las evaluaciones
de la complejidad del Software

Contina en la siguiente pgina

6 Universidad Tecnolgica de Jalisco


Manual de Anlisis y diseo II. Maestro
Mtricas orientadas a la funcin, Continuacin

Se determinan 5 caractersticas del dominio de la informacin y se


proporcionan las cuentas en la posicin apropiada de la tabla.

Nmero de entradas del usuario. Se cuenta cada entrada del usuario


que proporciona diferentes datos orientados a la aplicacin. Las
entradas se deben diferenciar de peticiones.

Nmero de salidas. Se cuenta cada salida que proporciona al usuario


informacin orientada a la aplicacin. 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.

Nmero de peticiones del usuario. Se define como una entrada


interactiva que produce la generacin de alguna respuesta del
Software inmediata en forma de salida interactiva.

Numero de archivos. Se cuenta cada archivo maestro lgico de datos


que puede ser una parte de una gran base de datos o un archivo
independiente.

Nmero de interfaces externas. Se cuentas todas las interfaces


legibles por la mquina (Archivos o cintas) que se utilizan para
transmitir informacin 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 vara desde 3 (para
las entradas externas sencillas) hasta 15 (para archivos internos complejos).
Las organizaciones que utilizan mtodos de puntos de funcin desarrollan
criterios para determinar si una entrada en particular es simple, media o
compleja. No obstante la determinacin de la complejidad es algo subjetiva.

Academia de Ingeniera de Software 7


Ana E. Romo Gonzlez
Tabla de Factor de ponderacin
puntos de Parmetros Cuenta Simple Medio Complejo
funcin de medici n
Nmero de
entradas de X 3 4 6 =
usuario
Nmero de
salidas de X 4 5 7 =
(Problema usuario
abierto) Nmero de
peticiones de X 3 4 6 =
usuario
Nmero de
Ejercicio 1 archivos X 7 10 15 =

Nmero de
interfaces X 5 7 10 =
externas
Cuenta total

Clculos de Para calcular puntos de funcin se utiliza la siguiente relacin:


puntos de PF = cuenta total X [0.65 + 0.01 X ( Fi )]
funcin 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 segn las respuestas de las siguientes preguntas:
1.Requiere el sistema copias de seguridad y de recuperacin fiables?
2.Se requiere comunicacin de datos?
3.Existen funciones de procesamiento distribuido?
4.Es crtico 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 mltiples 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 diseado el cdigo para ser reutilizable?
12.Estn incluidas en el diseo la conversin y la instalacin?
13.Se ha diseado el sistema permitir mltiples instalaciones en diferentes organizaciones?
14.Se ha diseado la aplicacin para facilitar los cambios y para ser fcilmente 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 ecuacin y los factores de peso que se aplican a
las cuentas de los dominios de informacin se determinan empricamente.
Una vez que se han calculado los puntos de funcin, se utilizan de forma anloga a
las LDC como forma de normalizar las medidas de productividad, calidad y otros
atributos del software.

Contina en la siguiente pgina

8 Universidad Tecnolgica de Jalisco


Manual de Anlisis y diseo II. Maestro
Mtricas orientadas a la funcin, Continuacin

Puntos de La medida de punto de funcin Enfatiza la dimensin de datos (los valores de


funcin dominios de informacin de PF) para la exclusin de dimensiones (control)
ampliados funcionales y de comportamiento.

Una extensin se denomina puntos de caracterstica (alta complejidad en los


algoritmos), los valores de dominio de informacin se cuentan otra vez y se
pesan como en el modelo anterior. Adems cuenta otra caracterstica del
Software los algoritmos Un algoritmo se define como: un problema de
clculo limitado que se incluye dentro de un programa de computadora
especfico, ejem. Invertir una matriz, manejar una interrupcin, etc.
Otra extensin propuesta por Boeing se denomina Punto de funcin 3D
adecuada a aplicaciones que enfatizan las capacidades de control y funcin.
Evala la dimensin de datos exactamente igual al modelo anterior. Las
cuentas de datos retenidos (ejem. Archivos), y los datos externos (entradas,
salidas, peticiones).
La dimensin funcional: se mide considerando el nmero de operaciones
internas requeridas para transformar datos de entrada en datos de salida.
La dimensin de control: se mide contando el nmero de transiciones entre
estados.
La siguiente tabla proporciona estimaciones del nmero medio de lneas de
cdigo que se requieren para construir un punto de funcin

Lenguaje de programacin 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 cdigo) 16
SQL 12

Los conteos de los puntos de funcin se pueden utilizar junto con las tcnicas
de estimacin de lneas de cdigo. Se utiliza para estimar el tamao final del
cdigo como el nmero promedio de lneas de cdigo (LCP):
Tamao del cdigo = LCP x Nmero de puntos de funcin.

Productividad = PF / personas-mes
Calidad = errores / PF
Costo = pesos / PF
Documentos = Pag. Doc. / PF
Esfuerzo = PF / ProdMedia (personas-mes)
Academia de Ingeniera de Software 9
Ana E. Romo Gonzlez
Tcnicas de Consisten en descomponer el problema, volvindolo a definir como un
descomposicin conjunto de pequeos problemas. Ya que en la mayora de los casos el
problema a resolver es demasiado complejo, para considerarlo como un todo.

Tamao del El tamao representa el primer reto importante del planificador de proyectos.
software En el contexto de la planificacin de proyectos, el tamao se refiere a una
produccin cuantificable del proyecto de software. Si se toma un enfoque
directo, el tamao se puede medir en LDC. Si se selecciona un enfoque
indirecto, el tamao se representa como PF.

Varios mtodos combinan estadsticamente para crear una estimacin de tres


puntos o del valor esperado. Esto se lleva a cabo desarrollando valores de
tamao optimista (bajos), y ms probables, y pesimistas (bajos), y se
combinan utilizando la ecuacin de PF.
VE = ( S opt + 4 S m + S pess ) / 6

NOTA: Ver la Tcnica de descomposicin Estimacin basada en el problema

Calcular tamao del software con Puntos de Funcin

Ejercicio 2 Parmetros Optimista Ms probable Pesimista VE


de medicin
Nmero. de
entradas
Nmero de
salidas
Nmero de
peticiones
Nmero de
archivos
Nmero de
interfaces
externas

Emplear la tabla de Puntos de funcin del problema 1, sustituyendo

PF =

10 Universidad Tecnolgica de Jalisco


Manual de Anlisis y diseo II. Maestro
Estimacin 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 funcin las LDC y PF. En
general, el dominio del proyecto debera calcular las medias de LDC/pm o PF/pm,
agrupando los proyectos por tamao, rea de aplicacin o complejidad y otros
parmetros relevantes.

El planificador estima un valor de tamao optimista, ms probable y


pesimista para cada funcin. Entonces se calcula un valor de tres puntos o
esperado. El valor esperado de la variable de estimacin (tamao), 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 estimacin, se aplican datos


histricos de productividad y LDC y PF.

mbito del Desarrollo de un paquete de software para una aplicacin de diseo asistido por computadora CAD.
El software de CAD aceptar del ingeniero de datos de geometra bi y tri-dimensional. El ingeniero controlar e
problema interactuar con el sistema CAD a travs de una interfaz de usuario que exhibir caractersticas de un buen diseo
hombre-mquina. Todos los datos geomtricos y cualquier informacin adicional se mantendrn en una base de datos
de CAD. Los mdulos de anlisis del diseo se desarrollarn de forma que produzcan la salida requerida en una forma
que pueda ser mostrada en una gran variedad de dispositivos grficos. El software estar diseado para poder
Ejercicio 3 controlar e interactuar con dispositivos perifricos tales como un ratn, un digitalizar, una impresora lser y un
trazador.
Tabla de estimacin de LDC

Funcin OP MP PES $/L Costo Mes


L/mes
VE
es

Control de interfaz de
usuario
Anlisis geomtrico
bidimensional
Anlisis geomtrico
tridimensional
Gestin de estructura de
datos
Visualizacin de grficos

Control de perifricos

Anlisis de diseo

Total * * *

Academia de Ingeniera de Software 11


Ana E. Romo Gonzlez
Estimacin La tcnica ms comn para estimar un proyecto es basar la estimacin 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
estimacin de cada tarea.

Esta tcnica comienza con un esbozo de las funciones del software obtenidas
a partir del mbito del proyecto. Para cada funcin 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 funcin.

Tabla de estimacin basada en el


proyecto

Actividad Anlisis
Construccin
CC Planificacin de Ingeniera EC Totales
entrega
riesgo
Tarea Anlisis Diseo Cdigo Prueba

Funcin

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 = Comunicacin cliente EC= Evaluacin cliente

12 Universidad Tecnolgica de Jalisco


Manual de Anlisis y diseo II. Maestro
Como ltimo paso se calculan los costes y el esfuerzo de cada funcin, y la
actividad del proceso de software. Si la estimacin basada en el proceso se
realiza independientemente de la estimacin 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 estimacin para el software de computadora utiliza frmulas


empricos de derivadas empricamente para redecir el esfuerzo como una funcin de LDC
estimacin o PF.

Un modelo comn de estimacin se extrae utilizando el anlisis de regresin


sobre los datos recopilados de proyectos de software anteriores.

La mayora de los modelos de estimacin tienen algn 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 economa de la ingeniera de software, introduce


COCOMO una jerarqua de modelos de estimacin 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 estimacin
de coste del software ms utilizados y estudiados de la industria. La primera
versin del modelo COCOMO fue un modelo de tres niveles donde stos
reflejaban el detalle del anlisis de la estimacin del costo. El primer nivel
(bsico) provee una estimacin inicial burda, el segundo nivel la modifica
utilizando varios multiplicadores del proyecto y del proceso, y el nivel ms
detallado produce estimaciones para las diferentes fases del proyecto.

Tipos de 1. Modo Orgnico. Proyectos de software relativamente pequeos y


proyectos en sencillos en los que trabajan pequeos equipos, con buena
COCOMO experiencia en la aplicacin, sobre un conjunto de requisitos poco
rgidos.
2. Modo semiacoplado. Proyectos de software intermedios (en tamao y
complejidad) en los que equipos, con variados niveles de experiencia,
deben satisfacer requisitos poco o medio rgidos.
3. Modo empotrado. Proyectos de software que deben ser desarrollados
en un conjunto de hardware, software y restricciones operativas muy
restringido.

Academia de Ingeniera de Software 13


Ana E. Romo Gonzlez
Ecuaciones de COCOMO (Constructive Cost MOdel)
COCOMO E=ab(KLDC)exp(bb)
bsico D=cb(E) exp (db)
N=E/D
Tabla de
COCOMO
bsico Proyecto ab bb cb db

Orgnico 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 bsico 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 aplicacin. Son una
estimacin con peso:

1. El nmero 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 nmero de informes que se producen. Para informes simples,
cuentan como 2 PO, para informes moderadamente complejos 5
PO y para informes difciles de producir 8 PO.
3. El nmero de mdulos 3GL que deben desarrollarse para
complementar el cdigo 4GL. Cada mdulo 3GL cuenta como 10
PO.

14 Universidad Tecnolgica de Jalisco


Manual de Anlisis y diseo II. Maestro
Tabla para el
clculo del PO Tipo de objeto Peso de la complejidad
Bsico Intermedio Avanzado
Pantalla 1 2 3
Informe 2 5 8
Componente 3GL 10

Una vez que se ha determinado la complejidad, se valora el nmero de


pantallas, informes y componentes. La cuenta de punto objeto se determina
multiplicando el nmero 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 reutilizacin de software en general, se estima el porcentaje de reutilizacin
(% reutilizacin) y se ajusta la cuenta del punto objeto:

PON = (puntos objeto) x [(100 - % reutilizacin) /100]


Donde PON = Puntos objeto nuevos

Esfuerzo con Para obtener una estimacin del esfuerzo basado en el valor PON calculado.
punto objeto Se debe calcular la proporcin de productividad para los diferentes niveles de
nuevo experiencia del desarrollador y de madurez del entorno de desarrollo. Una
vez determinada la proporcin de productividad, se puede obtener una
estimacin 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.

Academia de Ingeniera de Software 15


Ana E. Romo Gonzlez
Calcular PON tomando en cuenta el ejercicio 5

Ejercicio 6 PON =

La decisin de En muchas reas de aplicacin del software, a menudo es ms rentable


desarrollar- adquirir el software de computadora que desarrollarlo. En una decisin de
comprar desarrollarlo o comprarlo se pueden complicar an ms con las opciones de
adquisicin: (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.

16 Universidad Tecnolgica de Jalisco


Manual de Anlisis y diseo II. Maestro
Proyecto 1 La Universidad Tecnolgica de Jalisco, aplica diferentes Test psicomtricos a los alumnos que
ingresan a la institucin, con la intencin de definir un perfil que permita apoyar el programa de
tutorias y la colocacin de alumnos en estadas.
El sistema actual permite dar de alta alumnos de manera externa mediante el cdigo del alumno,
proporcionado por servicios escolares, pero no cuenta con facilidades para el mantenimiento debido
a que los requerimientos originales especificaba que la informacin la proporcionara servicios
escolares mediante un acceso a su base de datos.
La herramienta (SEP) Sistema de Evaluacin Psicomtrica, permite realizar la calificacin
automatizada de 3 test psicomtricos, una vez que se ha presentado la aplicacin. 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 informacin relevante para la institucin. El sistema
genera reportes que son resultado de la evaluacin. Fue desarrollado en Cbuilder.

Del sistema actual solamente se cuenta con el cdigo ejecutable por lo que se necesita reingeniera.
Los nuevos requerimientos especifican que se permita el mantenimiento de alumnos (altas, bajas,
modificaciones, consultas), seguridad en el sistema, as como el clculo automatizado de otros 2
test:

o Raven (inteligencia)
o Encuesta de hbitos y actitudes hacia el estudio.

Del primero an no se realiza la aplicacin manualmente. No se cuenta con documentacin que


permita darle mantenimiento.

Proyecto 2 El Sistema Estadstico de Ingreso a Exposiciones (SIEI) genera estadsticas de visitantes a


exposiciones. Debe permitir la captura de datos fijos (nombre, domicilio, telfono, correo
electrnico, etc.) de los visitantes y la captura de datos variables (preguntas especficas de cada
exposicin, las cuales podrn ser abiertas XYZ? o de seleccin mltiple.

El sistema deber contar con un mdulo de configuracin para cada expo, y uno de mantenimiento
para preguntas, solicitando la pregunta y las posibles opciones. Deber generar grficas de cada
pregunta con un resumen de respuestas de las que hayan sido abiertas. El Software recibe
informacin de entrada de las capturistas que debern entregar un formato a cada visitante e
Sistema SEIE imprimir una etiqueta de acceso a la exposicin 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 categoras:

1. Mantenimiento. Instala el sistema y puede dar de alta preguntas


2. Capturista
3. Empresario. Verifica estadsticas e imprime.

Academia de Ingeniera de Software 17


Ana E. Romo Gonzlez
Factor de ponderacin

Parmetros Cuenta Simple Medio Complejo


de medici n
Nmero de
Calcular PF entradas de X 3 4 6 =
usuario
Nmero de
salidas de X 4 5 7 =
usuario
Nmero de
peticiones de X 3 4 6 =
usuario
Nmero de
archivos X 7 10 15 =

Nmero de
interfaces X 5 7 10 =
externas
Cuenta total

Para calcular puntos de funcin se utiliza la siguiente relacin:


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 segn las respuestas de las siguientes preguntas:
1.Requiere el sistema copias de seguridad y de recuperacin fiables?
2.Se requiere comunicacin de datos?
3.Existen funciones de procesamiento distribuido?
4.Es crtico 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 mltiples 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 diseado el cdigo para ser reutilizable?
12.Estn incluidas en el diseo la conversin y la instalacin?
13.Se ha diseado el sistema permitir mltiples instalaciones en diferentes organizaciones?
14.Se ha diseado la aplicacin para facilitar los cambios y para ser fcilmente 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=

18 Universidad Tecnolgica de Jalisco


Manual de Anlisis y diseo II. Maestro
VE = ( S opt + 4 S m + S pess ) / 6
Calcular
tamao del Parmetros Optimista Ms probable Pesimista VE
software con de medicin
PF Nmero. de
entradas
Nmero de
salidas
Nmero de
peticiones
Nmero de
archivos
Nmero de
interfaces
externas

PF =

Academia de Ingeniera de Software 19


Ana E. Romo Gonzlez
Divida el mbito del proyecto en por lo menos 6 funciones y calcule LDC
Calcular LDC

Funcin OP MP PES $/L Costo Mes


L/mes
VE
es

Total * * *

20 Universidad Tecnolgica de Jalisco


Manual de Anlisis y diseo II. Maestro
Seleccione un tipo de proyecto, tome los valores de la tabla y calcule
COCOMO bsico
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 Bsico Intermedio Avanzado
objeto y punto Pantalla 1 2 3
objeto nuevo Informe 2 5 8
Componente 3GL 10

PO =

PON = (puntos objeto) x [(100 - % reutilizacin) /100]

PON =

Academia de Ingeniera de Software 21


Ana E. Romo Gonzlez
3. Reingeniera de Software e ingeniera de reversa

Sistemas Son sistemas de SW tradicionales esenciales para el apoyo a negocios. Las


heredados compaas de apoyan en estos sistemas por lo que conviene mantenerlos en
operacin.

Antecedentes La cantidad de cdigo en los sistemas heredados es inmensa. En 1990, se


estim que existan 120 mil millones de lneas de cdigo. Se escribieron en
COBOL, o FORTRAN.
Desde 1990, ha habido un gran incremento en la utilizacin 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 lneas de cdigo
fuente en existencia que requieren mantenimiento. Muchas de estas lneas no
estn escritas en lenguajes orientados a objetos y an se ejecutan en
computadoras mainframe.
Reingeniera Se refiere a reimplementar sistemas heredados para hacerlos ms
de SW mantenibles.

La reingeniera comprende la redocumentacin del sistema, la organizacin


y reestructura del sistema, la traduccin del sistema a un lenguaje de
programacin ms moderno y la modificacin y actualizacin de la estructura
y los valores de los datos del sistema. La funcionalidad del software no se
cambia y, normalmente, la arquitectura del sistema tambin permanece igual.

Ventajas de la a. Riesgo reducido Existe un alto riesgo en volver a desarrollar software


reingeniera esencial para una organizacin. Se cometen errores en la
especificacin del sistema, existen problemas en el desarrollo,
etctera.

b. Costo reducido El costo de la reingeniera es mucho menor que los


costos de desarrollar nuevo software. Puede ser 4 veces menos costoso
que reescribir el sistema.

Ingeniera
directa y
reingeniera

22 Universidad Tecnolgica de Jalisco


Manual de Anlisis y diseo II. Maestro
Posible proceso de
reingeniera

El proceso de 1.- Traduccin del cdigo fuente El programa se convierte de un lenguaje de


reingeniera programacin antiguo a una versin ms moderna del mismo lenguaje o a un
lenguaje diferente.
2. Ingeniera inversa Se analiza el programa y se extrae informacin de l, la
cual ayuda a documentar su organizacin y funcionalidad.
3. Mejora de la estructura del programa Se analiza y modifica la estructura de
control del programa para hacerlo ms fcil de leer y comprender.
4. Modularizacin del programa Donde sea apropiado, se agrupan las partes
relacionadas del programa y la redundancia se elimina. En algunos casos, esta
etapa comprende la transformacin arquitectnica.
5. Reingeniera de datos Se cambian los datos procesados por el programa
para reflejar los cambios en l.

Enfoques de la
reingeniera

Academia de Ingeniera de Software 23


Ana E. Romo Gonzlez
Factores 1. La calidad del software al que se aplica reingeniera. Entre ms baja sea la
principales que calidad del software y de su documentacin asociada (si existe), ms altos
afectan los sern los costos de la reingeniera.
costos 2. Las herramientas de apoyo disponibles para la reingeniera. Normalmente
no es costeable hacer reingeniera 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 conversin de datos requerida Si la reingeniera requiere
que se conviertan grandes volmenes 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
reingeniera, esto incrementar los costos. Los ingenieros
encargados de la reingeniera tienen que invertir gran cantidad de
tiempo para comprender el sistema.

1. Traduccin del cdigo fuente

Traduccin 1. Actualizacin de la plataforma de hardware. La organizacin desea


cambiar su plataforma estndar de hardware. Los compiladores para el
del cdigo 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 estndar
que est fuera de circulacin.
3. Cambios en las polticas organizacionales. Una organizacin decide
adoptar un estndar para un lenguaje de programacin 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
estn fuera de circulacin de los negocios o no existe continuidad en el apoyo
de este producto.

24 Universidad Tecnolgica de Jalisco


Manual de Anlisis y diseo II. Maestro
2. Ingeniera La ingeniera inversa es el proceso de analizar el software con el objetivo de
inversa recuperar su diseo y especificacin. El programa mismo no cambia por el
proceso de ingeniera inversa.

1.Se puede aplicar ingeniera inversa al diseo y a la especificacin de un


sistema existente por lo que stos pueden servir como una entrada a la
especificacin de requerimientos para la sustitucin del programa.

2.De forma alternativa, se puede aplicar ingeniera inversa al diseo y a la


especificacin para que sirvan como ayuda al mantenimiento del programa.
Con esta informacin adicional, no es necesario aplicar la reingeniera al
cdigo del sistema.

El proceso de ingeniera
inversa

3. Mejora de la La necesidad de optimizar la utilizacin de la memoria y la falta de


estructura del comprensin de la ingeniera de software por varios programadores han
programa generado que muchos sistemas heredados no estn bien estructurados.
Su estructura de control est enmaraada con muchas ramas no condicionales
y lgica de control no intuitiva. Esta estructura tambin se ha degradado por
el mantenimiento regular.
Los cambios al programa han hecho que algn cdigo no sea alcanzable, pero
esto slo se descubre despus de un anlisis profundo.
A menudo, los programadores del mantenimiento no se atreven a remover el
cdigo en el caso de que se acceda a l de forma indirecta.

Simplificacin Condicin compleja


de la condicin
if not (A > B and (C < D or not E > F) ) )...

Condicin simplificada

Academia de Ingeniera de Software 25


Ana E. Romo Gonzlez
Reestructuracin automatizada
de programas

Problemas de la 1.Prdida de comentarios Si el programa tiene lneas de comentarios,


reestructuraci invariablemente stas se pierden como parte del proceso de reestructuracin.
n automatizada
de programas 2. Prdida de documentacin De forma similar, se pierde la correspondencia
entre la documentacin de programas externos y el programa. Sin embargo,
en muchos casos los comentarios y la documentacin de un programa no
estn actualizados, por lo que esto no es un factor importante.

3. Demandas de computacin pesadas Los algoritmos incrustados en las


herramientas de reestructuracin son complejos. Aun con el hardware
moderno y rpido se puede llevar mucho tiempo completar el proceso de
reestructuracin para programas grandes.

Mtricas para o la tasa de cadas;


identificar
programas
candidatos a
o el porcentaje de cdigo fuente que cambia por ao;
reestructuracin
o la complejidad del componente.

Otros factores, como el grado de cumplimiento de los estndares actuales de


los programas o componentes, se deben tomar en cuenta al tomar las
decisiones sobre reestructuracin.
4. La modularizacin del programa es el proceso de reorganizar un programa
Modularizacin con el fin de que las partes relacionadas se ubiquen conjuntamente y se
del programa consideren como un solo mdulo.
Una vez hecho esto, es ms fcil 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 mdulos creados se encapsulan como objetos y
se acceden a travs de una interfaz comn.

26 Universidad Tecnolgica de Jalisco


Manual de Anlisis y diseo II. Maestro
Tipos de 1.Abstracciones de datos stos son tipos de datos abstractos creados al
mdulos que se asociar los datos con componentes del procesamiento.
crean durante
el proceso de 2.Mdulos de hardware stos estn fuertemente relacionados con las
modularizacin abstracciones de datos y recolectan conjuntamente todas las funciones
del programa
utilizadas para controlar un dispositivo particular de hardware.

3.Mdulos funcionales stos son mdulos que recolectan conjuntamente


funciones que llevan a cabo tareas similares o muy relacionadas. Este tipo de
modularizacin se considera cuando no es prctico recuperar las abstracciones
de datos del programa.

4.Mdulos de apoyo al proceso stos son mdulos donde se agrupan todas las
funciones y elementos de datos especficos requeridos para apoyar un proceso
de negocios en particular.

Recuperacin Para reducir costos del cambio a reas de datos compartidas, el proceso de
de modularizacin del programa se centra en la identificacin 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 lgicas


de datos.

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


abstracciones. Si el lenguaje de programacin no tiene caractersticas 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 navegacin de programas o un generador de


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

Academia de Ingeniera de Software 27


Ana E. Romo Gonzlez

You might also like