Metodos de Evaluacion de SW

7/21/2019 Metodos de Evaluacion de SW

1/9

Mtodos de Estimacin de Costos de Software para Grandes Proyectos

El software ha alcanzado una mala reputacin pues ha sido considerado como una tecnologaperturbadora. Los grandes proyectos de software han tendido a tener una muy alta frecuencia de excesode calendarizacin, costos, problemas de calidad e indiscutibles cancelaciones. Mientras esta malareputacin a menudo es merecida, es importante notar que algunos grandes proyectos de software

finalizan a tiempo y con el presupuesto estimado, adems funcionan satisfactoriamente cuando !stosson desplegados.

Los grandes proyectos exitosos difieren en muchos sentidos de los fracasos y desastres "#ones $%%&'.(na diferencia importante es, cmo los proyectos exitosos concluyen a tiempo, dentro de los costos,recursos y estimacin de calidad pre)ista en un primer t!rmino. *e un anlisis de resultados de lasherramientas de estimacin usadas, publicado en +Estimacin de ostos de -oftware "#ones /001', eluso de instrumentos de estimacin automatizados conduce a estimaciones ms exactas. 2 la in)ersa,los m!todos informales o manuales de llegar en estimaciones iniciales son generalmente inexactos y amenudo excesi)amente optimistas.

(na comparacin de 3% estimaciones manuales con 3% estimaciones automatizadas para proyectos en

el rango de los 3%%% puntos de funcin, mostr resultados interesantes "#ones /001'. Las estimacionesmanuales fueron creadas por administradores de proyectos quienes usaban calculadoras y ho4as declculo. Las estimaciones automatizadas tambi!n fueron creadas por administradores de proyectos opor sus asistentes de estimacin, usando )arias herramientas de estimacin comercialmente diferentes.Las comparaciones fueron hechas entre las estimaciones originales presentadas a clientes y e4ecuti)oscorporati)os, y los resultados acumulados al final cuando las aplicaciones fueron puestas en prctica.

-olamente cuatro de las estimaciones manuales estu)ieron dentro del /%5 de los resultados reales.2proximadamente /6 estimaciones eran optimistas entre el /%5 y el 7%5. (na consternacin, $0proyectos fueron optimistas por ms del 7%5. Es decir, las estimaciones manuales rindieron costosba4os y calendarios cortos que lo ocurrido )erdaderamente, a )eces por cantidades insignificantes. "8orsupuesto )arias estimaciones re)isadas fueron creadas a lo largo del camino. 8ero la comparacin fue

entre la estimacin inicial y los resultados finales'.

8or contraste $$ de las estimaciones generadas por herramientas de estimacin comercial estu)ierondentro del /%5 real de los resultados. 2proximadamente $& fueron conser)adoras entre /%5 y $35.9res fueron conser)adoras por ms que $35. :nicamente una automatizada fue optimista, por cerca del/35.

(no de los problemas con los estudios desarrollados tal como es el hecho de muchos proyectosgrandes con estimaciones imprecisas fueron cancelados sin haber culminado. *e ese modo, para quelos proyectos estu)iesen incluidos en todo, ellos tendran que haber finalizado. Este criterio eliminmuchos proyectos que usaron tanto estimacin manual como automatizada.

*e modo interesante, las estimaciones manuales y las automatizadas eran equitati)amente cercanas ent!rminos de prediccin del esfuerzo de programacin o codificacin. 8ero las estimaciones fueron muyoptimistas cuando predecan el crecimiento de los requerimientos, esfuerzo del dise;o, esfuerzo dedocumentacin, esfuerzo de administracin, esfuerzo de e)aluacin y esfuerzo de re)isin y reparacin.La conclusin de la comparacin fue que tanto las estimaciones manuales como las automatizadas eranequi)alentes para la programacin real, pero las estimaciones automatizadas eran me4ores parapredecir acti)idades de no codificacin.


2/9

Este es un asunto importante para la estimacin de grandes aplicaciones de software. 8ara proyectosde software por deba4o de aproximadamente /%%% puntos de funcin en tama;o "equi)alente a /$3,%%%declaraciones ', la programacin es el mayor costo de mane4o, la exactitud de estimacin paracodificacin es un elemento cla)e. 8ero para proyectos sobre los /%,%%% puntos de funcin en tama;o"equi)alente a /,$3%,%%% declaraciones ', tanto la eliminacin de defectos como la produccin dedocumentos son ms costosas que el cdigo por s mismo. 8or lo tanto la exactitud en la estimacin de

esos tpicos es un factor cla)e.

Las estimaciones de tiempo y costo deberan ser exactas, naturalmente. 8ero si ellas difieren de losresultados reales, es ms seguro ser ligeramente conser)ador que ser optimista. (na de las principalesque4as sobre los proyectos de software se refiere a su tendencia alarmante de exceder gastos ycalendarios planificados. *esafortunadamente, tanto clientes como e4ecuti)os superiores tienden ae4ercer presiones considerables en los administradores de proyectos y en el personal encargado derealizar las estimaciones. 8or consiguiente un colorario oculto de estimacin acertada es aquel endonde !stas deben ser defendibles. La me4or defensa es una buena coleccin de datos histricos deproyectos similares.

*ebido a que el crecimiento de la estimacin de costos es una acti)idad comple4a, existe un crecimientoindustrial de compa;as dedicadas a ofrecer diferentes marcas comerciales de herramientas de

estimacin de costos en el mercado. 2 partir del $%%3, algunas de esas herramientas de estimacin son>, o-tar, ostModeler, ost?pert, @nowledge8lanA, 8B>E -, -EEB, -L>M y -oftost.2lgunas de las herramientas de estimacin de costos ms antiguas, no estn acti)amente en elmercado pero toda)a son utilizadas, tales como< hecC8oint, ==M=, E-9>M2-, BED> y-8BF$%, ya que su uso no es apoyado por los )endedores, por lo que su utilizacin est en decli)e.

Mientras estos instrumentos de estimacin fueron desarrollados por empresas diferentes y no sonid!nticos, ellos realmente tienden a proporcionar un nGcleo de funciones comunes. Los rasgosprincipales de instrumentos de estimacin de software comerciales en incluyen estos atributos-' son las siglas en ingl!s para Mangement >nformation -ystems. El +=utsource en software es


3/9

similar al M>-, pero realizado por una contratista externa. El software de +sistemas es aquel quecontrola los dispositi)os fsicos como sistemas de telecomunicaciones o computadoras. El softwaremilitar constituye todos los proyectos los cuales son obligados para seguir )arios estndares de ndolemilitar. El software comercial se refiere a paquetes ordinarios como procesadores de palabras, ho4as declculo y otros por el estilo.

Tabla 1: Actividades tpicas de desarrollo de software de seis tipos de aplicaciones !"os datos indican #$e el porcenta%e de esf$er&o de traba%o por actividad'

Actividades reali&adas (eb M)S *$tso$rce Comercial Sistema Militar

%/ Bequerimientos 3.%%5 6.3%5 0.%%5 &.%%5 &.%%5 6.%%5

%$ 8rototipo /%.%%5 $.%%5 $.3%5 /.%%5 $.%%5 $.%%5

%7 2rquitectura %.3%5 /.%%5 $.%%5 /.3%5 /.%%5

%& 8lanes del proyecto /.%%5 /.3%5 /.%%5 $.%%5 /.%%5

%3 *ise;o inicial 1.%%5 6.%%5 K.%%5 6.%%5 K.%%5

%K *ise;o en detalle 6.%%5 1.%%5 3.%%5 K.%%5 6.%%5%6 Be)isiones de dise;o %.3%5 /.3%5 $.3%5 /.%%5

%1 odficacin 7%.%%5 $%.%%5 /K.%%5 $7.%%5 $%.%%5 /K.%%5

%0 2dquisicin Beutilizacin 3.%%5 $.%%5 $.%%5 $.%%5 $.%%5

/% ompras de paquetes /.%%5 /.%%5 /.%%5 /.%%5

// >nspecciones de cdigo /.3%5 /.3%5 /.%%5

/$ Dalidacin y )erificacin /.%%5

/7 2dministracin de laconfiguracin

7.%%5 7.%%5 /.%%5 /.%%5 /.3%5

/& >ntegracin formal $.%%5 $.%%5 /.3%5 $.%%5 /.3%5

/3 *ocumentacin del usuario /%.%%5 6.%%5 0.%%5 /$.%%5 /%.%%5 /%.%%5

/K 8rueba de unidad 7%.%%5 &.%%5 7.3%5 $.3%5 3.%%5 7.%%5/6 8ruebas de funcin K.%%5 3.%%5 K.%%5 3.%%5 3.%%5

/1 8ruebas de integracin 3.%%5 3.%%5 &.%%5 3.%%5 3.%%5

/0 8ruebas de sistemas 6.%%5 3.%%5 6.%%5 3.%%5 K.%%5

$% 8ruebas de campo K.%%5 /.3%5 7.%%5

$/ 8ruebas de aceptacin 3.%%5 7.%%5 /.%%5 7.%%5

$$ 8ruebas independientes /.%%5

$7 2seguramiento de lacalidad

/.%%5 $.%%5 $.%%5 /.%%5

$& apacitacinF>nstalacin $.%%5 7.%%5 /.%%5 /.%%5

$3 2dministracin de proyecto /%.%%5 /$.%%5 /$.%%5 //.%%5 /$.%%5 /7.%%5

9otal /%%.%%5 /%%.%%5 /%%.%%5 /%%.%%5 /%%.%%5 /%%.%%52cti)idades 6 /K $% $/ $$ $3

La 9abla / es simplemente ilustrati)a, y los nGmeros reales de acti)idades realizadas y los porcenta4esde esfuerzo para cada acti)idad pueden )ariar. 8ara estimar proyectos reales, el instrumento deestimacin presentara el con4unto ms probable de acti)idades para ser realizadas. Entonces el 8ro4ectManager o el especialista en estimacin de costos a4ustara el con4unto de acti)idades quecorresponden a la realidad del proyecto. 2lgunos instrumentos de estimacin permiten a los usuariosa;adir acti)idades adicionales que no son parte del con4unto de acti)idades originales.


4/9

Generadores de Costos para Grandes Sistemas de Software: Traba%o Administrativo yEliminacin de de +efectos

En con4unto, los grandes proyectos de software dedican ms esfuerzo a la produccin de documentos ya la eliminacin de defectos que la produccin de un cdigo fuente. *e este modo, la estimacin exactapara grandes proyectos de software debe incluir el esfuerzo para producir documentos, y el esfuerzopara encontrar y reparar los defectos, entre otras cosas.

La in)encin de m!tricas de puntos de funcin "2lbrecht /01&' ha hecho de la lgica de e)aluacincompleta para documentos un caracterstica estndar de muchas herramientas de estimacin. (na delas razones para el desarrollo de las m!tricas de puntos de funcin fue pro)eer un m!todo de e)aluacinpara documentos entregables. 8ara informacin adicional sobre puntos de funcin, pueden entrar al-itio eb www,ifp$-,or-.

9abla $< >lustra e4emplos de tama;o de documentacin seleccionada a partir de sistemas, proyectosweb, M>-, =utsource, omercial, -istemas y dominios de software militar.

Tabla .: P/-inas de doc$mento por p$nto de f$ncin para seis tipos de aplicaciones !+atos e0presados en trminos de p/-inas por cada p$nto de f$ncin'

(eb M)S *$tso$rce Comercial Sistema Militar PromedioBequerimientos %.$3 %.3 %.33 %.7 %.&3 %.13 %.&1

Especificaciones defuncin

%./ %.33 %.33 %.K %.1 /.63 %.67

Especificaciones delgica

%.3 %.3 %.33 %.13 /.K3 %.1/

8lanes de prueba %./ %./ %./3 %.$3 %.$3 %.33 %.$7

uas de usuario %.%3 %./3 %.$ %.13 %.7 %.3 %.7&

Beferencia %.$ %.$3 %.0 %.7& %.13 %.3/

>nformes %./3 %.3 %.K %.& %.K3 $ %.6$

9otal %.K3 $.3 $.1 7.13 7.K& 1./3 7.K

2l menos una herramienta comercial de estimacin de software puede incluso predecir el nGmero depalabras en ingl!s en el con4unto de documentos y tambi!n los nGmeros de diagramas queprobablemente estn presentes. La estimacin de documento puede tambi!n cambiar basada oempapelar el tama;o tal como el papel 2& europeo. *e hecho, ahora es posible estimar los tama;osbasados en texto e incluso estimar los costos de traduccin de un idioma a otro para los proyectos queson desplegados internacionalmente.

Potenciales de +efecto de Software y iveles de Eficacia de Eliminacin de +efecto

(n aspecto cla)e de la estimacin de costo de software es predecir el tiempo y el esfuerzo que sernecesario para re)isiones de dise;o, inspecciones de cdigo, y todas las formas de pruebas. 8araestimar la eliminacin los costos de eliminacin de defecto y calendarios, es necesario conocer cuntosdefectos son susceptibles de ser encontrados.

La secuencia tpica es estimar los )olGmenes de defecto por un proyecto y entonces estimar la serie dere)isiones, inspecciones y pruebas que utilice el proyecto. La eficiencia en la eliminacin de defecto decada paso tambi!n sern estimada. Los costos y esfuerzo para la preparacin, e4ecucin y reparacinde defectos asociados con la acti)idad de eliminacin tambi!n sern estimadas.

9abla 7< >lustra la distribucin global de errores de software entre los seis mismos tipos de proyectosconocidos en la tabla /. En la 9abla 7, los defectos son mostrados a partir de cinco fuentes< errores derequerimientos, errores de dise;o, errores de codificacin, errores de documentacin de usuario y
http://www.ifpug.org/http://www.ifpug.org/


5/9

reparaciones malas. (na mala reparacin es un defecto secundario inyectado accidentalmente en undefecto reparado. En otras palabras una mala reparacin es una intencin fallida para reparar undefecto pre)io que por casualidad contiene un nue)o defecto. 8or regla general, aproximadamente el65 de las reparaciones de errores accidentalmente inyectarn un nue)o defecto, aunque la gama es demenos del /5 ms que el $%5 de inyecciones de mala reparacin.

Los datos en la Tabla 3 y en las otras tablas en este escrito, estn basadas en un total de

aproximadamente 12,000 proyectos de software evaluados por el autor y sus colegas alrededor de19!"200!# $nformaci%n adicional sobre las fuentes de datos puede ser encontrada en &'ones 199(),&'ones 199), and &'ones 2000)# Tambi*n pueden ver a &+an 2003)#

Tabla 2: Potenciales defectos promedios para seis tipos de aplicaciones !+atos e0presados en trminos de 3defectos por p$ntos de f$ncin3'

(eb M)S *$tso$rce Comercial Sistema Militar Promedio

Bequisitos / / /./ /.$3 /.7 /.6 /.$7

*ise;o / /.$3 /.$ /.7 /.3 /.63 /.77

digo /.$3 /.63 /.6 /.63 /.1 /.63 /.K6

*ocumentos %.7 %.K %.3 %.6 %.6 /.$ %.K6

Mala reparacin %.&3 %.& %.7 %.3 %.6 %.K %.&09otal & 3 &.1 3.3 K 6 3.71

La 9abla 7 presenta )alores de promedio aproximados, pero en el rango de cada categora de defecto esms que $ a /. 8or e4emplo, los proyectos de software desarrollados por compa;as que estn en elni)el cinco sobre su modelo de capacidad de madurez, pudieran tener menos de la mitad de losdefectos potenciales expuestos en la 9abla 7. >gualmente, para las compa;as con )arios a;os deexperiencia con el +-ix -igma, la calidad aproximada tambi!n tendra potenciales de defectos ba4os queestn mostrados en este cuadro. Darias herramientas comerciales de estimacin hacen a4ustes paracada factor.

(n factor cla)e para la estimacin exacta in)olucra la eliminacin de defectos a tra)!s de re)isiones,

inspecciones y e)aluacin. La medida de remocin de defectos es de hecho bastante sencilla y muchasempresas ahora hacen esto. El promedio de los Estados (nidos es aproximadamente 135, pero lasempresas destacadas pueden promediar ms del 035 de ni)eles de eficiencia de eliminacin dedefectos "#ones /006'.

Es ms fcil estimar proyectos de software que utilizar controles de calidad sofisticados y tener altosni)eles de eliminar el defecto en el 035 de las posibilidades. Esto es porque generalmente no hayocurrencias tardas de desastres en desarrollo cuando aparecen defectos inesperados. 2s los proyectosrealizados por compa;as en los ms altos ni)eles de MM o por compa;as con amplia experiencia enN-ix -igmaN para software, frecuentemente tienen muchas ms precisin que el promedio.

La 9abla & ilustra las )ariaciones en pre)encin de defectos tpicos y m!todos de remocin de defectosentre los seis dominios ya discutidos. 8or supuesto, muchas )ariaciones pueden ocurrir en esosmodelos.

"Los )alores de eficiencia acumulati)os en la 9abla & son calculados as< -i el nGmero de partida dedefectos es /%%, y hay dos etapas de prueba consecuti)as que cada una elimina el 3%5 de los defectospresentes, entonces la primera prueba remo)er 3% defectos y la segunda prueba quitar $3 defectos.La eficacia acumulati)a de ambas pruebas es de 635, porque 63 de los /%% defectos posibles fueroneliminados.'

Tabla 4: Patrones de la prevencin de defectos y eliminacin de actividades


6/9

eb M)S *$tso$rce Comercial Sistema Militar

Actividades deprevencin

8rototipos $%.%%5 $%.%%5 $%.%%5 $%.%%5 $%.%%5 $%.%%5

uartos limpios $%.%%5 $%.%%5

-esiones #2* 7%.%%5 7%.%%5

-esiones *O $3.%%5

ubtotal $%.%%5 &&.%%5 &&.%%5 $%.%%5 3$.%%5 7K.%%5

Pre5pr$ebas deeliminacin

Be)isin deescritorio

/3.%%5 /3.%%5 /3.%%5 /3.%%5 /3.%%5 /3.%%5

Be)isin de requerimiento 7%.%%5 $3.%%5 $%.%%5 $%.%%5

Be)isin dedise;o

&%.%%5 &3.%%5 &3.%%5 7%.%%5

Be)isin de

documentos

$%.%%5 $%.%%5 $%.%%5

>nspeccin decdigo

3%.%%5 K%.%%5 &%.%%5

Dalidacin y)erificacin

$%.%%5

8ruebas decorreccin

/%.%%5

Laboratorios deusabilidad

$3.%%5

ubtotal /3.%%5 /3.%%5 K&.7%5 10.&15 11.%75 17.335

Actividades de

eval$acin8rueba deunidad

7%.%%5 $3.%%5 $3.%%5 $3.%%5 $3.%%5 $3.%%5

Iue)a pruebade funcin

7%.%%5 7%.%%5 7%.%%5 7%.%%5 7%.%%5

8ruebas deregresin

$%.%%5 $%.%%5 $%.%%5 $%.%%5

8ruebas deintegracin

7%.%%5 7%.%%5 7%.%%5 7%.%%5 7%.%%5

8ruebas dedesempe;o

/3.%%5 /3.%%5 /3.%%5

8ruebas delsistema

73.%%5 73.%%5 73.%%5 &%.%%5 73.%%5

8ruebasindependientes

/3.%%5

8ruebas decampo

3%.%%5 73.%%5 7%.%%5

8ruebas deaceptacin

$3.%%5 $3.%%5 7%.%%5

ubtotal 7%.%%5 6K.//5 1%.105 0/.115 0$.K05 07.K75

Bendimiento 3$.&%5 11.K75 0K./15 00.7$5 00.315 00.775


7/9

global

IGmero deacti)idades

7 6 // /& /K /1

La 9abla & simplifica demasiado la situacin, ya que las acti)idades de eliminacin de defecto tieneneficiencias )ariables para los requerimientos, dise;o, codificacin, documentacin, y categoras dedefectos mal reparados. *el mismo modo, las malas reparaciones durante la e)aluacin serncolocadas detrs del con4unto de defectos no detectados.

La ba4a eficiencia de la mayora de las formas de la eliminacin de defectos explica por qu! una largaserie de acti)idades de remocin de defectos son necesarias. Esto explica por qu! la estimacin deeliminacin de defecto es crtica para la exactitud total de la estimacin de costos de software paragrandes sistemas. *eba4o de los /%%% puntos de funcin las series pueden incluir ms de una docenade tipos de re)isin, inspeccin y acti)idad de e)aluacin.

Cambios de re#$erimientos y estimacin de software

(n aspecto importante de estimacin es la relacin con el ndice en el cual los requerimientos NsecorrompenN y por consiguiente generan que los proyectos crezcan ms durante el desarrollo. 8or suerte,la m!trica de punto de funcin permite la medicin directa del ndice en el cual este fenmeno ocurre, yaque tanto los requerimientos originales como los requerimientos modificados tendrn cuentas de puntosde funcin.

El cambio de requerimientos puede ocurrir en cualquier momento, pero los datos en la 9abla 3 )andesde del final de la fase de requerimientos al inicio de la fase de codificacin. Este perodo de tiempopor lo general refle4a aproximadamente la mitad de del calendario de desarrollo total. La 9abla 3presenta el pago mensual aproximado de requerimientos que se corrompen para seis clases desoftware, y el )olumen total de cambio que podra ser esperadoncluso, las estimaciones iniciales hechaspara proyectos que usan #2* predecirn los )olGmenes reducidos de exigencias que se cambian.

8actores de A%$ste para Estimaciones de Software


8/9

uando son usadas para )erdaderos proyectos de software, las suposiciones bsicas de falta deherramientas de estimacin deben ser a4ustadas para empare4ar la realidad del proyecto que estsiendo estimado. Estos factores de a4uste son una porcin crtica del uso de herramientas de estimacinde software. 2lgunos de los factores de a4ustes disponibles incluyen9F2FL2-F0K-J//, 2ir Oorce >nstitute of9echnology "2O>9', right 8atterson 2OR, =hioQ -eptember /00KQ //0 pages.

8arC, Bobert E. et alQ -oftware ost and -chedule Estimating J 2 8rocess >mpro)ement>nitiati)eQ 9echnical Beport M(F-E> 0&J-BJ%7Q -oftware Engineering >nstitute, 8ittsburgh, 82QMay /00&.

8arC, Bobert E. et alQ hecClists and riteria for E)aluating the osts and -chedule Estimatingapabilities of -oftware =rganizationsQ 9echnical Beport M(F-E> 03J-BJ%%3Q -oftwareEngineering >nstitute, 8ittsburgh, 82Q #anuary /003.

8utnam, Lawrence T.Q Measures for Excellence JJ Beliable -oftware =n 9ime, ithin RudgetQSourdon 8ress J 8rentice Tall, Englewood liffs, I#Q >-RI %J/7J3K6K0&J%Q /00$Q 77K pages.

8utnam, Lawrence T and Myers, are.Q >ndustrial -trength -oftware J Effecti)e Management(sing MeasurementQ >EEE 8ress, Los 2lamitos, 2Q >-RI %J1/1KJ637$J$Q /006Q 7$% pages.

Boetzheim, illiam T. and Reasley, Beyna 2.Q Rest 8ractices in -oftware ost and -cheduleEstimationQ 8rentice Tall 89B, -addle Bi)er, I#Q /001.

-tuCes, -herry, *eshoretz, #ason, 2pgar, Tenry and Macias, >lonaQ 2ir Oorce ost 2nalysis

2gency -oftware Estimating Model 2nalysis Q 9BJ03&3F%%1J$Q ontract O%&6%/J03J*J%%%7, 9asC%%1Q Management onsulting W Besearch, >nc.Q 9housand =aCs, 2 0/7K$Q -eptember 7%/00K.

Metodos de Evaluacion de SW

Documents

Transcript of Metodos de Evaluacion de SW