Ingenieria Del Software - Gestion de Proyectos Informaticos

Unidad Didctica: Estimacin de Proyectos Software
ESTIMACIN DE PROYECTOS
SOFTWARE
AUTORA: ANA M MORENO S.- CAPUCHINO
Pag. 1
CONTENIDO DE LA UNIDAD DIDCTICA
TEMA 1: INTRODUCCIN
TEMA 2: ESTIMACIN DE SOFTWARE
TEMA 3: MTRICAS DE SOFTWARE
TEMA 4: TCNICAS DE ESTIMACIN
TEMA 5: MTODO DE ESTIMACIN
DE PUNTOS DE FUNCIN
TEMA : MTODO DE ESTIMACIN COCOMO
!I!LIO"RAF#A
Pag. 2
TEMA 1:
INTRODUCCIN
Pag. 3
Error! Marcador no definido.1.1. M$%&' () *$ ")+,-./ () P%'0)&,'+.
Durante muchos aos el proceso de desarrollo de software ha sido considerado como un arte
dejado a la improvisacin del jefe del proyecto. Los proyectos se dirigan m!s "ajo
consideraciones t#cnicas$ %ue de gestin. Las actividades de estimacin y de planificacin
%ueda"an relegadas a un mero acto protocolario al comien&o del proyecto. 'osteriormente$ el
seguimiento y control se reali&a"an sin un mnimo de rigor$ dada la "aja calidad de la
estimacin y la planificacin reali&ada. Mientras los proyectos han sido de complejidad media
la euforia de la tecnologa ha dominado el mercado. Las desviaciones en costos y tiempo han
sido consideradas como algo natural en un proyecto software. (lgo as como si nadie
estuviera o"ligado a sa"er cu!ndo se terminar! el sistema ni cu!nto costar!.
El continuo incremento de la potencia de los ordenadores ha hecho posi"le conce"ir sistemas
cada ve& m!s complejos. El cere"ro humano tiene solamente una capacidad limitada para
manejar tales sistemas$ y esto puede aplicarse igualmente al desarrollo del software para
tratarlos. (dem!s$ como puede verse en la )igura *.*$ conforme los costes del hardware
disminuyen $ el coste de producir el software tiene un mayor peso dentro del coste del proyecto.
+onforme los costes de desarrollo y mantenimiento del software crecen es necesario predecirlos
y controlarlos. Esto es algo %ue hasta el momento los constructores de software han encontrado
muy difcil de reali&ar.
,tro pro"lema e-istente es %ue no es siempre posi"le evitar errores en los sistemas complejos$ lo
cual puede producir costes elevados$ y perdidas fatales. El software controla actualmente
sistemas m#dicos$ trafico a#reo$ sistemas financieros o sistemas de misiles. Los errores en estos
sistemas pueden implicar serios desastres. Los ejemplos son innumera"les en todos los
dominios de la aplicacin de las .ecnologas de la /nformacin$ como se ha visto en la 0nidad de
/ntroduccin a la /ngeniera del 1oftware.
1eg2n ha crecido la e-periencia en la construccin de los sistemas software$ se han ela"orado
t#cnicas para el desarrollo de las especificaciones y el diseo. Estas disciplinas pueden$ en la
actualidad$ ensearse y aplicarse seg2n reglas muy precisas. 1in em"argo$ se ha puesto de
manifiesto %ue el uso sistem!tico de estas t#cnicas para la especificacin y el diseo de software
no ha resuelto el pro"lema de la produccin del software. En la industria se sigue ha"lando de
3crisis del software34 la cantidad de esfuer&o perdido en el desarrollo de software continua en
situacin similar a hace aos y los productos a menudo son entregados con errores significativos
%ue producen costes y peligros graves.
El hecho es %ue no es suficiente avan&ar a trav#s de las etapas tradicionales del proceso de
construccin de software y esperar un producto satisfactorio al final del mismo. El proceso de
Pag. 4
produccin del software tiene %ue ser gestionado y dirigido de una manera e-tremadamente
rigurosa y cuantitativa. De este modo se podr! verificar %ue el tra"ajo correspondiente a cada
fase se ha reali&ado completamente dentro de los pla&os de tiempo y coste esta"lecidos y de
acuerdo con est!ndares especficos de calidad.
100
0
20
40
60
80
1955
1975
1995
Desarrollo
Software
Mantenimiento
Coste
Ao
F-12%$ 1.1. R)*$&-./ () &'+,)+ H34S3
'or lo tanto$ las claves del #-ito en la gestin del desarrollo de software son5 una adecuada
gestin del proyecto de desarrollo de software y una adecuada gestin del proceso de software.
67u# entendemos por gestin del proyecto de desarrollo de software8
La gestin del proyecto consiste en la utili&acin de las t#cnicas y actividades de gestin
re%ueridas para conseguir un producto software de alta calidad$ de acuerdo con las
necesidades de los usuarios$ dentro de un presupuesto y con una planificacin de
tiempos esta"lecidos previamente.
Pag. 5
67u# es entonces$ la gestin del proceso del software8
La gestin del proceso es el conjunto de t#cnicas y actividades %ue permiten una
adecuada gestin de los procesos personales de los constructores y de los productos
%ue participan en el proyecto.
( lo largo de esta 0nidad y en las 0nidades de 'lanificacin y 1eguimiento profundi&aremos en
los conceptos de la gestin de proyectos. 9eremos las actividades %ue lo componen y cmo
llevarlas a ca"o efica&mente. La gestin del proceso se ver! cuando se e-pli%ue el propio
proceso de desarrollo.
En primer lugar daremos una definicin rigurosa de proyecto.
0n proyecto es una accin en la %ue recursos humanos$ financieros y materiales se
organi&an de una nueva forma para acometer un tra"ajo 2nico. En este tra"ajo$ dadas
unas especificaciones y dentro de unos lmites de costes y tiempo$ se intenta conseguir
un cam"io "eneficioso dirigido por unos o"jetivos cualitativos y cuantitativos.
El aspecto esencial de un proyecto es el ser un tra"ajo 2nico %ue se reali&a con una nueva
organi&acin para producir un cam"io "eneficioso. Estos elementos implican %ue un proyecto
lleva una incertidum"re considera"le y riesgo$ y por lo tanto su #-ito depender! en gran medida
de una adecuada gestin.
1.2. T$%)$+ C%5,-&$+ )/ *$ ")+,-./ () P%'0)&,'+.
El n2mero de tareas identifica"les a reali&ar por un director de proyectos$ dentro del !rea de la
gestin de proyectos e-cede de cien. 1in em"argo$ hay tres %ue son crticas y %ue de"en ser
desarrolladas correctamente si se desea %ue el proyecto termine "ien.
Estas tareas son5
a: Estimacin de duracin$ coste y esfuer&o necesarios para construir el producto.
": 'lanificacin de tareas a reali&ar$ asignacin de personas$ tiempos$ etc. para
construir el producto.
c: 1eguimiento$ durante la reali&acin del tra"ajo$ para asegurar el cumplimiento de lo
planificado en cuanto a costes$ fechas$ etc. En caso de desviaciones del plan$ se
de"en tomar las medidas pertinentes.
Pag. 6
1.2.1. E+,-6$&-./ () P%'0)&,'+
La primera tarea en la gestin de proyectos es la estimacin.
La estimacin se define como el proceso %ue proporciona un valor a un conjunto de varia"les
para la reali&acin de un tra"ajo$ dentro de un rango acepta"le de tolerancia. 'odemos
definirlo tam"i#n como la prediccin de perso nal$ del esfuer&o$ de los costes y de la
planificacin %ue se re%uerir! para reali&ar todas las actividades y construir todos los
productos asociados con el proyecto.
0no de los par!metros crticos de la estimacin es determinar su e-actitud. La estimacin
puede reali&arse a partir de datos histricos o con herramientas. +uriosamente$ en la
actualidad$ est! ocurriendo algo sorprendente y es %ue algunas herramientas actualmente
e-istentes proporcionan una estimacin m!s e-acta %ue la o"tenida por la empresa a partir de
sus datos histricos.
1.2.2. P*$/-7-&$&-./ () P%'0)&,'+
La planificacin de un proyecto se define como el proceso de seleccin de una estrategia para
la produccin de unos productos finales dados$ as como la definicin de las actividades a
reali&ar para conseguir ese o"jetivo$ la concurrencia y solapamiento de dichas actividades.
.am"i#n de"e asignar recursos a las actividades anteriores en funcin del plan esta"lecido.
La estimacin y la planificacin son actividades relacionadas pero difieren en su alcance y
propsito. La estimacin normalmente est! orientada al proyecto en su conjunto$ mientras %ue
la planificacin esta dirigida a los individuos. ,"viamente$ de"e e-istir una fuerte correlacin
entre la estimacin reali&ada y las tareas especficas a reali&ar da a da por el e%uipo de
proyecto. La estimacin la reali&aremos al principio del proyecto$ precisamente para pedir
presupuesto$ sa"er cu!nta gente se necesita$ otros recursos$ etc.$ y la planificacin es la etapa
donde se asigna e-actamente %ui#n hace %u# y en cuanto tiempo. (lgo as como5 6+u!nto
tiempo y dinero necesito para conocer 'ars8$ *; das y <;;.;;; pesetas. Esto es una
estimacin. El primer da voy al aeropuerto a las *; horas$ cojo el avin y llego a 'ars a las
...= es una planificacin.
0na diferencia t#cnica entre las herramientas de planificacin y estimacin es %ue estas
ultimas son normalmente sistemas e-pertos$ construidos a partir de las reglas derivadas de
miles de proyectos. Las herramientas para la planificacin$ en cam"io$ no son sistemas
Pag. 7
e-pertos$ sino herramientas para ser utili&adas por personas e-pertas. La ra&n para esta
diferencia es %ue las herramientas de estimacin est!n "asadas en miles de proyectos y
pueden llegar a alcan&ar una gran e-actitud$ pero el tra"ajo da a da de las personas %ue
participan en el proyecto con sus conocimientos$ planes de vacaciones e interrupciones
re%uieren un director de proyectos e-pertos y casi con ajustes diarios de la planificacin. 1e
puede sacar una conclusin y es %ue las herramientas de planificacin dan los mejores
resultados con los mejores directores. En cam"io$ las herramientas de estimacin pueden
aumentar y mejorar las capacidades de los nuevos jefes de proyecto o de los e-pertos cuando
tienen %ue planificar proyectos en los %ue no e-iste una e-periencia previa.
Las herramientas de planificacin son las m!s utili&adas por los jefes de proyectos.
1.2.3. S)12-6-)/,' () P%'0)&,'+
El seguimiento es la recoleccin de datos y su almacenamiento$ so"re tiempos$ recursos$
costes$ e hitos asociados con un proyecto$ para el an!lisis y estudio de la evolucin real de
dicho proyecto$ comparando el progreso real con el planificado.
Desafortunadamente$ el seguimiento de los proyectos de desarrollo de software no ha sido
todo lo correcto %ue ca"ra esperar.
+omo ya se vio en otra 0nidad$ muchos sistemas son ine-actos y entre el ><? y el @<? de los
costes reales del software no son registrados.
Las mayores omisiones en el seguimiento son de"idos a5
.iempo e-tra de profesionales no registrado.
+oste de viajes y reuniones.
Esfuer&o de los directivos.
Esfuer&o de los usuarios en tareas t#cnicas$ como escritura de manuales$ prue"as o
participacin en revisiones.
1oporte administrativo.
Desarrollos iniciales antes de comen&ar el proyecto.
E-isten muchas m!s$ pero #stos son una muestra de la situacin$ y de la poca e-actitud del
seguimiento.
(s mismo$ adem!s de la omisin de datos$ la descripcin de cuentas utili&adas para acumular
costes no es lo suficientemente detallada como para llevar una conta"ilidad seria del proyecto.
(lgunos costes se acumulan solamente como gasto del proyecto$ y est!n mas pensados para
ser utili&ados por los conta"les$ %ue para servir de ayuda a los jefes de proyectos.
Pag. 8
1.2.4. R)*$&-./ )/,%) *$+ A&,-8-($()+ C*$8) () *$ ")+,-./ () P%'0)&,'+
Los conceptos anteriores pueden dar la falsa impresin de %ue cada uno de los procesos
descritos son independientes$ discretos y de %ue se aplican una sla ve&. El hecho es %ue
#ste no es el caso. +uando tenemos una estimacin inicial so"re el proyecto %ue vamos a
desarrollar$ de"emos de definir una planificacin para el proyecto siempre dentro del marco de
esa estimacin$ es decir$ la salida del proceso de estimacin de"e ser una de las entradas del
proceso de planificacin. 0na ve& reali&ada la planificacin comen&aremos el seguimiento del
proyecto. 'or lo tanto$ las entradas del proceso de seguimiento ser!n la estimacin y
planificacin del proyecto$ adem!s de los datos reales recogidos mientras evoluciona el
proyecto. Durante la reali&acin del proceso de seguimiento se puede producir una
replanificacin si nos apartamos del plan original. 0na fuerte desviacin durante el seguimiento
puede ser la consecuencia$ por ejemplo$ de un cam"io en la naturale&a del proyecto. En ese
caso$ necesitaremos una reestimacin y replanificacin en consecuencia$ como muestra la
)igura *.A.
La gestin del desarrollo del software es inefica& a causa de %ue dicho desarrollo es
e-tremadamente complejo$ disponi#ndose de pocas medidas para guiar y evaluar el proceso. De
esta manera sin una estimacin efica& y e-acta$ la planificacin y el seguimiento eficaces son
pr!cticamente imposi"les de conseguir .
DESARROLLO
ESTIMACION
PLANIFICACION
SEGUIMIENTO
F-12%$ 1.2. R)*$&-./ )/,%) *$+ T$%)$+ () E+,-6$&-./
Pag. 9
P*$/-7-&$&-./ 0 S)12-6-)/,'.
( partir de este momento$ esta 0nidad se centra en el proceso de Estimacin de software.
E-isten otras unidades %ue tratan la 'lanificacin y el 1eguimiento.
Pag. 10
TEMA 2:
ESTIMACIN DE SOFTWARE
Pag. 11
2.1. P%'9*)6:,-&$ ()* P%'&)+' () E+,-6$&-./ ()* S'7,3$%)
Ba en los aos @; se comen& a ha"lar del proceso de estimacin del software. 1in em"argo$ y
desafortunadamente$ el arte y la ciencia de la estimacin est!n hoy en da es su infancia. La
industria del software sigue fuera de control$ con costes y tiempos desmedidos.
'ara ha"lar de las posi"ilidades actuales de la estimacin$ primero de"emos revisar su estado
actual y e-plorar las necesidades de la comunidad de desarrollo de software.
67u# es la estimacin8
9ista desde el punto de vista de un diccionario$ una estimacin es un conjunto apro-imado de
valores para algo %ue ha de ser hecho. En el mundo del desarrollo de software$ Larry 'utnam ha
apuntado %ue la gestin del desarrollo de software considera la estimacin como una actividad
%ue permite o"tener$ principalmente$ respuestas apro-imadas a las siguientes preguntas
6+u!nto costar! 8
6+u!nto tiempo llevar! hacerlo8
La respuesta a estas dos preguntas constituye el %uid del tema %ue a%u se contempla. 1in
em"argo$ y como se puede prever #sta no es tan sencilla.
67u# hace %ue la estimacin sea tan difcil de reali&ar8
Las ra&ones para esta complejidad son las siguientes5
1.Co e-iste un modelo de estimacin universal o una formula %ue pueda ser usada para
todas las organi&aciones. El hecho es %ue se pueden definir unos principios generales$ pero
cada interpretacin es particular y diferente del resto. +ada organi&acin tiene sus propios
recursos$ procedimientos e historia4 y es necesario ajustar los procesos de estimacin a
esos par!metros 2nicos. (dem!s$ a medida %ue estos par!metros cam"ien$ de"en
cam"iar los procesos de estimacin.
2.Day muchas personas implicadas en los proyecto %ue precisan de estimaciones. La alta
direccin de la empresa necesita las estimaciones para tomar decisiones de negocio$ so"re
la via"ilidad del proyecto y su continuidad a lo largo del desarrollo. La direccin del proyecto
necesita las estimaciones para hacer sugerencias a la alta direccin$ para o"tener los
resultados necesarios para el desarrollo del proyecto$ y para hacer una planificacin
detallada y controlar el proyecto. +ada recurso del proyecto tam"i#n necesita estimaciones
para planificar y controlar su propio tra"ajo.
Pag. 12
3.La utilidad de una estimacin tam"i#n depender! de la etapa de desarrollo en la %ue nos
encontremos. (l comien&o de un proyecto$ normalmente slo se necesitan estimaciones de
coste y duracin apro-imadas. ( medida %ue el proyecto madura las estimaciones %ue se
necesitan ser!n m!s e-actas. +on lo %ue una estimacin 2til al comien&o del proyecto
puede no serlo m!s tarde.
4.La estimacin $ a menudo$ se hace superficialmente$ sin apreciar el esfuer&o re%uerido para
hacer un tra"ajo. (dem!s$ tam"i#n se suele dar el caso de %ue la estimacin sea necesaria
antes de o"tener las especificaciones de re%uisitos del sistema. 'or esta ra&n$ una
situacin tpica es %ue se presiona a los estimadores para %ue se apresuren en escri"ir una
estimacin anticipada del sistema %ue no comprenden a2n.
5.Las estimaciones claras$ completas y precisas son difciles de formular$ especialmente al
inicio del proyecto. Los cam"ios$ adaptaciones y ampliaciones son m!s la regla %ue la
e-cepcin5 como consecuencia de ello$ de"en adaptarse tam"i#n las planificaciones y los
o"jetivos.
6.Las caractersticas del software y de su desarrollo hacen difcil la estimacin . 'or ejemplo$
el nivel de a"straccin$ la complejidad$ el grado de medicin del producto y del proceso$ los
aspectos innovadores$...
7.La rapide& con la %ue cam"ia la tecnologa de la informacin y las metodologas de
desarrollo de software son pro"lemas para la esta"ili&acin del proceso de estimacin. 'or
ejemplo$ son difciles de predecir la influencia de nuevos "ancos de prue"as$ lenguajes de
cuarta y %uinta generacin$ estrategias de prototipado$ y de t#cnicas y herramientas
novedosas en general.
8.0n estimador puede no tener mucha e-periencia en estimar desarrollos$ especialmente de
proyectos largos. 6+u!ntos proyectos largos puede alguien dirigir en$ por ejemplo$ *;
aos8
9.E-iste una tendencia aparente de los desarrolladores hacia la su"estimacin. 0n estimador
suele elegir una porcin de software de"era tomar para luego e-trapolarlo al resto del
sistema$ normalmente se ignoran los aspectos no lineales del desarrollo de software$ por
ejemplo$ la coordinacin y la gestin.
10.El estimador estima el tiempo %ue le llevara ejecutar personalmente una tarea$ ignorando
el hecho de %ue$ a menudo$ una parte del tra"ajo la reali&a personal menos e-perimentado$
con un ndice de productividad menor.
Pag. 13
11.E-isten malas interpretaciones en las relaciones lineales entre la capacidad re%uerida por
unidad de tiempo y el tiempo disponi"le. Esto significa %ue el software desarrollado por A<
personas en dos aos podr! ser llevado a ca"o por <; personas en un ao. Esta
interpretacin es errnea. +omo ya se coment en otra 0nidad una mujer puede dar a luz
un nio a lo largo de 9 meses, pero 9 mujeres no dan a luz un nio en un mes. (adir
personal a un proyecto retrasado no tiene por %u# disminuir el retraso.
12.El estimador tiende a reducir en alg2n grado las estimaciones para hacer m!s acepta"le
la oferta.
13./nfluyen un gran n2mero de factores en el esfuer&o y duracin de un desarrollo de
software. Estos factores se llaman Edrivers de coste= o disparadores de coste. Ejemplos de
estos disparadores son el tamao y complejidad del software$ el compromiso y participacin
del usuario$ la e-periencia del e%uipo de desarrollo. En general estos disparadores de coste
son difciles de determinar.
Es importante profundi&ar m!s en el tema de los disparadores de coste. 'ara mostrar su
importancia$ estudiaremos a continuacin algunos de ellos repartidos en cinco categoras$ como
se muestra en la .a"la A.*.
el producto software %ue se tiene %ue desarrollar5 ;U
el significado de la produccin5 CON ;U
el personal de produccin5 ;UIN
la organi&acin de produccin5 CMO
usuarioForgani&acin del usuario5 PARA ;UIN
70G
producto
+,C 70G
significado
70/GC
personal
+HM,
proyecto
'(I( 70/GC
usuario
.amao del
software
+alidad re%uerida
9olatilidad de
re%uisitos
Iestricciones
del ordenador
J tiempo de
ejecucin
J tiempo de
respuesta
J capacidad de
memoria
+alidad del
personal
E-periencia del
personal
+alidad de gestin
Ie%uisitos de la
duracin del
proyecto
J dilatacin
J compresin
Kases para el
control del
'articipacin
C2mero de
usuarios
Esta"ilidad de la
organi&acin del
usuario$
Pag. 14
+omplejidad del
software
Civel de utili&acin
+antidad de
documentacin
.ipo de aplicacin
0suarios de
herramientas
0so de t#cnicas
modernas de
programacin
J ocultacin de
informacin
J e%uipo de
programacin
principal
J programac.
estructurada
J diseo topJdown
Disponi"ilidad
para el proyecto
proyecto
J matri& de
organi&aJcin
J organi&aJcin del
proyecto
J prototipado
J incremental
J desarrollo lineal
procedimienJtos$
formas de tra"ajo
E-periencia del
usuario con la
inform!tica$ nivel
de conocimientos
inform!ticos
T$9*$ 2.1. D-+<$%$('%)+ () &'+,)
En la .a"la anterior podemos ver diversos tipos de disparadores$ todos ellos influir!n en la
estimacin %ue vallamos a reali&ar$ lo realmente difcil es determinar cu!les son los disparadores
de coste m!s importantes en cada situacin especfica$ cu!les son sus valores y cmo influyen
en el esfuer&o y la duracin de cada proyecto. 'ara resolver estas cuestiones conviene tener en
cuenta varios aspectos5
Definicin
Day una falta de definiciones claras y aceptadas de los disparadores$ tales
como tamao$ calidad$ complejidad$ e-periencia$... 'or ejemplo$ cu!ndo se dice
%ue un desarrollador es e-perimentado y cu!ndo no.
+uantificacin5
La mayora de los disparadores de coste son difciles de cuantificar. ( menudo$
se utili&an medidas tales como5 mucho$ moderado$ poco$...
,"jetividad5
La o"jetividad es un factor de riesgo potencial. Lo %ue puede ser complejo para
el desarrollador ($ puede no serlo para el K.
+orrelacin5
Es difcil considerar un driver independiente de los dem!s. 0n cam"io en el
Pag. 15
driver ($ puede tener consecuencias en los valores de otros disparadores. Esta
es una dificultad tremenda desde el punto de vista de la medi"ilidad.
Ielacin entre disparador y esfuer&o5
'ara la estimacin es importante poder predecir la relacin entre$ por ejemplo$
el tamao del software y el esfuer&o re%uerido$ el nivel de calidad especificado y
el esfuer&o re%uerido$ etc.
+ali"racin5
Es imposi"le ha"lar de los disparadores de coste m!s importantes de forma
aislada. 0na situacin difiere mucho de otra.
.odos estos aspectos pueden proporcionar una idea de la complejidad del proceso de
estimacin. 1in em"argo$ tam"i#n se han destacado las consecuencias negativas de la falta de
este proceso$ y la importancia de su aplicacin.
2.2 R)=2-+-,'+ =2) ()9) C26<*-% 2/ !2)/ E+,-6$('%
67ui#n de"e reali&ar el proceso de estimacin de un proyecto software8
El estimador de"e se un profesional$ %ue no tenga ning2n inter#s$ directo o indirecto$ en los
resultados del proceso de estimacin y %ue est! 2nicamente guiado por su profesionalidad.
El principal o"jetivo de un estimador es o"tener unas estimaciones de calidad$ las cuales no
tienen siempre por %u# coincidir con las e-pectativas de la direccin en t#rminos de coste y
tiempo.

0n "uen estimador de"era cumplir los siguientes re%uisitos5
1.De"e poseer una importante formacin y e-periencia profesional %ue le ayuden a entender
y solucionar los pro"lemas de la gestin de proyectos.
2.De"e tener una posicin en la organi&acin %ue le permita adoptar un juicio independiente.
3.De"e "asarse en un m#todo %ue pueda ser e-plicado$ cuestionado$ discutido y auditado
por otros e-pertos.
Pag. 16
4.1iempre %ue use una herramienta de estimacin$ #sta de"e ajustarse a su propsito de
estimacin y de"e soportar el m#todo. La herramienta tam"i#n de"e estar documentada y
controlada.
5.De"e ser capa& de descri"ir su e-periencia en cada estimacin. Es decir$ descri"ir los
pro"lemas a los %ue ha tenido %ue enfrentarse$ las soluciones$ etc.
6.De"e ser capa& de documentar su estimacin$ incluyendo los resultados o"tenidos y
cual%uier informacin necesaria para hacer el proceso de estimacin repeti"le y verificarle.
2.3. M$%&' T)6<'%$* () *$ E+,-6$&-./ () P%'0)&,'+
6+u!ndo se de"e reali&ar la estimacin de un proyecto software8
( continuacin veremos en %u# momento del desarrollo de un proyecto se ha de reali&ar el
proceso de estimacin.
La estimacin$ como ya hemos anticipado$ es un proceso continuo. ( medida %ue el proyecto
avan&a$ m!s se conoce de #l$ y por lo tanto m!s par!metros est!n disponi"les para introducir en
un modelo de estimacin.
El grado de informacin so"re los par!metros del sistema sigue una curva en forma de 3s3 tpica$
como se muestra en la )igura A.*.
La estimacin continua nos permite el uso de un 2nico modelo coherente %ue pueda capturar y
utili&ar la informacin so"re el proyecto a medida %ue este se cono&ca.
M!s precisamente$ el proceso de estimacin comien&a usando unas pocas varia"les claves para
proveer las 3macroJcaractersticas3 de un proyecto$ y evoluciona incorporando informacin de
m!s "ajo nivel para producir las 3microJcaractersticas3 del proyecto.
La naturale&a del proceso de estimacin cam"ia a medida %ue el programa progresa.
1upongamos %ue desarrollamos un proyecto con un ciclo de vida tradicional. (l principio$ en la
concepcin del sistema$ slo necesitamos estimaciones a grosso modo para determinar el
tamao del proyecto y estudiar su via"ilidad. Es interesante conocer el esfuer&o total del
proyecto$ su duracin$ riesgos$ necesidades de personal$ etc. ( esta primera estimacin se le
denomina 6$&%'-)+,-6$&-./ de un proyecto. +omo entrada para esta estimacin se necesitan
algunos par!metros descriptivos y gen#ricos so"re el proyecto.
Pag. 17
100
1
Concepcin Instalacin
Informacin
Vida del
producto
Software
F-12%$ 2.1. "%$(' () I/7'%6$&-./ +'9%) 2/ P%'0)&,'
0na ve& %ue los re%uisitos han sido definidos$ se necesita una estimacin m!s detallada para la
siguiente fase$ diseo del producto$ con el fin de utili&arla para confeccionar una planificacin para
dicha fase. .am"i#n se necesita una estimacin a m!s alto nivel para el resto del proyecto. En
este momento$ los par!metros descriptivos y gen#ricos %ue se emplean para hacer la primera
estimacin se conocen m!s e-actamente$ y tam"i#n se dispone de informacin adicional so"re
los recursos %ue intervendr!n en el desarrollo$ como por ejemplo la e-periencia de los
desarrolladores.>E%%'%? M$%&$('% /' ()7-/-('.
Despu#s de %ue el diseo del producto ha finali&ado$ puede ser incluso %ue la "ase de la
estimacin haya cam"iado$ es decir$ se puede pasar de utili&ar par!metros descriptivos a
emplear otros m!s detallados como el n2mero de mdulos esperados$ o el n2mero de lneas de
cdigo. .am"i#n podran conocerse consideraciones tecnolgicas a un nivel de detalle ra&ona"le.
Pag. 18
(l final de la fase de diseo detallado$ la informacin so"re el n2mero de mdulos y lneas de
cdigo$ por ejemplo$ puede ser refinada para la mejora de las estimaciones de las restantes
fases.
+uando la codificacin$ las prue"as y la instalacin han finali&ado podemos o"tener datos so"re
el rendimiento y la calidad del sistema %ue$ cuantificados adecuadamente$ pueden constituir la
"ase para la estimacin de defectos. Estos datos$ junto con el conocimiento so"re el entorno del
desarrollo$ permitir!n reali&ar estimaciones para la fase de mantenimiento.
La )igura A.A muestra la e-actitud con la %ue las estimaciones software se pueden hacer$ en
funcin de las fases del ciclo de vida tradicional$ o el grado de conocimiento %ue tenemos so"re
lo %ue pretende hacer el software.
Vi abi l i dad Pl ani fi caci n
y requi sitos
Di seo
producto
Di seo
detal l ado
Desarrol l o y
pruebas
Iniciacin
Especificacin
requisitos
Especificacin
de diseo
Especificacin
de diseo detallado
Software
aceptado
x
4x
0.5x
0.25x
2x
1.5x
1.25x
0.67x
0.8x
tipos de personas
ydatos
tipo de consultas
carga de datos, tpo. de respuesta
esttructuras de datos internas
algoritmos detallados
entendimeitno de
especificaciones
Fasess del
Software
Exactitud
F-12%$ 2.2. E@$&,-,2( () *$+ E+,-6$&-'/)+
$ *' *$%1' ()* D)+$%%'**'.
Pag. 19
+omo puede verse en la )igura A.A$ cuando comen&amos a estudiar las distintas posi"ilidades
para desarrollar un nuevo sistema$ las estimaciones pueden oscilar en un rango de cuatro veces
por arri"a o por a"ajo. Este rango proviene de la gran incertidum"re %ue se tiene en este
momento so"re la naturale&a real del producto. (s$ por ejemplo$ no se sa"e %u# tipo de
personas Lgestores$ consultores$ analistas$...: o %u# tipos de datos Ldigitales o analgicos$
num#ricos o te-to$...: soportar!n el sistema.
Las incgnitas anteriores se conocen cuando finali&a la fase de via"ilidad y se decide un
procedimiento de operacin. En este momento$ el rango de nuestra estimacin disminuye en dos
en cada direccin. Este rango es ra&ona"le por%ue todava no se tiene informacin so"re los
tipos de consulta %ue soportar! el sistema$ las funciones concretas$ etc. Estos elementos ser!n
conocidos en el momento de reali&ar la especificacin de re%uisitos$ en el %ue la estimacin
software estar! en un rango de *$< en cada direccin.
En el momento en %ue hayamos completado y validado la fase de diseo del producto$
tendremos informacin so"re la estructura de datos interna del producto software$ so"re las
t#cnicas para el manejo de "uffers$ etc. En este momento la estimacin software tendr! un rango
de e-actitud del *$A<. E-isten todava incgnitas$ como los algoritmos %ue se usar!n para la
planificacin de tareas$ el manejo de errores o los procedimientos de parada del sistema. Estas
ser!n conocidas al final de la fase de diseo detallado$ pero e-istir! todava una incertidum"re del
*;? "asada en la e-actitud con la %ue los programadores entiendan las especificaciones %ue
tienen %ue codificar.
'ara otros ciclos de vida como$ prototipado o desarrollos en tiempo real$ el proceso de estimacin
sera muy similar$ y en todos ellos a medida %ue el proyecto progresa$ la "ase de la estimacin y
las salidas esperadas de este proceso cam"iar!n.
2.4. S$*-($+ ()* P%'&)+' () E+,-6$&-./
En esta seccin intentaremos dar respuesta a la siguiente pregunta.
67u# es lo %ue de"emos estimar8
+uando se ha"l de la definicin de estimacin$ se vieron dos preguntas a las %ue este proceso
de"a dar respuesta. Estas preguntas eran5
6+u!nto costar!8
6+u!nto tiempo llevar! hacerlo8
Pag. 20
Esta informacin constituye la informacin "!sica de todo proceso de estimacin. Los distintos
m#todos e-istentes para reali&ar este proceso proporcionan informacin adicional para dar
respuestas$ en funcin del m#todo$ a algunas de las siguientes preguntas5
6+u!nta gente se necesita8
6De %u# perfiles8
6+u!les son los riesgos8
6+mo afectan las restricciones impuestas a las estimaciones8
6+u!nto esfuer&o se necesita para reali&ar cada fase del ciclo de vida8
6+mo impacta este proceso en el resto de los proyectos de
la empresa8
6+u!l ser! el esfuer&o para mantener este proyecto8
6+u!l ser! el tamao del sistema8Llneas de cdigo:
6+u!ntos defectos tendr! el producto8
6+u!nta documentacin ser! generada8
6+u!l ser! el esfuer&o para confeccionar dicha documentacin8
1e podra crear una lista compuesta por todas estas preguntas$ para utili&arla como "ase para la
solucin al pro"lema de 67u# estimar8. (s$ se o"servara %ue e-isten muchos conceptos en la
mente de los estimadores. 1in em"argo$ dada la r!pida evolucin de los m#todos de desarrollo
de sistemas y la creciente diversificacin de alternativas hardware$ es correcto suponer %ue esta
lista aumenta constantemente.
.odos estos par!metros %ue se pretenden o"tener$ son en realidad medidas so"re el producto
software$ es decir m#tricas$ de las %ue ha"laremos en el tema siguiente.
Pag. 21
TEMA 3:
MTRICAS DE SOFTWARE
Pag. 22
3.1. D)7-/-&-./ () MA,%-&$
'odemos definir las M#tricas de 1oftware o Medidas de 1oftware como5
La aplicacin continua de t#cnicas "asadas en las medidas de los
procesos de desarrollo del software y sus productos$ para producir una
informacin de gestin significativa y a tiempo. Esta informacin se
utili&ar! para mejorar esos procesos y los productos %ue se o"tienen de
ellos.
+omo se puede o"servar$ esta definicin cu"re infinidad de aspectos relacionados con el
desarrollo de software. Las m#tricas de software implican medir5 medir involucra n2meros4 el
uso de n2meros para hacer cosas mejor. Las m#tricas de software pretenden mejorar los
procesos de desarrollo del software y mejorar$ por tanto$ todos los aspectos de la gestin de
a%uellos procesos. Estas medidas son aplica"les a todo el ciclo de vida del desarrollo$ desde
la iniciacin$ cuando de"emos estimar los costes$ al seguimiento y control de la fia"ilidad de
los productos finales$ y a la forma en %ue los productos cam"ian a trav#s del tiempo de"ido a
la aplicacin de mejoras. Las m#tricas incluyen el uso de t#cnicas por parte de ingenieros de
software y programadores para detectar y corregir anticipadamente los errores de los distintos
componentes de los productos$ antes de llegar a la codificacin. (dem!s las m#tricas
controlan el progreso del proyecto$ de tal manera %ue lo %ue pueda ocurrir seis meses m!s
tarde se pueda identificar tan pronto como sea posi"le.
Esencialmente$ las M#tricas de 1oftware se aplican al producto software y a los procesos
mediante los %ue se desarrolla. El producto software de"era ser visto como un o"jeto
a"stracto %ue evoluciona desde una definicin inicial de necesidades hasta un sistema
terminado$ %ue incluyen codificacin$ fuente y o"jetos$ as como los distintos documentos
producidos durante el desarrollo. ( menudo$ estas medidas de los procesos de desarrollo y de
los productos software son estudiadas para su utili&acin en la monitori&acin de dichos
procesos.
'or tanto$ las medidas del software y los modelos de medida son entonces 2tiles para estimar
y pre decir costes y para medir la productividad y la calidad del producto .
3.2. A%)$+ () A<*-&$&-./
6'ara %u# podemos utili&ar las m#tricas8
Day diferentes formas en las %ue pueden ser utili&adas las M#tricas de 1oftware$ algunas de
Pag. 23
las cuales constituyen una especialidad por si solas.
La m!s consolidada de las !reas en el estudio de las m#tricas es la correspondiente a las
t#cnicas de estimacin de costes y tamao. E-isten distintos pa%uetes en el mercado %ue
proporcionan estimacin del tamao del software a desarrollar$ coste de desarrollo del sistema
y duracin del proyecto de desarrollo o mejora del software.
Estos pa%uetes est!n "asado en modelos de estimacin y el m!s conocido es el +,+,M,$
desarrollado por Karry Koehm en *MN* aun%ue
e-isten otros como son E1./M(+1$ 1,).+,1.$ 1'7I o +,'M,$ %ue se e-plicar!n
posteriormente.
E-iste una gran cantidad de investigacin so"re este !rea en EE.00.$ Europa y otros lugares.
Day organi&aciones especialmente interesadas en la implantacin de m#tricas en el desarrollo
de software$ por ejemplo el Departamento de Defensa de EE.00.
El control de proyectos de desarrollo de software a trav#s de medidas es un !rea %ue esta
generando un gran inter#s tanto en Europa como en EE.00. Este es un tema %ue ha
alcan&ado un inter#s relevante con el incremento de contratos a precio fijo para desarrollar un
producto software y la utili&acin de cl!usulas de penali&acin en los mismos en caso de
retrasos$ so"recostos$ etc..
La prediccin de los niveles de calidad del software$ a menudo en t#rminos de fia"ilidad$ es
otro !rea en %ue las M#tricas de 1oftware tienen un importante papel %ue jugar.
El uso de las M#tricas de 1oftware en proporcionar una verificacin cuantitativa del diseo del
software es otro !rea "ien definida. Estas m#tricas no se van a estudiar en esta 0nidad sino
en la 0nidad de Diseo.
Iecientemente se ha estudiado el efecto de los factores del entorno en la eficacia de los
procesos de desarrollo. Esta opcin no esta a"ierta para todas las organi&aciones$ pero e-iste
una gran preocupacin so"re como incrementar la productividad de los procesos de
desarrollo$ introduciendo cam"ios en el entorno en el cual a%uellos tienen lugar. Las medidas
pueden ser utili&adas para identificar donde de"eran concentrarse los cam"ios.
La utili&acin de las M#tricas para comparar unas organi&a ciones con otras es una !rea de
aplicacin muy importante. +1+J/nde- en Europa y el 1oftware Engineering /nstitute en
EE.00. ofrecen este tipo de servicios a la industria y muchas organi&aciones los utili&an. 0n
resultado de esta aplicacin es %ue se puede identificar %u# se est! haciendo mal y %ui#n lo
esta haciendo "ien y aprender de esas empresas.
Pag. 24
)inalmente$ el uso m!s com2n de las medidas de software es la provisin de informacin de
gestinB %ue incluye datos acerca de la productividad$ calidad y eficacia de los procesos. El
valor de esta informacin est! en anali&ar los datos de las tendencias$ da a da. 6Est!
mejorando o empeorando la calidad de un e%uipo de desarrollo8. 1i es as$ 6por %u# ocurre8
6%ue puede hacer la direccin para mejorar la situacin8.
Este campo ofrece pues importantes aspectos para mejorar la calidad de los procesos de
desarrollo de software.
3.3. C$%$&,)%5+,-&$+ () *$+ MA,%-&$+ () S'7,3$%)
La calidad de las medidas de"eran facilitar el desarrollo de modelos %ue sean capaces de
predecir el comportamiento de determinados par!metros %ue afectan al desarrollo de
productos o de procesos.
0na medida ideal de"era ser5
,"jetiva .
1encilla $ defini"le con precisin para %ue pueda ser evaluada.
)!cilmente o"teni"le La un coste ra&ona"le:.
9alida $ la m#trica de"era medir e-actamente lo %ue se %uiere medir y no otra
cosa.
Io"usta . De"era de ser relativamente insensi"le a cam"ios poco significativos en
el proceso o en el producto.
(dem!s$ para una mejor utili&acin de estas medidas$ a la hora de reali&ar estudios analticos
o an!lisis estadsticos de"eran de tener unos valores %ue se ajusten a una cierta escala de
medida.
3.4. C*$+-7-&$&-./ () *$+ MA,%-&$+ ()* S'7,3$%)
Las M#tricas de 1oftware se pueden clasificar$ de una manera general$ en M#tricas de
producto y M#tricas de proceso.
Las M#tricas de producto son medidas del producto software durante cual%uier fase de su
desarrollo$ desde los re%uisitos hasta la instalacin.
Pag. 25
Las M#tricas de producto pueden medir la complejidad del diseo$ el tamao del producto final
Lfuente u o"jeto: o el n2mero de p!ginas de documentacin producida.
Las M#tricas de proceso$ son medidas del proceso de desarrollo del software tales como
tiempo de desarrollo total$ esfuer&o en dasFhom"re o mesesFhom"re de desarrollo del
producto$ tipo de metodologa utili&ada o nivel medio de e-periencia de los programadores.
(dem!s de esta clasificacin de las m#tricas$ se pueden categori&ar de otras formas. 'or
ejemplo$ por la diferencia de las propiedades o"jetivas y su"jetivas.
De una manera general las medidas o"jetivas de"eran tener siempre un valor igual para una
medida dada$ cuando es medida por dos o m!s o"servadores cualificados. 'ara medidas
su"jetivas$ aun o"servadores cualificados pueden incluir diferentes valores para una medida
dada$ ya %ue sus juicios personales est!n involucrados en la o"tencin del valor medido.
(s por ejemplo$ el tamao del producto medido en lneas de cdigo LL,+: es una medida
o"jetiva del producto$ ya %ue cual%uier o"servador %ue tra"ajara con la misma definicin de
L,+$ de"era o"tener el mismo valor para un programa dado.
0n ejemplo de medidas su"jetivas del producto es la clasificacin del software seg2n el
modelo de estimacin de costes de Koehm L+,+,M,: en org!nico$ semili"re o rgido.
'ara medidas de procesos$ el tiempo de desarrollo es una medida o"jetiva y el nivel de
e-periencia de un programador es una medida su"jetiva.
,tra forma de clasificar las m#tricas puede ser en m#tricas primitivas o m#tricas calculadas.
Las m#tricas primitivas son a%uellas %ue pueden ser o"servadas directamente$ tales como las
lneas de cdigo$ n2mero de defectos o"servados en una prue"a unitaria o el tiempo de
desarrollo total de un proyecto. M#tricas calculadas son a%uellas %ue no pueden ser
o"servadas directamente sino %ue se o"tienen a partir de otras.
Ejemplos de este tipo de medidas pueden ser las utili&adas en la e-presin de la productividad
como lneas de cdigo producidas por una persona durante un mes o para la calidad del
producto$ el n2mero e errores por cada mil lneas de cdigo. Las m#tricas calculadas son
com"inaciones de otros valores de medidas y son valiosas para comprender o evaluar los
procesos del software.
3.5. MA,%-&$+ () P%'(2&,'+
Pag. 26
Muchos de los tra"ajos iniciales reali&ados so"re las m#tricas de producto est!n relacionados
con las caractersticas del cdigo fuente. +onforme se ha ido ganando e-periencia con las
m#tricas y los modelos se ha puesto de manifiesto %ue la informacin disponi"le durante los
primeros momentos del ciclo de desarrollo puede ser de gran valor para controlar el proceso y
los resultados.
9amos a anali&ar$ de todos los tipos de medidas utili&adas en la medicin del producto
software$ 2nicamente a%uellas %ue nos interesen para reali&ar el proceso de estimacin del
software$ %ue ser!n las m#tricas del tamao$ y en cierto grado las de calidad.
3.5.1 MA,%-&$+ ()* T$6$C'
E-iste un cierto n2mero de m#tricas %ue intentan cuantificar el tamao del software. La
m#trica m!s utili&ada$ lneas de cdigo$ tiene el inconveniente o"vio de %ue sus valores no
pueden ser medidos hasta %ue el proceso de codificacin ha finali&ado. Los 'untos de
)uncin$ y los Kang de DeMarco tienen la ventaja de ser medi"les durante los primeros pasos
del desarrollo.
El estado actual en el estudio de las medidas del tamao es5
E-iste un cierto consenso en cuanto a las medidas de la longitud$ pero no en cuanto a las
medidas de las especificaciones o diseo.
E-isten algunos tra"ajos de medicin de las funcionalidades de las especificaciones L%ue
se aplican igualmente al diseo y a los programas:
E-isten muy pocos tra"ajos en cuanto a la medida de la complejidad del pro"lema a
resolver. Ctese %ue este concepto es distinto %ue el de complejidad computacional$ por
tanto el tra"ajo hecho en ese !rea no sirve.
( continuacin$ vamos a anali&ar las medidas m!s utili&adas en la determinacin del tamao
del software.
$D L5/)$+ () C.(-1': La medida m!s utili&ada de la longitud del cdigo fuente de un
programa es el C2mero de Lneas de +digo LLines of +ode en ingles$ a"reviado L,+:. 1in
em"argo$ esta m#trica puede calcularse de muchas maneras. Estas diferencias afectan al
tratamiento de las lneas en "lanco y las lneas de comentarios$ las sentencias no ejecuta"les$
las instrucciones m2ltiples por lnea y las m2ltiples lneas por instruccin. (dem!s$ de"eran
contarse las lneas reusa"les de cdigo.
Pag. 27
La definicin m!s com2n es la siguiente5
0na lnea de cdigo es cual%uier lnea de un te-to de un programa %ue no
es un comentario o lnea en "lanco$ sin tener en cuenta el n2mero de
instrucciones o parte de instrucciones en la lnea.
Esta definicin incluye todas las lneas %ue contienen ca"eceras de programas$
declaraciones e instrucciones ejecuta"les y no ejecuta"les. Esta medida se suele
representar por C+L,+ LCo +omentary Lines of +ode:.
1in em"argo$ en algunos casos$ por ejemplo cuando deseamos conocer %u# capacidad de
almacenamiento %ue necesitamos para el cdigo fuente o cu!ntas p!ginas vamos a imprimir$
esta medida de"e incluir los comentarios.
+omo puede verse no es una medida %ue refleje la longitud real de un programa. 1u
justificacin est! en el uso %ue se ha hecho de ella en ciertos modelos para determinar el
esfuer&o desde el punto de vista de evaluar la productividad. 1in em"argo$ si %ueremos
conocer la longitud real del programa esta seria5
L,+ O C+L,+ P +L,+
donde +L,+ L+omentary Lines of +odeL es el n2mero de lneas de comentarios.
0na medida indirecta de la densidad de comentarios seria5
+L,+ F L,+
En general$ es interesante o"tener am"as medidas LC+L,+ B L,+: ya %ue e-presan
diferentes conceptos.
+uando se intenta utili&ar esta medida Llneas de cdigo: en t#rminos de productividad surgen
dos pro"lemas5
a: Co se tiene en cuenta el concepto de reutili&acin.
": Co se tiene en cuenta el concepto de costes fijos ni tareas %ue se desarrollan
%ue no producen instrucciones.
'or ello$ no de"e ser utili&ada esta medida directamente en la estimacin de esfuer&o o
productividad.
Pag. 28
+uando se est# "uscando la nocin pura de longitud e-isten dos alternativas acepta"les si se
%uiere utili&ar "ajo el concepto de ratio5
1.Medir la longitud en t#rminos de n2mero de "ytes de almacenamiento re%uerido para
contener el te-to del programa.
2.Medir la longitud en t#rminos de n2mero de caracteres en el te-to del programa. L+D(I$ del
ingl#s +haracter:
1i se conoce el n2mero medio de caracteres por lnea de te-to$ CL4 el n2mero de lneas sera5
L,+ O +D(IFCL
9D E+<)&-7-&$&-'/)+ () (-+)C': La definicin de medidas an!logas a la de longitud para las
especificaciones y los documentos de diseo no es f!cil. (l comien&o del ciclo de vida$ tales
documentos consisten en una infinidad de te-to$ grafos$ diagramas matem!ticos y sm"olos.
La naturale&a de a%uellos depender! en particular del estilo$ el m#todo o la notacin utili&ada.
0nas especificaciones o un diseo$ est!n compuestos por te-tos o diagramas$ los cuales
parecen inmedi"les con relacin a la longitud.
0na medida %ue se ha utili&ado para permitir las comparaciones es la del C2mero de '!ginas.
1in em"argo$ la unidad p!gina no puede ser formalmente definida si se desea incluir te-tos y
diagramas.
1i un documento de especificaciones o de diseo est! compuesto de te-tos y diagramas
donde estos 2ltimos tienen una sinta-is uniforme$ entonces se podra representar la longitud
del te-to y la de los diagramas. .am"i#n se pueden utili&ar o"jetos o elementos atmicos
representativos para los distintos tipos de diagramas y sm"olos.
(s$ DeMarco identifica en la fase de especificaciones tres vistas del sistema con relacin a
cuatro tipos de diagramas y seis elementos "!sicos5
9isin Diagrama Elemento K!sico
)uncional Diagrama de )lujo de Datos Kur"uja
Diccionario de Datos Dato elemental
Datos Diagrama EFI ,"jetos y relaciones
Estado Diagrama de .ransicin Estados y
Pag. 29
de estado transiciones
1in em"argo$ no e-isten medidas de longitud relativas a dichas funciones primitivas. 'or tanto$
puede decirse %ue$ hoy por hoy$ no e-iste una m#trica para comparar especificaciones ni
diseos.
&D P%)(-&&-./ () *$ *'/1-,2(.
E-isten una serie de modelos %ue veremos mas adelante para la prediccin del coste$ %ue
dependen de la ha"ilidad para predecir la longitud LCL,+: con e-actitud en la fase de
definicin de especificaciones del sistema a implantar.
0n modo intuitivo de predecir la longitud es o"teniendo una relacin entre la longitud de los
distintos productos o"tenidos durante el ciclo de vida. En particular$ una prediccin de longitud$
se puede o"tener considerando la relacin ratio de e-pansin entre la longitud de las
especificaciones o del diseo y la longitud del cdigo en proyectos similares de los %ue se
mantienen datos.
Da ha"ido algunos intentos para esta"lecer relaciones empricas entre la longitud del cdigo
de programas y la longitud de la documentacin.
(D F2/&-'/$*-($(.
El concepto de funcionalidad de un producto se origina a partir de una nocin intuitiva de la
cantidad de funcio nes %ue proporciona .
Da ha"ido dos intentos serios para medir la funcionalidad de un producto software. 0no de
ellos se de"e a (l"recht y corresponde a los 'untos de )uncin L)'($ del ingl#s )unction
'oint (nalysis:: y otro de"ido a DeMarco$ los Kang$ %ue no ha tenido una gran difusin.
El o"jetivo m!s importante es identificar una medida del tamao del software %ue pueda ser la
varia"le predominante en los sistemas de prediccin de costes y esfuer&o$ as como en la
evaluacin de la productividad. Este es un o"jetivo encomia"le$ ya %ue una medida de la
funcionalidad sera claramente preferi"le a la medida del tamao e-clusi vamente de la
longitud. En am"os casos$ los productos cuya funcionalidad est! siendo medida son
documentos de especificacin$ pero %ue podan aplicarse posteriormente a otros productos
del ciclo de vida. La funcionalidad$ a pesar de los pro"lemas e-istentes$ es un atri"uto muy
importante del producto y es la mejor apro-imacin e-istente hasta la fecha.
3.5.2. MA,%-&$+ () C$*-($(
Pag. 30
1e puede generar una larga lista de caractersticas de la calidad del software5 correccin$
eficacia$ porta"ilidad$ manteni"ilidad$ fia"ilidad$ etc.
Desafortunadamente$ las caractersticas a veces se solapan y entran en conflicto unas con
otras. 'or ejemplo$ incrementar la porta"ilidad$ %ue es muy desea"le$ puede dar lugar a una
eficacia menor.
(un%ue se han reali&ado una gran cantidad de tra"ajos en este !rea$ presenta una gran
variedad en los caminos seguidos frente a otras !reas de investigacin de las m#tricas$ tales
como el tamao de software o la complejidad$ cuyo estudio ha sido m!s uniforme.
Dan tenido considera"le atencin tres !reas5
C'%%)&&-./ () *'+ <%'1%$6$+ $ medida como el n2mero de defectos.
F-$9-*-($( ()* +'7,3$%) $ calculada a partir del dato anterior.
M$/,)/-9-*-($( ()* +'7,3$%) $ %ue se mide a partir otro conjunto de m#tricas$ incluidas
las de complejidad.
La calidad del software es una caracterstica %ue$ tericamente al menos$ puede ser medida
en cada fase del ciclo de desarrollo del software.
Estas m#tricas de calidad se ver!n a lo largo del curso$ en las 0nidades de +alidad$
9alidacin$ etc.
3.. MA,%-&$+ () P%'&)+'+
Estas m#tricas eval2an el proceso en s de fa"ricacin del producto correspondiente.
Ejemplos de este tipo de m#tricas son el tiempo de desarrollo del producto$ el esfuer&o %ue
conlleva dicho desarrollo$ el n2mero y tipo de recursos empleados Lpersonas$ m!%uinas$...:$ el
coste del proceso$ etc.
La o"tencin de este tipo de m#tricas est! asociada generalmente a alguna t#cnica de
estimacin. En el siguiente tema descri"iremos las t#cnicas "!sicas de estimacin$ y los
m#todos %ue se pueden aplicar.
3.E. C'/&*2+-./
Pag. 31
Desde el punto de vista de la estimacin de software$ la clasificacin m!s 2til de m#tricas es la
%ue distingue en m#tricas del producto y del proceso.
De las m#tricas del producto$ las %ue realmente nos interesan son las de C2mero de Lneas
de +digo y los 'untos de )uncin de (l"recht. La primera m#trica es interesante por%ue sirve
de punto de partida de diversos m#todos de estimacin como el M#todo +,+,M,$ %ue se
ver! en el TEMA de esta 0nidad llamado MA,'(' () E+,-6$&-./ COCOMO. La segunda$
est! teniendo cada ve& mayor importancia en la estimacin de software$ de"ido a %ue se ha
demostrado en estos 2ltimos aos su utilidad para medir el tamao de un producto software$ y
tam"i#n en gran parte$ de"ido a la la"or del /)'0Q %ue sirve de apoyo y de soporte para
todos los usuarios %ue apli%uen la t#cnica de los 'untos de )uncin.
El resto de m#tricas del producto se han enunciado$ simplemente para %ue el alumno tenga
conocimiento de ellas$ sin necesidad de entrar m!s en detalle.
En cuanto a las m#tricas de procesos$ como se ha indicado en el apartado anterior$ suelen
estar con alguna t#cnica de estimacin$ %ue se estudiar! en el siguiente tema.
Pag. 32
TEMA 4:
TCNICAS DE ESTIMACIN
Pag. 33
4.1. F-+-./ ")/)%$*
'ara la estimacin$ e-isten cuatro t#cnicas "!sicas y comunes5
1.La opinin de los e-pertos4 Esta t#cnica se "asa en la e-periencia profesional de los
participantes en el proyecto de estimacin.
2.La analoga4 Es una apro-imacin m!s formal %ue la e-periencia de los e-pertos y se "asa
en la comparacin directa de uno o m!s proyectos pasados. La estimacin inicial se ajusta
dependiendo de las diferencias entre el proyecto pasado y el nuevo.
3.La descomposicin 4 +onsiste en la descomposicin de un producto en componentes m!s
pe%ueos$ o descomponer un proyecto en tareas de nivel inferior. La estimacin se hace a
partir del esfuer&o re%uerido para producir los componentes m!s pe%ueos o para reali&ar
las tareas de nivel inferior. La estimacin glo"al del proyecto resultar! de sumar las
estimaciones de los componentes.
4.Las ecuaciones de estimacin 4 1on frmulas matem!ticas %ue esta"lecen la relacin de
algunas medidas de entrada L%ue normalmente es la medida del tamao del producto: y
determinan el esfuer&o %ue se re%uerir!.
La primera t#cnica es un tanto informal y es la %ue se ha llevado a ca"o hasta el momento$ con
no muy "uenos resultados como ya hemos visto$ dada la complejidad del propio proceso de
estimacin.
'ara poder utili&ar la segunda t#cnica es necesario disponer de una "ase de datos histrica de
proyectos finali&ados con la %ue poder reali&ar la comparacin. (dem!s todos esos proyectos
tendr!n %ue ha"er seguido un proceso est!ndar. Es decir$ el ciclo de vida utili&ado y las
actividades han de ser similares. 1i no es as$ es difcil hacer comparaciones proyectoJproyecto.
0n proyecto puede ha"er comen&ado siguiendo unos pasos totalmente definidos y formali&ados$
y otro puede %ue slo tenga definida formalmente la fase de codificacin y prue"as$ el resto de
las fases nadie sa"e como se hicieron ni si se hicieron.
'or lo tanto$ a menos %ue los proyectos tengan un es%uema de proceso similar$ compararlos
unos con otros es como comparar peras con man&anas. Es necesaria una estandari&acin
para usar esta t#cnica.
,tro aspecto a tener en cuenta es %ue los datos so"re esos proyectos han de ser fia"les. Esto
%uiere decir %ue las empresas correspondientes han de tener un programa formali&ado para la
toma de medidas so"re sus proyectos.
Pag. 34
(ctualmente es difcil %ue las empresas cumplan estos dos re%uisitos5 estandari&acin de
procesos y formali&acin de la recogida de medidas. Day %ue tener en cuenta %ue las empresas
de"eran ha"erlos implantado desde hace algunos aos atr!s$ y %ue en estos momentos
todava e-isten muchas empresas %ue no siguen una metodologa de desarrollo y %ue tampoco
intentan a"ordar la cuestin de la confeccin de un histrico de proyectos.
'ara aplicar la tercera t#cnica hay %ue disponer tam"i#n de una "ase de datos histrica para
poder identificar el esfuer&o de las distintas actividades de "ajo nivel$ y #sta no est! normalmente
definida por las ra&ones %ue anteriormente hemos indicado.
'or todo ello$ cuando se comien&a a reali&ar el proceso de estimacin en una organi&acin se
utili&a alg2n m#todo o modelo esta"lecido$ es decir$ se emplea la cuarta t#cnica.
4.2. R)=2-+-,'+ () 2/ !2)/ MA,'(' () E+,-6$&-./
0n m#todo de estimacin tendr! #-ito si5
La estimacin inicial est! dentro del >;? de desviacin del coste final real.
El m#todo permite el refinamiento de la estimacin durante el ciclo de vida del producto
software.
El m#todo es f!cil de usar por el estimador. Esto permite una r!pida reJestimacin cuando
sea necesario4 por ejemplo$ para evaluar distintas alternativas.
Las reglas de la estimacin son entendidas por todas las personas a las %ue afectan los
resultados de la misma. Los directivos se sienten m!s seguros cuando el proceso de
estimacin es f!cilmente comprensi"le.
El m#todo es soportado por herramientas y est! documentado. La disponi"ilidad de
herramientas aumenta la eficacia de cual%uier m#todo. Esto es de"ido$ principalmente$ a %ue
los resultados pueden ser o"tenidos m!s r!pidamente y de una forma est!ndar.
4.3. MA,'('+ () E+,-6$&-./
0n m#todo de estimacin efica& permitir! ignorar aspectos sin inter#s y concentrare en los
aspectos esenciales. 0n "uen modelo de"era poseer capacidades predictivas$ mejor %ue ser
meramente descriptivo o e-plicativo.
La valide& de las m#tricas de software y de los modelos de estimacin de"e ser esta"lecida
demostrando la coincidencia entre los datos empricos y los e-perimentales. Esto re%uiere una
cuidadosa atencin en la toma de medidas y en el an!lisis de los datos.
Pag. 35
En general$ el an!lisis y la validacin de las m#tricas y los modelos de estimacin re%uiere una
slida "ase estadstica y diseo de e-perimentos. 'ara o"tener resultados significativos son
necesarios una definicin precisa de las m#tricas involucradas y de los procedimientos para la
captura de datos.
Los e-perimentos a pe%uea escala de"eran ser diseados cuidadosamente$ y no
aleatoriamente$ utili&ando principios de diseo e-perimental.
Los e-perimentos muy largos son muy difciles de dirigir. Es esencial poseer una "ase slida
de estadstica para llevar a ca"o e-perimentos significativos y anali&ar los datos resultantes.
En general$ si no se posee la "ase estadstica suficiente de"era de solicitarse la ayuda de
estadsticos para evaluar seriamente el tra"ajo reali&ado.
Los modelos de estimacin e-istentes se pueden clasificar como Modelos Estadsticos$
Modelos "asados en .eoras y Modelos +ompuestos. ( continuacin descri"iremos cada uno
de ellos.
4.3.1. M'()*'+ E+,$(5+,-&'+
+.E. Ralston y '.+. )eli-$ de /KM utili&aron datos de S; proyectos terminados completamente
para desarrollar un modelo simple de calculo del esfuer&o de desarrollo de software.
El principal determinante del esfuer&o de desarrollo fue la m#trica L,+.
1e asumi una relacin de la forma5 E O aL
"
$ donde L es el n2mero de lneas de cdigo$ en
miles y E es el esfuer&o total re%uerido en mesesFpersonas.
Mediante un an!lisis de regresin se encontraron los valores apropiados para a y ".
La ecuacin resultante fue5
E O <$A L
;$Ml
La productividad nominal de programacin en L,+ por personaFmes$ puede ser calculada
como LFE. Ralston y )eli- tam"i#n intentaron desarrollar un ndice de productividad$ /$ %ue
podra hacer incrementar o disminuir la productividad$ dependiendo de la naturale&a del
proyecto.
Pag. 36
Pag. 37
4.3.2. M'()*'+ 9$+$('+ )/ T)'%5$+: M'()*' () P2,/$6.
'ocos modelos propuestos tienen una "ase t#cnica su"stancial.
El modelo m!s importante es el de 'utnam. Este modelo asume una distri"ucin especfica
del esfuer&o a lo largo de la vida de un proyecto de desarrollo de software. El modelo se ha
o"tenido a partir de distri"uciones de mano de o"ra en grandes proyectos. 1in em"argo$ se
puede e-trapolar a proyectos m!s pe%ueos.
'utnam desarroll la siguiente relacin entre el tamao del producto software y el tiempo de
desarrollo5
E O L
>
FL+
>
.
T
:
donde L O el n2mero de instrucciones fuente producidas.
E O el esfuer&o durante todo el ciclo de vida en aosFpersona
+ O una constante dependiente de la tecnologa.
. O el tiempo de desarrollo en aos.
Los valores tpicos de + pueden ser5 + O A.;;; para un entorno po"re de desarrollo de
software Lsin metodologa$ con una documentacin y unas revisiones po"res:4 + O N.;;; para
un "uen entorno de desarrollo de software Lcon una "uena metodologa$ adecuadas
documentacin y revisiones:4 + O **.;;; para un entorno e-celente Lcon herramientas y
t#cnicas autom!ticas:. 1e puede o"tener la constante + correspondiente al entorno propio a
partir de datos histricos recopilados so"re anteriores esfuer&os de desarrollo.
4.3.3. M'()*'+ C'6<2)+,'+
1on modelos %ue utili&an una com"inacin de intuicin$ an!lisis estadstico y juicio de
e-pertos. ( continuacin se descri"en los m!s importantes.
$D M'()*' COCOMO () !')G6 .
Es pro"a"lemente el mas conocido y slidamente documentado de todos los modelos de
estimacin de costes. En el TEMA . M'()*' () E+,-6$&-./ COCOMO se estudia en
profundidad este modelo$ con aplicaciones pr!cticas.
9D SOFTCOST - T$2+3'%,G)
.ausworthe$ de Uet 'ropulsion La"oratory$ intent desarrollar una estimacin de coste del
software utili&ando elementos de los modelos de mas #-ito disponi"les. Este modelo re%uiere
Pag. 38
SN par!metros de entrada$ cuyos valores se deducen a partir de las respuestas del usuario a
T@ preguntas acerca del proyecto.
&D SP;R - C$<)%+ H'/)+
+apers Uones ha desarrollado un modelo de estimacin de costes llamado 1oftware
'roductivity$ 7uality and Ielia "ility L1'7I:.
El enfo%ue del pro"lema es similar al de Koehm en su modelo +,+,M,. Est! "asado en A;
factores %ue influyen ra&ona"lemente en el coste y productividad del desarrollo de software y
%ue est!n "ien definidos y otros A< factores %ue no est!n tan "ien definidos.
1'7I es un producto comercial$ pero no est! tan "ien documentado como otros modelos.
Ie%uiere responder a mas de *;; preguntas relacionadas con el proyecto para formular los
par!metros de entrada necesarios en el c!lculo de los costes y los planes. Uones seala %ue
con este modelo es posi"le proporcionar estimaciones de coste %ue estar!n el M;? de las
veces dentro del valor real con una desviacin del *<?.
(D COPMO - TG)9$2,
.he"aut propone un modelo de desarrollo de software %ue intenta conta"ili&ar el esfuer&o
re%uerido cuando los e%uipos de programacin est!n involucrados en grandes proyectos. La
ecuacin general de calculo de esfuer&o es5
E O a P "1 P c'
d
donde
a$ "$ c y d son constantes para ser determinadas a partir de datos empricos mediante
an!lisis de regresin5
1 es el tamao del programa en miles de L,+
' es el nivel medio de personal durante el ciclo de vida del proyecto.
Desafortunadamente$ este modelo re%uiere no uno sino dos par!metros cuyos valores no son
conocidos hasta la terminacin del proyecto. (dem!s$ las constantes " y c dependientes de la
complejidad del software no son f!cilmente determina"les.
Este modelo presenta una formula interesante$ pero necesita un mayor desarrollo y ajuste
para %ue sea de inter#s general.
Pag. 39
)D ESTIMACS - R29-/
Iu"in ha desarrollado un modelo de estimacin %ue utili&a especificaciones del negocio para
sus c!lculos. El modelo proporciona estimacin del esfuer&o total$ re%uisi tos de personal$
coste$ riesgo y efecto so"re la cartera de proyectos.
E1./M(+1 ser! anali&ado en la pr!ctica de la asginatura.
Pag. 40
TEMA 5:
MTODO DE ESTIMACIN DE
PUNTOS DE FUNCIN
Pag. 41
5.1. D)+$%%'**' () *$ ,A&/-&$ () P2/,'+ () F2/&-./
Los 'untos de )uncin miden el software cualificando la funcionalidad %ue proporciona
e-ternamente$ "as!ndose en el diseo lgico del sistema. 'or lo tanto$ en el caso de
su"sistemas diseados independientemente los 'untos de )uncin se calcular!n para cada
una de ellas$ y luego se sumar!n. 'or ejemplo$ cuando un sistema %ue proporcione por un
lado una funcionalidad onJline y por otro lado una funcionalidad "atch$ y por tanto$ se han
diseado independientemente los dos su"sistemas %ue proporcionan cada funcionalidad.
Los o"jetivos de los 'untos de )uncin son5
Medir lo %ue el usuario pide y lo %ue el usuario reci"e.
Medir independientemente de la tecnologa utili&ada en la implantacin del sistema.
'roporcionar una m#trica de tamao %ue d# soporte al an!lisis de la calidad y la
productividad.
'roporcionar un medio para la estimacin del software.
'roporcionar un factor de normali&acin para la comparacin de distintos software.
(dem!s de estos o"jetivos$ el proceso de conta"ili&ar los 'untos de )uncin de"era ser5
1uficientemente simple como para minimi&ar la carga de tra"ajo de los procesos de
medida.
+onciso en sus resultados.
El an!lisis de los 'untos de )uncin se desarrolla considerando cinco par!metros "!sicos
e-ternos del 1istema5
1. Entrada LE/$ del ingl#s E-ternal /nput:.
2. 1alida LE,$ del ingl#s E-ternal ,utput:.
3. +onsultas LE7$ del ingl#s E-ternal 7uery:.
4. Qrupos de datos lgicos internos L/L)$ del ingl#s /nternal Logic )ile:.
5. Qrupos de datos lgicos e-ternos LE/)$ del ingl#s E-ternal /nterface )ile:.
+on estos par!metros$ se determinan los puntos de funcin sin ajustar.
( este valor$ se le aplica un )actor de (juste o"tenido en "ase a unas valoraciones su"jetivas
so"re la aplicacin y su entorno. Es decir las caractersticas generales del sistema.
La aplicacin de la t#cnica de los 'untos de )uncin comprende los siguientes pasos5
Pag. 42
Definicin de los limites del sistema .
Definicin de par!metros .
9aloracin de la complejidad .
(n!lisis de las caractersticas generales del sistema.
5.2. D)7-/-&-./ () *'+ L-6-,)+ ()* S-+,)6$
El limite es utili&ado para definir el alcance del sistema y ayudar a identificar los par!metros
e-ternos.
E-isten tres visiones de los limites del sistema$ dependiendo de la utili&acin %ue %uiera
reali&arse de la t#cnica5
1I L$ $<*-&$&-./ ' *-6-,) ()* <%'(2&,'.
("arca a la totalidad de la aplicacin y se reali&a la cuenta de puntos al final del
desarrollo del proyecto cuando se gestiona el grupo de mantenimiento o cuando la
organi&acin inicia el uso de )'(. Este tipo de cuenta puede ser tam"i#n o"tenida de
un sistema en funcionamiento.
2I L-6-,) -/-&-$* ()* <%'0)&,' $ ()+$%%'**$%.
Es un tipo de conteo similar al anterior$ la diferencia est! en %ue se deriva de los
re%uisitos de un sistema %ue no e-iste aun.
3I L-6-,) ()* <%'0)&,' () 6)J'%$.
Esta situacin surge cuando ya e-iste el sistema y se trata de o"tener nuevas
versiones del mismo. La utili&acin de )'( en proyectos de mejora difiere de las
anteriores en %ue se consideran adiciones$ modificaciones o anulaciones de
funcionalidades$ en lugar de la totalidad del sistema. Co se puede caer en la trampa
de calcular los puntos del sistema total antes y despu#s de las mejoras y luego
su"straer uno de otro.
E-iste un elemento su"jetivo en la determinacin de los lmites del sistema y o"viamente un
cam"io en ellos cam"iar! el total de 'untos de )uncin. (un%ue esto podra parecer una
apro-imacin poco cientfica$ en la pr!ctica la orientacin %ue el analista de"era seguir es
considerar el pro"lema como un todo discreto.
La formula %ue permite calcular los 'untos de )uncin de un nuevo desarrollo es la siguiente5
)'( O )' V ()
Pag. 43
Donde5
)' es el n2mero de 'untos de )uncin sin ajustar de la aplicacin
() es el )actor de (juste de la aplicacin
El c!lculo de los 'untos de )uncin de un proyecto de mejora se puede o"tener mediante la
formula5
L(DDP+DQ(: W 9()( P LDEL W 9()K: O E)'
donde5
E)' es el n2mero de 'untos de )uncin del 'royecto de Mejora.
9()K es el )actor de (juste de la aplicacin antes del proyecto de mejora.
(DD es el n2mero de 'untos de )uncin de a%uellas funciones %ue se aadir!n al proyecto
como consecuencia de la mejora.
+DQ( es el n2mero de 'untos de )uncin sin ajustar de a%uellas funciones %ue ser!n
modificadas por el proyecto de mejora. Este n2mero refleja las funciones despu#s de la
modificacin.
DEL es el n2mero de 'untos de )uncin sin a%uellas funciones %ue ser!n eliminadas en el
proceso de mejora.
9()( es el )actor de (juste de la aplicacin despu#s del proyecto de mejora.
5.3. D)7-/-&-./ () P$%:6),%'+
'ara poder determinar la e-istencia de los componentes %ue contri"uir!n al total final$ hay %ue
definirlos previamente.
La definicin %ue vamos a considerar a%u es la reali&ada por /)'0Q en *MMT$ 2ltima versin.
Estos componentes pueden ser clasificados como .ipos de )unciones y son de dos clases5
D$,'+ ' T%$/+$&&-'/)+.
Pag. 44
5.3.1. T-<'+ () F2/&-./ D$,'+
Iepresentan la funcionalidad proporcionada a los usuarios para cumplir con sus re%uisitos de
datos internos y e-ternos.
1on de dos tipos5 )icheros Lgicos /nternos y )icheros de /nterface E-ternos.
5.3.1.1. F-&G)%'+ L.1-&'+ I/,)%/'+
0n )ichero Lgico /nterno es un grupo de datos lgicamente relacionados identifica"les por los
usuarios o informacin de control mantenidos y utili&ados dentro de los limites de la aplicacin.
'or un grupo de datos lgicamente relacionados e identifica"les por un usuario se entiende
a%uellos datos %ue un usuario e-perto podra identificar cumpliendo con un re%uisito especfico
de la aplicacin.
+orrespondera al almac#n de datos identificado por un nom"re en un Diagrama de )lujos de
Datos. El significado de almac#n u Diagrama de )lujo de Datos se ver! en las 0nidades de
(n!lisis y Diseo.
/nformacin de control corresponde a datos utili&ados por la aplicacin cumpliendo con
re%uisitos del negocio.
Mantenidos es la ha"ilidad para aadir$ cam"iar o "orrar datos mediante procedimientos
estandari&ados a
trav#s de la aplicacin.
Las reglas para identificar estos tipos de funcin son5
R)1*$ 1 El grupo de datos o informacin de control es un grupo de datos lgico
identifica"le por el usuario %ue cu"re de manera completa re%uisitos
especfico de #ste
R)1*$ 2 El grupo de datos es mantenido dentro de los lmites de la aplicacin
R)1*$ 3 El grupo de datos es mantenido o modificado por medio de un proceso
elemental de la aplicacin
R)1*$ 4 El grupo de datos identificado no se ha contado como un fichero
interfase e-terno de la aplicacin
Ejemplos de /L) son5
F-&G)%'+ 6$)+,%'+
Pag. 45
A<*-&$&-'/)+ () S)12%-($( () D$,'+
D$,'+ () A2(-,'%5$ A&,2$*-K$('+ <'% *$ $<*-&$&-./
M)/+$J)+ H)*< A&,2$*-K$('+ <'% *$ $<*-&$&-./
M)/+$J)+ () E%%'% A&,2$*-K$('+ <'% *$ $<*-&$&-./
D$,'+ () !$&L - 2<B +- )* 2+2$%-' *' %)=2-)%)
F-&G)%'+ I/,)%/'+ L.1-&'+ 6$/,)/-('+ <'% 6:+ () 2/$ $<*-&$&-./
5.3.1.2. F-&G)%'+ I/,)%7$+) E@,)%/'+
Iepresentan un grupo de datos relacionados lgicamente identifica"les por el usuario o
informacin de control utili&ada por la aplicacin$ pero mantenida por otra aplicacin.
R)1*$ 1 El grupo de datos o informacin de control es un grupo e datos lgico
identifica"le por el usuario %ue cu"re de manera completa re%usitos
especficos de #ste
R)1*$ 2 El grupo de datos es referenciado y es e-terno a la aplicacin %ue est!
siendo contada
R)1*$ 3 El grupo de datos no es mantenido por la aplicacin %ue est! siendo
contada
R)1*$ 4 El grupo de datos se ha contado como un /L) por$ al menos$ otra
aplicacin
R)1*$ 5 El grupo de datos identificado no ha sido contado como un /L) para la
aplicacin
5.3.2. T-<'+ () F2/&-./ T%$/+$&&-./
+omprende tres tipos de funcin5
E/,%$($+ )@,)%/$+ MEID: mantiene datos almacenados internamente.
S$*-($+ )@,)%/$+ MEOD: datos de salida de la aplicacin.
C'/+2*,$+ )@,)%/$+ ME;D: +om"inacin de una entrada Lpregunta: y de una salida
Lrespuesta:.
9amos a comentar "revemente cada una de ellas.
5.3.2.1. E/,%$($+ E@,)%/$+
Las Entradas E-ternas son datos o informacin de control %ue se introducen en la aplicacin
Pag. 46
desde fuera de sus limites.
Estos datos mantienen un )ichero Lgico /nterno. La /nformacin de +ontrol est! constituida
por datos utili&ados por un proceso dentro de los lmites de la aplicacin para asegurar el
cumplimiento de los re%uisitos del negocio definidos por los usuarios.
Esta /nformacin de +ontrol puede mantener directamente un )ichero Lgico /nterno. 0na
Entrada E-terna de"era ser considerada 2nica si tiene un formato distinto de las dem!s o el
diseo lgico re%uiere una lgica de procesamiento distinta de otra Entrada E-terna del mismo
formato. En otras pala"ras$ una Entrada E-terna se considera 2nica si los datos son mante X
nidos en un )ichero Lgico /nterno L/L): y el formato de entrada es 2nico o la lgica del
proceso es 2nica.
'ara cada proceso identificado %ue actuali&a un )ichero Lgico /nterno5
Day %ue considerar cada formato de entrada como un proceso distinto$ si los datos
utili&ados por el proceso pueden tener distintos formatos.
Day %ue sumar una unidad a cada Entrada E-terna por cada actividad de mantenimiento
de datos reali&ada Lsumar$ cam"iar$ "orrar:.
R)1*$ 1 Los datos se reci"en desde fuera de los lmites de la aplicacin
R)1*$ 2 Los datos mantienen un /L) a trav#s de un proceso elemental de la
aplicacin
R)1*$ 3 El proceso es la unidad m!s pe%uea de actividad %ue es significativa
para el negocio del usuario final
R)1*$ 4 El proceso es autocontenido y deja a la aplicacin %ue est! siendo
contada en un estado consistente
R)1*$ 5 El proceso identificado de"e verificar alguna de estas dos reglas 5
J 1u lgica de proceso es 2nica respecto otras entradas e-ternas de la
aplicacin.
J Los elementos de datos identificados son distintos a los de las otras
Els de la aplicacin.
Ejemplos de este tipo de funcin son5
L$+ ,%$/+$&&-'/)+5 Datos introducidos para mantener )icheros Lgicos /nternos.
L$+ <$/,$**$+ () )/,%$($5 Day %ue aadir una unidad a Entradas E-ternas por
cada funcin %ue mantiene un )ichero Lgico /nterno. 'or ejemplo$ si los datos
Pag. 47
introducidos en esa pantalla pueden aadir$ cam"iar y "orrar informacin en un
)ichero Lgico /nterno$ se contaran tres Entradas E-ternas.
L$+ )/,%$($+ <'% *',)+5 'or cada proceso 2nico %ue mantiene un )ichero /nterno
Lgico se de"e aadir una Entrada E-terna por cada adicin$ modificacin o
"orrado de datos.
0n fichero fsico de entrada$ cuando se anali&a lgicamente$ corresponde a una
Entrada E-terna o varias$ dependiendo de los tipos de registros contenidos y del
proceso re%uerido para su tratamiento.
(s mismo dos o m!s ficheros fsicos de entrada pueden corresponder a una
Entrada E-terna si el proceso lgico y el formato son id#nticos para cada uno de
los ficheros.
L$+ )/,%$($+ )@,)%/$+ (2<*-&$($+5 1i distintos procesos de entrada solicitados
e-presamente por el usuario duplican una Entrada E-terna$ son contados indepenX
dientemente cada uno.
0n ejemplo puede ser un ingreso en una cuenta "ancaria %ue se puede hacer por
un +ajero (utom!tico o a trav#s de una operacin normal$ siendo el mismo tipo de
entrada.
En cam"io$ no son Entradas E-ternas5
L'+ ($,'+ %)7)%)/&-$('+ utili&ados por la aplicacin pero no mantenidos como
)icheros Lgicos /nternos.
L$+ )/,%$($ () 2/$ C'/+2*,$
L'+ 1)/)%$('%)+ () I/7'%6)+
L$+ <$/,$**$+ () C'/)@-./ %ue no mantengan un )ichero Lgico /nterno.
5.3.2.2. S$*-($+ E@,)%/$+
Las 1alidas E-ternas son datos o informacin de control %ue sale de los lmites de la
aplicacin. Esta salida de"e ser considerada 2nica si tiene un formato 2nico o si el diseo
lgico re%uiere un proceso lgico distinto de otras salidas del mismo formato. .oda salida ha
de re%uerir un proceso de c!lculo de la informacin %ue se proporciona.
Las reglas para identificar este tipo de funciones son5
Pag. 48
R)1*$ 1 El proceso enva datos o informacion de control
R)1*$ 2 Los datos o informacin de control se envan a trav#s de un proceso
elemental de la aplicacin
R)1*$ 3 El proceso es la unidad m!s pe%uea de actividad %ue es significativa
para el negocio del usuario final
R)1*$ 4 El proceso es autocontenido y deja a la aplicacin en un estado
consistente
R)1*$ 5 El proceso identificado de"e verificar alguna de estas dos reglas 5
J 1u lgica de proceso es 2nica respecto otras salidas e-ternas de la
aplicacin
J Los elementos de datos identificados son distintos a la los de otras
E,s de la aplicacin
De"en considerarse 1alidas E-ternas5
L$ ,%$/+7)%)/&-$ () ($,'+ $ ',%$+ $<*-&$&-'/)+5 Datos %ue residen en un
)ichero Lgico /nterno %ue son formateados y procesados para ser utili&ados por
otra aplicacin.
Las salidas son identificadas "asadas en los procesos re%ueridos para el
tratamiento de los datos. 0n fichero fsico de salida$ cuando se anali&a
lgicamente$ puede corresponder a varias salidas. De una manera similar$ dos o
m!s ficheros fsicos de salida pueden corresponder a una 1alida E-terna si el
proceso lgico y los formatos son id#nticos para cada uno de ellos.
0n m#todo para identificar m2ltiples 1alidas E-ternas es ver cu!ntos tipos de
registros distinto hay en el fichero.
L'+ 6)/+$J)+ () )%%'%4&'/7-12%$&-./: Co se contaran si est!n asociados a una
+onsulta o a una Entrada.
L'+ 1%:7-&'+: +ada gr!fico distinto$ solicitado por el usuario$ de"era ser contado
como una salida. (s$ si unos datos estadsticos se presentan en formato de ta"la$
diagrama de "arras$ y tarta$ se contar!n como > salidas.
L'+ 1)/)%$('%)+ () -/7'%6)+: 0na salida desarrollada por el usuario con un
generador de informes de"era ser contada como una salida para cada tipo de
informe especificado.
1i el usuario solicita una facilidad de generacin de informes como parte de la
Pag. 49
aplicacin para ser confeccionados por #l mismo$ la cuenta ser! la siguiente5
De"era contarse una Entrada E-terna por cada par!metro para la definicin
de informes o comando Lej. select$ compare$ sort merge$ calculate$ format$ etc.:
utili&ado por el usuario para controlar la generacin del informe.
De"era contarse una 1alida por el informe total.
De"era contarse un )ichero Lgico si se crea un nuevo fichero y #ste se salva.
Co se de"en contar como 1alidas5
L$+ $02($+
L$+ (-+,-/,$+ 7'%6$+ () -/8'&$% *$ 6-+6$ +$*-($ *.1-&$
L'+ 6)/+$J)+ () )%%'%4&'/7-%6$&-./ $+'&-$('+ &'/ ,-<'+ ()
72/&-./ (-+,-/,'+ () E/,%$($+ E@,)%/$+
'or ejemplo$ no se conta"ili&ara como salida los mensajes de errorFconfirmacin
asociados a una +onsulta E-terna.
L'+ -/7'%6)+ 6N*,-<*)+48$*'%)+ N/-&'+ () ($,'+: /nformes id#nticos con el
mismo formato y la misma lgica de proceso$ pero %ue e-isten de"ido a distintos
valores de datos$ no se cuentan como salidas distintas. 'or ejemplo$ dos informes
id#nticos en formato y construccin$ el primero de los cuales contiene nom"res
comen&ando desde la ( a la L y el segundo desde la M a la Y se cuenta como una
2nica salida.
L'+ -/7'%6)+ A( H'&: +uando el usuario dirige y es responsa"le de la creacin
mediante la utili&acin de lenguajes como ),+01 o 17L de un n2mero indefinido
de informes$ no se cuentan como salidas.
5.3.2.3. C'/+2*,$+ E@,)%/$+
Las consultas representan los re%uisitos de informacin a la aplicacin en una com"inacin
2nica de entradaFsalida %ue se o"tiene de una "2s%ueda de datos$ no actuali&a un )ichero
Lgico /nterno y no contiene datos derivados. 0na consulta se considera 2nica si tiene un
formato distinto de otras consultas$ ya sea en entrada o salida$ o si el diseo lgico re%uiere
ediciones distintas a las de otras consultas.
1e entiende por datos derivados a%u#llos %ue re%uieren un proceso distinto a la "2s%ueda
Pag. 50
directa$ edicin o clasificacin de informacin de )icheros Lgicos /nternos o )icheros
/nterfases E-ternos.
Las reglas para identificar este tipo de funcin son5
R)1*$ 1 0na peticin entra dentro del lmite de la aplicacin
R)1*$ 2 0n resultado sale del lmite de la aplicacin
R)1*$ 3 Day recuperacin de datos
R)1*$ 4 Los datos recuperados no contiene datos derivados
R)1*$ 5 la peticin de entrada y el resultado de salida juntos$ hacen del proceso
la unidad de actividad m!s pe%uea %ue es significativa para el negocio
del usuario final
R)1*$ El proceso es autocontenido y deja a la apliacin %ue est! siendo
coantada en un estado consistente
R)1*$ E El proceso no actuali&a /L)s
R)1*$ O El proceso identificado de"e verificar alguna de estas dos reglas 5
J La lgica de proceso so"re la entrada y la salida es 2nia respecto a
otras E7s de la aplicacin
J Los elementos de datos LDE.s: %ue forman la entrada y la salida son
distintos a los de las otras E7s de la aplicacin
Ejemplos de +onsultas son5
L$ 9N+=2)($ -/6)(-$,$ () ($,'+
L$+ &'/+2*,$+ /' )@<*5&-,$+5 Las pantallas de modificacinF"orrado %ue
proporcionan capacidad de "2s%ueda de datos antes de la funcionalidad de
cam"ioF"orrado se consideran como consultas slo si la informacin %ue
proporcionan se muestra al usuario.
1i la entrada y salida de la consulta son id#nticas en las funciones de modificacin
y "orrado$ se contar! una sola consulta.
L'+ 6)/N+ &'/ &'/+2*,$+ -6<*5&-,$+: Las pantallas de men2 %ue proporcionan
una seleccin de pantallas y entradas para la "2s%ueda de datos para la pantalla
llamada$ se cuenta como una +onsulta.
P$/,$**$+ () &'/)@-./: Las pantallas de logon %ue proporcionaran seguridad se
cuentan como una consulta.
L$+ $02($+: 1on una consulta donde la entrada y la salida Lte-to: son 2nicas. 0n
te-to %ue puede ser accedido o mostrado en pantalla mediante distintas peticiones
o diferentes !reas de una aplicacin se cuenta como una consulta.
Pag. 51
1e pueden distinguir dos categoras de (yudas como son consultas tpicas5
a: (yudas a plena pantalla5 Es una facilidad %ue proporciona una salida a pantalla
como consecuencia de una llamada$ tam"i#n a trav#s de una pantalla. 1e cuenta
como una consulta de "aja complejidad por aplicacin$ sin tener en cuenta el
n2mero de pantallas devueltas.
": (yudas por campos5 Es una facilidad %ue se proporciona dependiendo de la
posicin del cursor o alg2n otro m#todo de identificacin$ mostr!ndose
documentacin especifica a dicho campo. 1e cuenta como una consulta de "aja
complejidad por aplicacin.
L$+ +$*-($+ (2<*-&$($+5 +onsultas iguales %ue producen una salida en diferentes
soportes$ como consecuencia de especificaciones del usuario$ se cuentan como
consultas distintas.
T2,'%-$*)+: Los sistemas de software relativos a la formacin de usuarios de"era
contarse como un sistema distinto.
Co se consideran como +onsultas5
L'+ 6)/+$J)+ () E%%'%4C'/7-%6$&-./.
L$ 2,-*-K$&-./ () (-+,-/,'+ 6A,'('+ () **$6$($ $ *$ 6-+6$&'/+2*,$.
'uede ocurrir %ue en una organi&acin en particular surja una situacin %ue no est# cu"ierta
por las guas e-istentes para contar 'untos de )uncin. Este m#todo refleja %ue #sta es una
t#cnica en evolucin. En tales casos el t#cnico de"e tomar la decisin de formular una regla$
"asada en su e-periencia personal as como en la de otros. Lo mas importante es documentar
la regla y aplicarla consistentemente.
5.4. F$*'%$&-./ () *$ C'6<*)J-($(
'ara cada uno de los par!metros e-ternos se ha de indicar su complejidad como Kaja$ Media
o (lta. 'ara las entradas$ salidas y consultas$ se puede evaluar su complejidad en funcin del
n2mero de campos %ue contengan y de el n2mero de ficheros a los %ue hagan referencia.
Pag. 52
'ara los ficheros$ por el contrario$ su complejidad vendr! dada en funcin del n2mero de
registros y de campos %ue tengan.
F$*'%$&-'/ () *$ &'6<*)J-($( () *'+ ,-<'+ () 72/&-./ ($,'+
( cada /L) y E/) identificado se le asigna una complejidad funcional %ue es funcin del
n2mero de tipos de elementos datos LDE.s: y el n2mero de tipos de elementos registros
LIE.s: de los %ue est#n compuestos$ y %ue vienen e-presada mendiante las ta"las de
contri"ucin y complejidad del ap#ndice A.
R)1*$+ () -()/,-7-&$&-./ () DET+ <$%$ ,-<' () 72/&-./ ($,'+
0n tipo de elemento dato es un campo 2nico y no recursivo so"re un tipo de funcin
datos y %ue es reconoci"le por el usuario. Cormalmente se
corresponden con los atri"utos de las entidades lgicas de usuario. 'ara %ue un campo sea
reconocido como DE. de un tipo de funcin datos$ de"e verificar$ al menos$ una de las
siguientes reglas 5
Iegla * +ontar cada campo 2nico y no recursivo so"re los /L)s o E/)s %ue sean
reconoci"les por el usuario
Iegla A +ontar un DE. por cada dato %ue e-ista so"re un /L) o un E/) por%ue
el usuario re%uiere mantener una relacin de #stos con otro /L))
Lclaves ajenas:
Iegla > +ontar las siguientes t#cnicas de implementain fsica como un 2nico
DE. para el grupo completo de campos 5
>.* campo %ue aparecen m!s de una ve& en un /L) o E/)
de"ido ala tecnologa o t#cnicas de implementacin
>.A campos repetitivos %ue tiene el mismo formato y %ue e-isten para
permitir m2ltiples ocurrencias del valor de un dato
R)1*$+ () -()/,-7-&$&-./ () RET+
0n tipo de elemento registro es un su"grupo de datos elementales reconoci"les por el
usuario dentro de un tipo de funcin datos.
Los su"grupos son de dos tipos 4 opcionales y mandatorios.Los 1%2<'+ '<&-'/$*)+
son a%uellos %ue usuario tiene la opcin de incluir o no mediante un proceso elemental %ue
aada o cree una instancia dentro un tipo de funcin datos. Los 1%2<'+ 6$/($,'%-'+ son
a%uellos en los %ue el usuario de"e incluir cuando se crea o aade una instancia.
'ara %ue un su"grupo de datos sea reconocido como IE. de"e verificar$ alumnos$
una de las siguientes reglas 5
Pag. 53
R)1*$ 1 +ontar un IE. por cada su"grupo opcional o mandatorio de un tipo de
funcin datos
R)1*$ 2 1i no hay su"grupos$ contar el /L) o E/) como un 2nico IE.
0na ve& identificados el n2mero de IE. y DE. se ha de acudir a la siguiente ta"la para
determinar la complejidad del /L) o E/).
DET
RET
1 $ 1P 2Q $ 5Q 51 ' 6:+
1 Kaja Kaja Media
2 $ 5 Kaja Media (lta
' 6:+ Media (lta (lta
F$*'%$&-./ () *$ &'6<*)J-($( () *'+ ,-<'+ () 72/&-./ ,%$/+$&&-./
F$*'%$&-./ () *$ &'6<*)J-($( () *$+ )/,%$($+ )@,)%/$+
( cada El identificaa se le asigna una complejidad funcional %ue es funcin del n2mero
de tipos de elementos datos LDE.s: %ue procese el procedimiento elemental$ y el n2mero de
tipos fichero referenciados L).Is: a los %ue acceda tal proceso. 9iene e-presada mediante las
ta"las de contri"ucin y complejidad del ap#ndice A.
R)1*$+ () -()/,-7-&$&-./ () DET+ <$%$ )/,%$($+ )@,)%/$+
0C DE. es un campo no recursivo y 2nico$ reconoci"le por el usuario y mantenido
so"re un /L) durante el proceso de una El. 'ara %ue un campo sea reconocido como DE. de
un tipo de funcin transaccin de"e verificar$ al menos$ una de las siguientes reglas 5
R)1*$ 1 +ontar un DE. por cada campo no recursivo y 2nico$ reconoci"le por
el usuario y mantenido so"re un /L) durante el proceso la El
R)1*$ 2 +ontar un DE. por cada campo %ue no es introducio porel usuario$
pero %ue es mantenido so"re un /L) por medio de una El
R)1*$ 3 +ontar las siguientes t#cnicas de implementacin fsica como un
2nico DE. para el grupo completo de campos 5
3.1 0n campo lgico %ue es almacenado fsicamente en m2ltiples
campos$ pero %ue es re%uerido por el usuario como una 2nica
pie&a de informacin
3.2 +ampos %ue aparecen m!s de una ve& en un /L) de"ido a
e-igencias de implementacin o tecnologa
3.3 +ampos %ue indican un error ocurrido durante el proceso o
confirmaciones de %ue #ste ha finali&ado con #-ito. .odos los
Pag. 54
mensajes se cuentan como un 2nico DE.
3.4 +ontar un 2nico DE. para la capacidad de especificar una accin
%ue de"e ser tomada para una El
R)1*$+ () -()/,-7-&$&./ () FTR+ <$%$ )/,%$($+ )@,)%/$+
0n tipo fichero referenciado es 5
0n fichero lgico interno *)5(' ' 6$/,)/-(' por un tipo funcin transaccin
0n fichero interfase e-terno *)5(' por un tipo funcin transaccin
'ara %ue un conjunto de datos sea reconocido como ).I para entradas e-ternas$
de"e verificar$ al menos$ una de las siguientes reglas 5
R)1*$+ 1 +ontar un ).I por cada /L) 6$/,)/-(' durante el proceso de una El
R)1*$+ 2 +ontar un ).I por cada /L) oE/) *)-(' durante el proceso de una El
R)1*$+ 3 +ontar un 2nico ).I por cada /L) %ue sea tanto 6$/,)/-(' como
*)-(' so"re un /L) durante el proceso de una El
0na ve& identificados el n2mero de ).I y DE. se ha de acudir a la siguiente ta"la para
determinar la complejidad de la E/
DET
FTR
1 $ 4 5 $ 15 1 ' 6:+
Q $ 1 Kaja Kaja Media
2 Kaja Media (lta
3 ' 6:+ Media (lta (lta
F$*'%$&-./ () *$ &'6<*)J-($( () *$+ +$*-($+ )@,)%/$+
( cada E, identificada$ asignarle una complejidad funcional "asada en el n2mero de
tipos fichero referenciados L).Is: por el proceso elemental de dicha E, y el n2mero de tipos
elemento de datos LDE.s: %ue la forman.9iene e-presada mediante las ta"las de contri"ucin
y complejidad del ap#ndice A.
R)1*$+ () -()/7-,-7$&-./ () DET+ <$%$ +$*-($+ )@,)%/$+
0C DE. es un campo no recursivo y 2nico$ reconoci"le por el usuario y %ue aparece
durante el proceso de una E,. 'ara %ue tal campo sea reconocido como DE. de"e verificar
alguna de estas reglas 5
R)1*$ 1 +ontar un DE. por cada campo no recursivo y 2nico$ reconoci"le por el
usuario y %ue aparece durante el proceso una la E,
R)1*$ 2 Co contar literales como DE.s$ como ttulos de informes$ pantallas o
paneles de identificacin$ ca"eceras de columnas y ttulos de campos
Pag. 55
R)1*$ 3 Co contar las varia"les de paginado ni las marcas generadas por el
sistema
R)1*$ 4 +ontar las siguientes t#cnicas de implementacin fisica como un 2nico
4.1 0n campo lgico %ue es almacenado fsicamente en m2ltiples
campos$ pero %ue es re%uerido por el usuario como una 2nica pie&a
de informacin
4.2 +ada tipo de eti%ueta y cada tipo de e%uivalente num#rico en un
gr!fico de salida
4.3 /nformacin de te-to$ %ue puede ser una 2nica pala"ra$ una
sentencia o una frase
R)1*$+ () -()/,-7-&$&-./ () FTR+ <$%$ +$*-($+ )@,)%/$+
0n tipo fichero referenciado es un fichero %ue es ledo cuando se procesa la salida
e-terna. 'ara %ue un conjunto de datos sea reconocido como ).I para salidas e-ternas$
de"e verificar la regla siguiente 5
R)1*$ 1 +ontar un ).I por cada /L) o E/) ledo durante el proceso de una E,
DET
FTR
1 $ 4 5 $ 1P 2Q ' 6:+
F$*'%$&-./ () *$ &'6<*)J-($( () *$+ &'/J2*,$+ )@,)%/$+
( cada E7 %ue ha sido identificada$ asignarle una complejidad funcional "asada en el
n2mero de tipos fichero referenciados L).Is: y de tipos elemento de datos LDE.1: %ue
intervienen en el proceso de la componente de entrada y de la componenete de salida
respectivamente. 0na ve& calculada am"as complejidades$ escoger la m!s alta entre la de la
entrada y la de la salida$ y traducirla a n2mero de puntos de funcin sin ajustar seg2n las
ta"las de contri"ucin y complejidad del ap#ndice A.
R)1*$+ () -()/,-7-$&-./ () DET+ <$%$ &'/+2*,$+ )@,)%/$+
0n DE. es un campo no recursivo y reconoci"le por el usuario %ue aparece en el
proceso de una E7. 'ara %ue tal campo sea reconocido como DE. de tal E7$ de"e verificar
Pag. 56
alguna de esta reglas 5
RE"LAS DE IDENTIFICACIN PARA LA ENTRADA DE LA E;
R)1*$ 1 +ontar un DE. por cada campo no recursivo$ reconoci"le por el usuario
%ue apare&ca en la parte de entrada de una consulta
R)1*$ 2 +ontar las siguientes t#cnicas de implementacin fsica como un 2nico
R)1*$ 3 +ontar las siguientes t#cnicas de implentacin fsica como un 2nico DE.
para el grupo completo de campos 5
3.1 +ampos %ue indican un error ocurrido durante el proceso del DE.
de entrada$ o confirmacion del %ue el proceso ha terminado de
manera correcta. .odos los mensajes se cuentan como un 2nico
DE..
3.2 +ampos %ue especifican %ue la E7 de"e ser procesada
RE"LAS DE IDENTIFICACIN PARA LA SALIDA DE LA E;
R)1*$ 1 +ontar un DE. por cada campo no recursivo y reconoci"le por el usuario
%ue apare&ca en la parte de salida de una consulta
R)1*$ 2 Co contar como DE.s literales como por ejemplo$ ttulos de informes$
idenficacin de pantallas o paneles$ ca"eceras de columnas$ y ttulos de
campos.
R)1*$ 3 Co contar varia"les o marcas generadas por el sistema o marcas$ como
son los n2meros de p!gina$ informacin de posicin$ comandos de
paginado o campos de fecha y hora
R)1*$ 4 +ontar las siguientes t#cnicas de implementacin fisica como un 2nico
4.1 0n campo lgico %ue se almacena fisicamente en multiples campos
pero %ue es re%uerido por el usuario como una unidad de informacin
4.2 +ampos %ue aparecen m!s de una ve& en un /L) de"ido a
e-igencias de la tecnologa o t#cnicas de implementacin
R)1*$+ () -()/,-7-&$&-'/ () FTR+ <$%$ &'/+2*,$+ )@,)%/$+
0n tipo fichero referenciado es un fichero %ue es ledo cuando se procesa la consulta
e-terna. 'ara %ue un conjunto de datos sea reconocido como ).I para consultas e-ternas$
de"e verificar alguna de las reglas siguientes 5
R)1*$ 1 MENTRADAD +ontar un ).I por cada /L) o E/) ledo durante el
proceso de la E7
R)1*$+ 2 MSALIDAD +ontar un ).I por cada /L) o E/) ledo durante el
proceso de la E7
Pag. 57
'ara la parte de entrada
DET
FTR
1 $ 4 5 $ 15 1 ' 6:+
2 Kaja Media (lta
'ara la parte de salida5
DET
FTR
1 $ 4 5 $ 1P 2Q ' 6:+
0na ve& definida la complejidad de cada par!metro se aplica el siguiente c!lculo5
P$%:6),%' C'6<*)J-($( R P)+' T',$*
Entrada (lta V S O
Media V T O
Kaja V > O
1alida (lta V @ O
Media V < O
Kaja V T O
)ichero Lgico (lta V *< O
/nterno Media V *; O
Kaja V @ O
)ichero Lgico (lta V *; O
E-terno Media V @ O
Kaja V < O
+onsultas (lta V S O
Media V T O
Kaja V > O
La suma total da los 'untos de )uncin 1in (justar del 1istema.
Pag. 58
5.5. A/:*-+-+ () *$+ &$%$&,)%5+,-&$+ 1)/)%$*)+ ()* +-+,)6$
0na ve& o"tenidos el total de 'untos de )uncin sin ajustar$ de"e reali&arse un ajuste del
mismo en funcin de las caractersticas generales del sistema.
Estas caractersticas son5
*. +omunicacin de datos.
A. )unciones distri"uidas.
>. Iendimiento.
T. +onfiguraciones fuertemente utili&adas.
<. )recuencia de transacciones.
S. Entrada onJline de datos.
@. Diseo para la eficiencia del usuario final.
N. (ctuali&acin onJline.
M. 'rocesos complejos.
*;. 0tili&acin en otros sistemas.
**. )acilidad de instalacin.
*A. )acilidad de operacin.
*>. /nstalacin de M2ltiples sitios.
*T. )acilidad de cam"io.
En funcin de estas catorce caractersticas se calcula el grado de influencia$ del modo %ue se
mostrar! a continuacin.
0na ve& calculado el grado de influencia$ .D/ Ldel ingl#s .otal Degree of /nfluence:$ de las
caractersticas$ se puede llegar al valor del factor de ajuste mediante la frmula5
() O L.D/ - ,.,*: P ;.S<
El valor final de 'untos de )uncin ajustados ser!5
)'( O )' V ()
E-iste un de"ate general so"re *$+ &$%$&,)%5+,-&$+ 1)/)%$*)+ ()* +-+,)6$B ya %ue en gran
parte su evaluacin es su"jetiva$ y por otro lado su valor como multiplicador es muy "ajo. 1in
em"argo$ forma parte de la t#cnica y en el futuro se prev# %ue sea uno de los aspectos m!s
importantes en la evolucin de la misma.
Pag. 59
9amos a estudiar la valoracin %ue hace de estas caractersticas el /)'0Q. +ada una de ellas
se evaluar! de ; a <$ seg2n las guas %ue se indican a continuacin$ el .D/ se o"tendr! como
suma de los valores de cada una de ellas.
5.5.1. C'62/-&$&-./ () ($,'+
Los datos e informacin de control utili&ados en la aplicacin$ se reci"en o son enviados a
trav#s de medios de telecomunicacin.
Los terminales conectados localmente a la unidad de control$ son considerados como medios
de comunicacin.
Los valores utili&ados son los %ue se muestran en la .a"la <.*5
; La aplicacin es por lotes o utili&ando un ordenador personal
* La aplicacin es por lotes pero e-iste una entrada de datos o impresin remotas
A La aplicacin es por lotes pero son remotas la entrada de datos o la impresin.
> Entrada onJline de datos a un proceso por lotes o sistema de consultas.
T M!s de un ordenador frontJend$ pero la aplicacin soporta un solo tipo de protocolo de
comunicaciones.
< M!s de un ordenador frontJend$ pero la aplicacin soporta mas de un tipo de
protocolo de comunicaciones
T$9*$ 5.1. C'62/-&$&-./ () D$,'+
5.5.2. F2/&-'/)+ (-+,%-92-($+
1on caractersticas de la aplicacin %ue permiten la e-is tencia de datos o procesos distri"uidos
dentro del limite de la aplicacin.
Los valores son los mostrados en la .a"la <.A.
; Co e-iste este tipo de funciones en la aplicacin.
* La aplicacin prepara datos para %ue el usuario final los procese en otro
componente del sistema. 'or ejemplo$ en una hoja electrnica en un ordenador
personal.
A Los datos son preparados para ser transferidos. 1e transfieren y procesan en otro
componente del sistema$ pero no por el usuario final.
> El proceso distri"uido y la transferencia de datos son onJline y slo en una
direccin.
Pag. 60
T El proceso distri"uido y la transferencia de datos son onJline en am"as direcciones.
< Los procesos se desarrollan din!micamente en el componente m!s apropiado del
sistema.
T$9*$ 5.2. F2/&-'/)+ D-+,%-92-($+
5.5.3. R)/(-6-)/,'
Los o"jetivos de rendimiento del sistema$ definidos o apro"ados por el usuario$ tanto en
tiempo de respuesta como en volumen de datos a procesar$ se ver!n influenciados por el
diseo$ desarrollo$ instalacin y soporte de la aplicacin. La .a"la <.>. muestra la valoracin
del rendimiento.
; Co e-isten re%uisitos especficos de rendimiento.
* Iendimiento y re%uisitos de diseo han sido definidos y revisados pero no
re%uieren ninguna accin especial.
A El tiempo de respuesta o la capacidad de proceso es critico durante las horas
punta. Co se re%uiere ning2n diseo especial para la utili&acin de la 0nidad +entral
de 'roceso L0+': del ordenador. Los procesos demorados se ejecutan al siguiente
da.
> El tiempo de respuesta o la capacidad de proceso es critico durante todas las horas
de operacin. Co se re%uiere un diseo especial para la utili&acin de la 0+'.
T Los re%uisitos de rendimiento por parte de los usuarios son suficientemente
estrictos como para re%uerir un an!lisis de rendimiento en la fase de diseo.
< (dem!s$ hay %ue utili&ar herramientas para el an!lisis de rendimiento durante el
diseo$ desarrollo yFo fase de implantacin para verificar los re%uisitos de
rendimiento.
T$9*$ 5.3. R)/(-6-)/,'
5.5.4. C'/7-12%$&-'/)+ 72)%,)6)/,) 2,-*-K$($+
Es una caracterstica de la aplicacin %ue re%uiere consideraciones especiales de diseo
de"ido a las limitaciones de los e%uipos a utili&ar.
Los valores se muestran en la .a"la <.T.
; Co e-isten restricciones de ning2n tipo.
* E-isten restricciones operativas$ pero no re%uieren
un esfuer&o especial para conseguirlas.
A E-isten algunas restricciones de seguridad o tiempo.
> E-isten re%uisitos especficos de procesador para algunas partes de la aplicacin.
T Las restricciones definidas en el ordenador central o procesador dedicado o"ligan a
Pag. 61
limitaciones en la aplicacin.
< (dem!s de las caractersticas del punto T$ e-isten limitaciones en los componentes
distri"uidos del sistema.
T$9*$ 5.4. C'/7-12%$&-'/)+ 72)%,)6)/,) 2,-*-K$($+
5.5.5. F%)&2)/&-$ () ,%$/+$&&-'/)+
La frecuencia de transacciones es alta e influye so"re el diseo$ desarrollo$ instalacin y
soporte de la aplicacin.
Los valores a asignar son los de la .a"la <.<.
; Co e-iste una definicin del periodo punta de transacciones.
* 1e conoce el periodo punta Lmensual$ trimestral$ estacional$ anual:.
A 1e conoce el periodo semanal.
> 1e conoce el periodo punta diario.
T La frecuencia de transacciones definida por el usuario en los re%uisitos de la
aplicacin o acuerdos de nivel de servicio son suficientemente altos como para
re%uerir an!lisis de rendimiento de tareas durante la fase de diseo.
< La frecuencia de transacciones definida por el usuario en los re%uisitos de la
aplicacin o acuerdos de nivel de servicio son suficientemente altos como para
re%uerir el uso de an!lisis de rendimiento de tareas y de herramientas de medida
del rendimiento en el diseo$ desarrollo yFo fase de instalacin.
T$9*$ 5.5. F%)&2)/&-$ () T%$/+$&&-'/)+
5.5.. E/,%$($ () ($,'+ '/-*-/)
Los valores son los de la .a"la <.S.
; .odas las transacciones se procesan por lotes.
* *? al @? de las transacciones son interactivas.
A N? al *<? de las transacciones son interactivas.
> *S? al A>? de las transacciones son interactivas.
T AT? al >;? de las transacciones son interactivas
< M!s del >;? de las transacciones son interactivas.
T$9*$ 5.. E/,%$($+ '/-*-/)
5.5.E. E7-&-)/&-$ ()* 2+2$%-' 7-/$*
Las funciones onJline proporcionadas ponen #nfasis en un diseo %ue incremente la eficiencia
del usuario final. Estas funciones pueden ser5
Pag. 62
(yudas a la navegacin.
Men2s
(yudasFDocumentacin onJline
Movimiento autom!tico del cursor.
1crolling.
/mpresin remota.
.eclas de funcin preasignadas.
1u"misin de tra"ajos por lotes a trav#s de transacciones onJline.
1eleccin mediante cursor de datos en pantalla.
0so amplio de facilidades de vdeo.
/nterfase de ratn.
9entanas.
Iacionali&acin del uso de pantallas para reali&ar una funcin de negocio.
1oporte de dos lenguas L+ontar como T funciones:.
1oporte multiJlengua L+ontar como S funciones:.
Los valores son los de la ta"la <.@.
; Cada de lo anterior.
* *J> de las funciones anteriores.
A TJ< de las funciones anteriores.
> S o m!s$ pero no e-isten re%uisitos del usuario respecto a la eficiencia.
T S o m!s$ pero est!n definidos los re%uisitos de eficiencia del usuario %ue o"ligan a
disear tareas %ue tienen en cuenta factores humanos4 por ejemplo$ minimi&ar el
n2mero de tecleos$ uso de mascaras$ etc.
< S o m!s$ y hay re%uisitos del usuario so"re eficiencia %ue
o"ligan a utili&ar herramientas especiales y procesos para demostrar %ue los
o"jetivos se han alcan&ado.
T$9*$ 5.E. E7-&-)/&-$ ()* 2+2$%-' 7-/$*.
5.5.O. A&,2$*-K$&-./ '/-*-/)
La aplicacin proporciona actuali&acin on J line de los )icheros Lgicos /nternos .
Los valores se muestran en la .a"la <.N.
; Cinguno.
* (ctuali&acin onJline de * a > ficheros. El volumen de actuali&acin es "ajo y la
Pag. 63
recuperacin f!cil.
A (ctuali&acin onJline de T m!s ficheros. El volumen de actuali&acin es "ajo y la
recuperacin es "aja.
> (ctuali&acin importante de los )icheros Lgicos /nternos.
T (dem!s de la proteccin contra la perdida de datos es esencial y ha sido
especialmente diseada y programada en el sistema.
< (dem!s del punto T$ los altos vol2menes de transacciones re%uieren %ue sea
considerado el coste de los procesos de recuperacin. Los procedimientos de
recuperacin est!n altamente automati&ados con intervencin mnima del operador.
T$9*$ 5.O. A&,2$*-K$&-./ '/-*-/)
5.5.P. P%'&)+'+ &'6<*)J'+
Es una caracterstica de la aplicacin. Las categoras e-istentes son5
+ontroles especiales Lprocesos de auditora: yFo aplicaciones de seguridad.
'roceso lgico complejo.
'rocesos matem!ticos complejos.
E-cesivas e-cepciones de proceso dando lugar a transacciones incompletas %ue
de"en ser procesadas de nuevo4 por ejemplo$ transacciones incompletas en cajeros
autom!ticos$ falta de datos o"ligatorios$ etc.
Manejo de dispositivos complejos4 por ejemplo$ multiJmedia$ independencia de
dispositivos$ etc.
Los valores son los de la .a"la <.M.
; Cada de lo anterior.
* 0no de los anteriores.
A Dos de los anteriores.
> .res de los anteriores.
T +uatro de los anteriores.
< .odos los anteriores.
T$9*$ 5.P. P%'&)+'+ C'6<*)J'+
5.5.1Q. R)2,-*-K$&-./
La aplicacin y el cdigo han sido diseados especficamente$ desarrollados y soportados
para ser utili&ados en otras aplica ciones .
Los valores aparecen en la .a"la <.*;.
; Co reusa"le.
Pag. 64
* 1e utili&a cdigo reusa"le dentro de la aplicacin.
A Menos del *;? de la aplicacin tiene en cuenta las necesidades de mas de un
usuario.
> El *;? m!s de la aplicacin tiene en cuenta las necesidades de mas de un
usuario.
T La aplicacin fue empa%uetada e-presamente yFo documentada para ser
f!cilmente reusa"le. La aplicacin es adaptada por el usuario a nivel de cdigo
fuente.
< La aplicacin fue empa%uetada e-presamente yFo documentada para ser
f!cilmente reusa"le. La aplicacin es adaptada por el usuario por medio de
par!metros de mantenimiento.
T$9*$ 5.1Q. R)2,-*-K$&-./
Pag. 65
<.<.**. )acilidad de instalacin
La facilidad de conversin e instalacin son caractersticas de la aplicacin. durante la fase de
prue"as del sistema se proporcionar!n y pro"ar!n un plan de conversin e instalacin as
como herramientas para la conversin.
Los valores son los de la .a"la <.**.
; Co se reali&aron consideraciones ni se re%uirieron desarrollos especiales para la
instalacin por parte del usuario.
* Co se reali&aron consideraciones especiales por el usuario pero se re%uirieron
desarrollos especiales instalacin.
A Los re%uisitos de conversin e instalacin fueron definidos por el usuario y las guas
para la conversin e instalacin fueron desarrolladas y pro"adas. El impacto de la
conversin en el proyecto no se considera importante.
> Los re%uisitos de conversin e instalacin fueron definidos por el usuario y las guas
para la conversin e instalacin fueron proporcionadas y pro"ados.
T (dem!s del punto A$ se proporcionaran y pro"aran la conversin autom!tica y
herramientas para la instalacin.
< (dem!s del punto >$ se proporcionaran y pro"aran la revisin autom!tica y las
herramientas para la instalacin.
T$9*$ 5.11. F$&-*-($( () -/+,$*$&-./
5.5.12. F$&-*-($( () '<)%$&-./
La facilidad de operacin es una caracterstica de la aplicacin. 1e proporcionar!n y pro"ar!n
durante la fase de prue"as del sistema$ un arran%ue efica&$ procedimientos de respaldo y
recuperacin. La aplicacin minimi&a la necesidad de actividades manuales tales como
montaje de cintas$ manejo de papel o intervencin manual durante la operacin del sistema.
Los valores aparecen en la .a"la <.*A.
; Co se definieron por parte del usuario necesidades especiales de operacin o
respaldo de distintas de las normales.
*JT 1eleccionar$ valorando como uno$ cada una de las siguientes solicitudes reali&adas
a la aplicacin5
J 'rocesos eficaces de arran%ue$ respaldo y recuperacin
pero con intervencin del operador. L+ontar como A:
J La aplicacin minimi&a la necesidad de montajes de
cintas.
J La aplicacin minimi&a la necesidad de manejo de papel.
Pag. 66
< La aplicacin de"e disearse sin intervencin de operadores4
es decir el operador no de"e intervenir mas %ue para arrancar
y parar la aplicacin. 0no de los elementos de la aplicacin es la recuperacin
autom!tica de errores.
T$9*$ 5.12. F$&-*-($( () '<)%$&-./
5.5.13. I/+,$*$&-./ )/ (-+,-/,'+ *21$%)+
La aplicacin se disear! y desarrollar! para ser instalada y mantenida en distintos lugares por
distintas organi&aciones. Los valores los %ue se muestran en la .a"la <.*>.
; Co e-isten re%uisitos del usuario para considerar la necesidad de m!s de un
usuario lugar de instalacin.
* 1e necesita disear la aplicacin para ser utili&ada en m2ltiples lugares pero
funcionar! "ajo entornos -(A/,-&'+ de hardware y software.
A 1e necesita disear la aplicacin para ser utili&ada en m2ltiples lugares y funcionar!
"ajo un entorno de hardware y software +-6-*$%)+.
> 1e necesita disear la aplicacin para ser utili&ada en distintos lugares y funcionar!
"ajo entornos (-+,-/,'+ de hardware y software.
T De"er!n ser proporcionados y pro"ados la documentacin y los planes de soporte
de la aplicacin para ser utili&ados en distintos lugares$ en el modo %ue se indic en
los apartados L*: y LA:.
< De"er!n ser proporcionados y pro"ados la documentacin y los planes de soporte
de la aplicacin para ser utili&ada en distintos lugares$ en el modo %ue se indic en
el apartado L>:.
T$9*$ 5.13. I/+,$*$&-./ )/ (-+,-/,'+ *21$%)+
5.5.14. F$&-*-($( () &$69-'+
La aplicacin de"e ser especficamente diseada$ desarrollada y mantenida para facilitar el
cam"io.
Los siguientes son ejemplos de facilidades de cam"ios5
+apacidad para proporcionar fle-i"ilidad en las consultas y o"tencin de informes.
Los datos de la aplicacin relativos al negocio se mantienen en ta"las por parte de los
usuarios.
Los valores son5
Pag. 67
; Co e-iste ninguna especificacin por parte de los usuarios en este sentido.
*J< 1e seleccionar! alguna de estas opciones5
J )acilidad para reali&ar consultas o informes simples tales como la utili&acin de
operadores lgicos (CDF,I so"re un )ichero Lgico /nterno Lse contar! como *:.
J )acilidad para reali&ar consultas o informes de complejidad media tales como la
utili&acin de operadores lgicos (CDF,I so"re mas de un )ichero Lgico /nterno Lse
contara como A:.
J )acilidad para reali&ar consultasFinformes complejos. L1e contaran como >:.
J 1e mantendr!n datos de control en ta"las %ue ser!n mantenidas por los
usuarios a trav#s de procesos interactivos onJline$ pero los cam"ios no ser!n efectivos
hasta el siguiente da de funcionamiento de la aplicacin. L1e contar! como *:
J /gual %ue el caso anterior$ pero los cam"ios ser!n efectivos inmediatamente Lse
contar! como A:.
'ara usar eficientemente los 'untos de )uncin$ se emplean unos ratios relativos a las
siguientes m#tricas5
'roductividad4 /ndica el n2mero de 'untos de )uncin %ue puede desarrollar una
persona en un mes.
+alidad4 /ndica el n2mero de errores %ue supuestamente se cometer!n por 'unto de
)uncin.
+oste4 /ndica las pesetas %ue costar! a la empresa el desarrollo de un 'unto de
)uncin.
Documentacin4 /ndica el n2mero de p!ginas de documentacin %ue se generar! por
'unto de )uncin.
Lneas de +digo4 /ndica el n2mero de lneas de un determinado lenguaje de
'rogramacin$ %ue se escri"ir!n por 'unto de )uncin.
Estos ratios vendr!n medidos en5
'roductividad O puntos funcinFpersonaJmes
+alidad O erroresFpunto funcin
+oste O pesetasFpunto funcin
Documentacin O p!ginasFpunto funcin
Lneas de +digo O lneasFpunto funcin
La clave de la utili&acin de esta t#cnica radica en la o"tencin de estos ratios$ %ue ser!n
especficos de cada organi&acin$ y %ue nos dar!n informacin so"re el tamao de la
aplicacin. Estos ratios se o"tendr!n de proyectos anteriores %ue se hayan desarrollado en la
Pag. 68
organi&acin.
Pag. 69
TEMA :
MTODO DE ESTIMACIN
COCOMO

Pag. 70
.1. A<*-&$&-'/ ()* M'()*' COCOMO
Este modelo se aplica a los desarrollos %ue siguen el ciclo de vida en cascada Len nueve
etapas:$ y corresponde a las siguientes fases5
'lanificacin y Definicin de Ie%uisitos.
Diseo de 'roducto.
Diseo detallado.
+odificacin y prue"as unitarias.
/ntegracin y 'rue"as.
/mplantacin.
E-plotacin y Mantenimiento.
/ncorpora dentro del proceso5
9erificacin y 9alidacin.
Qestin de +onfiguracin.
E-isten tres modos de desarrollo de software seg2n +,+,M,5 org!nico$ semili"re y rgido$
seg2n las caractersticas de la aplicacin y del entorno de desarrollo. ( cada uno de estos
modelos se le puede aplicar tres m#todos de estimacin distintos 5 "!sico$ intermedio y
detallado.
+uando un ingeniero de software est! ante un proyecto a estimar$ lo primero %ue de"e hacer
para aplicar el +,+,M, es situar su proyecto en el espacio de dos dimensiones Lmodo$
modelo: de la )igura S.*.
En la )igura S.*$ '- es un proyecto %ue va a ser desarrollado seg2n un modelo 1emili"re$
dado e tipo de aplicacin y el e%uipo del %ue se dispone$ y se va estimar seg2n +,+,M,
Detallado$ dada la e-actitud %ue se re%uiere de la estimacin.
Pag. 71
Px
modos de desarrollo
del software
Rgido
Semirgido
Orgnico
Bsico Intermedio
Detallado
modelos de
aplicacin
F-12%$ .1. E+<$&-' <$%$ +-,2$% 2/ <%'0)&,'
$ )+,-6$% <'% COCOMO
.2. M'('+ () D)+$%%'**' () S'7,3$%)
Este modelo considera tres modos distintos de desarrollo de software5
.2.1. M'(' O%1:/-&'
Este modo se caracteri&a por lo siguiente5
El proyecto se desarrolla en e%uipos relativamente pe%ueos en un entorno familiar$
en la propia empresa.
Muchas personas relacionadas con el proyecto tienen amplia e-periencia tra"ajando
en sistemas similares dentro de la propia organi&acin y tienen un "uen conocimiento
de cmo el sistema %ue se est! desarrollando contri"uir! a los o"jetivos de la
,rgani&acin.
Pag. 72
Esto significa %ue muchas personas podr!n contri"uir al proyecto desde las primeras
etapas$ sin generar una so"recarga de comunicacin importante.
El proyecto se desarrolla en un entorno relativamente relajado en cuanto a e-igencia
por parte de los usuarios para %ue el software cumpla las especificaciones y pueda ser
desarrollado m!s f!cilmente. Esta es otra ra&n para una mayor productividad.
1e desarrolla en un entorno generalmente esta"le$ con muy pe%uea pro"a"ilidad de
coincidencia en el desarrollo de un nuevo hardware u operaciones desconocidas.
Mnima motivacin para terminar el proyecto antes de lo previsto .
'royectos de tamao relativamente pe%ueo. +omo m!-imo <; ZD1/ Lmiles de
instrucciones:.
.2.2. M'(' S)6-*-9%)
Este modelo se caracteri&a por lo siguiente5
El e%uipo del proyecto tiene un nivel medio de e-periencia en proyectos similares.
El e%uipo es una com"inacin de personal e-perto e ine-per to .
(lgunos miem"ros del proyecto tienen alguna e-periencia en aspectos del proyecto y
otros no.
El tipo de proyectos representativo podra ser un sistema de proceso de transacciones
con interfases muy poco riguro sas en algunos casos y muy rgidas en otros .
El tamao del producto llega a las >;; ZD1/ .
.2.3. M'(' R51-('
Los elementos caractersticos de este modo de desarrollo son5
'royectos %ue de"en desarrollarse dentro de unas limitaciones muy estrictas .
El producto de"e e-plotarse dentro de un entorno muy acoplado de hardware$
software$ normativa y procedimientos operativos$ tales como sistemas de transferencia
Pag. 73
electrnica de fondos o control de trafico a#reo.
Los costes de cam"iar algo en este complejo entramado son tan altos$ %ue sus
caractersticas se consideran inmodifi ca"les $ asi %ue el software de"e reali&arse
estrictamente conforme a las especificaciones.
+omo resultado$ estos proyectos no admiten negociar cam"ios en el software
modificando los re%uisitos e interfases del usuario$ por lo %ue el esfuer&o en
verificaciones y validacin asi como la gestin de configuraciones$ es muy alto.
Estos proyectos se desarrollan en !reas generalmente desconocidas$ lo cual lleva
inicialmente a e%uipos pe%ueos de analistas y a una so"recarga de comunicacin
importante durante el desarrollo.
0na ve& %ue el proyecto ha terminado la fase de diseo $ la mejor estrategia para
continuar el desarrollo es constituir un e%uipo grande de programacin para reali&ar el
diseo detallado$ codificacin y prue"as en paralelo. Esta estrategia conduce a puntas
en cuanto a personal y a un mayor consumo de esfuer&o mayor %ue en los restantes
niveles.
1e aplica a proyectos de cual%uier tamao.
.3. M'()*'+ COCOMO
'ueden aplicarse a los tres modos de desarrollo de proyec tos y son 5
.3.1. M'()*' !:+-&'
1e suele aplicar en los desarrollos de productos pe%ueosFmedios$ desarrollados por personal
de la propia empresa en modo org!nico. (un%ue tam"i#n puede aplicarse al resto de los
modos.
Las ecuaciones de estimacin de esfuer&o y tiempo de desarrollo para cada modo de
desarrollo5
O%1:/-&'5 MM O A$T LZD1/:
*$;<
.DE9 O A$< LMM:
;$>N
Pag. 74
S)6-*-9%)5 MM O >$; LZD1/:
*$*A
.DE9 O A$< LMM:
;$><
R51-('5 MM O >$S LZD1/:
*$A;
.DE9 O A$< LMM:
;$>A
Donde$
ZD1/ significa n2mero de instrucciones de cdigo en miles.
MM significa esfuer&o medido en MesesFDom"re.
.DE9 significa duracin en Meses.
EJ)6<*':
Supongamos que queremos desarrollar un programa que se ha estimado tendr 32.000
instrucciones ! en "ase a las caracter#sticas de la aplicaci$n decidimos tratarlo en el modo
orgnico.
%&ules sern el es'uerzo, tiempo ! recursos requeridos para desarrollar dicha aplicaci$n(
Esfuer&o5 MM O A$T L>A:
*$;<
O M* MesesFDom"re
.iempo5 .DE9 O A$<LM*:
;$>N
O *T Meses
C[Medio de Empleados5 M* F *T O S$< 'ersonas
La mayor limitacin del modelo "!sico es %ue no incorpora el efecto de los factores$ como la
e-periencia de los recursos por ejemplo4 %ue influyen so"re el coste ni el mantenimiento del
producto.
.3.2. M'()*' I/,)%6)(-'
El modelo intermedio incorpora *< varia"les de prediccin %ue influyen en el coste del
proyecto.
Estas varia"les se agrupan en cuatro categoras5 atri"utos del producto software$ atri"utos del
ordenador$ atri"utos de personal y atri"utos del proyecto.
9amos a comentar cada uno de ellos.
Pag. 75
.3.2.1. A,%-92,'+ ()* P%'(2&,' S'7,3$%)
RELY 5 )ia"ilidad re%uerida del software.
'odemos definir la fia"ilidad como la pro"a"ilidad de %ue el software realice sus
funciones satisfactoriamente en su pr-ima ejecucin durante un periodo dado de
tiempo. La influencia se clasifica en5 Muy (lto$ (lto$ Cominal$ Kajo y Muy Kajo$ en
funcin del efecto %ue tenga un fallo del producto. 0n rango Muy "ajo$ se usa cuando
el defecto tenga %ue ser eliminado por los desarrolladores pero sin ninguna otra
consecuencia4 cuando haya posi"les p#rdidas de vidas humanas indicaremos un
rango Muy (lto.
DATA : .amao de la "ase de datos.
1eala el tamao y complejidad de la "ase de datos. 1e e-presa mediante la
proporcin5
.amao de la "ase de datos en caracteres
Data O
.amao del programa en D1/
Este par!metro puede tomar los valores Kajo$ Cominal$ (lto y Muy alto$ en funcin de
cuatro segmentos determinados por los ratios5 *;J*;;J*;;;.
CPLR 5 +omplejidad del 'roducto.
Mide la complejidad en funcin de las funciones de control$ c!lculos$ gestin de datos
y operaciones dependientes de dispositivos.
El rango de este par!metro puede variar desde Muy "ajo si el mdulo utili&a
e-presiones matem!ticas simples a E-tra (lto si se emplean varios mdulos con
ejecucin din!mica.
.3.2.2. A,%-92,'+ ()* O%()/$('%
TIME 5 Limitaciones en el .iempo de Ejecucin.
Pag. 76
1e refiere a las limitaciones de uso de ma%uina del producto considerado. 1e e-presa
en t#rminos del porcentaje de tiempo de ejecucin disponi"le %ue se espera sea
usado por el sistema o su"sistema. Es Cominal cuando se usa menos del <;? del
tiempo y E-tra alto cuando se consume el M<?.
STOR 5 Limitaciones de Memoria 'rincipal.
1e e-presa en t#rminos de las restricciones de almacenamiento principal.
El rango vara desde Cominal si se espera una restriccin de memoria de menos del
<;? hasta E-tra alto si la reduccin es del M<?.
FIRT 5 9olatilidad de la Ma%uina 9irtual.
1e entiende por ma%uina virtual el conjunto de hardware y software %ue el producto
utili&a para reali&ar su tarea. Durante el desarrollo esta m!%uina puede sufrir cam"ios.
El rango de su varia"ilidad va desde Kajo hasta Muy (lto$ en funcin de estos
cam"ios.
TURN 5 )recuencia de cam"io en el modelo de e-plotacin del ordenador.
1eala el nivel del tiempo de respuesta e-perimentado por el e%uipo %ue desarrolla el
proyecto.
1e define por el tiempo medio de respuesta en horas desde %ue el desarrollador
introduce un tra"ajo en el ordenador hasta %ue o"tiene los resultados del proceso.
Estos factores han perdido parte de su importancia en los entornos actuales de
desarrollo y e-plotacin ya %ue estas limitaciones se producen slo en el desarrollo de
productos en %ue no es posi"le utili&ar herramientas de productividad o desarrollos en
entornos "atch.
El rango vara desde Kajo para un sistema interactivo hasta Muy (lto cuando el
tiempo de respuesta es mayor de *A horas.
.3.2.3. A,%-92,'+ () P)%+'/$*
ACAP 5 +apacitacin de los (nalistas.
E-presa en t#rminos de percentiles con relacin al conjunto de analistas los
siguientes atri"utos5
. Da"ilidad para el an!lisis.
. Eficiencia y calidad en el tra"ajo.
Pag. 77
. Da"ilidad para comunicarse y cooperar.
1e eval2a su eficiencia tra"ajando en e%uipo. +uanto m!s capa& sea el e%uipo de
analistas$ menor ser! el esfuer&o necesario. El rango de este par!metro puede variar
entre Muy Kajo y Muy (lto.
AERP 5 E-periencia en (plicaciones.
/ndica el nivel de e-periencia en aplicaciones del e%uipo de desarrollo de proyectos.
El rango vara desde Muy Kajo Lmenos de cuatro meses de e-periencia: y Muy (lto
Lm!s de *A aos:.
PCAP 5 +apacitacin de los 'rogramadores.
E-presa similares atri"utos %ue el par!metro (+(' pero para los programadores.
FERP 5 E-periencia en la Ma%uina 9irtual.
Es el tiempo de e-periencia en el entorno Dardware y 1oftware del e%uipo %ue
desarrolla el software. Co se considera el lenguaje de programacin.
Este par!metro puede tomar los valores desde Emuy "ajo= Lsi la e-periencia en la
m!%uina es menor de un mes: hasta Ealto= Lsi es mayor de tres aos:.
LERP 5 E-periencia en el Lenguaje de 'rogramacin.
0n e%uipo de programadores con amplia e-periencia en un lenguaje determinado$
programar! de una forma m!s segura$ disminuyendo incluso el n2mero de errores.
El rango de este par!metro puede variar desde Muy Kajo hasta (lto para un e%uipo
con un mes hasta tres aos de e-periencia.
.3.2.4. A,%-92,'+ ()* P%'0)&,'
MODP 5 'r!cticas Modernas de 'rogramacin.
1eala el grado de utili&acin de practicas modernas de programacin entendiendo
por tal5
(n!lisis de Ie%uisitos y Diseo .opJDown
Diseo Estructurado.
Desarrollo /ncremental.
Ievisiones o /nspecciones de Diseo y +digo.
'rogramacin Estructurada.
Pag. 78
Li"reras de 'rogramas.
1e valorar! el grado de utili&acin de estas pr!cticas desde Muy Kajo hasta Muy (lto.
TOOL : 0so de herramientas para el Desarrollo de 1oftware.
1eala el grado de utili&acin de herramientas en el desarrollo al software.
1e identifican cinco niveles de herramientas5
Derramientas "!sicas de microprocesador.
Derramientas "!sicas de microcomputador.
Derramientas potentes de microcomputador.
Derramientas potentes de ordenador central.
Derramientas avan&adas.
El rango de este par!metro vara entre Muy Kajo cuando slo se usan herramientas
"!sicas$ hasta Muy (lto cuando se usan herramientas de propsito especial como
+(1E L+omputer (ided 1oftware Engineering:.
SCED : Limitaciones en la planificacin.
1e define mediante el porcentaje de retraso o aceleracin con respecto a la
planificacin nominal impuesta al e%uipo de desarrollo.
+ual%uier aceleracin LMuy Kajo: o retraso LMuy (lto: re%uerir! mayor esfuer&o.
.3.2.5. C:*&2*' () *$ E+,-6$&-./ &'/ )* M'()*' I/,)%6)(-'
Estas *< varia"les van a influir so"re la estimacin de esfuer&o calculada. El esfuer&o
calculado se ajusta multiplic!ndolo por el resultado de multiplicar entre s los valores o"tenidos
de las ta"las de atri"utos en funcin de los valores identificados en la definicin del proyecto.
La .a"la S.*. muestra los multiplicadores de esfuer&os$ donde la primera columna muestra las
varia"les y las restantes el multiplicador a considerar para cada rango de valores desde Muy
Kajo hasta E-tra (lto.
9(I/(KLE Muy Kajo Kajo
9(L,IE1
Cominal (lto Muy (lto E-tra alto
Pag. 79
IELB
D(.(
+'LV
./ME
1.,I
9/I.
.0IC
(+('
(EV'
'+('
9EV'
LEV'
M,D'
.,,L
1+ED
;.@<
;.@;
*.TS
*.AM
*.TA
*.A*
*.*T
*.AT
*.AT
*.A>
;.NN
;.MT
;.N<
;.N@
;.N@
*.*M
*.*>
*.*@
*.*;
*.;@
*.*;
*.*;
*.;N
*.;
*.;
*.;
*.;
*.;
*.;
*.;
*.;
*.;
*.;
*.;
*.;
*.;
*.;
*.;
*.*<
*.;N
*.*<
*.**
*.;S
*.*<
*.;@
;.NS
;.M*
;.NS
;.M;
;.M<
;.M*
;.M*
*.;T
*.T;
*.*S
*.>;
*.>;
*.A*
*.>;
*.*<
;.@*
;.NA
;.@;
;.NA
;.N>
*.*;
*.S<
*.SS
*.<S
T$9*$ .1. M2*,-<*-&$('%)+ () )+72)%K'
La estimacin de esfuer&o aplicando este modelo es5
M'(' O%1:/-&': MMO >.A. LZD1/:
*$;<

M'(' S)6-*-9%): MM O >.; LZD1/:
*$*A

M'(' R51-(': MM O A.N LZD1/:
*$A;
El tiempo de desarrollo .DE9 se calcula como en el Modelo K!sico.
EJ)6<*':
Se negocia con la empresa &ompa#a de &omunicaciones )ega"it el precio para desarrollar un
so't*are complejo de +0 ,-S. para un microprocesador comercial.
/l so't*are de comunicaciones genera necesidades de codi'icaci$n de complejidad mu! alta,
pero planeamos utilizar personal mu! capacitado, el cual de"er#a equili"rar la tendencia a
incrementar los costes de"idos a la complejidad.
-eterminar el es'uerzo ! el coste de desarrollo si el precio medio es de 200.000 pesetas
hom"re1mes. 23os 4alores de las 4aria"les de ajuste se darn en 'unci$n del campo Situaci$n de
la ta"la que aparece en la soluci$n.
El esfuer&o lo calcularemos aplicando el Modo ,rg!nico$ puesto %ue el n2mero de lneas de
cdigo no e-cede las <; ZD1/. (s el esfuer&o original ser!5
Pag. 80
MM O >$A V L*;:
*$;<
O >S MM
Los factores de ajuste los calculamos de la siguiente forma5
)actor 1ituacin Iatio Multiplic.
IELB
D(.(
+'LV
./ME
1.,I
9/I.
.0IC
(+('
(EV'
'+('
9EV'
LEV'
M,D'
.,,L
1+ED
5S6 36&73
20.000 89:/S
&6)5;.&7&.6;/S
S/ 5S7<= /3 >0?
@0,1A@,
87S7-6 /; BC
&6)/<&.73
-6S B6<7S )/-.7
85/;6S 7;73.S:7S
:</S 7D6S
85/;6S E<6F<7)7-.
S/.S )/S/S
-6&/ )/S/S
)5&B7S :G&;.&7S
7 ;.H/3 ).&<6
;5/H/ )/S/S
C,M/C(L
K(U,
M0B
(L.,
(L.,
(L.,
C,M/C(L
C,M/C(L
(L.,
C,M/C(L
(L.,
K(U,
C,M/C(L
(L.,
K(U,
C,M/C(L
*.;
;.MT
*.>;
*.**
*.;S
*.;
*.;
;.NS
*.;
;.NS
*.*;
*.;
;.M*
*.*;
*.;
El factor de ajuste se calcula multiplicando todos los valores de los par!metros. En este caso
resulta *$*@.
El esfuer&o final entonces es el siguientes5
MM final O L>SMM:L*$*@: O TA.*A MM O TA MM
El coste de la aplicacin ser!5
'esetas O LTAMM: LA<;.;;; ptsFMM: O *;.<;;.;;;
'ara reducir este coste podramos ajustar los valores de los par!metros. 'or ejemplo$ aumentar
la potencia de los e%uipos$ usar personal m!s e-perimentado$ etc.
Pag. 81
.3.3. M'()*' D),$**$('
El Modelo /ntermedio tiene dos limitaciones %ue pueden ser significativas en la estimacin
detallada de coste en grandes proyectos de software5
La distri"ucin de esfuer&o por fases puede ser inadecuada .
'uede ser muy engorroso utili&arlo en un producto con muchos componentes.
El modelo detallado presenta dos funcionalidades %ue resuelven las limitaciones de +,+,M,
/ntermedio5
*. M2*,-<*-&$('%)+ () )+72)%K' <'% 7$+)+:
En el modelo +,+,M, /ntermedio$ la distri"ucin de esfuer&o por fase se determina
2nicamente por el tamao del producto.
En la pr!ctica$ factores como la fia"ilidad re%uerida$ la e-periencia en aplicaciones y
desarrollos interactivos afectan a unas fases m!s %ue a otras.
El modelo detallado proporciona un conjunto de multiplicadores de esfuer&o para cada atri"uto
en cada fase. Estos multiplicadores determinan el esfuer&o re%uerido para completar cada
fase.
2. D)+&'6<'+-&-./ J)%:%=2-&$ ()* <%'(2&,' $ ,%)+ /-8)*)+.
En el +,+,M, /ntermedio$ los factores de ajuste del coste se calcula"an para distintos
componentes del producto. Este proceso puede ser muy tedioso e innecesariamente repetitivo
si ciertos componentes son agrupados en su"sistemas con pr!cticamente el mismo factor de
ajuste.
El +,+,M, Detallado evita este pro"lema proporcionando una jerar%ui&aron del producto a
tres niveles5
J Civel mdulo.
J Civel su"sistema.
J Civel sistema.
E* N-8)* 6'(2*' se descri"e por el n2mero de instrucciones LD1/: producidas y por
a%uellos factores %ue tienden a modificar dicho nivel5 +omplejidad del mdulo y
adaptacin a partir del software e-istente y de la capacidad y e-periencia de los
programadores %ue desarrollar!n el mdulo en el lenguaje y en la m!%uina virtual.
Pag. 82
E* N-8)* +29+-+,)6$ %ueda descrito por los restantes factores Llimitaciones en tiempo y
memoria$ capacidad de los analistas$ herramientas$ planificacin etc.: %ue tienden a
variar de un su"sistema a otro$ pero %ue son iguales para todos los mdulos dentro de
un su"sistema.
E* N-8)* +-+,)6$ se define mediante los factores correspondientes al conjunto del
proyecto$ como son el esfuer&o nominal y la planificacin de tiempos.
Co se desarrolla este modelo dado %ue su aplicacin %ueda reservada a grandes
proyectos no muy frecuentes. El desarrollo completo de este modelo puede estudiarse
en el li"ro 31oftware Engineering Economics3 de K. Koehm$ editorial 'rentice Dall$
*MN*.
Pag. 83

Ingenieria Del Software - Gestion de Proyectos Informaticos

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Ingenieria Del Software - Gestion de Proyectos Informaticos

Загружено:

Авторское право:

Доступные форматы

Unidad Didctica: Estimacin de Proyectos Software

Вам также может понравиться