estimacia3n de costos y adminis - jones, capers(author)
DESCRIPTION
administracionTRANSCRIPT
-
Estimacin de costos y administracin
de proyectos de software
ACERCA DEL AUTOR
CAPERS JONES es toda una autoridaden el mundo de la
estimacin de costos, medicin,mtricas, productividad
y calidad de software. Dise laprimera herramienta
automatizada de estimacin de costos desoftware de IBM
-
en 1973. Tambin dise lasherramientas comerciales de
estimacin de costos de softwareSPQR20 y Checkpoint.
Fue fundador y presidente del consejode administracin de
Software Productivity Research (SPR),donde an ostenta el
cargo de director cientfi co emrito.Mientras funga como
presidente del consejo deadministracin de SPR, bajo su
mando, la compaa cre
-
KnowledgePlan, herramienta de
estimacin lder del mercado. Joneshabla frecuentemente
en conferencias como IEEE Software,International Function
Point Users Group (IFPUG), ProjectManagement Institute
(PMI), Software Process ImprovementNetwork (SPIN), la
serie de conferencias Computer Aid(CAI) adems de eventos
corporativos locales y de gobierno.Capers Jones fue desig-
-
nado miembro del consejo consultivo deComputer Aid en el
2007. Estimacin de Costos yAdministracin de Proyectos
de Software es su libro nmero 14.
Estimacin de costos y
administracin de proyectos
de software,
Segunda edicin
Capers Jones
Traduccin
-
Juan Carlos Vega Fagoaga
MCSE
Ingeniero en sistemas, ITAM
Instituto Anglo-Mexicano de Cultura
MXICO BOGOT BUENOSAIRES CARACAS GUATEMALA LISBOA MADRID
NUEVA YORK SAN JUAN SANTIAGO AUCKLAND LONDRES MILN MONTREAL
NUEVA DELHI SAN FRANCISCO SO PAULO SINGAPUR SAN LUIS SIDNEY
-
TORONTO
Director editorial: FernandoCastellanos Rodrguez
Editor sponsor: Miguel ngel LunaPonce
Supervisor de produccin: JacquelineBrieo lvarez
Estimacin de costos y administracinde proyectos de software,
Segunda edicin
-
Prohibida la reproduccin total oparcial de esta obra,
por cualquier medio, sin la autorizacinescrita del editor.
DERECHOS RESERVADOS 2008respecto a la primera edicin en espaolpor:
McGRAW-HILL/INTERAMERICANAEDITORES, S.A. DE C.V.
A Subsidiary of The McGraw-HillCompanies, Inc.
Corporativo Punta Santa Fe
Prolongacin Paseo de la Reforma
-
1015, Torre A
Piso 17, Colonia Desarrollo Santa Fe,
Delegacin lvaro Obregn
C.P. 01376, Mxico, D.F.
Miembro de la Cmara Nacional de laIndustria Editorial Mexicana, Reg. Nm.
736
ISBN 13: 978-970-10-6705-5
ISBN 10: 970-10-6705-3
Translated from the 2nd English editionof
-
Estimating Software Costs: BringingRealism to Estimating
By: Capers Jones
Copyright 2007 by The McGraw-HillCompanies. All rights reserved.
ISBN-10: 0-07-148300-4
ISBN-13: 978-0-07-148300-1
2345678901
0976543218
Impreso en Mxico
Printed in Mexico
-
Este libro est dedicado a colegas
que se cuentan entre los pioneros de lamedicin
y estimacin de costos de software:
Al Albrecht, Dr. Barry Boehm, TomDeMarco,
Steve Kan, Larry Putnam, HowardRubin
y Tony Salvaggio
Contenido
Prlogo xv
-
Prefacio xix
Reconocimientos xxv
SECCIN 1 INTRODUCCIN A LAESTIMACIN DE COSTOS
DE
SOFTWARE
Captulo 1. Introduccin
3
Cmo funcionan las herramientas deestimacin de costos de software?
4
-
Advertencias sobre omisionesaccidentales en las estimaciones
15
Estimacin de costos de software yotras actividades de desarrollo
17
Bibliografa
20
Captulo 2. Orgenes de la estimacinde costos de software
23
-
Historia de la estimacin de costos desoftware
24
Expansin y uso de mtricasfuncionales para la estimacin
de costos de software
28
Bibliografa
32
Captulo 3. Seis formas para estimarcostos de software
-
33
Descripcin de mtodos manuales paraestimar costos de software
34
Descripcin de mtodosautomatizados para estimar costos desoftware
36
Comparacin de estimacionesmanuales y automatizadas paragrandes
proyectos de software
-
48
Bibliografa
49
Captulo 4. Herramientas para laestimacin de costos de software
e ndices de xito y fracaso deproyectos
53
Probabilidades de xito o fracaso deproyectos de software
55
-
Bibliografa
59
vii
viii Contenido
Captulo 5. Fuentes de error en laestimacin de costos de software
61
Cmo juzgar la exactitud de lasestimaciones de costos de software
65
Clases de errores en la estimacin de
-
costos de software
68
Bibliografa
86
SECCIN 2 MTODOS DEESTIMACIN PRELIMINAR
Captulo 6. Mtodos manuales deestimacin de costos de software
91
Mtodos prcticos basados enmtricas de lneas de cdigo
-
92
Mtodos prcticos basados enproporciones y porcentajes
95
Mtodos prcticos basados enmtricas de puntos funcin
99
Mtodos prcticos para predecir eltamao de puntos funcin
102
Mtodos prcticos para fechas lmite,recursos y costos
-
117
Mtodos prcticos utilizando elanlisis de costos basado enactividades
121
Resumen y conclusiones
127
Bibliografa
128
Captulo 7. Mtodos de estimacinmanual derivados de proyectos
-
Agile y nuevos entornos
131
Mtricas utilizadas en mtodosprcticos
135
Mtodos prcticos para estimacionesmanuales de costos de software
140
Desarrollo basado en componentes
143
Mtodo de desarrollo dinmico de
-
sistemas (DSDM)
146
Implementacin de planeacin derecursos empresariales (ERP)
148
Programacin extrema (XP)
152
Subcontratacin internacional
155
Desarrollo orientado a objetos (OO)
-
159
Modelo de capacidad para madurez(CMM)
162
Mtodos de software slo con mtodosprcticos parciales
167
Desarrollo sala limpia
167
Enfoque de desarrollo Crystal
168
-
Desarrollo basado en caractersticas(FDD)
168
Estndares de calidad ISO 9000-9004
169
Desarrollo iterativo o incremental
169
Desarrollo de software basado enpatrones
171
Implementacin de funciones de
-
calidad (QFD)
174
Desarrollo rpido de aplicaciones(RAD)
175
Lneas cerradas
176
Seis sigma para software
177
Desarrollo de software en espiral
-
179
Lenguaje unifi cado de modelado(UML)
180
Casos de uso para requisitos desoftware
181
Aplicaciones basadas en la Web
183
Resumen y conclusiones
185
-
Bibliografa
185
Contenido ix
Captulo 8. Estimacionesautomatizadas a partir de datosmnimos
189
Etapa 1: Registro de informacinadministrativa e informacin delproyecto
190
Etapa 2: Prediccin de tamao
-
preliminar de entregables clave
203
Etapa 3: Produccin de unaestimacin de costos preliminar
219
Resumen y conclusiones
224
Bibliografa
225
SECCIN 3 PREDICCIN DELTAMAO DE ENTREGABLES DE
-
SOFTWARE
Captulo 9. Prediccin del tamao deentregables de software
229
Lgica general para predecir eltamao de entregables de software
229
Mtodos de prediccin de tamao enel 2007
230
Coincidencia de patrones a partir dedatos histricos
-
232
Uso de datos histricos para predecirel crecimiento de requisitos
233
Intentos matemticos o estadsticospara extrapolar el tamao a partir
de requisitos parciales
234
Mtodos prcticos arbitrarios paraagregar factores de contingencia
235
-
Congelacin de requisitos en puntos fijos en el tiempo
236
Produccin de estimaciones de costosformales slo para subconjuntos
de la aplicacin total
237
Volumen de datos de puntos funcinentregable
245
Anlisis de complejidad de software
-
247
Prediccin de tamao de software concomponentes reutilizables
258
Descripcin de las formas bsicas demtricas para predecir el tamao
del
software
260
Prediccin del tamao de cdigofuente
-
269
Prediccin de tamao de proyectos desoftware orientado a objetos
275
Prediccin de tamao de documentosen papel basados en texto
277
Prediccin de tamao de grfi cos eilustraciones
283
Prediccin de tamao de errores decdigo o defectos
-
286
Prediccin de tamao de casos deprueba
293
Horizonte de eventos para predecirtamao de artefactos de software
295
Lo que se sabe como resultado depredecir el tamao de proyectos
de
software
-
297
Fortalezas y debilidades de lasmtricas de tamao de software
299
Resumen y conclusiones
301
Bibliografa
302
SECCIN 4 FACTORES DEAJUSTE EN LA ESTIMACIN DECOSTOS
-
Captulo 10. Compensacin y ajustesen patrones de trabajo
307
Mtodos de ajuste manual yautomatizado
308
Exclusiones de estimaciones normalesde costos de software
312
Cmo establecer las condicionesiniciales para una estimacin de costos
313
-
Variaciones en ndices de carga ocostos adicionales
316
Variaciones en hbitos de trabajo ytiempo extra no pagado
319
Bibliografa
324
x Contenido
Captulo 11. Factores de ajuste enpatrones de actividad
-
325
Veinticinco actividades comunes paraproyectos de software
326
Bibliografa
332
Captulo 12. Factores de ajuste a latecnologa de software
335
Factores de ajuste y herramientas demacroestimacin
-
336
Factores que infl uyen laproductividad del desarrollo desoftware
340
Factores que infl uyen laproductividad del mantenimiento desoftware
343
Patrones de factores positivos ynegativos
345
-
Factores de ajuste y herramientas demicroestimacin
347
Bibliografa
362
SECCIN 5 ESTIMACIN DECOSTO DE SOFTWARE BASADA
EN ACTIVIDADES
Captulo 13. Estimacin de requisitosde software
367
-
Puntos funcin y requisitos desoftware
374
Temas primarios para requisitos desoftware
381
Temas secundarios para requisitos desoftware
382
Factores de ajuste de requisitospositivos y negativos
382
-
Requisitos y software de usuario fi nal
386
Requisitos y aplicaciones Agile
386
Requisitos y proyectos de sistemas deinformacin administrativa (MIS)
386
Requisitos y proyectos subcontratados
387
Requisitos y software de sistema
-
387
Requisitos y software comercial
388
Requisitos y proyectos de softwaremilitar
389
Requisitos y aplicaciones basadas enla Web
389
Evaluacin de combinaciones defactores de requisitos
-
390
Bibliografa
393
Captulo 14. Estimacin de prototiposde software
395
Prototipos desechables
398
Prototipos de cuadros de tiempo
398
-
Prototipos evolutivos
399
Valores predeterminados para estimarprototipos desechables
402
Factores positivos y negativos influyendo prototipos de software
404
Bibliografa
407
Captulo 15. Estimacin de especifi
-
caciones y diseo de software
409
Factores de ajuste de diseo positivos
414
Factores de ajuste de diseonegativos
415
Bibliografa
418
Contenido xi
-
Captulo 16. Estimacin deinspecciones de diseo
421
Literatura de inspeccin
421
Proceso de inspeccin
423
Valor de las inspecciones
426
Bibliografa
-
433
Captulo 17. Estimacin deprogramacin o codifi cacin
435
Impacto de la posibilidad dereutilizacin en programacin
442
Impacto de la experiencia enprogramacin
444
Impacto de errores de cdigo oerrores comunes en programacin
-
444
Impacto del tiempo extra no pagadoen programacin
446
Impacto de los requisitos en aumentoen programacin
448
Impacto de la estructura ycomplejidad del cdigo enprogramacin
449
Impacto de interrupciones no
-
planeadas en programacin
450
Impacto del tamao de lasaplicaciones en programacin
451
Impacto del espacio de ofi cina yergonoma en programacin
452
Impacto de las herramientas enprogramacin
454
-
Impacto de los lenguajes enprogramacin
455
Impacto de la presin de las fechaslmite en programacin
459
Bibliografa
459
Captulo 18. Estimacin deinspecciones de cdigo
461
-
Literatura de inspeccin de cdigo
461
Efectividad de inspecciones de cdigo
462
Consideraciones para estimarinspecciones de cdigo
466
Bibliografa
470
Captulo 19. Estimacin del control deconfi guracin de software
-
y administracin del cambio
471
Literatura sobre administracin delcambio
473
Medicin del cambio en software
475
Cambios en los requisitos del usuario
479
Cambios en especifi caciones y diseo
-
480
Cambios por errores de cdigo oreportes de defectos
481
Resumen y conclusiones
482
Bibliografa
483
Captulo 20. Estimacin de pruebas desoftware
485
-
Formas generales de prueba desoftware
491
Formas especializadas de prueba desoftware
495
Formas de prueba implicando ausuarios o clientes
498
Nmero de etapas de prueba
499
-
Variaciones en patrones de prueba porindustria y tipo de software
501
Variaciones en patrones de prueba portamao de la aplicacin
503
Etapas de prueba observadas enjuicios legales alegando mala calidad
504
Uso de puntos funcin para estimarvolmenes de casos de prueba
505
-
xii Contenido
Uso de puntos funcin para estimarnmero de empleados realizandopruebas
507
Pruebas y niveles de efi ciencia en laeliminacin de defectos
508
Uso de puntos funcin para estimaresfuerzo y costos de pruebas
510
Pruebas realizadas por
-
programadores o personal de pruebasprofesional
512
Cobertura de casos de prueba
514
Factores que afectan el rendimientode las pruebas
514
Bibliografa
515
Captulo 21. Estimacin de la
-
documentacin del usuario y elproyecto
519
Estimacin de la documentacin deherramientas y software
521
Cuantifi cacin de nmero y tamaosde tipos de documentos de software
523
Herramientas de documentacin desoftware en proyectos retrasados
y
-
avanzados
527
Bibliografa
529
Captulo 22. Estimacin de laadministracin de proyectos desoftware
531
Funciones de la administracin deproyectos de software
535
-
Gerentes de proyectos tambincontribuyentes tcnicos
537
Administracin de proyectos hbridosimplicando hardware y software
538
Administracin de proyectos ypresiones de tiempos lmite externas
538
Herramientas para administracin deproyectos
539
-
Administracin de proyectos ensistemas grandes con muchos gerentes
542
Divisin del tiempo o manejo de variosproyectos de forma simultnea
544
mbito del control o nmero deempleados por gerente
545
Manejo de grupos con ocupacionesmltiples
546
-
Presencia o ausencia de ofi cinas deproyectos para sistemas grandes
548
Niveles de experiencia de gerentes deproyectos de software
549
Mtodos de control de calidadseleccionados por gerentes deproyectos
550
Gerentes de proyectos y mtricas
551
-
Resumen de hallazgos enadministracin de proyectos
551
Bibliografa
551
SECCIN 6 ESTIMACIN DECOSTOS DE MANTENIMIENTO YMEJORAS
Captulo 23. Estimacin de costos demantenimiento y mejoras
557
Valores predeterminados nominales
-
para actividades de mantenimiento ymejora
562
Mtricas y problemas de medicin conproyectos de mantenimiento pequeos
566
Las mejores y peores prcticas enmantenimiento de software
567
Entropa y costo total de propiedad desoftware
570
-
Instalacin de nuevas versiones yparches de fabricantes de software
572
Mejoras mayores
573
Mejoras menores
574
Mantenimiento (reparaciones dedefectos)
576
Reparaciones por garanta
-
581
Soporte al cliente
581
Economa de mdulos propensos aerrores
582
Contenido xiii
Cambios obligatorios
584
Anlisis de complejidad
-
585
Reestructuracin y refactoraje decdigo
586
Optimizacin de rendimiento
588
Migracin a travs de plataformas
588
Conversin a nuevas arquitecturas
589
-
Ingeniera inversa
589
Reingeniera
590
Eliminacin de cdigo inservible
590
Eliminacin de aplicaciones noutilizadas
591
Nacionalizacin
-
591
Proyectos de actualizacin masiva
592
Retiro de aplicaciones
593
Servicio de campo
594
Combinaciones y operaciones demantenimiento concurrentes
594
-
Bibliografa
599
Captulo 24. Aspectos de investigacinen la estimacin de costos
de
software
603
Conversin de mtricas
604
Prediccin automtica del tamao apartir de requisitos del usuario
-
606
Costos basados en actividad deproyectos Agile, orientados a objetos
y basados en la Web
608
Anlisis de complejidad deaplicaciones de software
610
Anlisis de valor de aplicaciones desoftware
611
-
Anlisis de riesgos y estimaciones decostos de software
613
Inclusin de especialistas enestimaciones de costos de software
615
Anlisis de reutilizacin yestimaciones de costos de software
617
Estimacin de mejoras en procesos
622
-
Anlisis de metodologa y estimacinde costos de software
625
Resumen y conclusiones acerca de lainvestigacin de estimacin
de costos de software
629
ndice
631
Prlogo
Una vez, mientras analizaba un proyecto
-
retrasado por varios meses, un ejecutivoperplejo hizo una observacin cadaproyecto que abordamos llega tarde.
Dirigindose a su agazapado director desistemas de informacin, le dijo conenojo,
Te damos tiempos lmite razonables deentrada! Por qu no puedescumplirlos?
Una mirada conocida pas entre eldirector de sistemas de informacin ycierto consultor cuyo nombre nomencionaremos. Fijar la fecha antes deestablecer los requisitos es el problemams antiguo en la literatura de software,pero el director de sistemas de
-
informacin no tena credibilidadcuando prometa diferentes fechas, yaque careca de un elementoindispensable para exigir respeto de sussuperiores: un proceso de estimacin desoftware bien definido, consistentementeaplicado y rigurosamente ejecutado.
En sus primeros 50 aos, el negocio deldesarrollo de software adquiri unareputacin notoria por tiempos lmitefuera de control, elevaciones de costosmasivas y un control de calidadimperceptible. La estimacin,planeacin y administracin de lacalidad de los proyectos eran confrecuencia tan primitivas y fortuitas quela mayora de los proyectos de
-
desarrollo de software grandesterminaban tarde, excediendo ademssus presupuestos originales. De hecho,muchos de estos proyectos erancancelados antes de siquieracompletarse, comnmente despus demalgastar enormes cantidades derecursos humanos y financieros.
Desde luego, los peores casos defracasos en proyectos (fiascos realmentegrandes) a menudo eran encubiertos porlas organizaciones, ya que elconocimiento pblico de los peoresfracasos afectara severamente el valorde mercado y la percepcin pblica decompaas, en su defecto, exitosas.
-
Naturalmente, cada proyecto tena supropia historia, pero pareca correr unhilo comn a travs de los peores casos.La mayora de los excesos y fracasos enla entrega estaban basados enestimaciones descuidadas, arbitrariasy/o demasiado optimistas de costos;esfuerzo y duracin creadosgeneralmente con tcnicas de estimacinmanual improvisadas. Desde el inicio dela estimacin de costos de software, elenfoque de improvisacin ha sidoinmensamente popular y, como xv
xvi Prlogo
sola decir el comediante en una antiguarutina de cabaret, Nos ha perseguido
-
desde entonces.
Al principio, era bastante sencilloestimar el tamao anticipado deaplicaciones de software, pues losescasos lenguajes de programacin eranmuy similares asemejando mucho lasinstrucciones de mquina reales.
En este sentido, forma y funcin eran, sibien slo por un tiempo corto, casiidnticas. De forma similar, laproductividad de programadoresindividuales era razonablemente fcil depredecir y sola expresarse comolneas de cdigo por mes. De estemodo, un gerente de proyectos podaformular una estimacin aproximada
-
(en una pieza de papel), dividiendo eltamao total estimado entre laproductividad media, produciendo conello un estimado del nmero de mesesnecesarios para escribir el cdigo.
En la actualidad, cuando la codificacinpuede consumir slo 5% del ciclo devida de un proyecto de software, estastcnicas de estimacin primitivasparecen casi cmicas. No obstante, enmuchas organizaciones el procesofunciona casi de la misma forma que lohaca 50 aos atrs. En realidad, en unapieza de papel es tan slo una formacordial para decir improvisado y,desde un estudio ocasional de aumentosen costos y tiempos lmite, podra
-
decirse que el mtodo improvisado yaest un poco gastado.
Sera un gran alivio decir que todo esoha cambiado en estos das de escla-recimiento, marcado por herramientasde desarrollo fenomenales, aplicacionesempresariales comerciales que hacentodo bien, desde que se instalan (bueno,casi), samuris seis sigma cinturnnegro y expertos en mejora de procesos,con guas ampliamente documentadas.Todo tendra que ser mucho mejor ahora.Sin embargo, si hemos de pronosticar, esprobable que dentro de 50 aos an sediga que en su infancia (y ahora en supresunta adolescencia), la industria delsoftware fue notable por su necedad y
-
casi completamente exitosa resistencia acualquier cosa, como disciplinas deingeniera estndar, incluida laparticularmente rigurosa, calibracinrepetida, medicin y estimacin.
Por fortuna, ha habido voces valientesen la jungla del software a travs de losaos, quienes estudiaron y buscaronremediar el problema bsico de unaestimacin deficiente de proyectos desoftware. Capers Jones, fundador ydirector cient-
fico de Software Productivity Research,LLC (SPR), es quiz el msampliamente publicado y ledo de estereducido grupo de pioneros
-
apasionados. De su trabajo inicial enlingstica y dinmica de lenguajes deprogramacin, hasta el desarrollo de unalnea altamente exitosa de modeloscomerciales de estimacin paramtrica,incluido el sistema actual SPRKnowledgePlan, Jones se ha avocadoconsistentemente a un proceso deestimacin de costos de softwareformalizado.
En 1998, Jones public la primeraedicin de Estimacin de costos yadministracin de proyectos desoftware, que estudiaba ampliamente lahistoria de la estimacin de costos desoftware, adems de toda la gama deherramientas y tcnicas de estimacin
-
disponibles para gerentes de proyectosen ese entonces.
Con esta segunda edicin revisadaactual, extiende el mbito de su estudiopara incluir observaciones ycomentarios acerca del estado actual dela estimacin, en Prlogo xvii
numerosos y nuevos puestos deavanzada en el paisaje del desarrollo desoftware, incluidos programacinextrema, mtodos Agile, y solucionesERP y COTS an ms extensas.
Adems, Jones proporciona los datosms recientes de la investigacin deSRP
-
en torno a sinnmero de factoresafectando la estimacin de proyectos.
Jones contina argumentando que lasorganizaciones deben abandonar el
concepto de la estimacin del softwarecomo una aplicacin lineal de principiosindustriales. Su tesis central es que eldesarrollo de software exitoso no essimple cuestin de empatar un nmerode personas con otro de unidades detrabajo, para lograr presupuestos ytiempos lmite arbitrarios, enfoque quecontina conllevando al fenmeno delproyecto interminable, en su defectoconocido como la marcha de lamuerte, el descarrilamiento del tren o
-
el hoyo negro. (Con frecuencia, steconduce tambin a contratar un nuevodirector de sistemas de informacin).Capers Jones nos recuerda que elproceso de software mismo sigueexcepcionalmente orientado a laspersonas y es un tanto cuanto resistente ala influencia de tecnologas nuevas ymejores. El autor seala queherramientas y metodologas en francoavance, han tendido en realidad amejorar la productividad con el paso deltiempo, pero los costos no siempre sehan reducido de manera proporcional ylas personas trabajando en un proyecto(sus habilidades, percepcin e inclusosentimientos) an pueden ser lo msimportante. De alguna forma, las
-
estimaciones deben tomar esto encuenta.
El problema con una estimacindeficiente sigue siendo el optimismoexcesivo, inducido principalmente pormtodos deficientes y expectativasarbitrarias. Sin embargo, la mayor partede la estimacin de costos de softwaresiguen realizndola gerentes de proyectotrabajando con mtodos primitivoshechos en casa.
Algunos exitosos, pero la presenciaperenne de costos excesivos, retrasos entiempos lmite y proyectos canceladosen todas las industrias, sugiere que lamayora no lo son. Algo necesita
-
cambiar, y Capers Jones argumenta demanera efectiva que mtodos deestimacin formales y rigurosos (ascomo el compromiso institucionalinvolucrado en su uso) son los agentesnecesarios de este cambio.
Doug Brindley
Presidente de Software ProductivityResearch LLC
Prefacio
En los 10 aos transcurridos entre laprimera y segunda ediciones de estelibro, muchos cambios han ocurrido enla industria de las computadoras, ascomo en la tecnologa de la estimacin
-
de costos de software.
Han aparecido ms de 20 nuevasmetodologas de desarrollo, incluidascerca de una docena de tipos dedesarrollo Agile. Los mtodosorientados a objetos (OO) crecen enpopularidad. Casos de uso y lenguaje demodelos unificado (UML) se han unido amtodos de diseo de software mspopulares. El Software EngineeringInstitute ha dado a conocer la nuevaintegracin del modelo de madurez decapacidades (CMMI). Todos estosenfoques se utilizan en proyectos desoftware en que son importantesestimaciones de costos y tiempo lmitepreciso.
-
Algunos de estos mtodos nuevos hancreado a su vez mtricas recientes paraestimacin y medicin. De este modo, enel 2007, tal vez los gerentes deproyectos de software deban entender noslo lneas de cdigo y mtricas depuntos funcin, sino puntos funcincsmicos, puntos funcin de ingeniera,puntos de objeto, puntos de historia,puntos de objetos Web, puntos de casosde uso y quiz otros 30.
Sin embargo, tales mtricas de recienteaparicin siguen siendo experimentalesy carecen de grandes volmenes dedatos histricos. Las mtricas de puntosfuncin estndar se han utilizado paramedir ms de 25 000 proyectos de
-
software. Hasta donde se puededeterminar, todas las otras mtricasjuntas, se han usado para medir menosde 300 proyectos o quiz 10 proyectospor mtrica.
Asimismo se ha realizado muchainvestigacin de mtodos de estimaciny
respecto a las razones de ser paraaqullas imprecisas. Aunque los erroresen las estimaciones siguen siendocomunes, ahora conocemos las causasprimarias de estos errores. Existencuatro de ellas:
Los proyectos de software crecen auna tasa aproximada de 2% por mes
-
durante su desarrollo
Nmeros excesivos de errores decdigo o defectos alteran tiempos lmitede prueba
xix
xx Prefacio
La produccin de documentos enpapel a menudo cuesta ms que elcdigo fuente
Existe la posibilidad de queestimaciones precisas seanreemplazadas arbitrariamente porestimaciones optimistas
-
Ahora que conocemos las fuentesprincipales de errores en lasestimaciones de costos de software,podemos comenzar a controlarlas. Lastres fuentes tcnicas principales deerrores en la estimacin de costos desoftware suelen eliminarse de lasestimaciones. Pero la cuarta fuente deerror, el reemplazo de estimacionesprecisas con estimaciones optimistas,sigue dando problemas.
Una vez creadas, las estimaciones decostos de software deben ser aprobadaspor los clientes para quienes se crea elproyecto de software y algunas vecestambin por personal administrativo dems alto nivel. Cuando los clientes o
-
personal administrativo de nivelsuperior enfrentan necesidades denegocios urgentes, existe una tendenciamarcada a su rechazo de estimacionesde costos precisas.
Ello se debe a que la construccin deaplicaciones de software grandes ocomplejas, an consume mucho tiempo yes costosa.
As, en vez de iniciar un proyecto desoftware con una verdadera estimacindel costo basada en el equipo de trabajoy las capacidades tcnicas, muchosproyectos de software se ven forzados amanejar fechas de negocios externascomo fechas lmite. Tambin se ven
-
forzados a emplear presupuestos msbajos que lo indispensable para incluirtodas las funciones precisas. stos sonaspectos sociolgicos y difciles deresolver.
La mejor solucin para evitar elreemplazo de estimaciones precisasconsiste en dar soporte a la estimacincon datos histricos de proyectossimilares. Si la historia prueba que untipo de proyecto especfico nunca se hadesarrollado en menos tiempo o a uncosto ms bajo que la estimacin decosto formal, es probable que laestimacin sea rechazada y sustituida.Ello significa que el uso de pruebas dereferencia o la recopilacin de datos
-
histricos consistentes, actuaran comoprecursor importante de estimacionesprecisas.
La recopilacin de datos histricos, aligual que el diseo y construccin deherramientas para estimar el costo delsoftware, han sido mis ocupacionesprincipales desde 1971. Mi trabajo entorno a las estimaciones dio inicio enIBM, cuando nos pidieron a un colega ya m reunir datos acerca de los factoresafectando los costos de software.
Despus de dedicar un ao a reunirdatos de costos en IBM y revisarliteratura externa sobre costos desoftware, pareca posible construir una
-
herramienta de estimacin automatizada,basada en reglas para predecir esfuerzo,tiempos lmite y costos de lasactividades principales de proyectos dedesarrollo de software para sistemas deIBM; es decir, requisitos, diseo,revisiones de diseos, codificacin,inspecciones de cdigo, pruebas,documentacin del usuario yadministracin de proyectos.
Se entreg una propuesta a laadministracin senior de IBM parafondear el desarrollo de una herramientapara estimar costos de software. Lapropuesta Prefacio xxi
fue aceptada y los trabajos se iniciaron
-
en 1972. De all en adelante, hediseado y construido una docena deherramientas para estimar costos desoftware para compaas individuales oel mercado de soluciones de estimacincomercial. El objetivo de este libro esmostrar algunos de los tipos deinformacin necesarios para construirmodelos de costo de software ypresentar una perspectiva interna delnegocio de la estimacin de costos.
El libro intenta abarcar aspectosfundamentales implicados en laestimacin de costos de software. Otrosespecialistas en estimaciones y mtricashan contribuido con ideas e informaciny los menciono en varias ocasiones.
-
Analizamos el trabajo de estos otrosespecialistas en estimaciones comoAllan Albrecht, el Dr. Barry Boehm,Frank Freiman, Don Galorath, el Dr.Randall Jensen, Steve McConnell, LarryPutnam, el Dr. Howard Rubin y CharlesSymons, aunque como competidores, amenudo no compartimos informacin depropietario.
Segn mi punto de vista, adems de miscompetidores, la estimacin precisa decostos de software es importante para laeconoma global. Todo gerente deproyectos de software, especialista encontrol de la calidad del software,ingenieros de software, analistas desistemas y programadores deben
-
entender los conceptos bsicos de laestimacin de costos de software. stees un punto de vista que compartimostodos los fabricantes de solucionescomerciales para la estimacin decostos de software.
Los que estamos en el negocio de laestimacin de costos de softwareconocemos docenas de algoritmos deestimacin manual. En el negocio de laestimacin de costos usamos mtodos deestimacin manual, de cuando encuando, en proyectos pequeos; peroninguno de nosotros considera que losmtodos de estimacin manual seansuficientes para el manejo deestimaciones del ciclo de vida completo
-
de proyectos de software importantes. Sibastaran los mtodos manuales, noexistiran las herramientas comercialespara estimar de costos de software.
Es un fenmeno interesante que lamayora de los excesos importantes ydesastres del software, estn sustentadosen estimaciones de costos descuidadas yen extremo optimistas que,generalmente, se realizan de formamanual. Los proyectos recurriendo aherramientas de estimacin formales,como las herramientas de lacompetencia, COCOMO II, GECOMO,SLIM, PRICE-S, ProQMS, SEER,
SoftCost o de mi compaa (SPQR/20,
-
CHECKPOINT o KnowledgePlan),suelen
tener mejores registros de permanenciadentro de sus presupuestos y de terminarcon realidad el proyecto, sincontratiempos graves.
La razn por la que fracasan losmtodos de estimacin manual consistemas grandes, se puede expresar enuna palabra: complejidad. Existencientos de factores determinando elresultado de un proyecto de software yno es posible sortear las combinacionesde estos factores empleando algoritmossimples y mtodos manuales.
Este libro ilustra los tipos de problemas
-
de estimacin complejos que activaronla creacin de industrias de lasherramientas de estimacin de costos yadministracin de proyectos desoftware. Los problemas de lasestimaciones en sistemas grandes son elmotivo principal de preocupacin,aunque tambin se analizan mtodos deestimacin para proyectos pequeos.
xxii Prefacio
La estimacin no es la nica funcin deadministracin de proyectos que tieneahora soporte automatizado. En el librotambin intentamos poner el tema de lasherramientas de estimacin en contexto,respecto a otros tipos de herramientas
-
de administracin de proyectos ysealar brechas donde se necesita otrotipo de herramientas.
Las herramientas de estimacin decostos de software son ahora parte deuna suite de herramientas deadministracin de proyectos de softwareincluyendo estimacin de costos, decalidad, planeacin de tiempos lmite(conocida a menudo comoadministracin de proyectos),administracin de metodologas oprocesos, anlisis de riesgos,presupuestos departamentales,seguimiento de hechos trascendentales,reportes de costos y anlisis devariancia.
-
Estas herramientas independientes anno han alcanzado el nivel de integra-cin avanzada e imperceptible, logradaen el dominio de procesadores depalabras aunados a hojas de clculo,bases de datos y herramientas grficas,pero ese nivel de integracin sevislumbra en el horizonte.
Como la estimacin de costos desoftware es una actividad muy complejaen que intervienen mltiples factores ycientos de ajustes, este libro tiene unaestructura bastante compleja. Se divideen seis secciones principales y 24captulos individuales.
La Seccin 1 incluye una introduccin al
-
tema de la estimacin de costos desoftware y un estudio de caractersticasde las herramientas para estimacin decostos de software. Asimismo, laSeccin 1 abarca aspectos de negociosde la administracin de proyectos desoftware, como cul es el costoprobable de las herramientas y qu tipode valor crean. La Seccin 1 asume queel lector no posee conocimientosprevios del tema.
La Seccin 2 aborda varios mtodospara crear estimaciones tempranas,mucho antes de entender por completolos requisitos de un proyecto. Laestimacin temprana a partir deconocimientos parciales es una de las
-
formas ms difciles de estimacin y, noobstante, de las ms importantes. Muy amenudo, las estimaciones tempranasterminan grabadas en piedra o seconvierten en la estimacin oficial de unproyecto de software.
Esta seccin analiza mtodos deestimacin manual empleando mtodosprc-
ticos y los mtodos de estimacinpreliminar, ligeramente ms avanzadosque ofrecen herramientas comerciales deestimacin de costos de software.
La Seccin 3 aborda mtodos parapredecir el tamao de diversosartefactos de software. Todas las
-
herramientas comerciales de estimacinde costos de software necesitan algunaforma de informacin sobre tamao paraoperar y existe un nmerosorprendentemente grande de formaspara manejar tamao.
Mientras escriba este libro, laprediccin del tamao basada enmtricas de puntos funcin era elsistema dominante en el mundo desoluciones de estimacin de costos desoftware; pero la prediccin del tamaobasada en lneas de cdigo y materialesmenos tangibles, tambin es unaposibilidad. Existen a su vez algunasnuevas mtricas experimentales comopuntos de casos de uso y
-
puntos de objetos. Sin embargo, stasson primordialmente experimentalesPrefacio xxiii
y carecen de cantidades significativas dedatos histricos. Existen tambinmtricas especializadas en el dominioorientado a objetos. Aunque soninteresantes y tiles para proyectosorientados a objetos (OO), las mtricasOO especializadas no pueden usarsepara comparaciones integrales entreproyectos orientados a objetos yproyectos convencionales.
La Seccin 4 aborda la forma en que lasherramientas para estimacin de costosde software manejan factores de ajuste.
-
Existen ms de 100 factores conocidosque pueden influir los resultados deproyectos de software, incluidas lascapacidades del equipo de trabajo,presencia o ausencia de tiempo extra,metodologas y herramientas empleadas,incluso el espacio de oficina y laergonoma.
Aunque las herramientas comercialespara estimacin de costos de softwareofrecen valores predeterminados paramuchos temas importantes, los rangos deincertidumbre son tan grandes que seaconseja a los usuarios reemplazarpromedios genricos de la industriacon valores especficos de susempresas, para parmetros clave, como
-
niveles de salario promedio, ndices decarga, niveles de experiencia delpersonal y otros factores que impactenlos resultados finales.
La Seccin 5 tiene que ver conprincipios de estimacin de costosderivada de actividades, para 10 que serealizan con ms frecuencia en muchosproyectos de software:
Recopilacin y anlisis de requisitos
Creacin de prototipos
Especifi caciones y diseo
Inspecciones de diseo formales
-
Codifi cacin
Inspecciones de cdigo formales
Administracin del cambio o controlde confi guracin
Documentacin del usuario
Pruebas
Administracin de proyectos
Desde luego, existen ms de 10actividades, pero las seleccionamosporque se realizan con mayor frecuenciaen muchos proyectos de software. Amenos que las estimaciones de estas 10actividades sean precisas, existe poca
-
esperanza de precisin en el nivel deproyectos en bruto.
La Seccin 6 aborda principios de laestimacin de costos, a partir de 21tipos de actividades de mantenimiento ymejora. La estimacin delmantenimiento es mucho ms complejaque la de desarrollo, pues antigedad yestructura de la aplicacin de base tieneun impacto severo.
Existen tambin varios tipos muyespecializados de estimacin de costosdel mantenimiento que pueden ser muycostosos cuando se presentan, pero no lohacen con frecuencia (eliminacin demdulos propensos a errores, servicio
-
de xxiv Prefacio
campo y manejo de defectosexpectantes, ocurrentes cuando unusuario ejecuta una aplicacin, pero nopuede duplicarse en la instalacin dereparaciones de mantenimiento). LaSeccin 6 analiza tambin varias nuevasformas de mantenimiento muy costosas(fechas especiales, expansin delnmero de dgitos en nmeros detelfono, cambio del horario de verano yproblemas similares afectando cientosde aplicaciones).
Capers Jones
Reconocimientos
-
Como siempre, agradezco a mi esposa,Eileen Jones, por hacer este libroposible en muchas formas. Ella seencarga de todos nuestros contratos coneditoriales y ahora conoce los detallesde estos contratos tan bien como algunosabogados.
Agradezco tambin su paciencia cuandome sumerjo en la escritura ydesaparezco en nuestra sala de cmputo.Agradezco por igual su paciencia endas festivos y vacaciones, cuando llevoconmigo mi computadora porttil.
Deseo externar mi aprecio a MichaelBragen, Doug Brindley y PeterKatsoulas de Software Productivity
-
Research LLC. Doug, Michael y Petercontinan desarrollando y refinandoherramientas basadas en algunos de misalgoritmos de estimacin. Gracias aChas Douglis por su ayuda durantemuchos aos.
Tambin deseo externar mi aprecio aCharles Douglis y Mark Pinis por su
diseo de la herramienta de estimacinKnowledgePlan de SPR.
Gracias a Tony Salvaggio y a MichaelMilutis de ComputerAid, por proporcio-narme muchas oportunidades paraanalizar temas de estimacin y pruebasde referencia con sus clientes y colegas.Gracias tambin por su inters al
-
publicar mis reportes en su sitio Web.
Externo mi aprecio a cientos de colegasmiembros del International FunctionPoint Users Group (IFPUG). Sin IFPUGy la serie de proyectos siempre en
aumento, medidos utilizando puntosfuncin, la tecnologa de estimacin nohabra alcanzado su nivel actual derendimiento.
Expreso mi agradecimiento a DaveShough, colega de IBM, quien me ayuda
recopilar datos para mi primeraherramienta de estimacin. Graciastambin al Dr. Charles Turk, otro colega
-
de IBM y experto de clase mundial enAPL, quien construy la primeraherramienta de estimacin que yodise. Debo mi aprecio al finado TedClimis de IBM, quien patrocin muchade mi investigacin sobre costos desoftware.
Debo un especial aprecio a Jim Frame,quien falleci en octubre de 1997, justocuando se terminaba la primera edicinde este manuscrito. Jim fue director delos Laboratorios de Lenguajes yRecursos de Datos de IBM ypatrocinador inme-xxv
xxvi Reconocimientos
diato de mis primeros estudios sobre
-
estimacin de costos de software. Jimfue despus vicepresidente deprogramacin de ITT, donde dio soportetambin a la investigacin sobreestimacin de costos de software.
La industria del software perdi a unafigura importante con su muerte. Lavisin de Jim del importante roldesempeado por el software en losnegocios modernos, inspir a todosquienes lo conocieron.
Debo gran aprecio a todos mis colegasde Software Productivity Research porsu ayuda en la recopilacin de datos,por ayudar a nuestros clientes,desarrollar las herramientas que
-
utilizamos y hacer de SPR un entornoagradable. Agradezco especialmente alas familias y amigos del personal deSPR, quienes tuvieron que lidiar conmuchos viajes y demasiado tiempo extraen la oficina. Gracias a mis colegasMark Beckley, Ed Begley, Chuck Berlin,Barbara Bloom, Julie Bonaiuto, WilliamBowen, Michael Bragen, Doug Brindley,Kristin Brooks, Tom Cagley, LynneCaramanica, Debbie Chapman, SudipCharkraboty, Craig Chamberlin,
Carol Chiungos, Michael Cunnane, ChasDouglis, Charlie Duczakowski, Gail
Flaherty, Dave Garmus, RichardGazoorian, James Glorie, Scott
-
Goldfarb, Jane Green, David Gustafson,Wayne Hadlock, Bill Harmon, ShaneHartman, Bob
Haven, David Herron, Steve Hone, JanHuffman, Peter Katsoulas, Richard
Kauffold, Heather McPhee, ScottMoody, John Mulcahy, Phyllis Nissen,Jacob Okyne, Donna ODonnel, MarkPinis, Tom Riesmeyer, Janet Russac,Cres Smith, John Smith, Judy Sommers,Bill Walsh, Richard Ward y JohnZimmerman.
Agradezco tambin a Ajit Maira y DickSpann por su servicio en el consejo deadministracin de SPR.
-
Muchos otros colegas trabajan connosotros en SPR en proyectos especialeso como consultores. Agradezco enespecial a Allan Albrecht, inventor delos puntos funcin, por su contribucininvaluable a la industria y trabajosobresaliente con SPR. Sin el trabajopionero de Allan en puntos funcin,probablemente no existira laposibilidad de crear lneas de base ypruebas de referencia precisas.
Muchas gracias a Hisashi Tomino y asus colegas en Kozo KeikakuEngineering de Japn. Kozo hatraducido varios de mis libros anterioresal japons. Adems, Kozo ha sidofundamental en la introduccin de
-
mtricas de puntos funcin al Japn,traduciendo algunos documentosrelevantes sobre puntos funcin.
Externo mi aprecio a las organizacionescliente cuyo inters en evaluaciones desoftware, pruebas de referencia y lneasde base, medicin y mejoras a procesos,nos ha permitido trabajar juntos. stasson las organizaciones cuyos datoshacen posibles las herramientas deestimacin.
Existen demasiados grupos paramencionarlos a todos, pero agradezco anuestros clientes y colegas de AndersenConsulting, AT&T, Bachman, Bellcore,Bell Northern Research, Bell Sygma,
-
Bendix, British Air, CBIS, CharlesSchwab, Church of the Latter DaySaints, Cincinnati Bell, CODEX,Computer Aid, Credit Suisse, DEC, Dun& Bradstreet, Du Pont, EDS, Finsiel,Ford Motors, Fortis Group, GeneralElectric, General Motors, GTE,Hartford Insurance, Hewlett-Packard,IBM, Informix, Inland Steel, InternalRevenue Service, ISSC, JC Penney, JP
Morgan, Kozo Keikaku, LanguageTechnology, Litton, Lotus, Mead DataCentral, Reconocimientos xxvii
McKinsey Consulting, Microsoft,Motorola, Nippon Telegraph, NCR,Northern Telecom, Nynex, Pacific Bell,
-
Ralston Purina, Sapiens, Sears Roebuck,Siemens-Nixdorf, Software PublishingCorporation, SOGEI, Sun Life, Tandem,TRW,
UNISYS, Fuerza Area de EstadosUnidos, grupos Surface Weapons de laMarina de Estados Unidos, US West,Wang, Westinghouse y muchos otros.
Agradezco tambin a mis colegas en elterreno de la estimacin de software:Allan Albrecht, Barry Boehm, CarolBrennan, Tom DeMarco, Don Galorath,
Linda Laird, Steve McConnell, LarryPutnam, Don Reifer, Howard Rubin,Frank Freiman, Charles Symons yRandall Jensen. Aunque estos
-
investigadores de la estimacin decostos de software pueden sercompetidores, tambin son pioneros enla estimacin de costos de software yexpertos importantes. Sin suinvestigacin, no existira la industria dela estimacin de costos de software. Laindustria del software es afortunada porcontar con investigadores y autorescomo ellos.
Debo tambin mi aprecio a aquellaspersonas que imparten cursos de estima-cin de costos de software y exponeneste importante tema a sus alumnos. ElDr.
Victor Basili y el Profesor Daniel
-
Farens, han hecho mucho para cerrar labrecha entre el mundo acadmico y el denegocios, introduciendo herramientas deestimacin del mundo real al dominioacadmico.
Capers Jones
Seccin
1
Introduccin a la estimacin
de costos de software
La estimacin de costos de software esuna actividad compleja que
-
requiere conocimiento de atributosclave acerca del proyecto para el
que se construye. La estimacin decostos se conoce a veces como
estimacin paramtrica, porque laprecisin demanda entender
relaciones entre parmetros discretosde efecto potencial para
los resultados de proyectos de software,tanto individuales como en
concierto. La creacin de estimacionesde costos de software precisas requiereconocimiento de los siguientesparmetros:
-
Tamaos de entregables importantes,como especifi caciones, cdigo fuente ymanuales
Tasas a las que es probable cambiarlos requisitos durante el desarrollo
El nmero probable de errores decdigo o defectos que quiz detecten
Talentos del equipo de desarrollo
Salarios y costos adicionalesasociados con el equipo de desarrollo
Las metodologas formales aemplearse (como los mtodos Agile)
Las herramientas a ser usadas en el
-
proyecto
Actividades de desarrollo parallevarse a cabo
Restricciones de costos y tiemposlmite impuestas por clientes delproyecto en estimacin
1
2 Seccin 1: Introduccin a laestimacin de costos de softwareAunque los factores que influyen en losresultados de proyectos de
software son numerosos y algunoscomplejos, las herramientas comer-
-
ciales modernas para estimacin decostos de software pueden aligerar lacarga de los gerentes de proyecto,proporcionando valorespredeterminados para todos losparmetros clave, mediante el uso devalores de la industria, derivados de labase de conocimiento integral,proporcionado por las herramientas deestimacin.
Adems, las herramientas deestimacin de costos de software per-
miten construir plantillas deestimacin personalizadas, derivadasde proyectos reales, usadas paraestimar tamaos y tipos de proyectos
-
similares.
Esta seccin analiza orgenes yevolucin de las herramientas de
estimacin de costos de software ycmo sta encaja en la categora msamplia de administracin de proyectosde software. Adems, esta seccinanaliza el impacto de herramientas deestimacin de costos de software enndices de xito de proyectos desoftware y recurre a estos datos parailustrar el retorno aproximado de lainversin (ROI) de herramientas deestimacin de costos de software yadministracin de proyectos.
Captulo
-
1Introduccin
La estimacin de costos de software hasido una tarea importante, pero difcil,desde el inicio de la era de lascomputadoras en la dcada de 1940.Conforme las aplicaciones de softwarehan crecido en tamao e importancia, lanecesidad de precisar la estimacin decostos de software ha crecido tambin.
En los primeros das del software, losprogramas de computadora tenan, engeneral, un tamao inferior a 1 000instrucciones de mquina (o menos de30
-
puntos funcin); se requera slo unprogramador para escribirlos y rara veztar-daba ms de un mes en completarse.Los costos de desarrollo totales eran amenudo inferiores a los 5 000 dlares.Aunque la estimacin de costos eradifcil, las consecuencias econmicas delos errores en la estimacin de costos noeran graves.
Hoy da, algunos sistemas de softwaregrandes superan 25 millones de ins-
trucciones de cdigo fuente (o ms de 30000 puntos funcin); pueden requerir 1000 empleados tcnicos o ms y tardarms de cinco aos para completarse.
Los costos de desarrollo de estos
-
sistemas de software pueden exceder500
millones de dlares; por tanto, loserrores en estimacin de costos puedenser muy graves en realidad.
Es ms grave an el hecho de que unporcentaje significativo de sistemas desoftware grandes tiende a retrasarse,exceder sus presupuestos o cancelarsepor completo, debido a severasimprecisiones de estimacin durante lafase de requisitos. De hecho, unoptimismo excesivo en la estimacin decostos de software es fuente importantede excesos, fracasos y litigios.
El software es ahora la fuerza motriz de
-
las operaciones de negocios modernos,del gobierno y militares. Esto significaque una corporacin tpica de Fortune500
o gobierno estatal, puede producircientos de nuevas aplicaciones ymodificar cientos de las ya existentescada ao. Como resultado del sinfn deproyectos de software en el mundomoderno, la estimacin de costos desoftware es ahora una tarea cotidianapara toda compaa involucrada en laactividad.
3
4 Seccin 1: Introduccin a la
-
estimacin de costos de softwareAdems de necesitar estimacionesprecisas de los costos de software paraoperaciones cotidianas de negocios,estimar costos de software asume unvalor significativo en litigios. Durantelos ltimos 15 aos, el autor y suscolegas han observado docenas dejuicios legales donde demandantes,acusados o ambos produjeronestimaciones de costos de software. Porejemplo, la estimacin de costos desoftware desempea ahora un rol claveen los juicios legales, implicando lassiguientes disputas:
Juicios por incumplimiento decontratos entre clientes y contratistas
-
Juicios implicando valor gravable deactivos de software
Juicios implicando la recuperacin decostos excesivos de software dedefensa, debido a la expansin delmbito
Juicios implicando favoritismo en laconcesin de contratos de desarrollo desoftware
Juicios implicando despido ilegal depersonal de desarrollo de softwareDesde muchos puntos de vista, laestimacin de costos de software se haconvertido en una tecnologa decisiva enel siglo 21, porque ahora el software esmuy penetrante.
-
Cmo funcionan las herramientas deestimacin de costos de software?
Existen muchos tipos de herramientasautomatizadas que los gerentes deproyecto experimentados pueden utilizarpara la creacin de estimaciones decostos, tiempos lmite y recursos paraproyectos de software. Por ejemplo, ungerente de proyectos de softwareexperimentado puede crear unaestimacin de costos y un plan detiempos lmite, recurriendo a cualquierade los instrumentos siguientes:
Hojas de clculo
Herramientas para administracin deproyectos
-
Herramientas para la estimacin decostos de software
Una pregunta hecha con frecuencia porlos fabricantes de herramientas paraestimar los costos de software es Porqu necesitamos su herramienta, cuandoya tenemos hojas de clculo yherramientas de administracin deproyectos?.
Las herramientas comerciales paraestimar costos de software sediferencian de todos los otros tipos deherramientas de administracin deproyectos de software y herramientasgenricas, como las hojas de clculo,por los siguientes atributos clave:
-
Contienen bases de conocimientos decientos de miles de proyectos desoftware
Realizan predicciones de tamao, quelas herramientas genricas sonincapaces de realizar
Ajustan automticamente estimacionesbasadas en herramientas, lenguajes yprocesos
Captulo 1: Introduccin 5
-
Predicen calidad y confi abilidad, lasherramientas genricas no lo hacen
Predicen costos de mantenimiento ysoporte despus de implementadas
Predicen (y previenen) problemas,mucho tiempo antes de que stos ocurranen realidad
A diferencia de otros tipos deherramientas de administracin deproyectos, las herramientas comercialesde estimacin de costos de software nose sujetan a los conocimientos delusuario o gerente del proyecto, aunquelos gerentes experimentados puedenrefinar las estimaciones producidas. Lasherramientas comerciales de estimacin
-
de costos contienen experienciaacumulada de muchos cientos o miles deproyectos de software.
Debido a las bases de conocimientosadjuntas asociadas con herramientas
comerciales de estimacin de costos, losgerentes poco experimentados o que seenfrentan con tipos de proyectos pococonocidos, pueden describir lascaractersticas del proyecto al que seenfrentan y la herramienta de estimacinconstruir una basada en proyectossimilares, sustrada de informacin en subase de conocimientos asociada.
La figura 1.1 ilustra los principiosbsicos de las herramientas comerciales
-
modernas de estimacin de costos desoftware.
El punto de partida de la estimacin desoftware es el tamao del proyecto entrminos de instrucciones lgicas delcdigo fuente, lneas fsicas de cdigo,puntos funcin o, a veces, las tresmtricas juntas. El tamao del proyectose puede derivar de la lgica deprediccin del tamao propia de laherramienta de estimacin, provista porusuarios como entrada explcita oderivada de la analoga con proyectossimilares, almacenados en la base deconocimientos de la herramienta deestimacin. Incluso, en el caso deproyectos Agile y los que emplean
-
desarrollo iterativo, cuando menos sepuede crear informacin de tamaoaproximada.
Una vez determinado el tamao bsicodel proyecto, la estimacin se puedeproducir con base en atributosespecficos del proyecto en cuestin.Algunos ejemplos de los atributos quepueden afectar el resultado de laestimacin incluyen los siguientes:
Velocidad a que pueden cambiar losrequisitos del proyecto
Experiencia del equipo de desarrollocon este tipo de proyecto
Proceso o mtodos empleados para
-
desarrollar el proyecto, que van deAgile a Waterfall
ESTIMADOS
Tiempo lmite
TAMAO DEL
ATRIBUTOS DEL
Esfuerzo
PROYECTO
PROYECTO
Costos
-
Entregables
Figura 1.1 Principios de la estimacindel software.
6 Seccin 1: Introduccin a laestimacin de costos de software
Actividades especfi cas a realizarsedurante el desarrollo
Nmero de incrementos, iteraciones ocarreras que se utilizarn
El o los lenguajes de programacin aser manejados
Presencia o ausencia de artefactosreutilizables
-
Suites de herramientas de desarrolloque se usarn para desarrollar elproyecto
Entorno o ergonoma del espacio detrabajo en la ofi cina
Separacin geogrfi ca del equipo enmltiples lugares
Presin de los tiempos lmite ejercidaen el equipo por clientes o ejecutivos
Obligaciones contractuales entrminos de costos, fechas, defectos ocaractersticas
Utilizando herramientas comerciales deestimacin, estos atributos de los
-
proyectos pueden ser proporcionadospor el usuario o heredados de proyectossimilares, ya almacenados en la base deconocimientos de la herramienta deestimacin.
En un sentido, las herramientas deestimacin comparten caractersticas delparadigma orientado a objetos en quepermiten la herencia de atributoscompartidos de un proyecto a otro.
En terminologa de estimacin desoftware, tales atributos compartidos sedenominan plantillas y puedenconstruirse de varias formas. Porejemplo, los usuarios de herramientas deestimacin pueden apuntar a un proyecto
-
completo ya existente y seleccionarcualquiera o todas las caractersticas delmismo como base para la plantilla. Portanto, si el proyecto seleccionado comobase de una plantilla fuese un proyectode software de sistema, emplear ellenguaje de programacin C einspecciones formales de diseo ycdigo; estos atributos podranheredarse como parte del ciclo dedesarrollo y se volveran parte de unaplantilla de estimacin para otrosproyectos.
Tambin pueden heredarse muchos otrosatributos de proyectos histricos yvolverse aspectos de plantillas paraestimacin de software. Por ejemplo,
-
una plantilla de estimacin completapuede contener datos de atributosheredados acerca de temas, como lossiguientes:
Experiencia del equipo de desarrolloen aplicaciones similares
Proceso o metodologa empleadospara desarrollar la aplicacin
Nivel de madurez de las capacidadesSEI de la organizacin
Estndares a los que se apegar, comoISO, DoD, IEEE, etctera
Herramientas utilizadas durante eldiseo, redaccin del cdigo, pruebas,
-
etc-
tera
El o los lenguajes de programacinutilizados
Volmenes de artefactos reutilizablesdisponibles
Ergonoma del entorno de la ofi cinade programacin
Como los proyectos de software no sonidnticos, cualquiera de estos atributosheredados puede adaptarse a lasnecesidades. Sin embargo, ladisponibilidad de
-
Captulo 1: Introduccin 7
plantillas agiliza el proceso deestimacin, lo hace ms cmodo yconfiable porque las plantillas sustituyenconocimientos especficos de proyectoslocales, por valores predeterminadosgenricos de la industria.
-
Las plantillas pueden derivar tambin deseries de proyectos y no slo de unproyecto especfico, incluso pueden sercreados a la medida por los usuarios,mediante el uso de factores artificiales.Sin embargo, el mtodo ms comn dedesarrollo de plantillas consiste en usarla capacidad de construccin automticade plantillas de la herramienta deestimacin, simplemente seleccionandoproyectos histricos relevantes a usarsecomo base de la plantilla.
Por regla general, las plantillas deestimacin de software estn asociadascon cuatro tipos clave de atributosheredados: (1) personal, (2)tecnologas, (3) herramientas y (4)
-
entorno de programacin, como loilustra la figura 1.2.
Tres de estos cuatro factores(experiencia del personal, proceso dedesarrollo y tecnologa [lenguajes deprogramacin y herramientas desoporte]) son bastante obvios en suimpacto. Lo que no es obvio, peroigualmente importante, es el impacto delcuarto factor ( entorno).
El factor del entorno abarca el espacioindividual de oficina y los canales decomunicacin entre equipos dedesarrollo geogrficamente dispersos.De forma sorpresiva, el acceso a unentorno de oficina libre de ruido, es uno
-
de los factores principales influyendo laproductividad de la programacin.
La posibilidad de incluir factoresergonmicos en una estimacin, es unejemplo excelente del valor de lasherramientas comerciales de estimacinde costos de software. No slocontienen resultados de cientos o milesde proyectos completados, sino datosacerca de factores de influencia,probablemente subestimados pormuchos gerentes de proyectos.
Tecnologa
Calidad y
Procesos
-
Personal
productividad
del software
Entorno
Figura 1.2 Factores clave deestimacin.
8 Seccin 1: Introduccin a laestimacin de costos de software Sedeben considerar los cuatro conjuntosclave de atributos si se realiza unaestimacin manual o una herramienta deestimacin automatizada. Sin embargo,una de las caractersticas clave de lasherramientas comerciales de estimacin
-
de costos de software radica en el hechode que son repositorios conteniendoresultados de cientos o miles deproyectos de software y, de este modo,en condiciones para examinar el efectode tales reas de atributos, adems depoder analizar sus impactos.
Existe una secuencia estndar para laestimacin de costos de software usadapor el autor ms de 35 aos. Estasecuencia puede usarse conestimaciones manuales de costos desoftware y es tambin un reflejo de lasetapas de estimacin en las herramientasde estimacin de software diseado porel autor. Existen 10 pasos en estasecuencia, aunque inicia con 0, porque
-
la primera etapa es un anlisis previo ala estimacin de requisitos de laaplicacin.
Paso 0: Analice los requisitos
La estimacin de costos de software anivel de proyecto no puede realizarse amenos que se entiendan bien losrequisitos del mismo. Por tanto, antes deiniciar la estimacin, es indispensableexplorar y comprender los requisitos delusuario.
En algn momento en el futuro debe serposible crear estimacionesautomticamente, a partir deespecificaciones de requisitos, pero elnivel actual de la tecnologa de
-
estimacin exige intervencin humana.
Una actividad de estimacin comn hoyda, consiste en analizar los requisitosde software y crear totales de puntosfuncin, basados en esos requisitos. Estoproporciona datos de tamao bsicos ausarse en una estimacin formal decostos. El anlisis de puntos funcinsuele ser realizado de manera manualpor personal certificado. Se acercarpidamente una poca en que los totalesde los puntos funcin podrn derivarseautomticamente a partir de requisitosde software y es posible que estemtodo aparezca en herramientascomerciales de estimacin de costos desoftware en unos aos.
-
Es un hecho conocido que los requisitospara grandes sistemas no puedendefinirse por completo al iniciar elproyecto. Este hecho es la base de losmtodos Agile, de la programacinextrema, lneas cerradas y otros. Estehecho est incorporado tambin en losalgoritmos de diversas herramientascomerciales de estimacin de software.Una vez esclarecidos los requisitosiniciales, la tasa media de crecimientode nuevos requisitos es de, ms omenos, 2% por mes calendario. stepuede ser planeado e incluido en laestimacin.
Paso 1: Comience prediciendo eltamao
-
Toda forma de estimacin y herramientacomercial de estimacin de costos desoftware necesita los tamaos deentregables clave, a fin de completar unaestimacin. Los datos de tamao puedenobtenerse de varias maneras, incluidaslas siguientes:
Captulo 1: Introduccin 9
Prediccin del tamao recurriendo aalgoritmos de prediccin de tamao,integrados de una herramienta deestimacin
Prediccin del tamao porextrapolacin, partiendo de totales depuntos funcin
-
Prediccin del tamao por analogacon proyectos similares de tamao co -
nocido
Aproximacin del tamao, segn laintuicin del gerente del proyecto
Aproximacin del tamao,recurriendo a la intuicin delprogramador
Prediccin del tamao, empleandomtodos estadsticos o la simulacinMonte Carlo
En el caso de mtodos Agile y proyectosbasados en desarrollo iterativo, laprediccin del tamao de la aplicacin
-
completa se puede posponer hastacompletar los primeros incrementos. Sinembargo, incluso en el caso deproyectos Agile e iterativos, es posiblehacer una prediccin aproximada deltamao final, tan slo comparando lanaturaleza del proyecto con proyectossimilares o usar aproximaciones detamao basadas en la clase, tipo ynaturaleza del software. Ms adelante eneste libro, se dan ejemplos de mtodosde prediccin del tamao.
El tamao bsico de la aplicacinestimado suele expresarse en trminosde puntos funcin, instrucciones decdigo fuente o ambos. Sin embargo, esmuy importante calcular el tamao de
-
todos los entregables y no slomanipular cdigo. Por ejemplo, ms de50 tipos de documentos en papel estnasociados con proyectos de softwaregrandes y tambin se necesita anticiparsu tamao. Desde luego, cuando seemplea una de las herramientascomerciales de estimacin de software,con capacidad para predecir el tamaode documentos, stos se predicen deforma automtica.
El clculo del tamao del cdigo fuentese debe ajustar a lenguajes deprogramacin especficos y ahora semanejan ms de 600 lenguajes. Cerca deun tercio de los proyectos de softwareemplean ms de un lenguaje de
-
programacin. Hay ms de una docenade tipos de pruebas y cada una requerirdiferentes volmenes de casos deprueba.
La prediccin del tamao es unaactividad de estimacin clave. Si lostamaos de entregables importantespueden predecirse dentro de un rango de5 a 10%, entonces la precisin de laestimacin global puede ser bastantebuena. Si las predicciones de tamaoson imprecisas, entonces el resto de laestimacin ser imprecisa tambin.Como ya se mencion, la evidenciaemprica de grandes proyectos desoftware indica que los requisitosaumentan a una tasa promedio de ms o
-
menos 2% por mes calendario, desde elfinal de la fase de requisitos hasta elinicio de la fase de pruebas. Elcrecimiento total de los requisitos puedesuperar 50% del volumen de losrequisitos iniciales cuando se mide conpuntos funcin.
Un problema importante en laestimacin de la precisin ha sido omitiro dejar a un lado requisitos progresivos.Las herramientas de estimacin decostos modernas pueden predecir elcrecimiento de los requisitos e incluirsus costos y fechas lmite en laestimacin.
10 Seccin 1: Introduccin a la
-
estimacin de costos de software Lastecnologas disponibles para predecir eltamao han mejorado rpidamente.
En los albores de la estimacin decostos de software, los usuarios debanaportar datos del tamao empleandomtodos muy primitivos. Ahora lasherramientas de estimacin de costosmodernas tienen a su disposicincapacidades para predecir tamaos,incluido el soporte para estimacionestempranas de tamao, aun antes de quelos requisitos sean firmes.
Paso 2: Identifi que las actividadesque se incluirn
-
Una vez conocidos los tamaos deentregables clave, el siguiente paso esseleccionar la serie de actividades arealizarse. En este contexto, el trminoactividades refiere al trabajo arealizarse para el proyecto estimado,como requisitos, diseo interno, diseoexterno, inspecciones de diseo,redaccin de cdigo, inspecciones decdigo, creacin de documentos delusuario, reuniones o sesiones de lneascerradas, control del cambio,integracin, control de calidad, pruebade unidades, prueba de nuevasfunciones, pruebas de regresin, pruebasde sistemas y administracin deproyectos. Una estimacin precisa esimposible sin el conocimiento de las
-
actividades a emprender.
Los patrones de actividad varanampliamente de un proyecto a otro. Lossistemas grandes utilizan msactividades que los pequeos. Losproyectos Waterfall realizan msactividades que los proyectos Agile. Enel caso de proyectos del mismo tamao,el software militar y de sistemas empleams actividades que los sistemas deinformacin. Se deben usar patroneslocales de actividades, ya que reflejanmetodologas de desarrollo de softwarede su propia empresa.
Las herramientas modernas deestimacin de costos de software tienen
-
lgica integrada para seleccionarpatrones de actividad asociados conmuchos tipos de proyectos de desarrollode software. Asimismo, los usuariospueden ajustar sus patrones de actividadpara igualar variaciones locales.
Paso 3: Estime fallas potenciales ymtodos de eliminacin
de defectos en el software
El trabajo ms costoso y consumidor detiempo en el desarrollo de softwareconsiste hallar errores de cdigo yrepararlos. En Estados Unidos, elnmero de errores de cdigo o defectosen requisitos, diseo, cdigo,
-
documentos y malas reparacionespromedia 5 por punto funcin. Laeficiencia promedio de eliminacin dedefectos antes de la entrega es de 85%.El costo de hallar y reparar estosdefectos promedia cerca de 35% delcosto de desarrollo total de construccinde la aplicacin. El tiempo lmiterequerido es ms o menos de 30% de lasfechas lmite para el desarrollo deproyectos. Costos y fechas lmite parareparar defectos suelen ser mayores quelos costos y fechas lmite para laredaccin del cdigo. No se puede tenerprecisin en las estimaciones de loscostos de software si los defectos y sueliminacin no se incluyen en lasestimaciones. Las herramientas de
-
estimacin de costos de softwareincluyen capacidades completas deestimacin de defectos y dan soporte atodos los tipos conocidos de actividadde eliminacin de defectos. Esto esnecesario porque Captulo 1:Introduccin 11
el esfuerzo, costo y tiempo totalesinvertidos en una serie completa derevisiones, inspecciones y pruebas enmltiples etapas costarn mucho msque el mismo cdigo fuente.
La estimacin de defectos incluyehabilidades para predecir defectos enrequisitos, diseo, cdigo,documentacin del usuario y una
-
categora muy problemtica llamadadefectos por malas reparaciones. Lafrase malas reparaciones se refiere anuevos defectos introducidos de maneraaccidental como consecuencia de lareparacin de defectos previos. Losdefectos por malas reparacionespromedian cerca de 7% de todas lasreparaciones de defectos. Algunasherramientas de estimacin puedenpredecir malas reparaciones.
Herramientas de estimacin con soportepara software comercial puedenpredecir tambin reportes de defectosduplicados o errores de cdigoencontrados por ms de un cliente.Tambin es posible estimar reportes de
-
defectos no vlidos o reportes deerrores de cdigo que resultan no serculpa del software, como errores delusuario o problemas de hardware.
La capacidad de predecir defectos desoftware no sera muy til sin otro tipode estimacin, prediciendo la eficienciade eliminacin de defectos de diversostipos de revisiones, inspecciones yetapas de pruebas. Las herramientasmodernas de estimacin de costos desoftware pueden predecir cuntoserrores de cdigo sern encontrados porcada forma de eliminacin de defectos,desde la verificacin en el escritoriohasta pruebas beta externas.
-
Paso 4: Estime requisitos de personal
Todo entregable de software tiene unmbito de asignacin caracterstico ocantidad de trabajo a realizar por unempleado. Por ejemplo, una asignacinpromedio para un programadorindividual variar de 5 000 a 15 000instrucciones de cdigo fuente (de unos50 a 2 000 puntos funcin).
Sin embargo, los sistemas grandes sevalen tambin de muchos especialistas,como arquitectos de sistemas,administradores de bases de datos,especialistas en control de calidad,ingenieros de software, escritorestcnicos, comprobadores, etc.
-
La identificacin de cada categora deempleado y nmero de trabajadores paracumplir el proyecto completo, es el pasosiguiente en la estimacin de costos desoftware.
Los requisitos de personal dependernde las actividades planeadas y de losentregables que se crearn; de ese modo,las predicciones de personal se derivandel conocimiento del tamao total de laaplicacin y las series de actividades aincluirse. Las predicciones de personalnecesitan tambin tener presente laprogramacin en parejas o equipos dedos personas, considerados entre losnuevos mtodos Agile.
-
En el caso de sistemas grandes, esposible que los programadores mismos
comprendan menos de la mitad de lafuerza de trabajo. Diversos tipos deespecialistas y gerentes de proyectoconforman la otra mitad. Algunos deestos especialistas incluyen personal decontrol de calidad, personal de pruebas,escritores 12 Seccin 1: Introduccin ala estimacin de costos de softwaretcnicos, analistas de sistemas,administradores de bases de datos yespecialistas en control de laconfiguracin. Si el proyecto essuficientemente grande para demandarespecialistas, una estimacin precisarequiere incluir sus esfuerzos.
-
Deben incorporar programacin y otrostipos de actividades ajenas a laredaccin del cdigo, como laproduccin de manuales y control de lacalidad, para completar la estimacincorrectamente.
Paso 5: Ajuste suposiciones basadasen capacidades y experiencia
El personal de software puede variar deexpertos con aos de experiencia anovatos en su primera asignacin. Unavez identificadas las categoras deempleados tcnicos, el paso siguiente eshacer ajustes con base en niveles deexperiencia y factores de habilidadtpicos.
-
Los expertos pueden realizar mstrabajo y en menos tiempo que losnovatos.
Esto significa que los expertos tendrnmbitos de asignacin ms grandes endices de produccin ms altos que elpersonal promedio o pocoexperimentado.
Otros ajustes incluyen horas de trabajopor da, vacaciones y das festivos,tiempo extra pagado y no pagado,adems de suposiciones acerca de ladispersin geogrfica del equipo desoftware. Ajustar la estimacin paraigualar capacidades del equipo es unade las actividades de estimacin ms
-
decisivas.
Aunque las herramientas de estimacinpueden hacer ajustes para igualar
diferentes grados de conocimientos,carecen de medios para conocercapacidades especficas de un equipodeterminado. Muchas herramientas deestimacin comerciales estnpredeterminadas a capacidadespromedio y permiten a los usuariosajustar esta suposicin hacia arriba oabajo para igualar caractersticasespecficas del equipo.
Paso 6: Estime el esfuerzo y fechaslmite
-
Las estimaciones de esfuerzo y fechaslmite estn estrechamenteinterrelacionadas y a menudo se realizande forma iterativa.
Una estimacin precisa del esfuerzorequiere conocimiento del tamaobsico de la aplicacin ms el nmero yniveles de experiencia de los miembrosdel equipo de software, as comotamaos de diversos entregablesesperados de su produccin,especificaciones y manuales para elusuario.
Una estimacin precisa de fechas lmiteprecisa entendimiento de las actividadesproyectadas, nmero de incrementos o
-
carreras que se realizarn, tama-
os de diversos entregables,superposicin entre actividades condependencias mutuas, adems delnmero y niveles de experiencia de losmiembros del equipo establecido.
Las estimaciones de fechas lmite yesfuerzo estn estrechamente ligadas,pero la interaccin entre estas dosdimensiones en ser es complicada. Porejemplo, si un proyecto de software va atardar seis meses desarrollado por unprogramador, la adicin de un segundoprogramador no reducir la fecha lmitea tres meses.
Captulo 1: Introduccin 13
-
De hecho, puede llegar el punto en quela adicin de personal alargue la fechalmite del proyecto, en lugar deacelerarlo.
La compleja serie de reglas vinculandoesfuerzo y fechas lmite para proyectosde software son el corazn de losalgoritmos de herramientas deestimacin de costos de software. Paraponer un ejemplo de las reglas mssutiles en las herramientas deestimacin, la adicin de personal a unproyecto de software en undepartamento acortar en general lasfechas lmite de desarrollo. Pero si seagrega personal suficiente, de modo queun segundo departamento se involucre en
-
el proyecto, las fechas lmite seextendern. El razonamiento tras estamedida radica en que las fechas lmitedel software, adems de los ndices deproductividad, estn inversamenterelacionados con el nmero de gerentesdel proyecto implicados. Existenmltiples reglas asociadas con lainteraccin de fechas lmite y esfuerzo, yalgunas de ellas son sutiles.
De hecho, en el caso de proyectos desoftware muy grandes con mltiplesequipos, la tasa a que disminuye laproductividad de desarrollo tiende acorrelacionarse ms estrechamente conel nmero de gerentes implicados que elnmero real de programadores
-
interviniendo en el proyecto. Estefenmeno conlleva hallazgos sutiles,como el hecho de que los proyectos conun mbito de control reducido (menos deseis programadores por cada gerente)pueden tener menor productividad queproyectos similares con un mbito decontrol extenso (12 programadores porcada gerente).
Paso 7: Estime los costos dedesarrollo
Los costos de desarrollo son lapenltima etapa del proceso deestimacin y resultan muy complejos.Obviamente, dependern del esfuerzo yfecha lmite de proyectos de software;
-
de modo que estos factores se predicenen primer trmino y despus se aplicanlos costos.
Los costos de proyectos de softwarerequiriendo exactamente la mismacantidad de esfuerzo en trminos dehoras o meses pueden variarampliamente, debido a las siguientescausas:
Salarios promedio de trabajadores ygerentes del proyecto
El ndice de carga o costo excesivocorporativo aplicado al proyecto
ndices de infl acin, si el proyecto seextiende a varios aos
-
Tipos de cambio de divisas, si elproyecto se desarrolla a nivelinternacional Puede haber tambin temasde costo especiales que debernmanejarse por
separado, fuera de la estimacin bsica:
Cuotas de licencia de cualquiersoftware adquirido necesario para eldesarrollo
Costos de capital de cualquier equiponuevo
Costos de mudanza y vida para nuevosmiembros del personal
14 Seccin 1: Introduccin a la
-
estimacin de costos de software
Viticos para proyectosinternacionales o proyectosdesarrollados en diferentes lugares
Costos de contratistas ysubcontratistas
Honorarios legales por derechos decopyright, patentes u otros asuntos
Costos de mercadotecnia y publicidad
Costos por el desarrollo de videos omateriales para tutoriales en CD-ROM ycapacitacin
Costos de adquisicin de contenido, si
-
la aplicacin es un producto basado enla Web
En general, el desarrollo de unaestimacin de costo completa de unproyecto de software es mucho mscomplejo que simplemente desarrollaruna estimacin de recursos del nmerode horas de trabajo necesarias. Muchoselementos de costo, como ndices decarga o viticos, estn slo relacionadosindirectamente con esfuerzo y puedenimpactar el costo final del proyecto deforma significativa.
El patrn normal de estimacin delsoftware consiste en horas, das,semanas o meses de esfuerzo como
-
unidad de estimacin principal y luegoaplicar costos al final del ciclo deestimacin, una vez determinados lospatrones de esfuerzo.
Paso 8: Estime costos demantenimiento y mejoras
Los proyectos de software a menudo seusan y modifican durante muchos aos.
La estimacin de costos demantenimiento y mejoras son temasespeciales y ms complejos que laestimacin de costos de proyectosnuevos.
La estimacin de costos demantenimiento requiere conocimiento
-
del nmero probable de usuarios de laaplicacin, combinado con elconocimiento del n me -
ro probable de errores de cdigo odefectos en el producto, en el momentode lanzarlo al mercado.
La estimacin de costos de mejorasrequiere buenos datos histricos acercadel ndice de cambio de proyectossimilares, una vez iniciada suproduccin y entrada en uso. Porejemplo, los nuevos proyectos desoftware pueden agregar 10% o ms alvolumen total de nuevas caractersticas,con cada versin actualizada a lo largode versiones consecutivas, pero
-
disminuir por un periodo de dos a tresaos antes de alcanzar otra versinimportante.
Muchas herramientas de estimacincomerciales pueden ponderar costos ini-
ciales de construccin de un proyecto ylos patrones de costos de mantenimientoy mejoras por ms de cinco aos de usode los clientes.
No existe un lmite real respecto alnmero de aos a estimar, pero como lasproyecciones de largo alcance para elnmero de usuarios y posibles nuevascaractersticas son altamentecuestionables, la vida til de lasestimaciones de mantenimiento y
-
mejoras, va de tres a cinco aos.Estimar los costos de mantenimiento conproyecciones a 10 aos en el futuro sepuede realizar, pero ninguna estimacinde ese rango se puede considerarconfiable, ya que pueden presentarsedemasiadas variables de negocios msall del control de prediccin.
Captulo 1: Introduccin 15
Paso 9: Presente su estimacin alcliente y defi ndala
en caso de que la rechace
Una vez preparada la estimacin decosto, el paso siguiente es presentarla alcliente patrocinador del proyecto. En el
-
caso de sistemas y aplicaciones grandesde 5 000 puntos funcin o ms(equivalentes a unas 500 000instrucciones de cdigo fuente), cerca de60% de las estimaciones iniciales sernrechazadas por el cliente.
La fecha lmite estimada ser demasiadolarga, los costos demasiado elevados oambos. A menudo, el cliente decretaruna fecha de entrega especfica mscorta que la estimada. Asimismo, elcliente advertir que los costos debenmantenerse dentro de lmites muy pordebajo de costos estimados. Losproyectos en que se rechazanestimaciones formales y reemplazan porfechas lmite y costos arbitrarios,
-
derivados de necesidades de negociosexternas y no de las capacidades delequipo de trabajo, tienen los ndices defracaso ms altos en la industria. Cercade 60% de estos proyectos secancelarn sin completarse. (En elmomento de la cancelacin, costos yfechas lmite ya habrn excedido susmetas.) De 40% de los proyectos quefinalmente se completan, la fecha lmitepromedio ser ms o menos un ao tardey el costo promedio alrededor de 50%arriba de lo estimado.
La mejor defensa contra el rechazo deuna estimacin de costo es contar condatos histricos slidos, al menos deuna docena de proyectos similares. La
-
segunda mejor defensa contra el rechazode una estimacin de costo es prepararuna estimacin completa, basada enactividades incluyendo calidad,papeleo, requisitos progresivos, todaslas actividades de desarrollo y lastareas de mantenimiento.
Necesitar demostrar que su estimacinha sido elaborada con detenimiento sindejar nada al azar. Las estimaciones dealto nivel o a nivel de fases carentes dedetalle no convencen y son rechazadascon facilidad.
Advertencias sobre omisionesaccidentales
-
en las estimaciones
Como las herramientas de estimacindel software tienen una base deconocimientos vasta, es probable que nose cometan los errores de gerentes pocoexperimentados cuando creanestimaciones a mano o con herramientasgenricas y omiten actividades de laestimacin de manera accidental.
Por ejemplo, al hacer estimaciones desistemas grandes, la redaccin delcdigo puede ser quiz la cuartaactividad ms costosa. A menudo, losgerentes tienden a omitir o subestimar eltrabajo no relacionado con cdigo, perolas herramientas de estimacin pueden
-
incluir estas otras actividades.
Histricamente, el esfuerzo dedicadoa buscar y reparar errores de cdigo pormedio de revisiones, repasos superficiales, inspecciones y pruebas, requierems tiempo y costos que cualquier otraactividad relacionada con el software.
Por tanto, las estimaciones de costosprecisas deben iniciar con prediccionesde calidad, pues los costos deeliminacin de defectos suelen ser mselevados que cualquier otro.
16 Seccin 1: Introduccin a laestimacin de costos de software
En segundo lugar, como elementos de
-
costo importantes, se encuentran gastos yesfuerzo dedicados a la produccin dedocumentos en papel: planes, especifi -
caciones, manuales de usuario, etc. En elcaso de proyectos de software militar, elpapeleo costar dos veces ms que elcdigo mismo. Tratndose de grandesproyectos civiles con ms de 1 000puntos funcin o 100 000 instruccionesde cdigo fuente, los documentos enpapel sern un elemento de costoimportante y se aproximarn oexcedern el costo del cdigo.
En tercer lugar, muchos proyectosgrandes sitan costos y fechas lmite enel manejo de requisitos progresivos o
-
nuevas caractersticas agregadas alproyecto, tras la fase de requisitos.Todos los desarrollos de softwarecrecern por requisitos progresivos y,por tanto, este factor debe ser parteintegral de las estimaciones de todos losproyectos de software importantes.
En el caso de grandes aplicacionesdistribuidas, implicando mltiples sitiosde desarrollo o subcontratistas, loscostos de reuniones y viticos,transportndose de un lugar a otropueden ser ms elevados que el delcdigo fuente y estar en el cuarto lugar,siguiendo la secuencia de los costos desoftware. Una omisin frecuente en lasestimaciones de costos es la exclusin
-
accidental de viticos (lneas areas,hoteles, etc.), para reuniones entreequipos de desarrollo en diferentesciudades o pases. En el caso desistemas muy grandes, como sistemasoperativos, sistemas detelecomunicaciones o sistemas dedefensa, pueden implicar desarrollodistribuido en media docena de pases yuna docena de ciudades; los viticospueden exceder el costo de la redaccindel cdigo de forma signifi cativa y eltema no debe omitirse de maneraaccidental.
Muchas estimaciones de costos desoftware (y diversos sistemas de medi-cin tambin) cubren slo actividades
-
centrales del desarrollo de software yomiten temas tales como administraciny soporte a proyectos (es decir,bibliotecarios del programa, secretarias,administracin, etc.). Estas actividadesauxiliares son parte del proyecto ypueden ascender, en algunos casos, a20% de los costos totales. Esto esdemasiado para omitirlo por accidente.
El dominio del software se hafragmentado en diversas habilidades yocupaciones especializadas. Es muycomn omitir las contribuciones deespecialistas si sus habilidades slo senecesitan en una etapa del ciclo dedesarrollo del software. Algunos gruposde especialistas que tienden a ser
-
omitidos accidentalmente de lasestimaciones de los costos de software,integraran las reas de control decalidad, redaccin tcnica, puntosfuncin, administracin de bases dedatos, optimizacin del rendimiento,redes y administracin de sistemas. Lasaportaciones combinadas de estos yotros especialistas pueden totalizar msde 20% del costo total para eldesarrollo de software y no debenomitirse de forma accidental.
La omisin ms comn de lasestimaciones internas de los costos desoftware para sistemas de informacin,son costos en que incurren los usuariosdurante la defi nicin de requisitos,
-
creacin de prototipos, revisiones deestado, revi-Captulo 1: Introduccin 17
siones de fases, documentacin,inspecciones, pruebas de aceptacin yotras actividades en que losdesarrolladores tienen un rol clave.Como los representantes de usuarios nosuelen considerarse parte del equipo delproyecto, sus contribuciones al proyectorara vez se incluyen en las estimacionesdel costo del software y estudios demedicin. El esfuerzo real que aportanlos usuari