Cap23 Est Imac Ion Proy Soft

5/17/2018 Cap23 Est Imac Ion Proy Soft - slidepdf.com

http://slidepdf.com/reader/full/cap23-est-imac-ion-proy-soft 1/34

CONCEPTOS

CLAVE

a m b i t o . . . . . . . 6 9 3

( o l t p l e j i d a d . . . 7 0 3

e s t i m t K i O n

b a s a d a

e n l o t . . • . 7 6 0b as a d a e n P F 7 0 2

(' b a s a d a

e n p ro ce so s 7 04

: ; , ; c a s a s d e u sa .7 0 5

c o n c e pt o s. . . 6 98f"

r ec o nd li oc iim 7 0 8

~ fG d ib il i d ad ' " .6 93. ,~anifi(lKion d e

p , r o y e d o . . . . . 6 9 2

f e c u r s o s . . . . . . 6 9 4)

t o m a i i o

d e l s o h w u r e . . 6 9 8

ESTIMACION PARA

PROYECTOS DE SOFTWARE

L

a gestion del proyecto de software comienza con un conjunto de aCtiVid_

des que en grupo se denominan p lon if icaci on de l p royect o. Antes de qu a .

proyecto comience el gestor del proyecto y el equipo de software debeneel

timar el trabajo que habra de realizarse, los recursos que se requenran y el tien:

que transcurrira desde el principio hasta el final. Una vez que se completen estas

actividades, el equipo de software debe establecer un plan del proyecto que de-

fina las tareas y fechas clave de la ingenieria del software, que identifique qUi(;n

es responsable de dirigir cada tarea y especifique las dependencias entre tareas

que pueden ser determinantes en el progreso.

En una excelente guia para "sobrevivir el proyecto de software", Steve MCConnell

[MCC981 presenta una vision del mundo real de la planificacion del proyecto:

Muchos trabajadores tecnicos prefertran realizar el trabajo tecnico en lugar depa-

sar el tiernpo en la planificaci6n. Muchos gestores tecnicos no nenen suticiente en-

trenamiento en la gestion tecnica para sentirse seguros de que su planificaci6n

mejorara el resultado de un proyecto. Puesto que ninguna parte quiere hacer 1apla.

nificacion. con frecuencia no se realiza .

Pero las fallas para planificar es uno de los mayores errores que un proyecto pueda

cometer... se necesita la planificacion eficaz para resolver los problemas corriente

arriba [temprano en el proyecto] a bajo costo, mas que coniente abajo [tarde en el

proyecto] a alto costo. El proyecto promedio gasta 80 p ar c ie n to de su tiempo en ree-

laboracion: corrigiendo errores que se cornetieron en etapas tempranas del proyecto .

•

690

I,



sr_-c JOC

:: : :> _r -> : oe

:e cs s.se-

-::;.:r :0'-'-

3- : : : . : r . . . . . - ~ e .

~::r ~,·en·

!! ::r:X'cdc.

• ::: ::x x : ..tfX)

.,sr_"= y

i,

-,

C A P I T U L O 23 ESTIMACION PARA PROYECTOS DE SOFTWARE 69

McConell argumenta que cualquier proyecto puede encontrar el tiempo para pla

nificar (y adaptar el plan a 10 largo del proyecto) simplemente tomando un pequerio

porcentaje del tiempo que se habria gastado en la reelaboraci6n que ocurre debido

a que no se planific6.

La planificaci6n requiere que los gestores tecnicos y los miembros del equipo d

software establezcan un compromiso inicial, aun cuando sea probable que est

"compromise" pruebe estar equivocado Siempre que se realizan estimaciones s

atisba al futuro y se ace pta automaticamente algun grado de. incertidumbre Par

citar a Frederick Brooks [BR07S]:

[Nluestras tecnicas de estimaci6n estan pobremente desarrolladas. Mas seriamente, re-

flejan una suposici6n no expresada que es bastante incierta. es deciri que todo ira bien ..

Puesto que no estamos seguros de nuestras estimaciones, can frecuencia los gestores de

software carecen de la cortes testarudez para hacer que la gente espere un buen producto.

Aunque la estimaci6n es tanto un arte como una ciencia, esta importante actividad

no necesita realizarse en una forma improvisada Existen tecnicas utiles para la estimaci6n de tiempo y esfuerzo. Las metricas del proceso y del proyecto ofrecen l

perspectiva hist6rica y la energia para la generaci6n de estimaciones cuantitativas.

La experiencia (de toda la gente involucrada) puede auxiliar enormemente conforme

se desarrollan y revisan las estimaciones. Puesto que la estimaci6n coloca lo

cimientos para las demas actividades de planificaci6n del proyecto, y esta proper-

ciona la ruta para la ingenieria del software exitosa, se estaria mal aconsejado si s

embarcara sin ella,

· l o s b u e n o s e n f oq u e s d e e s t i m a ti o n y l o s d a to s h i s to r ic o s s e li d o s o f re c en 1 0 m e i e r e sp er o n z a d e q ue e n r e al i d od s e

m u n fo r o s ab re d em o n c l as i m p o s i b le s . "

C a p e rs J O l I e s

I. .

." . ,



'1

r .i

. .

!

692 PARTE CUATRO G ES TIO N D E PROYECTOS DE SOITWAi<E

La estimacion de recursos, costa y programa de trabajo para una tarea de in

nieria de software requiere experiencia, acceso a buena informacion hist6;e.

(metricas) y el valor para comprometerse con predicciones cuantitativas cUand Cq

informacion cualitativa es todo 10 que existe. La estirnacion implica riesgo inh'e0 lareno

te, I y este conduce a la incertidumbre.

La disponibilidad de informacion historica tiene una fuerte influencia en el n'eSa o

de la estimaci6n. AI mirar en retrospectiva, se pueden emular las cosas que funCi~.

naron y mejorar las areas don de surgieron problemas. Cuando hay disponibles

amplias metricas de software (capitulo 22) de proyectos previos, las estimaciones Se

hacen con mayor seguridad, los programas de trabajo se pueden establecer para ev].

tar dificultades pasadas y el riesgo global se reduce.

u n a m e n t e i n s t r u id a e s d es cc n s ar s a l i s fe ch a c o n e l g r ad o d e p re ci s io n q u e 1 0 n o t u r o l e z a

'f n n b u sc o r 1 0 e x ac ti l u d c u an d o 5 6 1 0 e s p o s ib le u n o a p ro x im o c i b n d e 1 0 v e r d o d . "

EI riesgo de la estimacion se mide por el grado de incertidumbre en las estima-

ciones cuantitativas establecidas para recursos, costos y programa de traba]o Sie l

ambito del proyecto se comprende en forma deflciente 0 los requisitos del proyecto

estan sujetos a eventuales cambios, la incertidumbre y el riesgo de la estimacion seincrementan peligrosamente. EI planificador y, en forma mas importante, el cliente

deben reconocer que la variabilidad en los requisitos del software significa mestao:

lidad en costa y programa de trabajo.

Sin embargo, un gestor de proyecto no debe obsesionarse con las estimacione

Los modernos enfoques de ingenieria del software (por ejernplo, modelos de proce-

so incremental) asumen una visi6n iterativa del desarrollo. En tales enfoques es

posible, aunque no siempre aceptable politicamente, reexarninar las estimaciones

(cuando se conozca mas informacion) y modificarlas cuando el c1iente cambia los

requisitos.

M i en tr a s m a s

c o n O IW , m e io r

e s t i m o r o , E n

c o n s e c u e n c i o ,

a c tu o li ce s u s

e s t i m o c i o n e s

c on fo rm e a v a n c e e l

p r o y e c t o .

EI objetivo de la planiflcacion del proyecto de software es proporcionar un marco de

trabajo que permita al gestor estimar razonablemente recursos, costa y programa

de trabajo. Ademas. las estimaciones deb en intentar definir los escenarios de mejor y

peor caso de modo que los resultados del proyecto se puedan acotar. Aunque existe

un grado inherente de incertidumbre, el equipo de software se embarca en un plan

establecido como consecuencia de las tareas de planificaci6n. Por 10tanto, el plan se

debe adaptar y actualizar conforme avance el proyecto. En las secciones siguientes

se estudiara cada una de las actividades asociadas con la planificaci6n del proyecto

de software.

I En elcapitulo 25se presentan tecnicas sistematicas para el anahsis del riesgo

I

"



· :' 0' ::: :r.Jce-

~-··=·:..;es es

~:-:-:o.::.Jnes

: :0 .- : - : -13 los

. :-,~arcode

:~:::grama

:e mejor y

:_;e existe

:-.In plan

::: pian se

~ :::guientes

> ~ orovecto

CAPfTuLo 23 ESTIMACION PARA PROYECTOS DE SOFTWARE

~

onjunto de tareas para 1ap1anificacion del proyecto

1. Establecer el 6mbito del proyecto. b. Desarr_:,liar dos 0 m6s estimaciones empleando

2. Determinar la factibilidad. tamano, puntos de funcion, tareas de proceso

3. Analizar los riesgos (capitulo 25). casas de uso.c. Reconciliar las estimaciones.

6. Desarrollar un plan del proyecto (capitulo 24).a. Establecer un conjunto de tareas significativo.

b. Definir una red de tareas.

c. Usar herramientas de planifieacion para

desarrollar un cronograma.

d. Definir mecanismos de seguimiento del

programa de troboio.

4. Definir los reeursos requeridos.

a. Determinar los recursos humanos requeridos.

e.

b. Definir los recursos de software reuti lizables.

Identifiear los recursos del entorno.

El ambito del software describe las funciones y caracteristicas que se entregaran a

usuarios finales, los datos que son entrada y salida, el "contenido" que se presenta

los usuarios como consecuencia de emplear el software, as! como el desernperio.

restricciones. las interfases y la confiabilidad que aeotan el sistema. EIambito se de

ne al usar una de las dos tecnicas siguientes:

1. pespues de una comunicaci6n con todos los participantes se desarrolla \ ina

descripci6n narrativa del ambito del software.

2. Los usuarios finales desarrollan un conjunto de casos de uso.'

Las funciones descritas en el enunciado del ambito (0 dentro de las casos de usa)

evaluan y en algunos casos se refinan para proporcionar mas detalles antes

comenzar la estimaci6n. Puesto que las estimaciones de costo y programa de traba

estan funcionalmente orientadas, con frecuencia es uti! cierto grado de descompo

sici6n. Las consideraciones del desemperio abarcan los requisitos de procesamientoy tiempo de respuesta. Las restricciones identifican los limites colocados en el so

ware por el hardware externo. la memoria disponible u otros sistemas existentes.

Una vez identificado el ambito (con la participacion del cliente) es razonable p

guntar ~es posible construir software para satisfacer este ambito? ~El proyecto

factible? Con mucha frecuencia los ingenieros de software soslayan est as pregunta

(0gestores 0 clientes impacientes los presionan para hacerlo). solo para verse enr

dados en un proyecto condenado al fracaso. Putnam y Myers [PUT97aj abordan e

cont1icto cuando escriben:

2 Los casos de uso se discutieran con detalle en las partes 2 y 3 de este libra. Un caso de usa es

descripci6n basada en escenario de la interacci6n del usuario con el software, desde el puntovista del usuario.

1

-,,. .L

~I-;

5. Estimar costo y esfuerzo.

q. Descomponer el problema.

A u n q u e e x is te n

m u ch a s r o zo ne s p o r a

i o i n c e rt i d u m b r e ,

p re va le ce l a

i n fo r m a ci o n i n co m p l e ta

a ce rc a d e l o s r eq u is it o s

d e l p r o bl em a .



r:

\

\.I

694

t c O N S E J O S .L a f ac t i b i li da d d e l

p ra y e c t a e s i m p o r -

t a n t e , p e r a u n a c o n sf

d e r ac io n d e l a s

n e ce s i d a de s d e l

n e ga c ia e s i nc /u s a

m a s im p or t a n t e . N o

e s b u e n a c o n s t r u i r u n

s i s t e m a a p ro du ct o d e

a l t a t e c na la g ia q u e

n a d ie q u ie r e.

PARTE CUATRO GESTION DE PROYECfOS DE SOFTWARE

[N]o todo 10imaginable es factible, incluso ni en software, tan evanescente como PUede

parecer a los extranos, Por el contrario, la factibilidad del software tiene cuatro dimensio_

nes solidas Tecnologia. "el proyecto es tecnicamente factible? "Esta dentro del terreno de

la disciplina> "Los defectos se pueden reducir a tal grado que se emparejen con las nece-

sidades de la aplicacion? Finanzas: i.es financieramente factible? i.Se puede completar el

desarrollo a un costo que la organizaci6n de software, su cliente 0 el mercado puedan en-

frentar? Tiempo: "el proyecto llegara al mercado antes y vencera a la cornpetencia> Re.

cursos. "la organizaci6n tiene los recursos necesarios para triunfar?

Putnam y Myers sugieren, acertadamente, que el ambito no es suficiente. Una vez

que el ambito se comprende, el equipo de software y otros deben trabajar para deter-

minar si se puede hacer dentro de las dimensiones anotadas lineas arriba. Esta es

una parte crucial, aunque con frecuencia ignorada. del proceso de estimacion

La segunda tarea de la planificacion es la estimaci6n de los recursos necesarios para

completar el esfuerzo de desarrollo del software. La figura 23.1 muestra las tres

grandes categorias de los recursos de ingenieria del software: personal. componen-

tes de software reutilizables y el entorno de desarrollo (hardware y herramientas desoftware). Cada recurso se especifica con cuatro caracteristicas: descripcion del

recurso: un informe de disponibilidad; cuando se requerira el recurso: tiempo duran

te el cual el recurso se aplicara. Las ultimas dos caracteristicas se pueden ver c ome

· ; W il ' iS -Recursos del

proyecto.

-1'



::c':":"";:oduran

':::e~.ver como

tcONSEJOS.

N u n ca a lv id e q u e

i nt eg r a r v o ri as c o m p o-

n e n te s d e r e ut il il o ci 6 n

p u e de s e r u n r e ta

d e sa f i a n te , E I

p ro b l e m a d e 1 0 i n t e -

g r a ci 6 n c o n f re c u en c ia

r e5 u r g e c on fa rm e s e

a c tu a l i za n v a ri o s

c o m p o n e n t e s .

C AP IT UL O 23 ESTIMACON PARA PROYECTOS DE SOFTWARE

una ventana de tiempo. La disponibilidad del recurso para una ventana

debe establecerse 10mas pronto posible.

23.4.1 Recursoshumanos

El planificador comienza evaluando el ambito del software y seleccionando

lidades requeridas para completar el desarrollo. Se especifican tanto la

organizacional (por ejemplo, gestor, ingeniero de software ejecutivo) como

cialidad (por ejemplo, telecomunicaciones, base de datos, cliente/servidor)

yectos relativamente pequenos (unos pocos persona-meses) un solo individrealizar todas las tareas de ingenieria del software y consultar con especialis

forme se requiera. En proyectos mayores el equipo de software puede esta

ficamente disperso en varios sitios. Aqui se especifica la ubicacion de cad

humane.

EI nurnero de personas que requiere un proyecto de software solo se d

despues de que se ha hecho una estimacion del esfuerzo de desarrollo (por

personas-rues). Las tecnicas para estimar el esfuerzo se trataran mas ad

este capitulo,

23.4.2 Recursosde software reutilizables

La ingenieria del software basada en componentes (capitulo 30) enfatizazacion. es decir, la creacion y reutilizacion de bloques de construccion de

[H0091], Tales bloques. usualmente llamados compotientes, deben cataloga

consultarlos con facilidad, estandarizarse para facilitar su aplicacion y

para integrarlos facilmente.

Bennatan [BEN92] sugiere cuatro categorias de recursos de software q

considerarse conforme avanza la planificacion:

Componentes ya desairollados. EI software existente se puede adquirir d

cero 0 se desarrollo internamente para un proyecto previo. Los CCYD (co

tes comerciales ya desarrollados) se compran de un tercero, estan listos para

los en el proyecto actual y han sido ampliamente validados.

Componentes experimentados. Especificaciones, diserios. codigo 0 datos

ba existentes que se desarrollaron para proyectos previos son similares al soft

se construira para el proyecto actual. Los miembros del equipo de software

tienen experiencia en el area de aplicaci6n que representan dichos compone

consecuencia, las modificaciones que requieran los componentes experim

seran relativamente de bajo riesgo.

Componentes de experiencia parcial. Especificaciones, disefios, c6digo 0

prueba existentes que se desarrollaron para proyectos previos estan rela

con el software que se construira para el proyecto actual pero requeriran

ciones sustanciales. Los miembros del equipo de software actual s610 tien

riencia limitada en el area de aplicaci6n que representan dichos compone

. . . . . ~~,_,.,--~ -, -_____,.---.-.-.---~~~~,

I.;



I

.. . ,

•b-

696 PARTE CUATRO G ES TIO N D E PROYECfOS DE SOFTWARE

10 tanto, las modificaciones que requieren los componentes de experiencia par'clal

tienen un grado considerable de riesgo.

C o mp on en te s n ue vo s. EI equipo de software debe construir los componentes d

software especificamente para las necesidades del proyecto actual. e

Ir6nicamente, con frecuencia los cornponentes de software reutilizables son despre_

ciados durante la planificaci6n, s610 para convertirse en una preocupaci6n impor_

tante durante la fase de desarrollo del proceso de software. Es mejor especificarcuanto antes los requisitos de recursos de software. De esta forma se puede llevara

cabo la evaluaci6n tecnica de las alternativas y puede ocurrir la adquisici6n Oportuna

23.4.3 Recursos del entorno

EI entorno que soporta un proyecto de software, con frecuencia denominado entomo

de ingcnietia del software (EIS), incorpora hardware y software. EI hardware propor-

ciona una plataforma que soporta las herramientas (software) con que se producen

los product os de trabajo basados en una buena practica de la ingenieria del softwa-

re.' Puesto que la mayor parte de las organizaciones de software tienen multiples

constituyentes que requieren acceso al EIS, el planificador de proyecto debe prescn .

bir la ventana de tiempo requerida por el hardware y el software, y verificar que estosrecursos estaran disponibles.

Cuando un sistema basado en computadora (que incorpora hardware y software

especializados) se sornetera a ingenieria, el equipo de software quiza requiera acce-

so a elementos de hardware que estan desarrollando otros equipos de ingenieria.

Por ejernplo, el software de un contador numerico (CN) utilizado en un tipo de

maquinas-herramienta tal vez requiera una maquina-herramienta especifica (par

ejemplo, un CN de torno) como parte del paso de prueba de validacion: un proyecto

de software para plantilla de pagina avanzada quiza necesite una impresora de alta

calidad en algun punto durante el desarrollo. EI planificador del proyecto de softwa-

re debe especificar cada elemento de hardware.

EI software es el elemento mas caro de virtual mente todos los sistemas basados en

computadora. En sistemas complejos, personalizados, un gran error en la estima-

cion del costa puede hacer la diferencia entre beneficio y perdida. Rebasar el costa

puede ser desastroso para el desarrollador.

B E n llIlll e ro d e s u b co n lr a to c ii m y c o m p e t e n c io c re ci e n l e , 1 0 h ab il i d o d p a r a e st i m o r c o n m a y o r p re c i s iO n ., . f m S U T g i l f O ' .

•IlIJlO u n f a d o r d e e x i t o a u t i o l p a r a m u c h o s g ru p o s d e T I . "

R o b T f I o m s e 1 t

3 Otro hardware -el entomo objetivo- es la computadora en la que el software se ejecutara cuandohaya side liberado al usuario final.

- ,

I•



!'CL':::C:-::;' ::;'Cce-

·le:~;;::-,leria

- : . . . = -. .ipo de

:;:-¢::::ca (por

..::-.proyecto

=:s:,a de alta

: : de softwa-

oasados en

- la estima-

sar el costa

_ h n l U r g i d o

~ ob T h o m s e n

: :- ~~ ;_a ra cuando

ir

A u n qu e e l e s f u er l o d e

I I Ig e n i e ri a d e l

s o ft w a re e s u n

e /e m e n l a d o m in a n l e

d e l c o s io d e l p r o y e c /o ,

e s i m p o rt a n le r ec o rd a r

Q u e t a m b i e n s e d eb en

c o n si d er a r o l I O S c o s l os

( po r e ;e m p /o , e n iG m a

d e d e s a r ro l lo y

h e r ra m i en ta s , v ia ; es ,

e n t r e n a m i o o l o ,

e sp a ci o d e o fi c in a ,

h a r d w a r e ) .

,.,i

CAPITULO 23 ESTIMACION PA.'<A PROYECTOS DE SOFTWARE

La estimaci6n del costo y el esfuerzo nunca sera una ciencia exacta." D

variables ~humanas, tecnicas: arnbientales politicas-; pueden afectar el

del software y el esfuerzo apIicado a desarrollarlo. Sin embargo, la estim

proyecto de software se puede transformer de una practice oscura en un

pasos sisternaticos que proporcionan estimaciones con riesgo aceptable. P

estimaciones confiables de costo y esfuerzo se tienen varias opciones:

1. Demorar la estimaci6n hasta mas tarde en el proyecto (obviamente.

lograr 100 por ciento de estimaciones precisas despues de que el pro

este terminadot)

2. Basar las estimaciones en proyectos similares que ya hayan sido com

3. Emplear tecnicas de descomposici6n relativamente simples para gen

maciones de costa y esfuerzo del proyecto.

4. Utilizar uno 0 mas model os empiricos en la estimaci6n de costa y es

Desgraciadamente, la primera opcion, aunque atractiva, no es practica L

ciones de costos se tienen que proporcionar "por adelantado". No obstante

reconocer que, mientras mas se espere mas se conocera, y mientras mas

ca menos probable es que se cometan serios errores en las estimaciones.

La segunda opci6n puede funcionar razonablemente bien si el proyecto

es muy similar a los previos y a otras influencias del proyecto (por ejernplo

po de software, el cliente. las condiciones del mercado, el EIS, las fechas

aproximadamente equivalentes. Por desgracia, la experiencia no siempre

buen indicador de los resultados futuros.

Las opciones restantes son enfoques viables para la estimacion del pr

software. Idealrnente. las tecnicas mencionadas para cada opci6n deben

juntas, cada una empleada como una marca de verificacion para la otra.

cas de descomposici6n asumen un enfoque de "divide y venceras" respe

estimaci6n del proyecto de software. Al descomponer un proyecto en funci

cipales y actividades de ingenieria del software relacionadas, las estimac

costa y esfuerzo se pueden realizar en forma escalonada. Los modelos

cion empirica son utiles para complementar las tecnicas de descomposicio

cer un enfoque de estimacion potencialmente valioso por su propio derec

model os se estudian en la secci6n 23.7.

Cada una de las opciones viables de estimaci6n de costa del software

buena como 1 0 sean los datos l!istoricos en que se basa la estimacion. Si

datos historicos. la estimaci6n Jdel costa se basara en un fundamento m

leante. En el capitulo 22 se examinan las caracteristicas de algunas de la

de software que proporcionan la base para los datos historicos de estimac

4 Bennatan [BEN03]reporta que 40por ciento de los desarrolladores de software continu

con las estimaciones y que el tarnano del software y el tiempo de desarrollo son muy d

timar con precision.

-1



P AR T E C UA TR O G ES TIO N D E PROYEG:TOS DE SOFTW?~ '<E

~l~~

CfAVEE I " l o m on o " d e l

s o ftw a re q ue s e

c o n s tr u ir il p u e de

e s t im a r se e m p le o nd o

u n a m e d id o d ir e c Ia ,

L D C , 0 u n a i nd ir e ct o ,

P F .

; f l L C om a s e

{I' m id e e l

l a m a n a d e l

s o ft w a r e q u e se

p l an e o ( on s tr u ir ?

La estimacion del proyecto de software es. una forma de resolver problemas; en la

mayoria de los casos. el problema que debe resolverse (es decir, el desarrollo de una

estimacion de costo y esfuerzo para un proyecto de software) es muy complejo como

para considerarlo una sola pieza. Por esta razon se descompone el problema, reca-

racterizandolo como un conjunto de problemas mas pequerios (y, esperanzadora_

mente, mas manejable).En el capitulo 21 se examino el enfoque de descomposicion desde dos diferentes

puntos de vista: descomposicion del problema y descomposicion del proceso L a

estimaciou emplea una 0 ambas formas de particion. Pero antes de que pueda rea-

lizarse una estimacion. el planificador del proyecto debe entender el ambito del soft-

ware que se construira y generar una estimacion de su «tamatio".

23.6.1 Tomano del software

La precision de la estimacion de un proyecto de software se manifiesta en varios fae-

teres: 1) el grado con el cual el planificador ha estimado adecuadamente el tamano

del producto que se construira; 2) la habilidad para traducir la estimacion del tama-

no en esfuerzo humane, programa de trabajo y dinero (una fun cion de la disponibt.

lidad de las mctricas de software confiables a partir de proyectos previos): 3) el grado

en el cual el plan del proyecto ret1eja las habilidades del equipo de software; y 4 3

estabilidad de los requisitos del producto y el entorno que soporta el esfuerzc . :e

ingenieria del software.En esta seccion se considera el problema del tamafiO del software. Puesto que ia

estimaci6n de un proyecto solo es tan buena como la estimacion del tamano del tra-

bajo para realizarlo, el tamafio representa el primer gran desafio del planificador del

proyecto En el contexto de la planificaci6n del proyecto, mmaiio se refiere a lin

resultado cuantificable del proyecto de software. Si se asume un enfoque directo, el

tamafio se puede medir en lineas de codigo (LDC). Si se elige un enfoque indirecto.'

el tamafio se representa como puntas de tuncion (PF).Putnam y Myers [PUT92j sugieren cuatro diferentes enfoques al problema del

tamano:

• 'tamaiio de "l6gica difusa" La aphcacion de este enfoque requiere que el plani-

ficador identifique el tipo de aplicaci6n, establezca su magnitud en una escala

cualitativa y luego refine la magnitud dentro del range original.

• Tamano de punto defunci6n. EI planificador desarrolla estimaciones de las

caracteristicas del dominio de la informaci6n tratadas en el capitulo 15 .

• Tamaiio de componentes estcindar El software se compone de varios «compo-

nentes estandar", los cuales son diferentes y genericos de una area particular

de la aplicacion Por ejemplo, los componentes estandar de un sistema deinformacion son subsistemas, m6dulos, pantallas, reportes, programas inter-

I

.. .



: " ' . 3 c escala

: ::"l1pO-

: ~~:ic;Jlar

.::~~aie :-.35 inter-

~ ~ ; . Q u e t i e n e n

I I I e n ( o m ll n l a s

e s t i m a c i o n e s

b a s a d a s e n lO C y

P F ?

( u an d a r e co p il e

m e t f ic a s d e p r od u c ti -

v id a d p a ra p r oy e ct os ,

a se gu re se d e e st a "

b le e e r u n a t a x on o m ia

d e l o s t i p os d e

, or a ye c to . E s to I e

o e r m i ti ra c o l w la r

, o ro m e d i o s e s p e c if ic o s

d e d o m in io , 1 0 q u e

p e rm i te r e a l iz o r e s ti "

m a ci o n e s m a s

p r e c i s n s .

CAPITULO 23 ESTIMACION PARA PROYECTOS DE SOFTWARE 6

actives. programas por lotes, archives. LDCe instrucciones al nivel de objeto

EI planificador del proyecto estima el numero de ocurrencias de cada cornpo-

nente estandar y luego aplica datos de proyectos hist6ricos para determinar

tarnario de entrega por componente estandar.

• Tamaiio del cambio. Este enfoque se aplica cuando un proyecto incluye la uti

zacion de software existente que debe modificarse en cierta forma como par

de un proyecto. El planificador estima el numero y tipo (por ejemplo, reutiliza

cion, codigo de adicion c6digo de cambio, c6digo de borrado) de las modifi-

caciones que se deben lograr.

Putnam y Myers sugieren que los resultados de cada uno de estos enfoques de tama

no se combinen estadisticamente para crear una estimaci6n de tics puntas 0dell/ala

esperado. Esto se logra desarrollando valores optimistas (bajos). mas probables

pesimistas (altos) para el tarnano y combiriandolos con la ecuaci6n (23-1) descrit

en la siguiente secci6n.

23.6.2 Estimacion basada en el problema

En el capitulo 22, las lineas de c6digo y los puntos de funci6n se describieron com

medidas a partir de las cuales se calculan las metric as de productividad. Los datode las LDCy los PF se utilizan en dos formas al estimar el proyecto de software:

como una variable de la estimacion para el "tarnano" de cada elemento del sottwa

re. y 2) como metricas de linea base recolectadas a partir de proyectos previos y u

lizados en conjunci6n con variables de estimacion para desarrollar proyecciones d

cos to y esfuerzo.

Las estimaciones de LDCy PF son distintas tecnicas de estimaci6n, aunque amba

tienen varias caracteristicas en com un. EIplanificador del proyecto comienza con u

enfoque acotado del ambito del software y a partir de ahi intenta descornponer

software en funciones problema que puedan estimarse individualmente. Entonces

estiman las LDC 0 PF (las variables de estimaci6n) para cada funci6n. De maner

alternativa, el pJanificador puede elegir otro componente para tarnano. como clase

u objetos, cambios 0 procesos de negocios afectados.

Entonces se aplican las metricas de la linea base de productividad (por ejemplo

LDC/pm 0 PF/pm5) a la variable de estimaci6n apropiada, y se deriva el costa 0 esfue

zo de la funcion. Las estimaciones de funci6n se combinan para producir una estirna

cion global del proyecto completo.

Sin embargo, es importante notar que con frecuencia existe una dispersion sus

tancial en las metricas de produetividad de una organizaci6n, 1 0 que hace sospe

choso el uso de una sola metrica de linea base de productividad En general, el domini

del proyecto debe calcular los promedios de LDC/pm 0PF/pm. Es decir: los proyec

tos deben agruparse por tamafio de equipo, area de aplicacion. complejidad y otro

5 Las siglas pm significan persona-mes de esfuerzo.



b &

E n l o s e st i m o c i o n e s P F

l a d e s co m p os ic io n s e

e n f o c o s o b re l a s

c a ra c te r i st ic a s d e l

d om i n io d e

i n f o r m a c i o n .

it~~:~:~" v a lo r e s pe r ad o "

p ara e l ta ma iio d e

so f tware?

P AR TE C UA TR O G ESTIO N DE PROYEcrOS DE SOFTWARE

parametres relevantes. Luego se tienen que calcular los promedios de dOffiinioI

C do se esti . d b bi oCaluan 0se esnma un nuevo proyecto pnmero e e u icarse en un dominio v I'~ lleg

aplicar el promedio del dorninio apropiado para la productividad y asi generar la 0

., e su.macron.

Las tecnicas de estimaci6n LDC y PF difieren en en cuanto al detalle reqlleIid

para descomposicion y el objetivo de la particion. Al emplear LDC como variabl 0e de

estirnacion la descomposici6n es absolutamente esencial y con frecuencia se Ilevaa

grados considerables de detalle. Mientras mayor sea el grado de partician es rn'as

probable que se desarrolle una estimaci6n razonablemente precisa de LDc.

En las estimaciones de PF la descomposici6n funciona de manera diferente. M a s

que enfocarse sobre la funcion, se estima cada una de las cinco caracteristicas de

dominio de informacion, asi como los 14 valores de ajuste de complejidad estlldia_

dos en el capitulo 15. Entonces se pueden utilizar las estirnaciones resultantes para

derivar un valor de PF que se pueda ligar a datos previos y empleados para generar

una estimaci6n.

Sin importar la variable de estimacion que se utilice, el planificador del proyecto

comienza estimando una gama de val ores para cada funcion 0valor de dominio de

informacion. Al emplear datos hist6ricos 0 (cuando todo 10demas falla) intuician, e!

planificador estima un valor de tamario optirnista. mas probable, y pesimista para

cada funcion 0 cuenta para cada valor de dominio de informacion. Cuando se espe-

cifica un range de valores se proporciona un indicio implicito del grado de incerti

dumbre.

Entonces se puede calcular un valor de tres puntos 0uno esperado. El valor espe

rado para la variable de estimaci6n (tamario), S, se calcula como un promedio pen-

derado de las estimaciones optimista (Sopt), mas probable (Sm) y pesimista (Spes)' Por

ejemplo,

S = (Sopt + 4Sm + Spes)/6 (23-1)

brinda la credibilidad mas fuerte a la estirnacion "mas probable" y sigue una distri-

bucion de probabilidad beta. Se supone que existe una probabilidad muy pequeria deque el tarnario real resultante se ubique fuera de los valores optimista y pesimista.

Una vez determinado el valor esperado para la variable de estimaci6n se aplican

los datos de productividad hist6rica de LDC 0 PF. c:Son correctas las estimaciones?

La (mica respuesta razonable a esta pregunta es: no se puede estar seguro. Cualquier

tecnica de estimaei6n, no importa cuan sofistieada sea, debe eontrastarse con otro

enfoque. Incluso entonces deben prevalecer el sentido comun y la experiencia.

23.6.3 Un ejemplo de estimccion basada en LDC

Como ejemplo de tecnicas de estimaci6n de LDCy PF basadas en el problema, eon-

siderese un paquete de software que sera entregado para una aplicacion de diserio

asistido por eomputadora (CAD, por sus siglas en Ingles) destinado a componentes

mecanicos. El software se ejecutara en una estaei6n de trabajo de ingenieria y debe

~'-- , •

j

1



=

Jtro

. : :: -- :- _ a _ con-

~«G _ debe

---",-"'-~

, _ c ' : : : . ' : ] ! i c a c i o n e s

- ; , : E c -,:;0 r es id e n e n

. - : . ~ : : ' s o n p or t e

: ~ _ c .: J [ q u i t e c t u r o

. ~ ' ·e -s e l ' l i do r . P a r 1 0

-:"0, J se g O r es e d e

:.e s u s e s ti m o e io n e s

' : uy en e l e sf u er zo

' e q ue rM o p o ro d e sa ·

r ro ll o r s o ft w a re d e

" i nf r oe s tr u c tu r o " .

tcONSEJOS.

N o s uc u m b o a 1 0

t en to e io n d e u t i /i zo r

e s t e r es u / t o d o c o m a /0

e st i m o c i o n d e s u

p ro y e c t o . U s te d d e b e

o b te n er o f r o r es u lt od o

u sa n d o u n e n f o qu e

d i f e r e n t e ,

CAPITULO 23 ESTIMACION PARA PROYECTOS DE SOFTWARE 7

tener interfaz con varios perifericos que incluyen raton, digitalizador, monitor

color de alta resolucion e impresora laser. Se puede elaborar una descnpcion pre

minar del ambito del software:

El software CAD rnecanico aceptara del ingeniero datos geometricos de dos y tres dimen-

siones. El ingeniero interactuara y controlara el sistema CAD a traves de una interfaz del

usuario que exhibira caracteristicas de buen diserio de interfaz humano-rnaquina. Todos

los datos geometric os y otra informacion de soporte se conservaran en una base de datos

CAD, Se desarrollaran modules de analisis de diserio para producir la salida requerida, la

cual se desplegara en una diversidad de dispositivos graficos. El software se diseriara para

controlar e interactuar con dispositivos perifericos que incluyen raton, digitalizador, im-

presora laser y plotter.

Esta descripcion del ambito es preliminar, no esta acotada. Se tendria que expand

cada oracion para ofrecer detalle concreto y acotacion cuantitativa. Por ejernpl

antes de que comience la estimacion, el planificador debe determinar que signifi

"caracteristicas de buen diseno de interfaz humano-rnaquina" 0 cuales seran

tamano y la complejidad de la "base de datos CAD",

En cuanto a los propositos actuales, se sup one que se ha llevado a cabo mas re

namiento y que estan identificadas las grandes funciones de software mencionada

en la figura 23.2, Al continuar con la tecnica de descomposicion para LDC se elab

ra una tabla de estirnacion. la cual se muestra en la figura 23,2, En cada funcion

desarrolla un rango de estimaciones LDC Por ejemplo, el rango de las estimacione

LDC para la funcion de analisis geometrico 3D es. optirnista, 4 600 LDC;mas prob

ble, 6 900 LDC;y pesimista, 8 600 LDC Al aplicar la ecuacion 23-1 el valor esperad

para la funcion de anal isis geometrico 3D es 6 800 LDC Otras estimaciones se de

van en forma similar, AI sumar verticalmente en la columna de LDC estimadas,

establece una estimacion de 33 200 lineas de codigo para el sistema CAD,

Funcian LD e estimadas

Facilidades de interfaz del usuario y control (FIUC) 2300

Anolisis geomelrico bidimensional [AG2DI 5300

An61isisgeometrico triqimensional (AG3D) 6800

Gesli6n de base de dalos (GBD) 3350

Focilidodes de presentocion gr6fica de 4950

compuladora (FPGC)

Funci6n de control perilerico (FCP) 2100

MOdulos de cnclisis de disefio (MAD) 8400

Uneas de codiqo estimadas 33200

· ; @ F ' f' .Tabla de

estimctcton

para metodos

LDC.

-1



·.

P AR T E C UA TR O G ES TI ON D E P RO YE CT OS D E S OF TWA RE

Una revisi6n de los datos hist6ricos indica que el promedio organizacional de pro _

ductividad para sistemas de este tipo es de 620 LDC/pm. Con base en una tarifa

laboral de 8 000 d6lares por mes, el costa par linea de c6digo es aproximadarnente

de 13 d61ares. Con base en la estimaci6n de LDCy los datos hist6ricos de produ t.c 1 -

vidad, el costo total estimado del proyecto es de 431 000 d6lares y el esfuerzo esti_

mado es de 54 personas-meso

Laoficina de Doug

niti.cacioodel proyedo.

de cosos de usc, delemlinc

pore implementor

paro coda pieza

que coda uno to h,.,.~"I'l .. ".,

comparomos los f E l $ l ! 1 f C 1 a o : "

Vinod: Vamos a

23.6.4 Un ejemplo de estimocton basada en PF

La descomposici6n de la estimaci6n basada en PF se centra en los valores de dominio

de informaci6n mas que en las funciones de software. Al consultar la tabla presen-

tada en la figura 23.3 el planificador del proyecto estima entradas externas. salidas

externas, consultas externas. archivos Iogicos internos y archivos de interfaz exter-

nos para el software CAD. Los PF se calculan usando la tecnica estudiada en el capi-

6 Las estimaciones estan redondeadas a 1000 dolares y a lapersona-mes mas cercanos. Mayorpre-

cision es innecesaria e irreal, dadas las limitaciones de precision de la estimacion .

. ..."



CAPITuLo 23 ESTIMACION PARA PROYECTOS DE SOFTWARE 7

Estimacion de valores de dominio de informacion.

Valor de dominio de Conteo Conteoinformacion Optim. Probable Pesim. estim. Peso PF

Numero de entradas externas 20 24 30 24 4 97

Numero de solidos extemas 12 15 22 16 5 78

Numero de pregvntas externas 16 22 28 22 5 88

Numero de archivos t6gicos internos 4 4 5 4 10 42

Numerc de archivos de interfase externos 2 2 3 2 7 15

Conteo toto! 320

- -....J

- :._~sa.idas

- ; : c" e. capi-

.' c. rre-

tulo 15. En cuanto a los prop6sitos de esta estimaci6n se supone que el factor po

derado de complejidad es el promedio. La figura 23.3 presenta los resultados de e

estimaci6n.

Se estima cada uno de los factores ponderados de complejidad y el valor del f

tor ajustado se calculan como se describe en el capitulo 15:

Factor

I . Respoldo y recuperocion

2. Comunicacianes de datos

3 Procesomiento distribuido

Valor

4

2

o

4

3

4

5

3

5

54

3

5

5

1.17

4 Desempeno cri tico

5. Eniorno operotivo existente

6. Entrada de datos en linea

7. {ronsoccion de entrado sobe pantallas multiples

8 ILF cctuolizooo en linea

9 Co noleio de valores de dO'l1inio de informacion

10I 1 d .se n odo para

12 Conversi6n//instolaci6n er; diseno

I 3 Instaiaciones

1 4 dseriodc para corr.b.o

Factor de ajuste de valor

Finalmente, se deriva el numero estimado de PF:

PFestimado= conteo total x [0.65 + 0.01 x I(F/)]

PFcsurnauo = 375

La productividad organizacional promedio para sistemas de este tipo es 6.5 PFIp

Con base en una escala salarial de 8 000 d6lares por mes, el costo por PF es aprox

madamente 1 230 d6lares. Con base en la estimaci6n de PF y los datos de product

-1



. .'i"

S~,J7':t~':5 - : ' - : - : : 5

~ C 'i:r: ~ 3 J . . P o r=erne : C ' , ' , : c 0 1

m i$~ :,- 5 ; . 5 TreaS

: r r · ( ~ : C i - = 5 f' : s t - ; m e

PARTE CUATRO GESTIOND E P RO YE Cf OS D E S OF TW AR E

.~'::ad historicos, el costa total estimado del proyecto es de 461 000 dolares, Yel

esruerzo estimado es de 58 personas-meso

23.6.5 Estimacion basada en e1proceso

La tecnica mas comun para estimar un proyecto es basar la estimacion en el proce-

so que se ernpleara. Esto es. el proceso se descompone en un conjunto relativa_

mente pequerio de tare as y se estima el esfuerzo requerido para lograr cada tarea.

Al igual que las tecnicas basadas en el problema, la estimacion basada en el pro-

ceso comienza con un bosquejo de las funciones del software obtenidas a partir del

ambito del proyecto. Cada funcion requiere realizar una serie de actividades del marco

de trabajo. Las funciones y actividades/ del marco de trabajo relacionadas se pre-

sentan como parte de una tabla similar a la presentada en la figura 23.4.

· ; W F E f OTabla de

estimctcionbasadaen

procesos.

Adividad CC PlanifieacionAncllisis

IngenieriaLibercKi6n de

E C ~otalesde riesgo construcciOn

Tarea-+- Anal i s ! Diseno COdigo Pruebc

Funci':;ny

FIUC 0.50 2.50 0.40 5.00 n l a SAO

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 nfa 6.00

GBD 0.50 3.00 0.75 1.50 nfa 5.75

Fe? 0.25 2.00 0,50 1.50 nfa 4.25

MAD 0.50 2.00 0.50 2.00 n / a 5.00

Totol es 0.25 0.25 0.25 3.50 20.50 4.75 16.50 46.00

% esfuerzo 0.5% 0.5% 0.5% 8% 45% 1 0 " . . 1 . 36%

CC = comunicocicn del c liente EC = evoluccion del cliente

Una vez que se combinan las funciones del problema y las actividades del proce-

so, el planificador estima el esfuerzo (por ejernplo, personas-rues) que se requerira

para lograr cada actividad del proceso de software en cada tuncion. Estos datos

constituyen la rnatriz central de la tabla en la figura 23.4. Entonces se aplican las

tasas de trabajo prornedio (es decir, costo/unidad de esfuerzo) al esfuerzo estimado

para cada actividad del proceso. Es rnuy probable que la tasa de trabajo varie en

cad a tarea. EI equipo veterano esta enorrnemente involucrado en las actividades

7 Las actividades del marco de trabajo que se eligen para este proyecto difieren un poco de la activi-

dades genericas tratadas en el capitulo 2, que son la cornunicacion can el cliente (CC)' la planifica-

cion. el anal isi s de riesgos. la ingenieria y la construccion-hberacion.

I.. .



CAPITuLo 23 ESTIM_t>.CION PARA PROYECTOS DE SOFTWARE

.ernpranas del marco de trabajo y generalmente es mas costoso que el equipo men

experimentado involucrado en la construcci6n y liberaci6n.

Los costos y el esfuerzo para cada funci6n y actividad del marco de trabajo se

culan como el ultimo paso. 5i la estimaci6n basada en el proceso se realiza in

pendientemente de la estimaci6n de LDC0PF, ahora se tienen dos 0 tres estimaci

nes para costa y esfuerzo que se pueden comparar y armonizar. 5i ambos conjunt

de estimaciones muestran una concordancia razonable, existe una buena raz

para creer que las estimaciones son confiables. Si, por otra parte, los resultados

dichas tecnicas de descomposici6n muestran poca concordancia, se debe lleva

cabo mayor investigaci6n y analisis.

M r s m e j or c om p r e n de r e l t ra s fo n d o d e u n o e st im a c i6 n a n te s d e u t il i za rl a. n

B a r r y B o e h m y R i c h a r d F a i r l e y

_ ~. __ . _Ci

23.6.6 Un ejemplo de estirncrcion basada en el proceso

Para ilustrar el uso de la estimaci6n basada en el proceso considerese de nuevo

software CAD introducido en la secci6n 23.6.3. La configuraci6n del sistema y

funciones del software permanecen invariables y las indica el ambito del proyecto

En la tabla basada en el proceso que se muestra en la figura 23.4 las estimaci

nes del esfuerzo (en personas-mes) para cada actividad de ingenieria del software

proporcionan para cada funci6n del software CAD (abreviadas para mayor rapide

Las actividades de ingenieria y de liberaci6n de construcci6n se subdividen en

principales tare as de ingenieria del software que se muestran. Las primeras estim

ciones de esfuerzo corresponden a comunicaci6n con el cliente, planificacion y a

lisis de riesgos, las cuales se registran en la hilera total al final de la tabla. Los tota

horizontal y vertical ofrecen un indicio del esfuerzo estimado que se requiere p

anal isis, diseno, c6digo y prueba. 5e debe serialar que 53 por ciento del esfuerzo

emplea en las tareas de ingenieria del sistema de salida (analisis de requisites y di

no), 10 que indica la importancia relativa de este trabajo.

Con base en la escala salarial promedio de 8 000 d6lares por mes. el costo to

estimado del proyecto es de 368 000 d6lares , y el esfuerzo estimado es de 46 per

nas-rnes. Si se desea. los promedios de trabajo pueden asociarse con cada activid

del marco de trabajo 0 tarea de ingenieria del software y calcularse por

23.6.7 Estimccton con casos de uso

. .dades 1 1 \ io r q u e e s_ , d if i c i l d es a -

r r o l l a r u n a t ec n ic il

d e e sl im a c io n c o n

c a s o s d e u s o ?

Como se ha serialado a 10 largo de las partes 2 y 3 de este libro, los casas de uso p

miten que un equipo de software comprenda el ambito del software y los

Sin embargo, desarrollar un enfoque de estimacion con casos de uso es problerna

co por las siguientes razones [Sl'vlI99j:

3. ~lanltlca-• Los casos de uso se describen empleando muchos formatos y estilos difc-

rentes no existe un formate estandar.



• _=5 C3.5JS de uso representan una vision externa (la vision del usuario) del

~ = :'":'.'.are y con frecuencia estan escritos con diferentes grados de abstracci6n

• :":5 cases de uso no abordan la complejidad de las funciones ni de las carac_

.eristicas que se describen .

• Los casos de uso no describen el comportarniento complejo (par ejemplo,

interacciones) que involucran muchas funciones y caracteristicas .

.-, diferencia de las LDC 0 un punto de funcion, el "caso de usa" de una persona tal

ve z requiera meses de esfuerzo mientras que el de otra qu iza se implemente en un

dia 0 dos.

Aunque varios investigadores han considerado los casos de uso como una entra-

da a la estimacion, a la fecha no ha surgido ningun metoda de estimacion prabado

Smith [SMI99] sugiere el empleo de los casos de uso en la estirnacion, pero s610 Si

se consideran dentro del contexto de la "jerarquia estructural" que los casas de Usa

describen.

Smith argumenta que cualquier nivel de esta jerarquia estructural se describe can

no mas de 10 casos de uso. Cada uno de estes abarcaria no mas de ,30 escenarios

distintos. Obviamente, los casos de uso que describen un sistema grande estan escri-tos con un grado mucho mayor de abstraccion Iy representan considerablemente

mas esfuerzo de desarrollo) que aquellos que describen un solo subsistema. En (on-

secuencia, antes de que los casos de uso se empleen en la estimacion, se establece

el nivel en la estructura jerarquica, se determina la longitud promedio (en paginasi

de cada caso de usc, se define el tipo de software (por ejemplo, tiempo real. de nego-

cios, de ingenieria/cientifico, anidado) y se considera una arquitectura comun del

sistema. Una vez establecidas dichas caracteristicas, los datos empiricos se aprove-

chan para establecer el nume r o estimado de LDC0de PF por caso de usa (para cada

nivel de la jerarquia). Entonces se utilizan los datos hist6ricos para calcular el esfuer-

zo necesario para desarrollar el sistema.

Enseguida se ilustra como realizar este ca l cu lo par tanto, considerese la s igu ien-

te relacion."

LDC estimada = N x LDCprom + [(SolS", - 1) + (PalPh - 1)] x LDCaJuste (23-2)

donde

N = numero real de casos de uso

LDCprom = promedio historico de LDCpar caso de usa para este tipa de subsis-

tema

8 Es importante serialar que la expresion (23-2) se emplea solo con propositos ilustrativos. Aligual

que todos los modelos de estimacion. debe validarse localmente antes de que se le pueda utilizar

con seguridad.



-=':, _00 = .epresenta un ajuste con base en n por ciento de LDCprom dond

se define localmente y representa la diferencia entre este proye

y los proyectos "promedio"

5- = escenarios reales por caso de uso

5h = escenarios promedio par caso de uso para este tipo de subsistema

Pa = paginas reales por caso de uso

Ph = pagina promedio por caso de uso para este tipo de subsistema

Con la expresi6n (23-2) se desarrolla una estimaci6n comun del numero de LDC

base en el numero real de casos de uso ajustado mediante el nurnero de escenari

y la longitud de la pagina de los casos de uso. El ajuste representa hasta n por ci

to del promedio hist6rico de las LDCpor caso de uso.

23.6.8 Un ejemplo de estimccion basada en casos de uso

El software CAD presentado en la secci6n 23.6.3 esta compuesto de tres grupos

subsistemas:

• Subsistema de interfaz del usuario (incluye FIUC).

::-::::::-"r;os

: ::::~":-.::scri-::~,,2Itmente

• Grupo de subsistema de ingenieria (incluye el subsistema AG2D, subsistema

AG3D y el subsistema MAD).

.ma. En con-

se establece

len paginasj

eal, de nego-

a cornun del

)S se aprove-

;0 (para cada

dar el esfuer-

(23-2)

• Grupo de subsistema de infraestructura (incluye el subsistema FPCGy el

subsistema FCP).

Seis casos de uso describen el subsistema de interfaz del usuario. Cada caso de u

10describen no mas de 10 escenarios y tiene una longitud promedio de seis pagina

EI grupo de subsistema de ingenieria 10describen 10 casos de uso (considerados

un nivel mas alto de la jerarquia estructural). Cada uno de los casas de uso no tie

mas de 20 escenarios asociados y tiene una longitud promedio de ocho pagina

Finalmente, el grupo de subsistema de infraestructura 10describen cinco casos de u

con un promedio de 5610 seis escenarios y una longitud promedio de cinco paginas

Con la relaci6n anotada en la expresi6n (23-2) y n = 30 por ciento se elaboratabla de la figura 23.5. Si se considera la primera hilera de la tabla, los datos histor

cos indican que el software IU requiere un promedio de 800 LDC por caso de u

cuando este no tiene mas de 12 escenarios y esta descrito en menos de cinco pag

it la siguien-

, de subsis- • m l ! ; 'to Estimacicn de caso de uso.

,;l iguaJ

: _ : - : ; ; _ i e c a utilizar

Subsistema de interfaz del usuario

Grupo de subsisterno de ingenieria

Grupo de subsistema de infraestructura

casos

de usc

6

105

escenarios poqincs

10 6

20 8

6 5

escenorios locoinos lD C1 2 5 560

16 8 310010 6 1650

lD C estimodas

3366

31 233

7970

42568otal LD C estimadas

-1



~ :;:A..-ro ~:':~;:E ?ROYECTOS DESOfTWARE

" : ' . ~ = ~:"3 ' : ' : : : : : : · S se ajustan razonablemente bien para el sistema CAD. As! PUe

. . C l subsi de in te rf d 1 . I I S, la:s:_- .=: ,:~::e;_D para e su s i s t ema e mter t a z e usuano se ca cu a mediante 1

='=-::5:~, 13-21. 5i se aplica el mismo enfoque, se realizan estimaciones para loa

~---:.: s ':e suosisternas de ingenieria e infraestructura. La figura 23.5 resume las esti~

-.= :: : r .es e .n dic a que el t ama r io global del software CAD se estima en 42 50 0 L D C

5. se utilizan 620 LDC/pm como la productividad promedio en los Sistemas de

::~:e ..po y una escala salarial de 8000 dolares por mes, el cos to por linea de c6digo::5 ,,:;roximadamente de 13 dolares. Con base en la estimacion de caso de usa y los

:3.:C5 historicos de productividad, el costo total estimado del proyecto es de 552 0 00

_:.:lares, y el esfuerzo estimado es de 68 personas-meso

23.6.9 Reconciliacion de estimaciones

Las tecnicas de estimacion estudiadas en las secciones precedentes dan por resultado

multiples estimaciones que deben reconciliarse para producir una sola estimaci6n

de esfuerzo, duracion del proyecto 0 costo. Este procedimiento de reconciliaci6n se

ilustra considerando de nuevo el software CAD presentado en la seccion 23 .6 .3 .

I m c J o s m e t o d o s ( o m p l i c o d o s n o p ro d u ze o n u n a e s t i m a ti o n m a s p r e d s e , p a r t i w l a r m e n t e

o t t o l l ad 'D r e s p u ec k n i n c o r p o ro r s u p ro p io i n tu ic i6 n e n 1 0 e s ti m a t i o n ."

El esfuerzo estimado total para el software CAD varia desde un bajo de 46 perso

nas-mes (obtenido empleando el enfoque de la estimacion basada en el proceso :

hasta un alto de 68 personas-mes (derivado con la estimacion de caso de USO), L a

estimacion promedio (que utiliza los cuatro enfoques) es de 56 personas-meso La varia-

cion de la estimacion promedio es aproximadamente 18 por ciento en ellado bajo,

y de 21 por ciento en ellado alto.

~Que ocurre cuando la concordancia entre las estimaciones es insufictente>

Responder esta pregunta requiere reevaluar la informacion con que se hicieron las

estimaciones. Las estimaciones ampliamente divergentes con frecuencia pueden

rastrearse hasta una de dos causas:

1. El planificador no ha comprendido adecuadamente 0ha malinterpretado el

ambito del proyecto.

2. Los datos de productividad que utilizan las tecnicas de estimacion basadas en

el problema son inapropiados para la ap l i c a c i o n . obsoletos (pues ya no r e f l e -

jan con precision la organizacion de ingenie ria de software) 0 se han aplicado

mal.

El planificador debe determinar la causa de la divergencia y luego reconciliar las

estimaciones.

I. ,



CAPITuLo 23 ESTIMACION PARA PROYECTOS DE SOFTWARE 7

!lit Tecrucas de esiimacion automatizada para proyectos de software-~ -=; -e--:JC"1ientas de estimaci6n autamatizadas

"V""" :e- 'ec ::jue plonificodor estime costa y

"""J.~ , -=:: :e cnolisis "si .. enronces" respecto de

'""::IOC-O::--';, .:' ccles del proyecto, coma la fecha de

~-=C_c : ::: : c-rillo de personal. Aunque existen muchas

-~- :--'::5 ::8 estirnccion automatizada [vecse el

"?'::,C·:': +csodeicnle en este capitulo) , todas presentan

= " ' - S-::5 :Gcccteristicas generales y realizan las

:; .e--' ;5 selSfunciones genericas [JON96]:

-::'""1cna de los enfregables del proyecfo. 5e estima el

'CToiio" de uno 0 mas productos de trabajo del

soiware. Los productos de trabajo incluyen 1 0=eoresentocion externa del sof tware (por ejemplo,

contcllcs. reportes], el software en si mismo (par

eiernplo, KLDC),funcionalidad entregada (por

ejernp lo . puntos de funci6n) e informaci6n descriptiva

'por ejemplo, documentos).

L Sefecci6n de los actividades del proyecto. 5e

selecciona el marco de trabajo del proceso

adecuado y se especifico el conjunto de tareas de

ingenieria del software.

3. Prediccicin de losnivelesdelpersonal. S e especifica el

nurnero de personas que sstoro disponible para realizar

el trobajo. Puesta que 1 0 relaci6n entre el personal

disponible y el frabajo (esfuerzo predicho) es

enormemente no lineal, estc es uno entrada impartante.

4. Predicci6ndel esfuerzo de software. Las

herramientas de estimaci6n emplean uno 0 mas

modelos [seccicn 23.7) que relacionan el torncfio de

los entregables del proyecto con el esfuerzo

requerido para producirlos.

5. Predicci6ndel costo del software. Dodos los

resultados del paso 4, los costas se cclculon

relacionondo los indices de trabajo con los

actividades del proyecto anatados en el poso 2.

6. Predicci6ndel progroma de trobajo del software.

Cuondo se conocen el esfuerzo, el nivel del personal

y las actividades del prayecto es pasible producir un

anteproyecto de progmma 0 1 ubicor el trabaja a

troves de las actividades de ingenieria del software

con base en los modelos recomendados para 1 0

distr ibuci6n del esfuerzo estudiados en el capitulo 24

La apl icaci6n de di ferentes herramientos de est imaci6n a

los mismos datos de proyecto permite encontrar una

variaci6n relativamente grande en los resultados

est imados. Mas importonte lodovio, en ocosiones los

volores predichos son significat ivamente diferentes de los

valores reales. Esto refuerza la noci6n de que los salidos

de los herramientos de estimaci6n se deben emplear como

un "punto de datos" a partir del cual se derivan los

estimaciones, no como 1 0 unico Fuente para una

estirnocion.

~,

- - ,C~VEU n m o d e l e d e

e s ti m o c io n r e f/ ej o 1 0

pobloei6n e p r o ye c to s

d e s d e 1 0 q u e s e h o

d e ri vo d o . P a r 1 0 t a n t o ,

e l m o d el o e s s en s i b le

0 1 d o m i n i o .

Un modelo de estimacion para software de computadora utiliza formulas obtenidas

empiricamente para predecir el esfuerzo como una func ion de LDC 0PF9 Los valo

res de LDC 0 PF se estiman mediante el enfoque descrito en las secciones 23.6.3

23.6.4. Pero, en lugar de emplear las tablas descritas en dichas secciones, los valo

res resultantes para LDC 0 PF se colocan en el modelo de estimacion.

Los datos empiricos que apoyan la mayo ria de los modelos de estimaci6n proce

den de una muestra limitada de proyectos. Por esta razon, mngun modelo de est

macion es apropiado para todas las clases de software ni en todos los entornos d

desarrollo En consecuencia, los resultados obtenidos a partir de tales modelos s

deben emplear juiciosamente.

9 En la secci6n 23.6.7 se sugiere un modelo empirico que utiliza casos de uso como la variable mdpendiente Sin embargo, a la fecha han aparecido relativamente pocos en la respectiva bibliografia

-1



-::.':~:5 s s : e D e

= - - : s : 5 i , n u n a c a /~

: -:::c : : : i o c a o s o a

t.= " ' e n o .

! H i J d iii""E n sunset.usc .

e d u j r e s e o r d l j

C O C O M O l l j

c o c om o -m a i l l . h f l n l

s e p u O O e o b ~

in fo rm a c io n ~

Q ( e r c o d e ( { j ( Q M O I f ,

e i n c l u s o s o f 1 w n r ed e s c a r g a b l e .

_- t: .ce.; ce estimaci6n debe calibrarse para reflejar las condiciones locales E

-:":'! : :!::e probarse mediante la aplicaci6n de los datos recopilados a partir' d e

:-::!::::; :::mpietados, colocar los datos en el modelo y luego comparar los resui.

: . . = : : : : ::::'.::5 con los predichos. Si la concordancia es insuficiente, el modelo debe afi-

- :.:'>::' ;:::,nerse a prueba nuevamente antes de que se pueda utilizar.

23.7.1 La estructura de los modelos de esttmccton

._.~.modele de estimaci6n tipico se deriva mediante el analisis de regresi6n de los

:3.:os recopilados de proyectos de software previos. La estructura global de talr;:s

rncdelos tom a la forma [MAT94]

(23-3)

- -•i

-1r

r•J

I.

!;

- I,

. .

don de A, B Y C son constantes obtenidas empiricamente, E es el esfuerzo en perso-

na-mes y eves la variable de estimaci6n (ya sea LDC 0 PF). Adernas de la relaci6n

anotada en la ecuaci6n (23-3), la mayo r i a de los modelos de estimaci6n tiene algu-

na forma de componente de ajuste del proyecto que permite ajustar E por otras

caracteristicas del proyecto (por ejemplo, complejidad del problema, experiencia del

personal, entomo de desarrollo). Entre los muchos modelos de estimaci6n orienta-I

dos a LDC propuestos en la bibliografia se encuentran

E = 5.2 X (KLDC)0 91

E = 5.5 + 0.73 x (LDC)116

E = 3.2 x (KLDC)105

E = 5.288 x (KLDC)10457

modelo Walston-Felix

modelo Bailey-Basili

modelo simple de Boehm

modelo Doty para KLDC > 9

Tambien se han propuesto model os orientados a PF. Entre estes se incluyen:

E = -91.4 + 0.355 PF

E = - 3 7 + 0.96 PF

E = -12.88 + 0.405 PF

modele de Albrecht y Gaffney

modelo de Kemerer ,modele de regresi6n para proyecto pequefio

Un rapido exam en de estos modelos indica que cada uno producira un resultadodiferente para los mismos valores de LDC 0 PF. La implicaci6n es clara. .Los mode-

los de estimaci6n deben calibrarse para las necesidades locales!

23.7.2 £1modelo COCOMO II

En su libro clasico acerca de "economla de la ingenieria del software", Barry Boehm

[BOE81] introduce una jerarquia de model os de estimaci6n de software que lIeva el

nombre de COCOMO, por COnstructive COst MOdel (Modelo Constructivo de Costos)

EImodelo COCOMO original se volvi6 uno de los mas ampliamente utilizados y estu-

diados model os de estimaci6n de costa de software en la industria. Ademas, ha evo-

lucionado a un modelo de estimaci6n mas amplio, lIamado COCOMO II [BOE96,

BOEOO].AI igual que su predecesor, COCOMO II es en realidad una jerarquia de

model os de estimaci6n que aborda las areas siguientes:



tQ u e e s

. u n p u n t o

o b j e t o ?

" .. -" - - - -f _ . _

r ,

i,. .!.

~;w ::~:_:.::::~.: ?AR.A PROYECTOS DE SOFTWARE

• »: :.: z: :~r;'posicj6n de Ia apIicaci6n. Se emplea durante las primeras eta

:C ' '~:-5e:-:eria del software, cuando son primordiales la elaboraci6n de

:~::::::;:05 de las interfases de usuario, la consideraci6n de la interacci6n

':-:::-,-.a,:: y el sistema, la valoracion del desernpeno y la evaluaci6n de la

~.a'::..;rez de la tecnologia .

• . ,:: celo de etapa de disaio temprano. Se utiliza una vez que se han estabili-

zado los requisitos y se ha establecido la arquitectura basica del software.

• ',:)deIo de etapa posterior a Ia arquitectura. Se emplea durante la construcci6

':el software.

-\' :gual que los modelos de estimaci6n del software, los model os COCOMO IIreq

ren informacion de tamario. Como parte de la jerarquia del modele hay disponi

tres opciones diferentesde tamafio: puntos objeto, puntos de funci6n y Iinea

c6digo fuente.

EI modelo COCOMO IIde composici6n de la aplicaci6n emplea puntos objeto,

medida indirecta de software que se calcula mediante conteos del numero de 1)

tallas (en la interfaz del usuario), 2) reportes y 3) componentes que probableme

se requieran para construir la aplicaci6n. Cada instancia de objeto (por ejemplo,pantalla 0 reporte) se clasifica en uno de tres niveles de complejidad (es decir,

ple, medio 0dificil) aplicando criterios sugeridos por Boehm [BOE96]. En esencia

complejidad es una funci6n del numero y origen de las tab las de datos del cIien

el servidor que se requieren para generar la pantalla 0 reporte, y el numero de

tas 0 secciones presentadas como parte de la pantalla 0 el informe.

Una vez que se ha determinado la complejidad, el numero de pantalIas, infor

y componentes se pondera de acuerdo con la tabla ilustrada en la figura

Entonces se determina la cuenta de puntos objeto al multiplicar el numero orig

de instancias de objeto por el factor de ponderaci6n en la figura y se suma para o

ner una cuenta total de puntos objeto. Al aplicar el desarrollo basado en com

nentes 0 la reutilizaci6n general de software se estima el porcentaje de reutilizac(%reut) y se ajusta la cuenta de puntos objeto:

NPO = (puntos objeto) x [(100 - %reut)/IOOj

donde NPO se define como nuevos puntos objeto.

Para obtener una estimaci6n del esfuerzo con base en el valor NPO calculado,

debe calcular una "tasa de productividad". La figura 23.7 presenta la tasa de prod

tividad

PROD = NPO/persona-mes

para diferentes niveles de experiencia del desarrollador y madurez del entorno

desarrollo. Una vez determinada la tasa de productividad se puede obtener una

macion del esfuerzo del proyecto del modo siguiente:

esfuerzo estimado = NPO/PROD



,~,Iil_~_:_:Ii:'~",

-,'~

10

Peso decompleiidod

Simple Medio Dificil

2 3ontollo

2 5 8eporte

Ccmponente 3GL

7::sc de productividad pot puntos objeto [BOE96].

III ief~1 capocidod del ' M uy

Bo i o Nom in a l A f t c t M . J y~ bojc 0 1 1 0

1t I todure1/ capacidod del entomo MttyBaja Nomin a l Allo M u y

bojo alto

TA SA P RO DU CT MD AD (P RO D) 4 7 13 25 50

E n w w w . q s m . ( O l IJ

s e p u e d & ef l(OI l t ror

i I l fo f m l K i O n O O l f r o d e

h a m J m i e n l u s d e

e s l i m t J d O l l d e r o s t o d e

s o fI w o r e q u e n O l l6 ' I O I u d o n o d o 0 p o f f i r

d e 1 0 e c u o d o n d e !s o f f w o r e .

En modelos COCOMO II mas avanzados'? se requieren varios factores de escala,

controladores de costa y procedimientos de ajuste. EI lector interesado debe leer

[BOEOO]0visitar el sitio Web de COCOMO It

23.7.3 La ecuecicn del software

La ecuaci6n de software [PUT92] es un modelo multivariable que sup one una distri-

buci6n especifica del esfuerzo a 10 largo de la vida de un proyecto de desarrollo de

software, EI modelo procede de datos de productividad recopilados de casi 4 0 0 0

proyectos de software contemporaneos. Con base en estos datos, un modelo de esti-

maci6n de la forma

(23 -4)

donde

E = esfuerzo en personas-mes 0personas-ano

t = duraci6n del proyecto en meses 0 afios

B = "factor especial de habilidades" I I

10 Como se anoto anteriormente, estos modelos utilizan conte os de PFy KLDCpara la variable tamano

lIB aumenta lentamente con forme "crecen la necesidad de integracion, las pruebas, la garantia deca-

lidad. la documentacion y las habilidades de gesti6n" [PUT92].Para programas pequerios (KLDC 5

a 15),B = 0 16. Para programas mas grandes que 70KLDC,B=0,39,

:" >. .-"1 ~

~.,..j

~

J



C A PIT UL O 23 ESTIMACION PARA PROYECTOS DE SOFTWARE

P = "pararnetro de productividad" que refleja: madurez global del proc

practicas de gestion, la medida en la que se emplean las buenas pra

de ingenierfa del software, el nivel de los lenguajes de prograrnacion

zados, el est ado del entorno del Jas habilidades y experie

la aplicacion.

Los valores tipicos pueden ser P = 2 000 para desarrollo del software ani da

tiernpo real; P = 10 000 para software de teleeomunieaciones y sistemas; P = 2

para aplieaeiones de sistemas de negoeios. EI pararnetro de productividad se

calcular para condiciones locales si se emplean datos historicos recopilado

esfuerzos de desarrollo previos.

Es importante notar que la ecuacion del software tiene dos parametres inde

dientes. I) una estirnacion del tamano (en LOC)y 2) una estimacion de la dura

del proyeeto en meses 0 anos calendario.

Putnam y Myers [PUT92] sugieren un eonjunto de ecuaciones derivadas

ecuacion del software para simplifiear el proceso de estirnacion y emplear una f

mas comun para su modelo de estimacion E1 minirno de desarrollo se

ne como

tmin = 8. 14 (LDCIP)o43 en meses para tmin > 6 meses

E = 180Bt3 en personas-mes para E 2: 20 personas-mes

[.23

Notese que t se representa en arios en la ecuaci6n (23-5b).

Al utilizar las ecuaciones (23-5) con P = 12000 (el valor reeomendado para

ware cientifico) para el software CAD estudiado previamente en este capitulo,

tmm = 8.14(33200/12000)°43

tmin = 12.6 meses calendario

E = 180 x 0.28 x (lOW

E = 58 personas-mes

Los resultados de la ecuacion del software corresponden favorablemente conestimaciones desarrolladas en la secci6n 23.6. Al igual que el modelo COCO

sen ala do en la seccion preeedente, la ecuacion del software ha evolueionado du

te la decada pasada. En [PUT97b] se puede encontrar una detallada exposicion

una version extendida de este enfoque de estimaei6n.

23.8

Vale la pena eomplementar los metodos conveneionales de estimacion de costa

software con un enfoque diseriado explicitamente para software 00. Lorenz y K

[LOR94] sugieren el enfoque siguiente:

1. Desarrollar estimaeiones aplicando la descomposicion de esfuerzo, analisisPF y cualquier otro metodo que sea aplicable en apIicaciones conveneionales

'-~.

-1



PARTE CUATRO G ES TI ON D E PROYEC fOS DE SOITWARE

2. Aplicar el modelado de analisis orientado a objetos (capitulo 8), desarrollar

casos de uso y determinar un conteo. Reconocer que el numero de casos de

uso puede cambiar conforme avance el proyecto.

3. A partir del modelo de analisis, determinar el numero de clases clave (llama-

das c la se s de a tu il is is en el capitulo 8).

4. Categorizar el tipo de interfaz para la aplicacion y desarrollar un multiplicador

para las clases de soporte

Tipo de interfaz

Sin lUG

interfaz del usuario basada en texto

lUG

lUG cornpleio

Multiplicador

2.0

2.25

2.25

3.0

Multiplicar el numero de clases clave (paso 3) por el multiplicador para obte-

ner una estimacion del numero de clases de soporte.

5. Multiplicar el numero total de clases (clave + soporte) por el numero prome ..

dio de unidades de trabajo par clase. Lorenz y Kidd sugieren de 15 a 20 perso

nas-dia par clase.

6. Comprobar de manera cruz ada la estimacion basada en clase al multiplicar el

numero promedio de unidades de trabajo por caso de uso.

l ._ • .

LaS tecnicas de estrmacion estudiadas en las secciones 23.6, 23.7 Y23.8 se pueden

aplicar en cualquier proyecto de software. Sin embargo, cuando un equipo de soft-

ware encuentra una duracion de proyecto extremadamente corta (semanas mas que

meses) -que probablemente tengan una continua corriente de cambios- la planifi-

cacion del proyecto en general y la estimacion en particular se deben abreviar. 12 En

las secciones siguientes se examinan dos tecnicas de estimacion especializadas

23.9.1 Estimacion para desarrollo agil

Puesto que los requerimientos para un proyecto agil (capitulo 4) se definen como un

conjunto de escenarios de usuario (por ejemplo, "historias" en programacion extre-

ma) es posible desarrollar un enfoque de estimacion informal, aunque razonable-

mente disciplinado y significative dentro del contexte de la planificacion del proyec-

to para cada incremento de software

La estimacion para los proyectos agiles aplica un enfoque de descomposici6n que

abarca los pasos siguientes:

12 "Abreviar" no significa eliminar. lncluso los proyectos de corta duracion deben planificarse, y laes-timacion es el fundamento de la planificacion solida.

. . . . . .

)

i -1f

~.~t·

~~t.

.~~~

•



:sarrollar

:; casos de

we (llarna_

nultiplicador

para obte-

-ro prome.

j a 20 perso-

mltiplicar el

.8 se pueden

uipo de soft-

nas mas que

)- la planifi-

breviar. ! 2 En

ializadas

n como un

cion extre-

razonable-

del proyec-

posicion que

·~carse. y la es-

t .

.~ . .

"

C o m o s e

d e s a r r o l l a n

l a s e s ti m a c i o n es

c ua n d o s e a p l i e a

u n p r o c e s o a g i l ?

t c O N S E J O S .E n e l c o n l e x l o d e l ae s t i m a c i o n p a r a u np r o y e c t o 6 g i l ," v o l u m e n " e s u n ae s ti m a c i o n d e ll a m a n o g lo b a l d e u n

e s c e n a r i o d e u s u a r ioe n W C 0 P F

CAPITULO 23 ESTIMACrON PARA PROYECTOS DE SOFTWARE

1. Cada escenario de usuario (el equivalente de un minicaso de usa c

co rn i e nzo mismo de un proyecto por los usuarios finales u otros p

se considera por separado respecto de propositos de estimacion.

2. EI escenario se descornpone en el conjunto de funciones y las tarea

nieria del software que se requeriran para desarrollarlo.

3a. Cada tarea se estima por separado. Nota: la estirnacion se puede b

tos historicos, en un modelo empirico 0 en la "experiencia".

3b. Alternativamente, el "volumen" (tarnario) del escenario se puede e

LDC, PF 0alguna otra medida orientada a volumen (por ejemplo, p

jeto).

4a. Las estimaciones de cada tarea se suman para crear una estimacion

escenario.

4b. Alternativamente, el volumen estimado para el escenario se traduce

fuerzo mediante la aplicacion de datos historicos.

5. Las estimaciones de esfuerzo ace rca de todos los escenarios que se

men t a r a n para un incremento de software dado se suman con el tirrollar el esfuerzo estimado para el incremento.

Puesto que la dura cion del proyecto requerido para el desarrollo de un

de software es bastante corta (usualmente de 3-6 sernanasj. este enfoq

mac ion tiene dos propositos 1) asegurar que el numero de escenarios qu

ran en el incremento se integra con los recursos disponibles, y 2) establece

para ubicar el esfuerzo conforme se desarrolla el incremento .

23.9.2 Estimacion para proyectos de ingenieria Web

Como se asento en el capitulo 16, los proyectos de ingenieria Web con

adoptan el modelo de proceso agil. Es factible emplear una medicion dfuncion modificada, en conjunto con los pasos subrayados en la seccion

el tin de desarrollar una estimacion para la WebApp.

Roetzheim [ROEOO]sugiere los siguientes valores de dominio de in

cuando se adaptan puntos de funci6n (capitulos 15y 22) para la estirnacion

• Entradas son cada pantalla 0 formate de entrada (por ejemplo. CGI

cada pantalla de mantenimiento y, si en alguna parte utiliza una etiq

metafora de cuaderno, cada etiqueta.

• Salidas son cada pagina Web estatica, cada gui6n de pagina Web din

(por ejemplo, ASP, ISAPI 1 . . 1 otro guion DHTML)y cada reporte (ya sea

bas ado en Web 0 sea del todo administrativo).

• Tables son cada tabla logica en la base de datos mas, si emplea XML

almacenar datos en un archive, cada objeto XML (0 coleccion de atr

XML)



r-

I

)

716 PARTE CUATRO G ES TION DE PROYECTOS DE SOFTWARE

• Las interfaces retienen su definicion como archivos logicos (por ejemplo,

formatos de registro unicos) en las fronteras exteriores del sistema .

• C on su ltas son cada interfaz publicada externamente 0utiliza una interfaz

orientada al mensaje. Un ejemplo tipico son las referencias externas DCOMa

COM.

Los puntos de funcion (calculados empleando los valores de dominio de informacion

anotados) son un indicador razonable del volumen para una WebApp.Mendes y sus colegas [MENOl] sugieren que el volumen de una WebApp se deter-

mina mejor mediante la recopilacion de medidas (llamadas "variables predictoras")

asociadas con la aplicacion (por ejemplo, con teo de pagina. conteo de medias

audiovisuales, conteo de funcion), las caracteristicas de su pagina Web (por e;empla.

complejidad de pagina. complejidad de vinculacion, complejidad grafica), sus carac-

teristicas de medios audiovisuales (por ejernplo, duracion de los clips) y caracteristi_

cas funcionales (por ejemplo, longitud de codigo. longitud de codigo reutilizado)

Dichas medidas se pueden emplear en el desarrollo de modelos de estimaci6n empi-

Estimacion de esfuerzo y costo

Objetivo: E I ob je tivo de la s he rra m ie nta s de

e sti m ac i6n de e sfue rzo y c osto e s p ro po rc io na r

0 1 e qu ipo de l p ro ye cto un a estimocion d e l e s fu e rz o

re que rido , de 1 0 dura c i6n de l pro ye do y de l c o sto e n un a

fo rm a q ue a bo rde la s c ara cte ris tic as e spe df ic as de l

pro y e c to inm edia to y e l e n to rn o e n e l q ue se construiro,

Mecanica: E n ge ne ra l, la s he rra m ie nta s de e stim a ci6n de

c o sto u til iza n un a b a se de da to s hisrcr ico p ro ce de nte de

pro ye cto s lo ca le s, da to s re co pila do s a tro ve s de 1 0in dustria y un m o de lo em piric o (po r e jem plo , C OC OM O II)

q ue se e m ple a p ara c alc ula r e stim a cio ne s de e sfue rzo ,

du ra ci6n y c osto . la s c ara cte ri stic as de l p ro ye cto y e l

e n to rn o de de sa rro llo so n e n tra da s, y 1 0 h e r r am i e n t apro po rc io na un ra ngo de e stim a ci6n de so lido s.

Herramientas representefives 13

Costar, d es arro ll ad o p o r S of ts ta r S ys te m s

( www .s of ts ta rs ys te m s.c o m ). e m p le a e l m o d el o

C OC OM O II pa ra de sa rro lla r e stim a cio ne s de

sof tware .

C o st X p er t, de sa rro lla do p or C ost X pe rt G ro up , In c.

i www.c o stx pe rt.c o m ). i nte gra m o d el os d e e sti m a ci 6n

m ultip le s y un a b ase de da to s historico d e p ro y e ct os .

Es tim at e Pro fe ss ional , de sa rro lla do p or e l S of tw are

P ro du cti vi ty C e nte r, In c . ( www .s pc .c o m L e st6 b as ad o e n

COCOM O II Y e n e l M ode lo SLIM .

K no wled ge P lan , d es arr ol la do p or S of tw are P ro du ct iv ity

R e se a rc h ( www .s pr .c o m ) . u ti li za 1 0 e n trada de pun to de

hmc ion c om o e l c on tro la do r prim a rio pa ra un p aq ue te

de e stim a ci6n c om p le to .

P ri ce S , de sa rro lla do p or Pric e S yste m s

( www .p ri ce sy ste m s .c o m ). e s u na d e l as h erra m i en ta s

m a s vie ja s y a m pl ia m en te uti l iza da s e npro ye cto s de

de sa rro llo de so ftw are a gra n e sc ala .

S EER / S EM, de sa rro lla do po r G alo ra th In c.

(w ww .ga lo ra th.c om ). pro po rc io na un a c apa cida d de

estimocion c omp l e t a , cnclisis d e s e n si b il i da d ,

v al ora c i6 n d e ri es go y o tra s c ara c te ri st ic as .

SLIM-Estimate, de sa rro ll ado p or Q SM (w ww .q sm .c om l ,

e cho m o no de "b ase s de c on oc im ie nto in dustria l"

de ta lla da s pa ra o fre ce r un a "veriiicccion s an ita ri a" d e

la s e stim a cio ne s o bte nida s e m ple an do da to s lo ca le s.

13 Las herramientas anotadas aqui son una muestra de esta categoria. En la mayo ria de los casos los

nombres de las mismas son marcas registradas por sus respectivos desarrolladores.

I. .



=v __ ~~""<'$A" ','.'.','" ,,'.,",

.

mplo,

nterfaz

is DeOM 0

nformaci6n

pp se deter-

redictoras")

de medios

lor ejemplo,

), sus carac-

caracteristi _

reutilizado) .

aci6n empi.

vore

to basado en

oductivity

de punto de

un paquete

ramientas

.yectos de

cidad de

L

-i.com},

.trio!"

litaria" de

; locales.

-:._os casos los

>

it

CAPITULO 23 ESTlMACrON PARA PROYECTOS DE SOFTWARE

\

rica para esfuerzos de proyecto total, de creaci6n de pagina. de creaci6n de m

audiovisuales y de creacion de guiones. Sin embargo, todavia falta realizar m

bajo antes de que tales modelos puedan emplearse con confianza.

tt ! r ~ ~ en as is t e m a t i c a d e

o r d e n a r l a s

o p c i o n e s

a so c i a d a s c on 1 0d e c i s i o n

d e s a r r o l l a r -

c o m p r a r ?

A menudo, en much as areas de aplicaci6n de software es mas rentable adquiri

desarrollar software de computadora. Los gestores de ingenieria del sof

enfrentan una decisi6n de desarrollar-comprar que tal vez se complique aun m

varias opciones de adquisicion: 1) el software se puede comprar (0 adquirir la

cia) ya desarrollado, 2) los componentes de software de "experiencia comple

"experiencia parcial" (vease la secci6n 23.4.2) se pueden adquirir y luego mod

e integrar para satisfacer necesidades especificas, 03) el software se puede con

de manera personalizada por medio de un contratista externo para satisface

necesidades del comprador.

Los pasos involucrados en la adquisici6n los definen 10c rucial del software

se comprara y el costo final. En el analisis final, la decision desarrollar-comprar

realiza basandose en las siguientes condiciones: 1) GElproducto de software

disponible antes que el software desarrollado de manera interna? 2) GElcos

adquisici6n mas el costo de personalizaci6n sera menor que el costo de desarr

el software de manera interna> 3) GElcosto del soporte externo (por ejemplo, un

trato de mantenimiento) sera menor que el cos to del soporte interno? Estas c

ciones se aplican a cada una de las opciones de adquisicion.

23.10.1 Creacion de un Cubol de decision

Los pasos recien descritos se pueden aumentar mediante tecnicas estadisticas

como el analisis del arbo! de decision [BOE89]. Por ejemplo, la figura 23.8 bosquej

arbol de decisi6n para un sistema basado en software, X En este caso, la orga

ci6n de ingenierfa del software puede I) construir el sistema X desde cero. 2)

lizar componentes existentes de "experiencia parcial" para construir el sistemcomprar un producto de software disponible y modificarlo para satisfacer las

sidades locales, 04) contratar el desarrollo de software con una empresa exter

Si el sistema se construira desde cero existe un 70 por ciento de probabilidad

que el trabajo sea dificil. Al emplear las tecnicas de estimacion estudiadas ante

este capitulo, el planificador del proyecto estima que un esfuerzo de desarrollo

cil costara 450 000 dolares. Un esfuerzo de desarrollo "simple" se estima que co

380 000 dolares. EI valor csperado para el coste. calculado a 10 largo de cualq

rama del arbol de decisi6n, es

costo esperado =I(probabilidad de la ruta), x (costo estimado de la ruta

donde j es la trayectoria del arbol de decision. Para la trayectoria de construcci6

costo esperadOconstrUir=0.30(380K dolares) + O . 70(450K dolares) = 429K d6



718

\

frLb

",- r': .: : . ,

"

._

P AR T E C UA TR O G ES TIO N D E PROYECfOS DE SOITWARE

S imp l e (0.30) = 380000 do l o r e s

tr===~ __ ~ _Difki l (0.70) 450000 do l o r e s

Const ruir275 000 do l o r e s

· ~ ~ i · H · i j · ; · f · ! q i ~ ; j ~ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ~

Arbol de decision

para apoyar 1 0

decision

desarrollar-

comprcr.

Si ~ 310 000 do l o r e s

t;. 490000 do l o r e sComplejo(0.80)

210 000 do l o r e s

Si n ccrnbios 350000 d-I~ o a re s

" 500 000 do l o r e sCa n cornbios(0.40)

Al seguir otras trayectorias del arbol de decision tambien se muestran, en una

diversidad de circunstancias, los costos proyectados para reutilizacion, compra v

contratacion. Los costos esperados para dichas trayectorias son

costo esperadOreutllizar= OAO(275K dolares) = O.60[O.20(310K dolares) + 0.80(490'

dolaresil = 382K dolares

costa esperadocomprar = 0.70(21 OKdolares) + O.30(400Kdolares) = 267K dolares

costa esperadocontratar = 0.60(350K dolares) + 0.40(500K dolares) = 41OKdolares

Con base en la probabilidad y los costos proyectos que se han anotado en la figura

23.8, el costo esperado mas bajo es la operon "comprar".

Sin embargo, es importante sefialar que se deben considerar muchos criterios -no

solo costo- durante el proceso de toma de decision. Disponibilidad, experiencia deldesarrollador-vendedor-contratista, concordancia con los requisites. "politic as"

locales y la probabilidad de cambiar son solo algunos de los criterios que pueden

incidir en la decision final de construir. reutilizar. comprar 0 contratar.

23.10.2 suocontrcrtccton

Tarde 0 temprano, cualquier comparua que desarrolla software de computadora se

plantea una pregunta fundamental: ~existe una forma de conseguir los sistemas y

software necesarios a un precio mas bajo? La respuesta no es tan simple, y los deba-

tes emocionales que genera la pregunta siempre conducen a una sola palabra: sub-

contrataci6n.

Como concepto, la subcontratacion es extremadamente simple. Las actividades

de ingenieria del software se contra tan con una tercera parte que realiza el trabajo

-.--,.~:: .,.<~.,."..,.,.-,-_~,.,c__-~- __",.._, ~,. __~" .. _._~.r ~~ --

i



~

- - - -~es

~es

~es

'es

r es

res

.ran, en una

n, compra y

+ 080(490K

7K d6lares

OK dolares

) en la figura

:riterios -no

oenencia del

"politicas"

iue pueden

.utadora se

sistemas y

y los deba-

' , . : \ labra sub -

, actividades

/0el trabaio

I. .,-

CAPITULO 23 ESTlMACION PARA PROYECTOS DE SOFTWAEE

a un costa mas bajo y, asi se espera. mayor calidad. EI trabajo de software llevado

cabo dentro de una compafiia.se reduce a una actividad de gestion de contratos."

La decision de subcontratar puede ser estrategica 0 tactica. En el ambito estra

gico, los gestores comerciales consideran si una porcion significativa de todo el

bajo de software se puede contratar con otros. En el plano tactico, un gestor de p

yecto determina si parte 0 todo un proyecto puede lograrse mejor al subcontratar

trabajo de software.

Sin importar la amplitud de la vision, la decision de subcontratar usualmente

financiera. Una exposicion detallada del analisis financiero de la subcontratacio

esta mas alia del ambito de este Iibro y mejor se deja a otros (por ejemplo, [MIN9

Sin embargo, vale la pena una breve revision de los pros y contras de la decision.

En el lado positive. usualmente es factible ahorrar en el costo reduciendo

numero de personal de software y las instalaciones (por ejemplo, computadora

infraestructura) que los soportan. En el lado negative, una compariia pierde cie

control sobre el software que necesita. Dado que el software es una tecnologia

diferencia sus sistemas, servicios y productos. una compania corre el riesgo de pon

el destino de su competitividad en las manos de una tercera parte.

. :)

14 Lasubcontrataci6n se puede considerar. de manera mas general, como cualquier actividad que c

duce a la adquisici6n de software 0 algunos de sus componentes con una fuente externa a la o

nizaci6n de ingenieria del software

- ,



-~

\J

72 0 P AR T E C UA TR O GESnON DEPROYEcrOS DE SOFTWARE

EI planificador de! proyecto de software debe estimar tres factores antes de que un

proyecto comience: cuanto tiempo tornara, cuanto esfuerzo requerira y cuanto per-

sona! estara involucrado. Ademas. el planificador debe predecir los recursos (hard-

ware y software) que se requeriran y el riesgo involucrado.

La descripcion del ambito ayuda al planificador a desarrollar estimaciones emplean-

do una 0mas tecnicas que se clasifican en dos amp lias categonas descomposirion

y modelado ernpirico.

Las tecnicas de descornposicion requieren un bosquejo de las principales funcio-

nes del software, seguido par estimaciones de I) el numero de LDC, 2) valores selec-

cionados dentro del dominio de informacion, 3) el numero de casos de usc, 4) el

numero de personas-mes requerido para implementar cada funcion, 05) el numero

de personas-rues requerido para cada actividad de ingenieria del software. Las tee-

nicas empiricas usan expresiones para esfuerzo y tiempo obtenidas empiricamente

para predecir estas cantidades del proyecto. Se pueden utilizar herramientas auto-

matizadas para implementar un modelo empirico especifico.

Por 10 general, las estimaciones precisas de proyecto emplean al menos dos de

las tres tecnicas anotadas. Al comparar y reconciliar las estimaciones obtenidas conla aplicacion de diferentes tecnicas. el planificador tiene mas probabilidad de calcu-

-1

I. .



CAPITULO 23 ESTIMAC!ON PARA PROYECTOS DE SOFTWARE

lar una estimacion precisa. La estimacion de! proyecto de software nunca sera

ciencia exacta, pero una combinaci6n de buenos datos historicos y tecnicas s

maticas puede mejorar la precision de la estimaci6n.

de que un

ianto per-

sos (hard-

; emplean-

mposicion

s funcio-

es selec-

so, 4) el

numero

Las tee-

.camente

ntas auto-

os dos de

-nidas can

de calcu-

i,'-.••~. ..t.

-[BEN92J Bennatan, E. M, Software Project Management A Practitioner's Approach, McGraw-

1992.[BEN03J Bennatan, E. M. "So What is the State of Software Estimation?" en The Cutter Edge

informativa en linea), II de febrero de 2002, disponible en http.z /www.cutter.com.

[BOE81 J Boehm, B., Software Engineering Economics, Prentice-Hall, 1981.

[BOE89J Boehm, S., Risk Management, IEEE Computer Society Press, 1989.

[BOE96J Boehm, B., "Anchoring the Software Process", en IEEE Software, vol. 13, num. 4,

de 1996, pp. 73-82.

[BOEOO] Boehm, B. et al., Software Cost Estimation in COCOMO II, Prentice-Hall, 2000.

[BR075J Brooks, F, The fvlythical Man-Month, Addison-Wesley, 1975.

[GAU89J Gause, D. C Y G. M. weinberg, Exploring Requirements: Quality Before Design, D

House, 1989.

[H0091J Hooper, J . y R. O. Chester, Software Reuse Guidelines and Methods, Plenum Press,

UON96J Jones, c ., "How Software Estimation Tools Work", en American Programmer, vol. 9,

7, julio de 1996, pp. 19-27.

[LOR94J Lorenz, M. y J . Kidd, Object-Oriented Software Metrics, Prentice-Hall, 1994.

[MAT94] Matson, J ., B. Barrett y J . Mellichamp, "Software Development Cost Estimation UFunction Points", en IEEE Trans. Software Engineering, vol. SE-20, num. 4, abril de 1994275-287.

[MCC98J McConnell , S, Software Project Sutvival Guide, Microsoft Press, 1998.

[MENO!] Mendes, E, N. Mosley y S. Counsell, "Web Metrics-Estimating Design and Autho

Effort", IEEEMultimedia, enero-marzo de 2001, pp. 50-57.

[MIN95] Minoli, D, Analyzing Outsourcing, McGraw-Hi ll , 1995.

[PHI98] Phillips, D., The Software Project Manager's Handbook, IEEE Computer Society P

1998

[PUT78J Putnam, L., "A General Empirical Solution to the Macro Software Sizing and Estima

Problem", en IEEE Trans. Software Engineering, vol. SE-4, num. 4, julio de 1978, pp. 345-

[PUT92J Putnam, L. y W. Myers, Measures for Excellence, Yourdon Press, 1992.

[PUT97a] Putnam, L. y W Myers, "How Solved Is the Cost Estimation Problem?", en

Software, noviembre de 1997, pp. 105-107.

[PUT97bJ Putnam, L. y W. Myers, Industrial Strength Software: Effective Management U

Measurement, en IEEE Computer Society Press, 1997.[ROEOO]Roetzheim, W, "Estimating Internet Development", en Software Development, agosto

2000, disponible en http://www.sdmagazine.com/documents!s=741/sdm0008d/0008d.htm.

[SMI99] Smith, J ., "The Estimation of Effort Based on Use Cases", Rational Software Corp., 1

se puede descargar de http://www.rational.com/media/whitepapers/finalTP 171.PDF

23.1. Suponga que es el gestor de proyecto de una compafua que construye software

robots caseros. Se le ha contratado para construir el software destinado a un robot que cort

pasto. Describa por escrito el ambito del software. Asegurese de que la descripci6n del am

este acotada. Si no est a familiarizado con los robots, investigue un poco antes de comenza

escribir. Ademas, establezca sus suposiciones acerca del hardware que se requeri

Alternativa: sustituya el robot que corta el pasto por otro problema rob6tico que Ie interese

23.2. La complejidad del proyecto de software influye en la precisi6n de la estimaci6

Desarrollar una lista de caracteristicas de software (por ejemplo, operaci6n concurrente, sa

grafica) que afecten la complejidad de un proyecto. Establecer prioridades en la lista.

_",

http://www.cutter.com./

http://www.sdmagazine.com/documents!s=741/sdm0008d/0008d.htm.

http://www.rational.com/media/whitepapers/finalTP

http://www.rational.com/media/whitepapers/finalTP

http://www.sdmagazine.com/documents!s=741/sdm0008d/0008d.htm.

http://www.cutter.com./



72 2 P AR TE C U AT RO G ESTIO N D E PROYECTOS DE SOF lWARE

23.3. El desempeno es una consideracion importante durante la planificacion. Comentar c'

se puede interpretar de manera diferente el desempefio, dependiendo del area de apl icaci6~~0software. el

23.4. Haga una descornposicion funcional del software robotico que describio en el probl

23.1. Estime el tamano de cada funcion en LDC. Suponga que su organrzacion prodUcee:a

LDC/pm con una escala salarial de 7 000 dolares por persona-meso Estime el esfuerzo y co ~orequeridos para construir el software ernpleando la tecnica de estimacion basada en LOCde0

es-crita en este capitulo.

23.5. Emplear el modelo COCOMO II en la estimacion del esfuerzo que requiere la construcci6

del software para una simple ATMque produce 12 pantallas. 10 reportes y requerira aproximada~

mente 80 componentes de software. Suponer complejidad promedio y madurez desarrollador_

entomo promedio. Emplear el modelo de composicion de apl icacion con puntos objeto.

23.6. Utilizar la ecuacion del software para estimar el software del robot que corta pasto del

problema 23.1. suponer que las ecuaciones (23-5) son aplicables y que P = 8000.

23.7. Comparar las estimaciones de esfuerzo obtenidas en los problemas 23.4 y 23.6. ~Cuales

la desviacion estandar y como afecta el grado de certidumbre acerca de la estimacion>

23.8. Utilizar los resultados obtenidos en el problema 23.7 para determinar si es razonable

esperar que el software se construya dentro de los siguientes seis meses y cuanto personal S e

tendna que emplear para realizar el trabajo.

23.9. Desarrollar un modelo de hojas de calculo que implemente una 0mas de las tecnicas de

estimacion descritas en este capitulo. Alternativamente, adquirir de fuentes basadas en Web

uno 0mas modelos en linea para la esttmacion de proyectos de software.

23.10. Para un equipo de proyecto, desarrollar una herramienta de software que implementf

cada una de las tecnicas de estimacion desarrolladas en este capitulo.

23.11. Parece extrario que las estimaciones de costo y programa de trabajo se desarrollo

durante la planiflcacion del proyecto de software, antes de que se haya llevado a cabo un dis,

fio 0un analisis detallado de los requisitos de software. ~Por que cree que se haga esto? ~ExIste!

circunstancias en las cuales no se deba hacer?

23.12. Vue Iva a calcular los valores anotados para el arbol de decision en la figura 23.8

Suponga que cada rama tiene una probabilidad de 50-50. ~Esto cambiaria su decision final?

La mayoria de los libros de gestion de proyectos de software incluyen anal isis de la estimac.or.

de proyectos. El Project Management Institute (PMBOK Guide, PM!, 2001), Wysoki Ysus colegas

(Effective Project Management, Wiley, 2000), Lewis (Project Planning Scheduling and Control. :e~-

cera edicion, McGraw-Hill, 2000), Bennatan (On Time, Within Budget: Software Pt=:':

Management Practices and Techniques, tercera edicion, Wiley, 2000) y Phillips [PHI98] ofrecen ::;::-

les directrices de estimacion.

Jones (Estimating Software Costs, McGraw-Hil l, 1998) ha escrito uno de los tratamientos rr .as

completos de la materia publicados a la fecha. Su libro contiene modelos y datos aplicables ~

estimaciones de software en cualquier dominio de aplicacion. Coombs (IT Project Estimac::

Cambridge University Press, 2002), Roetzheim y Beasley (Software Project Cost and scnec::Estimating: Best Practices, Prentice-Hall, 1997) y wellman (Software Costing, Prentice-Hall. 1qG ~

presentan muchos modelos utiles y sugieren directrices paso a paso para generar las me j o r e s

estimaciones posibles.

El detallado tratamiento de Putnam y Myers de la estimacion de costo del software ([Pl'T~:

y [PUT97b]) Y los libros de Boehm acerca de economia de ingenieria del software ([BOE8: -'

COCOMO II [BOEOO])describen modelos de estimacion empiricos. Estos libros praporcionan :_;~analisis detallado de datos derivados de cientos de proyectos de software. Un libra excelente : ::

cr



:ntar corno

Icacion del

I problernaoduce 450

"zo Y cOsto

1LDC desc

mstrucci6n

Jroximada_;arrollador _o.

~pasto del

6. ~Cual esm?

razonable

lersonal se

.ecnicas de

as en Web

.nplernenr-

jesarrollen

)0 un dise-

o? ~Existen

lgura 23.8.

in final?

estimaci6n

"JS colegasntrol, ter-

e Project

recen uti-

ntos mas

licables a

stimation,

Schedule

Hall, 1992)

as mejores

re ([PUT92]

[BOE81] Y

rcionan un

xcelente de

72

Delvlarco sContiothng 5c'~.',c;re FY:'ec:s Yourdon Press, 1982) ofrece un valiosa vision de gcstion

medicion y estimac.or: de ;'fcyec:c5 de software. Lorenz y Kidd (Object-Oriented Softwar

vietrics. Prentice-Hall. i99.. :: Cxkbur. SX,T,:ng Object-Oriented Projects, Addison-Wesley

1998) consideran la estirnac.on para si s ernas crientados a objetos.

En Internet hay dispor.ible .ira 5.::"F .a variedad de fuentes de informacion ace rca de esti

maci6n de software. t.r.a iista 30:·.;,,:'za a ce rererencias en la World Wide Web se encuentra e

el sitio Web de SEPA:

http;//www.mhhe.com/pressman.

Documents

Cap23 Est Imac Ion Proy Soft