4. Implementación del Enfoque
5.2. Evaluación de la identificación de responsabilidades
En esta sección se detallará el proceso de evaluación y los resultados obtenidos a la hora de evaluar la identificación de las responsabilidades contenidas en los requerimientos funcionales siguiendo el enfoque propuesto en la sección 3.3. La misma estará dividida en 6 secciones: Objetivos, en donde se plantearan los objetivos propuestos a la hora de plantear la evaluación; Casos de Estudio, en donde se describirán los casos de estudio usados para la evaluación; Métricas de Evaluación, en donde se describirán las métricas elegidas para la evaluación; Setup de Algoritmos, en donde se explicará el proceso de evaluación; Resultados, en donde se plantearán los resultados obtenidos luego de la eva- luación; Análisis, en donde se realizará un análisis de los resultados explicando el por que de los valores en cada caso.
5.2.1. Objetivos
Siguiendo nuestro enfoque, una vez clasificados los requerimientos, se procede a la identificación de responsabilidades contenidas en los requerimientos funcionales. Dado que estas responsabilidades sirven como entrada de la siguiente etapa del enfoque, es importante analizar la precisión y eficacia de dicha identificación.
5.2.2. Casos de estudio
Para evaluar la estrategia de identificación de responsabilidades, se pusieron a prueba 5 proyectos. Los requerimientos de dichos proyectos se encuentran previamente clasificados de forma manual para evitar posibles ruidos provenientes del proceso de clasificación.
Tres de estos proyectos fueron extraídos de los proyectos usados para la evaluación de los clasificadores(sección 5.1.2), y 2 proyectos extraídos de trabajos prácticos dictados en la carrera de Ingeniería de Software de la universidad de Nueva York11. Estos últimos fueron previamente analizados y desglosados en varios requerimientos por 4 estudiantes avanzados de la carrera de Ingeniería de Software de la UNICEN entre 23 y 26 años de edad.
A continuación se detallan uno a uno los proyectos junto con sus responsabilidades. Es importante recordar que algunas de las responsabilidades fueron descubiertas por la herramienta y no por el experto. Estos son los casos de las responsabilidades cuyo ID tiene como prefijo el término “added”.
5.2.2.1. Proyecto 1 Este proyecto 1 se corresponde con el proyecto 2 explicado en la sección 5.1.2. El mismo consta de 40 requerimientos de los cuales 11 son requerimien- tos funcionales. Estos requerimientos detallan un sistema de gestión de inmobiliarias, en donde, basándose en los requerimientos funcionales, se pueden identificar las responsabi- lidades detalladas en el cuadro 14.
ID Responsabilidad resp0 query MLS information resp1 get driving directions resp2 download appointment resp3 download contact information resp4 display clear property images resp5 create new property listing resp6 update new property listing resp7 generate CMA report
resp8 call seller
resp9 call buyer
resp10 schedule appointment resp11 notify new client appointment resp12 retireve map
resp13 notify realtor resp14 save search result added1 show property location Cuadro 14: Responsabilidades del proyecto 1
5.2.2.2. Proyecto 2 El proyecto 2 es un enunciado extraído de la carrera de Inge- niería de Software de la universidad de Nueva Yorkhttp://www.nyu.edu/classes/jcf/ CSCI-GA.2440-001/handouts/Assignment2.htm. El mismo describe los requerimientos de un sistema de monitoréo y control de bombas de agua y monitoréo de gas metano en minas. El mismo consta de 7 requerimientos funcionales de las cuales se pueden identificar 11 responsabilidades descritas en el cuadro 15.
ID Responsabilidad
resp0 monitor water level
resp1 measure maximum acceptable level resp2 measure minimum level
resp3 start mine pump
resp4 trigger evacuation alarm
resp5 stop mine pump
resp6 verify security credential resp7 override automatic behaviour resp8 reestablish automatic vehaviour added1 reset pump system
5.2.2.3. Proyecto 3 Este proyecto 3 se corresponde con el proyecto 8 explicado en la sección 5.1.2. El mismo consta de 93 requerimientos de los cuales 20 son requerimientos funcionales. Estos requerimientos describen un sistema online de streaming de películas. Luego de analizar los requerimientos funcionales, fueron identificadas 22 responsabili- dades. Las mismas son listadas en el cuadro 16.
ID Responsabilidad
resp0 search movie
resp1 display movies description actor resp2 display movies description director resp3 request credit card payment resp4 authorize credit card payment
resp5 stream movie
resp6 browse movie
resp7 view review
resp8 add own movie review
resp9 approve review
resp10 purchase prepaid credit card resp11 update main page resp12 show latest movie resp13 purchase streaming movie resp14 store customer information resp15 log usage statistics added0 update billing added1 update contact information added2 view movie detail added3 cancel account added4 support free trial period added5 purchase movie
5.2.2.4. Proyecto 4 Este proyecto 4 se corresponde con el proyecto 9 explicado en la sección 5.1.2. El mismo consta de 24 requerimientos de los cuales 17 son requerimientos funcionales. Analizando estos requerimientos funcionales, se identificaron 19 responsabi- lidades listadas en el cuadro la 17.
ID Responsabilidad
resp0 verify invalid lead resp1 submit credit validation record resp2 supply lead datum
resp3 supply score
resp4 validate lead
resp5 insert lead
resp6 process lead
resp7 compile contact information resp8 compile academic scoring information
resp9 return lead
resp10 verify users authentication resp11 verify users rights
resp12 store lead
resp13 assign lead
resp14 receive period list
added0 score part
added1 make parameter update
added2 use parameter
added3 submit lead
Cuadro 17: Responsabilidades del proyecto 4
5.2.2.5. Proyecto 5 El proyecto 5 es un enunciado extraído de la carrera de Inge- niería de Software de la universidad de Nueva Yorkhttp://www.nyu.edu/classes/jcf/ CSCI-GA.2440-001/handouts/Assignment2.htm. En el mismo se identificaron 10 reque- rimientos de los cuales 9 son funcionales, los cuales describen un sistema de gestión de Alumnos. Analizando los requerimientos funcionales, se identificaron 14 responsabilidades listadas en el cuadro 18.
ID Responsabilidad resp0 register for courses resp1 view report cards resp2 access system resp3 request course catalogue resp4 select course offering resp5 indicate alternative choice resp6 change schedule
resp7 add course
resp8 drop course resp9 send information resp10 submit schedule resp11 view electronic report card resp12 record grade added0 teach course added1 make informed decision Cuadro 18: Responsabilidades del proyecto 5 5.2.3. Métricas de evaluación
Al llevar al cabo las pruebas, en algunos casos la herramienta identificó responsabilida- des que no fueron identificadas por los estudiantes. Por este motivo nos pareció importante llevar registro del porcentaje de responsabilidades que fueron identificadas correctamente por la herramienta y que no fueron identificadas por los estudiantes. A esta métrica se la denominó after-added-responsibilities-percent(AARP), y se describe en la fórmula 14
aarp=af ter−added−responsibilities
total−responsibilities (14)
En los casos que AARP sean cercanos a 1 significará que la herramienta identifico más responsabilidades que las que identificaron los estudiantes mientras que un valor cercano a 0 significara que la herramienta no pudo identificar muchas responsabilidades que no hayan sido identificadas por los estudiantes.
Es importante destacar que dentro de total-responsibilities, también se encuentran las responsabilidades identificadas por la herramienta que no fueron identificadas por los estudiantes.
Para evaluar la eficacia del enfoque, usar la cantidad de responsabilidades correctamen- te identificadas no nos pareció suficiente, por lo que se decidió usar las mismas métricas que en 5.1.3(accuracy, recall y f-measure). A diferencia de la evaluación de los clasifica- dores, se tomaron TP12 como las responsabilidades identificadas por los estudiantes más
las que detectó correctamente el enfoque que no fueron identificadas por los estudiantes, TN13 como las responsabilidades que detecto la herramienta sin que fueran identificadas por los alumnos, FP14 como las responsabilidades que identificó incorrectamente el enfo-
12True Positive 13True Negative 14False Positive
que y FN15 como las responsabilidades que fueron identificadas por los estudiantes pero
que la herramienta no pudo identificar. 5.2.4. Setup de algoritmos
Para evaluar el proceso de identificación de responsabilidades, en principio se calcula- ron las métricas descritas en la sección 5.2.3 para cada uno de los proyectos. Para ello, se usaron los requerimientos de cada proyecto(los cuales se encuentran previamente clasifi- cados por un experto) y el listado de responsabilidades identificadas por los estudiantes. Estos requerimientos se encuentran almacenados en archivos de igual manera que los re- querimientos usados para evaluar los algoritmos de clasificación(explicados en la sección 5.1.4). Las responsabilidades también se encuentran almacenadas en archivos CSV, en donde cada línea de este archivo contiene un identificador único para cada responsabili- dad, el verbo de la responsabilidad, el sujeto de dicha responsabilidad, el identificador del requerimiento del cual fue identificada y el número de oración en dicho requerimiento en donde se identificó a dicho requerimiento. Es importante aclarar que una responsabilidad puede identificarse de múltiples requerimientos, pero para llevar a cabo la evaluación sólo bastó con identificar uno de ellos.
Paso siguiente, se identifican las responsabilidades usando el enfoque propuesto y se analizaron las responsabilidades obtenidas en busca de posibles responsabilidades que no hayan identificado los estudiantes. Estas nuevas responsabilidades se mezclan con el listado anterior y se calculan las métricas usando este nuevo listado. Finalmente, luego de analizar todos los proyectos, se calcula el promedio para cada métrica.
Es importante aclarar que, como se explicó en 3.3, la identificación de responsabili- dades en algunos casos necesita de supervisión de un experto para eliminar algunas de las responsabilidades dudosas. Durante el proceso de evaluación, dicha supervisión fue realizada por nosotros mismos a través de línea de comandos.
Algoritmo 5 Pseudo-código del proceso de evaluación de la identificación de responsa- bilidades
functionevaluateIdentification(responsibilityExtractor, proyects)
results←emptyArray
for allproyect←proyectsdo
originalResp←getOriginalResponsibilities(proyect)
af terAddedResp←getAf terAddedResp(proyect)
identif iedResp←identif yResp(respExtractor, proyect)
results←calculateM etrics(identif iedResp, originalResp, af terAddedResp)
push(proyectResult, results) end for
calculateM eansOf Results(results) end function
5.2.5. Resultados
La ejecución del proceso de evaluación de la identificación de responsabilidades(te- niendo en cuenta que en este hubo períodos de intervención por parte del usuario para asistir a la herramienta como se propuso en 3.3), llevó al rededor de 3 minutos en un ambiente mono-threading con un procesador de 3.2GHz.
Los resultados aproximados obtenidos para las métricas descritas en 5.2.3, las cua- les son Accuracy, Recall, F-Measure y After Added Responsibilities Percent(AARP), se detallan en el cuadro 19.
Proyecto Accuracy Recall F-Measure AARP Proyecto1 1.0000 0.9375 0.9677 0.0625 Proyecto2 0.7143 1.0000 0.8333 0.1000 Proyecto3 0.8095 0.7727 0.7907 0.2728 Proyecto4 0.8000 0.6316 0.7059 0.2105 Proyecto5 0.7500 0.8000 0.7742 0.1333
Cuadro 19: Resultados por proyecto de la evaluación de la detección de responsabilidades El promedio para cada una de las métricas, usando los resultados de el cuadro 19, se describen en el cuadro 20.
Métrica Valor Promedio Accuracy 0.8148
Recall 0.8284 F-Measure 0.8144
AARP 0.1558
Cuadro 20: Resultados generales de la evaluación de la detección de responsabilidades 5.2.6. Análisis
En el cuadro 19 vemos que el accuracy obtenido para el proyecto 1 fue del 100 %. Esto significa que la herramienta no detectó ninguna responsabilidad de forma errónea. Sin embargo esto no quita que haya podido identificar todas las responsabilidades identificadas por los alumnos.
También podemos notar que el recall del proyecto 2 es de 100 % lo cual nos indica que todas las responsabilidades identificadas por los alumnos fueron identificadas por la he- rramienta. Sin embargo esto no quiere decir que todas las responsabilidades identificadas por la herramienta sean correctas. De hecho en este ejemplo el accuracy en el mismo es menor que el 100 %, con lo cual indica que al menos una responsabilidad identificada por la herramienta es incorrecta.
Figura 32: Resultados de la evaluación para la identificación de responsabilidades Analizando los resultados obtenidos, detallados en la sección 5.2.5, es posible observar que los proyectos que más bajo accuracy obtuvieron fueron el proyecto 2 y el proyecto 5. Casualmente estos proyectos son los extraídos de los enunciados de la universidad de Nueva York. Comparando los requerimientos funcionales de estos proyectos con los del resto, se puede observar que son mucho más extensos. En el gráfico 33 se muestra la cantidad de palabras promedio por requerimiento de cada proyecto.
Esto nos lleva a pensar que hay una relación inversa entre la cantidad de palabras y el accuracy obtenido. Esta relación podría ser consecuencia de que, al ser más extenso el requerimiento, el mismo contiene mayor cantidad de frases verbales. Esto podría provocar que la herramienta identifique de forma errónea, responsabilidades incorrectas.
Analizándolo desde el punto de vista del recall, se puede observar que el proyecto que menos recall tuvo fue el proyecto 4. El que haya dado un bajo recall nos indica que muchas de las responsabilidades que fueron identificadas por los estudiantes, no pudieron ser identificadas por la herramienta. Analizando los requerimientos, y entrando en detalle en cada una de las etapas de la identificación de las responsabilidades, se observó que la biblioteca que se usó para realizar el part-of-speech-tagging, en muchas ocasiones cometió errores. Tomando como ejemplo el requerimiento 12 del proyecto 4, el cual es:
The leads washing functionality will insert all leads captured by the web service
De este requerimiento es de donde debería haberse deducido la responsabilidad resp5(“in- sert lead”). Analizando las etiquetas que le asignó la biblioteca de Stanford, mostradas en el cuadro 21, se observa que en la segunda aparición de “leads” se la etiquetó como un verbo, cuando en realidad hace referencia a un sustantivo. Esto generó que no pue- da ser identificado como un objeto directo de insert, y que no se haya identificado la responsabilidad.
Palabra PoS Significado
The DT Determinante
leads NNS Sustantivo en plural
washing VBG Verbo en gerundio
functionality NN Sustantivo
will MD Modal
insert VB Verbo
all DT Determinante
leads VBZ Verbo en 3ra persona en presente simple captured VBN Verbo en pasado participio
by IN Preposicion
the DT Determinante
web NN Sustantivo
service NN Sustantivo
Cuadro 21: Etiquetas de PoS asignadas al requerimiento 12 del proyecto 4 Si a modo de ejemplo, se reemplazara la segunda aparición de “leads” por cualquier otro sustantivo S(ej: “data”), y analizando con la herramienta nuevamente, se ve quela herramienta identificó una responsabilidad de la forma “insert S”(en el ejemplo, “insert data”).