www.monografias.

com

Estimacin de software basada en puntos de casos de uso. Ejemplo prctico

1. 2. 3. 4. . Resumen Introduccin Planificacin basada en casos de uso Conclusiones !iblio"raf#a

Resumen
Aunque la estimacin es ms un arte que una ciencia no es aconsejable embarcarse sin ella. En el mundo actual de la informtica y las comunicaciones muchos proyectos fracasan por no llevar a cabo de manera correcta esta actividad. Para un proyecto de software es necesario conocer el esfuerzo y el costo que tiene implicado. Para ello son muchos los m todos de estimacin que e!isten en la actualidad" #$%&' ()()&) %%' *uicio E!perto' Analog+a' algunos basados en t cnicas estad+sticas e %nteligencia Artificial que se basan en datos histricos para inferir el esfuerzo de nuevos proyectos. Algunos de los m todos antes mencionados se basan en paradigmas de programacin antiguos. Por la importancia del paradigma )rientado a )bjetos y la metodolog+a ,-P' este trabajo se encarga de describir el m todo de estimacin basado en Puntos de (asos de -so a trav s de un caso prctico' un sistema .eb para la gestin de la actividad telefnica en un (entro de Educacin #uperior' y mostrar las ventajas y desventajas del mismo.

Introduccin
Aunque la estimacin es ms un arte que una ciencia' es una actividad importante que no debe llevarse a cabo de forma descuidada. E!isten t cnicas /tiles para la estimacin de costes y de tiempos. 0 dado que la estimacin es la base de todas las dems actividades de planificacin del proyecto y sirve como una gu+a para una buena ingenier+a del software' no es en absoluto aconsejable embarcarse sin ella. 123 El objetivo de la Estimacin es predecir las variables involucradas en el proyecto con cierto grado de certeza. #e trata de aportar una prediccin de alg/n indicador importante para la gestin de proyectos de software" tiempo' esfuerzo' cantidad de defectos esperados' entre otros' sin dejar de tener en cuenta que la incertidumbre y el riesgo son elementos inherentes. En la actualidad son muchos los proyectos que fracasan e incumplen sus plazos de entrega. #eg/n el 4he #tandish 5roup en su publicacin (haos ,eport 6778' determin que el 69: de los proyectos informticos fueron cancelados' solo el ;6 : terminaron a tiempo y dentro del presupuesto y el 99: de los proyectos de software fueron concluidos despu s de la fecha estimada. #on muchos los m todos de estimacin del esfuerzo que e!isten en la actualidad" #$%&' ()()&) %%' *uicio E!perto' Analog+a' algunos basados en t cnicas estad+sticas e %nteligencia Artificial que se basan en datos histricos para inferir el esfuerzo de nuevos proyectos. El objetivo de este trabajo es describir el m todo de estimacin basado en Puntos de (asos de -so a trav s de un caso prctico y mostrar las ventajas y desventajas del mismo. El m todo escogido se acopla con la metodolog+a ms usada hasta nuestros d+as' la metodolog+a ,-P <Proceso -nificado de ,ational=' esta metodolog+a se basa en la identificacin de los casos de uso' encargados de dirigir el proceso y la t cnica escogida toma como punto de partida estos elementos. $E%&RR'(('

Planificacin basada en casos de uso

Para ver trabajos similares o recibir informacin semanal sobre nuevas publicaciones' visite www.monografias.com

www.monografias.com

Este m todo de estimacin de proyectos de software fue desarrollado en 288; por 5ustav >arner de ,ational #oftware y est basado en una metodolog+a orientada a objetos' dndole el nombre de ?estimacin de esfuerzos con casos de uso@. #urgi como una mejora al m todo de puntos de funcin pero basando las estimaciones en el modelo de casos de uso' producto del anlisis de requerimientos. #eg/n su autor' la funcionalidad vista por el usuario <modelo de casos de uso= es la base para estimar el tamaAo del software. 163 -n caso de uso por s+ solo no permite efectuar una estimacin de esfuerzos ni de tiempos' los casos de uso son solamente herramientas para el anlisis. $a idea fundamental es predecir el tamaAo del software a partir de los requerimientos de los casos de uso. El objetivo fundamental de esta t cnica es" Estimar las horas necesarias para ejecutar un conjunto de casos de uso. Es decir' necesitamos predecir cunto tiempo llevar el desarrollo de software y cuntas personas se requieren para realizarlo. Para ello' es necesario cuantificar la complejidad del sistema y el tiempo necesario para producir una unidad de complejidad. En etapas tempranas del ciclo de vida' se identifican los Actores y los (asos de -so del sistema' y se documenta cada uno de ellos mediante una breve descripcin. Aplicando el Anlisis de Puntos de Buncin a estos (asos de -so' se podr obtener una estimacin grosera del tamaAo y a partir de ella del esfuerzo. Esta estimacin es bastante imprecisa debido principalmente a la escasa informacin que se tiene sobre el software al principio de un proyecto' pero permitir obtener una idea del esfuerzo necesario para llevar adelante el mismo' y podr ser refinada a medida que se obtenga ms. El ejemplo prctico a trav s del cual se describir el m todo consiste en una aplicacin .eb para la gestin de informacin telefnica' de reportes de aver+as' y de estad+sticas de los estados de los tel fonos de un (entro de Educacin #uperior <(E#=. Actualmente este proceso se realiza manualmente' provocando dificultades en la organizacin y control de la informacin referente a los equipos telefnicos y a sus respectivos usuarios. $a aplicacin es desarrollada en la plataforma .Cet' con lenguaje (D. A continuacin se presentan los actores y casos de uso identificados.

Clculo de Puntos de Casos de )so sin &justar *))CP+ Para la estimacin el primer paso que se lleva a cabo es el clculo de los Puntos de (asos de -so sin ajustar. Este valor se calcula a partir de la siguiente ecuacin" --(P E -A. F --(. donde' --(P" Puntos de (asos de -so sin ajustar -A." Bactor de Peso de los Actores sin ajustar --(." Bactor de Peso de los (asos de -so sin ajustar $eterminacin del factor de peso de los actores sin ajustar *)&,+. Este valor se calcula mediante un anlisis de la cantidad de Actores presentes en el sistema y la complejidad de cada uno de ellos. $a complejidad de los actores se establece' teniendo en cuenta en primer lugar' si se trata de una persona o de otro sistema' y en segundo lugar' la forma en que el actor interact/a con el sistema . -actores de peso de los actores. 4ipo de actor #imple Gescripcin )tro sistema que interact/a con el sistema a desarrollar mediante una interfaz de programacin<AP%' Aplication Bactor de peso 2 C/mero actores 7 de Resultado 0

Para ver trabajos similares o recibir informacin semanal sobre nuevas publicaciones' visite www.monografias.com

www.monografias.com

Promedio

(omplejo

Programming %nterface= )tro sistema que interact/a con el sistema a desarrollar mediante un protocolo o una interfaz basada en te!to. -na persona que interact/a con el sistema mediante una interfaz grfica.

Total -A. E 8

Determinacin del factor de peso en los casos de uso sin ajustar (UUCW). Este valor se calcula mediante un anlisis de la cantidad de (asos de -so presentes en el sistema y la complejidad de cada uno de ellos. $a complejidad de los casos de uso se establecen teniendo en cuenta la cantidad de transacciones efectuadas en el mismo' donde una transaccin se entiende como una secuencia de actividades atmicas. -actores de peso de los casos de uso. 4ipo de caso de uso #imple Promedio (omplejo Gescripcin 2H; 4ransacciones 9HK 4ransacciones &ayor de J 4ransacciones. Bactor de peso I 27 2I C/mero (asos de -so J 8 6 Total de Resultado 40 90 30 160

--(. E 2L7 (alculando --(P E -A. F --(. --(P E 8 F 2L7 --(P E 2L8 .2.2 Clculo de Puntos de Casos de )so ajustados #eguidamente de calcular los Puntos de (asos de -so sin ajustar' se debe ajustar este valor mediante la siguiente ecuacin" -(P E --(P ! 4(B ! EB donde' -(P" Puntos de (asos de -so ajustados --(P" Puntos de (asos de -so sin ajustar 4(B" Bactor de complejidad t cnica EB" Bactor de ambiente 5.2.2.1 Determinacin del factor de complejidad tcnica (TCF) Este coeficiente se calcula mediante la cuantificacin de un conjunto de factores que determinan la complejidad t cnica del sistema. (ada uno de los factores se cuantifica con un valor de 7 a I' donde 7 significa un aporte irrelevante y I un aporte muy importante. 1623 .abla 1/. -actores de complejidad t0cnica. C/mero factor 42 46 de Gescripcin #istema Gistribuido 4iempo respuesta Peso 6 de 2 Malor 2 2 Bactor 6 2 Comentario El sistema es Web, por lo que posee cierto nivel de distribucin El tiempo de respuesta respalda los ob etivos que se persi!uen con el pro"ecto reali#ado, por lo que es el adecuado$ %l!unos roles necesitan estar relacionados con el sistema para

4;

Eficiencia por el usuario

Para ver trabajos similares o recibir informacin semanal sobre nuevas publicaciones' visite www.monografias.com

www.monografias.com

49

Proceso interno complejo

4I

,eusabilidad

4L

Bacilidad instalacin

de

7.I

7.I

4K

Bacilidad de uso

7.I

6.I

4J

Portabilidad

27

48

Bacilidad cambio

de

427 422

(oncurrencia )bjetivos especiales seguridad

2 2 de

I I

I I

426 42;

Acceso directo a terceras partes Bacilidades especiales de entrenamiento a usuarios finales

2 2

6 2

6 2

su me or &uncionamiento$ El sistema no posee c'lculos comple os, aunque proporciona una serie de datos l!icos que necesitan un nivel medio de conocimiento para lo!rar su correcta comprensin$ (o es ob etivo esencial )acer reusabilidad del cdi!o, a pesar de que este ser' orientado a ob etos " podr' ser usado por sistemas similares$ *or ser un sistema Web la comple idad de instalacin es m+nima$ El sistema debe ser &'cil de usar, aunque se encuentra diri!ido a personas a enas al centro adem's$ El sistema se encuentra dise,ado para que sea usado en situaciones similares en otras empresas, adem's como est' desarrollado en $(et puede ser publicado en cualquier plata&orma$ El sistema encuentra estructurada para que los cambios reali#ados a&ecten lo menos posible las &uncionalidades del sistema$ -a concurrencia es tratada con suma importancia$ -a se!uridad del sistema es un tema bastante controlado, "a que el sistema slo permite que un usuario realice las &uncionalidades correspondientes a su rol dentro del sitio$ -a aplicacin es accesible a cualquier usuario$ (o se )ace necesario el entrenamiento de los usuarios &inales, debido a la &acilidad de uso que presenta el sistema, pero se debe incluir un manual de usuario para !aranti#ar la correcta usabilidad de dic)o sistema$

Total .actor

4/

El Bactor de complejidad t cnica se calcula mediante la siguiente ecuacin"

Para ver trabajos similares o recibir informacin semanal sobre nuevas publicaciones' visite www.monografias.com

www.monografias.com

Determinacin del factor am iente (!F) $as habilidades y el entrenamiento del grupo involucrado en el desarrollo tienen un gran impacto en las estimaciones de tiempo. Estos factores son los que se contemplan en el clculo del Bactor de ambiente. -actores de ambiente. C/mero del factor E2 Gescripcin Bamiliaridad con el modelo del proyecto usado. E!periencia aplicacin en la Peso 2.I Malor ; Bactor 9.I Comentario 0e est' &amiliari#ado con el modelo del pro"ecto, pero la e1periencia en el modelado es media$ (o es una aplicacin que requiera de muc)a e1periencia, pero se necesita de un equipo capacitado " de conocimientos su&icientes para !aranti#ar su correcto &uncionamiento$ 0e considera cierto !rado de e1periencia en la pro!ramacin orientada a ob etos 2334, debido a que esta es la que se )a estudiado " traba ado$ (o e1iste analista l+der, los analistas que inte!ran el equipo de traba o poseen capacidad media$ %lta %unque el sistema se encuentra su eto a cambios, el mismo brinda las &uncionalidades esenciales que dan cumplimiento a los ob etivos que iniciaron su reali#acin$ 0e traba ar' a tiempo completo$ Como el len!ua e empleado &ue C5 " este o&rece !randes &acilidades " venta as, se considera una di&icultad media su empleo$

E6

7.I

E;

E!periencia )).

E9

(apacidad analista l+der.

del

7.I

2.I

EI EL

&otivacin. Estabilidad de requerimientos.

los

2 6

I 9

I J

EK EJ

Personal media jornada. Gificultad en lenguaje de programacin.

H2 H2

7 ;

7 H;

Total

//

El factor de ambiente se calcula mediante la siguiente ecuacin"

(lculo de los Puntos de de (asos de -so Ajustados" -(P E --(P N 4(B N EB -(P E 2L8 N 2.76 N 7.K9

Para ver trabajos similares o recibir informacin semanal sobre nuevas publicaciones' visite www.monografias.com

www.monografias.com

-(P E 26K.IL .2.3 Clculo del esfuer1o El esfuerzo en horasHhombre viene dado por" E E -(P N (B donde" E" esfuerzo estimado en horasHhombre. -(P" Puntos de casos de uso ajustados. (B" Bactor de conversin <67 horasHhombre por defecto=. E E 26K.IL N 67 E E 6II2.6 OorasHhombres #e debe tener en cuenta que ste m todo proporciona una estimacin del esfuerzo en horasHhombre contemplando slo el desarrollo de la funcionalidad especificada en los casos de uso. Para la obtencin de una estimacin ms e!acta de la duracin del proyecto' se hace necesario agregar a la estimacin del esfuerzo obtenida por los Puntos de (asos de -so' las estimaciones de esfuerzo de las restantes actividades que se llevaron a cabo durante el desarrollo del softwareP as+ se la distribucin del esfuerzo entre dichas actividades est dada por la siguiente apro!imacin" $istribucin "en0rica del esfuer1o. Actividad Anlisis GiseAo Programacin Pruebas 0obrecar!a2otras actividades4 *orcenta e 10$006 /0$006 40$006 17$006 17$006

(on este criterio y tomando como entrada la estimacin de tiempo calculada a partir de los Puntos de (asos de -so' se pueden calcular las dems estimaciones para obtener la duracin total del proyecto. $istribucin real del esfuer1o. Actividad Anlisis GiseAo Programacin Pruebas #obrecarga<otras actividades= Total *orcenta e 638$9 1/87$6 /771$/ 976$8 976$8 6389

(lculo del esfuerzo total" E4otal E L;KJ horas Qhombre (lculo del tiempo de desarrollo" 4Gesarrollo E E4otalQ(O4otal (O4otal" (antidad de hombres 4Gesarrollo E L;KJQ6 4Gesarrollo E ;2J8 horas (onsiderando que se trabajan J horas diarias" 4Gesarrollo E 4GesarrolloQJ horasQd+a 4Gesarrollo E ;2J8 horasQJ horasQd+a

Para ver trabajos similares o recibir informacin semanal sobre nuevas publicaciones' visite www.monografias.com

www.monografias.com

4Gesarrollo E ;88 d+as apro!imadamente (lculo del costo" (osto4otal E E4otal N 6 N 4O (osto4otal E L;KJ N 6 N 2.7;2 (osto4otal E 2;2I2.9I 4O" 4arifa horaria<E 2.7;2=

(onsiderando los resultados arrojados respecto a la factibilidad del software despu s del estudio realizado en este cap+tulo' se concluye que brinda suficientes beneficios para cubrir sus costos' o sea' que se aconseja la realizacin del sistema en el (E#' ya que es factible y econmicoP el mismo implicar un esfuerzo total de L;KJ horas Qhombre' para un tiempo de desarrollo de ;88 d+as apro!imadamente' se contarn con 6 hombres para su realizacin' lo que implica un costo de R2;2I2.9I para una tarifa horaria de R2.7;2. Entre las cosas buenas del m todo se puede citar que trabaja bien con diferentes tipos de software' siempre que sigan un paradigma orientado a objetos' muestra buen rendimiento en proyectos pequeAos' medianos y grandes. Es una nueva m trica que se adapta mejor a paradigmas ms avanzados de programacin e %ngenier+a de #oftware. El m todo no est e!ento de problemas que hacen que no se haya consolidado' entre estos problemas destacan la no e!istencia de un estndar para describir casos de uso' eso hace que aplicar la m trica sea ms engorroso' hay un alto grado de subjetividad a la hora de calcular los factores t cnicos y ambientales que hacen que el clculo no sea del todo realista. #e puede observar que entre los autores que han usado los -(P no se distingue un criterio /nico aplicado para el clculo de la complejidad de un caso de uso" por ejemplo' Anda <Anda et al.' 677I= y Giev <Giev' 677L= no tienen en cuenta los objetos de anlisis. Adems' tambi n e!isten diferentes criterios para identificar una transaccin. -nos definen la transaccin como un conjunto atmico de actividades entre el actor y el sistema' que debe ser realizado en forma completa <Anda et al.' 6772P Anda et al.' 6776P Anda et al.' 677IP (arroll' 677IP Giev' 677L=. )tros claramente definen las diferencias entre transacciones y escenarios <Giev' 677L=' mientras otros no hacen ninguna diferencia entre ellos <Anda et al. 677I=. Oay otro que define el n/mero de transacciones como el n/mero de transacciones dentro de los escenarios de un caso de uso <%ssa' 677L=.

Conclusiones
En el presente art+culo se ha descrito el m todo de estimacin por puntos de casos de uso' a trav s del caso prctico de una aplicacin .eb diseAada e implementada para un centro de educacin superior. #e arribaron a conclusiones acerca de la viabilidad del proyecto usando dicho m todo. Por otra parte se desprendieron algunas de las ventajas y desventajas que presentan los puntos de casos de uso $a estimacin por Puntos de (aso de -so resulta muy efectiva para estimar el esfuerzo requerido en el desarrollo de los primeros (asos de -so de un sistema' si se sigue una apro!imacin iterativa como el Proceso -nificado de ,ational. En ste tipo de apro!imacin' los primeros (asos de -so a desarrollar son los que ejercitan la mayor parte de la arquitectura del software y los que a su vez ayudan a mitigar los riesgos ms significativos <iteraciones de Elaboracin en el Proceso -nificado=. Buera de ste conte!to' el m todo tiende a sobredimensionar el esfuerzo requerido.

Bibliografa
123 ,oger #. Pressman. <288J=. :n!enier+a del so&t;are, un en&oque pr'ctico' EspaAa' Ed. &c5rawHOill. 163Malero )rea' #ergio .E#4%&A(%SC GE P,)0E(4)# GE #)B4.A,E ()C P-C4)# GE (A#)# GE -#). ,oy >. (lemmons. <677L=. *ro ect estimation ;it) <se Case *oints. EE--' (rosstalT" 4he *ournal of Gefense #oftware Engineering. ,eportes 4 cnicos en %ngenier+a de #oftware Mol. L CU 2 <6779=' pg. 2H2L. E#4%&A(%SC GE$ E#B-E,V) WA#AGA EC (A#)# GE -#). &ario Peralta Autor" (iann2 '3-arrill -ernnde1 lofarrill4ucl5.edu.cu

Para ver trabajos similares o recibir informacin semanal sobre nuevas publicaciones' visite www.monografias.com