validación aplicación técnicas gómez 2012
DESCRIPTION
Validación Aplicación Técnicas Gómez 2012TRANSCRIPT
VALIDACIÓN Y APLICACIÓN DE TÉCNICAS
DE PRIORIZACIÓN DE REQUISITOS
JHONNY GÓMEZ CHALACÁN
UNIVERSIDAD DE SAN BUENAVENTURA
CALI- COLOMBIA
FACULTAD DE INGENIERÍA
PROGRAMA INGENIERÍA DE SISTEMAS
SANTIAGO DE CALI,
2012
VALIDACIÓN Y APLICACIÓN DE TÉCNICAS
DE PRIORIZACIÓN DE REQUISITOS
JHONNY GÓMEZ CHALACÁN
Trabajo de Grado presentado como requisito para optar
al título de INGENIERO DE SISTEMAS
Director
Ingeniero Luis Merchán Paredes
UNIVERSIDAD DE SAN BUENAVENTURA
CALI - COLOMBIA
FACULTAD DE INGENIERÍA
PROGRAMA INGENIERÍA DE SISTEMAS
SANTIAGO DE CALI
2012
3
DEDICATORIA
A la ingeniería de requisitos
Jhonny Gómez Chalacán
4
AGRADECIMIENTOS
Gracias a mi familia por el apoyo, la exigencia y la buena energía.
Jhonny Gómez Chalacán
5
CONTENIDO
Pág.
GLOSARIO 13
RESUMEN 13
RESUMEN DEL PROYECTO 15
INTRODUCCIÓN 16
1. PLANTEAMIENTO DEL PROBLEMA 18
2. OBJETIVOS DEL PROYECTO 20
2.1 OBJETIVO GENERAL 20
2.2 OBJETIVOS ESPECÍFICOS 20
3. REFERENTE TEÓRICO 21
3.1 BUSQUEDA EN ARBOL BINARIO (BINARY SEARCH TREE (BST)) 26
3.2 TÉCNICA DE ASIGNACIÓN DE PESO NUMÉRICO (NUMERAL
ASSIGNMENT TECHNIQUE) 27
3.3 JUEGO DE LA PLANIFICACIÓN (PLANNING GAME) 27
3.4 MÉTODO DE LOS 100 PUNTOS (100-POINT METHOD) 27
6
3.5 TEORÍA W (THEORY-W) 28
3.6 REQUISITOS DE TRIAGE (REQUIREMENTS TRIAGE) 29
3.7 WIEGERS' METHOD 29
3.8 FRAMEWORK DE PRIORIZACIÓN DE REQUISITOS
(REQUIREMENTS PRIORITIZATION FRAMEWORK) 29
3.9 CONJOINT 30
3.10 ANALYTIC HIERARCHY PROCESS (AHP) 31
3.11 ANÁLISIS KANO (KANO ANALYSIS) 31
4. DESARROLLO METODOLÓGICO DEL PROYECTO 33
4.1. RECOPILACIÓN Y DOCUMENTACIÓN DE LAS TÉCNICAS DE
PRIORIZACIÓN 33
4.1.1 Marco descriptivo de la técnica 34
4.1.2 Caracterización detallada de las Técnicas 35
4.1.3 Actividades del método 36
5. ANÁLISIS DE APROPIACIÓN Y USO DE LAS TÉCNICAS POR LA
INDUSTRIA DEL SOFTWARE. 58
5.1 FICHA TÉCNICA DE LA ENCUESTA 58
5.2 RESULTADOS DE LA EVALUACIÓN 59
5.2.1 Sección 1: Información general. 60
5.2.1.1 Pregunta 1. 60
7
5.2.1.2 Pregunta 2. 61
5.2.1.3 Pregunta 3. 63
5.2.1.4 Pregunta 4. 64
5.2.1.5 Pregunta 5. 65
6. CONCLUSIONES DE LA EVALUACIÓN 67
7. ANÁLISIS DE HERRAMIENTAS DE ADMINISTRACIÓN DE
REQUISITOS 69
7.1 RESULTADOS DE LA EVALUACIÓN 69
7.1.1 Pregunta 1. 69
7.1.2 Pregunta 2. 70
8. PROPUESTA; NUEVA TÉCNICA 71
9. RESULTADOS DE APLICACIÓN DE LAS TÉCNICAS 81
9.1 CASO CMSOFTLUTIONS 81
9.1.1 Primero, Listar Requisitos. 81
9.1.2 Segundo, Categorizar requisitos 81
9.1.3 Tercero, Beneficio Relativo 82
9.1.4 Cuarto, Penalidad Relativa 84
9.1.5 Quinto, Valor Total 86
8
9.1.6 Sexto, Costo Relativo 88
9.1.7 Séptimo, Riesgo relativo 90
9.1.8 Octavo, Calculo de Prioridades 92
9.1.9 Noveno, Ordenar 94
9.2 CASO COOMEVA 96
10. TRABAJOS FUTUROS 97
11. CONCLUSIONES 98
BIBLIOGRAFIA 100
ANEXOS 104
9
LISTA DE TABLAS
Pág.
TABLA 1. TÉCNICAS DE PRIORIZACIÓN 33
TABLA 2. EJEMPLO DE UNA MATRIZ DE COMPARACIÓN POR PARES
CON 8 REQUISITOS 37
TABLA 3. INTERPRETACION DE LOS VALORES EN LA MATRIZ 38
TABLA 4. INTERPRETACIÓN DE LOS COSTOS EN LA MATRIZ 38
TABLA 5. MATRIZ NORMALIZADA 39
TABLA 6. COLUMNA DE PUNTUACIÓN. 40
TABLA 7. RANDOM INDEX VALUES - ÍNDICE DE VALORES
ALEATORIOS 42
TABLA 8. RATIO 42
TABLA 9. SEGÚN EL NÚMERO DE REQUISITOS, PARA ESTE EJEMPLO
EL INDICE ALEATORIO(RI) ES 1,41 42
TABLA 10. FICHA TÉCNICA DEL ESTUDIO ADELANTADO 59
TABLA 11. INGENIEROS DE SISTEMAS EN LAS EMPRESAS 60
TABLA 12. NÚMERO DE PRODUCTOS SOFTWARE POR EMPRESA. 61
TABLA 13. EQUIVALENCIAS DE TAMAÑO CON RANGOS EN
ENCUESTA. 63
TABLA 14. ACTIVIDADES PRINCIPALES POR EMPRESA 63
TABLA 15. MODELOS IMPLEMENTADOS POR LAS EMPRESAS 64
10
TABLA 16. APLICACIÓN DE MÉTODOS DE PRIORIZACIÓN DE
REQUISITOS EN LAS EMPRESAS. 65
TABLA 17. APLICACIÓN DE MÉTODOS DE PRIORIZACIÓN DE
REQUISITOS EN LAS EMPRESAS(DESARROLLO DE SOFTWARE
HECHO A LA MEDIDA) . 66
TABLA 18. APLICACIÓN DE MÉTODOS DE PRIORIZACIÓN DE
REQUISITOS EN LAS EMPRESAS (DESARROLLO DE SOFTWARE
GENÉRICO). 66
TABLA 19. APLICACIÓN DE MÉTODOS DE PRIORIZACIÓN DE
REQUISITOS EN LAS EMPRESAS(DESARROLLO DE SOFTWARE
HECHO A LA MEDIDA Y GENÉRICO). 66
TABLA 20. HERRAMIENTAS DE ADMINISTRACIONES 70
TABLA 21. CATEGORÍAS E INFLUENCIAS 81
TABLA 22. BENEFICIO RELATIVO (CORE) 82
TABLA 23. BENEFICIO RELATIVO (INSIDENTES) 82
TABLA 24. BENEFICIO RELATIVO (NTH) 83
TABLA 25. BENEFICIO RELATIVO (SOFTWARE) 83
TABLA 26. PENALIDAD RELATIVA (CORE) 84
TABLA 27. PENALIDAD RELATIVA (INSIDENTES) 84
TABLA 28. PENALIDAD RELATIVA (NTH) 85
TABLA 29. PENALIDAD RELATIVA (SOFTWARE) 85
TABLA 30. VALOR TOTAL (CORE) 86
TABLA 31. VALOR TOTAL (INSIDENTES) 86
11
TABLA 32. VALOR TOTAL (NTH) 87
TABLA 33. VALOR TOTAL (SOFTWARE) 87
TABLA 34. COSTO RELATIVO (CORE) 88
TABLA 35. COSTO RELATIVO (INSIDENTES) 88
TABLA 36. COSTO RELATIVO (NTH) 88
TABLA 37. COSTO RELATIVO (SOFTWARE) 89
TABLA 38. RIESGO RELATIVO (CORE) 90
TABLA 39. RIESGO RELATIVO (INSIDENTES) 90
TABLA 40. RIESGO RELATIVO (NTH) 90
TABLA 41. RIESGO RELATIVO (SOFTWARE) 91
TABLA 42. CALCULO DE PRIORIDAD (CORE) 92
TABLA 43. CALCULO DE PRIORIDAD (INSIDENTES) 92
TABLA 44. CALCULO DE PRIORIDAD (NTH) 93
TABLA 45. CALCULO DE PRIORIDAD (SOFTWARE) 93
TABLA 46. REQUISITOS ORDENADOS (CORE) 94
TABLA 47. REQUISITOS ORDENADOS (INISIDENTES) 94
TABLA 48. REQUISITOS ORDENADOS (NTH) 94
TABLA 49. REQUISITOS ORDENADOS (SOFTWARE) 95
12
LISTA DE FIGURAS
Pág.
FIGURA 1. MODELO: MATRIZ DE PRIORIZACIÓN 56
FIGURA 2. INGENIEROS DE SISTEMAS EN LAS EMPRESAS 61
FIGURA 3. RELACIÓN TAMAÑO DE LA EMPRESA VS NÚMERO DE
PRODUCTOS. 62
FIGURA 4. ACTIVIDADES DE LAS EMPRESAS 64
FIGURA 5. CONCLUSIONES DE LA EVALUACIÓN 67
FIGURA 6. MODELO: MATRIZ DE PRIORIZACIÓN 80
13
GLOSARIO
Término Descripción
IEEE Institute of Electrical and Electronics Engineers
CMMI Capability Maturity Model Integration
RAE Real academia de la lengua española
Stakeholder “Quienes pueden afectar o son afectados por las actividades de una empresa” R.
E. Freeman en su obra: “Strategic Management: A Stakeholder Approach”
RAD Rapid Application Development
SW-CMM Capability Maturity Model for Software
SP Specific Practices
SG Specific Goal
CRUD Por sus siglas en ingles Create, Read, Update, Delete
14
RESUMEN
El tema de la ingeniería de requisitos es un subconjunto relativamente nuevo de la
ingeniería de software. La ingeniería de requisitos intenta agregar rigor a la
reunión y análisis de requisitos mediante el uso de métodos formales de
elicitación, análisis, y también en la creación de modelos de aplicación y validación
de los requisitos [1].
Por medio del trabajo exploratorio se pudo identificar un grupo de técnicas muy
utilizadas en la industria del software para priorización de requisitos, con la
investigación se validaron esas técnicas y su uso, luego se realizó un estudio a las
empresas Colombianas, buscando resolver cuál técnica es más precisa para los
proyectos que se presentan en el contexto actual de la industria del software,
como conclusión se aprovechan algunas técnicas dándoles otra forma y
aplicándolas en una nueva, esto según las necesidades de las diversas empresas
del país.
ABSTRACT
The topic of requirements engineering is a fairly new subset of software
engineering. Requirements engineering attempts to add rigor to requirements
gathering and analysis by using formal methods of elicitation, analysis, and also by
creating models of the application and validating the requirements[1].
Through the exploration it could identify a group of widely used techniques in the
software industry for prioritization of requirements, with research techniques and
their use were validated, then conducted a study to Colombian companies, seeking
to resolve which technique is most accurate for the projects presented in the
context of the industry, in conclusion exploit some techniques and
applying them otherwise in a new, this according to the needs of the
various companies.
15
RESUMEN DEL PROYECTO
Actualmente las empresas que desarrollan software comprenden que en su
proceso de administración de requisitos deben priorizar, lo que no saben aún, es
cómo hacerlo, en su mayoría las empresas usan la experiencia del encargado de
la priorización como factor determinante de este proceso; por eso se realiza una
exploración identificando las diferentes técnicas que nos ayudan a saber el cómo
priorizar y no caer más en la metodología de lo informal.
A partir de una caracterización1, se identifica un grupo de técnicas factibles para la
priorización de requisitos, de ahí se seleccionan algunas técnicas candidatas que
puedan aportar en la industria del software para dicha priorización, luego se
validan cuales de estas son reconocidas como formales, por último se propone y
aplica una técnica que sea efectiva para administrar los requisitos que se
demandan actualmente en los proyectos software.
1 Determinar los atributos peculiares de alguien o de algo, de modo que claramente se distinga de
los demás.
16
INTRODUCCIÓN
La priorización de requisitos2 [3][4][5] es una actividad muy importante en el
desarrollo de productos cuando las expectativas del usuario y del producto son
altas, existe limitaciones de tiempo, los recursos son limitados y el producto debe
cumplir las funciones más esenciales lo antes posible [6].
En el desarrollo de productos software, la totalidad de los requisitos no pueden ser
implementados por limitaciones de los recursos (tiempo y costos), esto nos hace
decidir qué requisitos deben ser implementados y de ahí la necesidad de priorizar.
De acuerdo a Wiegers [3] la información para la priorización de los requisitos es
extremadamente necesaria, no tanto para ignorar los requisitos menos
importantes o desarrollar los más importantes, sino que ayuda al administrador del
proyecto a resolver conflictos entre los requisitos, planear las entregas, etc. Esto
hace que la actividad de priorización de requisitos se convierta en una actividad
desafiante, compleja [7][8] y sea un factor de éxito o fracaso de los proyectos.
En la literatura se pueden encontrar distintas técnicas para la priorización de
requisitos, estas técnicas pueden clasificarse dependiendo del enfoque en tres
categorías: a) Agrupación de prioridades, b) Técnicas que combinan aspectos que
afectan las prioridades y c) Técnicas de votación e inversión, pero cada técnica
tiene sus ventajas y desventajas.
De igual manera los distintos enfoques y técnicas no especifican en qué etapa del
desarrollo del proyecto deben o pueden ser usados, se dejan a disposición de los
lideres de desarrollo o del proyecto para su utilización. El no tener una claridad
acerca del uso de la técnica y más aún en que etapa usarla, hace más ambiguo y
confuso el uso de una u otra técnica en el proceso de desarrollo de software,
inclinando a los líderes de proyectos a utilizar la regla del costo-beneficio [9],
donde el líder de desarrollo o del proyecto conjuga las restricciones de los
recursos del proyecto buscando el mayor beneficio al menor costo [10].
2 Requisito, Circunstancia o condición necesaria para algo [2].
17
El desarrollo de una propuesta que permita la implementación y que responda al
¿qué… y el ¿cómo…hacer para poder realizar una planificación del desarrollo de
los requisitos de software, basándose en una optimización de la priorización de los
requisitos, aporta al proceso de desarrollo de software para entregar productos
que cuentan con limitaciones de tiempo y de recursos, y ayuda a que se cumpla
con las necesidades del producto de una mejor manera.
18
1. PLANTEAMIENTO DEL PROBLEMA
El proceso que se sigue para construir, entregar y evolucionar el software, desde
la concepción, hasta la entrega y mantenimiento del mismo, tiene una etapa
fundamental, que en el modelo CMMI [11] es llamada en el área de procesos
como “Desarrollo de Requisitos”3 [11]. Esta etapa del proceso de desarrollo de
software trata de determinar desde un principio con total claridad lo que se desea
construir con el nivel de detalle requerido, de tal manera que el equipo de
desarrollo en las etapas subsiguientes del proceso, pueda fabricar con efectividad
las funcionalidades que implementan los requisitos de la solución software.
Esta problemática no es ajena en los proyectos de fabricación de software [6],
considerando que en lo absoluto se generan costosos re-procesos de implantación
e incluso de la misma elicitación [12] de los requisitos; es en este proceso donde
se hace muy importante poder trabajar sobre métodos más efectivos que permita
disminuir esta brecha de incertidumbre (requisitos ambiguos o mal entendidos) y
de re-procesos al momento de la fabricación de software, trayendo como
consecuencia favorable un producto con menos inconformidades de fabricación.
Contar con métodos colaborativos que nos ayuden a entender los requisitos,
ayuda también a que esa brecha de inconformidades sea más pequeña [13].
En el desarrollo de requisitos de software un factor determinante es la gestión de
los mismos y a su vez la priorización y planificación [6], dicha priorización es un
factor de éxito que determina la óptima utilización de los recursos tiempo, costos y
factor humano para una efectiva culminación del producto esperado.
La evidente necesidad de contar con un método que permita realizar una optima
priorización y planificación de los requisitos de software, abre las puertas para
aportar en el proceso de ingeniería de software una propuesta metodológica, la
cual llene el vació que hoy no cobijan algunas metodologías ó estándares [11] en
los cuales se aborda el tema de la priorización como una actividad del desarrollo
de requisitos de software pero no se enfatiza en el ¿cómo?, es decir, se plantea el
3 Es en esta área de desarrollo donde se identifican, entienden, documentan y planifican los
requisitos
19
hecho de priorizar, pero no se deja claro el cómo se debe priorizar, dejando de
alguna manera al libre albedrío del líder de desarrollo (o del proyecto) , una
actividad tan importante como la priorización y planificación de los requisitos,
donde en ultimas, se utiliza más que la técnica su propia experticia.
20
2. OBJETIVOS DEL PROYECTO
2.1 OBJETIVO GENERAL
Validar técnicas de priorización de requisitos y proponer una técnica que haga
parte del proceso de desarrollo de requisitos que permita optimizar la priorización
de estos.
2.2 OBJETIVOS ESPECÍFICOS
Caracterización de las diferentes técnicas de priorización de requisitos de
software.
Identificar factores en los requisitos que determinan y permiten su priorización.
Validar y aplicar la técnica propuesta en empresas reales.
21
3. REFERENTE TEÓRICO
Existen dos tendencia básicas en el modelo de ciclo de vida de desarrollo de
software: el secuencial o modelo en cascada [14], y el modelo de desarrollo
iterativo incremental. La diferencia entre estos dos modelos es que en el desarrollo
secuencial, el desarrollo se realiza por una serie de etapas que se siguen una de
otra relacionándose entre sí y en el iterativo incremental se va desarrollando en
pequeños incrementos y en varias iteraciones posteriores.
Sommerville [15] establece las etapas de desarrollo de software secuencial. Estas
etapas son la definición de requisitos, diseño del sistema y del software,
implementación, pruebas unitarias, integración y pruebas del sistema, operación y
mantenimiento.
Según Schach [16], el desarrollo de software iterativo consiste en un conjunto de
iteraciones seguidas unas tras otras. Las fases de cada interacción incluyen la
especificación, diseño, implementación y pruebas, las cuales pueden llegar a
sobreponerse en algunos casos.
Las ventajas y desventajas de ambos modelos han sido discutidas en todos estos
años, sin embargo lo que sí se puede ganar es una visión global de estos
enfoques entendiendo las diferentes actividades las cuales son comunes en
ambos. Un aspecto importante es que independiente del modelo que se utilice
para el ciclo de vida del desarrollo de software, la definición y selección de los
requisitos del software es necesario por cualquiera de los dos caminos que se
tome.
Según James Senn [17], existen tres estrategias para el desarrollo de sistemas: a)
El método clásico del ciclo de vida de desarrollo de sistemas, b) El método de
desarrollo por análisis estructurado y c) El método de construcción de prototipos
de sistemas. Cada una de estas estrategias tiene un uso amplio en cada una de
los diversos tipos de empresas que existen, y resultan efectivas si son aplicadas
de manera adecuada.
22
Consecuente a Schach, se concluye que el ciclo de vida de un sistema de
información es un enfoque por fases que sostiene que los sistemas son
desarrollados de mejor manera mediante el uso de un ciclo especifico de
actividades del analista, diseñador, desarrollador y del usuario.
Como complemento a lo que James Senn afirma, se puede decir que la ingeniería
de requisitos es un área de investigación que procura atacar un punto fundamental
en el proceso de desarrollo de software [18], definiendo lo que se quiere producir.
Jackson [19] ratifica que la ingeniería de requisitos se ubica en el punto de
encuentro entre lo informal y lo formal del desarrollo de software. La ingeniería de
requisitos debe cubrir todas las actividades relacionadas con la elicitación,
especificación y mantenimiento [4].
Wiegers [3] define un requisito como una propiedad que un producto debe tener
para ofrecer valor a un usuario. Sin embargo, "requisito" no es un término sin
ambigüedades, ya que diferentes autores lo definen de manera diferente y hacen
hincapié en diferentes puntos de vista en sus definiciones. Por ejemplo, el
estándar IEEE define el término [20] como:
Condición, capacidad ó necesidad de un usuario para resolver un problema ó
alcanzar un objetivo.
Condición ó capacidad que debe tener un sistema para satisfacer un contrato,
norma, especificación o de otro tipo impuesta por un documento formal.
Una representación documentada de una condición o capacidad como en las
dos primeras.
Davis [21] complementa la definición de la IEEE, mediante la definición de un
requisito como "una necesidad del usuario ó una característica necesaria, función
o un atributo de un sistema que puede ser detectado desde una posición externa a
ese sistema”. Kotonya y Sommerville [4] afirman que el requisitos define lo que el
sistema debe hacer y las circunstancias que se requieren para funcionar.
23
Es así como un aspecto fundamental del análisis de sistemas es comprender
todas las facetas, partes, componentes, etc., importantes del problema que se
encuentra bajo estudio. Los analistas, al trabajar con los usuarios interesados,
deben estudiar los procesos o problemas para dar respuesta a las siguientes
preguntas claves: ¿Qué es lo que hace?, ¿Cómo se hace?, ¿Con que frecuencia
se presenta?, ¿Qué tan grande es el volumen de transacciones o decisiones? ,
¿Cuál es el grado de eficiencia con el que se efectúan las tareas? , ¿Existe algún
problema?, ¿Qué tan serio es? ¿Cuál es la causa que lo origina?
El proceso de ingeniería de requisitos se puede definir como un conjunto
estructurado de actividades que se siguen para calcular, validar y mantener un
documento de requisitos del sistema [4]. Según Kotonya y Sommerville [4], la
secuencia básica del proceso de ingeniería de requisitos incluye la obtención de
requisitos, análisis de requisitos y negociación de los mismos, la documentación y
validación de los requisitos. Sin embargo, no existe un proceso único en la
ingeniería de requisitos que esté adecuado para todas las organizaciones.
Además, la descripción del proceso secuencial de por sí no es suficiente .La
ingeniería de requisitos hace hincapié en un enfoque de colaboración para el
desarrollo de los productos [13], con la participación de múltiples perspectivas de
los interesados que participan en un proyecto [3].
La ingeniería de requisitos es generalmente vista como la primera fase del ciclo
desarrollo del producto. Por ejemplo, Jackson [19] sostiene que la ingeniería de
requisitos y el diseño son actividades separadas, debido a que los requisitos son
en su mayoría relacionados con el problema a resolver y el diseño tiene que ver
con la solución al problema. Sin embargo, Kotonya y Sommerville [4], por ejemplo,
sostienen que estas dos son actividades interrelacionadas.
Sin embargo la ingeniería de requisitos suele ser vista como una actividad al inicio
del ciclo vida de desarrollo de software. La ingeniería de requisitos es necesaria a
través del ciclo de vida del desarrollo incluyendo las iteraciones que sean
necesarias cuando se utiliza un enfoque incremental iterativo.
Si bien es cierto CMMI es un referente importante para los procesos de desarrollo
de software por ende es importante anotar que CMMI también trata algunas
24
prácticas especificas donde se plantean actividades dentro del ciclo de desarrollo
del software donde se gestionan los requisitos pero no define el cómo se deben
priorizar los requisitos. [22]
El nivel 2 requiere que hayamos considerados las siguientes cosas:
Gestión de requisitos,
Plan de Proyecto,
Monitorización y control del proyecto,
Gestión de acuerdos con proveedores,
Medida y análisis,
Medidas de calidad en el proceso y producto,
Gestión de la configuración
A continuación podemos ver las actividades detalladas, definidas por CMMI a
realizar en el primer punto del nivel de madurez 2 en la gestión de requisitos.
SG Gestionar Requisitos (SG – Meta especifica)
SP 1.1 Obtener y comprender requisitos (SP - Práctica Especifica)
SP 1.2 Obtener la aprobación de los requisitos.
SP 1.3 Gestionar los cambios en requisitos
SP 1.4 Mantener una trazabilidad bidireccional de requisitos
SP 1.5 Identificar inconsistencias entre el trabajo real a realizar y los
requisitos.
Otro referente es el modelo Requirements Management Maturity (RMM) [23],
donde también se expone la idea de identificar atributos y características de los
requisitos para luego priorizarlos. En este modelo tampoco se encuentra algo
explicito que indique el cómo priorizar aunque si se sugiere el hecho de tomar
métricas e identificar la importancia de cada requisito en el proyecto.
25
En un artículo publicado por IBM en el 2003, “The Five Levels of Requirements
Management Maturity” se afirma textualmente en el nivel 3 de RMM,
“Level Three – Structure, You need to understand how the requirements will be
used in order to understand what attributes are necessary. What reports and
queries will you need to support? What metrics must you keep? Getting answers to
these questions up front will help you start on the right foot” [23]
Por lo anterior, si en la fabricación de software el punto de partida se encuentra en
el desarrollo de requisitos previamente identificados, lo normal es que se quieran
priorizar. Debido a limitaciones de tiempo y presupuesto, puede ser difícil de
implementar todos los requisitos que se han suscitado para un sistema de
información. Además, los requisitos deberían ser implementados en etapas, y la
priorización puede ayudar a determinar cuáles deben implementarse en primer
lugar. Seguramente muchas fabricas desarrollan los requisitos de más bajo costo
en su implementación [9], sin tener en cuenta su importancia. Otros desarrollan los
requisitos que son más “fáciles” primero, seguramente basados en su propia
experiencia. La cuestión es, ¿Estos enfoques empíricos tienen posibilidades de
lograr los objetivos del producto o solución esperada? Para dar prioridad a los
requisitos de software, se recomienda un enfoque sistémico de priorización [3].
Si se tiene en cuenta un enfoque sistémico algunas técnicas de priorización
podrían ser potencialmente utilizadas en la ingeniería de requisitos como apoyo al
proceso de priorización o como ayuda a los líderes de desarrollo de software, de
tal forma que se acerque un poco esta actividad a una realidad basada en
ingeniería y no en un enfoque empírico.
Sommerville [15] Define la priorización de requisitos como la actividad en la cual
se identifican los requisitos más importantes para el sistema. Harwell et al. [24]
describe la prioridad como una característica del requisito que puede ser utilizada
para diferentes efectos de la solución y de la necesidad de la compañía. Otro
como Karlsson y Ryan [7]; Jung [25] definen la priorización como la característica
que identifica a un requisito que tiene mayor ponderación en importancia y menor
costo.
26
Podríamos mencionar técnicas como [26]:
Binary Search Tree,
Numeral Assignment Technique,
Planning Game, the 100-Point Method,
Theory-W,
Requirements Triage,
Wiegers' Method,
Requirements Prioritization Framework,
Conjoint analysis y
AHP
Kano Analysis
3.1 BUSQUEDA EN ARBOL BINARIO (BINARY SEARCH TREE (BST))
Este algoritmo es usado comúnmente en la búsqueda de información y puede ser
usado para la priorización de requisitos [27]. El enfoque básico para ser usado en
requisitos es el siguiente:
Ponga todos los requisitos en una pila.
Tome uno de los requisitos como raíz del árbol.
Tome otro de los requisitos y compárelo con el raíz.
Si el requisito es menos importante que el nodo raíz, se compara con el nodo
hijo izquierdo. Si el requisito es más importante que el nodo raíz, se compara
con el nodo hijo derecho. Si el nodo no tiene nodos secundarios, introducir el
nuevo requisito como nuevo nodo secundario a la derecha o izquierda,
dependiendo de si el requisito es más o menos importante.
Repita los pasos 3-4 hasta que todos los requisitos han sido comparados e
insertados en el árbol.
Para efectos de presentación recorra el árbol binario y ponga los requisitos en
una lista tomando el de menos importancia al final y el más importante al inicio.
27
3.2 TÉCNICA DE ASIGNACIÓN DE PESO NUMÉRICO (NUMERAL
ASSIGNMENT TECHNIQUE)
Esta técnica asigna un valor (escala) a cada requisito, adicionalmente los
requisitos se dividen en tres grupos: Obligatorios, deseables y no esenciales [5].
Los participantes asignan a los requisitos un número dentro de la escala de 1 a 5
indicando la importancia de cada uno de ellos [28]. Los números en la escala
tienen el siguiente significado:
El cliente no lo necesita.
No es importante.
Bastante importante (Si lo tiene el cliente lo agradece).
Es muy importante (El cliente lo desea).
Es obligatorio (El cliente no puede prescindir de él).
La clasificación final es el promedio de las clasificaciones de todos los
participantes para cada uno de los requisitos.
3.3 JUEGO DE LA PLANIFICACIÓN (PLANNING GAME)
Es una técnica utilizada por el Método de desarrollo de software Extreme
Programming [29, 29A] y se utiliza con los clientes para priorizar los requisitos
basado en historias. Esta es una variación de la técnica de asignación numérica
donde el cliente distribuye los requisitos en tres grupos, a) aquellos sin los cuales
el sistema no funcionará, b) los que son menos esenciales, pero proporcionan un
importante valor empresarial, y c) los que sería bueno tener.
3.4 MÉTODO DE LOS 100 PUNTOS (100-POINT METHOD)
El método de los 100 puntos [30] es básicamente un esquema de tipo votación
que es usada en ejercicios de lluvia de ideas. A cada interesado se le dan 100
puntos que puedan utilizar para votar por los requisitos que considere más
importantes, el interesado puede usarlos de la manera que él considere más
pertinente. Por ejemplo si existen cuatro requisitos que él considera son igual de
prioritarios, entonces el podrá darle a cada uno 25 puntos. Si existe un requisito
que él considera de importancia primordial podría darle los 100 puntos. Sin
28
embargo, este tipo de esquema sólo funciona para una votación inicial. Si una
segunda votación se toma, la gente tiende a redistribuir sus votos para conseguir
que sus favoritos avancen en el esquema de prioridades.
3.5 TEORÍA W (THEORY-W)
Teoría-W fue inicialmente desarrollado en la Universidad del Sur de California [31,
32]. También se conoce como "Win-Win" (“Ganar-Ganar”). Un punto importante es
que soporta la negociación para resolver los desacuerdos acerca de los requisitos,
de manera que cada actor tiene una "victoria". Cuenta con dos principios:
Plan the flight and fly the plan (Plan de vuelo y volar el plan).
Identificar y administrar sus riesgos.
El primer principio tiene por objeto la construcción de planes bien estructurados
que cumplen con los estándares predefinidos para un fácil desarrollo, clasificación
y consulta. "Vuela el plan" asegura que el progreso sigue el plan original. El
segundo principio, "Identificar y administrar sus riesgos", implica la evaluación y
manejo de riesgos. En las negociaciones de ganar-ganar, cada usuario debe
clasificar los requisitos de forma privada antes de comenzar las negociaciones. En
el proceso de clasificación individual, el usuario considera si existen requisitos que
él está dispuesto a renunciar y que conoce completamente los riesgos e
implicaciones de ello. La Teoría-W tiene cuatro pasos:
Separe las personas del problema.
Centrarse en los intereses, no posiciones.
Invertir opciones para beneficio mutuo.
Insistir en el uso de un criterio objetivo.
29
3.6 REQUISITOS DE TRIAGE (REQUIREMENTS TRIAGE)
Requisitos Triage [33] es un proceso de varios pasos que incluye el
establecimiento de prioridades relativas a los requisitos, la estimación de recursos
necesarios para satisfacer cada necesidad, y la selección de un subconjunto de
los requisitos para optimizar la probabilidad de éxito del producto en el mercado en
cuestión. Esto está claramente dirigido a los desarrolladores de productos de
software en el mercado comercial. Es un enfoque único que vale la pena revisar, a
pesar de que claramente va más allá de los requisitos de asignación de
prioridades tradicionales, teniendo en cuenta los factores de negocio también
[33A].
3.7 WIEGERS' METHOD
Este método se relaciona directamente con el valor de cada requisito para un
cliente [3]. La prioridad se calcula dividiendo el valor de una obligación por la suma
de los costos y riesgos técnicos asociados a su aplicación [3]. El valor de una
obligación se considera como función tanto en el valor proporcionado por el cliente
para el cliente y la pena que se produce si el requisito falta. Esto significa que los
desarrolladores deben evaluar el costo de la exigencia y sus riesgos de
implementación, así como la penalidad si el requisito falta. Los atributos son
evaluados en una escala de 1 a 9.
3.8 FRAMEWORK DE PRIORIZACIÓN DE REQUISITOS (REQUIREMENTS
PRIORITIZATION FRAMEWORK)
El framework de priorización de requisitos asocia herramientas que incluyen [34,
35] las actividades de elicitación y priorización. Este framework intenta direccionar
lo siguiente:
Elicitar con ayuda de los interesados del negocio los objetivos del proyecto.
30
Permitir que los interesados en el proyecto puedan dar puntajes a los
requisitos y objetivos del proyecto mediante una escala de calificación grafica
difusa.
Calificar los requisitos basándose en una medida objetiva.
Encontrar las dependencias entre requisitos y agrupación de requisitos tanto
que la priorización de los mismos sea más efectiva.
Usar técnica de análisis de riesgos que permitan identificar entre los
interesados las desviaciones de apreciaciones o calificaciones subjetivas y la
asociación entre los aportes de los interesados y las calificaciones finales.
3.9 CONJOINT
Es una técnica estadística que permite medir el valor relativo de cada atributo de
un producto, con lo cual se puede determinar qué combinación de estos atributos
maximiza la probabilidad de elección por parte del consumidor. Inicialmente fue
desarrollada para su uso en modelos matemáticos de psicología y su aplicación al
marketing fue ideada en 1974 por Paul Green, profesor en The Wharton School
[36]. La técnica se desarrolla implementando lo siguiente:
Elegir los atributos más valiosos para posicionar una marca.
Al tener que elegir entre varios productos potenciales, identificar al que tendrá
mayor nivel de ventas
Decidir cuál es el precio adecuado para un producto
Estimar la cuota de mercado de un producto nuevo antes de su lanzamiento
Segmentar el mercado de acuerdo a los atributos de un producto
31
3.10 ANALYTIC HIERARCHY PROCESS (AHP)
AHP es una método para la toma de decisiones en situaciones donde existen
múltiples objetivos presentes [37][38][7] . Este método utiliza dos matrices para
calcular el valor y los costos relativos de los requisitos entre sí. Mediante el uso
de AHP el ingeniero de requisitos puede confirmar la consistencia de los
resultados. AHP puede ayudar a evitar errores generados de juicios subjetivos e
incrementar la probabilidad de que los resultados sean fiables. AHP puede ser
soportada por una herramienta independiente preferiblemente computacional. El
método AHP consta de 5 pasos:
Revisar los requisitos candidatos y completarlos enteramente.
Aplicar el método de comparación por pares para evaluar el valor relativo de
cada uno de los requisitos candidatos.
Aplicar el método de comparación por pares para evaluar el costo relativo de
los requisitos candidatos.
Calcular el valor relativo de cada requisito candidato y el costo de su
implementación y poder hacer seguimiento en un diagrama de costo – valor.
Usar el diagrama de costo – valor como un mapa que permita analizar los
requisitos candidatos.
3.11 ANÁLISIS KANO (KANO ANALYSIS)
Análisis Kano proporciona un medio poderoso y fácil de usar para clasificar
requisitos. Podemos utilizar esa clasificación para manejar nuestras decisiones de
priorización, asegurándonos de entregar todos los requisitos que deben estar en la
primera versión. Kano también nos ayuda a centrarnos en las necesidades que
diferencian a nuestro software, identificando y contrastando los requisitos
esenciales para el cliente. [39]
32
Kano definió cuatro categorías en las que se puede cada característica o requisito
pueden ser clasificados:
Sorpresa y deleite: capacidades que diferencian a un producto de la
competencia (por ejemplo, el iPod nav-wheel).
Más es mejor: dimensiones a lo largo de un continuo con una dirección clara de
utilidad incremental (por ejemplo, duración de la batería o la capacidad de la
canción).
Debe ser: las barreras funcionales de acceso al mercado, sin estas
capacidades, los clientes no utilizaran el producto (por ejemplo, la aprobación
de UL).
Mejor no ser: Representa las cosas que los clientes no les satisface (por
ejemplo, imposibilidad de aumentar la capacidad de la canción a través de
actualizaciones).
Aunque existen algunas técnicas de priorización que podrían ser usadas en
proyectos no solo de construcción de software sino de otra índole, realmente
no es fácil encontrar dentro de las empresas desarrolladoras de software,
estándares, métodos o técnicas evolucionadas con respecto a la priorización y
planificación de los requisitos de software [40]; existe más bien una tendencia a
utilizar la experiencia como instrumento principal para realizar esta actividad; No
obstante, algunas fabricas podrían estar usando alguna técnica en particular [6]
pero la verdad es que en un alto porcentaje las mismas no involucran en su
proceso ninguna , es por esto que la priorización “es uno de las actividades más
difíciles a la que se enfrentan los lideres de proyectos o desarrollo de software "
[41].
Podemos concluir entonces que la necesidad de poder contar con una
propuesta metodológica aliviaría de alguna manera esta falencia y aportaría
directamente al proceso de desarrollo software.
33
4. DESARROLLO METODOLÓGICO DEL PROYECTO
4.1. RECOPILACIÓN Y DOCUMENTACIÓN DE LAS TÉCNICAS DE
PRIORIZACIÓN
A partir de la investigación se han identificado algunas de las técnicas de
priorización de requisitos más reconocidas por la industria. Previamente en este
documento, estas técnicas se exponen en breve dando una introducción a las
mismas.
Tabla 1. Técnicas de priorización
Técnicas Acrónimo Autor Tipo
Analytic Hierarchy Process AHP Thomas L. Saaty Combinatorio
Binary Search Tree BST Adelson-Velskii y Landis.
Numeral Assignment Technique Brackett, J.W Combinatorio
Planning Game PG BECK, K. Agrupación
100-Point Method 100P Votación
Theory-W
University of Southern
California Combinatorio
Conjoint analysis Paul Green
Requirements Triage
Wiegers' Method Karl E. Wiegers Combinatorio
Requirements Prioritization
Framework Combinatorio
Kano Analysis Noriaki Kano
La caracterización de las técnicas tiene el objetivo de identificar cuál de estas,
según sus procesos y metas, pudiera ajustarse más a los diferentes tipos de
industria del software y sus diversos proyectos; a continuación se hace una
descripción más detallada de las técnicas que se listan en la Tabla 1.
Para presentar el detalle de las técnicas se ha diseñado un marco sobre el cual
éstas se documentan.
34
4.1.1 Marco descriptivo de la técnica
Nombre de la Técnica
Descripción de la técnica
Proceso de la Técnica
Entradas
Atributos
Requisitos
Actividades
Procesos
Tareas
Salidas
Logros
Entradas
ACTIVIDADES DEL MÉTODO
# Actividad Título de la actividad
Propósito Para qué y por qué tiene relevancia la actividad en la
totalidad de la técnica.
Descripción Breve descripción de la Actividad
Roles Aquellos roles encargados de realizar la actividad
Técnica
Prácticas o procedimientos para obtener el resultado y lograr el propósito de la
técnica.
Salidas
Resultado (Logros, metas) de la técnica
35
4.1.2 Caracterización detallada de las Técnicas
AHP - Analytical Hierarchy Process
Thomas L. Saaty
AHP es un método para la toma de decisiones en situaciones donde se presentan
múltiples objetivos. Este método utiliza una matriz de comparación por pares para
calcular el valor y los costos relativos de los requisitos. Mediante el uso de AHP,
el ingeniero de requisitos puede también confirmar la coherencia de los
resultados. Con AHP se pueden evitar errores de juicio subjetivo e incrementar la
probabilidad de que los resultados sean fiables. Hay cinco pasos en el método
AHP:
1. Revisar los requisitos del candidato a la integridad.
2. Aplicar el método de comparación por pares para evaluar el valor relativo de
los requisitos candidatos.
3. Aplicar el método de comparación por pares para evaluar el costo relativo de la
implementación de cada requisito candidato.
4. Calcular el valor relativo de cada requisito candidato y los costos de
implementación, y la trama de cada uno en un diagrama de costo-valor.
5. Utilice el diagrama de costo-valor, como un mapa para el análisis de los
requisitos candidatos.
Proceso
ENTRADAS
Requisitos candidatos.
Valor relativo.
Costo Relativo
SALIDAS
Gráfica Valor.
Gráfica Costo.
Gráfica Valor vs Costo.
ACTIVIDADES
S-1: Revisión de requisitos candidatos para la integridad. S-2: Comparación por pares S-3: Determinar la prioridad de los requisitos S-4: Columna de puntuación S-5: Verificar la consistencia.
36
ENTRADAS AL MÉTODO
Las entradas corresponden a los requisitos que el analista ha recolectado
previamente en el proceso de elicitación. Estos requisitos deben estar en un
mismo nivel de abstracción4 y estar claramente documentados, sin
ambigüedades.
Lo que ocurre es que en ocasiones los requisitos no se encuentran en un “estado
puro”, es decir, hay situaciones donde se presentan requisitos que a su vez son
composición y resultado de una conglomeración de requisitos. Por esto, y para
que AHP sea lo más preciso posible, se espera que los requisitos se encuentren
en un mismo nivel de abstracción.
Requisitos candidatos.
Valor relativo de cada requisito en el producto.
Costo relativo que se genera por la implementación de cada requisito.
4.1.3 Actividades del método
S - 1 REVISIÓN DE REQUISITOS CANDIDATOS PARA LA
INTEGRIDAD
Propósito Revisar que los requisitos estén claros y completos.
Descripción Se revisa y se re-analiza los requisitos para asegurarse que
estén correctos, completos y claros.
Roles
Rol Responsabilidades
Jefe del proyecto Lidera el proceso.
Stakeholder Acompaña en la
ponderación de los
requisitos.
Técnicas
Después de reunirse con el cliente, se revisan los requisitos basados en la
retroalimentación recibida, de esta forma se pueden identificar problemas de
ambigüedades, de falta de información o mala interpretación.
4 Según la RAE, Abstraer significa, separar por medio de una operación intelectual las cualidades
de un objeto para considerarlas aisladamente o para considerar el mismo objeto en su pura esencia o noción.
37
S - 2 COMPARACIÓN POR PARES
Propósito Obtener una comparación cardinal del valor y costo de los
requisitos.
Descripción
En este paso, los interesados implementan el método de
comparación por pares de AHP. Se hacen dos matrices una
para el valor relativo y otra para el costo relativo. Suponiendo
que el número de requisitos sea n, el número de celdas
resultantes será de n x n. La calificación para el costo y valor
relativo se da en una escala de 1 a 9.
Tabla 2. Ejemplo de una matriz de comparación por pares
con 8 requisitos
SR-1 SR-2 SR-3 SR-4 SR-5 SR-6 SR-7 SR-8
SR-1 1 0,1 0,2 0,3 0,5 0,3 0,3 0,3
SR-2 9 1 0,3 0,3 0,2 0,2 0,2 0,1
SR-3 6 3 1 0,5 0,5 0,5 0,5 0,3
SR-4 3 4 2 1 0,3 0,3 0,3 0,3
SR-5 2 5 2 3 1 0,2 0,2 0,1
SR-6 3 5 2 3 5 1 0,2 0,2
SR-7 3 6 2 3 6 5 1 0,3
SR-8 3 7 4 3 7 5 3 1
Roles
Rol Responsabilidades
Jefe del proyecto Lidera el proceso.
Stakeholder
Acompaña en la
ponderación de los
requisitos.
Técnica
Una entrada arbitraria en la fila i y la columna j de la matriz, con la etiqueta aij,
indica la diferencia que tiene un requisito i sobre otro j, ya sea valor o costo, según
la medida que se tome en función de la comparación.
Como en un producto cartesiano, la comparación se realiza para la totalidad de los
requisitos en la matriz. En realidad no hay que llenar la matriz completamente, con
solo llenar la matriz diagonal superior (o inferior) se sabe que el restante de la
matriz contiene los mismos valores invertidos, es decir 1/aij. Ver Tabla 2
38
Tabla 3. Interpretacion de los valores en la matriz
Intensidad del
valor Interpretación
1 Requisitos i y j son de igual valor.
3 Requisito i tiene un valor ligeramente superior a j.
5 Requisito i tiene un valor superior a j.
7 Requisito i tiene un valor muy superior a j.
9 Requisito i tiene un valor absolutamente superior a j.
2, 4, 6, 8 Estas son las escalas intermedias entre dos juicios
adyacentes.
Recíprocos Si el requisito i tiene menor valor que j
Tabla 4. Interpretación de los costos en la matriz
Intensidad del
valor Interpretación
1 Requisitos i y j son de igual costo.
3 Requisito i tiene un costo ligeramente superior a j.
5 Requisito i tiene un costo superior a j.
7 Requisito i tiene un costo muy superior a j.
9 Requisito i tiene un costo absolutamente superior a j.
2, 4, 6, 8 Estas son las escalas intermedias entre dos juicios
adyacentes.
Recíprocos Si el requisito i tiene menor valor que j
S - 3 DETERMINAR LA PRIORIDAD DE LOS REQUISITOS
Propósito Hallar la matriz de comparación normalizada.
Descripción
Se promedian los datos sobre las columnas normalizadas
para calcular el vector propio de la matriz que representa la
distribución del criterio.
39
Roles
Rol Responsabilidades
Jefe del proyecto Lidera el proceso.
Stakeholder
Acompaña en la
validación de los
requisitos.
Técnica
Primero, se hace la sumatoria de los valores para cada columna de la matriz.
= amj + a(m+1)j + a(m+2)j + … + anj = Columna j
= am(j+1) + am+1(j+1) + am+2(j+1) + … + an(j+1) = Columna j+1
= amn + a(m+1)n + a(m+2)n + … + ann = Columna n
A continuación, se divide cada valor de la matriz por la suma de su respectiva
columna.
Tabla 5. Matriz Normalizada
SR-1 SR-2 SR-3 SR-4 SR-5 SR-6 SR-7 SR-8
SR-1 0,03333333 0,00357143 0,01234568 0,02366864 0,02435065 0,0265252 0,05847953 0,12184508
SR-2 0,3 0,03214286 0,02469136 0,01775148 0,00974026 0,01591512 0,02923977 0,05221932
SR-3 0,2 0,09642857 0,07407407 0,03550296 0,02435065 0,0397878 0,0877193 0,09138381
SR-4 0,1 0,12857143 0,14814815 0,07100592 0,01623377 0,0265252 0,05847953 0,12184508
SR-5 0,06666667 0,16071429 0,14814815 0,21301775 0,0487013 0,01591512 0,02923977 0,05221932
SR-6 0,1 0,16071429 0,14814815 0,21301775 0,24350649 0,0795756 0,03508772 0,07310705
SR-7 0,1 0,19285714 0,14814815 0,21301775 0,29220779 0,39787798 0,1754386 0,12184508
SR-8 0,1 0,225 0,2962963 0,21301775 0,34090909 0,39787798 0,52631579 0,36553525
jain
mi
n
mi
jai )1(
n
mi
ain
40
S - 4 COLUMNA DE PUNTUACIÓN
Propósito Hallar la columna de puntuación de los requisitos.
Descripción La puntuación de cada requisito es el porcentaje que el requisito
suma al valor total de los requisitos.
Roles
Rol Responsabilidades
Jefe del proyecto Lidera el proceso.
Técnica
Para determinar la puntuación de cada requisito, se halla el promedio de la fila de la
matriz normalizada, dividiendo la suma de cada fila por el número de requisitos, el
resultante de esta operación es una nueva columna definida aquí como
PUNTUACIÓN.
Promedio para una fila i:
Promedio( =Nim + Ni(m+1) + Ni(m+2) + … + Nin = Fila i), donde Nij es el
valor normalizado de la etiqueta aij.
Tabla 6. Columna de Puntuación.
Puntuación
0,03801494
0,06021252
0,0811559
0,08385113
0,09182779
0,13164463
0,20517406
0,30811902
n
mj
Nij
41
S - 5 VERIFICAR LA CONSISTENCIA
Propósito Verificar que los resultados sean coherentes y fiables.
Descripción
El punto de vista de la coherencia en AHP se basa en la idea de
transitividad cardinal. Por ejemplo, si el requisito A es considerado
como dos veces más importante que B y el requisito B se considera
que es tres veces más importante que el requisito C, la consistencia
cardinal perfecta entonces implicaría que el requisito A se
considerará seis veces más importante que el requisito C. De esta
manera, si los participantes juzgan el requisito A menos importante
que el requisito C, esto implica que un error de juicio existe y la
matriz de priorización es inconsistente.
Roles
Rol Responsabilidades
Jefe del proyecto Lidera el proceso.
Técnica
Se utiliza el índice de consistencia / índice aleatorio (CI / RI) para verificar la
consistencia de los resultados.
Calcular el producto entre la matriz de comparación (ver tabla 1.) y el vector de
puntuaciones (ver tabla 5.). Esto genera una nueva columna denominada aquí,
PRODUCTO.
Calcular los ratios; Para esto se crea una nueva columna definida aquí como
RATIO. En la primera celda de esta nueva columna se registra el ratio el cual se
halla dividiendo la primera celda de la columna PRODUCTO entre la primera celda
de la columna PUNTUACIÓN. En la segunda celda de la nueva columna se registra
el ratio que se halla dividiendo la segunda celda de la columna PRODUCTO entre
la segunda celda de la columna PUNTUACIÓN, respectivamente esto se repite
para cada celda subsiguiente.
Calcular el valor de CI; Calcular el índice de consistencia con la fórmula "=
(promedio (columna Ratio) - n) / n - 1" donde n es el número de requisitos.
Calcular la puntuación de CI / RI. Si la puntuación de CI / RI es suficientemente
pequeña, entonces las comparaciones de los participantes son probablemente lo
suficientemente consistentes como para ser útil. Thomas Saaty sugiere que si el CI
/ RI es menor que 0.10, entonces el grado de consistencia es satisfactorio, sin
42
embargo, si el CI / RI es mayor que 0.10, hay incoherencias y el método AHP no
puede dar resultados significativos. Para calcular la puntuación de CI / RI, se
obtiene el valor de RI estándar de la información de Saaty, algunos de los valores
de RI están listados en la Tabla 6.
Tabla 7. Random index values - Índice de valores aleatorios
Tabla 8. Ratio
Tabla 9. Según el número de requisitos, para este ejemplo el indice
aleatorio(RI) es 1,41
Numero de requisitos 2 3 4 5 6 7 8 9 10
RI 0 0,58 0,9 1,12 1,24 1,32 1,41 1,45 1,51
Producto Ratio
0,3470747 9,12995502
0,5732689 9,52075945
0,8231617 10,1429684
0,8466463 10,0970171
0,9873271 10,7519415
1,5224148 11,5645799
2,4062555 11,7278736
3,3363684 10,8281805
CI 0,35291563
CI/RI 0,25029478
SALIDAS DEL MÉTODO
Las salidas del método deben contener dos tipos de diagramas que muestren el
comportamiento de cada requisito según el valor y costo. Debe mostrar una tercera
gráfica, donde se exponen las prioridades para cada requisito del proyecto.
Gráfica 1; Distribución del Valor de los requisitos.
Gráfica 2; Distribución del Costo de los requisitos.
43
Gráfica 3; Diagrama Costo vs Valor, este diagrama está dividido en tres
grupos.
a) Alto ratio valor-costo de los requisitos (mayor de 2,0).
b) Medio ratio valor-costo de los requisitos (entre 2,0 y 0,5).
c) Bajo ratio valor-costo de los requisitos (menos de 0,5).
Binary Search Tree (BST) – Árbol Binario de Búsqueda
Adelson-Velskii y Landis
El Árbol de búsqueda binaria es un algoritmo que se utiliza normalmente en la
búsqueda y/o recuperación de información y se puede escalar fácilmente para ser
utilizado en la priorización de requisitos. Se recomienda que el árbol siempre este
equilibrado para una inserción más rápida. A este tipo de árbol equilibrado se le
llama Árbol AVL.
En los árboles AVL el factor de equilibrio de un nodo es la altura de su subárbol
izquierdo menos la altura de su subárbol derecho (a veces lo contrario) y un nodo
con un factor de equilibrio 1, 0 o -1 se considera equilibrado. Un nodo con
cualquier otro factor de equilibrio se considera desequilibrado y requiere
reequilibrar el árbol. El factor de equilibrio se almacena directamente en cada
nodo o es calculado a partir de las alturas de los subárboles.
Proceso
ENTRADAS
Lista de
requisitos.
SALIDAS
Requisitos
priorizados.
ACTIVIDADES
B-1: Listar requisitos
B-2: Comparación de
nodos (inserción)
ENTRADAS AL MÉTODO
Lista de requisitos
44
ACTIVIDADES DEL MÉTODO
B - 1 LISTAR REQUISITOS
Propósito Listar los requisitos.
Descripción
Identificar los items que se van a priorizar en este proceso de
análisis. Todos los ítems deben estar al mismo nivel de
abstracción; no se deben mezclar requisitos con algo tan general
como las características.
Roles
Rol Responsabilidades
Jefe del Proyecto Lidera el proceso.
Técnica
Los requisitos identificados se organizan en una lista.
B - 2 COMPARACIÓN DE NODOS
Propósito Identificar los requisitos que según el valor/importancia de cada
uno, tengan mayor prioridad en el proyecto.
Descripción
Para la comparación, se elije de la lista de requisitos un nodo, el
cual lleva el nombre de Raiz, los nodos secundarios a la derecha
tienen un mayor valor | importancia que el nodo raíz, y los nodos
secundarios a la izquierda tienen menos valor | importancia que
el nodo raíz. Cada nodo hijo es en sí mismo un nodo raíz a su
porpio nodo hijo. Si un nodo no tiene ningún hijo, este se llama
hoja.
45
Roles
Rol Responsabilidades
Principales
representantes de los
desarrolladores
Líder del equipo técnico.
Suministra las
puntuaciones para el
valor | importancia.
Principales
representantes del
cliente
Suministra las
puntuaciones para el
valor | importancia.
Técnica
Arbitrariamente se toma uno de los requisitos y se hubica como nodo raíz. Se
toma otro de los requisitos y se compara con el nodo raíz, si el requisito es menos
importante (valor|importancia), entonces el nodo raíz, se compara con el hijo de la
izquierda. Si el requisito es más importante (valor|importancia) que el nodo raíz, se
compara con el hijo de la derecha. Si el nodo no tiene ningún nodo
secundario(hijo) apropiado, introduzca el nuevo requisito como el nuevo nodo
secundario a la derecha o a la izquierda, dependiendo de si el requisito es más o
menos importante.
Lo anterior se repite hasta que todos los requisitos hayan sido comparados.
SALIDAS DEL MÉTODO
Luego de situar en una nueva lista los requisitos, y según el orden jerárquico que
esta representado en el árbol final; para la salida de este método se debe tener la
priorización de los requisitos, ordenados de mayor a menor según su grado de
prioridad.
Planning Game (PG)
Planning Game (PG) es una función de programación extrema (XP) y se utiliza
con los clientes para dar prioridad a las características basadas en “historias”. El
cliente distribuye los requisitos en tres grupos, "aquellos sin los cuales el sistema
no funcionará", "los que son menos esenciales, pero proporcionan un importante
valor empresarial", y "los que seria agradable tener.”(nice to have).
46
Proceso
ENTRADAS
Lista de
requisitos.
SALIDAS
Lista de los
requisitos con la
mayor prioridad.
ACTIVIDADES
PG-1: Categorizar
requisitos
ENTRADAS AL MÉTODO
Lista de requisitos.
ACTIVIDADES DEL MÉTODO
PG - 1 CATEGORIZAR REQUISITOS
Propósito Identificar aquellos requisitos con los cuales se debe empezar el
desarrollo del proyecto.
Descripción
Los requisitos se distribuyen en tres grupos "aquellos sin los cuales
el sistema no funcionará", "los que son menos esenciales, pero
proporcionan un importante valor empresarial", y "los que sería
agradable tener.”(nice to have).
Roles
Rol Responsabilidades
Principales
representantes del
cliente
Cataloga los requisitos,
según el valor que estos
tengan en el proyecto.
Técnica
A partir de una estimación subjetiva, se aprecia el valor que cada requisito, con su
implementación, otorga al producto. Según esta apreciación se decide a cual de las
tres categorias pertenece el requisito.
El sistema se debe empezar a desarrollar con aquellos requisitos que han sido
catalogados como, "aquellos sin los cuales el sistema no funcionará".
47
SALIDAS DEL MÉTODO
Luego de situar en una nueva lista los requisitos, según su clase y valor que le
aporta al producto final. Para la salida de este método se debe tener los requisitos
organizados por categorías.
Categorías:
a) Aquellos sin los cuales el sistema no funcionará.
b) Los que son menos esenciales, pero proporcionan un importante valor
empresarial
c) Los que seria agradable tener (nice to have).
100 Point Method - 100P
El método de los 100 puntos es básicamente un sistema de votación parecido a el
que se utiliza en los ejercicios de lluvia de ideas. Cada actor dispone de 100
puntos que él o ella puede utilizar para votar a favor de los requisitos más
importantes. Los 100 puntos se pueden distribuir de cualquier forma que el
interesado desee. Por ejemplo, si hay dos requisitos que el actor considera con la
misma prioridad, se le puede poner 50 puntos a cada uno. Sin embargo, este tipo
de esquema sólo funciona para una votación inicial. Después que los resultados
han sido publicados, todos los participantes podrán ver como han sido las
votaciones de los demás, por lo que si una segunda votación se toma, la gente
tiende a redistribuir sus votos para conseguir que sus favoritos avancen en el
esquema de prioridades.
Proceso
ENTRADAS
Lista de
requisitos.
SALIDAS
Priorización de
cada individuo.
Gráfica 2.
ACTIVIDADES
P-1: Asignación de
puntaje
P-2: Calculo de
prioridades
ENTRADAS AL MÉTODO
Las entradas corresponden a los requisitos que el analista ha recolectado
previamente en el proceso de elicitación.
Lista de requisitos.
48
ACTIVIDADES DEL MÉTODO
P - 1 ASIGNACIÓN DE PUNTAJE
Propósito Asignar puntajes a los requisitos.
Descripción Dividir los puntos entre todos los requisitos, de acuerdo a cuál de
los requisitos es más importante para el sistema.
Roles
Rol Responsabilidades
Desarrolladores
Suministra las
puntuaciones de los
requisitos.
Técnica
A partir de una estimación subjetiva, se aprecia el valor que cada requisito, con su
implementación, otorga al producto. Según esta apreciación se asigna un puntaje a
cada requisito.
P - 2 CALCULO DE PRIORIDADES
Propósito Obtener las prioridades de cada requisito.
Descripción
Después de que cada uno de los integrantes del grupo han
asignado puntos a los requisitos, se calcula el valor total de cada
uno de ellos.
Roles
Rol Responsabilidades
Jefe del Proyecto Lidera el proceso.
49
Técnica
Se recolectan los puntajes que cada participante le ha asignado a cada uno de los
requisitos. Se suman estos puntajes de manera independiente, es decir,
respectivamente para cada requisito. Así, el puntaje del requisito 1 del participante
A se suma con el puntaje del requisito 1 del participante B, C, D, etc. Esto se
repite para todos los requisitos.
SALIDAS DEL MÉTODO
Para la salida de este método se debe tener la priorización que cada uno de los
desarrolladores le asigno a los requisitos y la priorización global de los mismos.
Wiegers’ Method – Metodo de Wiegers
Karl E. Wiegers
Priorización basada en valor, costo, y riesgo relativo.
Este método se relaciona directamente con el valor de cada requisito.
La prioridad se calcula dividiendo el valor de un requisito por la suma de los
costos y riesgos técnicos asociados con su implementación. El valor de un
requisito se considera como función tanto en el valor proporcionado por el cliente
para el cliente y la pena que se produce si el requisito falta. Esto significa que los
desarrolladores deben evaluar el costo de las necesidades y los riesgos de
implementación, así como la pena impuesta si el requisito falta. Los atributos son
evaluados en una escala del 1 al 9.
50
Proceso
ENTRADAS
Influencia relativa.
Beneficio relativo.
Penalidad
relativa.
Costo relativo.
Riesgo relativo
SALIDAS
Prioridad de los
requisitos
ACTIVIDADES
W-1: Listar requisitos
W-2: Beneficio relativo
W-3: Penalidad relativa
W-4: Valor total
W-5: Costo relativo
W-6: Riesgo relativo
W-7: Calculo de
prioridades
W-8: Ordenar
ENTRADAS AL MÉTODO
Las entradas en este método corresponden a los requisitos de carácter
negociable, aquellos que no se encuentran en la cima de la lista de priorización.
Es decir, no se debe incluir en este análisis, aquellos requisitos que
corresponden al núcleo del producto, aquellos que se definan como claves, parte
esencial o aquellos que sean necesarios para el cumplimiento de las regulaciones
gubernamentales. Una vez identificados estos requisitos, que definitivamente
deben ser desarrollados para que el producto pueda ser entregado, se usa el
Modelo (ver Figura 1) para determinar la prioridad de los requisitos restantes.
Lista de requisitos, características o casos.
Influencia relativa: Es el peso de cada factor en el proyecto.
Factores:
Beneficio relativo: Valor relativo que se le da a cada requisito según el
beneficio que con su implementación este otorga al producto.
Penalidad Relativa: Valor relativo que se estima por la no implementación
de un requisito.
Costo relativo: El costo relativo se refiere a la extensión de tiempo o trabajo
que los desarrolladores estiman se presentara en la implementación de
cada requisito.
Riesgo relativo: El grado relativo de cualquier tipo de riesgo asociado a los
requisitos. (Riesgo de negocio, técnico, de estimación, etc.).
51
Actividades y proceso del método
W - 1 LISTAR REQUISITOS
Propósito Listar los requisitos, características o casos que se desean
priorizar.
Descripción
Identificar los items que se van a priorizar en este proceso de
análisis. Todos los ítems deben estar al mismo nivel de abstracción;
no se deben mezclar requisitos con algo tan general como las
características.
Roles
Rol Responsabilidades
Jefe del Proyecto
Lidera el proceso.
Arbitra conflictos.
Ajusta el aporte de los
otros participantes si es
necesario.
Técnica
Para listar los requisitos se deben tener en cuenta ciertas normas y caracteristicas
inherentes a los propios, por ejemplo; Una norma sería; si algunos requisitos estan
conectados logicamente: - se implementaria un requisito B solo si el requisito A
fuera implementado – para este caso solo se lista el requisito conductor.
W - 2 BENEFICIO RELATIVO
Propósito Estimar el beneficio relativo que cada requisito provee al cliente o al
negocio.
Descripción En una escala del 1 al 9 se valora el beneficio relativo del requisito,
donde 1 indica “Beneficio despreciable” y 9 significa “Enorme valor”.
Roles
Rol Responsabilidades
Principales
representantes del
cliente
Suministra las
puntuaciones para el
beneficio y la penalidad.
52
Técnica
A partir de una estimación subjetiva, se valora el beneficio que cada requisito con
su implementación otorga al producto.
W - 3 PENALIDAD RELATIVA
Propósito Estimar la penalidad relativa que el cliente o el negocio sufriría si el
requisito no es implementado.
Descripción En una escala del 1 al 9 se valora la penalidad relativa del requisito,
donde 1 indica “ningun inconveniente” y 9 significa “sanción grave”.
Roles
Rol Responsabilidades
Principales
representantes del
cliente
Suministra las
puntuaciones para el
beneficio y la penalidad.
Técnica
A partir de una estimación subjetiva, se valora la penalidad que cada requisito con
la omisión de su implementación otorga al producto
W - 4 VALOR TOTAL
Propósito
Calcular el valor total de las puntuaciones en los requisitos respecto
a penalidad y beneficio. Calcular el valor porcentual de cada
requisito.
Descripción
A partir de las estimaciones de beneficio relativo y penalidad
relativa se llega a calcular el valor total y posteriormente el valor
porcentual que cada requisito otorga al total (Valor %).
53
Roles
Rol Responsabilidades
Jefe del Proyecto Lidera el proceso.
Técnica
Para el valor total (En la Figura 1, columna Valor Total), primero se multiplica la
valorización en cada requisito por la influencia relativa del respectivo factor
(Beneficio relativo, Penalidad relativa). Por defecto los beneficios y las penalidades
tienen una influencia equitativa, como un refinamiento de la tecnica se pueden
cambiar las influencias para cada factor.
Luego se suman estos resultados para cada requisito, se totalizan los valores de
los requisitos y se calcula el porcentaje (Valor %) que cada requisito tiene en este
total.
Suponiendo que;
Valor Total para un requisito(VTi)
Beneficio Relativo de un Requisito(BRRi)
Penalidad Relativa de un Requisito(PRRi)
Influencia Relativa del Beneficio(IB)
Influencia Relativa de la Penalidad(IP)
Se puede decir que;
VTi = (BRRi *IB) + (PRRi *IP)
Valori % = , donde n es el número de requisitos
n
i
VTi1
100 * VTi
54
W - 5 COSTO RELATIVO
Propósito Estimar el costo relativo que conlleva la implementación de cada
requisito.
Descripción
Se valora el costo que cada requisito con su implementación
otorga al producto. Este costo se mide según la extensión de
tiempo o trabajo que cada requisito le agregue al proyecto.
Roles
Rol Responsabilidades
Principales
representantes de los
desarrolladores
Líder del equipo técnico.
Técnica
Se valora el costo relativo de la implementación de los requisitos en una escala de
1 (bajo) a 9 (alto). Luego se calcula el porcentaje que cada requisito contribuye en
el costo total. Hallar el costo total es similar a calcular el valor total. Los
desarrolladores pueden estimar los costos basados en la complejidad del
requisito, el trabajo que requiere hacer la interfaz de usuario, la habilidad para la
reutilizacion de codigo existente, la cantidad de pruebas y documentación que se
necesitara, etc.
Suponiendo que;
Costo Relativo para un requisito(CRi)
Se puede decir que;
Costo Total = , donde n es el número de requisitos.
Costo % =
iCRn
i
1
n
i
CRi1
100 * CRi
55
W - 6 RIESGO RELATIVO
Propósito Estimar el grado relativo de riesgo que conlleva la implementación
de cada requisito.
Descripción
Similar al costo relativo, los desarrolladores deben estimar el
grado relativo de cualquier tipo de riesgo asociado a cada requisito
en una escala de 1 a 9. Un puntaje de 1 significa que el requisito
se puede programar con un bajo nivel de concentración, mientras
que 9 indica serias preocupaciones sobre la viabilidad.
Roles
Rol Responsabilidades
Principales
representantes de los
desarrolladores
Líder del equipo técnico.
Técnica
Se calcula el porcentaje del riesgo total que proviene de cada requisito. Por
defecto, beneficio, penalidad , costo y riesgo tienen una influencia equitativa, pero
estas pueden ser ajustadas. Si no se quiere considerar el riesgo en el total del
Modelo, este puede cambiarse a cero.
Suponiendo que;
Riesgo Relativo para un requisito(RRi)
Se puede decir que;
Riesgo Total = , donde n es el número de requisitos.
Riesgo % =
iRRn
i
1
n
i
RRi1
100 * RRi
56
W - 7 CALCULO DE PRIORIDADES
Propósito Obtener la prioridad de cada requisito.
Descripción Una vez estimado todo los factores anteriores, se calcula la
prioridad para cada requisito.
Roles
Rol Responsabilidades
Principales
representantes de los
desarrolladores
Líder del equipo técnico.
Técnica
Con la siguiente formula se calculan las prioridades de cada requisito:
Figura 1. Modelo: Matriz de priorización
Influencias
relativas:
1 1 1 1
Requisitos Benefici
o
Relativo
Penalid
ad
Relativa
Valor
Total
Valor % Costo
Relativo
Costo
%
Riesgo
Relativo
Riesgo
%
Priorida
d
1.
2.
3.
4.
5.
6.
7.
n.
)inf*%()cosinf*%(
%
RiesgoluenciaDelriesgotoluenciaDelCosto
Valorprioridad
57
W - 8 ORDENAR
Propósito Ordenar la lista para tener mejor visibilidad de las prioridades.
Descripción Ordenar la lista de características en orden decreciente de
prioridad.
Roles
Rol Responsabilidades
Principales
representantes de los
desarrolladores
Líder del equipo técnico.
SALIDAS DEL MÉTODO
Para la salida de este método se debe tener la priorización de los requisitos que
fueron candidatos, ordenados de mayor a menor según su grado de prioridad.
58
5. ANÁLISIS DE APROPIACIÓN Y USO DE LAS TÉCNICAS POR LA
INDUSTRIA DEL SOFTWARE.
Para el estudio del contexto de las empresas Colombianas en relación a sus
procesos y prácticas de priorización de requisitos en proyectos software, se realizó
una caracterización a las empresas del Sur Occidente Colombiano según los
siguientes objetivos:
Tener un diagnóstico de los procedimientos, técnicas, métodos y herramientas
que utilizan como soporte a los procesos de administración de requisitos en
proyectos software.
Obtener una idea global de los atributos organizacionales de las empresas del
contexto.
Asociar tipos de empresas a tipos de procedimientos, técnicas, métodos y
herramientas para priorizar requisitos en proyectos software.
La estrategia seleccionada para adelantar el estudio, fue utilizar la encuesta como
instrumento de recolección de información.
5.1 FICHA TÉCNICA DE LA ENCUESTA
La muestra de este estudio consta de 16 empresas pequeñas desarrolladoras de
software del sur occidente Colombiano.
Las empresas fuentes de información para la encuesta se escogieron bajo el
criterio aleatorio. En lo que respecta al componente aleatorio, cada empresa tenía
la misma probabilidad de ser escogida.
Las encuestas se aplicaron a empresas ubicadas en la capital del Valle del Cauca
y Bogotá.
59
Tabla 10. Ficha técnica del estudio adelantado
Universo en estudio Empresas desarrolladoras de software e integradoras de sistemas.
Tamaño de muestra 16 empresas
Distribución de la
muestra 93,8 % Cali, 6,2 % Bogotá
Cobertura Geográfica
Cali (15 empresas)
Bogotá (1 empresa)
Error muestral + 4.02%
Nivel de Confianza 95,5%
Tipo de muestreo Aleatorio, Mixto
Recolección de la
información Entrevistas personales en empresas
Fecha del trabajo de
campo 26 de febrero de 2011 – 30 de Marzo de 2012
Se realizaron entrevistas guiadas a los ingenieros involucrados en las actividades
de desarrollo de software de cada una de las empresas de la muestra a través de
un cuestionario conformado por dos secciones para un total de 7 preguntas (ver
Anexo A: Encuesta para el estudio de contexto):
Sección 1: Información general de la organización de la empresa.
Sección 2: Información sobre la aplicación de métodos de priorización de
requisitos.
5.2 RESULTADOS DE LA EVALUACIÓN
A continuación se presentan los resultados para las preguntas de cada sección.
Sólo se consideran aquellas pertinentes al proyecto de mejora a adelantar, y el
número de la pregunta referenciado corresponde al número en el instrumento
completo (ver Anexo A).
60
5.2.1 Sección 1: Información general. En esta sección de información general se
buscaba entender aspectos organizacionales, administrativos, financieros, de
comercialización y características del mercado al cual proveen productos y
servicios. Se recolectó información mediante 5 preguntas.
Para el interés particular se analizan cuatro de las preguntas (1, 2, 3 y 5 del Anexo
A).
5.2.1.1 Pregunta 1. Marque con una X el tamaño de su empresa de acuerdo a:
Ingenieros relacionados con las actividades de desarrollo de software. Se ofrecían
los rangos 1-3, 4-7, 8-15, 16 – 40, 40 ó más.
Tabla 11. Ingenieros de sistemas en las empresas
Número
de Ingenieros
Frecuencia Porcentaje
1 – 3 3 18,75 %
4 – 7 4 25 %
8 – 15 2 12,5 %
16 – 40 4 25%
40 ó más 3 18,75 %
61
Figura 2. Ingenieros de sistemas en las empresas
18,75%
25%
12,50%
25%
18,75%
0,00%
5,00%
10,00%
15,00%
20,00%
25,00%
30,00%
1 – 3 4 – 7 8 – 15 16 – 40 40 ó más
Nú
me
ro d
e e
mp
resa
s (%
)
Número de Ingenieros de sistemas
Los anteriores porcentajes nos dan una idea del tamaño de la empresa en lo que
respecta a recursos humanos directamente relacionados con desarrollo de
productos software. Con esta medida podemos saber de cuán compleja puede ser
la organización y administración en una empresa.
5.2.1.2 Pregunta 2. ¿Cuántos productos de software tiene su empresa?
Tabla 12. Número de productos software por empresa.
Empresa Nº de productos
1 5
2 0
3 5
4 0
5 8
6 0
7 8
8 3
9 3
62
Tabla 12. (Continua)
Empresa Nº de productos
10 1
11 3
12 0
13 10
14 5
15 3
16 0
Según el número de productos software de cada empresa se puede hacer una
idea de la experiencia de estas empresas en cuestión de métodos de
administración de proyectos y técnicas de priorización, partimos del hecho de que
se aprende de las experiencias y se supone por cada desarrollo un refinamiento
de las técnicas.
Figura 3. Relación Tamaño de la empresa vs Número de productos.
La Figura 3 muestra el tamaño de la empresa por número de desarrolladores
vinculados directamente en los proyectos software con relación al número de
productos por empresa. Para que se pueda leer de una forma más clara la anterior
figura, a continuación las equivalencias de los tamaños diagramados en la Figura
3 según los datos en la encuesta.
5
1
5 4
1
3
1 2 2 2
3 4 4
2
4
0
2
4
6
8
10
12
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
Empresas
Nº de productos
Tamaño
63
Tabla 13. Equivalencias de tamaño con Rangos en encuesta.
Tamaño Rangos
1 1-3
2 4-7
3 8-15
4 16-40
5 40-más
5.2.1.3 Pregunta 3. ¿Cuál es su actividad principal? Para este caso se
ofrecían las opciones:
Desarrollo de software hecho a la medida
Desarrollo de software genérico
Tabla 14. Actividades principales por empresa
Empresa Software a la medida Software genérico
1 x
2 x
3 x
4 x
5 x
6 - -
7 x
8 x x
9 x x
10 x
11 x
12 x
13 x
14 x
15 x
16 x
64
Figura 4. Actividades de las empresas
5.2.1.4 Pregunta 4. ¿Cuáles de los siguientes modelos ha implementado su
organización en los últimos 3 años?
Tabla 15. Modelos implementados por las empresas
CMM-SW CMMI SPICE ISO 9001 PSP/TSP NA No sabe Otros
1 x
2 x
3 x
4 x
5 x
6 x
7 x
8 RAD
9 x
10 x SCRUM
11 x
12 x
13 x
14 x x
15 x
16 x
56,25%
25%
12,50%
6,25%
0
1
2
3
4
5
6
7
8
9
10
Software a la medida Sofware genérico Sofware genérico y a la medida
ninguno
Nú
me
ro d
e e
mp
resa
s
Actividades de las empresas
65
La mayoría de las empresas hace uso de un modelo de procesos para el
desarrollo y mantenimiento de sistemas de software. De la Tabla 15 se puede
concluir que las empresas buscan la organización y madurez de sus procesos.
Sección 2: Información sobre la aplicación de los métodos de priorización de
los requisitos.
5.2.1.5 Pregunta 5. De la cartilla adjunta cuál(es) método(s) de priorización de
requisitos aplica.
Métodos combinatorios.
Métodos mixtos combinatorios.
Método
s de votación.
Tabla 16. Aplicación de métodos de priorización de requisitos en las
empresas.
Combinatorio Mixto Votación Otros, ¿Cuál(es)?
1 x
2 x x
3 na
4 x
5 x
6 x
7 x
8 x
9 x x
10 x x
11 x
12 x
13 x
14 Propio
15 x
16 x
66
La Tabla 16 da una visión global de la metodología de cada empresa respecto a
priorización de requisitos.
Tabla 17. Aplicación de métodos de priorización de requisitos en las
empresas(Desarrollo de software hecho a la medida) .
Combinatorio Mixto Votación Otros, ¿Cuál(es)?
1 x
2 x x
3
4 x
5 x
7 x
10 x x
12 x
16 x
Tabla 18. Aplicación de métodos de priorización de requisitos en las
empresas (Desarrollo de software genérico).
Combinatorio Mixto Votación Otros, ¿Cuál(es)?
11 x
13 x
14 Propio
15 x
Tabla 19. Aplicación de métodos de priorización de requisitos en las
empresas(Desarrollo de software hecho a la medida y genérico).
Combinatorio Mixto Votación Otros, ¿Cuál(es)?
8 x
9 x x
De la tabla 17 a la 19 se dividen las empresas en 3 grupos; Desarrollo de software
hecho a la medida, genérico y hecho a la medida y genérico, de estos 3 grupos se
hace una categorización de las empresas respecto a la aplicación de métodos de
priorización de requisitos.
67
6. CONCLUSIONES DE LA EVALUACIÓN
Se pudo saber cómo las empresas implementan modelos de desarrollo de
software entre los cuales algunos, como el CMMI, sugieren la priorización de
requisitos. El estudio indica que las empresas, según sus modelos de desarrollo,
de alguna forma sí aplican priorización de requisitos.
A través de una caracterización de las empresas se pudieron obtener tres tipos de
organizaciones, las cuales al evaluarlas por separado, pero en un mismo
concepto, han arrojado datos similares (ver Tablas 17 - 19); es decir;
Figura 5. Conclusiones de la evaluación
Al parecer los métodos combinatorios son ciertamente preferidos por las empresas
o bien son de los más conocidos, ya que el indicador arroja mayor porcentaje de
uso de este tipo de técnicas para la priorización de requisitos.
Ya que la teoría indica que tanto el ambiente organizacional como la naturaleza de
los proyectos definen la técnica que se debe usar para la priorización de los
68
requisitos, en un principio se pensó que por cada tipo de empresa (categorizadas
según la actividad principal, a) Desarrollo de software a la medida, b) genérico o,
c) genérico y a la medida), se practicaría de forma distinta la priorización, sin
embargo para la mayoría de casos las empresas utilizan los métodos
combinatorios, donde la técnica más conocida y practicada es Numeral
Assignment Technique.
Lo que hacen estas empresas es simplemente asignar valores a cada requisito
basándose en experiencias de otros proyectos, ocasionando que la priorización en
el caso de Numeral Assignment Technique sea subjetiva y poco precisa.
69
7. ANÁLISIS DE HERRAMIENTAS DE ADMINISTRACIÓN DE REQUISITOS
El análisis consta de un grupo de herramientas usadas en la administración de
proyectos software. Este análisis quiere determinar cuáles de las técnicas se
utilizan más en los procesos de gestión de requisitos. Es importante saber cual
técnica implementan estas herramientas en su proceso de priorización ya que son
productos muy usados y reconocidos en la industria.
Para la elección de estas empresas y sus herramientas se usó el método
aleatorio. En lo que respecta al componente aleatorio, cada herramienta tenía la
misma probabilidad de ser escogida.
7.1 RESULTADOS DE LA EVALUACIÓN
7.1.1 Pregunta 1. ¿Su herrramienta usa algunas de las siguientes técnicas:
Binary Search Tree, Numeral Assignment Technique, Planning Game, the 100-
Point Method, Theory-W, Requirements Triage, Wiegers' Method, Requirements
Prioritization Framework, y AHP? Listelas.
70
7.1.2 Pregunta 2. ¿Usa algún otra técnica? ¿Cuál?
Tabla 20. Herramientas de administraciones
Herramientas Distribuidor
Bin
ary
Se
arc
h T
ree
Nu
mera
l A
ssig
nm
en
t
Tech
niq
ue
Pla
nn
ing
Gam
e
100
-Po
int
Meth
od
Th
eo
ry-W
Req
uir
em
en
ts T
riag
e
Wie
ge
rs' M
eth
od
Req
uir
em
en
ts
Pri
ori
tizati
on
Fra
mew
ork
AH
P
otr
os
Nin
gu
no
Acclaro DFSS Axiomatic Design
Solutions x
Aligned
Elements Aligned x
ReqMan RequirementOne x
IRqA Visure Solutions x x x x x x KAN
O
Cognition
Cockpit Cognition x
RaQuest SparxSystems x x x
De nuevo el estudio arroja que una mayoría, en este caso 50%, implementa en su
proceso de administración de requisitos, los métodos combinatorios para priorizar,
más que nada la técnica Numeral Assigment Technique.
71
8. PROPUESTA; NUEVA TÉCNICA
La diversificación de técnicas de priorización es una práctica muy común para
mejorar procesos ajustando metodologías a cada proyecto y contexto. Haciendo
caso a esta premisa que plantea la diversificación de técnicas, se ha ajustado una
técnica apartándola de su estado único y uniforme para acoplarla a otra esperando
que de esta asociación se complemente una técnica con la otra. El fin de esta
mezcla es refinar una idea y presentar una nueva opción, una nueva técnica.
Antes se ha propuesto la unión de técnicas para la priorización, tomando lo mejor
de cada una y desarrollar una idea mejor. Tomando un ejemplo formal, la unión de
las técnicas AHP y PG, PGcAHP [42], otro ejemplo no tan formal sería la
estrategia de las empresas que priorizan con técnicas propias que en realidad son
una diversificación de otras ya conocidas. Para esta oportunidad la propuesta es la
combinación de las técnicas Planning Game (PG) y Wieger’s Method, PGcWs.
Aunque en una primera instancia se pensó en implementar PGcAHP hoy
pensamos que una técnica como PGcWs se acerca más a la realidad de las
empresas del contexto; se dice “del contexto” porque según cada proyecto y
empresa, varia la técnica a implementar y la técnica per se. Aun cuando PGcAHP
es una técnica bastante precisa y útil, se hace muy exhaustivo el proceso de
valuar en dos matrices distintas cada requisito contra todos los demás, la
metodología cartesiana demanda tiempo y no es rentable para el negocio.
72
PG with Wiegers’ Method – PGcWs
Priorización basada en atributos, valor, costo, y riesgo relativo.
Identificar atributos de los requisitos es importante en este método, ya que a
diferencia de la técnica PG, en PGcWs primero se deben categorizar los
requisitos para priorizar por categoría.
Al igual que en el método de Wieger la prioridad se calcula dividiendo el valor de
un requisito por la suma de los costos y riesgos técnicos asociados con su
implementación. El valor de un requisito se considera como función tanto en el
valor proporcionado por el cliente para el cliente y la pena que se produce si el
requisito falta. Esto significa que los desarrolladores deben evaluar el costo de las
necesidades y los riesgos de implementación, así como la pena impuesta si el
requisito falta. Los atributos son evaluados en una escala del 1 al 9.
Proceso
ENTRADAS
Influencia relativa
Beneficio relativo
Penalidad relativa
Costo relativo
Riesgo relativo
SALIDAS
Prioridad de los
requisitos
ACTIVIDADES
PGWs-1: Listar requisitos
PGWs-2: Categorizar
requisitos
PGWs-3: Beneficio relativo
PGWs-4: Penalidad relativa
PGWs-5: Valor total
PGWs-6: Costo relativo
PGWs-7: Riesgo relativo
PGWs-8: Calculo de
prioridades
PGWs-9: Ordenar
ENTRADAS AL MÉTODO
Las entradas en este método corresponden a todos los requisitos de una
categoría específica. Una vez identificados estos requisitos, se usa el Modelo
(ver Figura 1) para determinar la prioridad de los requisitos en la categoría.
Lista de requisitos, características o casos.
73
Influencia relativa: Es el peso de cada factor en el proyecto.
Factores:
Beneficio relativo: Valor relativo que se le da a cada requisito según el beneficio
que con su implementación este otorga al producto.
Penalidad Relativa: Valor relativo que se estima por la no implementación de un
requisito.
Costo relativo: El costo relativo se refiere a la extensión de tiempo o trabajo que
los desarrolladores estiman se presentara en la implementación de cada
requisito.
Riesgo relativo: El grado relativo de cualquier tipo de riesgo asociado a los
requisitos. (Riesgo de negocio, técnico, de estimación, etc.).
Actividades y proceso del método
W - 1 LISTAR REQUISITOS
Propósito Listar los requisitos, características o casos que se desean
priorizar.
Descripción
Identificar los items que se van a priorizar en este proceso de
análisis. Todos los ítems deben estar al mismo nivel de abstracción;
no se deben mezclar requisitos con algo tan general como las
características.
Roles
Rol Responsabilidades
Jefe del Proyecto
Lidera el proceso.
Arbitra conflictos.
Ajusta el aporte de los
otros participantes si es
necesario.
74
Técnica
Para listar los requisitos se deben tener en cuenta ciertas normas y caracteristicas
inherentes a los propios, por ejemplo; Una norma sería; si algunos requisitos estan
conectados logicamente: - se implementaria un requisito B solo si el requisito A
fuera implementado – para este caso solo se lista el requisito conductor.
PGWs - 2 CATEGORIZAR REQUISITOS
Propósito
Identificar atributos de los requisitos. Dividir en categorías los
requisitos, dejando en cada categoría requisitos un mismo nivel de
abstracción.
Descripción
Los requisitos se distribuyen en grupos según sus características.
Tres grupos base podrían ser "aquellos sin los cuales el sistema no
funcionará", "los que son menos esenciales, pero proporcionan un
importante valor empresarial", y "los que sería agradable
tener.”(nice to have).
Roles
Rol Responsabilidades
Jefe del Proyecto
Lidera el proceso.
Arbitra conflictos.
Ajusta el aporte de los
otros participantes si es
necesario.
Técnica
Se identifican los atributos de cada requisito, luego estos se distribuyen en grupos
según las similitudes en los atributos y características. Se nombra cada grupo
haciendo alusión a las características de los requisitos que ahí se alojan.
PGWs - 3 BENEFICIO RELATIVO
Propósito Estimar el beneficio relativo que cada requisito provee al cliente o al
negocio.
75
Descripción En una escala del 1 al 9 se valora el beneficio relativo del requisito,
donde 1 indica “Beneficio despreciable” y 9 significa “Enorme valor”.
Roles
Rol Responsabilidades
Principales
representantes del
cliente
Suministra las
puntuaciones para el
beneficio y la penalidad.
Técnica
A partir de una estimación subjetiva, se valora el beneficio que cada requisito con
su implementación otorga al producto.
PGWs - 4 PENALIDAD RELATIVA
Propósito Estimar la penalidad relativa que el cliente o el negocio sufriría si el
requisito no es implementado.
Descripción En una escala del 1 al 9 se valora la penalidad relativa del requisito,
donde 1 indica “ningun inconveniente” y 9 significa “sanción grave”.
Roles
Rol Responsabilidades
Principales
representantes del
cliente
Suministra las
puntuaciones para el
beneficio y la penalidad.
Técnica
A partir de una estimación subjetiva, se valora la penalidad que cada requisito con
la omisión de su implementación otorga al producto.
76
PGWs - 5 VALOR TOTAL
Propósito
Calcular el valor total de las puntuaciones en los requisitos respecto
a penalidad y beneficio. Calcular el valor porcentual de cada
requisito.
Descripción
A partir de las estimaciones de beneficio relativo y penalidad
relativa se llega a calcular el valor total y posteriormente el valor
porcentual que cada requisito otorga al total (Valor %).
Roles
Rol Responsabilidades
Jefe del Proyecto
Lidera el proceso.
Arbitra conflictos.
Ajusta el aporte de los
otros participantes si es
necesario.
Técnica
Para el valor total (En la Figura 1, columna Valor Total), primero se multiplica la
valorización en cada requisito por la influencia relativa del respectivo factor
(Beneficio relativo, Penalidad relativa). Por defecto los beneficios y las penalidades
tienen una influencia equitativa, como un refinamiento de la tecnica se pueden
cambiar las influencias para cada factor.
Luego se suman estos resultados para cada requisito, se totalizan los valores de
los requisitos y se calcula el porcentaje (Valor %) que cada requisito tiene en este
total.
Suponiendo que;
Valor Total para un requisito(VTi)
Beneficio Relativo de un Requisito(BRRi)
Penalidad Relativa de un Requisito(PRRi)
Influencia Relativa del Beneficio(IB)
Influencia Relativa de la Penalidad(IP)
Se puede decir que;
VTi = (BRRi *IB) + (PRRi *IP)
77
Valori % =
n
i
VTi1
100 * VTi , donde n es el número de requisitos.
PGWs - 6 COSTO RELATIVO
Propósito Estimar el costo relativo que conlleva la implementación de cada
requisito.
Descripción
Se valora el costo que cada requisito con su implementación otorga
al producto. Este costo se mide según la extensión de tiempo o
trabajo que cada requisito le agregue al proyecto.
Roles
Rol Responsabilidades
Principales
representantes de los
desarrolladores
Líder del equipo técnico.
Suministra las
puntuaciones para el
costo y el riesgo.
Técnica
Se valora el costo relativo de la implementación de los requisitos en una escala de
1 (bajo) a 9 (alto). Luego se calcula el porcentaje que cada requisito contribuye en
el costo total. Hallar el costo total es similar a calcular el valor total. Los
desarrolladores pueden estimar los costos basados en la complejidad del requisito,
el trabajo que requiere hacer la interfaz de usuario, la habilidad para la reutilizacion
de codigo existente, la cantidad de pruebas y documentación que se necesitará,
etc.
Suponiendo que;
Costo Relativo para un requisito(CRi)
Se puede decir que;
Costo Total = iCRn
i
1
, donde n es el número de requisitos.
78
Costo % =
n
i
CRi1
100 * CRi
PGWs - 7 RIESGO RELATIVO
Propósito Estimar el grado relativo de riesgo que conlleva la implementación
de cada requisito.
Descripción
Similar al costo relativo, los desarrolladores deben estimar el grado
relativo de cualquier tipo de riesgo asociado a cada requisito en una
escala de 1 a 9. Un puntaje de 1 significa que el requisito se puede
programar con un bajo nivel de concentración, mientras que 9
indica serias preocupaciones sobre la viabilidad.
Roles
Rol Responsabilidades
Principales
representantes del
cliente
Líder del equipo técnico.
Suministra las
puntuaciones para el
costo y el riesgo.
Técnica
Se calcula el porcentaje del riesgo total que proviene de cada requisito. Por defecto,
beneficio, penalidad , costo y riesgo tienen una influencia equitativa, pero estas
pueden ser ajustadas. Si no se quiere considerar el riesgo en el total del Modelo,
este puede cambiarse a cero.
Suponiendo que;
Riesgo Relativo para un requisito(RRi)
Se puede decir que;
Riesgo Total = iRRn
i
1
, donde n es el número de requisitos.
79
Riesgo % =
n
i
RRi1
100 * RRi
PGWs - 8 CALCULO DE PRIORIDADES
Propósito Obtener las prioridades de cada requisito.
Descripción Una vez estimado todo los factores anteriores, se calcula la
prioridad para cada requisito.
Roles
Rol Responsabilidades
Principales
representantes del
cliente
Líder del equipo técnico.
Suministra las
puntuaciones para el
costo y el riesgo.
Técnica
Con la siguiente formula se calculan las prioridades de cada requisito:
)inf*%()cosinf*%(
%
RiesgoluenciaDelriesgotoluenciaDelCosto
Valorprioridad
80
Figura 6. Modelo: Matriz de priorización
Influencias relativas: 1 1 1 1
Requisitos Beneficio
Relativo
Penalidad
Relativa
Valor
Total
Valor % Costo
Relativo
Costo % Riesgo
Relativo
Riesgo % Prioridad
1.
2.
3.
4.
5.
6.
7.
n.
PGWs - 9 ORDENAR
Propósito Ordenar la lista para tener mejor visibilidad de las prioridades
Descripción Ordenar la lista de características en orden decreciente de
prioridad.
SALIDAS DEL MÉTODO
Para la salida de este método se debe tener la priorización de los requisitos que
fueron candidatos, ordenados de mayor a menor según su grado de prioridad.
81
9. RESULTADOS DE APLICACIÓN DE LAS TÉCNICAS
9.1 CASO CMSOFTLUTIONS
CMSOFTLUTIONS es una empresa colombiana que tiene como actividad principal
el desarrollo de software genérico. En enero de 2012 en una reunión con el
director de desarrollo de dicha empresa, se expuso un grupo de técnicas, entre
ellas; 100P, AHP, BST, PG, Wieger’s Method, esta reunión con el motivo de
validar técnicas y posteriormente aplicar alguna en esa organización. Haciendo
uso de Excel se hizo un ejercicio de priorización ajustado con las técnicas AHP y
Wieger´s Method respectivamente, al término de la reunión se concluyó que el
caso más adecuado para la clase de proyectos que CMSOFTLUTIONS construye,
sería Wieger´s Method por la capacidad que esta técnica tiene para tomar
diversas formas según el tipo de proyecto.
Para este caso se aplicará la técnica PGcWs:
9.1.1 Primero, Listar Requisitos. CMSOFTLUTIONS proporcionó 47 requisitos
de un proyecto que actualmente se encuentra desarrollando. Por motivos de
confidencialidad no se expondrá la descripción de estos requisitos.
9.1.2 Segundo, Categorizar requisitos
Tabla 21. Categorías e influencias
CATEGORÍAS Beneficio Penalidad Costo Riesgo
CORE5 4 4 2 0
NTH6 1 1 1 4
SOFTWARE7 2 2 1 1
INSIDENTES8 4 4 1 1
5 CORE, requisitos básicos del sistema, aquellos sin los cuales el sistema no podría funcionar.
6 NTH, nice to have.
7 SOFTWARE, requisitos funcionales.
8 INSIDENTES, errores que pudieran presentar las aplicaciones desarrolladas
82
9.1.3 Tercero, Beneficio Relativo
Tabla 22. Beneficio relativo (CORE)
Requisitos Beneficio
Relativo
1 9
2 9
3 9
4 9
5 9
6 9
7 9
8 9
9 9
10 9
11 9
12 9
13 9
Tabla 23. Beneficio relativo (INSIDENTES)
Requisitos Beneficio
Relativo
14 4
15 3
16 7
17 5
18 9
19 9
20 8
83
Tabla 24. Beneficio relativo (NTH)
Requisitos Beneficio
Relativo
21 7
22 7
23 5
Tabla 25. Beneficio relativo (SOFTWARE)
Requisitos Beneficio
Relativo
24 9
25 9
26 9
27 9
28 9
29 9
30 9
31 9
32 9
33 9
34 9
35 9
36 7
37 4
38 9
39 9
40 9
41 9
42 9
43 9
44 9
45 8
46 7
47 4
84
9.1.4 Cuarto, Penalidad Relativa
Tabla 26. Penalidad relativa (CORE)
Requisitos Penalidad
Relativa
1 9
2 9
3 9
4 9
5 9
6 9
7 9
8 9
9 9
10 9
11 9
12 9
13 9
Tabla 27. Penalidad relativa (INSIDENTES)
Requisitos Penalidad
Relativa
14 4
15 3
16 7
17 5
18 9
19 9
20 8
85
Tabla 28. Penalidad relativa (NTH)
Requisitos Penalidad
Relativa
21 7
22 7
23 5
Tabla 29. Penalidad relativa (SOFTWARE)
Requisitos Penalidad
Relativa
24 9
25 9
26 9
27 9
28 9
29 9
30 9
31 9
32 9
33 9
34 9
35 9
36 7
37 4
38 9
39 9
40 9
41 9
42 9
43 9
44 9
45 8
46 7
47 4
86
9.1.5 Quinto, Valor Total
Tabla 30. Valor Total (CORE)
Influencia
relativa:
4 4
Requisitos Beneficio
Relativo
Penalidad
Relativa
Valor Total Valor %
1 9 9 72 7,6923
2 9 9 72 7,6923
3 9 9 72 7,6923
4 9 9 72 7,6923
5 9 9 72 7,6923
6 9 9 72 7,6923
7 9 9 72 7,6923
8 9 9 72 7,6923
9 9 9 72 7,6923
10 9 9 72 7,6923
11 9 9 72 7,6923
12 9 9 72 7,6923
13 9 9 72 7,6923
Total 936
Tabla 31. Valor Total (INSIDENTES)
Influencia
relativa:
4 4
Requisitos Beneficio
Relativo
Penalidad
Relativa
Valor Total Valor %
14 4 2 24 6,8182
15 3 1 16 4,5455
16 7 9 64 18,182
17 5 5 40 11,364
18 9 9 72 20,455
19 9 9 72 20,455
20 8 8 64 18,182
Total 352
87
Tabla 32. Valor Total (NTH)
Influencia
relativa:
1 1
Requisitos Beneficio
Relativo
Penalidad
Relativa
Valor Total Valor %
21 7 4 11 35,484
22 7 3 10 32,258
23 5 5 10 32,258
Total 31
Tabla 33. Valor Total (SOFTWARE)
Influencia
relativa:
2 2
Requisitos Beneficio
Relativo
Penalidad
Relativa
Valor Total Valor %
24 9 9 36 4,401
25 9 9 36 4,401
26 9 9 36 4,401
27 9 9 36 4,401
28 9 9 36 4,401
29 9 9 36 4,401
30 9 9 36 4,401
31 9 9 36 4,401
32 9 9 36 4,401
33 9 9 36 4,401
34 9 9 36 4,401
35 9 6 30 3,6675
36 7 9 32 3,912
37 4 7 22 2,6895
38 9 9 36 4,401
39 9 9 36 4,401
40 9 9 36 4,401
41 9 9 36 4,401
42 9 9 36 4,401
43 9 9 36 4,401
44 9 9 36 4,401
45 8 8 32 3,912
46 7 7 28 3,423
47 4 9 26 3,1785
Total 818
88
9.1.6 Sexto, Costo Relativo
Tabla 34. Costo Relativo (CORE)
Requisitos Costo
Relativo Costo %
1 5 8,62069
2 3 5,17241
3 6 10,3448
4 8 13,7931
5 8 13,7931
6 5 8,62069
7 5 8,62069
8 3 5,17241
9 3 5,17241
10 6 10,3448
11 2 3,44828
12 2 3,44828
13 2 3,44828
Tabla 35. Costo Relativo (INSIDENTES)
Requisitos Costo
Relativo Costo %
14 3 21,4286
15 1 7,14286
16 1 7,14286
17 2 14,2857
18 2 14,2857
19 4 28,5714
20 1 7,14286
Tabla 36. Costo Relativo (NTH)
Requisitos Costo
Relativo Costo %
21 2 15,3846
22 9 69,2308
23 2 15,3846
89
Tabla 37. Costo Relativo (SOFTWARE)
Requisitos Costo
Relativo Costo %
24 4 5,33333
25 2 2,66667
26 3 4
27 3 4
28 5 6,66667
29 5 6,66667
30 1 1,33333
31 3 4
32 3 4
33 7 9,33333
34 7 9,33333
35 4 5,33333
36 4 5,33333
37 4 5,33333
38 2 2,66667
39 2 2,66667
40 2 2,66667
41 2 2,66667
42 2 2,66667
43 2 2,66667
44 2 2,66667
45 2 2,66667
46 2 2,66667
47 2 2,66667
90
9.1.7 Séptimo, Riesgo relativo Tabla 38. Riesgo Relativo (CORE)
Requisitos Riesgo
Relativo Riesgo %
1 4 9,09
2 3 6,82
3 6 13,64
4 4 9,09
5 4 9,09
6 4 9,09
7 4 9,09
8 3 6,82
9 3 6,82
10 3 6,82
11 2 4,55
12 2 4,55
13 2 4,55
Tabla 39. Riesgo Relativo (INSIDENTES)
Requisitos Riesgo
Relativo Riesgo %
14 8,33 8,33
15 8,33 8,33
16 8,33 8,33
17 16,67 16,67
18 16,67 16,67
19 33,33 33,33
20 8,33 8,33
Tabla 40. Riesgo Relativo (NTH)
Requisitos Riesgo
Relativo Riesgo %
21 2 15,38
22 9 69,23
23 2 15,38
91
Tabla 41. Riesgo Relativo (SOFTWARE)
Requisitos Riesgo
Relativo Riesgo %
24 3 4,6875
25 2 3,125
26 2 3,125
27 2 3,125
28 4 6,25
29 4 6,25
30 1 1,5625
31 2 3,125
32 2 3,125
33 6 9,375
34 6 9,375
35 2 3,125
36 4 6,25
37 4 6,25
38 2 3,125
39 2 3,125
40 2 3,125
41 2 3,125
42 2 3,125
43 2 3,125
44 2 3,125
45 2 3,125
46 2 3,125
47 2 3,125
92
9.1.8 Octavo, Calculo de Prioridades
Tabla 42. Calculo de prioridad (CORE)
Influencia relativa: 4 4 2 0
Requisitos Beneficio
Relativo
Penalidad
Relativa
Valor
Total
Valor % Costo
Relativo
Costo % Riesgo
Relativo
Riesgo % Prioridad
1 9 9 72 7,6923 5 8,62069 4 9,09 0,45
2 9 9 72 7,6923 3 5,17241 3 6,82 0,74
3 9 9 72 7,6923 6 10,3448 6 13,64 0,37
4 9 9 72 7,6923 8 13,7931 4 9,09 0,28
5 9 9 72 7,6923 8 13,7931 4 9,09 0,28
6 9 9 72 7,6923 5 8,62069 4 9,09 0,45
7 9 9 72 7,6923 5 8,62069 4 9,09 0,45
8 9 9 72 7,6923 3 5,17241 3 6,82 0,74
9 9 9 72 7,6923 3 5,17241 3 6,82 0,74
10 9 9 72 7,6923 6 10,3448 3 6,82 0,37
11 9 9 72 7,6923 2 3,44828 2 4,55 1,12
12 9 9 72 7,6923 2 3,44828 2 4,55 1,12
13 9 9 72 7,6923 2 3,44828 2 4,55 1,12
Totales 936 58 44
Tabla 43. Calculo de prioridad (INSIDENTES)
Influencia relativa: 4 4 1 1
Requisitos Beneficio
Relativo
Penalidad
Relativa
Valor
Total
Valor % Costo
Relativo
Costo % Riesgo
Relativo
Riesgo % Prioridad
14 4 2 24 6,8182 3 21,4286 1 8,33 8,65
15 3 1 16 4,5455 1 7,14286 1 8,33 8,97
16 7 9 64 18,182 1 7,14286 1 8,33 10,88
17 5 5 40 11,364 2 14,2857 2 16,67 17,46
18 9 9 72 20,455 2 14,2857 2 16,67 18,10
19 9 9 72 20,455 4 28,5714 4 33,33 34,05
20 8 8 64 18,182 1 7,14286 1 8,33 10,88
Totales
352
14
12
93
Tabla 44. Calculo de prioridad (NTH)
Influencia relativa: 1 1 1 4
Requisitos Beneficio
Relativo
Penalidad
Relativa
Valor
Total
Valor % Costo
Relativo
Costo % Riesgo
Relativo
Riesgo % Prioridad
21 7 4 11 35,484 2 15,3846 2 15,38 63,84
22 7 3 10 32,258 9 69,2308 9 69,23 277,39
23 5 5 10 32,258 2 15,3846 2 15,38 63,64
Totales
31
13
13
Tabla 45. Calculo de prioridad (SOFTWARE)
Influencia
relativa:
4 4 2 0
Requisitos Benefici
o
Relativo
Penalida
d
Relativa
Valo
r
Total
Valor
%
Costo
Relativ
o
Costo
%
Riesgo
Relativ
o
Riesgo
%
Priorida
d
24 9 9 36 4,401 4 5,33333 3 4,69 5,51
25 9 9 36 4,401 2 2,66667 2 3,13 4,78
26 9 9 36 4,401 3 4 2 3,13 4,23
27 9 9 36 4,401 3 4 2 3,13 4,23
28 9 9 36 4,401 5 6,66667 4 6,25 6,91
29 9 9 36 4,401 5 6,66667 4 6,25 6,91
30 9 9 36 4,401 1 1,33333 1 1,56 4,86
31 9 9 36 4,401 3 4 2 3,13 4,23
32 9 9 36 4,401 3 4 2 3,13 4,23
33 9 9 36 4,401 7 9,33333 6 9,38 9,85
34 9 9 36 4,401 7 9,33333 6 9,38 9,85
35 9 6 30 3,6675 4 5,33333 2 3,13 3,81
36 7 9 32 3,912 4 5,33333 4 6,25 6,98
37 4 7 22 2,6895 4 5,33333 4 6,25 6,75
38 9 9 36 4,401 2 2,66667 2 3,13 4,78
39 9 9 36 4,401 2 2,66667 2 3,13 4,78
40 9 9 36 4,401 2 2,66667 2 3,13 4,78
41 9 9 36 4,401 2 2,66667 2 3,13 4,78
42 9 9 36 4,401 2 2,66667 2 3,13 4,78
43 9 9 36 4,401 2 2,66667 2 3,13 4,78
44 9 9 36 4,401 2 2,66667 2 3,13 4,78
45 8 8 32 3,912 2 2,66667 2 3,13 4,59
46 7 7 28 3,423 2 2,66667 2 3,13 4,41
47 4 9 26 3,1785 2 2,66667 2 3,13 4,32
Totales 818 75 64
94
9.1.9 Noveno, Ordenar Tabla 46. Requisitos ordenados (CORE) Requisitos Prioridad
11 1,12
12 1,12
13 1,12
2 0,74
8 0,74
9 0,74
1 0,45
6 0,45
7 0,45
3 0,37
10 0,37
4 0,28
5 0,28
Tabla 47. Requisitos ordenados (INISIDENTES) Requisitos Prioridad
19 34,05
18 18,10
17 17,46
16 10,88
20 10,88
15 8,97
14 8,65
Tabla 48. Requisitos ordenados (NTH)
Requisitos Prioridad
22 277,39
21 63,84
23 63,64
95
Tabla 49. Requisitos ordenados (SOFTWARE)
Requisitos Prioridad
33 9,85
34 9,85
36 6,98
28 6,91
29 6,91
37 6,75
24 5,51
30 4,86
25 4,78
38 4,78
39 4,78
40 4,78
41 4,78
42 4,78
43 4,78
44 4,78
45 4,59
46 4,41
47 4,32
26 4,23
27 4,23
31 4,23
32 4,23
35 3,81
El ejercicio de aplicación de la técnica PGcWs ha arrojado la priorización para
cada una de las categorías (CORE, INSIDENTES, NTH, SOFTWARE), no se
podría hacer una comparación contra la priorización de CMSOFTLUTIONS ya
que, para este proyecto, esa empresa no realizó.
El orden para el desarrollo de cada categoría es; CORE, SOFTWARE,
INSIDENTES, NTH, INSIDENTES9.
9 Los INSIDENTES en este caso aparecen dos veces en el orden, ya que luego del desarrollo de
los requisitos NTH se podrían presentar nuevos errores en la aplicación.
96
9.2 CASO COOMEVA
COOMEVA es una organización Colombiana que realiza proyectos a la medida e
insourcing. En diciembre de 2011 se hizo contacto con esta empresa la cual
estuvo muy interesada en la aplicación de una técnica de priorización en sus
procesos de administración de requisitos.
En cada proyecto software, COOMEVA maneja extensas listas de requisitos, lo
cual hace necesario el agrupamiento de estos según sus características, es decir,
definir categorías especificas en las cuales se distribuyan los diferentes requisitos
con el objetivo de priorizar las categoría por separado. Por lo anterior, se infiere
que Planning Game (PG) es la técnica más adecuada, aunque para hacer de la
aplicación algo más completo se pensó en unir PG con Wieger´s Method
aprovechando de esta última su capacidad para priorizar de manera distinta en
cada proyecto (Ver anexo B).
97
10. TRABAJOS FUTUROS
Para CMSOFTLUTIONS y COOMEVA se construirá un software que permita
priorizar requisitos basado en una combinación de las técnicas Wieger`s Method y
Planning Game (ver Anexo B), CMSOFTLUTIONS posee una herramienta propia
de administración de requisitos a la cual se le añadirá el módulo de priorización.
Este trabajo será complemento en la presentación de un método que busca
integrarse con los procesos de la Ingeniería de requisitos. La propuesta
metodológica indicará el momento y la forma para la implementación de prácticas
de priorización de requisitos en un instante del ciclo de vida del proyecto. A partir
de la investigación aquí datada se podrán identificar las características que
enmarcan la priorización de requisitos, lo que será útil para entender en que fase
de la ingeniería de requisitos se puede ubicar este avance de la administración de
requisitos. Se pretende formalizar la tarea de la priorización y agregarle valor a
este tipo de ingeniería, con un nuevo proceso aportar en la madurez de la
ingeniería.
98
11. CONCLUSIONES
Aunque las empresas implementen metodologías que suponen la priorización de
requisitos, esta priorización no es formal, lo que hacen las empresas es
simplemente asignar valores a cada requisito basándose en experiencias de otros
proyectos, ocasionando que la priorización en el caso de Numeral Assignment
Technique sea subjetiva y poco precisa.
Para elegir una técnica de priorización de requisitos la técnica misma debe hacer
manejo de dos aspectos muy importantes:
Atributos de los requisitos10
Roles11
Manejar atributos y hacer participes a los Stakeholders para la evaluación de los
atributos, hace que la priorización sea precisa, objetiva y confiable. Algunos
atributos que pueden ser útiles en el proceso son; Valor relativo para el cliente,
Costo de implementación, riesgo de implementación, penalidad por no
implementación.
Si se quieren obtener mejores resultados existen técnicas formales, reconocidas y
recomendadas para priorizar, aunque se pueden usar técnicas propias siempre y
cuando hagan caso a esos dos aspectos.
Aquellos proyectos software que posean un número considerable de requisitos,
deberían crear grupos en los cuales se puedan distribuir estos requisitos según
10
Se refiere a identificar características de los requisitos y valorar según la influencia de estas
características en el proyecto. 11
Implicar varios participantes en las diferentes actividades de la priorización, esto disminuye la
subjetividad.
99
sus características, lo que permitirá una gestión más fácil del proyecto y de la
priorización.
Un proceso formal, a diferencia de uno informal, ayuda a llevar el trazo de lo
aplicado en dicho proceso, lo que es muy útil en un refinamiento, además de dar
un horizonte al proyecto y plantear metas claras. Formalizar12 procesos es
importante, es así como se puede corroborar qué tanto se ha avanzado hacia el
objetivo.
12
Formalidad, exactitud, puntualidad y consecuencia en las acciones.
100
BIBLIOGRAFIA
[1] CAPERS JONES. “Software Engineering best practices”.
[2] Definición Requisito, Real Academia Español, [en línea]. Disponible en:
http://buscon.rae.es/dpdI/SrvltConsulta?requisito. [Consulta: Noviembre 2011].
[3] WIEGERS, K. “Software Requirements”, second edition. Redmond, WA:
Microsoft Press, 2003.
[4] KOTONYA, G. and SOMMERVILLE, I. “Requirements Engineering: Processes
and Techniques”. Chichester, England: John Wiley & Sons Ltd, 1998.
[5] BRACKETT, J. W. “Software Requirements” (SEI-CM-19-1.2, ADA235642).
Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, 1990.
[6] LEHTOLA, L. "Providing value by prioritizing requirements throughout software
product development State of practice and suitability of prioritization methods."
Tesis, Helsinki University of Technology, May 2006.
[7] KARSLSSON, J. & Ryan, K. "A Cost-Value Approach for Prioritizing
Requirements." IEEE Software 14, 5 (September/October 1997): 67-74.
[8] MOISIADIS, F. “The Fundamentals of Prioritizing Requirements. [En linea] .
Proceedings of Test and Automation Conference” (September 2002). [Consulta:
Noviembre 2011] Disponible en:
http://www.seecforum.unisa.edu.au/Sete2002/ProceedingsDocs/05P-Moisiadis.pdf
[9] Herrmann, A., M. Daneva, ”Requirements Prioritization Based on Benefit and
Cost Prediction: A Method Classification Framework”, Technical Report
SWEHDTR-2008-01, University Heidelberg
[10] FAVARO, J. “Managing Requirements for Business Value”. IEEE Software
14, 5 (Marzo/Abril 2002) ; 23 -24.
[11] “Capability Maturity Model® Integration (CMMI) is a process improvement
approach”, [En Linea]. [Consulta: Noviembre 2011]. Disponible en:
http://www.sei.cmu.edu/cmmi/.
101
[12] Definición Elicitar, Real Academia Española, [en línea]. [Consulta: Noviembre
2010]. Disponible en :http://buscon.rae.es/dpdI/SrvltConsulta?lema=elicitar
[13] GEISSER , M & HILDENBRAND , T. ”A Method for collaborative
Requeriments Elicitation and Decision-Supported Requeriments Analisys”, Paper,
University of Mannheim, Germany.
[14] ROYCE, W.W. “Managing the Development of Large Software Systems:
Concepts and Techniques”. Proceedings of Wescon, pp. 1-9, 1970.
[15] SOMMERVILLE, I. “Software Engineering”, fifth edition. Wokingham, England:
Addison-Wesley, 1996.
[16] SCHACH, S.R. “Object-Oriented and Classical Software Engineering”, fifth
edition.Boston: McGraw-Hill, 2002.
[17] JAMES A SENN, “Análisis y Diseño de Sistema de Información”, Mc Graw Hill,
Enero 1990.
[18] LEHTOLA, L. & Patrik Berander *, Kashif Ahmed Khan. “Towards a Research
Framework on Requirements Prioritization”. Paper, Helsinki University of
Technology.
[19] JACKSON, M. “Software Requirements and Specifications”, Addison-Wesley,
2001.
[20] IEEE Std 610.12.-1990 IEEE “Standard Glossary of Software Engineering
Terminology”.
[21] DAVIS, A. M. “Software Requirements: Objects, Functions, and States”.
UpperSaddle River, NJ:Prentice Hall, 1993.
[22] CMMI Product Team, “CMMI® for Development”, Version 1.3. Carnegie
Mellon, 2010.
[23] JIM HEUMAN. “The Five Levels of Requirements Management Maturity”,
2003.
102
[24] HARWELL, R., ASLAKSEN, E., HOOKS, I., MENGOT, R., PTACK, K.: “What
is a requirement?” Proceedings of the Third International Symposium of the
NCOSE. (1993) 17–24.
[25] JUNG, H. “Optimizing Value and Cost in Requirements Analysis”. IEEE
Software 15,4 (1998), 74-78.
[26] NANCY R., “Requirements Prioritization Introduction”, paper, Software
Engineering Institute, Carnegie Mellon University, September 2008.
[27] AHL, V. "An Experimental Comparison of Five Prioritization Methods."
Master's Thesis, School of Engineering, Blekinge Institute of Technology,
Ronneby, Sweden, 2005.
[28] KARSLSSON, J. "Towards a Strategy for Software Requirements Selection.
Licentiate." Thesis 513, Linköping University, October 1995.
[29] “Extreme Programming Rules.” [En Linea]. Disponible en:
http://www.extremeprogramming.org/rules.html. [Consulta: 22-Marzo-2012].
[29A] BECK, K. & Andres, C. “Extreme Programming Explained: Embrace
Change”, 2nd ed. Boston, MA: Addison-Wesley, 2004.
[30] LEFFINGWELL, D. & WIDRIG, D., “Managing Software Requirements: A Use
Case Approach”, 2nd ed. Boston, MA: Addison-Wesley, 2003.
[31] BOEHM, B. & ROSS, R. "Theory-W Software Project Management: Principles
and Examples." IEEE Transactions on Software Engineering 15, 4 (July 1989):
902-916.
[32] PARK, J.; PORT, D.; & BOEHM, B. "Supporting Distributed Collaborative
Prioritization for Win-Win Requirements Capture and Negotiation," 578-584.
Proceedings of the International Third World Multi-conference on Systemics,
Cybernetics and Informatics (SCI'99) Vol. 2. Orlando, FL, July 31-August 4, 1999.
Orlando, FL: International Institute of Informatics and Systemics (IIIS), 1999.
[33] DAVIS, A. "The Art of Requirements Triage." IEEE Computer 36, 3 (March
2003): 42-49.
103
[33A] DAVIS, A. “Just Enough Requirements Management: Where Software
Development Meets Marketing”. New York: Dorset House, 2005 (ISBN 0-932633-
64-1).
[34] MOISIADIS, F. "Prioritising Scenario Evolution." International Conference on
Requirements Engineering (ICRE 2000). June 2000.
[35] MOISIADIS, F. "A Requirements Prioritisation Tool." 6th Australian Workshop
on Requirements Engineering (AWRE 2001). Sydney, Australia, November 2001.
[36] “Marketísimo: ¿Qué es y cómo se usa el análisis conjoint?” [En linea].
Disponible en: http://marketisimo.blogspot.com/2008/06/qu-es-y-cmo-se-usa-el-
anlisis-conjoint.html. [Consulta: 29-Apr-2012].
[37] SAATY , T. L. “The Analytic Hierarchy Process”. New York, NY: McGraw-Hill,
1980.
[38] KARSLSSON, J. "Software Requirements Prioritizing," 110-116. Proceedings
of the Second International Conference on Requirements Engineering (ICRE'96).
Colorado Springs, CO, April 15-18, 1996. Los Alamitos, CA: IEEE Computer
Society, 1996.
[39] “Kano.” [En linea]. Disponible en:
http://www.pragmaticmarketing.com/publications/magazine/4/3/0605ss. [Consulta:
22-Apr-2012].
[40] PATRIK, B & ANNELIESE,A. “Engineering and Managing Software
Requirements”. Berlin, Blekinge Institute of Technology, p.p 69-94, 2005.
[41] YEH, A. Requirements Engineering Support Technique (REQUEST): A Market
Driven Requirements Management Process. Proceedings of the Second
Symposium of Quality Software Development Tools, IEEE Computer Society
Press, pp. 211-223, 1992
[42] VIGGO AHL. An experimental comparison of five prioritization methods.
Master Thesis, August 2005.
104
ANEXO A. ENCUESTA PARA EL ESTUDIO DE CONTEXTO; DIAGNOSTICO
DE PROCESOS PARA PRIORIZACIÓN DE REQUISITOS.
UNIVERSIDAD DE SAN BUENAVENTURA CALI
FACULTAD DE INGENIERÍA
PROGRAMA INGENIRIA DE SISTEMAS
DIAGNÓSTICO DE PROCESOS PARA PRIORIZACIÓN DE REQUISITOS
De manera especial se agradece su colaboración para responder este cuestionario. Este
instrumento hace parte de una investigación sobre la aplicación de métodos y técnicas de
priorización de requisitos en las empresas de la industria del software, con el fin de hacer una
caracterización en cuanto a la investigación mencionada. La información suministrada será
tratada con la confidencialidad pertinente.
Fecha (dd/mm/aaaa)
Nombre de la Empresa
Nombre del encuestado
Cargo
Telefono(s)
I. Información general de la organización de la empresa
1. Marque con una X el tamaño de su empresa de acuerdo a: a. Ingenieros relacionados con las actividades de desarrollo de software
a. 1 a 3 b. 4 a 7
c. 8 a 15 d. 16 a 40
e. 40 ó más
2. ¿Cuántos productos de software tiene su empresa? _____________________________________
105
3. ¿Cuál es su actividad principal?
a. Desarrollo de software genérico
b. Desarrollo de software hecho a la medida
4. ¿Cuántos clientes tiene actualmente la empresa? ____________
5 ¿Cuál(es) de los siguientes modelos ha implementado su organización en los últimos 3 años?
Seleccione todos los que aplican.
a. CMM-SW b. CMMI c. SPICE d. ISO 9001 e. PSP/TSP f. No ha implementado g. No sabe h. Otros, ¿Cuál?____________
II. Información sobre la aplicación de métodos de priorización de requisitos
6. De la cartilla adjunta identifique cuál(es) método(s) de priorización de requisitos aplica. Marque con una X.
a. ____ b. ____ c. ____
¿Aplica alguno(s) en especial que no están en la cartilla?
________________________________________
________________________________________
________________________________________
¿De los métodos de la cartilla cuál(es) en particular le gustaría aplicar?
________________________________________
________________________________________
________________________________________
7. ¿Conoce algún método distinto a los nombrados en la cartilla que sea utilizado por alguna compañía y que haya tenido éxito?
106
a. NO b. SI
Si su respuesta es SI, por favor descríbala a continuación.
MUCHAS GRACIAS POR SU VALIOSA PARTICIPACIÓN
107
CARTILLA DE DOCUMENTACION DE LOS DIFERENTES METODOS DE PRIORIZACIÓN
DE REQUISITOS
METODOS DE AGRUPACIÓN
Método Descripción
Priorización por Agrupación.
Técnica de Asignación de
Peso Numérico (Numeral
Assignment Technique)
[Brackett]
Esta técnica asigna un valor (puntuación) a cada requisito,
adicionalmente los requisitos se dividen en 3 grupos:
Obligatorios, deseables y no esenciales [Brackett]. Los
participantes asignan a los requisitos un número dentro de la
escala de 1 a 5 indicando la importancia de cada uno de ellos
[Karlsson]. Los números en la escala tienen el siguiente
significado:
El cliente no lo necesita.
No es importante.
Bastante importante (Si lo tiene el cliente lo agradece).
Es muy importante (El cliente lo desea).
Es obligatorio (El cliente no puede prescindir de él).
La clasificación final es el promedio de las clasificaciones de todos
los participantes para cada uno de los requisitos.
Top Ten Requirement Cada interesado selecciona los 10 requisitos más importantes
desde su punto de vista. Los requisitos seleccionados por todos
los Stakeholders en su lista de 10, son también considerados los
más importantes.
METODOS MIXTOS COMBINATORIOS
Método Descripción
AHP
Este método utiliza 2 matrices para calcular el valor y los costos
relativos de los requisitos entre si. Mediante el uso de AHP el
ingeniero de requisitos puede confirmar la consistencia de los
resultados. AHP puede ayudar a evitar errores generados de
juicios subjetivos e incrementar la probabilidad de que los
resultados sean fiables. El método AHP consta de 5 pasos :
Revisar los requisitos candidatos y completarlos enteramente.
Aplicar el método de comparación por pares para evaluar
108
el valor relativo de cada uno de los requisitos candidatos.
Aplicar el método de comparación por pares para evaluar el costo relativo de los requisitos candidatos.
Calcular el valor relativo de cada requisito candidato y el costo de su implementación y poder hacer seguimiento en un diagrama de costo – valor.
Usar el diagrama de costo – valor como un mapa que permita analizar los requisitos candidatos.
a. Bastante importante (Si lo tiene el cliente lo agradece).
b. Es muy importante (El cliente lo desea). c. Es obligatorio (El cliente no puede prescindir de
él).
La clasificación final es el promedio de las clasificaciones de todos los participantes para cada uno de los requisitos.
Hierarchy AHP Es una modificación del AHP, en el cual solo los requisitos del
mismo nivel de jerarquía son comparados con los demás.
Cost Value Approach Está basado en el Método AHP, donde todos los requerimientos
son comparados de acuerdo a su importancia y costo de
implementación.
Ordinal Cost Value Approach Los requisitos son puesto en 3 grupos de acuerdo a la importancia
del cliente y en 3 grupos de acuerdo al costo de implementación.
Los resultados son presentados en un diagrama de dispersión de
costo-valor.
Planing Game [Beck] Es una técnica utilizada por el Método de desarrollo de software
Extreme Programming [Beck] y se utiliza con los clientes para
priorizar los requisitos basado en historietas. Esta es una
variación de la técnica de asignación numérica donde el cliente
distribuye los requisitos en tres grupos, "aquellos sin los cuales el
sistema no funcionará", "los que son menos esenciales, pero
proporcionan un importante valor empresarial", y "los que sería
bueno tener. "
Wieger´s Method [Wiegers]. Este método se relaciona directamente con el valor de cada
requisito de un cliente [Wiegers]. La prioridad se calcula
dividiendo el valor de una obligación por la suma de los costos y
riesgos técnicos asociados a su aplicación [Wiegers]. El valor de
una obligación se considera como función tanto en el valor
proporcionado por el cliente para el cliente y la pena que se
produce si el requisito falta. Esto significa que los desarrolladores
deben evaluar el costo de la exigencia y sus riesgos de
implementación, así como la penalidad si el requisito falta. Los
109
atributos son evaluados en una escala de 1 a 9.
Impact Validation El impacto que cada requerimiento propuesto tiene sobre el logro
en el nivel más alto del proyecto es evaluado sobre una escala
definida, los requerimientos con mayor impacto son vistos como
los más importantes.
METODOS DE VOTACIÓN
Método Descripción
$100 Test (Acumulative
Mtehod) [Leffingwell]
El método de los 100 puntos es básicamente un esquema de tipo
votación que es usada en ejercicios de lluvia de ideas. A cada
interesado se le dan 100 puntos que él o ella puedan utilizar
para votar por los requisitos que considere más importantes, el
interesado puede usarlos de la manera que él considere más
pertinente. Por ejemplo si existen 4 requisitos que él considera
son igual de prioritarios, entonces el podrá darle a cada uno 25
puntos. Si existe un requisito que él considera que de
importancia primordial podría darle los 100 puntos.
110
ANEXO B. DOCUMENTO DE ANÁLISIS Y DISEÑO DE LA APLICACIÓN
“PGWITHWIEGER”.
VALIDACIÓN Y APLICACIÓN DE TÉCNICAS
DE PRIORIZACIÓN DE REQUISITOS
JHONNY GÓMEZ CHALACÁN
111
ÍNDICE GENERAL
Pág.
INTRODUCCIÓN 113
1. DEFINICIÓN DEL PROBLEMA 114
2. ACTORES DEL SISTEMA 115
2.1 JEFE DEL PROYECTO 115
2.2 REPRESENTANTE DE LOS DESARROLLADORES 115
2.3 REPRESENTANTE DE LOS CLIENTES 115
2.4 SISTEMA 115
3. REQUISITOS FUNCIONALES 116
3.1 LISTA DE REQUISITOS 116
3.1.1 EL SISTEMA DEBE PERMITIR 116
4. CASOS DE USO DEL SISTEMA 117
4.1 LISTADO DE CASOS DE USO 117
5. CASOS DE USO EXPANDIDOS 119
5.1 CASOS DE USO 119
112
6. DIAGRAMA DE CASOS DE USO DEL SISTEMA 130
6.1 REPRESENTANTE DE LOS CLIENTES 130
6.2 JEFE DEL PROYECTO 130
6.3 SISTEMA 133
6.4 PANTALLAS DEL SISTEMA 134
7. MODELO DE ENTIDAD DE RELACIÓN 138
113
Universidad de San Buenaventura
Cali - Colombia.
Documento de análisis y diseño de la aplicación “PGwithWieger”.
INTRODUCCIÓN
El presente es el documento de análisis y diseño para la construcción de un
sistema de priorización de requisitos que combina dos técnicas (PG, Wieger´s
Method) reconocidas por la industria y validadas en el documento base “Validación
y Aplicación de técnicas de priorización de requisitos”.
Versión Fecha Autor(es) Descripción
1.0 05/03/2012 Jhonny Gómez
Chalacán
Construcción del documento de análisis y diseño
para el sistema PGwithWieger.
2.0 30/04/2012 Jhonny Gómez
Chalacán
Modificación y desarrollo de última versión del
documento de análisis y diseño para el sistema
PGwithWieger.
114
1. DEFINICIÓN DEL PROBLEMA
En el Desarrollo de requisitos de software un factor determinante es la gestión de
los mismos y a su vez la priorización y planificación, dicha priorización es un factor
de éxito que determina la óptima utilización de los recursos tiempo, costos y factor
humano para una efectiva culminación del producto esperado.
La evidente necesidad de contar con un método que nos permita realizar una
optima priorización y planificación de los requisitos de software, abre las puertas
para aportar en el proceso de ingeniería de software una propuesta metodológica,
la cual llene el vació que hoy no cobijan algunas metodologías ó estándares en
los cuales se aborda el tema de la priorización como una actividad del desarrollo
de requisitos de software pero no se enfatiza en el ¿cómo?, es decir, se plantea el
hecho de priorizar, pero no se deja claro el cómo se debe priorizar, dejando de
alguna manera al libre albedrío del líder de desarrollo (o del proyecto) , una
actividad tan importante como la priorización de los requisitos, donde en ultimas,
se utiliza más que la técnica su propia experticia.
115
2. ACTORES DEL SISTEMA
2.1 JEFE DEL PROYECTO
Gestionar usuarios y sus roles.
Gestiona requisitos y ajusta los aportes de los demás participantes en la
priorización.
2.2 REPRESENTANTE DE LOS DESARROLLADORES
Gestiona requisitos y ajusta los aportes de los demás participantes en la
priorización.
Suministra las puntuaciones para el costo y el riesgo.
2.3 REPRESENTANTE DE LOS CLIENTES
Suministra las puntuaciones para el beneficio y la penalidad.
2.4 SISTEMA
Se encarga de listar automáticamente los requisitos, usuarios, categorías,
roles, tipos de requisitos, proyectos.
116
3. REQUISITOS FUNCIONALES
Un requisito funcional es aquel que permite de cierta manera saber que funciones
debe realizar el software a realizar; Además de saber los límites del mismo.
3.1 LISTA DE REQUISITOS
3.1.1 El sistema debe permitir
1. Gestionar proyectos.
2. Gestionar requisitos.
3. Gestionar usuarios.
4. Gestionar cuentas de usuario.
5. Gestionar tipo de cuentas
6. Gestionar categorías de requisitos.
7. Gestionar tipos de requisitos.
8. Catalogar requisitos.
9. Asignar valores a los requisitos (Costo relativo, Penalidad relativa, Riesgo
relativo, Beneficio Relativo).
10. Asignar peso (o influencia) que cada factor de valorización tiene en el proyecto.
11. Priorizar requisitos por categoría.
12. Listar los requisitos priorizados.
13. Listar requisitos.
117
4. CASOS DE USO DEL SISTEMA
4.1 LISTADO DE CASOS DE USO
1. Modificar Proyecto.
2. Crear proyecto
3. Inactivar Proyecto
4. Activar Proyecto
5. Consultar Proyecto
6. Listar Proyectos
7. Crear Requisitos
8. Modificar Requisitos
9. Eliminar Requisitos
10. Consultar Requisitos
11. Listar requisitos
12. Crear categorías de requisitos
13. Modificar categorías de requisitos
14. Eliminar categorías de requisitos
15. Consultar categorías de requisitos
16. Listar Categorías de requisitos
17. Crear tipos de requisitos
18. Modificar tipos de requisitos
19. Eliminar tipos de requisitos
20. Consultar tipo de requisitos
21. Listar tipos de requisitos
22. Calcular valor total
23. Calcular Costo total
24. Calcular riesgo total
25. Calcular valor porcentual
26. Calcular Costo Porcentual
27. Calcular riesgo porcentual
28. Configurar influencias
29. Consultar configuración de influencias
30. Modificar configuración de influencias
31. Listar requisitos priorizados.
32. Priorizar Requisitos
33. Crear Usuario
34. Modificar Usuario
118
35. Consultar Usuario
36. Inactivar usuario
37. Activar usuario
38. Listar usuarios
39. Crear rol de usuario
40. Consultar rol de usuario
41. Listar rol de usuario
42. Eliminar rol de usuario
43. Crear cuenta
44. Modificar cuenta
45. Consultar cuenta
46. Inactivar cuenta
47. Activar cuenta
48. Log In
49. Log Out
119
5. CASOS DE USO EXPANDIDOS
A continuación se exponen 5 guiones los cuales se definen como un CRUD y un
caso de uso del negocio.
5.1 CASOS DE USO
7 Crear requisito
8 Modificar requisito
9 Eliminar requisito
10 Consultar requisito
32 Priorizar requisitos
No. 1 CU_07_CREAR_REQUISITO
Nombre Crear requisito
Descripción Crea un nuevo requisito asociado a un proyecto
Actores Jefe del proyecto, Representante de los desarrolladores
Fase Análisis
Guión
Actor Sistema
1 Ingresa el código del
proyecto
2 Consulta si existe el proyecto
3 Ingresa código del requisito 4 Consulta si el requisito existe.
5 Ingresa nombre del requisito
6 Ingresa el código del Tipo
de requisito
7 Consulta si existe el tipo de
requisito.
8 Ingresa el código de la
categoría de requisito.
9 Consulta si existe la categoría.
10 Ingresa la descripción
11 Ingresa valor del beneficio
relativo.
12 Valida que sea numérico, mayor a
cero y se encuentre en un rango de
1 a 10.
120
13 Ingresa valor del Costo
relativo.
14 Valida que sea numérico, mayor a
cero y se encuentre en un rango de
1 a 10.
15 Ingresa valor de la
penalidad relativa.
16 Valida que sea numérico, mayor a
cero y se encuentre en un rango de
1 a 10.
17 Ingresa valor del Riesgo
relativo.
18 Valida que sea numérico, mayor a
cero y se encuentre en un rango de
1 a 10.
19 Almacena información del
requisito.
Excepciones
1. Proyecto no existe
Nombre Mensaje
Paso 2
1. Si no existe un proyecto con el código
digitado. Se despliega el siguiente
mensaje “No existe un proyecto con el
código xxxxx”.
2. Se despliega el mensaje “¿Desea
crear un nuevo proyecto?”
3. si la respuesta es afirmativa,; Llama al
caso de uso CREAR PROYECTO.
4. Vuelve al paso 1.
2. El requisito existe.
Nombre Mensaje
Paso 4
1. Se despliega la información del
requisito.
3. Tipo de requisito no existe.
Nombre Mensaje
Paso 7
1. Si no existe un tipo de requisito con el
código digitado. Se despliega el
siguiente mensaje “No existe un tipo
de requisito con el código xxxxx”.
2. Se despliega el mensaje “¿Desea
crear un nuevo tipo de requisito?”
3. si la respuesta es afirmativa,; Llama al
caso de uso CREAR TIPO DE
REQUISITO.
4. Vuelve al paso 6.
4. Categoría no existe.
121
Nombre Mensaje
Paso 9
1. Si no existe una categoría con el
código digitado. Se despliega el
siguiente mensaje “No existe una
categoría con el código xxxxx”.
2. Se despliega el mensaje “¿Desea
crear una nueva categoría?”
3. si la respuesta es afirmativa,; Llama al
caso de uso CREARCATEGORIA.
4. Vuelve al paso 8.
5. Valor no numérico, no mayor a cero.
Nombre Mensaje
Paso 12,14,16,18
1. Si el valor ingresado no es numérico,
menor o igual a cero. Se despliega el
mensaje “El valor debe ser numérico
mayor a cero.”
2. Vuelve al paso 11,13,15,17
respectivamente
6. Valor fuera del rango.
Nombre Mensaje
Paso 12,14,16,18
1. Si el valor ingresado se encuentra
fuera del rango. Se despliega el
mensaje “El valor debe tener valores
entre 1 - 10.”
2. Vuelve al paso 11,13,15,17
respectivamente
Casos de uso
relacionados
Consultar proyecto, Crear Proyecto, consultar tipo de requisito, Crear Tipo de
requisito, consultar categoría, Crear Categoría, Consultar requisito.
Documentos
Relacionados
Especificación de requisitos.
Requerimiento
Fuente
Gestionar requisitos
Autor Jhonny Gómez Chalacán
Revisado por
Fecha
Creación
Marzo 06 de 2012
Fecha de
Ultima
Modificación
122
No. 2 CU_08_MODIFICAR_REQUISITO
Nombre Modificar requisito
Descripción Modifica un requisito asociado a un proyecto
Actores Jefe del proyecto, Representante de los desarrolladores
Fase Análisis
Guión
Actor Sistema
1 Ingresa el código del
proyecto
2 Consulta si existe el proyecto
3 Ingresa código del requisito 4 Consulta si el requisito existe.
5 Ingresa nombre del requisito
6 Ingresa el código del Tipo
de requisito
7 Consulta si existe el tipo de
requisito.
8 Ingresa el código de la
categoría de requisito.
9 Consulta si existe la categoría.
10 Ingresa la descripción
11 Ingresa valor del beneficio
relativo.
12 Valida que sea numérico, mayor a
cero y se encuentre en un rango
de 1 a 10.
13 Ingresa valor del Costo
relativo.
14 Valida que sea numérico, mayor a
cero y se encuentre en un rango
de 1 a 10.
15 Ingresa valor de la
penalidad relativa.
16 Valida que sea numérico, mayor a
cero y se encuentre en un rango
de 1 a 10.
17 Ingresa valor del Riesgo
relativo.
18 Valida que sea numérico, mayor a
cero y se encuentre en un rango
de 1 a 10.
19 Actualiza información del requisito.
123
Excepciones
1. Proyecto no existe
Nombre Mensaje
Paso 2
1. Si no existe un proyecto con el código
digitado. Se despliega el siguiente
mensaje “No existe un proyecto con el
código xxxxx”.
2. Se despliega el mensaje “¿Desea
crear un nuevo proyecto?”
3. si la respuesta es afirmativa; Llama al
caso de uso CREAR PROYECTO.
4. Vuelve al paso 1.
2 El requisito no existe.
Nombre Mensaje
Paso 4
1. No se despliega ningún tipo de
información.
3. Tipo de requisito no existe.
Nombre Mensaje
Paso 7
1. Si no existe un tipo de requisito con el
código digitado. Se despliega el
siguiente mensaje “No existe un tipo
de requisito con el código xxxxx”.
2. Se despliega el mensaje “¿Desea
crear un nuevo tipo de requisito?”
3. si la respuesta es afirmativa; Llama al
caso de uso CREAR TIPO DE
REQUISITO.
4. Vuelve al paso 6.
4. Categoría no existe.
Nombre Mensaje
Paso 9
1. Si no existe una categoría con el
código digitado. Se despliega el
siguiente mensaje “No existe una
categoría con el código xxxxx”.
2. Se despliega el mensaje “¿Desea
crear una nueva categoría?”
3. si la respuesta es afirmativa,; Llama al
caso de uso CREARCATEGORIA.
4. Vuelve al paso 8.
124
5. Valor no numérico, no mayor a cero.
Nombre Mensaje
Paso 12,14,16,18
1. Si el valor ingresado no es numérico,
menor o igual a cero. Se despliega el
mensaje “El valor debe ser numérico
mayor a cero.”
2. Vuelve al paso 11,13,15,17
respectivamente
6. Valor fuera del rango.
Nombre Mensaje
Paso 12,14,16,18
1. Si el valor ingresado se encuentra
fuera del rango. Se despliega el
mensaje “El valor debe tener valores
entre 1 - 10.”
2. Vuelve al paso 11,13,15,17
respectivamente
Casos de uso
relacionados
Consultar proyecto, Crear Proyecto, consultar tipo de requisito, Crear Tipo de
requisito, consultar categoría, Crear Categoría, Consultar requisito.
Documentos
Relacionados
Especificación de requisitos.
Requerimiento
Fuente
Gestionar requisitos
Autor Jhonny Gómez Chalacán
Revisado por
Fecha
Creación
Marzo 06 de 2012
Fecha de
Ultima
Modificación
No. 3 CU_9_ELIMINAR_REQUISITO
Nombre Eliminar requisito
Descripción Elimina un requisito asociado a un proyecto
Actores Jefe del proyecto, Representante de los desarrolladores
125
Fase Análisis
Guión
Actor Sistema
1 Ingresa el código del
proyecto
2 Consulta si existe el proyecto
3 Ingresa código del requisito 4 Consulta si el requisito existe.
5 Borra información del requisito.
6 Actualiza información.
Excepciones
1. Proyecto no existe
Nombre Mensaje
Paso 2
1. Si no existe un proyecto con el código
digitado. Se despliega el siguiente
mensaje “No existe un proyecto con el
código xxxxx”.
2. Se despliega el mensaje “¿Desea
crear un nuevo proyecto?”
3. si la respuesta es afirmativa,; Llama al
caso de uso CREAR PROYECTO.
4. Vuelve al paso 1.
2. El requisito no existe.
Nombre Mensaje
Paso 4
2. No se despliega ningún tipo de
información.
Casos de uso
relacionados
Consultar proyecto, Crear Proyecto, Consultar requisito.
Documentos
Relacionados
Especificación de requisitos.
Requerimiento
Fuente
Gestionar requisitos
Autor Jhonny Gómez Chalacán
Revisado por
Fecha
Creación
Marzo 06 de 2012
Fecha de
Ultima
Modificación
126
No. 4 CU_10_CONSULTAR_REQUISITO
Nombre Eliminar requisito
Descripción Consulta un requisito asociado a un proyecto
Actores Jefe del proyecto, Representante de los desarrolladores
Fase Análisis
Guión
Actor Sistema
1 Ingresa el código del
proyecto
2 Consulta si existe el proyecto
3 Ingresa código del requisito 4 Despliega la información del
requisito.
Excepciones
1. Proyecto no existe
Nombre Mensaje
Paso 2
1. Si no existe un proyecto con el código
digitado. Se despliega el siguiente
mensaje “No existe un proyecto con el
código xxxxx”.
2. Se despliega el mensaje “¿Desea
crear un nuevo proyecto?”
3. si la respuesta es afirmativa,; Llama al
caso de uso CREAR PROYECTO.
4. Vuelve al paso 1.
2. El requisito no existe.
Nombre Mensaje
Paso 4
1. No se despliega ningún tipo de
información.
Casos de uso
relacionados
Consultar proyecto, Crear Proyecto.
Documentos
Relacionados
Especificación de requisitos.
Requerimiento
Fuente
Gestionar requisitos
Autor Jhonny Gómez Chalacán
127
Revisado por
Fecha
Creación
Marzo 06 de 2012
Fecha de
Ultima
Modificación
No. 5 CU_32_PRIORIZAR_REQUISITOS
Nombre Priorizar requisitos
Descripción A partir de los valores en beneficio relativo, costo relativo, penalidad relativa,
riesgo relativo, se debe calcular la prioridad de cada uno de los requisitos en el
proyecto.
Actores Jefe del proyecto, Representante de los desarrolladores
Fase Análisis
Guión
Actor Sistema
1. Ingresa el código del
proyecto
2. Consulta si existe el proyecto
3. Ingresa el código del Tipo
de requisito
4. Consulta si existe el tipo de
requisito.
5. Ingresa el código de la
categoría de requisito.
6. Consulta si existe la categoría.
7. Consultar requisitos
8. Calcular valor total
9. Calcular Costo total
10. Calcular riesgo total
11. Calcular valor porcentual
12. Calcular Costo Porcentual
13. Calcular riesgo porcentual
14. Multiplicar Influencia del
costo por el costo
porcentual
15. Multiplicar influencia del
riesgo por el riesgo
porcentual
16. Dividir Valor porcentual
sobre la suma de los
resultados de las
128
multiplicaciones en el
paso 14 y 15.
17. Actualizar información
18. Listar Requisitos priorizados.
Excepciones
1. Proyecto no existe
Nombre Mensaje
Paso. 2
5. Si no existe un proyecto con el código
digitado. Se despliega el siguiente
mensaje “No existe un proyecto con el
código xxxxx”.
6. Se despliega el mensaje “¿Desea crear
un nuevo proyecto?”
7. si la respuesta es afirmativa,; Llama al
caso de uso CREAR PROYECTO.
8. Vuelve al paso 1.
2. Tipo de requisito no existe.
Nombre Mensaje
Paso 4
5. Si no existe un tipo de requisito con el
código digitado. Se despliega el
siguiente mensaje “No existe un tipo de
requisito con el código xxxxx”.
6. Se despliega el mensaje “¿Desea crear
un nuevo tipo de requisito?”
7. si la respuesta es afirmativa,; Llama al
caso de uso CREAR TIPO DE
REQUISITO.
8. Vuelve al paso 6.
4. Categoría no existe.
Nombre Mensaje
Paso 6
5. Si no existe una categoría con el código
digitado. Se despliega el siguiente
mensaje “No existe una categoría con
el código xxxxx”.
6. Se despliega el mensaje “¿Desea crear
una nueva categoría?”
7. si la respuesta es afirmativa,; Llama al
caso de uso CREARCATEGORIA.
8. Vuelve al paso 8.
129
Casos de uso
relacionados
1. Consultar requisitos
2. Calcular valor total
3. Calcular Costo total
4. Calcular riesgo total
5. Calcular valor porcentual
6. Calcular Costo Porcentual
7. Calcular riesgo porcentual
8. Consultar Proyectos
9. Consultar Categorías
10. Consultar Tipos de requisito
Documentos
Relacionados
Especificación de requerimientos.
Requerimiento
Fuente
Priorizar requisitos
Autor Jhonny Gómez Chalacán
Revisado por
Fecha Creación Marzo 06 de 2012
Fecha de Ultima
Modificación
130
6. DIAGRAMA DE CASOS DE USO DEL SISTEMA
6.1 REPRESENTANTE DE LOS CLIENTES
6.2 JEFE DEL PROYECTO
131
132
133
Nota: El Representante de los desarrolladores tiene relacionados los mismos
casos de uso que el Jefe del Proyecto, a diferencia que no puede crear nuevos
usuario, cuentas, ni roles.
6.3 SISTEMA
134
6.4 PANTALLAS DEL SISTEMA
Gestión de categorías
Priorización
135
Gestión de proyectos
136
Gestión de requisitos
137
Gestión de requisitos
138
7. MODELO DE ENTIDAD DE RELACIÓN