estimacia3n de costos y adminis - jones, capers(author)

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


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


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


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


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


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


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


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:


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.


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.


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


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.


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

estimacia3n de costos y adminis - jones, capers(author)

Documents