85Gerenc. Tecnol. Inform. | Vol. 9 | N 25 | Sep - Dic | pp 85 - 93PARTICIPACIN DE LOS CASOS DE USO EN LA SOLUCIN DE LOS PROBLEMAS DE UNA ORGANIZACINUSE CASES PERFORMANCE IN ORGANIZATIONAL PROBLEM SOLVINGRECEPCIN: Abril 30 de 2010ACEPTACIN: Mayo 23 de 2010AUTORCARLOS MARIO ZAPATA JARAMILLO Ph.D.*Universidad Nacional de Colombia Profesor Asociado Escuela de Sistemascmzapata@unal.edu.coCOLOMBIAAUTORGLORIA LUCIA GIRALDO GMEZPh.D.*Universidad Nacional de Colombia Profesora Asociada Escuela de Sistemasglgiraldog@unal.edu.coCOLOMBIAAUTORDAVID ANDRS MORENO NIOPh.D.Estudiante de Ingeniera de Sistemas e Informtica*Universidad Nacional de ColombiaEscuela de Sistemasdamorenon@unal.edu.coCOLOMBIAINSTITUCIN*UNIVERSIDAD NACIONAL DE COLOMBIAUNAL MedellnUniversidadCarrera 80 No 65-223 Medelln, Antioquia cmzapata@unal.edu.coCOLOMBIATEMTICA: Ingeniera del softwareTIPO DE ARTCULO: Artculo de RefexinPARTICIPACIN DE LOS CASOS DE USO86ANALYTICAL SUMMARYOrganizations reach their goals and solve their problems bymakingdecisions.AccordingtoKepner-Tregoe methodology,goalsandproblemsmustbetracedto thesolution,inordertocompletethemostsuitable solution.However,UN-Metodoelicitationrequirement processdoesnothavesuchrelationshipbetween problemanalysisandsolutionassessmentappliances; so, the analyst job involves subjectivity when a software solutionisdeveloped.Forthisreason,inthispaper we propose a use cases performance in organizational problemsolvingmethod.Ourmaingoalisallowing traceabilityrelationshipapplicationtotheappliances involved, in order to make a more-objective assessment of the solution.KEYWORDSRequirementselicitation,Solutionassessment,Use cases, TraceabilityRESUMEN ANALTICOMediante las decisiones que toman, las organizaciones logran sus objetivos y superan los problemas que surgen. Segn la metodologa Kepner-Tregoe, se puede establecer una relacin secuencial o detrazabilidadentreladefnicindeunasolucin,susproblemasysusobjetivos,conelfnde encontrarlamsadecuada.Sinembargo,estarelacinnoseaplicaalprocesodeeduccinde requisitos en el mtodo de desarrollo UN-Mtodo y el anlisis de la problemtica de la organizacin ylavaloracindelimpactoquelaaplicacindesoftwaretienesobreella,larealizaelanalista subjetivamente. Por ello, en este artculo se propone un mtodo para determinar la participacin de los casos de uso en la solucin de los problemas de una organizacin, de modo que se aplique la relacin de trazabilidad que se puede establecer entre los artefactos que se afectan al introducir unasolucinsoftwarealaorganizacin,conelpropsitodequeserealiceunavaloracinms objetiva de dicha aplicacin de software.PALABRAS CLAVES: Educcin de requisitos, Valoracin de soluciones, Casos de uso, TrazabilidadINTRODUCCINToda organizacin tiene objetivos que alcanzar, pero, cuandosepresentaunacondicindedesequilibrio ensusprocesos,deberealizarunanlisisprofundo delaproblemticaparatomarlasdecisionesque permitanencontrarlasolucinmsadecuada. KepneryTregoe[8]proponenunametodologaque estableceunarelacinsecuencialentreladefnicin de los problemas, las decisiones y el planteamiento de objetivos de una solucin.En el mtodo de desarrollo de software UN-Mtodo [1], en la etapa de educcin de requisitos, se propone el anlisis de los objetivos y de la problemtica de la organizacin. Endichomtodo,losobjetivosserepresentanconel diagrama de KAOS [5] y la problemtica con el diagrama causa-efecto[7].Elmtodopretendedeterminarla manera como los objetivos y los problemas infuyen en los procesos de la organizacin, para luego proceder a analizar la posible solucin informtica, la cual se modela mediante los casos de uso. As, el analista determinar quproblemasdeberatacarensutotalidad,cules podromitiroculesatacarparcialmente,sinalejarse delobjetivogeneralquejustifcalacreacindel software [1]. Sin embargo, aunque UN-Mtodo procura elanlisisdelimpactodelaaplicacindesoftware sobrelosproblemasdelaorganizacin,laasignacin del porcentaje de actuacin de los casos de uso sobre los problemas se realiza subjetivamente, y no toman en consideracinotrosartefactosquetambinseafectan conlasolucinsoftware,locualserefejaraenun desfasealahoraderealizarlavaloracinfnaldela propuesta de solucin, afectando, consecuentemente, la consistencia y trazabilidad de los modelos.Por las razones antes anotadas, y como complemento a los trabajos de [14] y [1], en este artculo se propone un mtodo para determinar el porcentaje de actuacin queloscasosdeusotienensobrelascausasdelos problemas,demaneraqueserealiceunavaloracin ms objetiva del impacto de la aplicacin de software. Elmtodopropuestonoslotieneencuentalas ponderaciones de la problemtica, sino que tambin se aplica la relacin de trazabilidad que se puede establecer entrelosprocesos,losproblemasquelosafectanyla estructura jerrquica de los objetivos de la organizacin.Esteartculoseorganizadelasiguientemanera:en laseccin1sepresentaelmarcoterico,endonde serevisatantolarelacinqueexisteentreobjetivos, problemas y procesos, como los conceptos involucrados en la valoracin de la solucin software. En la seccin 2, Gerenc. Tecnol. Inform. | Vol. 9 | N 25 | Sep - Dic | Zapata, Giraldo, MorenoGerenc. Tecnol. Inform. | Vol. 9 | N 25 | Sep - Dic | Zapata, Giraldo, MorenoPARTICIPACIN DE LOS CASOS DE USO87sepresentanlosantecedentes,endondesehaceuna revisindealgunostrabajosqueprocuranunamejor trazabilidadentreloscasosdeusoyotrosartefactos propios del modelado de soluciones informticas. En la seccin 3 se propone el mtodo para determinar de una maneramsobjetivalaparticipacindeloscasosde usoenlasolucindeproblemasdeunaorganizacin, tomando en consideracin dicha relacin de trazabilidad. Finalmente, en la seccin 4 se presentan las conclusiones y el trabajo futuro.CONTENIDO 1.MARCO TERICO1.1 TRAZABILIDADENTRELOSPROCESOS ORGANIZACIONALES,LOSPROBLEMASY LOS OBJETIVOS.Todaorganizacintienemetasquealcanzary,de acuerdo con su nivel de abstraccin, se pueden clasifcar en: objetivos de alto nivel o estratgicos, de bajo nivel o tcnicos, funcionales, que corresponden a los procesos querealizanynofuncionales,queseasocianconla calidad de dichos procesos [11].Paraqueexistaunproblema,sedebepresentaruna condicin de desequilibrio total o parcial en los procesos del sistema analizado. Adems, su impacto debe ser lo sufcientemente signifcativo como para que el analista intervenga.Encontraste,unobjetivosecomponede elementos que enuncian un estado al que se debe llevar un proceso, mediante la toma de una serie de decisiones [8]. Por lo tanto, para tomar la decisin ms acertada, sedeberealizarunanlisisprofundodelosobjetivos, teniendo en cuenta su clasifcacin e importancia, de la valoracindelimpactodelproblemaydelasacciones que permitan revertirlo, para alcanzar todos los objetivos delaorganizaciny,fnalmente,deotrassituaciones adversas que puedan surgir ante la implementacin de las nuevas medidas a tomar.EnlametodologaKepner-Tregoeseestablece, entonces,unarelacinsecuencialodetrazabilidad entreladefnicindeunasolucin,elanlisisdelos problemas, la toma de decisiones sobre los procesos de la organizacin que seafectanyel establecimientode losobjetivosdedichasolucin[8],sinolvidarqueel analista es el encargado de determinarla, obedeciendo a la jerarqua de objetivos.En el mtodo de desarrollo de software UN-Mtodo [1], sedestacalaimportanciadetrabajarconlosobjetivos identifcados para la organizacin y se realizan paulatinas derivacionesalosobjetivosparaobtenersubobjetivos, hastallegaralasexpectativasyrequisitos,talycomo seexigeenlaestructuradeldiagramadeobjetivosde KAOS [5]. De este modo, se trata de evitar la informacin irrelevante, separando la estable de la voltil, buscando explicaralinteresadolosrequisitosnecesariospara solucionarunasituacinproblemtica,conlamenor ambigedadposible[12].Dichaproblemticase analiza,tambin,respectoalamaneracomoafectan losproblemasalosprocesosquesellevanacabo enlaorganizacinyqueserepresentandemanera jerarquizada y estructurada en el diagrama causa-efecto o Espina de Pescado [7]. As, el analista determinar qu problemasdeberatacarensutotalidad,culespodr omitiroculesatacarparcialmente,sinalejarsedel objetivo general que justifca la creacin del software [1].1.2 EL PROCESO DE EDUCCIN DE REQUISITOS.El desarrollo de software suele ser una tarea compleja yenlaquelaingenierapocoinfuye.Porello,sise realizaunaretrospeccin,seencuentranmsyerros quexitos[1].Sinembargo,conelsurgimientodela IngenieradeSoftware,aparecendiversascorrientes dedicadas a la planifcacin estructurada y al modelado delosproblemas,cuyopropsitoesintroducircierta organizacin a dicho proceso de desarrollo, permitiendo, a su vez, la capacidad de mantenimiento y trazabilidad en sus productos.El desarrollo de software, generalmente, inicia con una seriedeencuentrosentreelanalistayelinteresado, enloscualesseestableceunvocabulariocomnpara describir las funciones de los actores de la organizacin, laformadeproceder,lajerarquadeobjetivos,entre otros[1].Lasreunionesperidicasconelinteresado continan para identifcar el dominio del problema, los procesos que se afectan y los objetivos que los justifcan (plasmndolos en los diferentes diagramas y artefactos) ydeterminar,as,losaspectosmsrelevantesque conformanyjustifcanlasolucin.Sinembargo,es posibleque,despusdeesaarduatarea,seconcluya queunaaplicacindesoftwarenoaportaunamejora tan signifcativa como se esperaba, ya que sta puede requerir un cambio previo tanto en la estructura, como en los procesos de la organizacin o que, incluso, no se requieratalaplicacindesoftware[1].Unaaplicacin de software se modela con un conjunto de artefactos, y, por ello, se hace necesario articularlos de tal manera que los resultados sean consistentes, ya que, de lo contrario, el analista tendr que concentrarse en corregir errores cuyoorigenestenlasfasesinicialesdeldesarrollo desoftwarey,deestemodo,sedesperdiciatiempoy esfuerzo [16].Envistadequelaidentifcacindelosrequisitosse realizademanerasubjetiva,enmuchasocasiones, estoconllevaaquelaespecifcacinanalizadadela solucindistedelasituacinproblemticareal,lo PARTICIPACIN DE LOS CASOS DE USO88quepuedeprovocarinconsistenciasenelsistema desarrollado.Entrelosfactoresquepuedenocasionar estasimprecisionesenlosrequisitossedestacanlos siguientes [2]:Interesadosquetienenunavisinparcialdel negocio, conllevando a que los analistas no tengan una idea clara ni consistente del mismo.Analistascentradosenespecifcarlosrequisitosa travsdecasosdeuso,objetivosodiscursosde interesado con los que detallan las funcionalidades, pero que pasan por alto parte de la informacin de lasrelacionesentrerequisitosodeestosconsu entorno.Cadaartefactomodelaunaporcinespecfcadel dominioconsuspropiascaractersticas,loque aumenta la posibilidad de que se modelen elementos comunes.Esaqudondeaparecelanecesidadde consistencia [16].1.3 DIAGRAMAS DE CASOS DE USOLosdiagramasdecasosdeusopertenecenal estndar de UML y se emplean para modelar aspectos funcionales del sistema, ya que facilitan la delimitacin y el establecimiento de las relaciones entre los actores yelsistema[13].Uncasodeusosepuededefnir comounasecuenciadeacciones,incluyendoacciones alternas, que el sistema puede realizar y que producen un resultado concreto para un actor que interacta con el sistema [3]. Los siguientes elementos corresponden a la especifcacin del diagrama de casos de uso [4]:Actores: roles que los usuarios, ya sean humanos u otrossistemas,desempeanrespectodelsistema para comunicarse con el mismo.Escenario:secuenciaespecfcadeaccionesque refeja un comportamiento. Relaciones: interacciones entre casos de uso y entre actores. Las relaciones pueden ser de cuatro tipos:-Asociacin:sepresentaentrelosactoresylos casos de uso.-Inclusin:ocurrecuandouncomportamiento descritoporelcasodeusodestinoseincluye tambin en una instancia del caso de uso origen. -Extensin:sepresentacuandoelcasodeusoa extender invoca el caso de uso base de acuerdo con ciertas condiciones.- Herencia: ocurre cuando un actor o un caso de uso origen heredan la especifcacin del actor o caso de usodestino,respectivamente,yprobablementela modifquen. Las principales ventajas de utilizar el diagrama de casos de uso son [15]:permiten el buen desarrollo del sistema gracias a la capturadelosrequisitosdesdelaperspectivadel usuario. ofrecenunabuenabaseparalaverifcaciny validacin de los requisitos del sistema.ayudanagestionarlacomplejidaddeproyectos grandes,descomponindolosenfuncionesms simples.Figura1:Diagramadecasosdeusoparamodelar aspectos funcionales del sistema.Actor ACaso de Uso ACaso de Uso OrigenCaso de Uso OrigenCaso de Uso DestinoCaso de Uso Destino

2.ANTECEDENTES2.1 ALGUNASCONSIDERACIONESSOBRELOS CASOS DE USOAunqueelxitodeloscasosdeusoradicaenque constituyenunatcnicaintuitiva[6],laobtencinyla especifcacindecasosdeusorealmentetilesyla falta de consenso sobre cmo tratarlos, son las razones quehacennecesarioestablecerunaguaparala identifcacin, descripcin y organizacin de ellos.Los requisitos, y por tanto los casos de uso, se deberan organizar de manera jerrquica y cada nivel de casos de uso debe refnar los del nivel inmediatamente superior. Adems,lajerarquadecasosdeusonodebeserel resultado de una descomposicin funcional, sino que se debe realizar de manera iterativa e incremental [10].Otroaspectoatenerencuentaeslaubicacindel modeladodecasosdeusodentrodelprocesode desarrollo.Seentiendeelmodeladodecasosdeuso comounpasoprevioalmodeladoconceptual.En contraste, no es posible crear casos de uso adecuados ytilessincomprendereldominio,y,portanto,el modeladodecasosdeusoyelmodeladoconceptual deberan ser actividades paralelas [9].Gerenc. Tecnol. Inform. | Vol. 9 | N 25 | Sep - Dic | Zapata, Giraldo, MorenoGerenc. Tecnol. Inform. | Vol. 9 | N 25 | Sep - Dic | Zapata, Giraldo, MorenoPARTICIPACIN DE LOS CASOS DE USO89Figura 2: Esquema general del diagrama Causa-efecto para la representacin de problemas.Aunquelostrabajosaqurevisadosmanifestanla preocupacinpordarleuntratomsconsistentealas relacionesdeloscasosdeusoconotrosartefactos necesariosparamodelarunaaplicacindesoftware (comoeldiagramadeobjetivos),notienenencuenta losproblemasdelaorganizacin,nimuchomenosla manera en cmo la solucin informtica modelada con los casos de uso los atiende.2.2 ACTUACINDELOSCASOSDEUSOSOBRE LOS PROBLEMAS ORGANIZACIONALESEn [14] y, posteriormente, en [1], se propone un mtodo para la valoracin de la aplicacin de software desde las causasquesecubrenpormediodeloscasosdeuso delasolucininformtica.Paraello,seempleacomo base el diagrama Causa-Efecto [7], pero, en este caso particular, con pesos ponderados para cada una de las causas y subproblemas del dominio, cumpliendo con lo siguiente (vase la fgura 2):iA= 100% Pi,jmj=1i,jA 100% Ai,jk =1 Qi = 100% Pi,j*n mi=1j=1(1)(3)(4)(2)Enestasecuaciones,Qirepresentaelporcentajede relevancia del problema SPi sobre el problema principal; PijeselporcentajederelevanciadelacausaCijen elproblemaSPi.Elmtododevaloracinconsisteen asignar un porcentaje de actuacin Aij que una funcin de un caso de uso tiene sobre una causa determinada. En este caso, si es el conjunto de funciones asociadas conuncasodeusoyACUelporcentajedeatencin delcasodeusosobreelproblema,sedebecumplir tambin que:Tabla 1: Asignacin de porcentajes para la valoracin total de aplicaciones de software. Pi,j Ai,j Qi* *m nk=1 j=1 i=1%ACU =Laaplicacindeestemtodosuponelaelaboracin de una tabla que incluye el listado de las funciones de loscasosdeuso,consusrespectivosporcentajesde cumplimiento, junto con las ponderaciones del diagrama causa-efecto (vase la tabla 1).CASO DE USOCAUSA PijQijAijACUCdeU SP5 0.1 0.1 0.1 0.01... ... ... ... ... ...TOTAL XSinembargo,estemtodoindicaquenotodos losproblemasrequierensolucionesligadasconla informtica, pero, de todas formas, se podran estudiar desde el punto de vista de la Ingeniera de Sistemas [1]. Adems,seranecesariorealizarlavaloracinsobreel conjuntoseleccionadodesoluciones,parapresentarle alinteresadoconelfndemirarsuimpactosobrela organizacin.Aunque en UN-Mtodo se realiza un anlisis del impacto delaaplicacindesoftwaresobrelosproblemasde laorganizacin,desdeloscasosdeuso,lavaloracin delporcentajedeactuacindelasolucininformtica an la realiza el analista de manera subjetiva. Adems, sedejandeladoartefactoscomolosprocesosylos objetivosdelaorganizacin,degraninfuenciaen laeduccinderequisitos,representandounposible desfase respecto del impacto real sobre la problemtica, enelmomentoderealizarlavaloracintotaldela aplicacin de software.PARTICIPACIN DE LOS CASOS DE USO903.DESARROLLO3.1 ESTIMACINENUN-MTODODEL PORCENTAJE DE ACTUACIN DE LOS CASOS DE USO SOBRE LOS PROBLEMASTrassuperarlaetapadelaeduccinderequisitos,la aplicacindesoftwareresultantehabrdetenerun impacto sobre la organizacin, el cual [14] y [1] calculan desde el punto de vista de las causas de los problemas quesolucionatotaloparcialmente,comosemuestra acontinuacin.Supngaselanuevatablaexplicativa deprocesosresultanteeneltercerentregabledeun determinadoproyectorealizadoconUN-Mtodoyque se muestra en la Tabla 2. Por simplicidad, solamente se muestran las columnas relevantes para la demostracin yloscdigosdelosenunciadosdelosrespectivos artefactos.Eneseordendeideas,Pieselcdigodel proceso i que se lleva a cabo en una organizacin; OBi y REi son los respectivos objetivos y requisitos asociados con el proceso i; Ci es la causa o problema que afecta al respectivo proceso. Adicionalmente, se aade la columna casos de uso para especifcar aquellos procesos que se considerasepuedenautomatizarenloscasosdeuso CdeUi que atienden dichas causas.Deestemodo,elporcentajedeactuacindelos casosdeusosobrelascausasqueatienden,se calculaempleandolatabla1queproponen[14]y [1],determinandoelporcentajeAijcomosemuestra enlatabla3.Estamaneradeasignarporcentajes decumplimientolarealizaelanalistaintuitivamente basndose, la mayora de las ocasiones, en la cantidad de ocurrencias de una determinada causa en la nueva tabla explicativa de procesos.Tabla2:Nuevatablaexplicativadeprocesospara presentar los procesos automatizables.Tabla3:Asignacintentativadeporcentajesde actuacin para cada una de las causas.PROCESOS OBJETIVOS PROBLEMASCASO DE USOP1 OB1P2 OB2 C3 CdeU1P3 OB5,RE4 C3 CdeU1P4 RE1, RE9 C1 CdeU1P5 RE1, RE5 C1P6 OD3, RC2 C5 CdeU2P7 RE2, RE6 C5P8 OB4 CdeU3P9 OB6,RE7 C2 CdeU3P10 RE10 C2P11 RE3P12 RE8 C2PROBLEMA Aij %C1 0C2 33.3C3 100C4 100C5 50Como se observa en la tabla 2, la causa C1 no se asocia con ningn proceso automatizable, por lo que no se le asigna porcentaje de actuacin. Las causas C3 y C4 se encuentran presentes en procesos que se automatizan completamenteconcasosdeuso,porloqueseles asigna 100% de actuacin. Pero, ahora, como slo uno de los procesos (P9) que contiene la causa C2 se asocia con un caso de uso (CdeU3), dicha causa se atiende de maneraparcial;as,sesuponequesuporcentajede actuacin sera de tan slo una tercera parte, es decir, se le asignara el 33.3%, si los objetivos de la organizacin tuvieran igual importancia. De forma anloga, se podra deducir que la causa C5 se atendera al 50%, pues uno delosprocesosconloscualesseasocia(P7)nose incluye como un caso de uso en la solucin informtica. Lavaloracintotalparaestametodologasepresenta enlatabla4.Supngase,ademslosporcentajesde incidencia Pij y Qij, los cuales deben estar presentes en el diagrama Causa-efecto, como se indica en la Figura 2.Tabla4:Valoracintotaldelaaplicacindesoftware para determinar su impacto sobre la problemtica.CASO DE USOCAUSA PijQijAijACUCdeU1 C3 0,25 0,43 1 0,1075CdeU1 C4 0,2 0,375 1 0,075CdeU2 C5 0,16 0,52 0,5 0,0416CdeU3 C2 0,2 0,28 0,333 0,0186TOTAL0,2427= 24,3%Gerenc. Tecnol. Inform. | Vol. 9 | N 25 | Sep - Dic | Zapata, Giraldo, MorenoGerenc. Tecnol. Inform. | Vol. 9 | N 25 | Sep - Dic | Zapata, Giraldo, MorenoPARTICIPACIN DE LOS CASOS DE USO91En este mtodo, la valoracin total puede presentar un desfase respecto del impacto real sobre la problemtica, puestoque,sibienseempleaunrazonamiento matemticoparadefnirtalefecto,elporcentaje deactuacinAijparalascausasqueseatienden parcialmente(comoC2yC5),loasignaelanalista segnsucriterio,esdecir,sehacesubjetivamente. Adems, para este clculo, no se tienen en cuenta otros elementos vitales en la educcin de requisitos, como los objetivosylosprocesosdelaorganizacin(alterando la consistencia y trazabilidad de este mtodo), quienes, fnalmente, tambin se afectan con la introduccin de la aplicacin informtica en la organizacin. As, como se argument en la seccin 2.2, se puede establecer una relacinentreladefnicindeunasolucin,elanlisis de los problemas, las decisiones sobre los procesos y el establecimiento de los objetivos de la misma [8].3.2 MTODOPARADETERMINARLA PARTICIPACINDELOSCASOSDEUSO ENLASOLUCINDEPROBLEMASDEUNA ORGANIZACIN.A continuacin, se propone un mtodo para determinar el porcentaje de actuacin Aij sobre los problemas que se atienden parcialmente con los casos de uso. Para ello, supngase que los objetivos de la tabla 2, se jerarquizan de acuerdo con los pesos del diagrama de KAOS [5] de la Figura 3. Por simplicidad, se omiten los enunciados de los objetivos y los requisitos:Figura 3: Diagrama KAOS para representar los objetivos de la organizacin.Tabla5:Determinacindelospesosdelosobjetivos que se afectan con la causa C2.Ahora,teniendoencuentalamaneracomoinfuyen losprocesosqueunacausadeterminadaafectayla jerarqua de los objetivos asociados, el nuevo porcentaje deactuacinAijdeloscasosdeusosobrelascausas queatiendendemaneraparcial,secalcularealizando la sumatoria de los pesos de los objetivos involucrados, tras realizar el anlisis de la tabla 5.CAUSACASO DE USOPROCESOSAFECTADOSOBJETIVOS PESOSSUB-TOTALCdeU3 P9 OB6, RE7 3+2 5C2 P10 RE10 1 1P12 RE8 2 2TOTAL 8CAUSACASO DE USOPROCESOSAFECTADOSOBJETIVOS PESOSSUB-TOTALC5CdeU2 P6 OB3, RE2 4+3 7P7 OB2, RE6 3+2 5TOTAL 12Comosemencionanteriormente,elcasodeuso CdeU3 atiende nicamente la causa C2, implicando que solamente uno de los tres procesos a los que afecta (el proceso P9) es automatizable. Por lo tanto, el total de lospesoscorrespondientesalosrespectivosprocesos afectados es de 8, de los cuales slo 5 se atienden, luego (por regla de tres simple), el porcentaje de actuacin Aij delacausaC2esdel62,5%,ynodel33.3%como sehabaestipuladoinicialmente.Cabedestacarque, paraestecasoparticular,conlaasignacinoriginalse desprecia casi la mitad del porcentaje de actuacin del caso de uso.Anlogamente, el anlisis para la causa C5 se muestra en tabla 6, indicando que de los 12 pesos afectados, 7 se atienden. De este modo, su porcentaje de atencin Aij es del 58,3%, y no del 50%.Tabla6:Determinacindelospesosdelosobjetivos que se afectan por la causa C5.A partir de la valoracin fnal, con los nuevos porcentajes deatencin,seapreciaque,sisetieneencuentael impactodeloscasosdeusonicamentesobrela PARTICIPACIN DE LOS CASOS DE USO92Tabla7:Valoracinfnaldelimpactodelapiezade software con los nuevos porcentajes de cumplimiento.problemticaespecifca,seestaradespreciandocierto porcentaje de actuacin, que puede ser importante a la hora de determinar impacto total.CASO DE USOCAUSA PijQijAijACUCdeU1 C3 0,25 0,43 1 0,1075CdeU1 C4 0,2 0,375 1 0,075CdeU2 C5 0,16 0,52 0,583 0,0485CdeU3 C2 0,2 0,28 0,625 0,035TOTAL0,2660= 26,6%Para este caso particular, la valoracin fnal es del 26,6%, esdecir,2,3%msquelavaloracinoriginalmente realizada(24,3%),quesemuestraenlaTabla4.Se encuentraestevalordadoquelosobjetivosdelas organizacionesnoseconsiderandeigualimportancia, sinoquehayunosmsestratgicosqueotros,porlo generalaquellosqueseencuentrenmsaltosenla jerarqua que plantea el diagrama de objetivos.4.CONCLUSIONES Y TRABAJO FUTUROEn este artculo se present un mtodo para establecer unarelacinmediantelacualseintegranciertos artefactosqueseconstruyenduranteelprocesode educcinderequisitos,comolosprocesosquese afectan con las causas de los diferentes problemas y los objetivos por los cuales se llevan a cabo (teniendo encuentasujerarqua).Estemtodopermiteque serealiceunanlisismsrealistadelimpactode lasolucininformticasobrelosproblemasquese atacan parcialmente.Al mismo tiempo, se elimina la intervencin subjetiva del analista a la hora de hacer la valoracin del porcentaje deactuacindeloscasosdeusosobrelasolucinde los problemas que afectan a la organizacin, mejorando, enesesentido,laconsistenciaytrazabilidaddelos requisitos que se capturan por medio de UN-Mtodo.Comotrabajofuturoadesarrollarenrelacincon estetema,seencuentranlassiguienteslneasde investigacin:Desarrollarunametodologaqueestablezca uncriterioparatratardecuantifcarelgrado deautomatizacindeunproceso,conelfnde determinarlacertezadeasignarel100%de actuacindeuncasodeusosobreunproceso problemtico.Proponerunmtodoformalparadefnirlospesos de los objetivos presentes en el diagrama de KAOS, demaneraquenonecesariamenteseconsidere el aumento lineal, a medida que se asciende en la jerarqua de objetivos.Desarrollar un mtodo ms objetivo para establecer elporcentajedegravedaddelosproblemas,es decir,paradeterminarelgradodeimportanciade la causa que se atiende, evitando que el analista se base nicamente en su propio criterio.Proponerunmtodoquepermitaestablecer equivalencias entre los casos de uso y los requisitos queelloscubren,detalmaneraquesepueda determinarunarelacinmsdirectaentrelos mismos, a la hora de elegir la solucin informtica que se va a implementar.5.REFERENCIAS BIBLIOGRAFICAS[1]ARANGO, Fernando y ZAPATA, Carlos M. UN-MTODO para la Elicitacin de Requisitos de Software. Medelln: Carlos M. Zapata (Ed.), 2006. 100p.[2]BERROCAL,Javier,GARCA,JosManuel, MURILLO,JuanManuel.Patronesparala ExtraccindeCasosdeUsoapartirdeProcesos deNegocio.En:IITALLERDEPROCESOSDE NEGOCIOEINGENIERADESERVICIOS(II: 2009: San Sebastin). Actas de los Talleres de las JornadasdeIngenieradelSoftwareyBasesde Datos, San Sebastin: 2009.[3]BOOCH,G.,RUMBAUGH,J.,JACOBSON,I.The Unifed Modeling Language User Guide. New York: Addison-Wesley Professional, 1999. 512p. [4]FOWLER, M. A brief guide to the Standard Object ModelingLanguage.RedwoodCity:Addison-Wesley, 2004. 185p.[5]DARDENNE,Anne,LAMSWEERDE,Axel,FICKAS, Stephen.Goal-DirectedRequirementsAcquisition. Science of Computer Programming, Vol. 20, Issue 1-2. msterdam: Elsevier North-Holland, Inc. 1993.[6]GARCA, Jess, ORTN, M. Jos, MOROS, Begoa, NICOLS, Joaqun, TOVAL, Jos. De los procesos del negocio a los casos de uso. Tcnica Administrativa (revista electrnica), Vol. 6, No. 32. Buenos Aires: Ciencia y Tcnica Administrativa C&TA, 2007.Gerenc. Tecnol. Inform. | Vol. 9 | N 25 | Sep - Dic | Zapata, Giraldo, MorenoGerenc. Tecnol. Inform. | Vol. 9 | N 25 | Sep - Dic | Zapata, Giraldo, MorenoPARTICIPACIN DE LOS CASOS DE USO93[7]ISHIKAWA, Kaoru. Guide to quality control. Tokyo: Asian Productivity Organization, 1986. 225p.[8]KEPNER,Ch.andTREGOE,B.TheNewRational Manager:AnUpdatedEditionforaNewWorld. Princeton: Princeton Research Press, 1997. 254p.[9]KORSON, T. Constructing Useful Use Cases [en lnea]. Consultado el 5 de marzo de 2010. Disponible en: http://softwarearchi tects.com/publ i cati ons/korson/usecase3. 1999.[10]KORSON,T.MisuseofUseCases[enlnea]. Consultadoel5demarzode2010.Disponible en:http://softwarearchitects.com/publications/korson/korson9803om.htm. 1998.[11]LAMSWEERDE,Axel.Requirementsengineering intheyear2000:aresearchperspective.En: PROCEEDINGOFTHE22NDINTERNATIONAL CONFERENCEONSOFTWAREENGINEERING, (XXII: 2000: Limerick), 5-19. [12]LAMSWEERDE,Axel.(2001).Goal-oriented RequirementsEngineering:Aguidedtour.En: 5THIEEEINTERNATIONALSYMPOSIUMON REQUIREMENTSENGINEERING.(V:2001: Toronto), 249-262.[13]OMG. Object Management Group. Unifed modeling language specifcation [en lnea]. Consultado el 15 demarzode2010.Disponibleen:http://www.omg.org/UML/ [14]ZAPATA,CarlosyARANGO,Fernando.Alineacin entremetasorganizacionalesyelicitacinde requisitos del software. Revista Dyna Vol. 71, No. 143, pp. 101 - 110. Medelln: Universidad Nacional de Colombia, Noviembre de 2004. [15]ZAPATA,CarlosM.,TAMAYO,Paula,ARANGO, Fernando.Conversindeesquemas preconceptualesadiagramadecasosdeuso empleando atom3. Revista Dyna Vol. 74, No. 153, pp.237-251.Medelln:UniversidadNacionalde Colombia, Noviembre de 2007.[16]ZAPATA, Carlos M., VILLEGAS, Sandra M., ARANGO, Fernando.Reglasdeconsistenciaentremodelos derequisitosdeUN-Mtodo.RevistaUniversidad EAFITVol.42,No.141,pp.40-59.Medelln: Universidad EAFIT, 2006. Copyright of Gerencia Tecnologica Informatica is the property of Universidad Industrial de Santander and itscontent may not be copied or emailed to multiple sites or posted to a listserv without the copyright holder'sexpress written permission. However, users may print, download, or email articles for individual use.